CHEP 2003 @ La Jolla San Diego 24-28/3/2003

1. CHEP 2003 @ La JollaSan 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

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

3. 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 satisfiedconditions signaled by the existence of certain Trigger Elements

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

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

6. TE Data Object Trigger Elements Trigger Elements provide access to Data Objects. Steering creates and passes TEs to Algorithms. • 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 Hypothesisto the Steering “relation”

7. History Objects History Objects are the entities in charge of recording the “relation” between TEs  Objects • 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 Object (T=any Object Type)

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

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

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

11. Sequences Sequences are “instructions” to the Steering on how and when one or more algorithms should be executed • 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 TE Algorithm TE seed hypothesis

12. Signatures Signatures are a combination of active TEsthat identify the signature of a desired physics process. • 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 e50i + e50i

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

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

15. 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. • 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

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

17. Acknowledgments • HLT Steering • 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)