Geant4.10.06.p02 taking a lot of time when processing events

Particles, Track, Event, Run and Biasing
1

After installing geant4.10.06p02, I realized that it takes much more time to process e.g. 100 events with my prefered benchmark application (studying muon production by 18 GeV electron beam on copper dump) respect to geant4.10.06p01.

In particular, running both versions with “time”, I get for geant4.10.06p02

real 19m28,120s
user 19m10,802s
sys 0m0,272s

and for geant4.10.06p01 I get

real 3m22,695s
user 3m15,619s
sys 0m0,214s

So while the sys-time is more or less comparable, user time is much larger for geant4.10.06p02.
I tried on several computers, also with different compiler versions, but the result is always like this.

What could be the reason for this slow-down?

2

Hello,

we do not have such information so far. In our tests CPU per events is not affected. In order to figure out what is going on you may do following:

  • compare printouts at initialisation for two versions and identify all differences
  • try to run $G4INSTALL/examples/extended/hadronic/Hadr01, you need to prepare macro-file with Cu target and muon beam, you may compare both initialisation printout and results for different Physics Lists

VI

3

I compared the printouts of the two versions, and everything seems to be quite similar (physics, ranges in material, etc.). Only big difference is indeed:

Geant4.10.06p01:

Run Summary
Number of events processed : 100
User=207.130000s Real=207.475880s Sys=0.050000s [Cpu=99.9%]

Geant4.10.06p02:

Run Summary
Number of events processed : 100
User=1666.470000s Real=1672.114818s Sys=0.700000s [Cpu=99.7%]

I run also the Hadr01 example with 18 GeV mu- beam on 100cm long copper target with QGSP_BERT - in this case, there is in fact no difference in processing time between the two versions.

In my application, I use QGSP_BERT with EMZ Reference List, and in addition add the “GammaToMuPair”, “muonNuclear” and “photonNuclear” processes. I then add biasing to the processes “GammaToMuPair”, “photonNuclear” and “muonNuclear”.

I ran valgrind with the callgrind option with both versions, and I find that with Geant4.10.06p02, a lot of functions are called 10 times more often than for Geant4.10.06p01. It looks to me as if Geant4.10.06p02 is taking more steps. In particular, the function ‘G4MuBremsstrahlungModel:ComputeDMicroscopicCrossSection(double, double, double)’ is called 420 000 times in Geant4.10.06p02, while it seems to be absent in Geant4.10.06p01. So maybe this can explain the difference. What does this function do?

4

I verifiied that this problem can still be observed in the current version (10.07.p01). What I find is that in my application (18 GeV electrons on a copper beam
dump, modeling a SLAC experiment carried out in 1974), starting with the 10.06.p02 version,
electrons below ~2 MeV would lose energy exclusively via the “msc” process -
and this made the tracking much slower,
because it created much more stepping activity respect to the 10.06.p01-version,
in which low-energy electrons lose energy much quicker through the
“eIon”-process. This is connected to the “Safety” parameter in the stepping
procedure, which is apparently always set to “5.0000000000000003e-10” in
p02 (and following versions), forcing the “msc” to win over the “eIon” process (in p01 versions, this
parameter takes values which seem to be somehow proportional to the particle
energy, and change for the different processes which are probed, but I do
not know what this parameter represents).

The “Safety”-parameter derives from the “proposedSafety”-value, which
seems to be always “0.” in versions >= 10.06.p02. I have not found out yet why this is
the case.

The problem is then that in G4SteppingManager.cc:198

// endpointSafety= std::max( proposedSafety - GeomStepLength, 0.);
endpointSafety= std::max( proposedSafety - GeomStepLength,
kCarTolerance);

with usually “GeomStepLength” > 0., the first expression becomes negative
and “endpointsafety” takes the value of “kCarTolerance” (which is set to
0.5*G4GeometryTolerance::GetInstance()->GetSurfaceTolerance(); in
G4SteppingManager.cc and evaluates to 5.0000000000000003e-10)

Apparently, this does not change the stepping results for the first 100
steps or so (the energy of the primary electron going down from 18 GeV to 2
MeV), but then in line 519 of

processes/electromagnetic/standard/src/G4GoudsmitSaundersonMscModel.cc

there is a condition

if (gIsOptimizationOn && (distance<presafety))

which evaluates to ‘false’ for p02 since “presafety” is always smaller
than “distance”, while it is ‘true’ for p01. This results in a
recalculation of many quantities, to the effect that from now on for every
step, ‘msc’ process seems to win with the shortest steplength.

Discussing with Alberto Ribon and other experts on GEANT4, it was found that
this behavior is triggered by the G4GenericBiasingPhysics.cc-file -
replacing G4GenericBiasingPhysics.cc in geant4.10.07p01 with the one from
geant4.10.06p01 speeds up my calculations considerably, and recovers the
pre-p02 conditions.

I am aware that this file has been updated to fix a bug related to
parallel geometries and generic biasing, and I should preferably use the
most recent one. But since I am apparently one of the few people using both
primitive scorers and generic biasing in my application, this may explain
why I am apparently the only person affected so far by an increase in running
time (we talk about a factor 5-6!).

My question now is whether the fact that the “Safety”-parameter always takes
the value of “5.0000000000000003e-10” is intended behavior, or if this is an
unhappy coincidence which should be rectified?