Triggers: What, where, why, when and how

Transcription

1 Triggers: What, where, why, when and how ATLAS as an example (Other detectors do exist...) Alex Martyniuk (UCL) November 21, / 23 Alex Martyniuk

2 Triggering: What is it even? Triggering: A system/process to initiate a detectors readout system to record an event of potential interest Many modern particle physics experiments deploy multi-level trigger and data acquisition (TDAQ) systems to record their desired events I will concentrate on how the ATLAS experiment meets this challenge (personal bias) Hopefully I will explain each of these parts Disclaimer: Other detectors approach triggers in different ways, depending on their needs/challenges 2 / 23 Alex Martyniuk

3 Triggering: Why even trigger? First question: Why don t we just record every single event produced in ATLAS? Reason #1: The data rates are too damn high! Nominal LHC bunch crossing rate is 40MHz A raw ATLAS event is O(2MB) Back of the envelope, O(80 TB/s), O(288 PB/hr), O(6.9 EB/day) i.e. would need more storage than Google own after a few days... Silly... Also, the detector would likely be on fire (possibly literally) 3 / 23 Alex Martyniuk

4 Triggering: Why even trigger? Second question: Do we even want to record all events? Reason #2: Most events are really quite boring (subjectively) Of the total cross-section O(10 11 pb) Most collisions are inelastic Or jet production (it is a hadron collider) Interesting stuff (subjective) doesn t start for many orders of magnitude The more you record, the more you need to throw away later σ [pb] 4 / 23 Alex Martyniuk Standard Model Production Cross Section Measurements Status: July 2017 total (x2) ATLAS Preliminary inelastic Theory pp incl. dijets Jets R=0.4 pt > 25 GeV pt > 125 GeV pt > 100 GeV nj 1 nj 2 nj 3 γ fid. nj 0 nj 1 nj 2nj 1 nj 3nj 2 nj 2 nj 3 nj 4 nj 3 nj 4 nj 5 nj 4 nj 5 nj 6 nj 7 W fid. nj 0 nj 1 nj 5 nj 6 nj 6 nj 7 nj 7 Z fid. total nj 4 nj 5 nj 6 nj 7 nj 8 t t fid. Run 1,2 s = 7, 8, 13 TeV t-chan Wt s-chan Zt t tot. WW WZ ZZ WW WZ ZZ VV tot. WW WZ ZZ γγ fid. total ggf H WW H ττ VBF H WW H γγ H ZZ 4l H fid. WVVγ t tw fid. W γ Zγ fid. tot. t tz tot. t tγ fid. LHC pp s = 7 TeV Wjj EWK fid. Data fb 1 LHC pp s = 8 TeV Data 20.3 fb 1 LHC pp s = 13 TeV Data fb 1 W ± W ± WZ ZjjWWZγγWγγWWγ ZγjjVVjj EWK Excl. EWK EWK fid. tot. fid. fid. fid. fid. fid.

5 Triggering: How? ATLAS deploys a multi-level trigger system alongside its detector readout Level-1: Hardware based trigger Fast, 2.2µs latency Uses coarse data from calorimeters and muon system Reduces input rate to kHz High-level trigger (HLT): Software based trigger Slower, O(1s) latency Uses event data from all detectors Reduces input rate to O(1kHz) O(2GB/s) recorded to tape 5 / 23 Alex Martyniuk

6 Level-1 Architecture Level-1 Aims Hardware based trigger, with fast, 2.2µs latency due to pipelines Reduces input rate to kHz, partially dependent on detectors/readout Timing constraints only allow readout of calorimeters and fast-tracking detectors in muon system Clearly only a subset of detectors Need to reduce rate to allow full readout to occur Dedicated calo/muon hardware processors, digitise and interpret signals Pass to the CTP the multiplicity of thresholds passed (e.g. 2MU4) L1Topo can perform more complex checks, φ, M JJ... 6 / 23 Alex Martyniuk

7 Level-1 Items Only have muon/calorimeter information, but can do a lot with that Electrons, muons, taus, jets, ET miss, total energy When you add in L1Topo, this expands to many additional kinematic and topological lists/combinations L1 Calo Sliding window used in L1Calo, finds local maxima with isolation guard ring ( ) Similar method used for electrons/ photons/ taus/ jets Simple cone algorithm used in L1Topo ΣE T and ET miss done by summing towers L1 Items: Individual signatures that the processors search for and count the multiplicity of, e.g. J100, EM22VH, MU / 23 Alex Martyniuk

8 Level-1 Items Only have muon/calorimeter information, but can do a lot with that Electrons, muons, taus, jets, ET miss, total energy When you add in L1Topo, this expands to many additional kinematic and topological lists/combinations L1 Muon TGCs, RPCs and CSCs form the L1 Muon system (Yay, TLAs!) Form muon roads, connecting hits in the trigger chambers Provides ROI to HLT to search for combined tracks within L1 Items: Individual signatures that the processors search for and count the multiplicity of, e.g. J100, EM22VH, MU / 23 Alex Martyniuk

9 Level-1 HLT Handover Now have a list of multiplicities of L1 Items found in the event CTP takes all these inputs and checks against a menu If one item passes the entire event is read out and handed over to the HLT Read-out system (ROS) collects data from front-end boards Collates information from the whole detector into an event, which can be sent to HLT when it needs it Regions of interest (ROIs) Items passed with an ROI, so that the HLT does not have to look everywhere again Could then be combined at HLT into a super-roi Or ignored completely and perform a full-scan 8 / 23 Alex Martyniuk

10 Level-1: Bunch crossings LHC Fill Patterns Bunch structure matters for the L1 triggers Triggers formed by a logical OR of an L1 item and a type of bunch crossing: filled/empty paired/unpaired... Response of detectors also change depending on bunch position in train, affects rates Example of possible fill pattern issues: For example, the time taken for a the ionisation from a hadronic shower to be read out spans bunch crossings Many overlapping signals in the detector at the same time Pulse shape tries to smooth this out, but position of the bunch in the train can lead to over or under correction 9 / 23 Alex Martyniuk

11 Level-1: Dead time Deadtime Deadtime is there to halt the system in certain situations Simple Deadtime: After an event is recorded, no triggers can fire for a set number of bunch crossings Complex Deadtime: CTP modelled as a bucket with a hole If there is space for a trigger to be put in then it goes in the bucket No space then complex deadtime holds trigger until there is enough space Smooths the output rate of the system Backpressure through the system (detector read out issues, HLT farm on fire, e.t.c.) can also halt the system creating deadtime, want to keep this to a minimum 10 / 23 Alex Martyniuk

12 Backpressure == Bad Times! 11 / 23 Alex Martyniuk

13 HLT Farm HLT Farm Huge bank of 40k++ cores dedicated to running the HLT trigger Receives full event info, ROIs and L1 items fired Runs close to offline software to reconstruct objects in ROIs or the full event Menu of HLT chains decide whether to keep the event based on reconstructed objects Has O(1 s) in which to make its decision 12 / 23 Alex Martyniuk

14 HLT Alogrithms What is the HLT actually doing? Offline reconstruction too slow to run online 10s vs needed 1s Perform step-wise processing with early rejection to reduce time taken Streaming 1 Fast reconstruction Trigger-specific or special configuration of offline algorithms Guided by L1 ROIs 2 Precision reconstruction Offline (or close to) algorithms Full detector data available As soon as one step fails, stop processing! Events are always written out if any trigger passes Written to different streams depending on which trigger passed Can be written to a debug stream if something went wrong, i.e. timed out 13 / 23 Alex Martyniuk

15 Trigger Menu The trigger menu defines the physics program/reach of ATLAS, i.e. what it records Each physics signature defines a set of trigger chains The collection of all signatures form the full trigger menu The menu consists of: Primary physics triggers Support triggers Calibration and timing triggers Current menus contain around trigger chains Peak rate of 1.5kHz, average of 1kHz Menu varies with luminosity, time and running conditions Overall menu design driven by: Physics priorities Rate limitations at L1/HLT Online resources (CPU, bandwidth) 14 / 23 Alex Martyniuk

16 Prescaled Triggers Not all triggers need to or indeed can run at their full rate Rate might be too high A sub-sample might be enough to fulfil needs (support triggers) Adding in triggers as the luminosity naturally drops (unless levelling) leads to an optimal usage of resources Prescales used to reduce output rate Prescale of N means system accepts 1 out of N events Prescales can be fractional Can be applied at L1 and/or at the HLT Prescales can change during the run, i.e. can change the rate of a trigger, add it or remove it 15 / 23 Alex Martyniuk

17 Trigger Configuration Trigger Configuration This all has to hold together in a coherent way, to load into the hardware/farm and run the trigger on events Trigger Menu is stored in an Oracle database SMK: describes the contents of the L1/Topo/HLT menus L1PSK: Sets the L1 prescales HLTPSK: Sets the HLT prescales BGK: Describes the LHC fill pattern 16 / 23 Alex Martyniuk

18 What does an analyser care about? Three Main Things Where is the trigger turn-on? Where does the trigger reach maximal efficiency w.r.t. offline objects? What is the peak efficiency? Is it 100%? Or do you need a scale factor? Is it prescaled? Am I getting all the events? Or do I have to correct for a prescale? Turn on and peak efficiency are a function of: Resolutions Inefficiencies Online/Offline differences 17 / 23 Alex Martyniuk

19 Measuring efficiencies/turn ons How do you measure the efficiency of your trigger? Efficiency usually defined w.r.t. the objects reconstructed offline ɛ trigger = N trigger N offline Measure via various methods Tag-and-probe Trigger on one particle (the tag), e.g. leading muon from Z µµ, and measure how often the sub-leading (the probe) passes the trigger selection Boot-strap Use a sample triggered by a looser (prescaled) trigger to measure the efficiency of a higher threshold trigger Orthogonal trigger Use a sample triggered by one trigger (e.g. muon trigger) to measure the efficiency of a different trigger, e.g. a jet trigger (independent samples) Simulation/emulation Emulate the action of the trigger in your MC 18 / 23 Alex Martyniuk

20 Monte Carlo and Scale Factors Triggers have to be emulated in the simulated data (Monte Carlo) Problem is, MC samples are produced before data taking starts The MC production therefore contains a best-guess trigger menu to cover all known triggers Contains backups to emulate possible future triggers, cannot second guess everything though Differences between data/mc always slip in though Don t have perfect knowledge of the years run conditions, µ, instantaneous lumi etc The trigger menu is not always fixed, it reacts to changes Improvements or bug fixes added Therefore have to provide trigger scale factors Correct the MC to match the observed data Provided by trigger signature groups where necessary Parameterised as needed in p T, η, φ / 23 Alex Martyniuk

21 Challenges One major challenge to the trigger is pileup I.e. multiple pp collisions in the same bunch crossing, or the effect of collisions in adjacent crossings More collisions, means more tracks, more jets, more muons e.t.c. More objects to reconstruct takes more CPU and more time It is a long slog to get trigger objects to look flat in < µ > Tracking becomes more difficult and CPU intensive as tracks overlap Object isolation loses efficiency, harming one route to lower p T thresholds Event sizes increase, causing a knock on to the rate In short, nobody likes pileup (except maybe the jet trigger, we have crazy plans) 20 / 23 Alex Martyniuk

22 The course of true love never did run... The main problem with trigger systems is their permanent nature Make a cut in your analysis, you can undo it and try another one Make a cut in a trigger, that data is gone, even if your cut was wrong The ATLAS trigger system (other trigger systems are available) is incredibly complicated!!! Nothing could possibly go wrong right? Welllllll... This delightful example from the start of run-2 shows what can go wrong Above a certain energy trigger towers can saturate Pulse peak then lasts multiple bunch crossings Algorithm in place to pick the right bunch crossing from options This error was caused by a single 3 in a DB being set as 2 Meant saturated towers were assigned to the previous bunch crossing, thus triggering the previous event 21 / 23 Alex Martyniuk

23 Trigger Level Analyses Search analyses don t tend to like using prescaled triggers An automatic efficiency loss at the trigger level Signal events could be lost Prescales are there to keep rates under control Have another dial to tune though, event size Reduce the size of the event by only saving the objects you need for your analysis Can run unprescaled again (caveats exist) In this example, only save the leading few HLT trigger jets with selective variables Form the dijet invariant mass and push down below the threshold allowed by normal jet triggers 22 / 23 Alex Martyniuk

24 Summary hat I hope you take away... ATLAS deploys a two level trigger system Level-1: Fast first sweep with hardware thresholds HLT: Slower offline-like software reconstruction and decisions It is a complex, configurable system that aims to mesh the needs of the physics program with the capabilities of the detector As an analyser you should care about Does the trigger you need exist? When does it turn-on? Is it fully efficient? Or do you need a scale-factor? Is it prescaled? Remember: If you don t record the right events in the first place, your selection efficiency is always uestions? 23 / 23 Alex Martyniuk