RecoUtils truth matching functions do not correctly account for non-saved particles
When a particle is not saved by geant4 but has deposited energy into a hit, backtracker returns the negative ID of the closest ancestor.
The truth matching functions in RecoUtils do nothing regarding this situation and will happily return a negative track ID.
This actually has a knock on effect the user may not be aware of when assessing which particles made which hits.
Here is an example when using RecoUtils::TrueParticleIDFromTotalRecoHits(const std::vector<art::Ptr<recob::Hitit> >& hits) on a reconstructed pandora shower:
- ID: -86 Count: 2
- ID: 1 Count: 29
- ID: 86 Count: 27
Selected ID: 1 TruePDG: 13
ID 1 is the muon and ID 86 is the daughter Michel electron. ID -86 is a non-saved electron daughter particle.
RecoUtils::TrueParticleIDFromTotalRecoHits simply counts up which particle contributed to the most hits. In this case, the muon wins as it contributes the most energy to 29 hits. This should actually be a tie as the electron + its non-saved daughter contribute 29 hits.
The easiest solution is to offer the user the option to roll up any negative ID contributions to its ancestor. I think that this should be a bool function argument which is set to on by default.
To fully address the example above, a tie situation needs to be dealt with. RecoUtils::TrueParticleIDFromTotalRecoHits can default to a different RecoUtils truth matching function when a tie happens.
#1 Updated by Dominic Brailsford about 3 years ago
A fix has been pushed to develop.
All truth matching functions now come with a bool argument to active the rollup. The switches are on by default.
Additionally, if there is a tie for highest number of contributing hits then the alternative truth matching function which sums total true contributing energy is used.