An important feature of the BaBar simulation is the ability of an analysis job running on simulated data to analyze the original characteristics of particles created in the simulation (what we call Monte Carlo truth) and to associate reconstructed particles (such as tracks and calorimeter clusters) with the original particles.

This document describes what Monte Carlo truth information is stored by the simulation, which portions are available to an ordinary Beta analysis job, and how a user accesses this information.

The information in this web page generally applies to SP5. To see the differences with SP4, please refer to the last section.

Frequently asked questions

Q: Why Monte Carlo truth associator should I use?
A: For SP5, use the default (the GHit associator). For SP4, if you use SVT only tracks, use the chi-squared associator, otherwise, use the GHit associator.

Q: Why do I see the Monte Carlo truth for only some of the decay products of a particle?
A: As explained below, not all particles are stored in an event.

Q: Why doesn't the sum of four-momentum of the decay products of a particle match their parent?
A: The four-momentum stored in the database/kanga are the momentum at a particle's origin. As a particle travels through the detector it may lose energy, so when it decays, it may have less momentum, or even no momentum (if it stopped entirely before decaying).

Q: If I use the "productionVtx" method of a Beta candidate from the Monte Carlo truth list, why do I get zero?
A: Beta is broken. If your particle is a generated particle, use the "decayVtx" method for the parent particle. If you are not sure the particle is from the generator, there is no dependable way of obtaining the production vertex.

Q: Why do I sometimes get strange answers from the "decayVtx" method of a Beta candidate from the Monte Carlo truth list?
A: Beta is broken. Unfortunately, this makes it impossible to accurately obtain the decay point for a Monte Carlo truth Beta candidate.

Q: What is StdHepData?
A: See the description below. The StdHepData structure has also been used (or rather, misused) to store Monte Carlo information in the micro, a fact that has sometimes caused confusion.

What is created in simulation?

Particle decays and the generator

The first step in simulating an event is to simulate the semi-stable particles produced in a beam collision. This is done by programs we call "generators". The output of the generators is StdHepData, a primitive data structure that is somewhat akin to a FORTRAN common block. This data is passed to the detector simulation package to calculate how the particles interact with the detector materials and to simulation the response of detector elements.

Note that, in BaBar, the generator is used to specify the decays of most particle species. Specifically, particle species can be divided up into three catagories:

Short lived. These particle species have lifetimes that are small enough (< 0.5 mm) that there is little or no chance that a corresponding particle will escape the vacuum of the BaBar beampipe before decaying. The decay point and daughter momenta of these particles are specified by the generator. Note that for charged particles this introduces a small error since the generator does not account for bending in the magnetic field.
Long lived. Long lived particles include the gamma, electron/positron, muon, neutrino, pi+, K+, K-long, proton, and neutron. These are not decayed by the generator. Decays of the muon, pi+, K+, K-long, and neutron, if they occur, are handled by the detector simulation.
Semi-stable For these particles that do not fall into the above two catagories, the generator is used to specify their decay mode and the momentum of the decay products (but not their flight length!). This information is then passed to the detector simulation which calculates a random lifetime (according to the tables in the simulation which do not necessarily match the values in BaBar's PDT tables). If the particle is destroyed (by interaction with the detector material), the decay information is ignored. Otherwise, when the particle decays, the momentum of the decay products specified by the generator are boosted to the direction and boost of the particle (which may have lost momentum or been deflected in the magnetic field).

Particle Promotion

When dealing with Monte Carlo truth, it is important to remember that, because of particle interactions and showers, the detector simulation can produce many thousands of particles. Since it would not be practical (nor necessary) to store them all, only important particles are saved to the job output.

To decide if an individual particle is important enough to save, the following criteria is used:

If a particle was specified by the generator it is always saved.
If a particle is the result of one or more uninterrupted particle decays from a generated particle, it is always saved.
Any subsystem is allowed to decide if additional particles should be saved. We call this "promoting" a particle. The precise criteria is up to the subsystem, but the idea is that it is worthwhile to save any particle that is prominent enough to be individually distinguished by the subsystem.

The following is (as of writing) the criteria used by each subsystem to promote a particle:

SVT: Any charged particle that traverses the wafers on more than one layer is saved.
DCH: Any charged particle that traverses more than one superlayer is saved.
DIRC: No criteria used.
EMC: No criteria used.
IFR: No criteria used.

GTrack and related objects

There are three types of Monte Carlo truth objects that are saved by the simulation (these are not normally available in the micro!):

GTrack: This object, one of which is created for each saved particle, stores the particle type and the four-momentum at the particle's origin. In a way it is misnamed since it is produced both for charged and neutral particles. Each GTrack object has a pointer to a GVertex object (described below) that corresponds to the point in space and time at which the particle was created. If the particle did not survive to exit the detector, there will also be a pointer to a terminating vertex.
GVertex: This object stores the location and time of each particle's birth and the point of each particle's destruction, for those particles which decay or are otherwise destroyed in the detector. It is stored separately from the GTrack in order to save space since the decay point of a particle is sometimes the origin point of several other particles. Also stored in the GVertex is the reason for the vertex, whether it be a decay decay specified by the generator, a particle decay generated by the simulation, or caused by a particle interaction.
GTrimMarker: This object keeps track of those simulated particles that were not saved. In general, a separate GTrimMarker is created for each type of interation produced by a particle saved as a GTrack, as long as the interaction produces one or more particles that are not saved to a GTrack. Each GTrimMarker object has a pointer to a GVertex corresponding to the earliest occurance of the interaction type and a pointer to the corresponding GTrack object.

Note that all particles created in the simulation either have their own GTrack object or are part of a GTrimMarker object. An example list of GTrack/GVertex/GTrimMarker for an event is shown in a separate page.

What is a GTrack parent?

Consider the following definition of the "parent" of a particle:

If particle A produces a particle B by a decay or by interaction with some material, particle A is said to be the "parent" of particle B.

Now consider the somewhat misnamed "parentTrack" method of GTrack:

const GTrack *parentGTrack = myTrack->parentTrack();

Now, what is parentGTrack? The problem is that the true parent of the particle represented by myTrack might not have been saved in a GTrack object. In that case, parentGTrack does not point to the actual parent of myTrack but rather to the closest ancestor particle that was stored in a GTrack object.

How does one tell? If the "parentTrimMarker" method of GTrack returns a non-zero result, this means that the parent of the particle represented by the GTrack object was not itself stored in a GTrack object (but rather belongs to a GTrimMarker). In this case, the "parentTrack" method does not return the actual parent of the particle.

GHits

A GHit is an object that is associated with the interaction of a simulated particle with an active detector element. How GHits are converted into simulated raw data depends on the subsystem. The simulation of detector inefficiencies sometimes prevent a GHit from being used at all. Sometimes several GHit objects will be combined into one piece of raw data.

Note that each GHit is associated with a GTrack object. Much like the GTrack method "parentTrack", if a GHit object is created by a simulated particle that is not stored in a GTrack object, the GHit is associated with the most recent ancestor of the simulated particle that is stored. In this sense, a GTrack is associated not only with GHits that it directly produces, but also with GHits that are produced by any of its decendents that are not stored themselves in a (or are more immediate decendents of) another GTrack.

Because GHit objects are not always associated with a GTrack object that corresponds to the actual particle that created the GHit, some potentially confusing situations can occur. For example, a pi-zero hitting the EMC at one side of the detector could in principle produce secondary particles that escape the front of the EMC to hit the calorimeter on the opposite side. If this secondary particle is not saved to a GTrack, those GHit objects associated with energy on the far side of the EMC will be associated with the original pi-zero.

FORTRAN nastiness

It is considered bad practice to rely on the order of objects stored in HepAList templates. Unfortunately, this is what the simulation does. This is because many of the objects that store simulated hits refer to the GTrack that created the hits by using an index which counts from 1. This odd habit is left over from the old BBSIM Geant3 simulation in which the GHit objects were arrays in FORTRAN common blocks.

One day we might get around to eliminating this indexing, but for the moment, savy Monte Carlo truth users should recognize that GTrack objects are often refered to by their index into the GTrack HepAList. For example:

HepAList gTrackList = (get from somewhere);
HepAList gHitList = (get from somewhere);

//
// Fetch associated GTrack for SvtGHit number i
//
const GTrack *myGTrack = gTrackList[ gHitList[i]->igtr() - 1 ];

What is created in reconstruction?

Building Monte Carlo associators

The BaBar reconstruction starts by building tradition reconstruction objects such as tracks in the tracking chambers and clusters in the EMC. Each of these objects is constructed from pieces of data from their respective detector components. In simulated events, each piece of data is associated with any number of GHit objects, each of which is associated with a GTrack object.

Note that the simulation of noise or the addition of background data can produce raw data objects that are not associated with any GHit.

Expiration date: