The configuration of event building is re-worked with the following guiding principles:
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.
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.
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.
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.
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.
#2921Volker Friese authored