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