Frederic Tessier

@rtownson can I work to cleanup this branch, or would you rather I hold off?

This will be merged in `develop` after 2022 release.

Is there an option in the integrated estar code to compute density corrections for a density that is different from the bulk density, e.g., for the grain density in graphite?...

Indeed, I never _completely_ finished the octree geometry (in terms of proper testing and polishing up the input interface for it). I will also look at it to see what...

Agreed. Since this value is [exact in the SI](https://physics.nist.gov/cgi-bin/cuu/Value?e), I would go all the way and define `e = 1.602 176 634 x 10^-19 C`.

Found this in `src/EEMF_macros_beamnrc.mortran`: `REPLACE{$EC_em}WITH{1.60217662E-19}; "electron charge"`. I suggest we simply make such a constant available throughout, along with conversion factors such as `eVToMeV`, `MeVPerGramToGray`, etc., as suggested by @MartinMartinov...

Something like this, in a new header `egs_constants.h`: ``` // Physical constants const EGS_Float e_charge = 1.602176634e-19; // Coulomb, exact, CODATA 2018 // Conversion factors const EGS_Float eV_to_MeV = 1e-6;...

Or at the very least use `snprintf`!

I see only cosmetic changes in the [SLAB component module's history](https://github.com/nrc-cnrc/EGSnrc/commits/master/HEN_HOUSE/omega/beamnrc/CMs/SLABS_cm.mortran) on git, back to 2015. @agsponer-metas if you can run a test with EGSnrc v2016 quickly, that would prove...

@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...