Random seed policy moved back to per-event #442
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The policy now uses
randomas fallback policy for per-event seeds.This addresses issue #243.
The background: LArSoft provides a policy for providing seeds to the random number generators which ensures that the same event will always receive the same seeds, guaranteeing job reproducibility. Unfortunately that policy does not define what happens when seeds are required outside the event boundaries; a typical case is the LArSoft implementation of CORSIKA interface,
CORSIKAGen, which at beginning of the job decides randomly which pool of pre-generated events to use in the job. This choice happens at a time when no event is being processed (no input file, in fact, has been opened yet). The undefined behaviour of the per-event policy was in fact to always use0as a seed, which would cause the same pool of cosmic ray events to be used for every job.While LArSoft offers no real solution to this issue, it now provide a workaround in allowing to control which seeds are provided at that time. My choice here is to use a
randompolicy, which does not guarantee reproducibility (e.g. rerunning a job on a certain input will pick a different CORSIKA event pool) but at least behaves as a random generator.This pull request defines this new configuration, defines also an alias
icarus_default_NuRandomServicesupposed to define the "default" random seed service configuration for ICARUS, and then it uses the latter wherever there is the need to configure that service.This may be a breaking change for the simulation, since different random streams may be generated for some of the modules, but it will likely not be noticed by the integration tests, which fix the random seeds overriding the standard configuration settings.
This pull request has been tested running the unit tests, a
prodcorsika_genie_standard_icarus.fcljob, astandard_g4_icarus.fcljob and astandard_detsim_icarus.fcljob.