Reproducible events in the refactored LArG4
ProtoDUNE is currently transitioning to utilizing the refactored LArG4 for production and would like to be able to reproduce Monte Carlo Challenge events if needed. In LegacyLArG4, this is achieved by using the NuRandomService `perEvent` policy for the Geant4 seed engine which ensures that the random seed value for an existing event is consistent across multiple G4 stage runs. This reproducibility is described in the following wiki: Reproducing_jobs_using_the_same_random_number_sequences.
In the refactored LArG4, however, the native `createEngine()` function from the EDProducer base class is used, and the random seed utilized for the simulation is derived from the pid and the timestamp for the job. I created a feature branch (https://github.com/LArSoft/larg4/pull/7) to adopt the NuRandomService, instead; however it was pointed out that NuRandomService has issues with multi-threading, and as LArG4 will likely move towards multi-threading, this can present issues in the future.
(N.B. : Several modules in LArSoft utilize the NuRandomService.)
It would be great to be able to choose between the different policies available for the NuRandomService. We would appreciate guidance on the best way to proceed in order to make events reproducible in the refactored LArG4.
#2 Updated by Kyle Knoepfel about 1 year ago
- % Done changed from 0 to 100
- Status changed from Assigned to Resolved
Gianluca and I discussed the issue yesterday. The plan is as follows:
- I will work on an interface of
NuRandomServicethat supports the thread-safe generation of random number seeds.
- That interface will likely remove automatic seed-setting due to couplings that are difficult to handle in a multi-threaded environment--i.e. it will be the responsibility of the user to take the generated seed and apply that to the engine at the appropriate level (per job, per event, etc.)
- Gianluca and I will then look to find ways to improve the usability, while still retaining the thread-safe features of the service.
In the meantime, I will encourage the SciSoft team to approve the GitHub PR, with the understanding that the code will need to be adjusted once the new interface is ready.
One other issue: G4 supports multi-threaded execution, but it does so through its own threading mechanisms. In order to get art's TBB thread scheduler to interact with G4's task manager, some rather difficult manipulations are required. CMSSW and Mu2e have succeeded in doing this, but LArSoft has not yet pursued that issue. So even though the
NuRandomService will become thread-safe, additional work will be required to ensure that the G4 modules can also be used in a multi-threaded environment.