The Geant4 set of electromagnetic (EM) physics processes and models are used in practically all types of simulation applications including high energy and nuclear physics experiments, beam transport, medical physics, cosmic ray interactions and radiation effects in space. In addition to models for low and high energy EM physics for simulation of radiation effects in media, a sub-library of very low energy models was developed within the framework of the Geant4-DNA project, with the goal of simulating radiation effects involving physics and chemistry at the sub-cellular level.

In the early stages of Geant4, low and high energy EM processes were developed independently, with the result that these processes could not be used in the same run. To resolve this problem, the interfaces were unified so that the standard, muons, highenergy, lowenergy, and dna EM physics sub-packages now follow the same design. Migration to this common design resulted in an improvement of overall CPU performance, and made it possible to provide several helper classes which are useful for a variety of user applications (for example G4EmCalculator).

The electromagnetic processes of Geant4 follow the basic interfaces:

The class diagram is shown in Figure 3.1.

Figure 3.1.  Design of EM physics processes.

These common interfaces for all EM sub-packages enabled the full migration of EM classes to multi-threading without significant modification of existing physics model codes. Initialization of the energy loss, stopping power and cross section tables is carried out only once in the master thread at the beginning of simulation. These tables are shared between threads in run time.

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. t is strongly recommented to use existing processes and not create a new one for each new model. Here is a list of main EM processes:

More processes are provided in lowenergy, polarisation, and adjoint sub-libraries. In some specific cases, interfaces described above are not applicable and the high level interface G4VProcess is used.

Any concrete physics process class may need custom parameters. It is recommended to define following parameters specific to the class in the class constructor:

Any EM process should implement following methods:

Main initialisation of a process is performed by initialisation methods:

In these methods a default set of EM models and their energy intervals of applicability may be defined. It is strongly recommended that a process class cannot change EM parameters in G4EmParameters class or status of the de-excitation module. EM parameters can be modifided in physics lists or via UI commands.

Concrete physics models are implemented via EM model interfaces:

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 Figure 3.2.

Figure 3.2.  Design of EM physics models.

The base class G4VEmModel has a lot of virtual methods mostly with the default implementation. Pure virtual methods to be implemented in each model class are following:

Any model may have its own data structure or physics table. It is optimal to share data between threads in multi-threaded mode. For that at initialisation it is possible to check if initialisation is performed in master thread using a method IsMaster(). In the master thread data of the model should be initilized. A model initialisation may be performed between runs. In that case, potentially materials and cuts may be changed, so re-initialisation of model data should be foreseen. In worker thread it is possible to access shared data implementing virtual method InitialiseLocal(const G4ParticleDefinition*, G4VEmModel* masterModel). It is strongly recommended that a model class cannot change EM parameters in G4EmParameters class or status of the de-excitation module. EM parameters can be modifided in physics lists or via UI commands.