Documentation of Parameter Settings

[mrikasper]

Dear Tobias and Mirco,

it's been a while, but I finally found some time trying out your great toolbox and studying the examples you provide in more depth.

I was wondering about the parameter settings for both reconstruction and simulation, i.e., recoParams and simParams. The meaning of the arguments (subfields) in the parameter dictionaries is well explained in the documentation, but I wonder how to know which values are valid.

For example, for the recoParams in setupIterativeReco, it states

solvername::String - name of the solver to use

but it's not clear which strings would be supported solvers. Is this documented somewhere else? What would be the preferred place to document this?

I understand that I can go through the functions to find out, but maybe I am missing something. Also, if you have a suggestion where and how to put such documentation, I am very happy to contribute what I find helpful.

Thank you very much for your help and for creating such a fine toolbox!

All the best,
Lars

[tknopp]

Hi Lars,

you have quite well found the pros and cons of our parameter handling concept. Let me explain this a little bit the ideas behind this.

In general one has the issue that the reconstruction depends on quite some parameters and the question is, how to handle them all. From a high level perspective it is great to have a very dynamic system, where you are basically just throwing a parameter data structure to the reconstruction and get a reconstructed image back. The question now is:

• do you want a static, well defined structure for the parameters, where the types are stable and the order does not change (e.g. a class / struct)
• do you want a dynamic system where the parameters are stored in a dictionary and one can add a parameter at a very low level, without the need to change the software stack above.
  We have kind of a hybrid of that. Julia allows to combine the two using keyword arguments that can be kept type stable. But on the highest level be take the parameters as a dictionary and then on the lower levels convert to keyword arguments or just use the parameters from the dictionary. One crucial point here is that dictionaries are type unstable and should not be used in "hot loops". They will make the entire code slower.

Now the pro of the dictionary is that one can serialize them into a configuration file, which we currently do not support in MRIReco.jl but we use that concept in a sister project MPIReco.jl, where it works pretty well.

The downside of being so dynamic with the parameters is that they are not really checked and that they are not documented. Both are things that are really just missing in MRIReco.jl and can be added.

So lets keep this issue open as a reminder that we need to fully document the parameter dictionaries.

[alexjaffray]

Augmenting this discussion, the list of solvers is available here:

https://tknopp.github.io/RegularizedLeastSquares.jl/latest/solvers/