   |  |
Computing Technical Design Report
| | |
Computing Technical Design Report
The ATLAS High-Level Trigger (HLT) comprises the Level-2 trigger (LVL2) and the Event Filter (EF) which provide the second and third levels of the online event selection. These run in farms of Linux PCs (the first-level trigger, LVL1, using coarse-grain data from the calorimeters and muon detectors, is implemented in custom electronics). The second-level trigger runs specialized algorithms using selected fine-grain data to confirm and refine the LVL1 trigger, and the Event Filter runs optimized offline algorithms to provide additional confirmation and refinement. Overall the HLT has to provide the required rate reduction from the 75 kHz of LVL1 to the 200 Hz which can be recorded for offline analysis.
As noted above, the HLT applications provide the interfaces to the online run control and provide the data movement, with different implementations being used for the LVL2 and EF systems. In the LVL2 trigger, data is received as event fragments which are requested across the network from the data-acquisition ReadOut Buffers as required. Typically only a few percent of the data in an event is required, thus saving both data-bandwidth and processing time. In contrast the Event Filter DataFlow provides complete events in byte-stream format.
The use of the Athena-like environment in both LVL2 and EF allows considerable commonality in the event selection software itself and also allows this software to use various offline software components, provided that other requirements of LVL2 and EF are also met. Because of the short processing-time-budgets and the larger numbers of events processed, both areas impose severe performance and robustness requirements, particularly so at LVL2, where there is also a requirement for thread-safety as the LVL2 code runs in a multi-threaded environment.
Offline components currently being used within the HLT include:
In some cases modifications are required, for example to meet the performance requirements, especially in LVL2. Figure 3-11 shows the package diagram for the Event Selection software. This use of offline components within HLT leads to dependencies between the HLT and offline software repositories and places additional requirements on those offline components used. The mechanisms used to handle the additional dependencies are described in Section 3.14.10 . In addition specific HLT tests are included in RTT (described in Section 3.13 ) to test new offline releases.
|
|
To test the offline components for compatibility with the Athena environments provided at LVL2 and EF, the additional offline tools AthenaMT and AthenaPT have been provided - AthenaMT includes tests of thread-safety. This is shown in Figure 3-12.
The EF provides an infrastructure whereby complete events are provided to a processing task where selection algorithms see an Athena environment. This same infrastructure can be used for data monitoring by simply replacing or augmenting the selection algorithms by those for monitoring. This has been further generalized by allowing the data-input to be received not only from the Event Filter DataFlow, but also from the Event Monitoring Sampler - as shown in Figure 3-13. This capability will be used extensively during Detector Commissioning as described in Section 3.12 .
|
| | |
Copyright © CERN 2005