Wrong muon sorting in scdaq "production" branch
In the branch used at P5, namely https://gitlab.cern.ch/scouting-demonstrator/scdaq/-/tree/dinyar-reduce_eor_writing_wait_time/, there is an unexpected feature introduced that is breaking the muon sorting (which by rule is done with the criterium hwPt + 4*quality
).
For muons, we now split the BX data in two instances of the same data structure, as done in
- https://gitlab.cern.ch/scouting-demonstrator/scdaq/-/blob/dinyar-reduce_eor_writing_wait_time/src/muon_orbit_processor.cc?ref_type=heads#L22
- https://gitlab.cern.ch/scouting-demonstrator/scdaq/-/blob/dinyar-reduce_eor_writing_wait_time/src/muon_orbit_processor.cc?ref_type=heads#L52-53
Given the muon ordering as in the ugt specification
the result is that we put MU0, MU2, MU4, MU6 in the first bx data instance, and MU1, MU3, MU5, MU7 in the second bx data instance. Then we write on file the muons from the first instance and after the muons from the second instance. The outcome is that the sorting of the muons is broken, since the order on the scouting raw files is
MU0, MU2, MU4, MU6, MU1, MU3, MU5, MU7
Obvious solution: use only a BX data instance.