Triggers For LHC Physics e daq... · 2013. 3. 1. · Bryan Dahmes (Minnesota) Summer Student...

Summer Student Lecture Program: Triggers for LHC Physics (17-18 July 2012)Bryan Dahmes (Minnesota) 1

Triggers For LHC PhysicsTriggers For LHC Physics

Bryan DahmesBryan DahmesUniversity of MinnesotaUniversity of Minnesota

[email protected]@cern.ch


Introduction● Some terminology● Motivation: Why do we need a trigger?

● Using LHC physics to set the scale● Explanation of the Trigger components

● Level 1 (L1) and High Level Trigger (HLT)● Features of ATLAS and CMS trigger system

● How a trigger interfaces with an analysis● Building a trigger and discussion of strategy

● Other fun (i.e. examples) with triggers


Terminology● Data is collected online

● Collision data recorded by the detectors● Physicists analyze this data offline

● Optimizing selection, estimating/modeling background, establishing limits, discovering New Physics, etc.

● The LHC delivers a lot of data, which we need to first select online

● The trigger is a fast online filter that selects the useful events for offline analysis


Why Do We Need a Trigger?

Low cross sectionLow rate

● Save the most interesting events for later● Simple trigger in e+e- colliders: Take (nearly)

everything


A Few LHC Facts

Multiple collisionsper crossing

25 nsec (design)between proton bunches

20 MHz


The LHC: Setting the Scale

Process σ (nb)Productionrates (Hz)

Inelastic 108 109

bb 5×105 5×106

W → ℓν 15 150

Z → ℓℓ 2 20

tt 1 10

Z' (1 TeV) 0.05 0.5

gg (1 TeV) 0.05 0.5

Higgs (100 GeV) 0.05 0.5

Higgs (500 GeV) 10-3 10-2

14 TeV, 1034 cm-2 sec-1

~~

-

-


New Physics Rate

Roughly one light (125 GeV) Higgs

for every 10,000,000,000pp interactions


PerspectiveJet d'Eau: 500 L/sec

Drop of water: Roughly 0.1 mL

1 in 10,000,000,000: Like looking for a single drop of water from the Jet d'Eau over 30 minutes


Keeping Events● “New Physics” is rare, and thus buried under

lots of “uninteresting” events● Do we really want to keep every event?

● This would be the only way to be sure we don't miss anything

● No, for (at least) two reasons● We would mostly be saving “background” events● But also...


Keeping Events● We can't save everything!

● Event size: about 1 MB● Event reconstruction time:

● 30 sec – 1 minute ● At a data rate of O(100 Hz)...

● O(100) MB/sec● O(few) PB/year

per experiment● Keeping every event

● O(100000) PB/year● Too big to store● Too big to reconstruct● Too big to analyze


Trigger = Rejection● Problem: We must analyze AND REJECT

most LHC collisions prior to storage● Solution: Trigger

● Fast processing● High rejection factor: 104 – 105

● High efficiency for interesting physics● If events fail the trigger, we don't save them!

● Flexible● Affordable● Redundant


Trigger Signatures

Also: Trigger on total transverse (or missing transverse) energy

High pT jets

High pT e,γ

High pT μ


Trigger Setup

Lvl-1

Lvl-2

Event Filter

Front end pipelines

Readout buffers

Processor farms

Switching network

Detectors

Front end pipelines

Readout buffers

Processor farms

Switching network

Detectors

Lvl-1

High LevelTrigger

40 MHz40 MHz

100 kHz100 kHz

3 kHz

O(100) HzO(100) HzReduce the datavolume in stages


Trigger Setup● Level 1: Custom hardware and firmware

● Reduces the rate from 40 MHz to 100 kHz● Advantage: speed

● Level 2: Computing farm (software)● Further reduces the rate to a few kHz● Reconstruct a region surrounding the L1 trigger object● Advantage: Further rejection, still relatively fast

● Level 3: Computing farm (software)● Store events passing final selection for offline analysis● Advantage: The best reconstruction


Trigger Setup● Level 1: Custom hardware and firmware

● Reduces the rate from 40 MHz to 100 kHz● Advantage: speed

● Level 2: Computing farm (software)● Further reduces the rate to a few kHz● Reconstruct a region surrounding the L1 trigger object● Advantage: Further rejection, still relatively fast

● Level 3: Computing farm (software)● Store events passing final selection for offline analysis● Advantage: The best reconstruction

High Level Trigger


Trigger Example: HiggsHiggs Selection

using the Trigger

Level 1:Not all

information available, coarse granularity



using the Trigger

Level 2:Improved reconstructiontechniques, improved ability to reject events



using the Trigger

Level 3:High quality

reconstruction algorithms using information from

all detectors


L1 Trigger● Custom electronics designed to make very fast decisions

● Application-Specified Integrated Circuits (ASICs)● Field Programmable Gate Arrays (FPGAs)

● Possible to change algorithms after installation● Must be able to cope with input rate of 40 MHz

● Otherwise trigger wasting time (and money) as new events keep arriving

● Event buffering is expensive, too● L1 Trigger: Pipeline

● Process many events at once● Parallel processing of different inputs as much as possible


L1 Trigger Latency

Less than 1 μs:On-detector processing,

cables to underground control room

Less than 1 μs:Cables back to detector in hall,

distribution to detector front-ends

Roughly 1 μsspent on Processing and Decision Logic


L1 Calorimeter Trigger

Example: ATLAS e/γ trigger● Sum energy in calorimeter

cells into towers● Search in 4x4 tower

overlapping, sliding window● Cluster: local maximum

within the window

Signatures for several physics objects● Electrons, photons (EM only)● Jets, τ leptons (EM+Had)● Sum ET, missing ET


L1 Calorimeter TriggerL1 Jets (CMS)

● Search in large 12x12 region● Centering the L1 jet: highest

ET 4x4 region

L1 Tau (CMS)● Search in a narrow 2x2 region● Jet = τ if no τ veto set

Offline jet


L1 Muon Trigger

Curved pT-dependent muon path requires

fast pattern recognition

5 GeV

6.5 GeV

15 GeV

25 GeV

50 GeV

100 GeV

CMS, η = 0 (simulation)

Rough estimate of muon pT determined frombending in magnetic field


L1 Muon Trigger

CMS Muon Trigger selects best four candidates per bunch crossing


Putting Everything Together● We still need a global decision

● We have the information, does the event pass?● Decision needs to be made quickly

Large Detectors

Small time/space (25 nsec, 7.5 m)

between collisions


Central/Global Trigger

● Muon and Calorimeter L1 outputs sent to L1 Central/Global Trigger

● Responsibilities of CTP/GT● Time-synchronize inputs● Combine inputs, apply trigger logic● Apply prescales● Busy (deadtime) logic● Issue L1 decision

ATLAS Central Trigger


Dead Time● Sending information from detector to DAQ takes time

● Too many events at once can clog the system, prevent new data from being analyzed

● L1 trigger rules control the flow of data● Dead time in short time

window surrounding an event accepted by L1

● Prevent too many triggers in longer time periods

● Inefficiency at the percent level, but unbiased

Example of deadtimedue to detector readout issues


L1 Track Trigger?

● L1 triggers use muon systems and calorimeters● Many thousands of channels, fast pattern recognition

● Tracking detectors● (Tens of) Millions of channels, complicated track reconstruction● Transmitting all data at 40 MHz prohibitive

● LHC experiments currently run without tracking at L1● Tracking at L1 expected for SLHC upgrades


Upgrade? But We Just Started!● Problem: We know that the rate of

interesting physics is low● Otherwise, we would have found it already! ● We need to produce many more collisions to quantify

the new physics, whatever it looks like● Solution: Increase the collision rate

● More bunches (50→25 nsec spacing)● More protons per bunch, tighter bunches● More crossings, more collisions per crossing

● These extra collisions produce...


Pileup

1032 cm-2s-11033 cm-2s-1

1034 cm-2s-1 1035 cm-2s-1

CMS Simulation: 300 GeV H→ZZ→eeμμ at various instantaneous luminosities


Pileup● LHC Design:

20 collisions per crossing● Today: Average

15-20 collisions per crossing● Multiple pp collisions per crossing

produce lots of low-energy background tracks

● Tracks from interesting process should still be isolated

Z→μμ with 25 reconstructed vertices


L1 Trigger at High(er) Collision Rate● L1 Trigger must cope with high collision rate

● Tighten trigger requirements to reject extra background● Trade-off: Possible loss of signal efficiency

● Multiple collisions per crossing impacts the L1 trigger● All this was “known” already, as part of the LHC detector design

● SLHC: New challenges


Higher Level Triggering● From L1 we expect a large rate (up to 100 kHz) of

events that “might be interesting”● These events are not kept yet (rate too high for

storage), but sent to the HLT for additional filtering● Massive commercial computer farm● ATLAS: L2 and L3 handled by separate computing farms

● Roughly 17k CPUs that can be freely assigned to either● CMS: Single computing farm (roughly 13k CPUs)

● Parallel processing, each CPU processes individual event

● Resources are still limited● Offline: Full reconstruction takes seconds (minutes)● Online latency: milliseconds (input rate dependent)


Making a Fast HLT● HLT is composed of hundreds of trigger algorithms

● Software design, so no strict limit on the number of algorithms● Each designed with a specific physics signature in mind

● Algorithm speed enhanced by various checkpoints● Opportunity to reject early and save processing time

L1 EM

TrackReconstruction

Electron?

CalorimeterReconstruction EM like? NO

NOYES


Making a Fast HLT● All algorithms (“trigger paths”) are executed in parallel

● Every trigger path is run to completion (i.e. we get yes/no)● The time to process an event depends mostly on the

slowest running trigger path● Multiple checkpoints speed up processing

● Run more complicated, slower, operations on fewer events

...


Example: HLT Electrons● Start from L1 e/γ seed with sufficient ET

● Reconstruct the cluster in EM Calorimeter● Is there enough

energy to continue?● Does the cluster shape look like

that of an electron/photon?● Make sure the cluster is

not a hadron (check Hadronic Calorimeter)

● Is the candidate isolated in the calorimeters?

● Electrons● Is there a track matched to the cluster?● Is the electron isolated in the tracker?

● Photons● Check for tracks pointing to the cluster

Loose description of CMSelectron/photon paths, Similar logic in ATLAS


Example: HLT Muons● Muons in CMS:

● Starting from L1 muon candidate, refit using the muon system

● Continue if sufficient pT

● Combine tracker hits with muon system to get a better pT measurement

● Keep the event if pT is large enough

● Muons in ATLAS:● At Level 2, using detector information from the region of interest,

assign muon pT based on fast look up tables● Extrapolate to the collision point and find the associated track● Is the muon isolated in the tracker, calorimeters?● Refine selection at L3, compute pT using Tracking information


The Evolution of the TriggerThe trigger (L1+HLT) is by design very flexible:

● Should always be able to respond to the present physics demand

● And demands can change quickly!

Example: 2010 LHC running● First collisions, luminosity

of 1027 Hz/cm2

● Initially possible to save nearly every pp collision

● Very simple HLT algorithms● Pass-through of L1 triggers● And then...


Evolution of the Trigger● From March-October 2010, instantaneous

luminosity increased rapidly to 1032

● 105 increase over roughly six months● Important to be able to adapt

quickly, using tools best suited for the conditions

Burj Khalifa (828 m)Dubai, UAE

Increase of ~104


HLT Path StructureThe simplest HLT paths:

Pass-through for L1No additional selection,

no bias with respect to L1


HLT Path StructureIn

crea

sed

com

ple

xity

, in

crea

sed

tim

e The simplest HLT paths: Pass-through for L1No additional selection,

no bias with respect to L1

Next Level: Confirm L1 object using higher granularity

detector informationFast reconstruction techniques,

improved resolution

Continue adding complexityImprove quality of trigger object,

approaching offline quality


HLT Timing

Photons, Jets, and some Muons

Examine L1 information Fast accept/reject

Triggers with more intensive algorithms

(e.g. Track reconstruction)

Overflow: Very intensive computation

Expected CMS HLT CPU Performance at 2x1032 Hz/cm²Sample: Minimum Bias L1-skim

Mean time is critical“Slow” events have a

large impact on average time


Trigger and DAQTrigger designs for

ATLAS/CMS reflect physics goals

Different trigger configurations

for LHCb, ALICE

LHC Experiments have much higher DAQ requirements than previous experiments


LHCb Trigger

HLT23 kHz

Software

HLT150 kHzHLT130 kHz

L0(Hardware)

1 MHz

High ET/pT

candidates

Inclusive+ExclusiveFull Reconstruction

InclusivePartial Reconstruction

Pile-up Veto


ALICE Central Trigger ProcessorUnique ALICE constraints

● Low rate of Pb-Pb collisions● Very large events● Slow tracking detector (TPC)

Three levels of hardware triggers


Trigger/DAQ Comparison


Summary● Very challenging to design a trigger setup for

LHC conditions● Very high rate of collisions● High rejection rates, “interesting physics” efficiency,

and speed required● Custom hardware at first level partially reduces the rate

● Coarse granularity, but very fast● Parallel computing (massive commercial

computing farm) complicated data analysis online● Trigger stages cooperate to reject uninteresting

data quickly


Triggers For LHC PhysicsTriggers For LHC Physics

Bryan DahmesBryan DahmesUniversity of MinnesotaUniversity of Minnesota

[email protected]@cern.ch


Reminder● Very challenging to design a trigger setup for

LHC conditions● Very high rate of collisions● Require high rejection rates, “interesting physics” efficiency...● ...and speed!

● Custom hardware at first level partially reduces the rate● Coarse granularity, but very fast

● Parallel computing (massive commercial computing farm) allows complicated data analysis online

● Trigger stages (L1 through HLT) cooperate to reject uninteresting data quickly


Preview● What will happen today

● Overview of trigger strategy, and how a good understanding of the trigger is important for analysis

● Some examples of the trigger in action


Trigger Interface with Analysis● As far as the data is

concerned, the trigger is the first step towards publication

● But the order is a bit backward for physicists

● Why?


Trigger Interface with Analysis● Physicists start with an

analysis idea● Determine what you want to look

for (i.e. where you want to go)● Then figure out how to

select the data● There is little point in trying to do

an analysis if every “interesting” event fails the trigger

● Want to build a trigger that has loose requirements that you tighten up offline

● Design a trigger to meet analysis goals, but...


Competing for Data● There are hundreds to thousands of physicists on an

LHC collaboration● All are competing for the same resources● Only O(100) Hz of collision data available

● At L = 1034, this is roughly the rate of W→ℓν production!● How do you make sure your (very important) data is

kept for later analysis?● Need to meet physics needs with limited bandwidth

● Cutting at the trigger level throws away data forever● Potential bias to events that you analyze● Loss of interesting data

“The Trigger does not determinewhich Physics Model is right,

only which Physics Model is left”


Trigger MenusTriggers are created for a specific analysis,

but the Physics Goals of the experiment determine where the events can be most useful

Jets, MET: 30%b, Tau: 15%Electrons: 25%Muons: 30%“Support” Triggers: 10%

Jets, MET, Tau: 15%Electrons: 25%Muons: 25%“Support” Triggers: 50%

Trigger Menus: All triggers used to collect data for a given run period

L = 2x1032 Hz/cm2

Rate ~ 300-500 HzL = 2x1033 Hz/cm2

Rate ~ 200-300 HzL = 8x1029 Hz/cm2

Rate ~ 200-300 Hz (*)

Breakdown of sample CMS trigger menus

Early-Mid 2010End 2010

2011(*) Numbers and fractions approximate, and do not account for trigger overlap

Jets, etc.: 20%Tau: 5%Electrons: 20%Muons: 20%Cross Triggers: 20%“Support” Triggers: 5%

At present, roughly 500 triggers

in each menufor ATLAS/CMS


Trigger Menus

Object breakdown for present instantaneous luminositiesof (nearly 7 x 1033 s-1cm-2 at the start of a fill)


Trigger Menus

Object breakdown for present instantaneous luminositiesof (nearly 7 x 1033 s-1cm-2 at the start of a fill)


Menu Forecasting

We must predict the trigger menu behavior at each new step up in

instantaneous luminosity

Observed rate as a functionof luminosity section

Predicted rate,Corrected for dead time

Trigger rates for new menus determined from large minimum bias samples

Linear extrapolation based on increased luminosity

Some trigger ratesalso affected by pileup

CMS Double Electron Trigger

Luminosity section


Pileup● Some triggers can be very sensitive to pileup

● Low thresholds● Loose requirements

● Increasing requirementsor improving the trigger algorithmscan stabilizetrigger performance


Calibration Triggers● Additional triggers used for detector calibration● Calibration triggers in CMS

● Save only small portion of detector information● Allows O(kHz) output rate

Collect π0 for CMS ECAL

Fast reconstruction of π0 peak(using 200 seconds of data from

first 7 TeV collisions, 2010)

Similar techniques employed by ATLAS


Building a Trigger● Imagine you need events with a Z boson

● Standard Model, Higgs→ZZ, useful for Z' searches, ...● How do you collect these events online?


Trigger Strategy● Isolated high pT leptons are rarely

produced in a typical pp collision● Every Z decay has two of them!● So, construct a trigger that requires high pT leptons

● General strategy for building a trigger● The simpler, the better● Be as inclusive as possible● Robust design● Redundancy


Understanding Triggers● Simple triggers are

● Easier to commission● Easier to debug● Easier to understand

● If possible, create a new (tighter) trigger from an older (more inclusive) trigger

● At high rate, or limitedbandwidth, more inclusive triggers tend to be prescaled

Trigger Strategy● Simple● Inclusive● Robust design● Redundancy


Aside: Prescaling Triggers● Triggers start out as

loose as possible● Low pT thresholds● Minimum requirements

● Bandwidth needs change, loose triggers become tighter or get prescaled

● Looser triggers may still be useful for efficiency, calibration, analysis support, etc.

● Prescaling● Take 1 out of every N events

● ATLAS prescaler allows you to take x out of every N events (with x not necessarily 1)

● Usually used to deliver a small fraction of the nominal trigger rate

● O(1 Hz) or less is typical

Simulated rate evolution for an LHC Fill

Collection of “primary” triggers

“Support” triggers

Total rate

Support triggers typically provideSamples of low ET events

Events passing looser requirements

Prescale early to reduce processing time


Trigger Efficiency● In order to determine a cross section, you need to know your

selection efficiency● Detector acceptance● Reconstruction efficiency● Trigger efficiency

● Your trigger is used to collect your data● You cannot blindly use your data to study efficiency

● Need an unbiased measurement of trigger efficiency

● Random sample of pp collisions● Events collected by an

orthogonal trigger● Use events collected by

a looser (prescaled) trigger● Tag-and-Probe sample


Trigger Efficiency● Trigger efficiency is

usually measured as a function of pT and/or detector position

● We often speak of a trigger “turn-on” curve

● The turn-on curve should be as sharp as possible

● Prevents working in a region with unstable efficiency● Even when flat, the efficiency may not be 100%

● Important to consider in the analysis

Trigger efficiency forcentral (barrel) muon


CMS Electron Trigger TurnOn

Adjust trigger conditions to account for a changing detectorIncreased luminosity, increased light loss in CMS EM calorimeter

Sin

gle

Ele

ctro

n T

rigg

er E

ffic

ien

cy


Online Selection Evolution● Initially, we started with a single lepton trigger

● Efficiency for Z events was very high● Take our (hypothetical) single muon trigger

as an example● Let's say we estimated the muon efficiency to be

90% using tag and probe techniques● Our trigger efficiency for Z→μμ should be...


Online Selection Evolution● Initially, we started with a single lepton trigger

● Efficiency for Z events was very high● Take our (hypothetical) single muon trigger

as an example● Let's say we estimated the muon efficiency to be

90% using tag and probe techniques● Our trigger efficiency for Z→μμ should be...99%

9%+9%=18%Probability that only one muon

triggered the event

1%Probability that neither muon

triggered the event

81%Probability that

both muons triggered the event


Online Selection Evolution● By using minimal (simple) trigger strategies, we

have nearly 100% efficiency in our selection● By making our trigger more complicated by

adding a second muon (or electron), our efficiency drops

● Must account for such effects in the analysis

9%+9%=18%Probability that only one muon

triggered the event

1%Probability that neither muon

triggered the event

81%Probability that

both muons triggered the event


Back to Our Trigger Design...● So, we wish to collect events with Z decays online

● What should we do?● Easiest solution: Use single lepton triggers

● Two leptons (electrons or muons) from the Zas either could trigger the event

● If you choose a double lepton trigger, you are insisting online that both leptons pass trigger requirements

● Best to wait until you must do this● Determined by LHC conditions,

physics goalsTrigger Strategy

● Simple● Inclusive● Robust design● Redundancy

What is done onlinecannot be undone...


When Simple is no Longer Possible● LHC continues to increase luminosity

● Initially by adding more colliding bunches● Once maximum number of bunches

reached, increase number of protons per bunch

● Busier events as mean number of collisions per crossing increases

● Control the trigger rate by increasingsignal purity


Be Inclusive● What happens if your trigger has a large rate?

● Remember, we can only save O(100) events/second● Possible solution: Get Help!● Hopefully many physics analyses (besides yours)

could use the same trigger● Likely we are not the only group looking for lepton triggers

● Standard Model: Z, W, top● SUSY● Exotic signatures● ...

● A trigger is easier to keep if most of the collaboration is using it



Robust Design● Your trigger is going online, so it

should run on every kind of event● Prepare for “real life”, which

includes pathological events● Minimize (to ZERO) the

number of crashes due to trigger design ...when life might look like this

Don't design your trigger expecting this...


H→ZZ→4μ (and 25 pileup events),

with and without pT > 25 GeV track requirement


Aside: Splash Event

“Splash” events produce a very busy detector these eventsare for commissioning purposes

(and nice pictures) only

Extraordinarily busy detector can cause strange behavior in trigger algorithmsIncluding timeouts and crashes


Example: Missing ET at D0● Missing transverse energy is a signature of

many New Physics signatures● Attractive as a trigger idea

● It is also very susceptible to detector problems or beam conditions

● Dangerous as the sole trigger option foran analysis


Redundancy● It is very useful if your analysis can be selected

using more than one trigger● Will help understand any potential trigger bias● If one trigger has problems (detector or LHC conditions leading to

higher rate), you can still get your data● Try to introduce tighter triggers online before they are necessary

● Allows triggers to collect data before they are strictly necessary● Provides consistency for physics analysis, opportunity to study new

trigger on existing data


If anyone's got a Plan B, now would be a good time


Summary: Z Trigger● Trigger strategy with a concrete example● Collecting Z events using single electron, single muon triggers

● High pT, isolated leptons are rare in pp collisions● Much of the physics (and hence the detectors) designed around this fact

● Lots of consumers in the community, so we can use a “common” trigger● (Let's assume that the trigger

has been robustly tested and is working without problems online)

● We have back-up (redundant) triggers in place and ready for higher luminosity

● Single electron/muon triggers with tighter requirements

● Double electron, double muon triggers also ready

CMS Integrated Luminosity per day, 2010


And Now...the Analysis

W/Z cross section measurementat 8 TeV (CMS, SMP-12-011)

ZZ* to four leptons2011/12 data (CMS, HIG-12-016)

Once you have the data, analysis awaits!


Moving Forward● You should always look ahead, even when working

with the data you have● Always more to explore, additional properties to investigate

● The LHC is constantly improving● Higher instantaneous luminosity, so rate of W, Z, H, ... production

constantly increasing● Very likely that our first trigger

idea is now obsolete● Improvements in software will

increase efficiency● Additional filters in trigger

path increase purity● But these filters reduce efficiency

● Is it time to move to double electron/muon triggers?

Most Important: How do our trigger choices impact the analysis, and how do we adapt?


Another Perspective on Evolution● Great expectations for LHC physics

● Discovery of new physics phenomena● Precision tests of SM at high energy

● Physicists are impatient● All want to look at the data NOW, but must “fight”

for trigger bandwidth● Leads to higher purity triggers

● More selection applied online● Lower rate, higher thresholds● Negative impact on physics?


Data Parking● Data rate limited by offline resources

● Keep only what we can process● LHC shutdown in 2013● Opportunity to save data now,

process later● Physics with “new” data,

even during shutdown Total rate “core” “parking”


Fun With Triggers● Some “real world” examples to help illustrate what can

be done with triggers● Helps illustrate the power and flexibility of the triggers

● Example: The CDF “bump”● Recent results from CDF

imply an excess in dijet mass distribution for W+2 jets events

● CMS trigger menu was adjusted to collect extra events with this signature


Data Scouting● Events rejected online by the trigger can never

be recovered● What if we have the wrong picture of Nature, and are

insensitive to New Physics due to our bias?● Use the trigger to search for something new

● Keep events with ET sum for jet objects above 250 GeV● Minimize event size to deal with rate

● If you see something interesting● Trigger menu is configurable● Design a trigger to study

strange events


Fun With Triggers: LongLived Particles

● Several SM extensions predict particles with long lifetimes

● One such example (of several): “Split” SUSY, with gluino lighter than squark and decaying via R-parity conserving virtual squark

“R-hadrons” become stopped in the detector


LongLived Particles● Long-lived particle decays will be uncorrelated

with proton-proton collisions● Once stopped, could decay seconds, hours, days later

● Look for decays when CMS should be “quiet”● Record data during collision-free periods● Backgrounds from detector noise, cosmic rays


LongLived Particles● Trigger on jet-like

signature only when no beam in detector

● Also trigger on detector noise, cosmic rays

● Backgrounds studied prior to first collisions

Calorimeter Noise

Signal Decay (Simulation)


LongLived Particles

CMS EXO-11-020

Exclusion limits extend over13 orders of magnitude (~100 nsec to 106 sec),

depending on mass and model assumptions


Fun with Triggers: The “Ridge”● In early 2010, CMS started collecting a sample of events

with high track multiplicity● Useful for minimum bias studies● Performance studies,

looking ahead to high pileup conditions

● Examine two-particle angular correlations, and compare to those seen in relativistic heavy ion collisions


The Ridge● Design a trigger path to collect these events

● Level 1: Look for energy (60 GeV)● Reconstruct tracks at HLT● Keep the events if track multiplicity is high enough

● Enhanced selection statistics by O(103)● During Summer 2010, roughly 1/3 of the total

HLT CPU resources were spent on this trigger● First time at a hadron collider● Highlights the flexibility of the HLT


ResultsHigh Multiplicity events, N(trk) > 110Minimum Bias events, no multiplicity cut

Ridge-like structure at Δφ ~ 0, extending to large Δη (not expected)

First observation of such a long-range, near-side feature in pp collisions


ResultsHigh Multiplicity events, N(trk) > 110

First observation of such a long-range, near-side feature in pp collisions

Ridge-like structure at Δφ ~ 0, extending to large Δη


Summary● The trigger systems at the LHC experiments are designed

to handle a large influx of data, rejecting most uninteresting events quickly while maintaining a high efficiency on interesting events

● Successful trigger operations essential for discovery of New Physics phenomena

● Creating a trigger menu requires balancing the needs of the collaboration in order to record all the most interesting event signatures

● The trigger menu evolves over time, reflecting the current LHC/detector conditions and physics goals

● Challenging work, but very rewarding!


Thanks

Many thanks to those who provided material for these lectures!

Brian Petersen, Jamie Boyd, Wesley Smith, Monica Vazquez Acosta, Stephanie Beaceron,

Jeremiah Mans, Christoph Schwick, Christos Leonidopoulos, Len Apanasevich,

Greg Landsberg, Roel Aaij, David Evans


References● https://indico.cern.ch/conferenceDisplay.py?confId=129787● https://indico.cern.ch/conferenceDisplay.py?confId=115062● https://indico.cern.ch/materialDisplay.py?

contribId=22&materialId=slides&confId=108003● http://cmsdoc.cern.ch/~cschwick/talks/talkdata/Roma-Trigger.pdf● https://indico.cern.ch/getFile.py/access?

contribId=227&sessionId=74&resId=0&materialId=slides&confId=181298

● http://indico.cern.ch/contributionDisplay.py?contribId=683&sessionId=74&confId=181298

● http://www.hep.wisc.edu/wsmith/docs11/smith_tridaq_tipp11.pptx● http://indico.cern.ch/contributionDisplay.py?

sessionId=19&contribId=474&confId=102998


TwoParticle Correlations

Date post:	31-Mar-2021
Category:	Documents
Upload:	others
View:	1 times
Download:	0 times

Triggers For LHC Physics e daq... · 2013. 3. 1. · Bryan Dahmes (Minnesota) Summer Student...

Documents