Event¶
Representation of an event¶
G4Event represents an event. An object of this class contains all
inputs and outputs of the simulated event. This class object is
constructed in G4RunManager and sent to G4EventManager. The
event currently being processed can be obtained via the
getCurrentEvent() method of G4RunManager.
Structure of an event¶
A G4Event object has four major types of information. Get methods
for this information are available in G4Event.
- Primary vertexes and primary particles
Details are given in Event Generator Interface.
- Trajectories
Trajectories are stored in G4TrajectoryContainer class objects and the pointer to this container is stored in
G4Event. The contents of a trajectory are given in Trajectory and Trajectory Point.- Hits collections
Collections of hits generated by sensitive detectors are kept in
G4HCofThisEventclass object and the pointer to this container class object is stored inG4Event. See Hits for the details.- Digits collections
Collections of digits generated by digitizer modules are kept in
G4DCofThisEventclass object and the pointer to this container class object is stored inG4Event. See Digitization for the details.
Mandates of G4EventManager¶
G4EventManager is the manager class to take care of one event. It is
responsible for:
converting
G4PrimaryVertexandG4PrimaryParticleobjects associated with the currentG4Eventobject toG4Trackobjects. All ofG4Trackobjects representing the primary particles are sent toG4StackManager.Pop one
G4Trackobject fromG4StackManagerand send it toG4TrackingManager. The currentG4Trackobject is deleted byG4EventManagerafter the track is simulated byG4TrackingManager, if the track is marked as “killed”.In case the primary track is “suspended” or “postponed to next event” by
G4TrackingManager, it is sent back to theG4StackManager. SecondaryG4Trackobjects returned byG4TrackingManagerare also sent toG4StackManager.When
G4StackManagerreturnsNULLfor the “pop” request,G4EventManagerterminates the current processing event.invokes the user-defined methods
beginOfEventAction()andendOfEventAction()from theG4UserEventActionclass. See User Information Classes for details.
Stacking mechanism¶
G4StackManager has three stacks, named urgent, waiting and
postpone-to-next-event, which are objects of the G4TrackStack
class. By default, all G4Track objects are stored in the urgent
stack and handled in a “last in first out” manner. In this case, the
other two stacks are not used. However, tracks may be routed to the
other two stacks by the user-defined G4UserStackingAction concrete
class.
If the methods of G4UserStackingAction have been overridden by the
user, the postpone-to-next-event and waiting stacks may contain
tracks. At the beginning of an event, G4StackManager checks to see
if any tracks left over from the previous event are stored in the
postpone-to-next-event stack. If so, it attempts to move them to the
urgent stack. But first the PrepareNewEvent() method of
G4UserStackingAction is called. Here tracks may be re-classified by
the user and sent to the urgent or waiting stacks, or deferred again
to the postpone-to-next-event stack. As the event is processed
G4StackManager pops tracks from the urgent stack until it is
empty. At this point the NewStage() method of
G4UserStackingAction is called. In this method tracks from the
waiting stack may be sent to the urgent stack, retained in the
waiting stack or postponed to the next event.
Details of the user-defined methods of G4UserStackingAction and how
they affect track stack management are given in
User Information Classes.