I am building and running in purely sequential mode (GEANT4_BUILD_MULTITHREADED=OFF). At some intermediate event during a run, I start getting a cascade of warning messages (from G4ChordFinder) which don’t stop, and don’t let the job progress. The way I used to debug this problem was to identify which event was problematic (let’s say event #87), and then I could do something like
and get just my problematic event with high verbosity. But right now, using G4 10.03.p03, this no longer works. If I try to run the problematic event as the first event in a new run, it ends up with completely different activity, meaning that a different random seed started the event.
I know that random seeding is quite different in MT mode, but I thought this should still work in Sequential. Has something changed in 10.3 and later to change this?
Hi Mike, nothing has changed in this respect regarding seeding. In sequential mode this is totally under your control.
If the simulation history diverges and you cannot reproduce the same event, it is certainly not due to the seeding (unless you use your own seeding), but rather to other causes … uninitiated variables or else. You could try running Valgrind on your application and see what’s going on; it might give you some hints!
Thanks, Gabriele. That’s what I was afraid of
We do provide our own seeding in the application, but I’m not using it in this case.
I will try using Valgrind, which I have installed on my MacBook, but because we link against ROOT for our app (we save out more complex data structures than G4analysis can handle), the output is usually filled with spurious, or at least unfixable, reports.
Hmmm. Valgrind seems to be unhappy (on my MacBook) – if I launch my application with a macro input, it gets stuck right after instantiating the physics list. If I launch without a macro (to get the PreInit> prompt), valgrind segfaults. Argh