-
Notifications
You must be signed in to change notification settings - Fork 31
feat: ingest EventHeader into digi, generate UID to reseed RNG #1934
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
base: main
Are you sure you want to change the base?
Conversation
size_t getUniqueID(const event_num_t evt_num, const run_num_t run_num, | ||
const std::string_view& name) const { |
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.
Not strictly necessary to ingest name here, since can pass that on init
, not process
, but this is an attempt at sticking close to the k4FWCore approach. Only difference is that we take a string_view
instead of a string
(arguably they will want to move to string_view
anyway).
for more information, see https://pre-commit.ci
Interesting... The new plots for MT and non-MT should now be identical... But aren't.
Maybe I'm missing some reseeding somewhere. |
Or there's a data race, https://github.com/eic/EICrecon/actions/runs/15937325592/job/44960208488?pr=1934#step:7:928 ... |
Briefly, what does this PR introduce?
One challenge of multi-threaded/concurrent running is that the random number generators are called in no predictable order; this affects both events which can come out of order, or algorithms within the same event which can be called in different orders for different branches. That results in non-reproducibility.
This PR ingests the event header into digitization algorithms (which is our main use for random sampling). The event header is combined with the algorithm name into a random seed for that event/algorithm combination. With this seed, the random number generator is reseeded.
Outside the scope of this PR is reverting back to a single random service instead of the various algorithm specific approaches.
Still TODO in this algorithm:
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?
Yes. It results in a different random number sequence, so all distributions will be shuffled.