Open ftessier opened 3 years ago
I see only cosmetic changes in the SLAB component module's history on git, back to 2015. @agsponer-metas if you can run a test with EGSnrc v2016 quickly, that would prove useful. We have CVS history back to V4 2.2.3, but it is harder to untangle that... So knowing if the change happened before or after v2016 (when EGSnrc was ported to git) would help me steer my efforts in the right direction!
@ftessier, I tried using the v2016 tag, but could not get this version of EGSnrc to compile... (see compile_error_v2016.txt ). However, I was able to compile and run the simulation using the v2015 version (is there a significant difference between v2015 and v2016?).
With v2015 I still get the same result as v2021 (an excess of electrons, see plot). Similar to before, an airgap of 0.01 cm is inserted before the SLAB (see .egslst).
Therefore, I assume the relevant changes in the code happened some time before EGSnrc was ported to git / 2015.
@agsponer-metas, thank you for checking, this is helpful, I will dig up older changes to the SLABS component module, unless @blakewalters can recall any such change from memory alone. If I understand correctly, the SLAB CM is now behaving as expected (i.e., with the extra air added), right?
Hi @ftessier Thanks for looking into this issue! Yes, the SLAB CM is now (v2021) behaving as expected. What I'm trying to figure out is if this means that the old results obtained using EGSnrc v4 rev 2.2.3 are incorrect, or if the differences could be caused by some other parameters which have changed between EGS versions.
On a related note, I found the second CM in the simulation of the treatment head where I get differences between the two EGSnrc versions. As mentioned previously, even after adding the 0.01 cm of material to the SLAB mentioned above the results for the simulation using all CMs do not agree between the EGS versions.
This second CM is the flattening filter, which is constructed using FLATFILT. I ran a simulation using just this CM (and all other CMs removed, see filter_only_treathead_phot_8_5mev.egsinp.txt). In the resulting energy spectrum (total_energy.pdf) I see a very large difference for the primary electrons, but identical results for all other particle types. What intrigues me is that the peak around 8 MeV is identical for both EGSnrc versions.To me, if there was some additional absorption (which leads to EGSnrc v4 having fewer primary electrons at lower energies as in the plot), I would expect that this would also have an effect on the maximum electron energy.
In contrast to the SLAB module, I can not find any differences in the geometry (.egslst) generated by the two EGSnrc versions (see EGSnrc_v4 .egslt and EGSnrc_v2021 .egslst.
I will try splitting the FLATFILT in half and run the simulations again to see if I can identifiy a single layer which is responsible for this.
@agsponer-metas thank you for the detailed investigation, this proves extremely valuable to track down this issue. I will first diff through your .egslst
files; some default values for the transport parameters have changed over the years.
@ftessier Any updates on this?
No yet from my end.
@ftessier and @agsponer-metas: I've only had time to follow this from a distance up til now, but should have time to look at it in more detail this week! Just off the bat, I can't think of any changes to SLABS that would explain the (lack of) insertion of the 0.01 cm airgap between EGSnrc V4 and the 2021 release. In fact, I can't think of any substantive changes to that piece of coding at all since it was first released in 1995! Perhaps BEAMnrc has been changed somehow, but, even there, I can't think of one that was introduced that would be relevant to this issue. In any case, I'll take a closer look this week...
@blakewalters Any updates on this?
No, @agsponer-metas: I haven't yet installed the EGSnrc_V4 (or equivalent) on my system to see why the slab seems to be placed at the wrong position.
Any updates on this in the new year? Please let me know if I can help you with any additional information.
@agsponer-metas, I'm unable to reproduce this on the oldest release available on the EGSnrc wiki (EGSnrc 2015), so I'll track down EGSnrcV4, install on another machine, and see if I can reproduce it there. Stay tuned, then.
@ftessier, I was able to find a dropbox link you'd made to EGSnrcV4 with self-extracting installers, but do you know where I might find the standalone tarred/compressed directories for this distribution together with an installation script? I'd like to try installing on Mac, and, as I remember, this was the only way to do it.
Hi @agsponer-metas: I ran your cool_cap_test with EGSnrcV4 and still wasn't able to reproduce the missing airgap above the slab. I ran with BEAMnrc rev 1.78 (same as you) and EGSnrc rev 1.16. Although the EGSnrc rev is possibly not the same as yours, I'm not concerned because the geometry should all be taken care of in BEAMnrc in any case.
Can you send me any .egslog files from your EGSnrcV4 runs? Also, if you could zip up the contents of the $HEN_HOUSE/omega/beamnrc directory (including subdirectories) and somehow attach it, that would be helpful as well.
Hi @blakewalters Thanks for looking into the issue, I have attached the simulation files of a fresh run (BEAM_cool_cap_test.zip) as well as the beamnrc directory (beamnrc.zip).
Hi @agsponer-metas: Thanks for sending the files! They certainly helped sort out what I think is the source of the discrepancy between old and new results: In some of the CMs, SLABS among them, the Z-distance between the start of the CM geometry (i.e. Z-position of the first slab) and the end of the previous CM is tested against a minimum air gap thickness, $MIN_GAP. If this distance is found to be < $MIN_GAP, then the Z-position of the first slab is moved up to coincide with the end of the previous CM. So, you eliminate the air gap AND make that first slab (the only slab in your cool_cap_test case) thicker by $MIN_GAP. Now, $MIN_GAP is a macro defined in $OMEGA_HOME/beamnrc/beamnrc_user_macros.mortran and has been set to 0.01 cm since 2006 or earlier. The difference is that, at a more recent point in EGStory, we moved from single precision to double precision variables, including for those defining CM geometries. As a result, in EGSnrc from 2004-2006, roundoff error results in (Z of first slab) - (Z of back of previous CM) being < $MIN_GAP, while in the current version of the system this does not happen.
In summary, then, in the current version of the system, this Z-distance test is less likely (i.e. likely will never) fail, the geometry simulated is identical to that input and results are more accurate. Just to make sure that test never fails, though, I would suggest going into $OMEGA_HOME/beamnrc/beamnrc_user_macros.mortran and setting $MIN_GAP to a smaller number, say 1e-5, so this no longer becomes a concern.
I'm also going to suggest that we set $MIN_GAP to 1e-5 in the distribution. Given that we're using double precision now, there's no point in potentially introducing unnecessary inaccuracies by not modeling the actual Z-dimension of the first layer in a CM!
Discussed in https://github.com/nrc-cnrc/EGSnrc/discussions/772