Babar logo
SPIRES E S & H Databases PDG arXiv
Organization Detector Computing Physics Documentation
Personnel Glossary Sitemap Search Hypernews
Unwrap page!
 1. Introduction
 2. Accnt. Setup
 3. QuickTour
 4. Packages
 5. Modules
 6. Event Info.
 7. Tcl Cmds.
 8. Editing
 9. Comp.+Link
 10. Run the Job
 11. Debugging
 12. Parameters
 13. Tcl Files
 14. Find Data
 15. Batch
 16. Analysis
 17. ROOT I
 18. Kanga
Additional Info.
 Other Resources
 SRT/CVS Cmds.
 CM2 NTuples
 Root II, III
 tcsh Script
 perl Script
Check this page for HTML 4.01 Transitional compliance with the
W3C Validator

(More checks...)

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.


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:

  • Lists of particle candidates (BtaCandidates)
  • Tag ("nano") variables that describe the overall event
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:

  • double charge() const
  • double energy() const
  • double mass() const
  • double p() const
  • Hep3Vector p3() const
  • HepLorentzVector p4() const
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:

  • 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.
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:
  • 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 ChargedTracks list 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 GoodPhotonsLoose list.

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. Users can build their own lists. The SimpleComposition and CompositionTools packages provide the list-building tools. 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:

  • 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.
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 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 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:

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.

Back to Workbook Front Page

[Workbook Author List] [Old Workbook] [BaBar Physics Book]

Valid HTML 4.01! Page maintained by Adam Edwards

Last modified: January 2008