You can see that for ( more than half ! ) pfos: 3, 4, 7, 9, 10, 11, 12, 14, 17, 18, 20, 27, 28, 29, 30, 31, 33, 34, 36, 37
it leads to the linking to the wrong MCParticle, which does not have maximum contribution either track or calorimeter -wise.
I think the best behaviour would be to choose a MCParticle with a highest track weight.
If the maximum track weight is 0, then get the highest calorimeter weight.
Thanks. It's good to fix it. MCParticle is not as a part of production procedure so it is less debuged and also easier to modify without any effect on performance on existing analysis.
Taking first element from the
getRelatedToObjects()
is not ok and wrong here:https://github.com/lcfiplus/LCFIPlus/blob/8a4629883c1e1b8baef1feb2b6871859ecdda735/src/LCIOStorer.cc#L397
MCParticles from
getRelatedToObjects
are not sorted in any way.Here is an example of a random event, where I print MCParticle relations for each PFO explicitly with corresponding weights:
Code:
Output:
You can see that for ( more than half ! ) pfos: 3, 4, 7, 9, 10, 11, 12, 14, 17, 18, 20, 27, 28, 29, 30, 31, 33, 34, 36, 37 it leads to the linking to the wrong MCParticle, which does not have maximum contribution either track or calorimeter -wise.
I think the best behaviour would be to choose a MCParticle with a highest track weight. If the maximum track weight is 0, then get the highest calorimeter weight.
Weights encoding "documentation" here:
https://github.com/iLCSoft/MarlinReco/blob/541d61d96f6cb923042900f9284ccf0067d8fb10/Analysis/RecoMCTruthLink/include/RecoMCTruthLinker.h#L32-L50