Transcript Document

Architecture of the ATLAS
High Level Triggers
Event Selection Software
Nikos Konstantinidis (UCL)
on behalf of the ATLAS HLT group
Frontier Detectors for Frontier Physics
Elba, May 25-31, 2003
Outline

Introduction
• The Trigger/DAQ challenges of the LHC
• The ATLAS Trigger

Event selection @ High Level Triggers (HLT)
• Event selection Strategy
• Software Architecture – Components

Conclusions – Outlook
Nikos Konstantinidis
The ATLAS HLT Event Selection Software
2
Trigger/DAQ at the LHC
CoM Energy
14 TeV
Design Luminosity
1034 cm-2 s-1
Interactions per x-ing
 23
Bunch spacing
25 ns
Nikos Konstantinidis
• High rate (40 MHz)
• High granularity  large
event size (1-2 MBytes)
The ATLAS HLT Event Selection Software
3
ATLAS Trigger Strategy
HLT
Nikos Konstantinidis
The ATLAS HLT Event Selection Software
4
LVL1
> Latency: 2.5ms (max)
> Hardware based (FPGA, ASIC)
> Calo/Muon (coarse granularity)
LVL2
>
>
>
>
>
Latency: ~10 ms (average)
Software (specialised algs)
Uses LVL1 Regions of Interest
All sub-dets, full granularity
Emphasis on early rejection
EF
ATLAS Trigger/DAQ – Overview
>
>
>
>
Latency: few sec (average)
Offline-type algorithms
Full calibration/alignment info
Access to full event possible
Nikos Konstantinidis
The ATLAS HLT Event Selection Software
5
HLT Strategy
Event Selection relies on:
• Processing in Steps
 Alternate steps of feature extraction / hypothesis testing
 Events can be rejected at any step if features do not fulfil
certain criteria (signatures)
Emphasis on early event rejection
• Reconstruction in Regions of Interest (RoIs)
 RoI size/position derived from previous step(s)
Emphasis on minimising
a. Processing time
b. Network traffic
Nikos Konstantinidis
The ATLAS HLT Event Selection Software
6
HLT Strategy – Example
LVL1 claims two isolated
e/m clusters with pT>20GeV
(possible signature: Z–>ee)
STEP 4
Signature 
Strategy at HLT:
STEP 3
> Validate step-by-step
> Check intermediate signatures
> Reject as early as possible
Signature 
STEP 2
e30
e
+
Cluster
shape
Level1 seed 
EM20i
e30
pt>
30GeV
+
track
finding
STEP 1
e30i
Iso–
lation
pt>
30GeV
ecand
The ATLAS HLT Event Selection Software
+
Iso–
lation
Signature 
Sequential/modular approach
facilitates tuning for early rejection
Nikos Konstantinidis
e30i
e
track
finding
+
time
Signature 
ecand
Cluster
shape
+
EM20i
7
HLTSSW – Design
HLT DataFlow
Software
Event Filter
Processing
Application
Package
HLTSSW
HLT Selection Software
Interface
Dependency
HLT Core Software
Level2
Steering
HLT Algorithms
Processing
Application
HLT
Algorithms
Data
Manager
ROBData
Collector
Event
DataModel

HLTSSW runs on the L2/EF processors

Several external dependencies
(Monitoring Svc, MetaData Svc, offline…)
Nikos Konstantinidis
The ATLAS HLT Event Selection Software
8
Core Components

Steering
• Controls the order in which HLT algorithms should run, given
the result of the previous triggering step
 All possible signatures form the Trigger Menu
 All possible sequences form the Sequence Table

Data Manager
• Handles the event data during processing
 Provides feature extraction algorithms with access to
data within an RoI
 Stores extracted data objects and can pass them to
hypothesis testing algorithms
Nikos Konstantinidis
The ATLAS HLT Event Selection Software
9
Data access by an HLT algo
Algorithm
HLT
Algorithm
Region
Selector
Transient
EventStore
Region
Selector
Data Access
Byte
Stream
Converter
Trans.
Event
Store
Data source
organized
by ROB
region
list DetElem IDs
list DetElem IDs
Data arranged
by DetElems
list DetElem IDs
Data arranged
by DetElems
ROB ID
raw event
data
DetElems: Detector Elements (e.g. Pixel wafers)
IDs: Identifiers – Allow access to Geometry and mapping to ROBs
For the Event Filter: data already in the TES
Nikos Konstantinidis
The ATLAS HLT Event Selection Software
10
Event Data and Algs

Closely coupled to offline software
• Common class definitions (Track, Cluster etc)
 Facilitate code migration between LVL2/EF/Offline
 Saves effort in development and maintenance
 Makes comparisons and performance studies easier
• Same arguments for data access mechanism

However, special online requirements (esp. LVL2)
• Timing
• Multi-threaded running
Nikos Konstantinidis
The ATLAS HLT Event Selection Software
11
Conclusions – Outlook

ATLAS HLT Event Selection designed to be
• Flexible (to allow easy revision/tuning of trigger menus)
• Robust (to cope with the unexpected – machine/detector)
• Inclusive (to account for the unexpected new physics)

Minimise CPU/network resources by
• Analysing only Regions of Interest (only a few % of full event)
• Stepwise processing

Exploit synergies with offline software amap
• Algorithms / Data objects (EDM) / Data access; Easier to:
 Compare Trigger vs. Offline performance
 Import offline algs to Event Filter
 Study LVL2 / Event Filter boundary

Evaluation of various design choices in progress
• Detailed conclusions in the HLT-DAQ TDR (due end of June)
Nikos Konstantinidis
The ATLAS HLT Event Selection Software
12