configuration file for parameters

[c-dilks]

Is your feature request related to a problem? Please describe. Hard-coded configurations in src/tools/default_flags_table/reco_flags.py is not sustainable.

Describe the solution you'd like Separate the configuration parameters from the code. One option is yaml, which is easy to read and write, and edit in a text editor.

Colons in parameter names would correspond to nested maps, so

detector:tag1:a=1
detector:tag1:b=2
detector:tag2:z=3

in yaml becomes

detector:
  tag1:
    a: 1
    b: 2
  tag2:
    z: 3

More complex configurations could be used, for example, a table of quantum efficiencies vs. wavelength would be written in yaml as a list of pairs.

A custom parser, based on some C++ or Python yaml library, could handle units, description strings, etc.

---

EDIT:

• Hard-coding configuration parameter settings in EICrecon plugins is also not sustainable, and forces users to re-compile for any changes.
• drich-dev now uses a yaml file parser to generate eicrecon commands, allowing us to use such config files for the dRICH.

[DraTeots]

I believe we will start a discussion in December on how to refactor everything and such thoughts will be very important there.

Also, values like those should be put to calibration and constants database. I think, after this campaign, we will make a decision on what to use and then there will be big rehauling on how to do such configurations and how to store them.

[faustus123]

I'm late commenting on this, but since it was recently referenced in PR #442 ...

I just want to make sure it is clear that JANA already does support a configuration file format. The format is a pretty simple text format, but includes support for comments and arrays of values. It does not directly support equations like "3*GeV" which is what I believe one of the main motivations for using a python reco_flags.py instead.

I would be in favor of supporting an alternative format like yaml. I think it would be pretty easy to do, at least for basic configuration needs. I also like the idea of being able to support units in the configuration file.

We will be having a discussion soon (2 weeks?) on configurations for eicrecon. This will be intimately related with the plan for moving to an explicit, configuration-based piping scheme with algorithms.

[c-dilks]

I sketched out a yaml config file parser and wrote a default config file I would like to use for dRICH work. See https://github.com/eic/drich-dev/pull/65

I only did it in Ruby because I can write it quickly, but the core yaml-tree parsing algorithm could be easily ported to C++ and added as an option to eicrecon.