Original proposal :

Discussion on the proposed Review of key EM code
J. Apostolakis, D. Elvira, Krzysztof Genser
Wed 10 April 2013

  • Focus is on processes important to physics and computing performance of LHC, Intensity Frontier experiments.
  • Goal of this document is to define scope of work

Potential approaches / topics
- Language - including C++ 11 (is this relevant)
- Class structure, ..
- Physics algorithms - weaknesses
- Review algorithms
- Improve implementation of GouldsmithSanderson model

- What is the key target ? Sequential ; multi-threaded ; GPU/vector prototype
> First put sequential. Identify issues relevant for MT and Parallel versions (at the same time or within short-term horizon.)

Potential topics for future (beyond 'review')
- Implement alternative model

Potential team members
Krzysztof Genser
John Apostolakis
Potential person from OSCR

  • Stability and performance of current Multiple Scattering
  • Alternative approaches

Previous review
- External and not adversarial
- Recommendations: some can be followed, others not
Start points ?
- KLG: understand the algorithms & physics
=> propose a list of things to improve

Potential short term goals - a proposal
- Review design and implementation of key classes * language & class structure * identify areas of potential improvement for correctness, performance, maintainability and adaptability
- Review multiple scattering model implementation
- Identify issues or potential improvements from moving to C++11
( Expect slow adoption of C++11 features in Geant4 - likely none in 2013, some in 2014. Should clarify this with Gabriele, Makoto. )
- Identify concerns for Multi-Threading (performance, correctness, … )
- Identify potential issues for Vector and/or GPU prototypes

List of relevant classes - first inspection

Model and process classes ( key targets are in bold )
G4VEmProcess, G4VEmModel,
G4VMscModel, G4UrbanMscModel95, G4UrbanMscModel (latest ref tag)
G4VMultipleScatering, G4eMultipleScattering (Process)
G4Bremstrahlung, G4eBremsstrahlungModel, G4eBremsstrahlungRelModel

Utility classes: (discussed this new idea with Vladimir Iv. He is positive)
G4PhysicsVector and its derived classes: can we replace the existing implementation with one which:
- is more performant - potentially by avoiding use of inheritance
- is adapted to the needs for multi-threading (today's 'pattern' leads to use ThreadLocal storage at each call - proposed to revise the design so that each thread requests a 'cache' object from the PhysicsVector, and subsequently uses this. The Physics Vector would become constant.)

Follow up Summary (by Krzysztof)

We shall:
.) initially concentrate on the performance aspects of the code
.) flag difficult to understand code fragments as candidates for restructuring

.) the initial list of classes to look at would be:

G4PhysicsVector, esp ComputeValue
G4PhysicsLogVector, esp FindBinLocation

G4VProcess, esp SubtractNumberOfInteractionLengthLeft

G4VEmProcess, esp PostStepGetPhysicalInteractionLength,

G4VEnergyLossProcess esp PostStepGetPhysicalInteractionLength,
AlongStepDoIt, GetLambdaForScaledEnergy

G4VMultipleScattering esp AlongStepDoIt,

G4VEmModel, G4VMscModel,
G4UrbanMscModel95, G4UrbanMscModel, esp ComputeGeomPathLength,
ComputeTruePathLengthLimit, SampleCosineTheta

We shall skip previously mentioned G4eBremsstrahlung at least for now.

Soon afterwards suggested that we should come up with a specific
application like e.g. SimplifiedCalo which we could give to an ASCR
person to investigate with the idea to concentrate on the above list
of classes/functions.

Does it represent what we said? Do you agree with Soon suggestion? Have another
one? Where would you like to put the above text?