ATLAS High Level Trigger Steering

1
ATLAS High Level Trigger Steering

• Geneva Group Meeting Till Eifert
• 12th July 2006

• ATLAS Trigger
• High Level Trigger
• HLT Steering

2
Triggering at the LHC
s
rate
bunch crossing rate 40 MHz total interaction
rate 1 GHz event size 1.5 MB
total interaction rate
affordable 300 MB/s storage rate 200
Hz online rejection 99.9995
e.g. Higgs ? ZZ ? 2e2m
23 min. bias events 1725 particles/BC
storage rate
discoveries

• powerful trigger needed
• enormous rate reduction
• retaining the rare events in the very tough LHC
  environment

ET
3
ATLAS Trigger System
3-Level Trigger System

• LVL1 decision based on data from calorimeters and
  muon trigger chambers synchronous at 40 MHz
  bunch crossing identification
• LVL2 uses Regions of Interest (identified by
  LVL1) data (ca. 2) with full granularity from
  all detectors
• Event Filter has access to full event and can
  perform more refined event reconstruction

hardware
2.5 ms
10 ms
software
sec.
4
TDAQ Hardware Deployment
dual-CPU nodes
CERN computer centre
500
1600
100
30
Event Filter (EF)
Local Storage SubFarm Outputs (SFOs)
LVL2 farm
Event Builder SubFarm Inputs (SFIs)
Event rate 200 Hz
Second- level trigger
Data storage
pROS
DataFlow Manager
Network switches
stores LVL2 output
Network switches
LVL2 Super- visor
SDX1
Gigabit Ethernet
Event data requests Delete commands
Requested event data
Event data pulled partial events _at_ 100 kHz,
full events _at_ 3 kHz
Regions Of Interest
1600 Read- Out Links
150 PCs
VME
USA15
Read- Out Drivers (RODs)
Read-Out Subsystems (ROSs)
RoI Builder
Timing Trigger Control (TTC)
5
High Level Trigger - PCs

• 1 event lt-gt 1 PC (thread)
• Run (minimal) Athena software
• 1 Gaudi TopAlgorithm HLT Steering Controller -gt
  handles all (PESA) sub algorithms which do the
  reconstruction work
• HLT Steering Controller is common to L2 and EF
• PESA sub algorithms are different in general
• L2 algorithms work on RoIs
• EF algorithms have access to the whole event

6
HLT Introduction

• Selection Strategy
• RoI based -gt request as little as possible
• Step wise -gt reject as early as possible
• Minimizes CPU and network bandwidth, but adds
  complexity
• Need special algorithm scheduling, not just
  sequential list (like in the offline analysis) -gt
  Steering Controller
• Algorithms executed for RoI not for the whole
  event -gt offline reconstruction algorithms need
  wrappers/modifications

7
HLT Chains
1 chain
Stop chain, as soon as its signature is not
satisfied!
L1
Step 1 (L2)
L2
High Level Trigger
Step 2 (L2)
Step 1 (EF)
EF
Step 2 (EF)
Step 3 (EF)
1 signature

• Signature syntax e.g. 2e25ij90 2 x
  TE(e25i) AND 1 x TE(j90)

8
HLT - Sequences

• PESA algorithm name, input type(s), output type
  sequence
• Table of sequences -gt lookup which algorithm to
  run for a certain output TE type

• 2 types of PESA algorithms
• Feature extraction (FEX) producing the physical
  features
• Hypothesis (HYPO) checking whether features
  satisfy TE

9
HLT Steering components

• Configuration
• list of chains (having a signature for each step)
• sequence table
• from DB or XML files
• Level converter
• take results from previous level
• initialize corresponding chains
• create TEs, for Lvl1Conversion take all passed
  Lvl1 thresholds into account 1 EMRoI -gt TE e25,
  e20, e15, ..
• Main controller
• executes all active chains until all finished
  (either successfully done or failed)
• during each step, the chain classes try to
  satisfy their signatures by executing sequence
  classes
• sequence classes produce output TEs by executing
  PESA algorithms

10
HLT Steering components

• Things to keep in mind
• each PESA algorithm runs only once on one RoI
  (during one event)!
• each sequence is executed only once (during one
  event) !
• signature of a chain fails as soon as one
  sequence does not produce the required number of
  output TEs !
• Result builder
• summarizes the results of the chains into a bit
  pattern
• More issues
• topological Triggers more than one input TE
  type, e.g. B physics or Z-gtee
• sequence with several PESA algorithms
• prescaling (per chain) mechanism to artificially
  reduce number of otherwise accepted events
• forced accepts (per chain) do normal processing
  but always include chain (as if successful) into
  final result -gt event is accepted

11
HLT - Navigation
PESA Algorithms need to find features from
previous algs (e.g. track, cluster,..)
12
Summary

• Old (existing) code has several problems
• Concept of chains is missing !
• Possible execution of too many sequences
• Not object oriented
• No topological triggers
• New development is progressing well
• steering controller, chain, sequence, algo base,
  configuration classes in CVS (dev nightlies)
• topological triggers under development
• A lot of tests are needed -)