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

Overview of the BABAR Software Trigger

This Web site contains information from the Preliminary Design Review (PDR) of the Level 3 Trigger. The following items on the review itself are available from this Web site:

This document serves as the introduction and guide to the Level 3 documents for the Committee.

The Level 3 Trigger Group consists of

G.P. Dubois-Felsmann, A. Ryd, S. Yang
    California Institute of Technology

A.M. Eisner
    University of California, Santa Cruz

J.F. Kral
    Lawrence Berkeley National Laboratory

C. Cretsinger, E. Frank, L. Gladney, V. Suraiya
    University of Pennsylvania


General goals for the Trigger system

The multi-level triggering system for BABAR is designed to deal with the unique environment provided by the PEP-II Collider. Beam crossings occur at a rate of 238 MHz and can be considered as essentially continuous in comparison to the response time of the electronics. There may also be severe machine backgrounds that produce high occupancies. It is required that, under a variety of conditions, the rate of all processes recorded to permanent storage at the design luminosity of 3× 1033 cm-2s-1 be no more than 100 Hz. The trigger system must also be capable of handling the physics and background rates in the case of a luminosity upgrade of PEP-II to 1034 cm-2s-1. Under these conditions, the trigger must select, with high efficiency, e+e- interaction final states (Upsilon(4S), Upsilon(5S), charm-anticharm, and tau+tau-) and final states of gamma-gamma and gamma-gamma* interactions. The trigger must also select certain final states (e.g. e+e-, e+e-gamma, mu+mu- and a small rate of random triggers) for luminosity measurements, calibration, and monitoring purposes. To get some idea of the expected rate budget for these processes, consider the following rough estimate:
Process Rate
Upsilon(4S) resonant 4 Hz
q-anti-q 8 Hz
mu+mu- 2 Hz
tau+tau- 2 Hz
2-photon signal 3 Hz
Bhabhas 10 Hz
Misc. events for calibration ~10 Hz
Random 5 Hz
Total ~45 Hz

While selection for the above physics processes is mandatory, the 100 Hz rate limit demands that the trigger reject or select for removal most of the events produced from a number of background processes, e.g. beam-induced backgrounds, cosmic rays, and 2-photon events which are not of physics interest. Finally, the trigger system must be flexible, modelable (i.e. understandable and reliable), accurate, and stable; there are also stringent constraints on its contribution to the deadtime. These conditions form the basis for the trigger design requirements as described in the BABAR Trigger System Design Requirements document. As they apply to the system as a whole, the requirements for Level 3 must satisfy these conditions as well as conditions set by its role as part of the Online system.

The Software Trigger Subsystem

The overall design of the software trigger for BABAR differs somewhat from that of some other HEP experiments. The Online Event Processing subsystem (OEP) acts as the part of the Online system responsible for all processing of complete events short of Prompt Reconstruction. OEP receives complete events from the Event Builder and provides the infrastructure for the Level 3 trigger, for online data quality monitoring, event displays, validation of all online calibrations, and all processing for certain types of full calibrations. The Level 3 (L3) trigger, running in the OEP environment, is the first part of the trigger system to make decisions based on complete events. It identifies events coming from processes of interest due to their intrinsic value for physics, luminosity, or calibration purposes, then makes those identifications known to OEP. OEP is then responsible for event prescaling, monitoring analysis, and logging. This structure for the software trigger has several implications on the design of L3. For example, the requirement for the maximum rate for selection of events for permanent storage by L3 is 90 Hz, i.e. less than 100 Hz, to allow bandwidth for other information (e.g. subsystem diagnostics) which does not pass through Level 3 to get to permanent storage. The flexibility, reliability, and accuracy requirements on the software trigger demand certain properties of its general architecture. A subset is:
  • L3 must see and deliver a decision on all the events for which there is a L1Accept, hence OEP must provide this capability for L3. L3, in turn, is therefore part of the deadtime path and must conform to the same deadtime restrictions as any other part of the Online system
  • The OEP user code environment must be as similar to the offline environment as possible so as to avoid the need for parallel development and testing of code
  • L3 code must operate in both the online and offline environments
  • The L3 architecture must meet rigid requirements for physics efficiency and background rejection, but must be open enough to allow for unexpected happenstances

What's in the PDR Documentation?

The documents listed below will show how the architecture of L3 provides for the properties listed above. General properties of physics events which the software trigger is required to identify will be discussed in broad overview form later in this document. The full requirements can be read in detail in the Trigger System Design Requirements document. The list of provided documentation is

Overview of the BABAR Software Trigger
A PostScript verson of this document
Architecture of the BaBar Software Trigger
Describes the general architecture for L3
TrgConfig: Software for Ensuring Consistent Trigger Configurations
Describes the mechanism for ensuring consistency between the Level 1 Trigger, the Fast Control and Timing System, L3, and OEP
Drift Chamber based L3 Trigger
Gives an update on one of the tools used for discriminating between physics and background events
Level 3 Calorimeter Triggering Algorithm
This is the second tool. Both this algorithm and the Drift Chamber algorithm have undergone significant modification since the CDR+PDRR.
L3Svt
This describes the Svt tool, but it has not changed substantially since the CDR+PDRR.
Background and Physics Benchmarks for the BaBar Level 3 Trigger
Describes why the benchmark samples presented in the performance document below were chosen and how they were produced.
Performance of the Strawman BaBar Level 3 Trigger
Describes the actual efficiencies and rates for processes useful for physics, luminosity, and calibration purposes along with the rates for background processes. This document will be provided at a later date.
Progress Towards Meeting Level 3 Trigger Requirements
Describes the achievements of the Level 3 group in producing a trigger that meets requirements as specified in the Trigger Requirements Document. The focus is on efficiency, rates, and understandability of L3.

As the current review will not show a preliminary design that is proven to meet all the physics requirements, we will provide a separate document on "Satisfaction of Requirements" at the time of the review to summarize how our design addresses the major problems implicit in the requirements and to indicate the scope of work still to be done. We will also present the current estimates for CPU resources, memory usage, etc. used by compiler-optimized versions of the tools and architecture code.

Properties of Physics and Background Events

The principal mission of the BABAR experiment is to study CP violation in B meson decays. Events containing these decays are marked by their relatively large multiplicities and visible energies in the EM calorimeter. However, the large luminosities provided by a B factory also make for sizeable data samples of considerable interest for charm, tau, and two-photon physics. While charm events overlap with B events in terms of easily recognized charged particle multiplicities and calorimeter energy deposits, tau+tau- and 2-photon events present signatures which are closer to those of the most problematic background processes. The defining characteristic for many such events in the Level 3 Trigger is the presence of at least one charged track making it through most of the drift chamber and originating from the IP. The Level 3 trigger must also capture, with reasonably high efficiency (> 80%), physics events with no charged tracks such as 2-photon to all neutrals and e+e- to 2-photon. Hence, there will also be a L3 selection based purely on the ElectroMagnetic Calorimeter. The primary discriminants for such events are the number of energy clusters and angular distribution of those clusters.

Background processes, in contrast to physics, tend to deliver events with very low track multiplicity, a broad track-vertex distribution, small numbers of energy clusters and relatively low total energy in the calorimeter. The worst case background conditions for which we design the trigger to work is 10× nominal. This corresponds to the tolerance limit for the silicon vertex detector both in terms of radiation damage and tracking reconstruction. Under × 10 conditions, some fraction of the photoproduction and beam-gas processes (these are explained in detail in the Benchmark document) give events with tracks from the origin that pass the charged tracking triggers in Level 1 and in Level 3. For such events other information like dE/dx from the drift chamber or particular calorimeter signatures may be useful in dividing backgrounds from physics. Hence, the list of discriminants, or "knobs" as they are termed in Level 3, has been developed around track multiplicity, energy clusters in the calorimeter, and track properties. The knobs that we have found useful for preliminary benchmarks studies will be explained in the reports on Level 3 Tools.

Calibration and Luminosity Requirements

Bhabha scattering events, both radiative and non-radiative, require special care in Level 3. Depending upon their topology, Bhabhas are useful for either luminosity or calibration measurements, hence the events which are most useful for these purposes must be identified for later processing in the Online system and/or in the offline reconstruction. Since the rate for Bhabha events which are not useful for either calibration or luminosity is on the order of 50-100 Hz, Level 3 must identify, with high efficiency, such events so that they can be prescaled in OEP and do not saturate the trigger's 90 Hz limit by being included with the unprescaled physics sample. Radiative Bhabhas must be identified separately so that they are not prescaled. Finally, muon pairs will be identified as part of the regular physics sample although their primary use for BABAR will be in luminosity measurement (in conjunction with Bhabhas), calibration (e.g. tracking), and diagnostics.

The experiment will use two-prong non-radiative Bhabhas with both final state leptons in the detector acceptance as the primary measurement of physics luminosity. They are also the main method for tracking gain changes in calorimeter channels and can provide a warning of serious shifts in the calorimeter crystal properties. Hence, the efficiency for these events must be in excess of 95%, known to 0.5%, and stable to less than 1%. It is required that calibration information be extracted online so the two-prong non-radiative Bhabhas must be identified by Level 3 and, between Level 3 and OEP, any prescaling of these events must be polar angle-dependent so that the resulting yield per calorimeter crystal nowhere fall below the minimum unprescaled yield (check the Trigger Requirements document for the kinematic definitions of "radiative" and "non-radiative"). In order to track the photon response of the calorimeter over long time scales, Level 3 must also identify e+e-gamma events for which all three final state particles are in the detector acceptance. The positive identification requirement results from the expected low rate of such events and the concomitant need to have these events non-prescaled in OEP.

Since the most backward seven rings (120 CsI crystals per ring) of BABAR fall into the minimum accepted forward angle of 350 mr, these crystals must be calibrated with single-prong Bhabhas. In Level 1, these events are selected by the 1Y trigger, a calorimeter-only single cluster trigger which looks only in the backward region of theta. In Level 3, we apply single-prong Bhabha selection criteria only on the 1Y sample to identify events useful for this sample.

To allow for calorimeter calibration for high energy photons, Level 3 must identify events from the process e+e--> gamma gamma. Here, the rate of such events is low (about 6 Hz at design luminosity), hence we need to separate such events from the e+e--> e+e- process and its polar angle dependent prescaling. Single photon events in which the photon is found in the backward end of the calorimeter need to be identified at high efficiency for the equivalent photon calibration of crystals in this region of the detector.

Other Requirements

Other explicit requirements for the system are set by the need for flexibility, reliability, and accuracy. In particular, the complete trigger system must be expected to meet all requirements as stated above even under beam background conditions which are up to 10 times worse than nominal conditions. In addition, the Trigger must be capable of meeting the physics requirements despite any anticipated degradation of performance, e.g. realistic cell efficiencies for the drift chamber. To allow for rapidly changing beam conditions and possible changes in detector and trigger performance, the efficiency of the Software Trigger must be measurable from the data themselves. To achieve this goal, it is required that efficiencies be stable for a period of time which is long enough to make the efficiency measurements needed. Finally, it is required that the trigger, fast control and DataFlow systems be live more than 97% of the time, taking all deadtime causes into account. The Level 3 trigger, in its OEP system context, shall have a deadtime less than 1%.

The detailed rationale for these and other requirements are stated in the Trigger System Design Requirements document. What we have given here is a succint summary of many of the issues that impose strict requirements on the L3 design. We sincerely hope that the documentation list stated provides the necessary detailed information needed to determine that the Software Trigger design we have created does indeed meet the needs of an ambitious physics program for the BABAR collaboration.


Created: Thurs May 07 13:35:50 EDT 1998
Last modified: Fri May 08 18:57:33 EDT 1998