I am using the multithreading mode in a simulation where a single event generate many particles.
In particular, in PrimaryGeneratorAction.cc, a for cycle generate many particles (different position, direction, energy) with ParticleGun. By checking the number of threads running in the cluster(which I am using), only one is running. By increasing the number of events, the number of threads increase accordingly. I observed the same behaviour from the Geant4 examples, that employ a similar strategy to simulate more particles per event.
Is there a way to use many threads for a single event?
As I see, runManager->SetNumberOfThreads(N_THREADS) itself works only if many events are simulated.
Thanks in advance for your time.
Best regards,
No, there isn’t. The G4 run manager is written such that each event is dispatched to one of the worker threads. When that event finishes, another one starts on the thread. There’s no way with G4 out of the box to split up a single event across threads.
I recall that there was an effort in the past to make a GPU-capable version of G4, but I don’t know where that went.
thanks for your answer. Do you have some suggestions, please? Like how to implement the generation of many particles (with different energy, position, direction) as many events generated, in order to use multi-threading mode?
Thanks for your time.
Regards,
Geant4 treats each particle independently: that is, each particle traverses the same geometry, there’s no “heating” or “activation” that affects the passage of other particles, and tracks cannot interact with one another in any way. So instead of generating many particles per event, why not generate one particle per event? You can sum up results from multiple particles in your analysis.
Thanks @mkelsey
I modified the implementation, in order to simulate a different particle per event. I have only one problem.
Since I am working in multi-threading and I’m reading the particle information from an input file, I would like to have the possibility to read the file once to store the information of all particles.
Indeed, with the actual implementation, I read the input file in PrimaryGeneratorAction. In this way, the same file is read as many times as the number of threads.
A solution, that I thought, is to split the input files, in order to have the reading of each input file for each thread. Nevertheless, I would like to know if there is the possibility to read an input file before the call to PrimaryGeneratorAction and to allow PrimaryGeneratorAction to access to the variables (energy, pos. direction) stored in a dedicated class, that I’m already using in the actual implementation.
We do something quite similar in my experiment. My solution was to make the file reader a separate utility class, and make a single instance of it across all threads. That way there’s only thing reading the file sequentially, but the different threads call it individually. Use a mutex in the reader function to avoid thread collisions.
Good question; I don’t know if there’s an example with a global object and mutexes. . . . find examples -name '*.cc'|xargs grep G4Mutex found several instances, including at least a few – advanced/lAr_calorimeter, extended/runAndEvent/RE05, extended/optical/wls, and extended/medical/dna – which appear to be related to primary generators.