1. Trigger Systems at LHC Experiments
Institute of High Energy Physics of the Austrian Academy of Sciences`
Trigger Systems at LHC Experiments
Manfred Jeitler
Instr-2008, Novosibirsk, March 2008

2. first particle physics experiments needed no trigger
were looking for most frequent events
people observed all events and then saw which of them occurred at which frequency

3. later physicists started to look for rare events
“frequent” events were known already
searching “good” events among thousands of “background” events was partly done by auxiliary staff
“scanning girls” for bubble chamber photographs

4. Higgs -> 4m
+30 MinBias

5. it would not even be possible to record all data in computer memories
due to the extremely small cross sections of processes now under investigation it is impossible to check all events “by hand”
~ 1013 background events to one signal event
it would not even be possible to record all data in computer memories
we need a fast, automated decision (“trigger”) if an event is to be recorded or not

6. detectors yielding electrical output signals allow to select events to be recorded by electronic devices
thresholds (discriminators)
logical combinations (AND, OR, NOT)
delays
available in commercial “modules”
connections by cables (“LEMO” cables)

7. because of the enormous amounts of data at major modern experiments electronic processing by such individual modules is impractical
too big
too expensive
too error-prone
too long signal propagation times
 use custom-made highly integrated electronic components (“chips”)
400 x
 x
~ 10 logical operations / module  ~ logical operations in one chip

8. example: trigger logic of the L1-trigger of the CMS experiment

10. When do we trigger ? „bunch” structure of the LHC collider
„bunches” of particles
40 MHz
a bunch arrives every 25 ns
bunches are spaced at 7.5 meters from each other
bunch spacing of 125 ns for heavy-ion operation
at nominal luminosity of the LHC collider (1034 cm-2 s-1) one expects about 20 proton-proton interactions for each collision of two bunches
only a small fraction of these “bunch crossings” contains at least one collision event which is potentially interesting for searching for “new physics”
in this case all information for this bunch crossing is recorded for subsequent data analysis and background suppression
luminosity quoted for ATLAS and CMS
reduced luminosity for LHCb (b-physics experiment)
heavy-ion luminosity much smaller

11. the LHC experiments 4 major experiments 3 different main physics goals
“general purpose”: Higgs, Susy, : ATLAS+CMS
b-physics: LHCb
heavy ion physics: ALICE
different emphasis on trigger:
ATLAS+CMS: high rates, many different trigger channels
LHCb: lower luminosity, need very good vertex resolution (b-decays)
ALICE: much lower luminosity for heavy ions, lower event rates, very high event multiplicities

12. trigger: first level high level ATLAS, CMS 40 MHz  100 kHz  100 Hz
LHCb 40 MHz  1 MHz  kHz
ALICE 10 kHz  1 kHz  Hz
Event size (bytes)

13. How do we trigger ?
use as much information about the event as possible
allows for the best separation of signal and background
ideal case: “complete analysis” using all the data supplied by the detector
problem: at a rate of 40 MHz it is impossible to read out all detector data
(at sensible cost)
have to take preliminary decision based on part of the event data only
be quick
in case of positive trigger decision all detector data must still be available
the data are stored temporarily in a “pipeline” in the detector electronics
“short term memory” of the detector
“ring buffer”
in hardware, can only afford a few μs
how to reconcile these contradictory requirements ?
write
read

14.  multi-level trigger
first stage takes preliminary decision based on part of the data
rate is already strongly reduced at this stage
~1 GHz of events (= 40 MHz bunch crossings)  ~100 kHz
only for these bunch crossings are all the detector data read out of the pipelines
still it would not be possible (with reasonable effort and cost) to write all these data to tape for subsequent analysis and permanent storage
the second stage can use all detector data and perform a “complete analysis” of events
further reduction of rate: ~100 kHz  ~100 Hz
only the events thus selected (twice filtered) are permanently recorded

15. How does the trigger actually select events ?
the first trigger stage has to process a limited amount of data within a very short time
relatively simple algorithms
special electronic components
ASICs (Application Specific Integrated Circuits)
FPGAs (Field Programmable Gate Arrays)
something in between “hardware” and “software”: “firmware”
written in programming language (“VHDL”) and compiled
fast (uses always same number of clock cycles)
can be modified at any time when using FPGAs
the second stage (“High-Level Trigger”) has to use complex algorithms
not time-critical any more (all detector data have already been retrieved)
uses a “computer farm” (large number of PCs)
programmed in high-level language (C++)

16. How does the trigger actually select events ?
the first trigger stage has to process a limited amount of data within a very short time
relatively simple algorithms
special electronic components
ASICs (Application Specific Integrated Circuits)
FPGAs (Field Programmable Gate Arrays)
something in between “hardware” and “software”: “firmware”
written in programming language (“VHDL”) and compiled
fast (uses always same number of clock cycles)
can be modified at any time when using FPGAs
the second stage (“High-Level Trigger”) has to use complex algorithms
not time-critical any more (all detector data have already been retrieved)
uses a “computer farm” (large number of PCs)
programmed in high-level language (C++)
see Marta Felcini’s talk tomorrow

17. ATLAS+CMS: what’s the difference ?
similar task
similar conditions
similar technology

18. ATLAS+CMS: what’s the difference ?
similar task
similar conditions
similar technology
ATLAS+CMS: what’s the difference ?
let’s hope both ATLAS and CMS will fly ....
.... and none will crash

19. ATLAS+CMS: what is common ?
same physics objectives
same input rate
40 MHz bunch crossing frequency
similar rate after Level-1 trigger
kHz
similar final event rate
Hz to tape
similar allowed latency
pipeline length
within this time, Level-1 trigger decision must be taken and detectors must be read out
~ 3 μs
2.5 μs for ATLAS, 3.2 μs for CMS

20. ATLAS+CMS: what is different ?
different magnetic field
toroidal field in ATLAS (plus central solenoid)
get track momentum from η (pseudorapidity)
solenoidal field only in CMS
get track momentum from φ (azimuth)
number of trigger stages
two stages (“Level-1” and “High-Level Trigger”) in CMS
ATLAS has intermediate stage between the two: “Level-2”
Level-2 receives “Regions of Interest (RoI)” information from Level-1
takes a closer look at these regions
reduces rate to 3.5 kHz
allows to reduce data traffic

21. ATLAS+CMS: which signals are used by the first-level trigger ?
muons
tracks
several types of detectors (different requirements for barrel and endcaps):
in ATLAS:
RPC (Resistive Plate Chambers): barrel
TGC (“Thin Gap Chambers”): endcaps
not in trigger: MDT (“Monitored Drift Tubes”)
in CMS:
DT (Drift Tubes): barrel
CSC (Cathode Strip Chambers): endcaps
RPC (Resistive Plate Chambers): barrel + endcaps
calorimeters
clusters
electrons, jets, transverse energy, missing transverse energy
electromagnetic calorimeter
hadron calorimeter
only in high-level trigger: tracker detectors
silicon strip and pixel detectors, in ATLAS also straw tubes
cannot be read out quickly enough

22. how to find muon tracks ? (CMS: solenoidal field)

23. calorimeter trigger

24. ATLAS+CMS: principle of the first-level trigger
data are stored in “pipelines” for a few microseconds
e.g. in CMS: 3.2 s = 128 clock cycles at 40 MHz
question of cost
decision must never take longer! (must be synchronous!)
 no iterative algorithms
decision based on “look-up tables”
all possible cases are provided for
OR, AND, NOT can also be represented in this way

25. principle of event selection: ATLAS vs. CMS
Level-1 trigger delivers numbers of candidate objects
muon tracks, electron candidates, jets over appropriate threshold
no topological information used (no angular correlation between different objects)
Level-2 trigger carries out detailed analysis for “Regions of Interest”
using complete detector information for these regions
High-Level trigger analyzes complete detector data for the whole detector
CMS:
no “cuts” at individual low-level trigger systems
only look for muons, electrons, jets, choose the “best” of these candidate objects and forward to Level-1 Global trigger
so, all possible kinds of events may be combined
selection is only made by “Level-1 Global Trigger”
trigger information from all muon detectors and calorimeter systems available: completely flexible
High-Level trigger analyzes complete detector data for the whole detector

26. LHCb: the challenge study b-meson decays
need very good vertex resolution
lower luminosity
2  1032
50 times lower than ATLAS and CMS
aim at having only one proton-proton collision per bunch crossing
to correctly attribute primary and secondary vertices: “pile-up protection”
important difference from ATLAS & CMS !
achieved by deliberately defocusing the beam
detector looks rather like a fixed-target experiment
concentrate on forward direction
single-arm forward spectrometer
can take useful data at initial low-luminosity LHC operation

27. LHCb: the approach Level-0 trigger High-Level trigger
implemented in hardware
reduction from 40 MHz bunch-crossing rate down to 1 MHz
10 times more than ATLAS or CMS !
allowed latency: 4 μs
reject pile-ups (several proton collisions in one bunch crossing)
uses also vertex detector (“VELO”, VErtex LOcator)
different from other LHC experiments
alongside muon and calorimeter information
High-Level trigger
computer farm, using full detector information
reduce data rate to 2 kHz
20 times more then ATLAS or CMS

28. ALICE: the challenge study heavy-ion collisions
quark-gluon plasma
study also proton-proton interactions for comparison
lower bunch-crossing frequency and luminosity for heavy ions
bunches arrive every 125 ns
luminosity: cm-2 s-1
factor of 10 millions below proton-proton luminosity
rate: 10 kHz for lead-lead collisions
200 kHz for proton collisions
enormous complexity of events
tens of thousands of tracks per event
per pseudorapidity interval: dN / dη ~ 8000

30. ALICE: the approach
detectors can be slower, but must cope with high track multiplicity
 choice of Time Projection Chamber (TPC) as principal tracking detector (drift time up to 100 μs !)
no spatial correlation of objects in first-level trigger
is done by High Level Trigger, which has much bigger time budget
“past-future protection”: protect against pile-up of events from different bunch crossings
some detectors are faster than the TPC  for certain studies, read out only them
“detector clusters”
only LHC detector which aims at analyzing partial events

31. ALICE: the approach
detectors can be slower, but must cope with high track multiplicity
 choice of Time Projection Chamber (TPC) as principal tracking detector (drift time up to 100 μs !)
no spatial correlation of objects in first-level trigger
is done by High Level Trigger, which has much bigger time budget
“past-future protection”: protect against pile-up of events from different bunch crossings
some detectors are faster than the TPC  for certain studies, read out only them
“detector clusters”
only LHC detector which aims at analyzing partial events

32. ALICE: the trigger structure
no pipeline (as in the other LHC experiments)
trigger dead-time
only one or a few events can be buffered at low level before readout
several low-level triggers with different latencies for different subdetectors
Level-0: μs
Level-1: μs
Level-2: 88 μs
computer farm for High-Level Trigger

33. Where we are today ...
trigger is one of the most challenging and important tasks in major experiments at modern hadron colliders
at LHC, very similar setup for most experiments
only heavy-ion experiment ALICE differs significantly
when accelerator goes online, we will see which solutions are most appropriate
draw lessons for the future

34. ... and where do we go from here?
upgrading the LHC to Super-LHC makes sense only if trigger systems are upgraded at the same time
ATLAS and CMS will have to use their trackers in the first-level trigger
but this is easier said than done
remember Hans-Jürgen Simonis’ comments on the CMS tracker
probably, computers will get faster and more (all?) trigger processing will be done in software
stay tuned ... and help!

35. THANK YOU
Спасибо to the organizers of Instr for inviting me to give this presentation
Thanks to all members of the ATLAS, CMS, LHCb and ALICE collaborations who helped me to prepare it

36. backup

37. structure of the ATLAS Level-1 trigger

38. structure of the CMS Level-1 trigger

39. LHCb: the detector