CA: fresh mCBM NiNi parameters

Update of CA parameters for the online reconstruction

Dear @f.uhlig, @p.-a.loizeau, @d.emschermann,

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

assigned to @e.clerkin

assigned to @p.-a.loizeau and unassigned @e.clerkin

requested review from @se.gorbunov

assigned to @e.clerkin and unassigned @p.-a.loizeau

mentioned in merge request computing/cbmroot!1602 (merged)

approved this merge request

merged

Which type of files are this *.par files?

These are binaries created with the boost serializer by this method:

https://git.cbm.gsi.de/computing/cbmroot/-/blob/master/algo/ca/core/pars/CaParameters.h?ref_type=heads#L428

@se.gorbunov Why has a binary format been chosen over ascii? Surely it would be better to be able to have versioning and easier debugging of these files by gitlab. Why does serialization even make sense here?

I don't know, let's ask @s.zharko

Boost serialization is the most robust and the easiest way to handle the CA tracking parameters snapshot as it is. We have also discussed today, that the plain text serialization can be a better solution in terms of the version control, so I am going change it in the next merge request

@e.clerkin @s.zharko @f.uhlig,

the *.par file contains ca::Parameters object ( https://git.cbm.gsi.de/computing/cbmroot/-/blob/master/algo/ca/core/pars/CaParameters.h ) that is dumped as a binary.

This object is a combination of the tracker setup and the CBM setup. Dumping it into the file is only a temporary solution for the online data challenges.

Normally (offline), ca::Parameters are not read from the file but are created in memory during the run initialization.

The object is created by the ca::InitManager (https://git.cbm.gsi.de/computing/cbmroot/-/blob/master/algo/ca/core/pars/CaInitManager.h) out of the CBM setup (active detectors, material maps, magnetic field etc., all these read from the ROOT memory) and out of the tracker configuration (cuts, iterations, active stations etc., all read from the tracker *.yaml configuration file).

Once the CBM geo setup is available for the online chain initialization, we will only store the tracker *.yaml configuration in the parameter repository.