seedstate input

[Jochem Snuverink]

Now that the seedstate output (into a text file) has been removed in commit 6185ce6, is it correct that the reading of this file with the flag --seedstate is no longer relevant and can be removed?

By the way, what is the mechanism to rerun the same event now? It would probably be good to add an example to the manual.

[Laurie Nevay]

Actually, loading one of the old seedstates will still work and set the seed state, although they are no longer produced so it's not a good work flow.

The option is redundant and should be removed.

There isn't anyway currently to rerun an event, although it won't take too long to add.

I propose to create another primary generator action that will generate events based on a root event output file. It would require distrType="recreate", distrFile="somefile.root", ngenerate, event number offset, or selector - ie x>4 - possibly in the future to pick only certain events from file.

At the beginning of each event, the seedstate from that event in the file would be reloaded as part of the primary generator action (possibly through our static functions in BDS::Random or through static interfaces to CLHEP random engines).

We store start of run and start of event seedstates now, so we should be strongly reproducible.

There is a current mechanism (perhaps through globals) for the bunch distribution to signal / hijack the number of events to run, so we can use the same method here.

[Laurie Nevay]

If agreed, I'm happy to do this.

[Jochem Snuverink]

All agreed.

[Laurie Nevay]

This has been mostly implemented and is just under testing in the "recreate" branch. There is currently an issue with have TWO root files open at once. Stewart has taken this over. It will be merged into develop before the next release. This will break any use of previous seed state files.

[Laurie Nevay]

This also presents an issue with combined output, which is currently root + rootevent - the contents are mixed between files / all in one file as I remember. It'd be good if we weren't limited to only using one root file in the whole program at a time.

[Jochem Snuverink]

Hmm that should really work. Running the simpleMachineCombined test seems at first glance to work alright (in develop) with two filled ROOT files (but I haven't looked in them in detail). Maybe we should open a new issue for it?

[Laurie Nevay]

I've implemented strong reproducibility now. The seed state is first changed in BDSPrimaryGenerator action which is actually called by Geant4 before the begin of event action. The seed state is restored here and then coordinates will be restored. This can be stronger reproduction with the rootevent (now default) format where all the options will be restored.