Architecture of the ATLAS High Level Triggers Event

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 LVL2 > Latency: 2.5s (max) > Hardware based (FPGA, ASIC) > Calo/Muon (coarse granularity) > Latency: ~10 ms (average) > Software (specialised algs) > Uses LVL1 Regions of Interest > All sub-dets, full granularity > Emphasis on early rejection EF LVL1 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 VL1 claims two isolated /m clusters with pT>20GeV possible signature: Z>ee) STEP 4 Signature e30i Iso lation

e30 pt> STEP 30GeV 3 Signature e trategy at HLT: Validate step-by-step Check intermediate signatures Reject as early as possible Sequential/modular approach facilitates tuning for early rejection STEP 2 track finding Signature ecand STEP 1 Cluster shape Level1 seed EM20i

Nikos Konstantinidis The ATLAS HLT Event Selection Software + e30i Iso lation + e30 pt> 30GeV + 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 Region Selector Transient EventStore 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