During data taking ATLAS sees a bunch crossing event every 25 ns, i.e., sees collisions (referred to as events) at an average rate of 40 MHz. That is far more events than we could read out from the detector, store to disk, or reasonable process afterwards. Luckily for the typical physics analysis, we are only interested in a small subset of the data, so we use a trigger system that selects those events that are interesting for physics analysis, and only those are stored to disk.
The ATLAS experiment has a two-level trigger system, consisting of the Level-1 Trigger (L1) and the High-Level Trigger (HLT). L1 gets only limited data from the detector systems, but can process all input events (i.e., every 25 ns). L1 runs very simple algorithms in FPGA hardware in about 2 microseconds, with and output rate of about 100 kHz. When an event is accepted by L1, it is moved from event buffers in the detector electronics to temporary storage space in the HLT computing farm. HLT has access to the full detector information and can run a simplified version of the full event reconstruction algorithms. HLT has an output rate of about 1.5 kHz and all events accepted by the HLT are sent to permanent storage.
There are two reasons why you may have to worry about triggers in your analysis:
The algorithms, corrections, and calibrations used by the triggers are different from the versions you use in analysis. This means the trigger selection may miss some events that your analysis selection would have picked up, even if the trigger nominally has a “looser” selection. If that happens your analysis will have to account for that.
Your analysis may want to use events that the trigger isn’t even designed to select in the first place. In that case your analysis group will have to work with the trigger group to add your analysis signature to the trigger, so events you care about will be recorded in the future.
There are several figures of merit that characterize the performance of triggers: the rate and efficiency of each trigger. Separate rates apply for the L1 and HLT components of each trigger. The figure below shows the efficiency for the single electron trigger as a function of the electron ET. The efficiency is the fraction of events in each bin of ET that are selected by the trigger.
Triggers requirements implemented at L1 are called L1 items, while those in the HLT are
called chains. Each HLT chain is seeded by an L1 item. For example, the single electron
trigger in 2018 was
HLT_e26_lhtight_nod0_ivarloose. This trigger has an ET
threshold of 26 GeV, applies likelihood tight ID for each electron, no impact parameter
(d0) requirement and loose, variable threshold isolation. The chain runs on on events
that are first selected in the L1 trigger by the L1 item
L1EM22VHI. More details on
the trigger naming scheme can be found at the
TriggerNamingRun3 twiki page.
The full trigger menu includes both triggers with a prescale of 1 (where every event is accepted) and triggers that are prescaled. A trigger with a prescale of 10 will accept 1 out of every 10 events. Prescales can be used separately at L1 and the HLT and can vary from run to run, as well as within a single run.
The majority of physics analyses use triggers that are unprescaled. You can find a full list of unprescaled triggers on the LowestUnprescaled twiki page.
Most analyses use unprescaled triggers for the main signal regions, many analyses also make use of prescaled triggers for control and validation regions.
Keep in mind that the method used in the trigger make approximations to make them run
fast – therefore the thresholds do not necessarily match the same threshold offline. Take
MET as an illustrative example (which is probably the most extreme case). The unprescaled
item in Run 2 was
L1_XE50. The efficiency curve shown in the figure below does not reach
85% efficiency until the offline MET value reaches around 150 GeV. These differences have
to do with all of the approximations and calibration effects that differ between offline
and the trigger.
You can read more about the trigger menu in each year in these references:
In your analysis, you need to ensure that you select events that were selected by a specific trigger (or list of triggers). To do this, you need to access the trigger decision via the trigger decision tool, which we will walk you through in this example.