Trigger Software Overview (October 1996)
The trigger simulation has provided the detailed input to making the Level 1 Trigger electronics design. Engineering constraints have already been incorporated into the software representations of the algorithms. The simulation is up to date at a very
detailed level, including a complete simulation of the time domain and with overlay of simulated beam-induced backgrounds.
Recent efforts have focussed on completing the electronics implementation model of the Level 1 hardware trigger for the trigger workshop at the end of October 1996. Software filters (Level 3) are studied to validate the trigger architecture and aid
design of the online farm.
The trigger code also contains background hit mixing code and Fast Control system code. All code runs in the BaBar C++ Framework.
L1 Overview
L1 contains Drift Chamber and Calorimeter triggers.
Code functions:
- digitization of GEANT hits (GHits) into drift chamber times and calorimeter pulse height histories,
- trigger algorithms, which is feature extraction, pattern recognition and reconstruction all in one,
- analysis code to tabulate efficiencies, rates and event time (T0) jitter,
- event display code for debugging and quality control.
In the current structure (SRT + GEANT 3.21), trigger packages are equivalent to the digitization stage of the 5 detector subsystems.
Input data:
Level 1 input data are GEANT hits from the DCHA and EMCA systems. Both DC and EM triggers use GHits from dbio bbsim.xdr files. The DC trigger also has an ascii interface for standalone use. Geometry is communicated via ascii files. Thus L1 trigger is a
consumer of geometry and hits.
Output data:
Currently only data saved to disk is HBOOK histogram and ntuple files. Digi data will be written at some point in the future after the DAQ interface has been defined. Also the T0 (and trigger decision) has to be transmitted to other subsystems.
L3 Overview
Level 3 input data are outputs from Level 1, GHits and SVT digis. In principle, Level 3 needs the data of all subsystems at the digi level, including IFR and DRC. Various Level 3 algorithms are under consideration and consist of Level 1 trigger
verification, fast and precise T0 determination and fast tracking. There exists a prototype interface between trgDC (track segments) and DchReco (track finding and fitting).
Implementation
Trigger code is written to explore new ideas and algorithms - the current code reflects the electronics implementation model. To meet the schedule demands with existing level of manpower, Level 1 trigger digitization and algorithm code is written in
Fortran 77 (with extensions, of course) and analysis and event display code consists of PAW kumacs. The Framework interface and Level 3 code is written in C++ and Fortran 77. Final Level 3 algorithms will be written in C++ with time critical algorithms
potentially in C.
Trigger and Fast Control System packages are:
- TrgSim Trigger simulation driver (currently in trgFrame)
- TrgData Trigger System data
- trgDC Drift Chamber Trigger simulation
- trgEM Calorimeter Trigger simulation
- trgGL Global Trigger simulation (currently in trgFrame and trgDC)
- trgFrame Background Mixer (+ various other stuff to be moved)
- FcsData Fast Control System data
- FcsSim Fast Control System simulation (currently in trgFrame)
Existing packages: trgDC, trgEM, trgFrame.
Dummy packages: FcsData, FcsSim.
Future package: TrgData, TrgSim, trgGL
BBSIM Simulation
The gntrol package in BBSIM is obsolete. Its drift chamber trigger simulation is used as a diagnostic during Monte Carlo production running. Ascii data files output from gntrol are used in calibration runs to construct segment finder lookup tables for
trgDC.
Fast Simulation
There is no immediate need to provide a fast simulation. In the past, cutting on generated tracks was a useful method to explore new strategies. If needed, something may be put into a future fast simulation package.
Future
The output data of the trigger has to be made available to other subsystems. Level 3 algorithms have to be implemented and checked on performance and time consumption. Reconstruction algorithms to more thoroughly verify the trigger are needed at some
point. |