Bug #19461

RecoUtils truth matching functions do not correctly account for non-saved particles

Added by Dominic Brailsford about 3 years ago. Updated about 3 years ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:
First Occurred:
Occurs In:


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:
NParticleContribs: 3
- 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.

#2 Updated by Dominic Brailsford about 3 years ago

  • Status changed from New to Resolved

Also available in: Atom PDF