New TOF hitfinder class HitFinderTof in Algo namespace and corresponding CbmTaskTofHitFinder.
New classes HitFinderTof and CbmTaskTofHitFinder were implemented, based on CbmTofSimpClusterizer.
The class HitFinderTof exists in the algo namespace and is ROOT-free, other than using the ROOT::Math classes Rotation3D and XYZVector.
In accordance with the conventions of the algo namespace, to support future parallelization, the task is structured such that one HitFinderTof object is created for the smallest possible self-contained unit, which here is one RPC. Each of these objects is supplied with its own parameters struct. Per-channel parameters are stored therein, in a std::vector of channel parameter structs.
Also inline with the algo conventions, support for monitoring histograms has been dropped, and out-of-bounds checks were removed in multiple places. The earliest geometry version which is supported is now v14a. Previously, the earlier geometry v12b was also supported. This was dropped, as it required a bugfix for wrong channel IDs to be included in the hit finder.
The channel calibration parameters "offset", "gain" and "walk" are currently set to default values. In the old class CbmTofSimpClusterizer they could also be read from a file containing ROOT histograms. This is not supported here. Probably we will use a config class for this. Until we have such a class, the reading of other (RPC) parameters is still done in the same way as in the old class, by reading from CbmTofDigiBdfPar and CbmTofDigiPar.
The new class has been tested. The output of the old class is reproduced.
Side remark:
A feature of ROOT::Math::XYZVector was discovered: It implements the "/=scalar" operation as "*=(1./scalar)", which can lead to an unexpected rounding behavior, whereby "/=" and "*=" are not inverse operations. This can cause a subtle problem in statements such as the following:
vector/=scalar;
floor(scalar * vector.X());If the vector.X() is equal to an integer before applying the division, the floor operation can end up rounding to the next smaller one, which is non-intuitive.
One example of this exists in the code, and is described in a comment. We circumvent this problem by using element-wise divisions instead.