Skip to content

TOF and T0 unpackers in algo namespace.

Dominik Smith requested to merge d.smith/cbmroot:AlgoUnpackersTofT0 into master

Starting from the latest version of CbmTofUnpackAlgo from the mCBM fork maintained by @n.herrmann a new TOF unpacker in the algo namespace was created. The T0 unpacking was extracted from the class and implemented as a stand-alone T0 unpacker. Both unpackers were added to reco/tasks/CbmTaskUnpack and the CMakeLists files were updated accordingly.

Currently the parameters of the new unpackers are hardcoded. The values are taken from macro/beamtime/mcbm2022/mTofCriParNickel.par and macro/beamtime/mcbm2022/mBmonCriPar.par, in combination with cbmroot/core/detectors/tof/CbmMcbm2018TofPar, which is appropriate for the 2391 run. The class CbmMcbm2018TofPar also forms the basis for the newly implemented "readout config" classes of T0 and TOF.

In CbmMcbm2018TofPar.h, there is a mistake in the following line:

static const uint32_t kuNbGbtxPerGdpb = 6;

This should be "= 2". The value was only used for out-of-bounds checks in the old class and probably didn't cause any serious problems. The value is needed here and was corrected.

The new classes were tested on 2391 by unpacking a single timeslice (the second one in 2391_node8_0_0008.tsa since the old unpacker produces address errors for the first one in that file) and reproduce the number of digis and histograms for timestamp, address and charge.

The following filters are applied in the old unpacker by default, but are not in the new class (they were deactivated for the test):

  • Duplicate messages
  • (0 == uChanUId)
  • (fviRpcChUId.size() < uRemappedChannelNrInSys)
  • successive digis with same time

The "EpochCountHack2021" of the old class was switched off for the test and is not supported by the new classes. The recent "remap digi" hack is currently included in UnpackTof::ProcessHitMessage to make the comparison possible, but should be removed before merging.

The new class also always includes timeslice overlap.

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

Also involves I.Deppner.

On edit: The original class tracks whether epoch messages arrive in order. This check is not done here. If this feature is desired it should be fairly easy to implement.

Edited by Dominik Smith

Merge request reports