Some more infos to add to documentation and for additional developments

[shervin86]

Outcome of the meeting with @JunCEEE

Checking parameters

The syntax that we would like to support is the following:

# declaration of a calculator
mycalculator = FirstCalculator()
# getting default parameters initialized by the calculator
myparams = mycalculator.parameters()
# changing default values
myparams['wavelength']=4.5
# eventually print the list of parameters and their values
print(myparams)

The only checks performed by the parameter class is if the value is withing the allowed ranges.

More complex checks, especially those involving more parameters, should be carried on by the calculator.
The checks cannot be perfomed when setting the value because it would fail in case of correlated parameters.
E.g. check if parA+parB<10, with parB=6 and parA=3
If new values are parA=9 and parB=0, when setting parA = 9 would give an error bacause failing the condition.
So it is better to define a check() method for the calculators with each calculator perfoming all the checks that are required.

• need to enforce all calculators to have a check() method, that returns true by default (not implemented), it can be done in the base class
• specialized implementation of the check() method for specialized calculators needing a particular check to be carried on
• enforce the check() method to be called by the run() method
• suggest in the documentation to place the check() method where it makes sense in the code

Execution parameters

Calculators should have two sets of parameters:

• physics parameters: those related to the physics
• execution parameters: those related on how to run the code (e.g. number of cores, splitting of the output file, path for the output file, logging level)

Both are private members of the calculator class and of type CalculatorParameters.
A specific method to return them should be available:

• mycalc.parameters(): for physics parameters
• mycalc.run_parameters(): for execution parameters
  Naming has not been defined, so feel free to make suggestions.

Detector geometry

This seems to be a tricky part.
Needs:

• be able to load the instrument definition from the instrument database
• be able to dump in simple text format the geometry
  • to have it versioned in the instrument repository
  • to have diff patches be added to the openPMD file in case of changes

One possible solution would be to:

• pass the detector_geometry parameters as a string with the name of file defining the geometry
• ask to add in the first block of comments of the geometry file the name of the specialized class that generated it
• ask to implement a loader function that takes as input the path of the text file with the geometry description and reading the first block of comments instantiates and returns the right specialized geometry class

Originally posted by @shervin86 in #20 (comment)