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
Unwrap page!
Det. Search
Who's who?
Meetings
FAQ
Images
Archive
Systems
Performance
Intern. region
Vertex Tracker
Drift chamber
DIRC
Calorimeter
IFR
LST
Magnet
Electronics
Trigger
Operations
Run Coordination
Contact Experts
Shift Takers Info
Operations Manual
Electronic Logbook
Ops Hypernews
Shift Signup
Check this page for HTML 4.01 Transitional compliance with the
W3C Validator
(More checks...)

BaBar Drift Chamber

Online Event Processing Software

Last Updated: 14 October 1998 (Updated FMon links) by Michael Kelsey, UBC


The Online Event Processing system handles the collection of data from the subsystems transferred from readout modules (ROMs) to the Unix online farm, constructs an "event", and does the online reconstruction, and monitoring of that data. The Drift Chamber group work includes two major projects, discussed in detail below.

  • Conversion software between Tagged Containers (used by the data acquisition hardware) and Digi classes (used by the online event processing and reconstuction);
  • Monitoring of the data quality before and during online reconstruction.

DchDigi-Tagged Container Conversion

Two kinds of conversion routines are required. A conversion from pre-existing DchDigi data into output-level (after ROM feature extraction) TCs is needed for exercising the OEP data flow and event builder software. This conversion will not be needed or used in the real BaBar Online Farm. A conversion from real tagged containers, produced by the DataFlow ROMs, into DchDigis for reconstruction, will be used during actual data taking.

Several pieces of information need to exist before I can write these conversion routines. We need a stable definition of the drift chamber Digi, suitable for persistent storage in the Objectivity database, and without any Monte Carlo-related quantities. We need a definition of the output tagged container, and iterators to access a set of them in an event. We need a mapping between logical detector channels (geometric identification of cells) and physical electronics channels (tagged container dTags).

The conversion classes live in the BaBar code package DchOep. Michael Kelsey of UBC is working on this code together with Valery Miftahov of Princeton. We have a complete set of software written which implements bidirectional conversion as a Framework Module, including regression test jobs.

DchDigi Definitions

The drift chamber Digi's are defined in the DchData/DchDigi.cc,hh classes, in the HEAD of CVS. Sumit Sen of the University of Colorado is developing this class and associated classes for simulation of the electronics.

DCH Output Tagged Container

Erich Varnes is handling the development of the drift chamber tagged container (TC) classes, both for input (raw data) and for output (feature extraction data from ROMs).

All of the DCH TC classes are defined in the DchOnline package. The lowest-level output TC is the channel (DchChanFeature), which are grouped into chips, elements, and slots.

The term "tagged container" seems to be something of a misnomer, since the container class (odfTC) does not in fact have a data member corresponding to a "tag" or "address". Instead, a separate iterator class maintains the knowledge of which containers are which, and a user is expected to step through a list of TCs in sequence, rather than addressing them directly.

TC hierarchies have to be built as strictly ordered, contiguous blocks of memory, so that they can be portable between architectures. The core DataFlow software will provide appropriate classes and functions to build up a TC hierarchy from individual channels through chips, elements, and slots up to a full detector/event.

Mapping between detector addresses (OdfdTag) and DCH geometry

The Drift Chamber Electronics group (via Dave Coupal) has a table showing the relationship between readout electronics and geometric cell identifiers (BaBar Note 331). The readout electronics correspond to the dTag addressing scheme used by the DataFlow. an AWK script is include in the DchOep package to convert the DC Electronics' table into DataFlow standard mapping (MapDetector) files. This script also generates a data file for input to the DchOep/DchdTagGeom mapping class. The format of this latter file is five tab-delimited columns, containing the separate values for the DCH's odfdAdr hierarchy and the cell identifer for each channel. This format may change, if an input parser is provided for the Online Data Flow address classes.

Fast Monitoring and Prompt Recon Monitoring

Silvio Morganti (INFN Roma) has taken on the task of coordinating the DCH Fast Monitoring requirements and software development effort with his colleagues in Rome. They are preparing a more detailed requirements document, a separate document for prompt reconstruction monitoring, and are working on software for integration into the OEP/DataFlow system.


For questions or comments e-mail <kelsey@slac.stanford.edu>