Draft: Rich: Deterministic pixel addresses, introduce CbmRichAddress

Context:
For the RICH CFV we decided to mask channels in the digitization step providing a masking file,
since the cameras are out of acceptance and the extra material is negligible for downstream detectors.
For more details see #3471

As mentioned by @f.uhlig in #2898, the current version uses
a simple counter for channel addresses and pmt Ids.
This may not be deterministic across different fairsoft versions, operating systems, compilers, etc.
-> A channel masking file may fail here

This MR:
Now the channel addresses and pmt Ids are derived from node paths (only supports v22-v24 for now),
instead of an unsafe counter. This is deterministic and allows to safely use a channel masking file.

Changes

• Refactoring/cleanup of CbmRichDigiMapManger
• Rename of CbmRichDigiMapManger -> CbmRichGeoHandler
• Introduction of CbmRichAddress (similar to STS & FSD implementation)
• In CbmRichGeoHandler mapping from RICH pmt pixel node paths to RichAddress (deterministic)
• Remove obsolete class CbmRichMCbmDigiMapManager

TODO's

• More testing
• Add support for v25, as node structure changed
• Should older geometry versions (<v22) still be supported, as they have a different nodePath structure (address counter as fallback?)
  -> Using for now old counter implementation for versions < v22

added Geometry label

@f.uhlig Since addresses have changed, this breaks compatibility with transport/digi files for CBM RICH created before this MR. Forced rerun of tra/digi files is required yet again.

@ma.beyer,

is there an easy way to detect such old files to stop execution with a warning when using an old file?

I currently don't see a reasonable way to do it

In which data classes is the address used?

In CbmRichPoint, CbmRichDigi and CbmRichHit

changed the description

changed the description

added 1 commit

• cd3be0d2 - fallback for channel address and pmt id using previous counter implementation...

Compare with previous version

changed the description

marked the checklist item *Should older geometry versions (<v22) still be supported, as they have a different nodePath structure (address counter as fallback?)* as completed

Dear @f.uhlig, @v.friese, @p.-a.loizeau, @ma.beyer, @se.gorbunov,

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 @f.uhlig

For the mRICH the software channel addresses are directly derived from the geometry paths (addresses are encoded there) and identical with the hardware addresses
(which follow some scheme, but definitely not the same as CbmRichAddress).
CbmRichAddress is not used/needed.

@v.friese May I ask how it is done for mSTS?

• Do hardware addresses follow the CbmStsAddress scheme?
• Do software addresses match hardware addresses? (or is there a mapping?)

Is there a common way how subsystems should do it, looking towards CBM?

Since the RICH will use a masking file in the digitization step (not sure if only RICH does it this way),
it needs to be loaded somehow (manually or automatically).

@v.friese Is there a decision yet how this is done,
e.g. if the CFV setup is used (lets say sis100_electron_cfv), this is checked in the digitization step and masking files are automatically loaded.

Users having to manually load the masking files might lead to oversights/confusion.

I would have loved to have this solution throughout, but it seems some detector needs distinct geometries for the CFV. An automatism for loading the correct digitization parameters depending on the setup is not yet foreseen, but it is a good suggestion, I think.

added 15 commits

• cd3be0d2...3b849a44 - 12 commits from branch computing:master
• 195150d2 - Implementation of CbmRichAddress, cleanup and rename of CbmRichDigiMapManager...
• 5d142b2f - fallback for channel address and pmt id using previous counter implementation...
• 718819b1 - write out institute in copyright header

Compare with previous version

mentioned in merge request CbmSoft/cbmroot_parameter!212 (closed)

changed title from Draft: Rich: Deterministic pixel addresses (CFV requirement), introduce CbmRichAddress to Draft: Rich: Deterministic pixel addresses, introduce CbmRichAddress

changed the description