Cargando…

The ATLAS Run-2 Trigger Menu for higher luminosities: Design, Performance and Operational Aspects

The LHC, at design capacity, has a bunch-crossing rate of 40 MHz whereas the ATLAS experiment has an average recording rate of about 1 kHz. To reduce the rate of events, but maintain high selection efficiency for rare events such as physics signals beyond the Standard Model, a two-level trigger syst...

Descripción completa

Detalles Bibliográficos
Autor principal: Montejo Berlingen, Javier
Lenguaje:eng
Publicado: 2017
Materias:
Acceso en línea:http://cds.cern.ch/record/2265272
Descripción
Sumario:The LHC, at design capacity, has a bunch-crossing rate of 40 MHz whereas the ATLAS experiment has an average recording rate of about 1 kHz. To reduce the rate of events, but maintain high selection efficiency for rare events such as physics signals beyond the Standard Model, a two-level trigger system is used. Events are selected based on physics signatures such as presence of energetic leptons, photons, jets or large missing energy. Despite the limited time available for processing collision events the trigger system is able to exploit topological information, as well as using multi-variate methods. In total, the ATLAS trigger systems consists of thousands of different individual triggers. The ATLAS trigger menu specifies which triggers are used during data taking and how much rate a given trigger is allocated. This menu reflects not only the physics goals of the collaboration but also takes into consideration the instantaneous luminosity of the LHC and the design limits of the ATLAS detector and offline processing farm. For 2017 data taking, the trigger selections and menus have been improved to handle expected higher luminosities of up to 2.0x10^{34}cm^{-2}s^{-1} and to ensure robustness in the presence of multiple interactions per bunch crossing. We describe the criteria for designing the ATLAS trigger menu used for the LHC Run 2 period. Furthermore, we discuss how the trigger menu is deployed for data taking, through different phases: validation before deployment, decisions on prescale values for different triggers (ahead of running, or live in case of sudden rate changes), and monitoring during data taking itself.