-
Notifications
You must be signed in to change notification settings - Fork 29
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
feat: Calorimeter hit digi simplification #794
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No need to keep a pointer m_detector
in the factory.
Right... This is where randomness comes in. |
Maybe we need to consider a seed in the configuration for each digitization factory. Like https://github.com/eic/EICrecon/blob/main/src/algorithms/digi/PhotoMultiplierHitDigiConfig.h#L17. |
23534eb
to
f0e4162
Compare
@veprbl Thanks! The threshold is exactly it, now all that's left in terms of diffs (for gun simulations) is changing collection IDs. |
Co-authored-by: Dmitry Kalinkin <[email protected]>
06e6e1d
to
5994e5e
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Checked differences in edm4eic and flag artifacts, all looks good.
This applies the #666 treatment to the CalorimeterHitReco algorithms (on top of #794): - put all configuration in a single configuration struct for use with WithPodConfig mixin, - create a templated factory-factory to use in the plugins, - replace all old explicit CalorimeterHit factories with the new factory-factory.
Briefly, what does this PR introduce?
This applies the #666 treatment to the CalorimeterHitDigi algorithms:
What kind of change does this PR introduce?
Please check if this PR fulfills the following:
Does this PR introduce breaking changes? What changes might users need to make to their code?
No.
Does this PR change default behavior?
No.