The number of threads in Multithread will have a impact on results?

Hello,my program simulating neutron generation first set number of thread 64,after i change it to 20,the yield of neutron decreases.So ,i tried 1,10,30,40 as the number of threads.i find that the yield of neutron will increase along with the increasing of nOfThreads(i change nothing except nOfThreads) .Could told me why?
i use g4root to analysis the raw data and just use histogram to collect data about neutron.

I’m experiencing a very similar thing (G4 version 11.0.1), except my neutron count goes down with thread number. I’ve been trying to work out why this is the case for a while now.

If anyone has any thoughts, ideas or tests that could be done, it’d be very much appreciated.

So when I run the simulation, for example (./Sim mac.mac n), I get different neutron counts from my SD. I’m running a modified radioactive decay/Activation example.

In my simulation, I have a pencil beam of deuterons incident on a G4Box of lithium. Neutrons are produced in which the distribution has a forward bias. These neutrons that enter the SD are counted.

I tried (in MySD.cc)
aStep->IsFirstStepInVolume()
aStep->GetPreStepPoint()->GetPosition()
Track->SetTrackStatus(fStopAndKill) // To see if the primary neutrons are creating new neutrons in the SD.

I sent the neutron count (primary neutrons passing through SD surface) to Run.cc where they are counted. However, the neutron count is always the same. It only differs when I change the thread count using (./Sim mac.mac n) where n is the number of thread I want to use.

Neutron passing through the SD.
1 Thread = 1600746606 neutrons
6 threads = 824725087 neutrons
8 threads = 674259323 neutrons

A peculiarity I found which could be a clue, is that the neutron count doesn’t change when changing the seed in the macro file (/random/setSeed) made to run the simulation, however, other things do change, such as the number of elements and isotopes created.

Can anyone offer any assistance to solving this?
I can provide snippets of code if needed and answer any questions.

Solve it.
I wasn’t merging the hits from each worker thread correctly.
Still not sure what numbers it was spitting out, but I have the correct counts now.

Could you please explain a bit more detailed what was your solution? It would be much appreciated.

Some background
So I’ve been using G4 for a while now, but I’m still learning; I’m completely self taught, including c++. So my solution may be bad, but it worked. Ultimately, the issue was an ignorance of how G4 multithreading worked. To be honest, the concepts still aren’t cemented in my mind.

Originally I was passing hit information (count, Ekin, time) from my sensitive detector to Run:G4Run. I tried a basic counter and map to track the number of hits, but didn’t work. I tried to output to root, but still I had the incorrect neutron count.
I though decay maybe producing neutrons in the SD, so I killed the neutrons the moment they interacted, but nothing changed.
So the I implemented a hits collection, which also didn’t change anything. At this point I thoroughly ruled out that it wasn’t how I was collecting the neutrons. It was at this point I was fairly sure it was the merging of the data from different threads causing the issue; I eliminated what I though could have the easy solutions.

After a lot of coding, this is what I did to solve my issue.
Still using the hits collection, I sent the number of hits from SD::EndOfEvent() to a RunAction counter method I wrote; a simple neutronCount += x counter.
I merged the accumulables via the accumulable manager in RunAction::EndOfRun and obtained the total neutron count for the run.
Using if (isMaster) in RunAction::EndOfRunAction, I then passed that total neutron count to my Run::G4Run via a setter.
Also I wrote: G4ThreadLocal G4Accumulable<G4int> neutronCount = 0; in the RunAction .cc file, underneath the includes but above the methods.
From here I could use the correct neutron count entering the SD.
Also, I’m pretty sure that my other approaches to neutron counting would work now beucase I know how to somewhat handle merging data across worker threads, so I don’t believe the hits collections are necessary; it’s just what I used when I solved the problem first.

The neutron count values I was getting before were spurious.
I’d like to say again, I’m not formally educated in G4 or C++. So my use of coding lingo and my solution very likely aren’t good, but works. I still have a hell of a lot to learn.

1 Like