CHEP 2003 @ La Jolla San Diego 24-28/3/2003 The Algorithm Steering and Trigger Decision mechanism of the ATLAS High Level Trigger  Gianluca Comune (Bern University) On behalf of ATLAS Trigger/DAQ High Level Trigger Group

Introduction I will describe an online Event Selection Software (Steering) for the ATLAS High Level Trigger (HLT). The Implementation draws on the current ATLAS offline Software. The Steering is responsible for efficiently accepting or rejecting Physics Events. The two key selection strategy choices taken are Seeded Reconstruction approach. Reconstruction in incremental Steps allowing early event rejection These last two ingredients dramatically reduce the amount of CPU and bandwidth resources needed.

Overview Seeded reconstruction and Stepwise processing means fast Event rejection Seeded reconstruction: Objects and Knowledge (Seeds) built by one algorithm can be used by another algorithm without the two being actually aware of each other and how the seeds were produced. This is achieved by use of Sequences and a data Navigation scheme Processing by Steps: The decision whether or not to reject an Event occurs in Steps. This decision is taken based on Signatures and on existing satisfied conditions signaled by the existence of certain Trigger Elements

The Steering Event Accepted Signature + STEP #2 + Algorithm Sequence e50i+e50i ? e50i e50i + isolation isolation STEP #2 Decision e50 e50 + Algorithm Sequence elecId elecId STEP #1 EM50 EM50 + time Trigger Element Initial Seeds

The key Steering Components Trigger Elements History Objects Algorithms Data Navigation Sequences Signatures Seeding and RoI STEERING

Trigger Elements Trigger Elements provide access to Data Objects. Steering creates and passes TEs to Algorithms. “relation” TE Data Object Trigger Elements are linked to objects with a “relation”. Objects are external to the Trigger Element itself The “relation” is encoded in objects called History Objects Trigger Elements are used by algorithms to signal a satisfied Hypothesis to the Steering

History Objects History Objects are the entities in charge of recording the “relation” between TEs  Objects History Object key1 pointer<T1> key2 pointer<T2> ….. …. keyN pointer<TN> (T=any Object Type) In our implementation History Objects are STL multimaps that record pairs keypointer<T> The “key” can be any value. Its explicit meaning is not constrained by the History Class definition

History Objects: how they work “seeded by” 0xBBBBBB TE TE “uses” “excludes” 0xCCCCCC TE TE Type A 0xDDDDDD Type B History Object “seeded by” 0xBBBBBB “uses” 0xCCCCCC “excludes” 0xDDDDDD

Algorithms Algorithms are responsible for the Reconstruction. The Steering calls them on a conditional basis The set of algorithms that can potentially be executed in a run is configured based on XML files (see M. Elsing’s talk) Dynamical information in terms of existing Trigger Elements determine if and how many times a particular algorithm has to be executed Algorithms signal success condition to the Steering by activating the input Trigger Element

Algorithms and Navigation Receive Input TE Navigate to Seed Create New Object Link Object to Input TE Signal Success ALGORITHM time Navigate “seeded by” TE TE Input TE “uses” Link “uses” Object A Object B Seed New Object

Sequences TE Algorithm TE Sequences are “instructions” to the Steering on how and when one or more algorithms should be executed TE Algorithm TE seed hypothesis Sequences are used by the Steering Sequencer to decide whether to execute an algorithm or not. If the seed TE is active then the algorithm is executed with the hypothesis TE in input Only Algorithms which are relevant for the Physics Signatures that we are looking for are executed

Signatures Signatures are a combination of active TEs that identify the signature of a desired physics process. e50i + e50i Signatures are used by the Steering Decision at every Trigger step to select wanted and promptly reject unwanted events They are checked against the number of existing active TEs to determine if they are Satisfied. The ones that are fulfilled are recorded to be used later by the Steering Result The Signature Table in a run is defined in configuration files and identify the Physics signals that will be searched

Seeding and RoI The Steering Seeding mechanism is a natural implementation of the concept of Region of Interest (RoI) (see V. Boisvert talk). The RoI is the perfect candidate as initial seed for the reconstruction chain. An algorithm will be able to limit its processing only to this geometrical Region. Likewise the downstream algorithms can refer to the same Region through the Data Navigation With the RoI mechanism, Algorithms request and process only a small fraction of the full Event

Active TEs & Signatures Putting all together Previous Trigger Level Steering Initial Seed Satisf. Sigs Signatures Sequences Result Decision Sequencer Yes/No Exec (TE) Config Sequences and Signatures Create Event Result Retrieves Satisfied Signatures Active TEs & Signatures Set up “seeded by” Create input TE Algs Reco Active Config Result TE History A “uses” “seeded by” TE Reco TE

Current prototype The critical requirement is that the overhead introduced by the Steering framework should account only to few % of the 10ms reconstruction time available at Trigger Level 2. Event ~1200μs (5 signatures) 3 seeds Write History entry ~16μs O(10)/Evt Read History entry ~38μs Using RH7.3, optimized gcc-2.95 build, 1GHz/512MB machine. Times taken with NetLogger timing libraries This is a first iteration and it looks like we are on the right track

Conclusion We have a working Steering prototype based on the ATLAS offline Software Framework We are in the process of integrating the Steering with algorithms and Data Access to exercise a full event selection chain for electron and photons We expect the design/implementation choices to be reviewed mostly regarding the very tight timing constraints

Acknowledgments HLT Steering HLT Configuration Navigation A. Radu (Bern Uni.), G. Comune (Bern Uni.) HLT Configuration T. Schörner-Sadenius (CERN), M. Elsing (CERN) Navigation S. George (RHUL), A. Lowe (RHUL), M. Grothe (CERN)