1 / 12

Architecture of the ATLAS High Level Triggers Event Selection Software

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

quito
Télécharger la présentation

Architecture of the ATLAS High Level Triggers Event Selection Software

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 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

  2. 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

  3. Trigger/DAQ at the LHC • High rate (40 MHz) • High granularity  large event size (1-2 MBytes) The ATLAS HLT Event Selection Software

  4. ATLAS Trigger Strategy HLT The ATLAS HLT Event Selection Software

  5. 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

  6. 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

  7. + 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

  8. 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

  9. 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

  10. 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

  11. 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

  12. 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

More Related