Interactions with Database During a Typical Analysis Job
Before you start a Beta analysis job, you must decide what federation you want to read events from. A bootfile is a small text file containing the information Objectivity/DB needs to access a federation. You specify a bootfile by setting the environment variable OO_FD_BOOT to the corresponding bootfile pathname.
A single federation can hold millions of BaBar events. To provide physicists with efficient scalable access, groups of associated events are stored together as Event Collections. These collections form the basis of BaBar analysis and are arranged in a directory-like hierarchy known as tree nodes. Each branch of a tree node has a logical name. Collections are referenced using paths comprised of tree node branch names. Here is an example:
The event browser is an ideal way to view the tree node hierarchy of event collections stored in BaBar federations. The browser runs as a Java graphical user interface inside your web browser. You can examine collections along with the events they contain.
Once you identify an interesting collection, you can use it as the source of input events for a Beta analysis job. One way of configuring the Beta framework is to create/edit the Patches.tcl file in your workdir directory with your test release.
You need to add the following lines:
module talk BdbEventInput
input add /groups/sin2b/Charmonium/jpsikp_blk2/230600/V00/allevents
The first line informs the Beta command interpreter that we want to give instructions to module BdbEventInput.
This module allows you to read events from BaBar Objectivity federations. The following line tells BdbEventInput what collection (in the federation specified by OO_FD_BOOT) you want to read events from.
With these parameters set, you are ready to launch the Beta program. A good example job would be micro level analysis. We can configure the Beta framework using the bdbMicro.tcl script.
From the workdir directory, run BetaApp ../BetaUser/bdbMicro.tcl
You will see various output messages as the framework modules are initialized. Once Objectivity/DB has been initialized using $OO_FD_BOOT. The BdbEventInput module will use the Event Store to confirm that the specified input collection exists. The path components are implemented as a network of persistent map key/value maps (ooMap) stored in treenode databases. An authorization check also takes place to see if you have read/write permission. If everything is OK, the entire collection (based on a persistent array of pointers) is fetched into memory.
Once you see the command line prompt you can issue a command to iterate over some events.
Try: ev beg -nev 100
The BdbEventInput module uses a BdbCollectionIterator to access events. The events are comprised of subcomponents stored across multiple database files. Only the information required for a particular analysis task is retrieved. In the case of micro analysis, we read from col, evt, evshdr, tag and aod databases. At the start of the job, several pages of data are read from each specific database. The standard page size is 16K so a single page can contain many objects.
During iteration, additional pages may be read depending on how the data is clustered. In the worst case one page per object will be read. On average, the effective overhead of each event decreases as the number of iterations increases. The difference in the amount of data read for 1000 events compared to 10 events is far less than *100.
Detector conditions vary over time and different kinds of conditions data must be read according to the type of analysis job. In the case of our micro example, ~4 MB of conditions data was read. This information was valid for the entire collection, but this will not be the case if a collection contains events from different runs. Rolling Calibrations and IR2 conditions will change at least once from run to run. At the other end of the spectrum, detector alignments and materials may remain constant for several days, months or years.
Persistent event objects are converted to their transient representations before they are passed to the analysis modules. At the end of the event loop, the database transaction manager commits the current transaction, freeing any active locks.
BaBar Public Site | SLAC | News | Links | Who's Who | Contact Us
Page Owner: Jacek Becla
Last Update: June 13, 2002