-
Notifications
You must be signed in to change notification settings - Fork 99
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Get proper hit/MCParticle relations from Geant4Output2EDM4hep #1305
Comments
Is this particle scattering back, or created in the tracker? |
It is created in the tracker |
I had a suspicion that the podio python bindings might be causing this, but I see the same behavior in C++ |
The quality bit points to the hit coming from a different particle. So using that bit you can exclude the hits, which is probably what you aim for if you don't want the particle stored?
from the slcio output
I am not sure the PDGCode should be 13 in this case, I was expecting that to be what the actual particle was. And we don't store the momentum at hit, which might help to understand if we hit some threshold for storing particles. |
Changing
Let's you keep more secondaries, including those that make the hit. Adjust to your liking. I don't think there is anything wrong in the logic
|
Hi Andre, thank you very much for looking into this!
If we decide that the logic is "if the secondary is not kept, the relation points to the youngest kept mother", then PDG could be 13 to be consistent. But this only for lcio, right (edm4hep::SimTrackerHit does not have this member)? I am indeed ok with the current behavior. I got mislead by the fact that |
No, the hit comes from the particle that caused the hit, not from something it produced. So this sounds technically correct. Otherwise we would essentially always set that bit? If you find the explanation in EDM4hep confusing, you can propose a change there. |
Yeah, agreed. Thanks Andre! |
Check duplicate issues.
Goal
In some cases, all tracker hits are attached to the primary particle while there was clearly a secondary produced (colors reflect the MCParticle attached to the trackerHit):
.
This behavior gets cured when enabling
--part.keepAllParticles
:but the file size becomes too big for practical purposes...
Wanted behavior: if the particle attached to the hit is not kept in the output file,
sth.setParticle(mcp);
should not be called, or should be called in a way that does not make it point to an existing particle. See: https://github.com/AIDASoft/DD4hep/blob/master/DDG4/edm4hep/Geant4Output2EDM4hep.cppThis seems related to (but is not a duplicate of) #471 which I guess was opened for lcio output.
Operating System and Version
Alma9
compiler
gcc 11.4.1
ROOT Version
6.30/06
DD4hep Version
master
Reproducer
If you want to directly use the output rootfile, the pathological behavior can be seen on event 87 (starting to count at 0).
Additional context
No response
The text was updated successfully, but these errors were encountered: