Unification of address handling in MVD data-classes: Iteration 1

Introduction

This is the first part of the merge-request, which brings MVD data classes in consistency with other detectors.

TODO list for this iteration:

• Modify the detectorID bit-field definition in the CbmMvdDetectorId class
• Give an address (legacy definition) to the MVD hit
• Replace different access to MVD tracking stationID from hits and MC-points with a common look-up map in the tracking interface class
• Remove the CbmMvdDetectorId and replace it with the MVD-address (legacy definition).

What is wrong with the data classes?

Current addressing scheme with CbmMvdDetectorId class

1. Most of the MVD data-objects (CbmMvdHit, CbmMvdPoint, CbmMvdDigi) carry a 32-bit integral field fDetectorID, which defines a hardware place of their origin. The bit-fields stored in fDetectorID are defined with CbmMvdModuleId class as follows:

1. bits 1-4 (5): SystemId, which stores the ECbmModuleId::kMvd value
2. bits 5-31 (27): StationNr, which stores either a global index of the MVD sensor (CbmMvdPoint, CbmMvdDigi), or an index of MVD station (CbmMvdHit).

2. The size of the SystemId bit-field (5 bits) does not fit into the convention, used to define a hardware address for other detector subsystems in CBM (4 bits). Moreover, it differs from the one, defined in the newly introduced class for MVD address (CbmMvdAddress), which will cause mistakes in the reading digis of a new type (CbmMvdRawDigi) from the cbmreco output within the vertical tests.

3. Different interpretation of the CbmMvdDetectorId::StationNr() (to store either a sensor, or a station index) brings potential misuses of this information.

MVD hit addressing

The MVD hits does not store a hardware address (the corresponding field in the base class is explicitly 0). Instead, it stores a detectorId with a station index stored to the 5-31 bits (see previous section). This invalidates the calls of CbmMvdHit::GetAddress() function.

MVD address: version 1 (new) and version 07/2025 (legacy)

A current implementation of the CbmMvdAddress class provides two ways of the MVD sensor address decoding. For both ways, the information on the sensor is encoded in a 9-bit field (bits 4-12).

In simulation the "07/2025" legacy version is used, where this field contains a global index of the MVD sensor. The global index is retrieved from geometry as a counter in nested loops over geo-nodes.

In the new version of the address definition is used in the online MVD unpacker, and it decodes the sensor as following:

Level           Bits  Max. Elements  Bit Position

Station           2         4           4 -  5  // for station id
SideUD            1         2           6       // for upstream/downstream
SideLR            1         2           7       // for left right
SideTB            1         2           8       // for top bottom
Ladder            2         4           9 - 10  // Ladder no
Sensor            2         4          11 - 12  // sensor id

This version fits well in the online/offline reconstruction algorithms and parameter estimation software (e.g., BBA, track fitting), since it provides a direct and uniform access to the tracking station index without a necessity to introduce extra mapping of a tracking stationID.

Possible solutions to get the version 1 into MVD simulation and legacy reconstruction code

There are two ways of replacing the legacy address definition with the new one.

1. Quick hack: to provide a look-up table globalID->(Station, SideUD, SideLR, SideTB, Ladder, Sensor) in the CbmMvdGeoHandler class for each particular geometry. The main problem of this solution is, that it requires an extra parameter file, which defines the table and should be maintained manually.
2. Proper solution: to rename the paths to the geo-nodes of the MVD sensor in such a way, so the (Station, SideUD, SideLR, SideTB, Ladder, Sensor) indices could be extracted directly with a help of a regular expression. The process of creation and testing the new geometries can take a time.

Since the replacement of the legacy addressing scheme with the new one requires a decision on the way to provide the globalID->(Station, SideUD, SideLr, SideTB, Ladder, Sensor) mapping (either with a parameter file, or with the geometry), the work on it is a subject of the Iteration 2.

Of interest to

@ajit.kumar, @e.clerkin, @p.-a.loizeau, @f.uhlig, @f.kornas, @a.senger, @se.gorbunov, @bartosz.sobol

Bugs fixed

1. Fixed inconsistent bit-field size for storing the subsystem Id in CbmMvdDetectorId class (now the class is fully replaced with the CbmMvdAddress)
2. Fixed boundary conditions in CbmMvdSensorDigitizerTask and CbmMvdSensorDigitizerTBTask for creating a pixel charge object: the MC points on the border of the active surface were producing digis in pixels, which physically do not exist.