Updated CbmReco and dependent classes.

The task CbmReco carries out unpacking and subsequently triggering, event-building and event-selection. There are two different ways in which this task can be run:

1. By running the macro reco_fairroot.C.
2. By running the compiled binary cbmreco_fairrun.

This mode of running the read-out chain has not been in use for some time, and hence the corresponding code did not account for most recent developments in cbm::algo, most importantly the yaml-based configuration of the unpackers and the automated selection of the proper parameter files by using the ParFiles class. This is addressed in the present MR.

This MR builds upon !1873 (merged), to restore the functionality of CbmReco and update it such that it accounts for the new interface of CbmTaskUnpack. It is now possible to set the directory containing the online parameters, and a run ID by which the proper parameter set is selected, from the constructor of CbmReco. The macro reco_fairroot.C has been updated to support this. Likewise, the compiled binary cbmreco_fairrun has received two new program options, by which the parameter directory and run ID can be passed.

Both types of execution were tested and seem to reproduce the results of the online binary used in the data challenges and during the beam times.

@p.-a.loizeau @f.uhlig @fweig @j.decuveland @n.herrmann

requested review from @v.friese

assigned to @v.friese

mentioned in merge request !1874 (merged)

added 41 commits

• dd47bc4b...b625f7f9 - 39 commits from branch computing:master
• 70eb965c - Updated CbmTaskUnpack to reflect the current state of the online binary.
• d38b8b3c - Updated CbmReco, reco_fairroot.C and cbmreco_fairrun to account for new interface of CbmTaskUnpack.

Compare with previous version

Sorry if you got a "failed pipeline notification": I rebased before realizing that this one needs first to be re-synchronized with the latest changes of !1873 (merged) and that we therefore have first to fix the problem in the other MR

added Reconstruction label

added 34 commits

• d38b8b3c...49a1967f - 33 commits from branch computing:master
• e8387d13 - Updated CbmReco, reco_fairroot.C and cbmreco_fairrun to account for new interface of CbmTaskUnpack.

Compare with previous version

@d.smith I think you will now need to update the test reco_reco_<setup> at line 150 of the CMakeList in the corresponding macro folder, so that it also provide the two new macro parameters.

See also there for an example of the CI test crash

@p.-a.loizeau I'm not sure what to do here. Beneath the surface-level problem of the changed interface lies the conceptual problem that this test chain assumes the usual sequence of "simulation -> digitization -> reconstruction". This is fundamentally incompatible with the idea of choosing parameters based on a runID, which isn't defined for simulations.

Before !1873 (merged) was merged, CbmTaskUnpack contained a set of hard-coded paths to some parameter files (a mix of yaml and FairRoot ones). These were the correct ones for some mCBM setup from 2022 I believe. The test however loops through a list of setups. So while it ran up until now without throwing an error, the output of the test was likely garbage in most cases.

It would be easy to restore the original (non-) functionality of the test that existed prior to this MR: Just hard-code the parameter path to cbmroot/parameters/online/ and set some arbitrary runID (probably 2391 or 1588). Not sure what is gained by this though.

What we would need, is a one-to-one map between setup tags and runIDs. I don't think we have that.

Huum, looking at the beginning of CbmReco::Run, I think the trick here is that the test is valid because the input is a ROOT file, in which case the call to CbmTaskUnpack is skipped (lines 90 for the detection and 128 for the skip), avoiding the problem with the hard-coded parameters (as they are simply not used).

So maybe here the solution would be to

1. move the two new parameters to the end of the initialization list
2. set them to default values "" and 0
3. check when entering the conditional block at line 128 for the slip that the two parameters were provided with non-default value
4. (not 100% sure but strong suspicion on my side) add a call to the new SetOutputModeCbmrootLike flag setter to have an output of the unpack step matching the standard CbmRoot branches

This way we could avoid breaking the existing test chain for the "simulation only" while preserving a meaningful execution if used with some tsa files

@v.friese is probably the one who has to decide has he knows best the original intent of this class