MCH: introduce digit modifier in filtering workflow

[aferrero2707]

The digit modifier allows to change the contents of the digits in the filtering step.

It is introduced in order to correct some mapping issues in the CTFs already collected, but the interface is general, and in the future it might be used for any kind of digit manipulation, if needed.

The code also introduces pad remapping functions for some regions of ST1 and ST2 quadrants, where the mapping used until the 2024 data taking was wrong. The digits modifier uses the ST1 and ST2 remapping functions in order to fix the mapping of the already existing CTFs.

The ST1 and ST2 mappings are fixed by #13996 and #13938.

More details can be found in https://its.cern.ch/jira/browse/MCH-4 and https://its.cern.ch/jira/browse/MCH-5.

[github-actions]

REQUEST FOR PRODUCTION RELEASES:
To request your PR to be included in production software, please add the corresponding labels called "async-" to your PR. Add the labels directly (if you have the permissions) or add a comment of the form (note that labels are separated by a ",")

+async-label <label1>, <label2>, !<label3> ...

This will add <label1> and <label2> and removes <label3>.

The following labels are available
async-2023-pbpb-apass4
async-2023-pp-apass4
async-2024-pp-apass1
async-2022-pp-apass7
async-2024-pp-cpass0
async-2024-PbPb-apass1
async-2024-ppRef-apass1

[aferrero2707]

@pillot @lmassacr those are the fixes to the ST2 mapping that were discussed recently. As for #13921, we need to look closely to the implications for the reading of CCDB calibration objects - like the BadChannels.

[pillot]

Thanks @aferrero2707 . Appart from details of implementation, I am also wondering here about the connexion between the digit padId and the BadChannels (and the statusMap in general) and how this is affected by this bug in the mapping and the fix.

[aferrero2707]

@pillot I updated the code with all the changes we discussed, could you please have a final look?
The corresponding fix to the mapping is also ready, see #13938

[alibuild]

Error while checking build/O2/fullCI_slc9 for e51f1d3 at 2025-02-05 13:05:

## sw/BUILD/O2Physics-latest/log
Error in cling::AutoLoadingVisitor::InsertIntoAutoLoadingState:
Error in cling::AutoLoadingVisitor::InsertIntoAutoLoadingState:
Error in cling::AutoLoadingVisitor::InsertIntoAutoLoadingState:
Error in cling::AutoLoadingVisitor::InsertIntoAutoLoadingState:
Error in cling::AutoLoadingVisitor::InsertIntoAutoLoadingState:
Error in cling::AutoLoadingVisitor::InsertIntoAutoLoadingState:
Error in cling::AutoLoadingVisitor::InsertIntoAutoLoadingState:
Error in cling::AutoLoadingVisitor::InsertIntoAutoLoadingState:
Error in cling::AutoLoadingVisitor::InsertIntoAutoLoadingState:
Error in cling::AutoLoadingVisitor::InsertIntoAutoLoadingState:
Error in cling::AutoLoadingVisitor::InsertIntoAutoLoadingState:
Error in cling::AutoLoadingVisitor::InsertIntoAutoLoadingState:


## sw/BUILD/O2-full-system-test-latest/log
Detected critical problem in logfile reco_NOGPU.log
reco_NOGPU.log:[27395:internal-dpl-ccdb-backend]: [13:05:11][ERROR] Exception while running: Fatal error. Rethrowing.
reco_NOGPU.log-[27395:internal-dpl-ccdb-backend]: [13:05:11][FATAL] Unhandled o2::framework::runtime_error reached the top of main of o2-itsmft-stf-decoder-workflow, device shutting down. Reason: Fatal error
[27395:internal-dpl-ccdb-backend]: [13:05:11][ERROR] CCDBDownloader CURL transfer error - Unsupported protocol
[27395:internal-dpl-ccdb-backend]: [13:05:11][ERROR] CcdbDownloader finished transfer http://alice-ccdb.cern.ch/GLO/Param/MatLUT/1546300800000/3f0d0f81-99d9-11ee-b9a2-200114580202 for 1550600800000 (agent_id: alimetal01.cern.ch-1738757103-JLT3TZ) with http code: 0
[27395:internal-dpl-ccdb-backend]: [13:05:11][FATAL] Unable to find object GLO/Param/MatLUT/1550600800000
[27395:internal-dpl-ccdb-backend]: [13:05:11][ERROR] Exception while running: Fatal error. Rethrowing.
[27395:internal-dpl-ccdb-backend]: [13:05:11][FATAL] Unhandled o2::framework::runtime_error reached the top of main of o2-itsmft-stf-decoder-workflow, device shutting down. Reason: Fatal error
[ERROR] Workflow crashed - PID 27395 (internal-dpl-ccdb-backend) did not exit correctly however it's not clear why. Exit code forced to 128.
[ERROR]  - Device internal-dpl-ccdb-backend: pid 27395 (exit 128)
[INFO]    - First error: [13:05:11][FATAL] Unable to find object GLO/Param/MatLUT/1550600800000
[ERROR] SEVERE: Device internal-dpl-ccdb-backend (27395) had at least one message above severity 5: Unable to find object GLO/Param/MatLUT/1550600800000


## sw/BUILD/o2checkcode-latest/log
--
========== List of errors found ==========
++ GRERR=0
++ grep ' error:'
++ grep -v clang-diagnostic-error error-log.txt
++ GRERR=1
++ [[ 1 == 0 ]]
++ mkdir -p /sw/INSTALLROOT/3d5937117926b92747c1c62e81d4f3672e6afcb2/slc9_x86-64/o2checkcode/1.0-local285/etc/modulefiles
++ cat
--

Full log here.

[aferrero2707]

@pillot I have added the remapping for ST1, and refactored the code to better check if a given pad is a candidate for remapping, to minimize the number of accesses to the unordered_maps.

[pillot]

Hi @aferrero2707 , thanks for the new fixes! Looks fine to me.

[aferrero2707]

+async-label async-2024-PbPb-apass2 async-2023-PbPb-apass5

Labels updated; please review again.

[github-actions]

Hi @aferrero2707, the following label names could not be recognised: async-2024-PbPb-apass2 async-2023-PbPb-apass5

[pillot]

@aferrero2707 , should I squash the commits or let them separated ?

[aferrero2707]

@aferrero2707 , should I squash the commits or let them separated ?

The can be squashed, it was mainly intended to simplify the review.