MC matching using ToMC - many matches show large momentum differences

[donalhill]

all_hadrons_delta_p_per.pdf
all_hadrons_angle_match_delta_p_per.pdf

I have looked at two MC-matching methods in order to evaluate the performance of the ToMC association. The first method here:

https://github.com/donalrinho/fcc_python_tools/blob/master/examples/momentum_resolution.ipynb

calculates the angle between reconstructed hadrons and generated particles, and chooses the pair with minimum angle to be the MC-matched pair. The second method is here:

https://github.com/donalrinho/fcc_python_tools/blob/master/examples/mc_matching.ipynb

where I use the efcharged#1.index values for each reconstructed hadron in efcharged to pick the associated truth particle in genParticles.

Both methods always assign a true particle to each reconstructed hadron. This allows the momentum resolution to be studied by calculating the difference between the true and reco momentum for each pair.

I find that method 2 only produces a sensible resolution peak for about 1% of cases, judging by the size of the peak compared to method 1. The other 99% of matched pairs show larger momentum differences, which appear to be quite uniformly distributed. I don't know the origin of this effect, but it may indicate that a lot of the matched pairs are actually random associations. Perhaps the small peak I do find are the cases where the matching at random actually managed to pick the correct pair?

I have noticed that using efcharged#1.index and efcharged#0.index give exactly the same results, whereas I expected these two indices to point to the genParticles and efcharged, respectively. Is it possible that efcharged#1.index is not filled with the correct genParticle index values?

[donalhill]

A bit more info on this. I have run a further test using the minimum angle method to truth-match. I match kaons and pions to their generated particles by choosing the generated particle with the smallest angle. I then create D0 candidates from kaons and pions, both for the reco hadrons and their matched generated particles.

This lets me calculate both the reco and true D0 candidate masses. I can then use the true mass as a selection requirement, to keep only those combinations with a true mass consistent with the PDG D0 mass. The code is here:

https://github.com/donalrinho/fcc_python_tools/blob/master/examples/D0_mass_truth_matching.ipynb

and I attach the main figure here. It shows that you can cleanly select the genuine reco D0 candidates by cutting on the true mass of the MC-matched combination. This seems to indicate that the minimum-angle MC-matching is working as expected.

D0_MC_match.pdf

[vvolkl]

Hi @donalrinho @clementhelsens , it seems that (surprisingly) indeed the FCCSW delphes output tools will create an association even if the MC/Reco particles cannot be matched. It will then save the delphes particle status to the bits field of RecoParticles. The EDM4hep Delphes output handles this much better - I'll try the matching using that now.

[vvolkl]

For completeness, in FCC-EDM you would have to add a filter

efcharged.core.bits == 3

Values from https://github.com/HEP-FCC/FCCSW/blob/master/Sim/SimDelphesInterface/SimDelphesInterface/ParticleStatus.h

[donalhill]

Hi @vvolkl

Thanks for looking into this. Just to note that I've also been looking at MC association in the EDM4Hep output. Here I try to match ReconstructedParticles to Particle using the index MCRecoAssociations#1.index. But as I mentioned to @clementhelsens, there are 0.4% more entries in the MCRecoAssociations#1 container than the ReconstructedParticles container (they should be equal). Once that is resolved, I can redo the above check to see if the issue is present in EDM4Hep.