SLAC PEP-II
BABAR
SLAC<->RAL
Babar logo
HEPIC E,S & H Databases PDG HEP preprints
Organization Detector Computing Physics Documentation
Personnel Glossary Sitemap Search Hypernews
Workbook Home Introduction Account Setup QuickTour Packages Modules Unwrap page!
Event Information Tcl Commands Editing Compile and Link Run the Job Debugging
Check this page with the
W3C Validator
(More checks...)
Parameters Tcl Files Find Data Batch Analysis ROOT Tutorial

Event Information: What's available, and how to get it.


Event Information

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.

BtaCandidate Information

In every event, you can access lists of BtaCandidates, and get physics information about each BtaCandidate.
Available Lists The lists of candidates that are automatically available (e.g., ChargedTracks, CalorNeutral)
Kinematic Variables 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)

Tag(Nano) Information

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.
Event Parameters Variables describing the overall event (e.g., event shape, highest-momentum particles)
Trigger Flags 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
Tag Variables Alphabetical listings of the 400+ tag variables, and instructions on how to make a dump of the tags in your collection.

Contents

From detector to desktop

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.

Available event information

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.

BtaCandidate: the particle candidate class

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.

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.

BtaCandidate Lists

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:

BaBar packages contain code to produce many different run-time lists. Some lists, like GoodTracksLoose and 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.

Advanced users can also build their own lists. The SimpleComposition and CompositionTools packages provide the list-building tools.
(Not recommended for beginners.)

The table above provides a link to a table of available BtaCandidate lists.

Tag-level ("nano") variables

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.

Modules and event information

As described in the Framework 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:

MyModule::event(AbsEvent* anEvent) 

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.

BaBar's databases

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:


condXYboot
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,

cond22boot
because the analysis job was based on a 18-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.

Back to Workbook Front Page

Send comments to Workbook Team.