add treatment of TOF DRM Errors

[noferini]

No description provided.

[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
async-2024-PbPb-apass2
async-2023-PbPb-apass5

[noferini]

PR ready for the review.

It adds the possibility to filter digits if a DRM error is generated (new ccdb object DRMerrors)

For the moment only default entry with no error is available in the ccdb but I tested it with a local object (red = difference between ideal - realistic)

[noferini]

+async-label 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, async-2024-PbPb-apass2, async-2023-PbPb-apass5

[noferini]

Dear @shahor02 ,
I restared the tests since I needed to fix a trivial bug I discovered in previous implementation.
The behaviour is now validated.
This is an example of what I got for the worst run we collected so far
Left: no DRM masking vs DRM masking in digitization (sector = channel/8736)
Right: DRM error (reported by sector) probability (mask in ccdb object)

[shahor02]

Hi @noferini , just for my education, what is the effect of this on the reconstruction? The elimination of clusters which should not be there?

[noferini]

Hi @shahor02 ,
with this PR we are not touching reconstruction, as it only acts on the digitization step.

The assumption is that there are errors affecting the DRM that cause the loss of clusters with correct time information.
This implementation was triggered by a few runs (currently marked as bad) whose matching efficiency is significantly lower than expected, and we observed a strong correlation with orbit mismatch errors. This convinced us that when a DRM orbit mismatch error occurs, all hits on that DRM become unusable for matching (the time orbit is wrong). There are 12 kinds of DRM errors, but for now we only consider the orbit mismatch as critical (i.e., to be masked in MC) until we have further evidence.

The frequency of such problems is very low.
Here the frequency of such an error over all runs.

My idea is to upload CCDB objects only for the few runs where the error probability is non-negligible, and check whether agreement with MC is recovered. If so, we could mark some currently BAD runs as GOOD.

[noferini]

This is the plot which triggered the problem (run 568500 is the one with 26% of orbit mismatch)

[shahor02]

Thanks for clarifications!

[alibuild]

Error while checking build/O2/fullCI_slc9 for 2ad8beb at 2026-03-04 16:50:

No log files found

Full log here.