Geant4 has two user initialization classes and one user action class whose methods the user must override in order to implement a simulation. They require the user to define the detector, specify the physics to be used, and define how initial particles are to be generated. These classes are described in Section 6.1.
Additionally, users may define any of several optional user actions, to collect data during event generation from steps, tracks, or whole events, to accumulate data during runs, or to modify the state of new tracks as they are created. These user actions are described in Section 6.2.
To support the accumulation of data in the actions mentioned above, users may define subclasses for some of the container objects used during event generation and tracking. These are described in Section 6.3.
Three user initialization class objects are registered with
the run manager (Section 3.4.1.2) in the
user's main()
program, which takes ownership. The user
must not delete these objects directly, and they must be created using
'new'. Within the G4UserActionInitialization
class
(Section 6.1.3), the user must instantiate and register a
concrete G4VUserPrimaryGeneratorAction
subclass, which
generates the primary particles for each event.
Example 6.1.
G4VUserDetectorConstruction
class G4VUserDetectorConstruction { public: G4VUserDetectorConstruction(); virtual ~G4VUserDetectorConstruction(); public: virtual G4VPhysicalVolume* Construct() = 0; virtual void ConstructSDandField() = 0; };
In the Construct()
method, material and geometry has to be descrived.
Detailed discussions on material and geometry are given in Section 2.3
and Section 2.2. Detector sensitivity and electromagnetic field should
be defined in ConstructSDandField()
, as objects defined in this method are
thread-local if they are used in multi-threaded mode. Detailed discussions on
Detector sensitivity and electromagnetic field are given in Section 4.4
and Section 4.3.
The concept of a physics list arises from the fact that Geant4 can not offer a single modeling algorithm to cover the entire energy domain from zero to the TeV scale, for all known processes and particles. Instead, a combination of ideas and approaches is typically used to perform a simulation task.
A schematic view of the Geant4 modeling of the processes of particle passage through matter may be presented as follows:
The "patchwork" concept is especially true in the Geant4 hadronic physics domain: models are valid only over finite energy ranges, and there maybe competing models in the same range or one model maybe working better than the other for a specific group of particles, while its competitor may be better for other species. For this reason models have to be combined to cover the large energy range; every two adjacent models may have an overlap in their validity range.
G4VUserPhysicsList
This is an abstract class for constructing particles and processes. An introduction into the concept of the Geant4 Physics List and the Geant4 Physics Processes is also given in Section 2.5 and further in Section 5.2.
While the fabrication of a physics list is, in principle, a choice of a user, the toolkit is distributed with a number of pre-fabricated physics lists for the convenience of many user applications. These physics lists are supported by the Geant4 development team and can be recommended for specific physics tasks. However, based on the interests and needs of a specific project, a user may want to implement her or his own custom physics list.
The following sections offer several examples that show how to instantiate or select one or another pre-fabricated Physics List from the Geant4 standard collection, as well as guidance composing a custom Physics List from pre-facbricated components or even entirely from scratch.
To view the contents of a Physics List, there are two useful methods: DumpList()
and
DumpCutValueTable(G4int flag)
.
Number of ready to use Physics Lists are available with Geant4 kernel. Below an example of instantiation of FTFP_BERT Physics List class is shown. The full set of reference Physics Lists is described in Geant4 web.
Example 6.2. Creating FTFP_BERT Physics List.
G4int verbose = 1; FTFP_BERT* physlist = new FTFP_BERT(verbose); runManager->SetUserInitialization(physlist);
Geant4 provides a class G4PhysListFactory
allowing
to defined Physics List by its name. The last for characters in the name defines
an electromagnetic (EM) physics options. By default standard EM physics is used,
"_EMV" corresponding to standard option1, "_EMX" - to standard option2,
"_LIV" to EM Livermore physics, "_PEN" - to EM Penelope physics.
Example 6.3. Creating Physics List by name.
G4int verbose = 1; G4PhysListFactory factory; G4VModularPhysicsList* physlist = factory.GetReferencePhysList("FTFP_BERT_EMV"); physlist.SetVerboseLevel(verbose); runManager->SetUserInitialization(physlist);
The class G4PhysListFactory
provides also another interface
allowing to defined Physics List by the environment variable PHYSLIST.
Example 6.4. Creating Physics List by name.
G4int verbose = 1; G4PhysListFactory factory; G4VModularPhysicsList* physlist = factory.ReferencePhysList(); physlist.SetVerboseLevel(verbose); runManager->SetUserInitialization(physlist);
Technically speaking, one can implement physics list in a "flat-out" manner, i.e. specify all necessary particles and associated processes in a single piece of code, as it will be shown later in this document. However, for practical purposes it is often more convenient to group together certain categories and make implementation more modular.
One very useful concept is a Modular Physics List, G4VModularPhysicsList
, that is a sub-class
of G4VUserPhysicsLists
and allows a user to organize physics processes into "building blocks",
or "modules", then compose a physics list of such modules.
The concept allows to group together, at a relatively high level, desired combinations of selected particles and
related processes. One of the advantages of such approach is that it allows to combine pre-fabricated physics
modules that are centrally provided by Geant4 kernel with user's applications.
G4ModularPhysicsList
has all the functionalities as G4VUserPhysicsList
class,
plus several additional functionalities. One of the important methods is RegisterPhysics(G4VPhysicsConstructor* )
for "registering" the above mentioned pre-fabriced physics modules. There also methods for removing or replacing physics modules.
Example below shows how G4VModularPhysList
can be implemented.
Example 6.5. Creating Physics List by name.
MyPhysicsList::MyPhysicsList():G4VModularPhysicsList() { G4DataQuestionaire it(photon, neutron, no, no, no, neutronxs); G4cout << "<<< Geant4 Physics List: MyPhysicsList " <<G4endl; G4cout <<G4endl; defaultCutValue = 0.7*mm; G4int ver = 1; SetVerboseLevel(ver); // EM Physics RegisterPhysics( new G4EmStandardPhysics(ver) ); // Synchroton Radiation & GN Physics RegisterPhysics( new G4EmExtraPhysics(ver) ); // Decays RegisterPhysics( new G4DecayPhysics(ver) ); // Hadron physics RegisterPhysics( new G4HadronElasticPhysicsXS(ver) ); RegisterPhysics( new G4QStoppingPhysics(ver) ); RegisterPhysics( new G4IonBinaryCascadePhysics(ver) ); RegisterPhysics( new G4HadronInelasticQBBC(ver)); // Neutron tracking cut RegisterPhysics( new G4NeutronTrackingCut(ver) ); }
Note that each module to be registered with a Modular Physics List is a G4VPhysicsConstructor
(or a derived object), i.e. a "sublist" that holds groups of particles and accompanying physics processes.
A user can find these and other similar modules in the source/physics_lists/list area of Geant4 core code, and can
combine selected ones with custom modules, if desired.
In order to compose a custom physics module, two mandatory methods of a G4VPhysicsConstructor
must
be implemented: ConstructParticle()
and ConstructProcess()
; beyond that the implementation
can be structured according to the developer's taste.
Another useful concept in the modular approach to composing a Physics List is the concept of so called "builders". This concept allows to encapsulate certain implementation details into smaller-scale software components, and offers the flexibility of re-using those component in different modules. At the general level, the scheme is this:
This concept is widely used through the Geant4 hadronic domain, but the idea would be equally applicable in the electromagnetic area.
All builders can be found in the source/physics_lists/builders directory. There are basically two types of builders:
A particle builder is somewhat "superior" here, as it specifies a particle or a group of particles, what category
of processes are applicable, how to outfit a process with specified model(s), and how processes are to be registered
with the G4ProcessManager
.
A particle-model builder instantiates a given model and implements details of associating it with one or more
processes applicable to a given particle type. Some models can not be instantiated through a single interface class,
but instead they need, in turn, to be composed from several components (examples are QGS and FTF).
Useful example bulders to review and to consider as inspirations can be the following:
One detail to remember is that, in principle, the validity range for a given model can be setup for each particle type individually. But in these referenced applications the validity range is setup to be the same for a group of particles (i.e. for a number of corresponding inelastic hadronic processes). Once a builder is instantiated, one can override the default validity range (via SetMinEnery or SetMaxEnergy methods), but the new value will be, again, given to a group of particles/processes. Also note that the validity range can be overriden only before calling the Build() method of a builder. Again, the approach is just a specifics of this particular implementation. Obviously, if a limited validity range is selected for a specific particle/model/process, one has to supplement another model or several models, to cover the entire range.
One more useful class is the G4PhysicsListHelper
which is a service class that wraps around
the technicalities of the physics process registering in Geant4 and allows a user to easily associate a process
with a particles, without knowing many details about various types of processes (discrete, continuous, etc.) and
their internal ordering with G4ProcessManager
.
Curious users may eventually want to go deeper into details of G4ProcessManager class and, in particular,
its group of AddProcess(...)
methods, as it is the basis of G4PhysicsListHelper implementation.
But for practical purposes, the use of G4PhysicsListHelper is likely to be sufficient in most cases.
Other useful details, including several elements of the software design philosophy and class diagrams, are given in Section 2.5.
The user must
derive a concrete class from G4VUserPhysicsList
and implement three virtual methods:
ConstructParticle()
to instantiate each requested
particle type;ConstructPhysics()
to instantiate the desired physics
processes and register each of them;SetCuts(G4double aValue)
to set a cut value in range
for all particles in the particle table, which invokes the
rebuilding of the physics table.
At early stage of the initialisation of Geant4 the method
ConstructParticle()
of
G4VUserPhysicsList
is invoked.
The ConstructProcess()
method must always invoke the
AddTransportation()
method in order to insure particle
transportation. AddTransportation()
must never be
overridden. This is done automatically if G4VUserPhysicsList
inherits of G4VModularPhysicsList
. It is recommended for
users as the most robust interface to Physics List. Geant4 examples demonstrate
different methods how to create user Physics List.
All user action classes must be defined through the protected method
SetUserAction()
.
Build()
methos should be used for defining user action classes
for worker threads as well as for the sequential mode. BuildForMaster()
should be used only for defining UserRunAction for the master thread.
BuildForMaster()
is not invoked in the sequential mode.
In case the user uses his/her own SteppingVerbose
class,
it must be instantiated in the method InitializeSteppingVerbose()
and returned.
G4VUserActionInitialization
Example 6.6.
G4VUserActionInitialization
class G4VUserActionInitialization { public: G4VUserActionInitialization(); virtual ~G4VUserActionInitialization(); public: virtual void Build() const = 0; virtual void BuildForMaster() const; virtual G4VSteppingVerbose* InitializeSteppingVerbose() const; protected: void SetUserAction(G4VUserPrimaryGeneratorAction*) const; void SetUserAction(G4UserRunAction*) const; void SetUserAction(G4UserEventAction*) const; void SetUserAction(G4UserStackingAction*) const; void SetUserAction(G4UserTrackingAction*) const; void SetUserAction(G4UserSteppingAction*) const; };
G4VUserPrimaryGeneratorAction
Example 6.7.
G4VUserPrimaryGeneratorAction
class G4VUserPrimaryGeneratorAction { public: G4VUserPrimaryGeneratorAction(); virtual ~G4VUserPrimaryGeneratorAction(); public: virtual void GeneratePrimaries(G4Event* anEvent) = 0; };