egs_chamber either produces zeros or exceeds MXSTACK

[ojalaj]

I've been testing/learning to use egs_chamber. I've used a simple test file having a cylinder water phantom with a thin disc of air, where a collimated beam from a linac (IAEA phsp file) hits. I've also edited the example files for testing purposes - the one with simple Farmer chamber using either no VRTs at all or then using those ones that are utilized in test files (RR/XCSE/IPSS).

I've run simulations on two Linux clusters - one using the develop branch from March and the other one using the latest develop branch. In the former cluster I'm able to run the two test files with no VRTs with expected results, but when running the Farmer chamber example with VRTs, I get In subroutine ANNIH_AT_REST stack size exceeded! error. I've already previously increased the MXSTACK to 900000 to get other test files running, but now when I increase MXSTACK to 950000, all three different test files run without errors, but produce zero results with 100% uncertainty.

What is interesting, is that on the other cluster I needed to decrease MXSTACK to 10000 in order to get expected results from first two test files with no VRTs, but with the third test case, I get In subroutine ANNIH_AT_REST stack size exceeded!. When I increase MXSTACK to 100000, all three different test files run without errors, but produce zero results with 100% uncertainty.

So basically there are two problems:

1. Why there is such behaviour, i.e., with MXSTACK values below certain level I get expected results, but after applying VRTs, it needs to be increased, but all test files start producing zero results.

2. Why there is so large difference in the MXSTACK "threshold" values between two clusters/develop branch versions?

This behaviour has already been reported in G+ forum, but no solutions/explanations were provided.

[mainegra]

@ojalaj in the latest version $MAXRELAX in egsnrc.macros was increased to 10000 from 5000 and the binding_energies array dimension increased from (6,100) to (30,100) to allow relaxations for all available atomic shells in EADL. Just to test this, reset these dimensions to their previous values or set $EADL_RELAX to .false. in egsnrc.macros and see if the problem "goes away". You could monitor the memory consumption of your simulation using top and see if you are reaching the limits of the available memory. We have 8 Gb RAM memory nodes here. I have been running x ray simulations with splitting numbers of 3000000 and $MXSTACK = 5 millions on the BEAMnrc source and $MXSTACK = 9 mio in cavity. All this with the latest version. If you continue to have issues, perhaps you could send us your input file to try it here.

[ojalaj]

Thank you @mainegra for the info/tips. So far I've done the tests in interactive mode, since all the nodes on our cluster are reserved for one long parallel simulation (and practically all the HW resources are thus in use). This means that it might be that the egs_chamber simulation is running out of memory, so I need to wait for until the previous parallel simulation ends until I can really test what you suggested. The simulations I've tested so far crashed in the beginning of the first chunk, so practically no particles were simulated. If the simulation runs out of memory maybe there could be some clear(er) message to the user of that?

[ojalaj]

I've now done testing on both clusters ('develop' branch from March and June), setting $EADL_RELAX either .true of .false, but the problem persists, i.e., with MXSTACK below certain threshold two test files without VRTs run OK and the third test file with VRTs fails and when MXSTACK is increased, all test files produce zero results. I've also monitored memory usage with top, but there has always been memory available (at least 0.5 GB). I'll send you the test input files for a try.

[mainegra]

Thanks @ojalaj ! This info is very useful!