An analysis module can access this information from its event() function.
Each link includes instructions on how to do this.
|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)|
|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.|
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:
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.
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:
GoodTracksLooselist is made up of BtaCandidates from the
ChargedTrackslist that pass additional cuts on the track momentum, number of DCH hits, and distance of closest approach to the origin.
pi0AllDefaultlist 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
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 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.
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:
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:
condXYbootfrom 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,
cond22bootbecause 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.