Physics Processes

Design Philosophy

The processes category contains the implementations of particle transportation and physical interactions. All physics process conform to the basic interface G4VProcess, but different approaches have been developed for the detailed design of each sub-category.

For the decay sub-category, the decays of all long-lived, unstable particles are handled by a single process. This process gets the step length from the mean life of the particle. The generation of decay products requires a knowledge of the branching ratios and/or data distributions stored in the particle class.

The electromagnetic sub-category is divided further into the following packages:

  • standard: handling basic properties for electron, positron, photon and hadron interactions,

  • lowenergy: providing alternative models extended down to lower energies than the standard package,

  • dna: providing DNA physics and chemistry simulation,

  • highenergy: providing models for rare high energy processes,

  • muons: handling muon interactions and energy loss propagator,

  • adjoint: implementing reverse Monte Carlo approach,

  • xrays: providing specific code for x-ray physics,

  • optical: providing specific code for optical photons,

  • utils: collecting utility classes used by the above packages.

It provides the features of openness and extensibility resulting from the use of object-oriented technology; alternative physics models, obeying the same process abstract interface, are often available for a given type of interaction.

For hadronic physics, an additional set of implementation frameworks was added to accommodate the large number of possible modelling approaches. The top-level framework provides the basic interface to other Geant4 categories. It satisfies the most general use-case for hadronic shower simulations, namely to provide inclusive cross sections and final state generation. The frameworks are then refined for increasingly specific use-cases, building a hierarchy in which each level implements the interface specified by the level above it. A given hadronic process may be implemented at any one of these levels. For example, the process may be implemented by one of several models, and each of the models may in turn be implemented by several sub-models at the lower framework levels.

The hadronic sub-category is divided into the following packages:

  • management: providing the top level hadronic process classes;

  • cross_sections: providing inelastic and elastic cross sections for hadron-nucleon, hadron-nucleus and nucleus-nucleus interactions; it also contains inelastic cross sections for gamma- and lepto-nuclear interactions;

  • models: providing hadronic final-state models; there is a further sub-level, corresponding to each model (abla, abrasion binary_cascade, cascade, coherent_elastic, de_excitation, em_dissociation, fission, im_r_matrix, inclxx, lend, lepto_nuclear, management, parton_string, pre_equilibrium, qmd, quasi_elastic, radioactive_decay, rpg, theo_high_energy, util);

  • processes: providing the in-flight hadronic physics processes: inelastic, elastic, capture and fission;

  • stopping: providing the nuclear capture of hadrons and muon at rest;

  • util: collecting utility classes used by the above packages.

Class Design

General

The object-oriented design of the generic physics process G4VProcess and its relation to the process manager is shown in Fig. 5. Fig. 6 shows how specific physics processes are related to G4VProcess.

class diagram

Fig. 5 Management of Physics Processes

class diagram

Fig. 6 Management of Physics Processes

Electromagnetic

The electromagnetic (EM) processes of Geant4 follow the basic interfaces:

  • G4VEnergyLossProcess;

  • G4VEmProcess;

  • G4VMultipleScattering.

The class diagram is shown in Fig. 7.

Class diagram

Fig. 7 Design of EM physics processes.

These base classes provide all management work of initialisation of processes, creation and filling of physics tables, and generic run-time actions. Concrete process classes are responsible for the initialisation of parameters and defining the set of models for the process. In some specific cases these interfaces are not applicable and the high level interface G4VProcess is used.

Concrete physics models are implemented via EM model interfaces:

  • G4VEmModel;

  • G4VMscModel.

In the majority of use-cases when new EM physics is needed, it is enough to create only a new model class and use it in the existing EM process class. A new model may be added to an existing process using AddEmModel(G4int, G4VEmModel*, G4Region*) method. The class diagram is shown in Fig. 8.

Class diagram

Fig. 8 Design of EM physics processes.

Hadronic

The hadronic physics of Geant4 has been designed to allow three basic types of modelling: data-driven, parameterisation-driven, and theory-driven. Five implementation frameworks have been used to allow great flexibility in these modelling approaches. An overview of the first two framework levels will be given here (for a wider and more detailed coverage please refer to the next Chapter).

The top-level framework defines the hadronic processes, and provides the basic interface to other Geant4 categories. All processes have a common base-class G4VProcess, from which a set of specialised classes are derived. Two of them are used as base classes for hadronic processes for particles (G4VDiscreteProcess), and for processes like radioactive decay that can be both in-flight or at-rest (G4VRestDiscreteProcess). Each of these classes declares two types of methods: one for calculating the time to interaction (for at-rest processes) or the physical interaction length (for in-flight processes), allowing tracking to request the information necessary to decide on the process responsible for final-state production.

Note on at-rest processes: starting with Geant4 version 9.6 - when the Bertini and Fritiof final-state models have been extended down to zero kinetic energy and used also for simulating the nuclear capture at-rest - the at-rest processes derive from G4HadronicProcess, hence from G4VDiscreteProcess, instead than from G4VRestProcess as in the initial design of at-rest processes. This requires some adaptation a discrete process to handle an at-rest one using top level interface G4VProcess. A different solution, under consideration but not yet implemented, would be instead to have G4HadronicProcess inheriting from G4VRestDiscreteProcess: in this way, G4HadronicProcess, and therefore any theory-driven final-state model, could be deployed for any kind of hadronic process, including capture-at-rest processes and radioactive decays.

The class diagram is shown in the Fig. 9.

../../_images/Level11.jpg

Fig. 9 First level implementation framework of the hadronic category of Geant4.

Whenever possible, it is preferable to add any new hadronic physics to Geant4 in terms of a model, and assign the model to an existing process, rather than develop a new, specific process. However, in some cases, a directly implemented hadronic process may be necessary. In these cases, the new process must derive from G4HadronicProcess and the following three methods must be implemented:

virtual G4VParticleChange* PostStepDoIt(const G4Track&, const G4Step&) ,
virtual G4bool IsApplicable(const G4ParticleDefinition&) ,
G4double GetMeanFreePath(const G4Track& aTrack, G4double, G4ForceCondition*) .

More details on these methods will be provided in the next Chapter.

At the next level of abstraction, only processes that occur for particles in flight are considered. For these, the main design requirement is to treat cross sections and the final-state models (i.e. the models responsible for the production of the secondaries) independently, so that it is possible to change cross section while keeping a particular final-state model, or, vice versa, to keep a given cross section while replacing the final-state model. Moreover, a set of cross sections can be used for a single hadronic process to cover a wide kinematical range (e.g. from thermal energies up to several tera-electronvolts of the projectile kinetic energy). Similarly, for the same reason, a set of different final-state models can be used for a single hadronic process, allowing the overlapping between two models in an interval of the projectile kinetic energy, to insure a smooth transition between these models.

The class diagram for hadronic cross-sections is shown in Fig. 10 and in Fig. 11 for final-state models.

Implementation framework.

Fig. 10 Second level implementation framework of the hadronic category of Geant4: cross-section aspect.

Implementation framework.

Fig. 11 Second level implementation framework of the hadronic category of Geant4: final-state production aspect.

Each hadronic process is derived from G4HadronicProcess, which holds a list of “cross section data sets”. All cross section data set classes are derived from the abstract class G4VCrossSectionDataSet. The process stores and retrieves the data sets through a data store that acts like a FILO (First-In-Last-Out) stack. Details on how to write a new hadronic cross section set will be provided in the next Chapter.

The G4HadronicProcess class provides a registration service for classes deriving from G4HadronicInteraction, and delegates final-state production to the applicable model. Models inheriting from G4HadronicInteraction can be restricted in applicability in projectile type and energy, and can be activated/deactivated for individual materials and elements. Details on how to write a new hadronic final-state model will be provided in the next Chapter.