Geant4 EM Physics Code Review Weekly Phone Meeting


Date: January 10, 2014 at 10.00 AM US CST (Fermilab local time)
Place: 1-866-740-1260 (ReadyTalk line) (Host : Krzysztof)


Andrea Dotti
Krzysztof Genser
Soon Yung Jun


(Summary by Krzysztof)

Krzysztof reported on his work related to G4UrbanMscModel and G4PhysicsVector in g4.10.0

Inlined several shorter functions of G4UrbanMscModel:

ComputeTheta0(double, double)
SimpleScattering(double, double)

The g++ compiler inlined all but the last two.
(despite using -Winline no reason behind the compiler decision was revealed)

(Also looked at other short functions in the EM or related classes of interest, e.g.
StartTracking in G4VProcess, G4VEmProcess, G4VMultipleScattering, G4Transportation,
G4VEnergyLossProcess, but they did not inline; MP points out those calls are virtual so this is why)

The inlining functions of G4UrbanMscModel resulted in ~1.5% CPU savings as measured by Soon.
The functions themselves wee contributing about that much to the CPU usage, so this is quite a
significant result.

While looking at G4UrbanMscModel functions one notes many numeric literals, some of them
of a different type than the resulting expression types, e.g. in SampleCosineTheta.

(Is using two different exp functions in UpdateCache intentional?
G4double w = G4Exp(lnZ/6.) and G4double Z13 = std::exp(lnZ/3.) )

Regarding G4PhysicsVector, repeated the work of introducing G4xyd helper class in the context
of g4.10.0, similar to what was done in the g4.9.6.r07 case

In the case of g4.10.0 did not seem to have any measurable effect as measured on Krzysztof workstation.

While looking at G4PhysicsVector and classes inheriting from it, the following was noted:

The FindBinLocation function became non virtual, implemented at the base class level only,
with its behavior controlled by the derived class type G4PhysicsVectorType enum.
It was also inlined and the compiler did inline it. This may at least partially explain
the lack of speed up when using the new helper class (the previous change also involved inlining
FindBinLocation and using std::lower_bound in some of them, but the function was virtual and the
compiler did not inline it.)

We are slightly puzzled by the G4PhysicsLogVector & G4PhysicsLnVector classes though.
Both of them seem to be using the new G4Log (equivalent to std::log) and seem to be equivalent in

However, the constructor G4PhysicsLnVector::G4PhysicsLnVector(G4double theEmin,
G4double theEmax, size_t theNbin)
type = T_G4PhysicsLnVector;

whereas the other two G4PhysicsLnVector constructors use T_G4PhysicsLogVector
and the FindBinLocation is testing for T_G4PhysicsLogVector, not T_G4PhysicsLnVector
and defaults to a binary search if the type is not G4PhysicsLogVector or

We may want to point out that this type of approach makes this code more difficult to
maintain as one needs to remember to update all the places where the enum is used
and is more error prone.

Andrea pointed out that G4PhysicsVector::Value takes a bigger fraction of the CPU in the MT case.
And suggested that one may be able to mitigate it by using cashed values of some of the "edge" bins.


Follow up on the remaining action items from December 20th meeting

Krzysztof will start drafting the report.

Next meeting: January 17 at 9:15 CST (unless we find a better time)