"offline" replay of only certain events

Recording, Visualizing and Persisting Data
1

Hi everyone,

I want to compute a (very) high number of events on a headless machine, but still benefit from the nice visualization of detector geometry and trajectories in geant4.
Is there a smart and easy way to store certain events (only very few) for an “offline” analysis on a second machine? This would be quite similar to

G4EventManager::GetEventManager()->KeepTheCurrentEvent();

but I would need to capture the full information about the event, store it to disk and be able to retrieve afterwards…
Maybe there is also a better solution for this, via gdml files?
Has anyone implemented a similar use case?

Thank a lot in advance :slight_smile:

2

Mmm. I guess you could /vis/disable and KeepTheCurrentEvent as you mention, then at end of run, /vis/enable, /vis/open VRML2FILE (or one of the other file-writing drivers) and browse them with an appropriate off-line browser, but we don’t have a way of using Geant4 itself as a browser.

I wonder if you could save the seeds of interesting events and re-run them?

3

vrml is definitely a great suggestion, I have yet to find a viewer that is comfortable to handle.
maybe your second suggestion will do, saving the seeds and only replaying the interesting events on the weaker machine :slight_smile:

thanks a lot!

4

follow-up question on the replay: I miraculously managed to get one pair of seed values that allow me to recreate an event which is “interesting”.
However, I can’t reproduce this :smiley:

What I do in the PrimaryGeneratorAction.cc:

G4long fEventSeeds [2] = {56202135, 59145190};
CLHEP::HepRandom::setTheSeeds(fEventSeeds);
fGeneralParticleSource->GeneratePrimaryVertex(anEvent);

In mySD.cc:

const G4long* seeds = G4Random::getTheSeeds();
G4cerr << CLHEP::HepRandom::getTheSeed()
       << " " << seeds[0] << " " << seeds[1] << G4endl;

Problem is: the values are not the same, and differ from program launch to program launch. The event that is simulated however is always the same as expected. Example output:

56202135 -799016928 33

Using these values in any combination does not give me an event that matches the “interesting” criteria (probability around 1/10000)

In my main, the engine is initialized with:

//Choose the Random engine and reset the seed (before the RunManager)
G4Random::setTheEngine(new CLHEP::MixMaxRng);
srand(time(NULL));
G4long seed = uint64_t(time(NULL))*uint64_t(rand());
G4cout << "Random seed: " << seed << G4endl;
CLHEP::HepRandom::setTheSeed(seed);

which explains different values for different time stamps of the program launch, but my expectation would be that after resetting the seeds, this does not matter?!

5

Best let the run manager deal with the seeds. Have a look at the commands /random/.

6

wouldn’t that mean to create a *.rndm file for each event, and copy this file to a unique name on demand? my guess is that would significantly drop performance?!

/random/setSeeds does the same as my code above (but only for the master thread, so the event/seed created in a worker is different). The question remaining was how to extract the correct two numbers for the interesting events afterwards…

New insight: When I “getTheSeeds” from an arbitrary run/event with seeds initialized the regular way, I can extract the seeds for replay correctly from the sensitive detector. After setTheSeeds with these values in the PrimaryGeneratorAction, the event gets correctly replayed, but then “getTheSeeds” value is off.
Using the RunManager to initialize the seeds does not work as expected, probably due to multithreading.
I will keep investigating, if any of you have suggestions or ideas in the meantime I am most thankful :slight_smile:

update: yep! serial run-manager allows /random/setSeeds from the command line to replay an identical event, however the seeds displayed in the event are again different…