Set the fast simulation flag and adjust step length for contributions created by fast simulation#1582
Set the fast simulation flag and adjust step length for contributions created by fast simulation#1582tmadlener wants to merge 2 commits intoAIDASoft:masterfrom
Conversation
Test Results 18 files 18 suites 6h 29m 45s ⏱️ For more details on these failures, see this check. Results for commit fb04ca0. ♻️ This comment has been updated with latest results. |
|
The one thing that is untouched by this PR is the MC truth record handling. Hence, the fast sim flag will be set on whatever MCParticle is used for the hit contribution. One potential downside is that the fast sim flag will be set on a primary particle whenever any of its secondaries are done by fast simulation. Consider, e.g. a tau decaying to (among others) a pi0, going to photons, where any of the photons is done by fast simulation. Depending on how the simulation is configured it's possible that neither the pi0, nor the photons are in the output MCParticle record, so the fast sim flag will be set on the primary tau even though only a part of it was done using fast simulation. It might be useful to actually have the possibility via a I think for now this implementation is OK, as it at least gives us a handle to check things. However, it is possible that we will discover that we need a more detailed record, without having to go to the full glory full detailed mode in the future. |
|
We wait for key4hep/EDM4hep#474 to be merged before merging this. |
Makes it possible to distinguish them from contributions created in normal simulation because those will always have a positive step length by definition.
tmadlener
force-pushed
the
mcparticle-fastsim-flagging
branch
from
af0ed8a to
fb04ca0
Compare
|
I think the failing CI is not due to these changes. |
|
The failing changes are #1594 |
2 participants
BEGINRELEASENOTES
-1to clearly distinguish them from those created by ordinary simulation as those by definition have a step length that is>= 0. This will only be effective if the detailed shower mode is enabled.ENDRELEASENOTES
This is a follow up to an original attempt in #1503. As far as I can see this is the simplest non-intrusive approach that will always work regardless of the configuration / setup of the user. It also does not require to implement a UserParticleHandler that keeps track of the necessary state. Additionally, it doesn't require to add an additional internal flag to the Particle in DD4hep.
In order to fully profit from this DD4hep needs to be built against a version of EDM4hep with the changes from key4hep/EDM4hep#474 in.