Hi kind folks on the Geant4 forums,
I am currently calling
((G4MTRunManager*)G4RunManager::GetRunManager())->GetNumberOfThreads()
on a thread local instance of my PrimaryGeneratorAction to try and determine the total number of threads active in the current Geant4 program. Regardless of the number of threads which are active, this function is returning 1. I was wondering if this was expected behavior because I am calling this function from a thread local class, or if what I am experiencing is unanticipated behavior.
An obvious solution to this is just to pass the number of threads to the PrimaryGeneratorAction when I construct it – but I was wondering if the above approach might work as well.
Thanks for your help,
Joseph DeCunha
What is your idea about the number of threads? Do you need to record it somewhere?
I was working on creating a primary generator which cooperatively reads particles from a phase space file. For example, if the current Geant simulation was making use of 10 threads, then each thread-local primary generator would read every 10th entry from the phase space file.
For this I needed to know both the current threadID as well as the total number of threads active. However, this ended up being not a great idea because the G4RunManager doesn’t necessarily assign every thread an equal number of tracks to process, which could lead to issues with the design I had in mind.
Indeed. Maybe it is useful to write a custom particle generator for the task.
I use IAEA phase space and roll over the saved set in every thread. It does not seem right in general, but it helps to avoid the thread-locality issues in the IAEA code. It is old and does not even care about threads. Every reader is thread-local, and it may also mutilate the disk IO if threads are too many.
I see that the Geant4 patch notes for version 11.2.1 have been released and state
“Correctly report number of threads from G4TaskRunManager.”
I will check if this solves the problem I was facing.
1 Like