Babar logo
Workbook HEPIC Databases PDG HEP preprints
Organization Detector Computing Physics Documentation
Personnel Glossary Sitemap Search Hypernews
Unwrap page!
Wkbk. Search
Wkbk. Sitemap
Logging In
Info Resources
Software Infrastructure
CM2 Introduction
Event Store
Modifying Code
Writing and Editing
Framework II
Find Data
Batch Processing
Advanced Infrastructure
New Releases
Main Packages
Event Displays
Contributing Software
Advanced Topics
Make CM2 Ntuples
New Packages
New Packages 2
Persistent Classes
Site Installation
Check this page for HTML 4.01 Transitional compliance with the
W3C Validator
(More checks...)

Workbook for BaBar Offline Users - Event Store: Accessing Event Information in BaBar's Databases

Description of the information stored in the BaBar Event Store Databases and details of the event information available in the BaBar nano and micro databases. For information on finding data, see the Workbook section Finding Data.

Quick Link: Quantities accessible at Nano and Micro Level



In its most basic format, the raw data collected by the 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 must be reconstructed into tracks (in the SVT and DCH) and clusters (in the EMC and IFR), which in turn must be reconstructed into particle candidates.

With the advent of the "CM2" computing model, all event information is stored in the BaBar "Mini" database. Within this database is stored information at different levels of detail which are used for physics analysis jobs, including partially-reconstructed event information corresponding to the former "micro" and "nano" formats. While the full event information can also be retrieved, the Mini database contains event data, such as momenta, energies, number of hit crystals, ... - which is usually enough information to enable a complete analysis job to be run without having to resort to the full raw event information (which is very time-consuming to access).

Reconstruction is a resource-intensive process, and BaBar cannot afford to do it every time a collaborator wants to analyse an event. Consequently, we must store the results of the reconstruction algorithms, and provide a way of reading those stored results quickly. The various levels of the BaBar databases represent different balances of the level of detail and accuracy available with access and analysis time.

Data content of the Mini

The primary data content of the Mini consists of pattern-recognition objects (tracks, clusters, rings, ...), together with the hit objects from which they were built.

The Mini also stores a subset of the hit objects not associated to any pattern-recognition object. These unassigned hits can be due to background or to real parts of the event that were missed due to reconstruction inefficiency. It is important to store these for use in studies to evaluate and improve the current reconstruction alogrithms. However, there are too many background-induced hits present to store all of them. Therefore, only a subset of the unassigned hits, passing subsystem-specific quality cuts, are stored in the Mini.

Together, assigned and unassigned hits cover essentially the entire data content of a BaBar event. The Mini also stores the results of CPU-intensive calculations such as track fit parameters at the origin.

Level-of-Detail when accessing the Mini

The Mini database "persists" (stores) several levels of data which overlap in content. The Mini is designed to that the user can, and in fact must, decide which level of detail for their specific use when reading back the Mini. This is usually done in the tcl "snippet" used to run a user's analysis job. For example, in the Quicktour, the level-of-detail (LOD) parameter is set in the following line in "snippet.tcl":

set levelOfDetail cache
There are four options for the Level of Detail (LOD):


Micro mode is intended solely to simplify validating the Mini against a previously-used database called the "Micro". The micro mode is less accurate and no faster than the cache mode (described below), and is therefore not recommended for use for analysis jobs. However, information corresponding to the old "micro" database is still available in the Mini Most users will probably never use micro mode for actual physics analyses, since it is no faster than cache mode (described below) and returns less accurate values. (For example, the micro stores only pion-hypothesis track fits.)


Cache mode is probably the most useful mode for most analysis. This mode reads the Mini so that reconstruction objects are rebuilt directly from stored results of track-fitting, PID, and other high-level calculations. It provides easy access to track parameters for Kalman track fits calculated using five different particle mass hypotheses. However, cache mode cannot read new conditions data, and does not allow the user to access hit-level data.

Information that was previously available in the "nano" and "micro" databases in the previous computing model is accessible in the mini. A listing of those quantities is here.


The extended version of the cache mode extends track fits from the origin through detector material, allowing improved precision for studies involving particles such as Kshorts which decay outside the beampipe.

An example of the use of extend mode is when reconstructing long-lived particles when decay outside the beampipe, such as K0. In cache mode (and when using the micro), these particles are vertexed using fit results measured inside the beampipe. Extend mode will allow the material of the detector to be taken into account to improve the vertexing of long-lived particles when they decay in the detector material.


This is a much slower mode, used mainly for detector studies, event displays, specialized analyses that depend on hit-level data, or analyses that need the most recent calibration constants or algorithms. The Mini contains tracks and clusters that have already been reconstructed. But in refit mode, the Mini's tracks and clusters are ignored, and the user redoes the reconstruction directly from the stored hits, with the user's choice of inputs such as conditions, particle hypotheses in track-fitting algorithms, and PID methods.

The four Mini modes have been designed to produce equivalent information regardless of the levelOfDetail setting. Obviously the differnt modes will not be identical, but the same physics objects used in a Beta job should be present in all modes, and provide equivalent physics information.

The 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 need to be taken into account when data is reconstructed, and when Monte Carlo simulations are produced.

Because the Mini database rebuilds much of its information from raw detector quantities, it relies heavily on the Conditions Database to obtain conversion factor and calibration constants.

Related documents

Nano/Micro Level Quantities

Information contained at Micro level

Micro-level information, which is also available in the mini database contains the major variables (4-vectors, etc) and the most important variables of each Subdetector's major purpose, namely:

Subdetector Micro quantities
Svt, DchTracks which have goodness-of-fit and vertex information
EmcClusters which have various variables which depend on the distribution of energy in a cluster and number of crystals
DircPID information which separates Pions from Kaons
IfrMuon and neutral hadron finder

Micro-level information is made up of a list of BetaCandidates. Their behaviour from the point of view of kinematics is identical to that of the full event information, but other detector information is lost at this stage.

Nano (Tag) quantities

"Nano"-level quantities are a fast summary level that you can query in order to select events with desirable characteristics. Hard leptons, more than n tracks, hard photons, thrust, Fox-Wolfram moments, etc. It is essentially used to collect events together when some features depend on the modes of interest.

Nano-level information 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. Nano-level quantities include event information, such as selection bits, global variables and trigger information. This information is also known as "tag" information, as it has available a lot of information about "tag bits", which are set to true/false for whether or not an event satisfies certain criteria, such as different background filters.

Following the link below you can find several pages describing what quantities are available in the nano(tag) and micro portions of the BaBar event store. There is also sample code provided which can be used to access this data. Note that this table is not currently maintained, and has not been updated in several years, but is the best available excellent source of information on the quantities available in the BaBar event store.

Quantities in the Nano and Micro Databases

General Related Documents:

Back to Workbook Front Page

Authors: Jenny Williams, Chris Roat, Joseph Perl, authors of BAD508
Contributors: David Nathan Brown, Thomas Hadig, Fabrizio Salvatore

Last modification: 7 June 2005
Last significant update: 7 June 2005