FT0: update Digitizer signal shape and trigger logic; FV0: update trigger logic in digitizer

[spulawsk]

This PR introduces an updated signal shape model and revised trigger handling in the FT0 digitization.

The signal response used in the FT0 digitizer has been updated to a parametrization based on a sum of two log-normal components. This allows a better description of the detector pulse shape in Monte Carlo simulations and improves the agreement between simulated trigger response and data.

In addition, trigger logic has been adjusted to better reproduce the behaviour of the FT0 trigger chain.

Main changes

Signal model:

introduce a new signal shape function based on two log-normal components
provide analytical integral of the signal shape for amplitude evaluation
keep the previous implementation commented for reference

Trigger tuning:

update trigger thresholds in FT0DigParam (mtrg_central_trh, mtrg_semicentral_trh)
introduce a dedicated vertex trigger gate parameter (mTime_trg_vertex_gate)

Digitizer improvements:

introduce mapping from channel ID to PM hash using FT0 metadata
accumulate charge per PM using the mapping
improve calculation of central and semicentral triggers based on summed PM charge
add monitoring of summed PM amplitudes (debug logging)

The definition of FT0 triggers in the digitizer is updated to better match the trigger logic used in data processing. In particular, the central, semicentral, and vertex trigger conditions are now computed using PM-summed amplitudes and timing definitions consistent with those used in the FT0 trigger chain.

In addition, the FV0 trigger logic has been corrected to follow a consistent definition with the data.

These changes improve the consistency between MC digitization and the trigger quantities reconstructed from data.

No changes to the data format are introduced.

[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

[alibuild]

Error while checking build/O2/fullCI_slc9 for 4725b5e at 2026-03-30 19:59:

## sw/BUILD/O2Physics-latest/log
c++: fatal error: Killed signal terminated program cc1plus
ninja: build stopped: subcommand failed.


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

Full log here.

[andreasmolander]

I am a bit late to the PR, but please consider these

[andreasmolander]

We have this logic copy-pasted in a lot of FIT code, please consider moving it to a standalone class that can be reused in other places. If not that, then please at least consider moving it to a initialization section of the Digitizer. Now it will run for each BC stored. The hashmaps can for example be members of the digitizer class, as the LUT, they don't change often. Although I would prefer having this somewhere else all together.

[andreasmolander]

Fine for now, but we should also consider supporting the different trigger modes (A+C, A&C, A, C)

[andreasmolander]

We should support separate upper and lower vertex thresholds, also pls modify the comment to point to the correct setting in CS

[andreasmolander]

Fine for now, can maybe consider "true" HW division if we make that method globally available somewhere