Rework event building configuration. Refs #2921

The configuration of event building is re-worked with the following guiding principles:

1. Event building is one (optional) part of the online data processing. It consists of digi trigger, the actual event building (construction of events), and digi event selector. The configuration is organised in a modular way, with separate configuration classes for each of these steps. YAML allows to easily integrate that into a single file.

2. Formerly, there was a single configuration class and separate parameter classes for each of the steps, which were initialised from the common configuration class. The parameter classes / structs were replaced by the separate config classes for each step. The common config class is just a container for the algorithm config classes.

3. There are no Init methods any longer. All objects (config and algorithms) initialize their members through the member initialization list of the constructor. There are no default constructors, so no object can be constructed in an uninitialized state. This holds up to the steering class EventbuilderConfig.

4. The config classes do not expose their members publicly. This may be somewhat overcautious, but since the results of the online processing intimately depend on these settings, I felt that some more control / safety is in place.

5. I introduced a sub-namespace cbm::algo::evbuild for all related classes. They shall be moved to a common folder in a separate MR, thus cleaning up the top-level directory structure in algo.

The MR grew somewhat larger than I expected. However, half of the changes are follow-ups in the offline integration (reco/tasks). The tasks there will be replaced in a follow-up MR by a single task wrapping EventbuildChain. I kept the current functionality meanwhile for testing purposes. I did not update the devices in reco/mq in the same way and took it out of compilation for the time being.

changed milestone to %OCT23

added Online Reconstruction labels

requested review from @j.decuveland

assigned to @fweig

added 1 commit

• ad4c190f - Fix format issues (EOL) for yaml file

Compare with previous version

changed the description

added 1 commit

• a8fba485 - Next try for yaml file ending

Compare with previous version

added 1 commit

• 5ce4aa68 - Next try for yaml file ending

Compare with previous version

added 1 commit

• 8ccbf4d6 - Fix problem with macro/reco/reco_fairroot.C

Compare with previous version

added 6 commits

• bc60ac74 - 1 commit from branch computing:master
• cfa38758 - Rework event building configuration. Refs #2921
• 37386577 - Fix format issues (EOL) for yaml file
• b6f0a40c - Next try for yaml file ending
• 688f2b91 - Next try for yaml file ending
• 8ac10ce9 - Fix problem with macro/reco/reco_fairroot.C

Compare with previous version

Dear @f.uhlig, @v.friese, @p.-a.loizeau,

you have been identified as code owner of at least one file which was changed with this merge request.

Please check the changes and approve them or request changes.

added CodeOwners label

Looks very good to me!

Still, a few notes, as always.

I noticed that the output using the various ToString methods as it currently is seem designed with the idea of an uninterrupted multi-line text stream in mind. When running in parallel, this individual stream can often be recreated with some effort, but it is not the default view to the logs.

I have found that it is often easier to understand what is going on if individual log lines require as little context as possible. For example, a single line reading ""--- Using DigiEventQa with parameters:"" carries little information when viewed in a stream of messages from various sources.

This may not always be easy to implement, and may not even be desired in some cases (e.g., trace-level output). I just wanted to mention this topic as I feel we should try to at least slowly move in this direction with new code.

added 8 commits

• 8ac10ce9...c8c95f47 - 2 commits from branch computing:master
• 58c3e25d - Rework event building configuration. Refs #2921
• 302cab80 - Fix format issues (EOL) for yaml file
• 569d283a - Next try for yaml file ending
• c201ba9d - Next try for yaml file ending
• 9b0a720a - Fix problem with macro/reco/reco_fairroot.C
• ff142b13 - Changes following code review by JdC.

Compare with previous version

resolved all threads

approved this merge request

@fweig Could you have a look and merge if you are ok with the changes?

Changes seem fine for me. I didn't have an in-depth look. I assume, Jan has already done that. :-)

Only have a small question above. And a small request: Could you squash the three YAML-file fixes commits (302cab80 - c201ba9d) into 58c3e25d, @v.friese? I think we should avoid those in the master.

Otherwise looks good to merge.

Yes, all commits can be squashed into a single commit. This is already set in the MR properties, I think.

resolved all threads

added 16 commits

• ff142b13...f238aef3 - 10 commits from branch computing:master
• 04334079 - Rework event building configuration. Refs #2921
• 30c5041a - Fix format issues (EOL) for yaml file
• 5e5eed15 - Next try for yaml file ending
• 6cf8760c - Next try for yaml file ending
• 28e99ce4 - Fix problem with macro/reco/reco_fairroot.C
• bba3d310 - Changes following code review by JdC.

Compare with previous version

enabled an automatic merge when the pipeline for bba3d310 succeeds

merged