Add egs_brachy as a third-party submodule

[mchamberland]

@ftessier Let's move our discussion on how to include egs_brachy as a third-party submodule from #906 to here.

First order of business for me will be to look at our CLRP repos and figure out where we're at and what EGSnrc modifications are needed by egs_brachy.

[mchamberland]

I'll write things down as I find them.

Since our egs_brachy repo has the following structure:

docs/
egs_brachy/   <--- where the source code is
CONTRIBUTORS
LICENSE
README.md

we've modified the EGSnrc configure script to account for this structure.

[mchamberland]

Our custom egs_autoenvelope can use a Sobol QRNG and the gzstream library. See here. Those features were stripped out when egs_autoenvelope was added to egs++.

[mchamberland]

I see 96b9747 refers to Sobol and gzstream and points to this repo, which I had forgotten about. We were using that method to share those extras, before we decided to fork EGSnrc and distribute it with those extras already built-in + egs_brachy.

[mchamberland]

Note that the repo is slightly out of date since it changed the egsphant support to ndgeometry, but we didn't roll back this change when we rolled back the egsphant into egs_glib (due to the ramp file issue). See here.

[ftessier]

Thanks for the details. I think we can include the missing bits, minding the copyright (some files say copyright NRC, but I think it ought to CRLP; anyways we can sort this out). I am not sure how to best go about the integration, I would like to establish a common method for all third-party contributions. I am debating over:

1. submodule under third-party/ just for the application, and integrate the other bits in EGSnrc itself: impedes development of the third-party application, which then depends on integration of new functionalities upstream.

2. submodule under third-party/ for everything, including a patch (for apps requiring modifications to EGSnrc files).

I prefer the second alternative, which from a user perspective could look something like:

1. clone EGSnrc
2. git submodule update --init third-party/egs_brachy
3. cd third-party/egs_brachy/
4. git apply egs_brachy.patch
5. configure EGSnrc

Too technical? Requires git, but such steps could be abstracted inside an egs_brachy install script to run before configure. What is nice here is that developers can release hot fixes any time and just update the patch in their repo. Issue remains (as always) the reconfiguration upon changes, and syncing version of EGSnrc with that of third-party code.

At any rate, food for thought.

[mchamberland]

I also much prefer option 2.

[ftessier]

@mchamberland we are currently teaching a course in Wisconsin, and @dworogers and I are talking about egs_brachy integration again. Good thing you and I penned down our foregoing discussion, I did not remember half of what we had said last summer! 😄

At any rate, will you have some time over the summer to help me out with this? I will write draft instructions, and we can go from there. Let's see how simple we can make it for end users of egs_brachy!

[mchamberland]

@ftessier yes, I can take some time to sort this out with you. Would be great!