Event Information: What's available, and how to get it.
The following table shows what information is available in each event.
An analysis module can access this information from its event() function.
Each link includes instructions on how to do this.
In every event, you can access lists of BtaCandidates, and get physics information about each BtaCandidate.
||The lists of candidates that are automatically available (e.g., ChargedTracks, CalorNeutral)
||Kinematic variables accessible for every BtaCandidate (e.g., four-momentum, charge)
|Detector-Level Track and Cluster Info
||Variables describing a candidate's detector-level information
(e.g., numbers of hits or dEdX in the SVT and DCH, energy or number of bumps in the EMC, first hit in the IFR)
You can also access overall event information, such as selection bits, global variables, and trigger information.
|AWG Pages for Physics Flags
||The AWG people document their physics tag bits, along with the skims that are made from them.
||Variables describing the overall event (e.g., event shape, highest-momentum particles)
||Flags indicating which Level 1 and Level 3 trigger lines fired for this event.
|Background Filter and Digi Filter Flags
||Flags indicating why the background filter passed the event
||Alphabetical listings of the 400+ tag variables,
and instructions on how to make a dump of the tags in your collection.
In its most basic format, the raw data collected by the BaBar detector and seen by the online systems
is just a collection of Raw "digis" (e.g. details of individual "hits" on crystals in the EMC) from each subdetector.
To turn this raw data into useful information, the hits are used to reconstruct pattern-recognition objects,
such as DCH and SVT tracks, EMC and IFR clusters, and DIRC rings.
These pattern-recognition objects are then used to reconstruct particle candidates.
The reconstruction of charged and neutral particle candidates is performed centrally.
This central reconstruction stage is called "online prompt reconstruction", or OPR.
The output of OPR is stored in BaBar's main database, the Event Store.
The Event Store is the database that users interact with when they run standard BaBar analysis code.
For example, in the Quicktour, when you ran BetaMiniApp to make a histogram of the number of tracks per event,
BetaMiniApp found the the list of tracks in the Event Store.
As a user, you don't see the data until it gets to the Event Store.
This means that by the time you get your hands on the data, the original detector hits have already been reconstructed into particle candidates.
Most of the event information is now stored in one of two formats:
The following sections introduce the BtaCandidate class for particle candidates, explain how BtaCandidate lists are created and stored, and introduce you to tag variables.
- Lists of particle candidates (BtaCandidates)
- Tag ("nano") variables that describe the overall event
A BtaCandidate is a representation of what is known or assumed about an (alleged, thus candidate) particle.
Candidates can represent various levels of processing, various data types:
a reconstructed object, a combination of candidates, a transformation of a candidate for a few examples.
From a coding point of view, BtaCandidate is a C++ class.
Every particle candidate in the Event Store is stored as a BtaCandidate.
This means that for every particle candidate, you can easily access its physics information using the accessor member function of the BtaCandidate class.
Some of the most popular BtaCandidate functions include:
These values are for the BtaCandidate at the origin/decay vertex.
- double charge() const
- double energy() const
- double mass() const
- double p() const
- Hep3Vector p3() const
- HepLorentzVector p4() const
The table above provides a link to lists of
kinematic and detector-level information that you can access for any BtaCandidate.
You can also look at the header file, BtaCandidate.hh, for a complete list of member functions.
BtaCandidates are stored in lists (C++ class HepAList).
There are two main types of BtaCandidate list:
Two OPR lists that you will probably encounter a lot are the ChargedTracks list of charged candidates, and the CalorNeutral list of neutral candidates.
These lists serve as the building blocks for nearly all other lists.
Run-time lists are built from OPR lists or from other run-time lists:
- Lists produced during OPR.
Recall that OPR is the central reconstruction stage, and its output is stored in the Event Store.
Therefore, these lists are available to all users.
- Run-time lists. Run-time lists are lists produced at run-time - that is, when a BaBar analysis application (such as BetaMiniApp) is run.
They may or may not be produced, depending on what Tcl scripts are run during the job.
- Refined lists can be created by applying tighter selection criteria to another list.
For example, the
GoodTracksLoose list is made up of BtaCandidates from the
that pass additional cuts on the track momentum, number of DCH hits, and distance of closest approach to the origin.
- Composite lists are lists of composite candidates, BtaCandidates created by combining other BtaCandidates.
For example, the
pi0AllDefault list contains neutral pion BtaCandidates,
each of which is built from a pair of photon BtaCandidates from the
BaBar packages contain code to produce many different run-time lists.
Some lists, like
GoodPhotonLoose, are almost always produced.
Other lists are produced by the default job for some packages but not others.
Fortunately, it is usually not too hard to "turn on" the production of a run-time list by changing some tcl parameters.
Users can build their own lists.
and CompositionTools packages provide the list-building tools.
The table above provides a link to a table of available BtaCandidate lists.
In addition to lists of BtaCandidates, the Event Store also contains tag (or "nano") variables.
These are variables that describe the overall event rather than individual BtaCandidates.
Examples of tag variables include:
Tag variables are useful because they allow you to quickly skim over the database and select events with desirable characteristics.
The skim is fast because you do not have to query each object in the event for the information that you require
- you just have to look at the summary object.
For example, if you are interested only in events with a high-momentum lepton,
then you can just demand that the high-momentum lepton tag-bit be set to "true".
This is a lot faster than accessing a list of lepton BtaCandidates, and checking them one by one to see if one of them has a high momentum,
as you would have to do if the tag variable were not provided.
The table above provides links to lists of available tag variables.
- The number of tracks in the event
- Whether the event has a high-momentum lepton
- The Fox Wolfram moment of the event (used to reject continuum events)
- Trigger information
- Whether the event passed certain background filters.
As described in the Modules section,
BaBar code is built from modules (C++ class AppModule), and every module has an event() function.
You can access any of the BtaCandidate lists or tag information from the event() function of an analysis module.
The event() function is found in your MyModule.cc file.
It looks like this:
Most modules use the name "anEvent" or "event" for the argument in parentheses.
Whatever name your module uses, make sure you use the same name when you access your list or tag variable.
The code to access a list or tag bit usually looks something like this:
HepAList<BtaCandidate> *trackList = Ifd< HepAList<BtaCandidate> >::get( anEvent, "ChargedTracks");
AbsEventTag* tag = Ifd<AbsEventTag>::get( anEvent );
How to access particle candidate lists from modules is covered in much more detail in the Editing Code section.
You can see the complete examples for lists
and tag variables by following the links in the table above.
As you can see, both use the AbsEvent pointer anEvent from the module's event(AbsEvent* anEvent) function.
That is how the application knows which event in the Event Store to look at.
As mentioned above, BaBar's main database is the Event Store database.
The Event Store database contains the output of online prompt reconstruction (OPR): lists of BtaCandidates, and tag variables.
In addition, the Event Store contains hit-level information, used to evaluate and improve reconstruction algorithms, and study backgrounds.
The above sections have already described how to access Event Store information from an analysis module.
BaBar also has a Conditions Database.
The Conditions Database stores detector alignments, calibration constants, and other time-dependent quantities that describe the conditions under which data was taken.
These conditions are taken into account when data is reconstructed, and when Monte Carlo simulations are produced.
When you run an analysis job, you need to make sure that your application will use the right conditions and calibration information from the Conditions Database.
Fortunately, this is very simple: all you have to do is issue the command:
from your release directory, where XY is the number of the release series that you are using.
(See the Packages and Releases section for more information about how releases are numbered.)
For example, in the QuickTour, you used the command,
because the analysis job was based on a 22-series production release.
This automatically ensures that you are using the right part of the conditions database.
But don't forget: the condXYboot setting remains only for the current session.
At every new login this variable will need to be reset.
Page maintained by Adam Edwards
Last modified: January 2008