120 likes | 209 Views
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
E N D
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 The ATLAS HLT Event Selection Software
Trigger/DAQ at the LHC • High rate (40 MHz) • High granularity large event size (1-2 MBytes) The ATLAS HLT Event Selection Software
ATLAS Trigger Strategy HLT The ATLAS HLT Event Selection Software
ATLAS Trigger/DAQ – Overview > Latency: 2.5ms (max) > Hardware based (FPGA, ASIC) > Calo/Muon (coarse granularity) LVL1 > Latency: ~10 ms (average) > Software (specialised algs) > Uses LVL1 Regions of Interest > All sub-dets, full granularity > Emphasis on early rejection LVL2 > Latency: few sec (average) > Offline-type algorithms > Full calibration/alignment info > Access to full event possible EF The ATLAS HLT Event Selection Software
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) • Reconstruction in Regions of Interest (RoIs) • RoI size/position derived from previous step(s) Emphasis on early event rejection Emphasis on minimising a. Processing time b. Network traffic The ATLAS HLT Event Selection Software
+ e30i e30i + e30 e30 e + e ecand ecand + + EM20i EM20i HLT Strategy – Example Signature LVL1 claims two isolated e/m clusters with pT>20GeV (possible signature: Z–>ee) Iso– lation Iso– lation STEP 4 Signature pt> 30GeV pt> 30GeV STEP 3 Strategy at HLT: > Validate step-by-step > Check intermediate signatures > Reject as early as possible Signature t i m e track finding track finding STEP 2 Signature Sequential/modular approach facilitates tuning for early rejection Cluster shape Cluster shape STEP 1 Level1 seed The ATLAS HLT Event Selection Software
Package Interface Dependency HLTSSW – Design HLT DataFlow Software Event Filter HLTSSW HLT Selection Software Processing HLT Core Software Application 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…) The ATLAS HLT Event Selection Software
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 SequenceTable • 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 The ATLAS HLT Event Selection Software
Data Access Byte Stream Converter Data source organized by ROB Data access by an HLT algo Transient EventStore Region Selector Algorithm Trans. Event Store HLT Algorithm Region Selector region list DetElem IDs list DetElem IDs list DetElem IDs ROB ID raw event data Data arranged by DetElems Data arranged by DetElems 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 The ATLAS HLT Event Selection Software
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 The ATLAS HLT Event Selection Software
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) The ATLAS HLT Event Selection Software