Random Noise injection factory with its usage in tracker classes #1988
Conversation
github-actions
bot
added
topic: tracking
There was a problem hiding this comment.
Nice contribution. A few cursory comments to get things going, I haven't dived into the details.
I think this would sit better as a separate set of hits e.g. there is no input collection just the requested readout. Then the CollectionCollector would combine them later. This would stop you needing to clone the hits and help maintain the associations. There might be other opinions on this.
The N noise hits per system might be ok for a first pass but should later be replaced by a frequency per channel or frequency per surface area so when a MC timeframe period can be used it can be directly configured.
| } | ||
|
|
||
| // 3.3 duplicate check | ||
| if (hitMap.find(cid) != hitMap.end()) |
There was a problem hiding this comment.
I don't think this should be needed, as soon as you distribute hits across time there could be multiple noise hits in the same element. It's not quite that simple as it will be digitization dependent.
There was a problem hiding this comment.
not sure what to do at this moment - I will bring this point to tracking or reco. meeting!
|
Note the recently merged #1934 which imposes the use of the EventHeader info for any algorithms that use randomness, to ensure reproducibility in concurrent running. |
minjungkim12
force-pushed
the
Random_Noise_Injection_forTracker
branch
from
23bb179 to
a6dae27
Compare
for more information, see https://pre-commit.ci
There was a problem hiding this comment.
Can you please remove the calibrations, fieldmaps, and gdml directories from this PR?
4 participants
Briefly, what does this PR introduce?
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?
Does this PR change default behavior?
No, it should be transparent.