You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:LCFIPlus/src/LCIOStorer.cc
Line 397 in 8a46298
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
The text was updated successfully, but these errors were encountered: