Bug #23921

Cosmics corsika database selection not random

Added by Patrick Green about 1 year ago. Updated about 1 year ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:
0.50 h
First Occurred:


Cosmics generated with official MCP2.0 fhicls, e.g. prodcorsika_cosmics_proton.fcl, always select the same corsika database file rather than a random one from the list.

This can be fixed by changing:

services.NuRandomService.policy: "perEvent" 

services.NuRandomService.policy: "random" 

matching the configuration used by uboonecode.

The NuRandomService.policy is also set to "perEvent" for genie fhicls, e.g. prodgenie_nu_singleinteraction_tpc_gsimple-configf-v1.fcl, rather than "random" like in uboonecode. This causes issues with random numbers for events generated in a HPC environment - 1 event per core, merging together at the end - and may be an issue for MCP2.0 generated events but hidden because many events are generated per job.

Perhaps this should be changed at the upstream fhicl that both of these inherit from.


#1 Updated by Patrick Green about 1 year ago

  • Assignee set to Patrick Green

The nuRandomService policy had previously been set (in 2016) to "perEvent" in seedservice_sbnd.fcl to allow reproducible generation of events - the seed is based on the particular event timestamp and information. To generate a proper seed the "perEvent" policy requires an event to already exist, if not it always defaults to the same seed. For the generation stage this can be achieved by making an empty event to base the seed on beforehand. However, this is not being done as default for any of the standard and production workflows. This means that the first event generated by any of these workflows has exactly the same seed, but then subsequent events are seeded properly. This is the cause of the issues described with Corsika .db files and with the issues in the genie generated events -- event #1 for all the MCP2.0 files and any events generated on Theta HPC (since in this case only 1 event is generated in each job, they always have the same seed).

#2 Updated by Patrick Green about 1 year ago

To resolve this the policy has been reverted to "random". This can be changed back to "perEvent" in future if the workflows are all updated to generate empty events before each job to allow valid seeds for the first event.

Also available in: Atom PDF