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:
- By running the macro
reco_fairroot.C
. - 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.
Merge request reports
Activity
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.
-
dd47bc4b...b625f7f9 - 39 commits from branch
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.
-
d38b8b3c...49a1967f - 33 commits from branch
@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.@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 toCbmTaskUnpack
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
- move the two new parameters to the end of the initialization list
- set them to default values
""
and0
- check when entering the conditional block at line 128 for the slip that the two parameters were provided with non-default value
- (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
Edited by Pierre-Alain Loizeau