Cleanup of CbmTofUnpackAlgo.

Refactored and cleaned up CbmTofUnpackAlgo.

@p.-a.loizeau @f.uhlig

Some global fields were removed, some functions broken up into smaller units, some unneeded lines deleted, Root types removed etc. The changes introduced here make the code subjectively more readable. I leave it up to the experts whether to merge this or not. This is preliminary work for the implementation of a Tof unpacker in the Algo namespace and was mainly done to make this task simpler.

So far, the changed class has not been tested.

There are some compiler warnings about integer types:

/home/dsmith/cbmroot/reco/detectors/tof/unpack/CbmTofUnpackAlgo.cxx:410:43: warning: format ‘%llx’ expects argument of type ‘long long unsigned int’, but argument 2 has type ‘uint64_t’ {aka ‘long unsigned int’} [-Wformat=]
  410 |                << Form("Raw Epoch: 0x%06llx, Epoch offset 0x%06llx, Epoch in Ts: 0x%07lx, time %f ns (%f * %lu)",
...

@f.uhlig @p.-a.loizeau If we could do with fuCurrDpbIdx instead of fuCurrDpbId here, we could lose another global (class-scope) variable.

I think for the error messages the DPB index has no meaning: it is bound to change depending on the parameter file used (number of DPB declared in the array, order of the ID in array). The user should always be able to relate an error to the physical hardware triggering it.

Dear @n.herrmann, @i.deppner,

you have been identified as code owner of at least one file which was changed with this merge request.

Please check the changes and approve them or request changes.

added CodeOwners label

@d.smith, You didn't choose a reviewer and an assignee to your MR.
Should I assign it to Florian and make Pierre a reviewer? They are both on vacation currently. Do you prefer to wait until they are back, or shall I review and merge the code?

@se.gorbunov I cannot assign MRs to people. But your suggestion is fine: assign to Florian and make Pierre a reviewer. This can wait until after their vacation.

assigned to @f.uhlig

requested review from @p.-a.loizeau

I think the one to review this should be people from the TOF group: I am guilty of the ancestor version and latest changes, but in the future they are the ones who will have to control/maintain/use it.

@p.-a.loizeau I'm not sure that this MR is relevant any longer, at least in its present form. After seeing the changes from the mCBM fork, I realized that this class had deviated quite strongly from the master version. If we want to keep it, some of the recent work would have to be retraced.

Aaah, I missed that it was so much behind the master, my bad

I agree, then it is probably not worth redoing all these changes as you already have a cleaned up version in your "algo + mq, TOF + T0" MR

I think this one is more relevant: !946 (closed)

It can be an actual replacement for the existing class.

Closing for now, can be used as reference latter if such a cleanup is desired by the TOF team

closed