Event

Design Philosophy

In high energy physics the primary unit of an experimental run is an event. The same concept is also known in other fields as history. We retain the name from the HEP community. An event consists of a set of primary particles, and a set of detector responses to these particles.

In Geant4, objects of the G4Event class are the primary units of a simulation run. Before the event is processed, it contains primary vertices and primary particles produced by a generator (a concrete implementation of a G4VPrimaryGenerator). After the event is processed, it may also contain hits, digitisations, and optionally, trajectories generated by the simulation and additional user information (a sub-class of G4VUserEventInformation). The event category manages events and provides an abstract interface to the external generators.

G4Event and its content vertices and particles are independent of other classes. This isolation allows Geant4-based simulation programs to be independent of specific choices for physics generators and of specific solutions for storing the “Monte Carlo truth”. G4Event avoids keeping any transient information which is not meaningful after event processing is complete. Thus the user can store objects of this class for processing further down the program chain. For performance reasons, G4Event and its content classes are not persistent. Instead the user must provide the transient-to-persistent conversion.

The current event being simulated is managed by G4EventManager, a singleton responsible of handling the simulation of the event. The tracks being followed for the current event are stored in a stack managed by G4StackManager. Different stacks allow for fine control of the simulation (urgent, waiting and postponed stacks).

User hooks allow for a customisation of the simulation behaviour via G4UserEventAction, G4UserStackingAction and G4VUserEventInformation.

Event generation is performed via a concrete implementation of a G4VPrimaryGenerator class. This is usually instantiated by the user in the user-defined concrete implementation of G4VUserPrimaryGeneratorAction (belonging to the run category). Geant4 provides three concrete implementation of G4VPrimaryGenerator: G4ParticleGun, a simple generator that can shoot one or more primaries; G4HEPEvtInterface, specifically designed for HEP experiments to read /HEPEVT/ common block format; and the G4GeneralParticleSource able to generate primaries distributed according to complex and configurable distributions. This last possibility is described in detail in the Application Developers Guide.

Class Design

  • G4Event - this class represents an event. It is constructed and deleted by G4RunManager or its derived class.

  • G4EventManager - this class controls an event. It must be a singleton and should be constructed by G4RunManager.

  • G4TrajectoryContainer - this class can contain the concrete G4VTrajectory objects defined by user or used to display the current event.

  • G4UserEventAction - the abstract base class to allow for a user to inject code at the beginning and end of an event.

  • G4UserStackingAction - the abstract base class to allow for the user to control and tune the stacking of particles. See documentation in class and Geant4 examples.

  • G4StackManager - controls the stacks of tracks belonging to the event currently being processed. The three stacks are: urgent, waiting and postponed. The first is of type G4SmartTrackStack while the other two are of the simple G4TrackStack type.

  • G4VPrimaryGenerator - the abstract base class of all of primary generators. This class has only one pure virtual method, GeneratePrimaryVertex(), which takes a G4Event object, generates a primary vertex and associates primary particles with the vertex.

UML class diagrams for classes related to the event and event generator classes are shown in Fig. 3.

Class diagram

Fig. 3 Event Category UML Diagram. Classes in grey are to be sub-classed by user.