Cargando…
Evolution of the Trigger and Data Acquisition System in the ATLAS experiment
The ATLAS detector is designed to observe proton-proton collisions delivered by the LHC accelerator. The ATLAS Trigger and Data Acquisition (TDAQ) system is responsible for the selection and the conveyance of physics data, reducing the rate of stored events from the initial $40\MHz$ LHC frequency to...
Autor principal: | |
---|---|
Lenguaje: | eng |
Publicado: |
2012
|
Materias: | |
Acceso en línea: | http://cds.cern.ch/record/1494175 |
Sumario: | The ATLAS detector is designed to observe proton-proton collisions delivered by the LHC accelerator. The ATLAS Trigger and Data Acquisition (TDAQ) system is responsible for the selection and the conveyance of physics data, reducing the rate of stored events from the initial $40\MHz$ LHC frequency to several hundreds Hz. The TDAQ system is organized in a three-level selection scheme, including a hardware-based first-level trigger and second- and third-level triggers implemented as software systems distributed on commodity hardware nodes. The second-level trigger operates over limited regions of the detector, the so-called Regions-of-Interest (RoI). The last selection step deals instead with complete events. In the current design, the second and third trigger levels are separate systems. While this architecture was successfully operated well beyond the original design goals, the accumulated experience stimulated interest to explore possible evolutions. One attractive direction is to merge the second and third trigger level into a single homogeneous high-level trigger system in which each node executes all the steps required. This design has many advantages, among which: the radical simplification of the architecture, the flexible and automatically balanced distribution of the computing resources, the sharing of code and services on nodes. Furthermore, the full treatment of the HLT selection on a single node enables both further optimisations, e.g. the caching of event fragments already collected for RoI-based processing, and new approaches giving better balancing of the selection steps before and after the event building. In this paper, we report on the design of the new system, with particular attention to the prototyping effort that allowed to spot possible limitations and to demonstrate the benefits outlined above. We also discuss different trigger schemas, underlining the main parameters that can help in driving the choice. |
---|