RunInitialization shouldn’t be called directly into the kernel anyway. G4RunManager::GetRunManager()->Initialize() is much preferred.
If you take this out of your C++ code (probably a good idea), then you will need to put it into your macro file, immediately before /run/beamOn:
[... all your macro configuration stuff ...]
/run/initialize
/run/beamOn 1000000 # Or however many events
If you do multiple runs in a single job, you don’t have to repeat the /run/initialize each time; the RunManager will do it if anything (like geometry) has been changed.
You should have found this, or something like it, in the examples. I just checked, and all of the basic/B* examples have it in their run.mac files. They don’t do the direct C++ call at all.
Thanks mkelsey
I do have /run/initialize in my macro file
I think the generator UserAction is automatically trying to build angular distribution and cross-section for particles of any type for any material to be used in an actual run later in sequence. So it takes the first particle and runs the physics process for that particle by building a dummy volume and determines angular scattering histograms and then moves on to the next material and then the particle and so on sequentially.
And between each set of sequences it puts geant4 into idle state, rebuilds the new geometry and changes particle if it has to and then calls the runinitialize process to reset the cut tables and couples.
It appears to work for other particles like gamma or neutron but fails for optical photons as in my case without scintillation but just Rayleigh. But yes removing that line does work and I was wondering the implications of that.
And for tutorials - I was specifically looking for it as suggested by the tool book guide that says run initialization can be used for custom runs when geometry is changed but I cannot find any details or references to it. I will look up the examples you have suggested.
Oh! That doesn’t seem right. You said this is Gamos, not plain G4? I think this may be the point where you have to get their help to fix whatever is wrong. Changing the physics tables after the run has already been initialized (i.e., in the primary generator) sounds like a recipe for problems.
Yes I have posted it on GAMOS forum.
So what is a way if one needs to change the table because geometry has changed (material has changed and likely the particle also changed) between each ‘set’ of runs (e.g., one set is 10000 events and 200 runs for each particle and material)? Should I call ‘initialize’ again for every new set?
How can I do this in C++ loop in a UserAction rather than in a .mac or .in script? When I look up Custom runs - this RunInitialization is the only method I have access to isn’t it?
Thanks
Briefly, if the geometry changes, then the geometryHasChanged flag should get set; that triggers the next /run/initialize to rebuild the geomery. It also triggers the next /run/beamOn to automatically call /run/initialize so you don’t have to. Once the run has started, all that automatic stuff is past.
There is a way to trigger rebuilding the physics tables separately, but I’m not finding it right now. I think the flag is “physicsHasChanged”, but I’m not 100% sure.