[Common] Fix matching to MC for daughters interacting with material

[fgrosa]

Together with @mfaggin we realised that whenever a daughter particle (i.e. pion or kaon from a D0 decay) interacts with the material, the particle id changes and in particular another particle with same pdg of the original one is produced by GEANT, and it is set as daughter of the original mother. This can happen several times, due to several interactions with material.
When this happens, getMatchedMCRec does not match correctly the signals, since the track can be associated to the particle from material and not the original daughter:

[INFO]    pdg code 421
[INFO]        - daughter PDG -321 | idx 58356
[INFO]             - grandDaughter PDG 1000120250 | idx 58518
[INFO]             - grandDaughter PDG 11 | idx 58519
[INFO]        - daughter PDG 211 | idx 58357
[INFO]             - grandDaughter PDG 1000120260 | idx 58514
[INFO]             - grandDaughter PDG 211 | idx 58515
[INFO]             - grandDaughter PDG 11 | idx 58516
[INFO]             ++++  track found! 4963 | idxDaug 58356
[INFO]             ++++  track found! 4981 | idxDaug 58515
[INFO]    idx matched reco particle:   -1

To overcome this issue, I added a functionality similar to the one added by @Luca610 for the decays into muons, with the only difference that it searches the mothers iteratively, since multiple interactions might have happen.

The effect is anyway very small (< 1%) in case global tracks are required, since often if the particle interacts with material, there are two track segments reconstructed (only one of the two having hits in the ITS IB, i.e. the one produced by decay itself) or only a track for the particle produced by the material that has no ITS IB hit most of the times.
However, if no global track requirement is applied to the daughters (which might be in case of non-HF decays) the fraction is very high (in the case of the D0, about 25% of the D0 have at least a daughter that interacted with material), so the fraction of non matched signals becomes also very high.

@vkucera could you please have a look to check if it's good for you? If it's the case, I would ask @ddobrigk to merge this so that I will include it in the HF code. Thanks!

[alibuild]

Error while checking build/O2Physics/o2 for e525118 at 2025-01-20 09:28:

## sw/BUILD/O2Physics-latest/log
/sw/SOURCES/O2Physics/9391-slc9_x86-64/0/Common/Core/RecoDecay.h:702:12: error: declaration of 'int8_t nInteractionsWithMaterial' shadows a parameter
ninja: build stopped: subcommand failed.

Full log here.

[vkucera]

Thanks @fgrosa

[mfaggin]

hi @fgrosa many thanks for implementing the fix. Just a question: looking better into the code, I do not get the role of nInteractionsWithMaterial (see lines https://github.com/AliceO2Group/O2Physics/pull/9391/files#diff-7fb78a667de645413dabf3d3cb49ee16a67780bbb11e1f3f839d503906af9aefR847-R851) which is not used neither to constrain the number of iterations with material that one wants to check, nor to monitor things later e.g. with a histogram or anything else. Am I missing something?

[fgrosa]

hi @fgrosa many thanks for implementing the fix. Just a question: looking better into the code, I do not get the role of nInteractionsWithMaterial (see lines https://github.com/AliceO2Group/O2Physics/pull/9391/files#diff-7fb78a667de645413dabf3d3cb49ee16a67780bbb11e1f3f839d503906af9aefR847-R851) which is not used neither to constrain the number of iterations with material that one wants to check, nor to monitor things later e.g. with a histogram or anything else. Am I missing something?

It is needed to monitor when the matched candidate had a particle interacting with material, similarly to what done for the decays into muons. We will store this information in the HF tables to allow the analysers to evaluate the effect at the analysis level (excluding or including the signals with a decay daughter that interacted with material). Also consider that the momentum resolution might be worse when the particles interact with material and might effect the mass distribution of signals (as we observed for pi->mu)

[mfaggin]

hi @fgrosa many thanks for implementing the fix. Just a question: looking better into the code, I do not get the role of nInteractionsWithMaterial (see lines https://github.com/AliceO2Group/O2Physics/pull/9391/files#diff-7fb78a667de645413dabf3d3cb49ee16a67780bbb11e1f3f839d503906af9aefR847-R851) which is not used neither to constrain the number of iterations with material that one wants to check, nor to monitor things later e.g. with a histogram or anything else. Am I missing something?

It is needed to monitor when the matched candidate had a particle interacting with material, similarly to what done for the decays into muons. We will store this information in the HF tables to allow the analysers to evaluate the effect at the analysis level (excluding or including the signals with a decay daughter that interacted with material). Also consider that the momentum resolution might be worse when the particles interact with material and might effect the mass distribution of signals (as we observed for pi->mu)

thanks @fgrosa , indeed I was overlooking this thing (to be propagated to candidate creators)

Many thanks, all good for me

[ktf]

Please fix the linter in a subsequent PR.