Allow EGSnrc applications to run from any directory

[ftessier]

Problem Description

EGSnrc currently requires input files for an application to reside inside the application's directory in $EGS_HOME. This is also where output files are written. This constraint makes managing multiple projects cumbersome, as the directory becomes cluttered with input and output files from unrelated projects over time.

Proposed Solution

Enable EGSnrc applications to run from any directory, allowing simulation input and output to be isolated in their own project-specific directories. The application directory in $EGS_HOME would still be used for source files, and users could continue to run applications there as before. However, it should also be possible to run applications from any other location. This would match the expected behaviour of all other commands entered in the terminal.

Ideally, this enhancement would go a step further and also allow compilation of any EGSnrc application code anywhere. This change would essentially make $EGS_HOME obsolete for regular usage, allowing EGSnrc to function more like a standard software library toolkit.

Alternatives Considered

Long-time users of EGSnrc often develop workarounds, such as:

• Moving input and output files to a project directory after completion.
• Using symbolic links to manage files across project directories.
• Cloning and configuring a new EGSnrc instance for each project.

While these methods work, they are cumbersome and error-prone.

Steps to Implement

• [ ] Identify all dependencies on the application directory path for input and output in EGSnrc.
• [ ] Update every instance to use the current directory (./) for input and output.

Feedback on this proposal is welcome, especially regarding potential issues or improvements for implementation.

[crcrewso]

The impact of this sounds quite widespread, would it be better to break this into two stages 1) Break each code into subfolders

• bin
• input
• scratch
• output 1) Once all impacts have been discovered and tested, then consider moving each folder to a more modern location

I say this after having set up a git repositor of $EGS_HOME specially configured so that my input files don't go disappearing on me

[ftessier]

I am not sure what you mean @crcrewso, so in turn I wonder if what I said was clear. All I am suggesting is that the directory ./ becomes the default first path for input and output files for any EGSnrc application. Then it can move on to the other traditional paths like the egs_home directory etc.

I don't expect this to be a breaking change. Application could still compile to egs_home/bin, but one should be able to run them from any location.

[crcrewso]

[..] in turn I wonder if what I said was clear.

I reread both your post and your response, you were clear, I had been thinking that any change allowing any file location variance would be a breaking change. I can now see what you were going for, any change would be a good one.

My issues with organization have been: 1) How full each application folder gets (technical) 1) With applications like dosxyznrc I've had to play with the mortran dimension limits and haven't kept track of when I need to recompile (technical/human) 1) Archiving results and their source inp so that I don't accidently modify the source file (human)

[ftessier]

I agree with all three points you raised: ongoing grief when using EGSnrc, for many (most?) EGSnrc users, myself included.

1. My workaround is to use symlinks, but more often than not I use rsync -av between a specific project/ directory (outside of EGSnrc/) and an application directory such as $EGS_HOME/egs_chamber, to keep the latter pristine otherwise.

2. Fixed array sizes in F77 are a significant pain point. I am in the habit of adding my egs_home/ to git (after configuration), to keep track of modifications and easily diff against the pristine source code. Note that since by default egs_home is git ignored, you can git init your egs_home as a separate repo inside EGSnrc/ without conflict! I also make before launching new simulations, especially after not using the app in a while.

3. I usually rsync -av the entire app directory (and density correction files!) in my separate projects folder (outside of EGSnrc), so that years later I can diff with the existing version and be able to recover where I left off. Another trick which I use for quick simulations while I am in the middle of some other simulations, is to clone and configure EGSnrc all over again in a separate location for that quick one off. In a way, that is one sure way to reproduce your results: one EGSnrc clone per project!! 😄

[crcrewso]

I just had a whole new idea. What if we created a new front end, that handled projects, symlinks, all these new features, and would leave the existing code alone. I'm thinking python might be the most maintainable. We wouldn't have to deal with teaching users about simlinks or rsync?

[ftessier]

I like the way you think! 😄 For a long time I pondered on an overall egs command, that could dispatch sub-commands, e.g., egs chamber ..., egs configure ..., with perhaps man pages for egs-chamber, egs-configure, etc. This is inspired by the way git and other modern packages work, manifestly 😉

But in the short term, why even build a front end to maintain an outdated system that is rigid when it comes to file locations etc. If we simply allow ./ as the first path, and have the EGSnrc bin directory in the path, I reckon it would behave like most other software, and could be done quickly.

Interestingly, when we teach an EGSnrc course, the participants that know linux the most are the one struggling with the EGSnrc file system rigidity the most, because it does not behave as expected!

[crcrewso]

But in the short term, why even build a front end to maintain an outdated system that is rigid when it comes to file locations etc.

My worry is that identifying all of the references to file locations is a higher risk than just wrapping the existing code and leaving it alone. I know, a kludge.

[ftessier]

Yes, once I start looking I might change my mind! 😀