Skip to content

MCTupleToolDalitz crashes when an unknown PDGID is encountered

Continuing to investigate #32 (closed) I found a new, separate, issue. In a sample of Lb => J/psi(=> mu mu) p K decays I get a failure of the same TupleTool a few hundred events in. The verbose log is:

MCDTT1520mm         DEBUG #### Filling 2212
MCDTT1520mm         DEBUG FillOnePart MC 2212 p
MCDTT1520mm         DEBUG FillOnePart MC 2212 in MCTupleToolDalitz
MCDTT1520mm.MCT...  DEBUG Decay of 2212 with mother 0x9205ab0
MCDTT1520mm.MCT...VERBOSE does not decay
MCDTT1520mm         DEBUG #### Filling -321
MCDTT1520mm         DEBUG FillOnePart MC -321 K
MCDTT1520mm         DEBUG FillOnePart MC -321 in MCTupleToolDalitz
MCDTT1520mm.MCT...  DEBUG Decay of -321 with mother 0x9205ab0
MCDTT1520mm.MCT...VERBOSE does not decay
MCDTT1520mm.MCT...VERBOSE does not decay
MCDTT1520mm.MCT...VERBOSE Decay vertex of type DecayVertex with 3 products
MCDTT1520mm.MCT...VERBOSE Pushing back -211
MCDTT1520mm.MCT...VERBOSE Pushing back -211
MCDTT1520mm.MCT...VERBOSE Pushing back -99000000

The problem is the ID -99000000 which, according to https://github.com/scikit-hep/particle at least, is not a valid ID. This seems backed up by the fact that it causes MCTupleToolDalitz to die at this line: https://gitlab.cern.ch/lhcb/Analysis/-/blob/run2-patches/Phys/DecayTreeTupleDalitz/src/TupleToolDalitz.icpp#L72 The exact problem is the call to ppp->antiParticle()->particle() which fails because ppp->antiParticle() returns 0 which I guess means LHCb particle property service knows nothing about this ID.

We should add a protection against particles that are unknown and which will fail this call, perhaps before this line?

Again, reluctantly assigning to @pkoppenb since, though it feels like ancient history, I'm sure you're a good person to cast an expert eye over my debugging ;)

Also tagging @dathomps and @cburr because this was one of the two crashes that broke a recent batch of analysis productions.