Trigger glossary

Last update: 06 Aug 2024 [History] [Edit]

Introduction

This glossary briefly defines terms that pertain to the ATLAS Trigger and related systems, based on their state in Run 3. For an older version addressing Run 1 and Run 2, see TriggerGlossaryRun1Run2.

Bunch Crossing Identifier (BCID)
Number that defines the bunch crossing at which an event occurred. Potential bunch crossings are numbered 0 to 3563 per LHC orbit, starting with the first following the LHC extractor gap.
Bunch Group Set (BGS)
The BCIDs in a given LHC filling scheme are categorised into 16 potentially overlapping bunch groups, represented by a bit-pattern of length 3564 (the hypothetical maximum number of LHC bunches). These patterns are based on the fill pattern of the LHC and the physics-driven definition of masks to select various types of triggers based on bunch locations relative to the colliding bunches. These patterns are used in the L1CT (aka. CTP) for the formation of the L1 items.
Each bunch group categorises the corresponding bunch crossings, including categories such as Filled (2 colliding bunches), Empty, Unpaired (Isolated/Non-isolated), in the Abort Gap etc. The collection of Bunch Groups is known as a Bunch Group Set and represented in the Trigger Database by a Bunch Group Key.
Luminosity levelling
For optimal luminosity delivery, including more favourable conditions for the detectors, the LHC can collide protons at a lower luminosity than the theoretical maximum given the beam intensity – this is accomplished by beam separation, reduced focusing/squeezing of the beams (primarily longitudinally) etc. As the beams burn off, progressively optimising the collision settings allows the luminosity to be held constant for a long period. At some point it can no longer be retained, at which point the luminosity decays naturally.
The End of Fill period is the duration of the luminosity decay, during which looser triggers that may not operate unprescaled at peak luminosity may have their prescales reduced to maximise the use of L1 and HLT bandwidth.

General Trigger terms

Configuration
Specification of the intended behaviour of the entire trigger system. This includes the following elements:
  • L1 menu: The list and definitions of all L1 items, and associated adjustable parameters in the L1 system. These include inputs, thresholds, L1Topo algorithm logic, outputs and items to monitor in the CTP.
  • HLT menu: The list of all HLT chains, their associated L1 items, associated output stream(s), labels for book-keeping, and the step sequences to be executed for every chain. For each sequence, the list of algorithms is also recorded.
  • HLT job options: Specification of every Athena component that comprises the HLT execution, including their configurable properties and the control/data flow sequence construction.
  • HLT monitoring: Lists of HLT chains for which the HLT monitoring should collect histograms.
  • L1 and HLT prescales: Definition of the prescale factors for every L1 item and HLT chain. For a single trigger menu, multiple prescales may be used, e.g. to accommodate changing luminosity conditions throughout a run.
  • L1CT (Central Trigger) configuration files, for CTP and MUCTPI
  • Bunch Group Set: see above
Database
System holding instances of the trigger configuration, allowing the various configuration elements to be retrieved with reference to their associated keys.
The trigger configuration database (TriggerDB) is a relational database (currently defined in Oracle), of which several instances are defined, holding configurations relevant for data taking, reprocessing, and Monte Carlo simulation.
Not to be confused with the Conditions Database, which holds information that persists from event to event, e.g. detector configuration/status and calibration constants.
Decision
A binary result of trigger selection resulting in an event being accepted or rejected at the current processing stage.
Feature
Used interchangeably with “object” – a specific reconstructed quantity or particle candidate used to decide whether to select an event at L1 or HLT. The process of generating features is termed ‘feature extraction’.
High Level Trigger (HLT)
Software trigger system running on a dedicated CPU farm. In Run 3, this operates multithreaded, with events being sent to ‘slots’, such that algorithms operating on any given event may be handled by any free threads on a given CPU node. Any given Trigger Chain begins with a LVL1 Accept, requests data as required from the ROS, and then proceeds through one or more steps that perform reconstruction and hypothesis selection. See here for more detail.
Level-1 Trigger (L1)
The ATLAS Level 1 Trigger system provides a hardware based first trigger decision using only a sub-set of an event’s data (Calorimeter and Muon only). Normally, only the events accepted by L1 are transferred from the detectors into the HLT/DAQ system.
Menu
The top level configuration of every L1 item (L1 menu) or HLT chain (HLT menu) – see Configuration.
Monitoring
To assess Data Quality both in real time, and in more detail after a run is completed, triggers are monitored, with selected variables filled into histograms for scrutiny.
Online monitoring is filled by trigger reconstruction & hypothesis algorithms in the process of their execution. To keep it lightweight, only a small number of critical variables can be monitored, and their evolution during the run is tracked for the attention of the shifter.
Offline monitoring is run after data collection completes, on the Express and Main streams. This comprises independent algorithms that read the HLT/L1 collections and may be constrained to particular HLT chains flagged with monitoring groups.
Prescale factor (PS)
A number by which the rate of events accepted by a certain trigger chain is reduced without affecting the trigger selection logic. For instance for a prescale of 10, one event in every ten events fulfilling the chain leads to an accept of the event. Independent prescale factors can be given to each chain at L1 and HLT, with the total prescale being the sum of the L1 PS and HLT PS.
Prescale decisions are separately determined for L1 and HLT. In the case of L1, the trigger decision is always known, but the prescale decision determines whether the L1Accept is issued. At the HLT, the prescale decision is computed before the HLT algorithms execute, to save CPU. The prescale decision is taken by random sampling.
In general, prescales for different chains are uncorrelated. However, HLT chains with the same L1 seed may be placed in a Coherent Prescale Set (CPS), which ensures that prescale decisions with a smaller prescale factor are inclusive of those with a higher prescale factor. Applications of CPS include the computation of trigger efficiencies with reference to looser HLT selections based on the same L1 seed, where uncorrelated prescale decisions would dilute the statistics.
See Prescales and Prescale Sets for more details.
Trigger Keys
Numerical IDs that are used to call up parts of the configuration in the Trigger Database, chiefly by the Run Control system but also in Athena production jobs. Various important keys exist:
  • Super Master Key (SMK) – links to the L1 and HLT menus, the HLT job options and the monitoring configuration
  • Prescale Key (PSK) – defines the prescale factor for each trigger item. Separate PSKs exist for L1 and HLT, and are denoted L1PSK and HLTPSK respectively.
  • Bunch Group Set Key (BGK) – defines the Bunch Group Set to be used for the current fill or run
Trigger Tool
Web interface to the trigger database
TDAQ
The combination of the Trigger and DAQ systems, or the corresponding ATLAS Project, which oversees the associated hardware, including the L1 trigger, HLT farm and DAQ infrastructure. Also responsible for the hardware upgrades (Phase 2 TDAQ).

L1 Trigger terms

Central Trigger Processor (CTP)
The part of L1 which receives the L1 trigger signals from various input sources and generates the L1 Accept. The final decision can be a logical combination (AND/OR) over multiple inputs, including L1Muon, Phase-1 L1Calo FEXes (via L1Topo) and other modules directly connected to CTP including legacy L1Calo and subdetectors such as AFP, BCM, BMA, LUCID, MBTS, ZDC, and the LHCF experiment. The decision logic is combined with a mask over selected Bunch Groups.
The CTP also generates certain signals for calibration (CALREQ, used by Tile, ZDC) and ‘Random’ triggers.
Feature Extractor (FEX)
Three modules of the Phase-1 L1Calo trigger system performing hardware-level reconstruction of L1 TOBs on which event selection is performed.
The electromagnetic eFEX performs electron/photon identification and reconstruction of the hadronic tau shower core at supercell granularity.
The jet jFEX reconstructs small-radius jets in a circular area with 0.1×0.1 tower granularity, computes hadronic tau isolation sums, and performs summation across the calorimeter to calculate total transverse momentum and missing transverse momentum sums. In addition, electron/photon reconstruction in the forward region (outside the eFEX acceptance) can be performed.
The global gFEX performs larger-area summation with 0.2×0.2 tower granularity, producing missing transverse momentum and transverse momentum sums with global pileup subtraction capability and large-radius jets.
Item
A single selection that could evaluate a L1Accept decision. L1 items are formed in the CTP and are logical combinations of input signals which may come from various sources:
  • Signals from specific subdetectors (e.g. AFP, BCM)
  • Muon multiplicities from the MUCTPI
  • L1Calo multiplicities calculated by the L1Topo system from TOBs generated by the FEXes
  • More complex L1Topo selections using a combination of L1 objects
For each item, the logical selection is combined with a requirement that the current BCID falls in a specific bunch group (by default, selecting filled BCIDs).
Local Trigger Processor
The trigger local to a timing, trigger and control (TTC) partition used to generate LVL1 triggers when the associated sub-detector is run independently of the CTP. The TTC is the standard hardware system used across the LHC experiments for the distribution of fast timing, trigger and control signals.
L1Accept (L1A)
A positive signal produced by the CTP, indicating that some L1 item flagged the event as interesting enough to process in the HLT. In the case of subsystem tests, the Local Trigger Processor in a partition can also generate a L1A for the active partition.
L1Calo
The components of the L1 trigger that operate based on signals from the calorimeter (LAr, Tile). Object reconstruction and particle ID is performed by the FEXes, whose outputs are sent to the L1Topo system for all selection logic.
L1Muon
The components of the L1 trigger that operate based on signals from the Muon Spectrometer.
Central muon candidates are reconstructed by the Barrel Sector Logic based on hits in the Resistive Plate Chambers (RPC)
Forward muon candidates are reconstructed by the Endcap Sector Logic, receiving hits from the Thin Gap Chambers (TGC), the small-strip TGC (sTGC) and the MicroMeGas (MMG) subdetectors. The latter two systems form the New Small Wheels (NSW).
L1Muon Sector Logic decisions are sent to the CTP via the Muon-CTP interface (MUCTPI), while the candidates are also forwarded to the L1Topo.
L1Topo
The L1 Topological Processor computes event-level decisions that can include multi-object correlations. It is formed of three boards (Topo1,2,3) each of which holds two FPGA processors. All L1Calo decisions including simple multiplicities are computed as L1Topo algorithms on Topo1. The Topo2 and Topo3 boards execute algorithms which combine multiple objects; these may be TOBs from one or both of the L1Muon and L1Calo systems.
Supercell
The finest granularity available in the Phase-1 L1Calo system, produced by the LAr Digital Trigger readout, whereby in the central LAr barrel region, each 0.1×0.1 region is subdivided longitudinally and laterally into 10 supercells.
Specifically, 4 supercells with dimensions 0.025×0.1 in η × φ are produced by summing calorimeter cells in layers 1 and 2, while supercells in the presampler and layer 3 have 0.1×0.1 granularity. For details see the LAr Phase-1 TDR.
Threshold
A set of predefined selection criteria for a single L1 trigger object, including energy and particle ID values. The L1 decision may require a certain multiplicity of passed thresholds, or a more complex topological combination of the feature information.
Trigger Object (TOB)
Representation of a particle candidate or other event feature used for L1 event selection, produced by the L1Muon Sector Logic or the L1Calo FEXes. Generally transmits (transverse) energy values and particle ID quality criteria, used to determine if various thresholds have been passed.

Higher Level Trigger terms

Alignment
An operation during menu construction that adjusts the relative ordering of steps for different signatures, primarily for CPU reduction. All signatures are placed in alignment groups. Steps from signatures in the same alignment group may be executed concurrently. The groups are ordered, and all execution for a given group completes before steps from the next group are executed. Delaying of steps within a combined chain is achieved by the insertion of empty steps that perform no operations.
Chain
The combination of a L1 trigger item with an HLT trigger item, forming the smallest unit that can accept events for recording. The HLT item requires a L1Accept to be activated, after which it executes all its associated steps. If in any step the HLT accept criteria are not met, the event stops processing (Early Rejection). If all steps are passed, the event is accepted by the trigger, and recorded to the corresponding Stream.
See Individual Chain Construction for details.
Chain Merging
Menu construction operation that combines the steps for multi-signature chains. The menu construction initially generates the step sequences for individual legs. Subsequently, the steps for every leg are merged such that their collective decision is given by a joint ComboHypo. Legs that are not active in a certain step are represented by an Empty Step.
Combination Hypothesis (ComboHypo)
A component that generates a coherent step decision for the entire chain, given the set of leg decisions. The default ComboHypo chiefly serves to perform ambiguity resolution, ensuring that objects of the same type are counted towards the multiplicity for a single leg only. Custom ComboHypo logic may be used instead to perform multi-leg topological selections, such as ΔR separations, invariant mass calculations etc.
Early Rejection
To avoid wasting CPU on the reconstruction of features on events that will certainly not be recorded, events are rejected as soon as possible in the HLT. This is accomplished in a few ways. Firstly, for each Leg of the trigger, fast approximate reconstruction is performed in order to reject very poor candidates, and subsequent steps perform progressively more precise but expensive calculations. Secondly, ‘menu alignment’ in combined chains typically places more expensive signature processing after signatures with lower costs and high rejection (e.g. jets after leptons), reducing the frequency at which the expensive steps run.
Event View
The Athena mechanism responsible for HLT Region-of-Interest-seeded reconstruction. A view is a restricted region of the detector (in eta/phi/z) in which data is provided to a reconstruction algorithm. The algorithm therefore can typically act with no knowledge as to the size of the region it is processing.
Group Label
A string tag attached to one or more HLT chains that carries information about this chain’s application and composition. For example,
  • ‘Primary’ chains are always to be run unprescaled to collect data for physics analysis.
  • ‘Support’ chains are normally prescaled, and are needed for auxiliary measurements, calibrations on high rate processes etc.
  • ‘Rate’ and ‘BW’ labels are used to book-keep the resources used by particular signatures.
  • ‘Rate:CPS’ labels are used to define Coherent Prescale Sets
  • ‘PS’ labels are used to steer Menu Prescale Sets
Hypothesis
A component of the HLT that reads input features and decides whether to accept an event from the current processing step and permit it to continue processing, or to reject the event and discard it. In the Run 3 trigger, a Hypothesis Algorithm (HypoAlg) retrieves the input features, and passes them to one or more Hypothesis Tools (HypoTools), each of which represents the current step selection logic for a single Chain. In certain cases, the Hypothesis components may also generate new features by combining their inputs.
Leg
A single unique selection threshold in an HLT chain, which is typically overlap-removed from other selections on the same type of object, and can further be input to topological selections. These thresholds are tracked in the trigger navigation. A single leg can have a multiplicity >= 1. In unusual cases e.g. jets or B-physics, a complex multi-object selection (e.g. HT, Jψ→μμ) can also function as a leg. For example:
  • A single muon trigger e.g. HLT_mu24_ivarmedium has one leg (multiplicity 1)
  • A symmetric dimuon trigger e.g. HLT_2mu8 has one leg (multiplicity 2)
  • An asymmetric dimuon trigger e.g. HLT_mu22_mu4 has two legs (multiplicity 1 each)
Menu Prescale Set
A predefined and relatively simple logic for generating all L1 and HLT prescales, given a trigger menu. A prescale set is activated by appending a suffix onto the menu name, e.g. 'MC_pp_run3_v1_BulkMCProd_prescale' activates the prescale set for bulk Monte Carlo production with the MC menu as the template.
Most commonly, this enables/disables HLT chains on the basis of their associated labels (e.g. PS:NoHLTReprocessing, PS:NoBulkMCProd).
Navigation
The representation of the trigger decision logic, identifying features on which a chain has decided to accept an event for every step. In the Run 3 HLT, all features are affiliated with a TrigComposite a.k.a. Decision Object that identifies the step and leg that the object is responsible for passing.
Region of Interest (RoI)
For many HLT signatures, it suffices to only consider limited areas for reconstruction. For example, electrons or muons need only consider a very small area a.k.a. ‘Region of Interest’ in which the corresponding detector hits for the particle are expected to be found. These areas are defined to have a fixed size in eta/phi/z surrounding a seed either by the L1 system (L1 seeding) or by preceding HLT algorithms (e.g. b-jets use jet RoIs). Other HLT signatures are unseeded, performing ‘full scan’ reconstruction in which the full detector acceptance is processed. RoI-seeded reconstruction may also be referred to as ‘partial scan’. RoIs are recorded as eta/phi positions in the detector, and L1 RoIs specifically also hold information about which Thresholds (energy/momentum and/or particle ID criteria) have been passed by the seeding object.
Rulebook
For data taking at P1, the full set of L1 and HLT prescales is defined by ‘rules’, the union of which comprises the rulebook. This encodes:
  • Disabled triggers (and by inversion, enabled ones)
  • The PS values to be applied to individual triggers, or groups of triggers
    • These may define a fixed value PS, or a target rate.
  • Luminosity dependence of the PS values. For rate targets, the PS is computed based on a reference rate measurement, and scaled to the target luminosity. At lower luminosities, certain triggers may be assigned a smaller prescale and correspondingly more rate.
  • PS values for selected triggers to write to the Express Stream, used for monitoring.
Seeding
The definition of the conditions for producing an RoI. Primarily referred to in the context of L1 seeding, where L1 thresholds are selected for each seeded leg of the chain – these may or may not be explicitly part of the L1 item selection criteria. All seed thresholds must exist for the chain to successfully accept an event – if not, the processing will be prematurely terminated.
Sequence
This term carries slightly different meanings depending on the context –
  • In the Athena framework, a sequence holds several algorithms, which may executed in each event. The sequence execution may be sequential, with algorithms run in a fixed order, or it may be concurrent, such that algorithms may execute as soon as all data inputs they require become available. The algorithms in the sequence can also produce a filter decision that the sequence can aggregate with OR or AND logic. Algorithm sequences may also be nested.
  • In the HLT, each non-empty step in a chain has a particular attached sequence which governs the early rejection logic. The sequence opens with a filter algorithm that requires preceding steps to have been passed. It is followed by all the reconstruction algorithms, which are typically held in a concurrent Athena sequence. These provide data to the hypothesis algorithm, which terminates the sequence.
Signature
Categorisation of a chain or part of a chain’s selection by the type of features used to accept events together with the corresponding reconstruction and selection logic/code. Formerly referred to as Trigger (Vertical) Slice. There are two main types of signature:
  • Selections on a single type of observable/particle species, e.g. electrons/photons, taus, muons, jets, b-jets, missing transverse momentum
  • Selections on a single type of physics process with common features, e.g. B-physics & light states, unconventional tracking (long-lived particles), Minimum Bias/Forward physics.
The ‘Combined’ signature is a catch-all for any mixture of signatures.
Signature groups are responsible for studying the performance of and maintaining the code responsible for a particular signature.
Super-RoI
A hybrid RoI creation mechanism in which RoIs corresponding to several individual objects are merged into a single composite RoI, on which a full-scan-like algorithm (e.g. tracking) can be executed. This avoids edge effects and overlaps from adjacent RoIs, and improves CPU efficiency.
Step
A unit of computation in the HLT part of a trigger chain comprising reconstruction and hypothesis elements. A step is activated if a preceding filter accepts the event. It then performs reconstruction, the output of which feeds the hypothesis algorithm, which then passes decisions onto the filter for subsequent steps. The reconstruction operation can be null, in which case the hypothesis decides based on other information produced in earlier steps. In turn, there are two special cases for the hypothesis logic: ‘passthrough’ or ‘streamer’ mode, which always returns a positive decision; or ‘reject’ mode, which always returns a negative decision. A step with no reconstruction and a passthrough hypothesis is called an Empty Step.
Stream
The union of all events accepted by a predefined list of HLT chains, with a given purpose which may be analysis of generic or specific physics processes, detector calibration or monitoring, etc. Each chain writes events to a unique stream, with the exception of the Express Stream used for monitoring, which is a very low rate subset of various other streams used for rapid data quality monitoring. If an event is accepted by chains that feed multiple streams, it is written to all of them. Each stream is configured with a fixed Event Building configuration determining what content is recorded; this ranges from HLT objects for Trigger Level Analysis, to a limited quantity of subdetector data in Partial Event Building streams, to the entire detector event in Full Event Building streams.

Data Acquisition (DAQ) system terms

DataFlow system
The system handling transfer of detector data to the L1 and HLT, and transfer of accepted event data out of Point 1 to permanent storage
Detector Control System (DCS)
TDAQ system comprising the control of the sub-detectors and of the common infrastructure of the experiment and the communication with the services of CERN (cooling, ventilation, electricity distribution, safety etc.) and the LHC accelerator.
Event
All ROB fragments from the same bunch crossing. Identified by run number and global event identifier after event building
Event Builder
Part of the data flow system, it merges all the fragments belonging to a unique extended Level-1 identifier into a full event at a single destination and assigns a global event identifier.
Event Format Library (EFL)
A software library used across TDAQ to pack and unpack event fragments.
Event Fragment
A generic term for a sub-set of event data. Specific instances of an event fragment are ROD, ROB, ROS and sub-detector fragments.
Online Software System
All the software for configuring, controlling and monitoring of the TDAQ system. It excludes the management, processing and transportation of physics data.
Read-Out Buffer (ROB)
The buffer which receives data from one Read-Out Link, which is the physical link between ROD and ROS through which the data are sent at the event rate of the LVL1 trigger accept.
Read-Out Driver (ROD)
The ROD is part of the electronics. The ROD is the detector specific Front-End Functional element which gathers data from the derandomizers over one or more data streams and builds ROD fragments of events to be sent to the ROS or the Region-of-Interest Builder (RoIB). It gathers data from Front End Boards (FEBs) and then sends fragments to ROB or RoIB.
Read-Out System (ROS)
The ROS is the part of the ATLAS DataFlow system that accepts data from the detector-specific readout drivers (RODs), stores it and makes it available to the HLT until told to delete it.
Run
A continuous period in time of data taking using a given hardware and software configuration and a defined set of run parameters. It is identified by a unique run number. The run begins when the TDAQ, detectors and other sub-systems are correctly configured and the machine conditions are acceptable. : A run terminates either cleanly when the pre-defined goals of the run are met (e.g. a certain number of events have been taken) or aborts when a serious unexpected problem occurs (e.g. loss of the beam or unacceptable machine conditions etc.), or when the configuration changes.
Sub-Farm Output (SFO)
System that collects events accepted by HLT, then transfer them to permanent storage at CERN T0. In addition, the SFOs have sufficient storage capacity to buffer events temporarily in case of data transfer problems.