Beam Model from INI file, potential structure

Some users may want to avoid having to code their beam models in C++ and recompile the software. One solution would be to implement a 'generic beam model' that allows the specification of settings via one or several INI file, and that defaults back to some standard values if this INI file is not provided. This would easen implementation for newbies. It would also solve the problem with 'private beam models' that force now the use of a private repository and a public repository.

For example a beammodel.ini:

(JSON format could also be a nice option)

[EnergyCorrection]
100 100.5
105 105. 5
100 110.7
230 230.4

[EnergySpread]
100 1.4
105 1.5
...

[FluenceCorrection]
100 1.03
105
...

[SigmaXY] --> although this could be instead read from the RTplan
100 10.1 11.3
105 12.3 12.9
...

[SAD] --> although this could be instead read from the RTplan
x=1940
y=2340

[RangeShifters]
RS_80mm = 80 Lucite
RS_45mm = 45 Lucite
NoRS = 0 None

[MU2NP] --> If RTPlan PrimaryDosimeterUnit is in MU, perform this energy dependent conversion to number of particles
100 0.1
105 0.4
230 0.9

and a separate materialmodel.ini

[HU2RSPR]
-1000 0.8
0 1.0
1000 0.9

[HU2MassDensity]
-1000 0.001
0 1.0
1000 2.0
...

[HU2ElectronDensity]
-1000 0.001
0 1.0
1000 2.0
...

[HU2Composition]
-1000 0.001
0 1.0
1000 2.0

[HU2Material]
-1000 0
-900 1
-600 2
...

[Material2ElementalComposition]
0 0.15 0.22 0.8
1 ...
2 ...

[StoppingPowerModel_Material1] --> Optional, dependence of SPR on energy
100 0.98
105 0.99
110 1.00
230 1.01

See e.g. https://github.com/benhoyt/inih https://tuttlem.github.io/2012/12/26/a-simple-c-ini-file-reader.html https://stackoverflow.com/questions/6175502/how-to-parse-ini-file-with-boost

Potential benefits of this approach:

Not forcing user to recompile software / TOPAS extensions if he is tuning fluence correction parameters (iterations can be done quicker with the 'generic' machine). Once the final parameters are found, he can write them in a dedicated hpp as a 'custom' released machine if needed. This would also be a more gentle learning curve, where I only need to learn how to compile and make classes at the very end.
Not having problems with mixing private beam models in the public repo. The model is in a separate folder which is not committed, and the folder name is passed as argument when running the program / script.

Drawbacks:

less secure and fast than C++ direct compilation

topasmc / dicom-interface

Beam Model from INI file, potential structure #10