Given the LHC’s typical collision rate of 40MHz and an average event data size of 1.5Mb, it would be challenging to even read-out the detector systems for each collision, let alone store them all. The ATLAS trigger system analyses the collisions which take place in close-to-real-time and decides which events should be saved.
To operate within the experiment’s current technical and logistical constraints, the total rate must be reduced to around 1kHz. The trigger has a two-stage architecture. The L1 (Level 1) trigger uses dedicated hardware (primarily FPGAs and ASICs) to execute simple filtering algorithms and reduce the rate from 40MHz to 100kHz. Events which are accepted by the L1 trigger are then analysed by the software-based High-Level Trigger (HLT) which further reduces the rate to 1kHz. Events which pass the HLT are then stored for later reconstruction. A simplified schematic of the trigger architecture is shown in figure 2.13. The original ATLAS trigger design specified a three level trigger, where an additional software stage ran simplified algorithms on restricted regions-of-interest before a final software stage performed whole-event reconstruction. This was replaced with a single, more flexible, software stage in which individual chains can decide at when (if ever) to access the full detector readout or use more expensive reconstruction algorithms.
The L1 trigger decision is made by the central trigger processor (CTP), which takes three inputs, the L1-Calo, L1-Muon, and L1Topo. The L1-Calo receives low- granularity information from the EM and hadronic calorimeters and uses it to iden-
tify high-pT electrons, photons, taus, jets andETmiss candidates. The L1-Muon uses
the RPC and TGC to determine muon candidates. In addition to the CTP, these candidates are also forwarded to the L1Topo processor. The L1Topo was introduced for run-2 and performs simple topological selections on the L1 objects, e.g. finding
two electron candidates with a minimum separation in∆R. All of this information
is passed to the CTP, and it makes a decision on each event based on a menu of L1 triggers. If an event is selected by any trigger from this menu then an L1-accept bit is set, and the detector data is accessed, alongside identified Regions-of-Interest (RoIs), for use in the HLT and (potentially) storage. The whole L1 decision takes
place within2.5µs, of which 1.7µsis dedicated to reading out the data.
The HLT runs on a dedicated computer farm close to the ATLAS cavern. It receives the RoIs and L1-accept bits from the L1 trigger and has access to the full detector information, though for efficiency information is not read-out unless specifically requested. The HLT is built around the concept of chains. Each chain is a sequence of feature extraction (FEX) and hypothesis algorithms, where the FEX algorithms retrieve/calculate additional information about the event and hypothesis algorithms use that information to make a pass/fail decision. In the case of a failed hypothesis algorithm, the chain will cease processing immediately. Otherwise, it will continue until the final hypothesis algorithm is reached. The event is considered to have passed the chain if this last hypothesis algorithm is passed. Chains are seeded by
Level-1 Le ve l- 1 A cc ep t Level-1 Muon Endcap sector logic Barrel sector logic Level-1 Calo CP (e,γ,τ) CMX JEP (jet, E) CMX Central Trigger MUCTPI L1Topo CTP CTPCORE CTPOUT Preprocessor nMCM Detector Read-Out ROD FE ROD FE ROD FE ... DataFlow Read-Out System (ROS)
Data Collection Network
Data Storage
Muon detectors Calorimeter detectors
High Level Trigger (HLT) Processors O(28k) RoI Event Data Fast TracKer (FTK) TileCal Accept P ix el /S C T Tier-0
Figure 2.13: Architecture of the ATLAS trigger system during run-2. [19] an L1 trigger and will only run when that trigger fired. The trigger menu is a set of chains which are executed in parallel (with some caching of FEXs). The processing continues until either all chains have failed or one passes. If a chain passes then the event is accepted by the trigger, and the data is read-out to storage at tier-0. The average time taken to process an event is 0.3s.
The trigger menu is chosen to maximise the possible physics studies on the data while remaining within the 1kHz output limit and contains several hundred chains. Chains can be designed to find specific physics objects, such as isolated electrons
with pT > 100 GeV, which may be useful for many physics analyses or a more
complex combination of objects targeting a particular final state. Triggers whose
rate would ordinarily be too high to store, such as lowpT jet or lepton triggers, may
be prescaled. An otherwise passing chain with a prescale of 100 would be accepted
with a chance of 1
100. Since the luminosity delivered by the LHC can vary (both
during and between runs), several menus are defined, containing different chains and prescales, which can be switched between during data-taking.