Larger MCRecoAssocation collection than RecoParticles collection when using DelphesPythia8_EDM4HEP

[vvolkl]

Migrated issue: key4hep/EDM4hep#91

QUOTE:
In the process of implementing reco to truth matching in FCCAnalyses, I realised that the fact that we see a larger number of MCRecoAssocation collection than RecoParticles collection is mainly due to a generated pi0 decaying to two photons which are reconstructed as a single photon. I did not made a super detailed study, but I'm pretty sure this could happened with other types of particles. In such cases we have the same reco particle pointing to two MC particles in two different OneToOneRelations. Won't it be better to have OneToManyRelations in such cases?

Below is an interesting event at FCC-hh, very busy and rare one as it is ttHH.
In this event we have 6324 MC particles, 1224 reconstructed particles and 1234 associations (OneToOneRelation MC reco)
You can see that many of the reconstructed particles have in the event even build with up to 4 truth particles, from the same or different parents. I know we are restructuring the code, but I wanted to share this here for the record.

rec ind 549 reco P 24.269  mc ind 5528 truth P 0.859872 pdg_id 22  parent id 4456 parent pdg id 111
rec ind 549 reco P 24.269  mc ind 6267 truth P 10.1102 pdg_id 22  parent id 6203 parent pdg id 111
rec ind 549 reco P 24.269  mc ind 6267 truth P 10.1102 pdg_id 22  parent id 6203 parent pdg id 111
rec ind 549 reco P 24.269  mc ind 6288 truth P 13.2324 pdg_id 22  parent id 6230 parent pdg id 111
rec ind 687 reco P 18.5327  mc ind 6176 truth P 9.0619 pdg_id 22  parent id 5836 parent pdg id 111
rec ind 687 reco P 18.5327  mc ind 6177 truth P 9.10258 pdg_id 22  parent id 5837 parent pdg id 111
rec ind 852 reco P 14.8237  mc ind 5344 truth P 8.51735 pdg_id 22  parent id 4125 parent pdg id 111
rec ind 852 reco P 14.8237  mc ind 5379 truth P 5.31896 pdg_id 22  parent id 4251 parent pdg id 221
rec ind 993 reco P 33.1935  mc ind 4318 truth P 21.0651 pdg_id -211  parent id 4252 parent pdg id 21
rec ind 993 reco P 33.1935  mc ind 4721 truth P 13.2629 pdg_id 211  parent id 3982 parent pdg id -313
rec ind 1046 reco P 3.92714  mc ind 3785 truth P 3.28534 pdg_id 211  parent id 3768 parent pdg id 2
rec ind 1046 reco P 3.92714  mc ind 5149 truth P 1.80995 pdg_id 211  parent id 3646 parent pdg id 223
rec ind 1075 reco P 12.9256  mc ind 5323 truth P 2.71686 pdg_id -211  parent id 4054 parent pdg id 223
rec ind 1075 reco P 12.9256  mc ind 5838 truth P 9.04003 pdg_id 211  parent id 4984 parent pdg id 310
rec ind 1144 reco P 18.772  mc ind 3411 truth P 0.607773 pdg_id 211  parent id 3395 parent pdg id 1
rec ind 1144 reco P 18.772  mc ind 3957 truth P 19.3562 pdg_id 2112  parent id 3931 parent pdg id 5
rec ind 1201 reco P 190.908  mc ind 4424 truth P 41.8603 pdg_id 211  parent id 3226 parent pdg id 2
rec ind 1201 reco P 190.908  mc ind 4715 truth P 123.7 pdg_id -321  parent id 3976 parent pdg id -313
rec ind 1213 reco P 38.7616  mc ind 4363 truth P 99.3652 pdg_id -211  parent id 3226 parent pdg id 2
rec ind 1213 reco P 38.7616  mc ind 4549 truth P 33.114 pdg_id -211  parent id 3563 parent pdg id 113

ENDQUOTE

[clementhelsens]

@tmadlener , I realised this just now, but for the event above, if you look at the first 3 lines, you will notice that we have twice the same MC particle index 6267 in the association, which looks really strange

[tmadlener]

Hi @clementhelsens,

In such cases we have the same reco particle pointing to two MC particles in two different OneToOneRelations. Won't it be better to have OneToManyRelations in such cases?

After looking into the delphes output in a bit more detail, I also realized that the other case exists as well; One reconstructed particle pointing to more than one MC particle. From what I have seen these are all from the same decay chain, so it kind of makes sense, but still is somewhat unexpected, at least for me. In any case, this means that we should probably support both cases: multiple reco particles pointing to one MC particle and vice versa. This is easier with OneToOneRelations I think, because then you just add a new relation. With OneToManyRelations we would need two types, one per direction.

if you look at the first 3 lines, you will notice that we have twice the same MC particle index 6267 in the association, which looks really strange

I think this could also be because 6267 is simply a generated particle in a decay chain and for some reason delphes doesn't really take that into account properly. I am still investigating this in a bit more detail, but from a first look it seems that for some particles delphes also includes the parent in the related gen particles while for others it doesn't and that trips the association of reco to mc particles in the converter.