MCTRUTH using HepMC
This example demonstrates a mechanism for Monte Carlo truth handling using HepMC as the event record. The user does not interact directly with the HepMC classes but with the MCTruthManager class which takes care with storing all the necessary information about particles, vertices and relations between them. A specialized tracking action is used to test whether given particle is to be stored or not. The decision criteria for storing particle are configurable via the MCTruthConfig class.
% your_binary_directory/mctruthex
The main element of the MC truth handling machinery is the MCTruthManager class. This class is responsible for all the interaction with the HepMC event and does not depend on Geant4. It is a singleton, therefore it is guaranteed to be instanciated only once and the static 'GetInstance' method allows to access it from anywhere in the code. It contains methods like MCTruthManager::NewEvent() to start a new event, MCTruthManager::AddParticle() to add particle to the current event, as well as MCTruthManager::PrintEvent() for the purpose of the debugging. The core of the algorithm which deals with building up the MC truth event tree within the HepMC event is implemented in MCTruthManager::AddParticle() method.
The MCTruthManager::AddParticle() method is called with the following arguments: four-momentum, production position and 'end' position of the particle, PDG code of the particle, as well as the particle ID (unique identifier, as we will see later, corresponding to Geant4 TrackID) and the ID of the mother. Finally, there is a boolean flag specifying whether the direct mother of the given particle has been stored, or not.
The first step, which always takes place, is to instanciate a new HepMC::GenParticle with the barcode corresponding to particle ID, as well as to instanciate a new HepMC::GenVertex which will represent the 'end' vertex of the particle. The barcode of the 'end vertex' is equal to minus the barcode of the particle.
We can now distinguish several cases:
This concludes the description of MCTruthManager. The MCTruthConfig class is a collection of criteria (minimal energy, PDG, creator process, etc) that we want to apply when deciding whether to store or not given particle. These values are used by the 'MCTruthTrackingAction' which we describe below. This class can certainly be extended with other members.
The actual Geant4-dependent part of the MCTruth handling machinery consists of a few 'G4 user actions' as well as an implementation of G4VUserTrackInformation. The later one is, for the moment, used only to store one boolean flag indicating whether the direct mother of the given track has been stored or not.
The first user action is MCTruthEventAction which is only reponsible for calling MCTruthManager::NewEvent() at the beginning of each event. It can also be used for printing out events for the purpose of debugging.
The actual 'decision making' concerning which particle to store is done in MCTruthTrackingAction. At the end of each track the method trackToBeStored(track) is called to check for various characteristics of the particle. These, for instance can be energy, particle ID, creator process, etc.
If the particle satisfies the conditions the MCTruthManager::AddParticle is called and all the procedure described above is performed. The important element here is that the Geant4 TrackID is used as the unique particle ID in MCTruthManager and eventually as the barcode of the HepMC::GenParticle.
If the particle does not qualify to be stored, there are two actions performed. First the 'ParentID' of the daughters is set to the 'ParentID' of the currenly processed particle. In other words, the 'ParentID' of the daughters is set to the ID of the last stored particle. Second, the 'directParent' flag from MCTruthTrackInformation of the daughters is set to FALSE. In such a way, one is still able to navigate up in the event (to get the ancestors of the particle), but in the same time, the particle is flagged as 'not having direct parent'.