DDG4 Manual

5 Higher Level Components

Layered components, which base on the general framework implement higher level functionality such as the handling of Monte-Carlo truth associations between simulated energy deposits and the corresponding particles or the generic handling of input to the simulation.

To generalize such common behavior it is mandatory that the participating components collaborate and understand the data components they commonly access. The data model is shown in Figure 10.

Please note, that this data model is by no means to be made persistent and used for physics user analysis. This model is optimized to support the simulation process and the necessary user actions to handle MC truth, to easily and relatively fast look up and modify parent-daughter relationships etc. This choice is based on the assumption, that the additional overhead to convert particles at the input/output stage is small compared to the actual resource consumption of Geant4 to simulate the proper detector response. On the other hand this choice has numerous advantages:

• Accepting the fact to convert input records allows to adapt DDG4 in a simple and flexible manner to any input format. Currently supported is the input from raw LCIO files, StdHep records using LCIO and ASCII files using the HEPEvt format.
• Similarly as for the input stage, also the output format can be freely chosen by the clients.
• No assumptions was made concerning the structure to store information from energy deposits. Any information extract produced by the sensitive actions can be adapted provided at the output stage the proper conversion mechanism is present. The sensitive detectors provided by DDG4 are optional only and by no means mandatory. User defined classes may be provided at any time. Appropriate tools to extract MC truth information is provided at the output stage.
• The modular approach of the action sequences described in 3.4 allows to easily extend the generation sequence to handle multiple simultaneous interactions, event overlay or spillover response very easily ³

In section 5.1 the generic mechanism of input data handling is described.
In section 5.3 the MC truth handling is discussed.
In section 6 we describe the output mechanism.

5.1 Input Data Handling

Input handling has several stages and uses several modules:

• First the data structures Geant4PrimaryEvent, Geant4PrimaryInteraction and Geant4PrimaryMap are initialized by the action Geant4GenerationActionInit and attached to the Geant4Event structure.
• The initialization is then followed by any number of input modules. Typically each input module add one interaction. Each interaction has a unique identifier, which is propagated later to all particles. Hence all primary particles can later be unambiguously be correlated to one of the initial interactions. Each instance of a Geant4InputAction creates and fills a separate instance of a Geant4PrimaryInteraction. In section 5.2 the functionality and extensions are discussed in more detail.
• All individual primary interactions are then merged to only single record using the Geant4InteractionMerger component. This components fills the Geant4PrimaryInteraction registered to the Geant4Event, which serves as input record for the next component,
• the Geant4PrimaryHandler. The primary handler creates the proper G4PrimaryParticle and G4PrimaryVertex objects passed to Geant4. After this step all event related user interaction with Geant4 has completed, and the detector simulation may commence.

All modules used are subclasses of the Geant4GeneratorAction and must be added to the Geant4GeneratorActionSequence as described in 3.4.

An object of type Geant4PrimaryEvent exists exactly once for every event to be simulated. The empty Geant4PrimaryEvent is created by the Geant4GenerationActionInit component. All higher level components may then access the Geant4PrimaryEvent object and subsequently an individual interaction from the Geant4Context using the extension mechanism as shown in the following code: /// Event generation action callback  
void SomeGenerationComponent::operator()(G4Event* event)  {  
  /// Access the primary event object from the context  
  Geant4PrimaryEvent* evt = context()->event().extension<Geant4PrimaryEvent>();  
  /// Access the container of interactions  
  const std::vector<Geant4PrimaryEvent::Interaction*>& inter = evt->interactions();  
  /// Access one single interaction to be manipulated by this component  
  Geant4PrimaryInteraction* evt->get(m_myInteraction_identifier);  
  ....

Please note: To keep components simple, each component should only act on one interaction the component has to uniquely identify. The identification may be implemented by e.g. an access mask passed to the component as a property.

5.2 Anatomy of the Input Action

One input action fills one primary interaction. Geant4InputAction instances may be followed by decorators, which allow to to smear primary vertex (Geant4InteractionVertexSmear) or to boost the primary vertex Geant4InteractionVertexBoost and all related particles/vertices.

Please note, that a possible reduction of particles in the output record may break this unambiguous relationship between ”hits” and particles. ......

5.3 Monte-Carlo Truth Handling

As any other component in DDG4 , the was designed using the plugin mechanism ie. the default implementation which was inspired by the original implementation of the MC thruth handler developed by the Linear Collider community may easily be overloaded.

The Monte-Carlo thruth handler takes care that

• the proper MC particles are associated with the corresponding hits and tracks.
• To compress the particle record. Geant4 creates a large amount of temporary particles in particluar in dense areas of the detector such as calorimeters. In calorimeters however, the hits within a confined volume should be assigned to the incoming track. In addition a track is only supposed to be kept if it satisfies certain criteria.

To achieve this functionality the Monte-Carlo thruth handler implemented in the class Geant4ParticleHandler firstly

• implements the interface Geant4MonteCarloTruth which gets called whenever an interaction occurs in a sensitive volume which is modeled by an instance of a instance of Geant4SensitiveAction.
• to properly manager the MC particle records the Geant4ParticleHandler either inherits or uses the callbacks provided by the DDG4 interfaces to the
  • Geant4GeneratorAction
  • Geant4EventAction
  • Geant4TrackingAction
  • Geant4SteppingAction.

  While the response of one track is simulated, all relevant information is extracted in the callbacks and at the end of the simulation of the track response a decision is taken whether to store the information of the Geant4 track in the MC particle record or not.

• A Geant4 track is saved in the MC track record if
  • the track did not intercat with the detector, but is part of the Monte-Carlo record originating from the original generator consisting of quarks, leptons, gluons, gammas etc.
  • the track was declared to Geant4 as a Geant4 primary track from the generator action. These are either long-living remnants of the underlying hard interaction of particles decaying macroscopically inside the experiment volume like e.g. B-mesons.
  • the track exits the world volume.
  • the track is mother particle to secondaries.
  • the track created a hit in a ”tracker”-type sensitive volume.
  • the track is above a certain energy threshold and has at least one associated hit either in a calorimter-type volume of a tracker-type volume.

  For all tracks purged from the MC particle record, any resulting energy deposit is associated to the last parent particle stored in the MC particle record.

• To fine-tune the Monte-Carlo truth handler in DDG4 a use class with interface Geant4UserParticleHandler may be supplied, which allows to customize and fine tune if a given MC particle is supposed to be kept in the final record or not. This user class receives the identical callbacks as the truth handler, but at the end of the simulation of each track (the end-tracking-action) a call is issued by the truth handler and allows to override the decision whether to keep or dismiss storing a track.

As mentioned above this implementation is only an example how to realize such a Monte-Carlo truth logic. It is assumed that the interface Geant4ParticleHandler together with the easy-to-use subscription mechanism to all callbacks provided by Geant4 allow to easily implement other Monte-Carlo truth mechanisms.

The following table shows all properties accepted by the DDG4 Monte-Carlo truth handler.