Re-simulating specific events

[cherylepatrick]

This follows on from the cut module question in issue #177

Thanks to @fmauger 's help in issue #176 it looks like it is possible to simulate the true GEANT information. Ideally, what @wausain would like to be able to do is to rerun the simulation for a small subset of events, with the GEANT information turned on. I guess to do that, he would need to know the seeds used for both GENBB and GEANT for those events. Is that in any way possible? Is that information even stored anywhere? I suspect the answer will be no, but I'm asking in the hope that it is yes!

[fmauger]

It is yes of course. or it should be. At least it is implemented from Bayeux's tools. We should ask Yves where are the log files that are generated when flsimulate is ran automatically but in principle we should be able to trace back the seeds that have been used for each run (there are 4 seeds for each of the 4 core pseudo random number generators used by flsimulate).

In https://github.com/SuperNEMO-DBD/Falaise/blob/develop/documentation/flsimulate/FLSimulate-3.3.0.conf example file, you can see the section :

[name="flsimulate.simulation" type="flsimulate::section"] on line 45 there is a property named "rngSeedFileSave" which can be used to specify the name of a file where to store the initial seeds.

Above on line 42, there is the "rngSeedFile" which indicates the file that should be used to read the seeds for a given run.

Again, if you want to reprocess some MC files from existing material generated by Yves at CC with his special scripts, I guess such files are documented and saved within the official hierachy of dataproducts.

[cherylepatrick]

Wow @fmauger - that is amazing! I was totally expecting a "no" to that question. Thank you! You really do plan ahead :)

[drbenmorgan]

I've assigned @wausain and @mauger for this - it's on you both to document and/or add any code to achieve this.

@cherylepatrick, just to check, are you wanting to rerun a specific sequence of events from a previous sample? That would need the Random state right before starting those events, and would need a mechanism to reseed on each event.

[cherylepatrick]

Ideally it would be specific events (Can we see what happened in event 14 and 38? for example). The use case we had in mind was that there were certain events with characteristic reconstructed signatures, and we would want to know what really went on in those events: were these background events that passed our reconstruction cuts due to crossing electrons or e+/e- pair production?

[mauger]

Guys,

I think you mistakenly included me in this group.

Regards,

Em 25 de mar de 2020, à(s) 13:16, Ben Morgan notifications@github.com escreveu:

I've assigned @wausain https://github.com/wausain and @mauger https://github.com/mauger for this - it's on you both to document and/or add any code to achieve this.

@cherylepatrick https://github.com/cherylepatrick, just to check, are you wanting to rerun a specific sequence of events from a previous sample? That would need the Random state right before starting those events, and would need a mechanism to reseed on each event.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/SuperNEMO-DBD/Falaise/issues/178#issuecomment-603935108, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAJAPAAKBHQUFNJCPRG74I3RJIU6BANCNFSM4LTRFJ6Q.

[drbenmorgan]

Ah, so sorry!

[fmauger]

Such a feature exists in falaise but not exactly what you may want.

In such case the original run must regularly save the internal state (basically a sequence of intergers) of each pseudo random number generator (PRNG). Back to the file mentioned above, you can find the associated configuration parameters between lines 55 and 63. The idea is to ask the flsimulate core simulation engine to backup the last known states of PRNGs, every say 1000 events. This feature was implemented in Bayeux to be able to trace back some conditions a few events before a crash in order to save processing time while debugging a MC production with issues occurring randomly. The idea is to enforce the internals states of the PRNGs a bunch of events before the one of interest, thus saving some CPU needed to repoduce the full random sequence of events before the interesting region, as mentioned by Ben.

However, what you would need is to save periodically these states, not only the last one. Tis would allow you to identify the slice(s) of interest in the random sequence of events. And I must say "no". it is not implemented... while it should not be difficult to do (in Bayeux or Falaise, I don't remember now). May be you don't need that today because if you want to analyze some target known events, it does not hurt to reprocess say thousands of them with G4 hit infos. I won't say the same of you should pickup a few events among billions in a single run.

[fmauger]

YACM !!

Yet Another Confined Mauger !

[fmauger]

About this topic of PRNGs' seeds in Flsimulate, AFAIR, we have provided a tool to guarantee that when someone want to launch a large set of MC runs associated to the same physics cas.

To do that, we first generate some files with as many different quadruplet of seeds needed to ensure statistical independence between generated datasets associated to the same physics case. Each run is given its input seed file and thus we are sure no bias is introduced.

Usage is:

$ bxg4_seeds --help
$ bxg4_seeds --number-of-runs 10
$ tree __bxg4_seeds-set.d/
__bxg4_seeds-set.d/
├── __bxg4_seeds-runs.lis
├── seeds_0.conf
├── seeds_1.conf
├── seeds_2.conf
├── seeds_3.conf
├── seeds_4.conf
├── seeds_5.conf
├── seeds_6.conf
├── seeds_7.conf
├── seeds_8.conf
└── seeds_9.conf
$ cat __bxg4_seeds-set.d/seeds_0.conf
{EG=691798990; MGR=763212227; SHPF=935488941; VG=114887546}

where:

EG stands for Event Generator VG stands for Vertex Generator MGR stands for the Geant4 run manager (the specific PRNG for the G4 kernel) SHPF stands for Step Hit Processor Factory : which randomize the sensitive detector response (typically randomize first-ionization to model the spread of the Geiger cascade in tacker cells)

Yves uses such a mechanism from his scripts to generate batch launching scripts at CCIN2P3.