Trigger input to FFReq 1

Specific Issues for Trigger The HLT trigger reconstruction is a bit different from the offline reconstruction: – The trigger uses predominantly partial event reconstruction – For most of events we do as little reco. as possible to reject the event – To save bandwidth and CPU, reconstruction is with RoI – this can be naturally turned into parallel processing of RoIs within an event – Latency is important as well as through-put – The HLT performs several hundred small reconstructions per event – for every step of every trigger chain In consequence it may be suitable for HLT to process events using parallel code  at least we should try it 2

Framework Requirements - 1 Framework must create & configure algorithms, tools and services based on configuration information Mapping of existing online offline FSM Configure( TDAQ Config Object) – Create AppMgr – AppMgr->configure() – AppMgr->initialize() – Assign EventLoopMgr(s) to threads Unconfigure() – AppMgr->finalize() – AppMgr->terminate() prepareForRun( int runNumber ) : – Fire “begin run incident” for every EventLoopMgr – Load run dependent (calibration/conditions) data Process(RobFragment* lvl1Result, RobFragment*& lvl2Result, bool& eventDecision) – EventLoopMgr->executeEvent((void*)Lvl1Result) – EventLoopMgr->Lvl2Result(vector & l2resultData, vector & status) Trigger: Menu defines chains of algorithms, their parameters and their input & output Online: config. from DB; Offline: DB, XML or python Offline: jobOptions define algorithms & their parameters Framework must implement a Finite State Model i.e. creation, configuration, initialisation, execution, finalization, termination This state model must map onto online DAQ states (configure, unconfigure, prepareForRun, Process) 3

Differences between Trigger and Offline Processing 4 I/P: 100 kHz Event Rate O/P: 1 kHz Event Rate Trigger provides rejection => Full trigger processing for only 1 in 100 events  Different steps take very different amounts of time ~10ms->~few sec  Different events take very different amounts of time ~10ms->~few sec Event … Step Trigger Offline Framework(steering) must support early termination of event processing after a processing step

Framework Requirements - 2 Framework must provide configuration information at the start of a job and provide for updates at the start of a new run and during the run. The framework must support parallel processing of different events requiring different conditions info. 5 Online: Whole conditions info loaded at start of run Updates during run at lumi-block boundary (subset of folders=>small size) Offline: Updates at any time

Trigger Configuration 6 Trigger configuration defines: – chains of algorithms – Properties of the algorithms – The input and output from each algorithm

Framework and HLT Steering Current HLT Steering: Seen from athena: the HLT Steering is an algorithm Seen from the perspective of the trigger the HLT Steering has many of the properties of a framework Questions: What commonality between HLT steering and New Framework Scheduler? What additional requirements for framework/scheduler to provide HLT Steering functionality? What additional trigger-specific functionality that must be provided on top of Framework 7 HLT Steering: Creates & configures chains of algorithms Executes algorithm chains in a data-driven Chains process Regions of Interest Decides whether chain execution should terminate (reject event) or continue until event accepted HLT Navigation: Input & reconstructed objects attached to Trigger Element Collects reco. objects associated to RoI

Requirements for Trigger Framework Supports reconstruction in RoI Supports parallel processing of RoI Provides algorithms with sub-set of reconstructed objects for RoI Supports early termination of processing (event rejection) 8

Reconstruction Currently Future? 9 Trigger Partial Event Reconstruction Independent reconstruction in RoI Offline: Full reconstruction Full event Trigger & Offline Regions of Reconstruction? Define “windows” in event around interesting features (e.g. eta-phi region or road).

Reference Material 10

Requirements & design of Current (Run-1) HLT Steering ATL-COM-DAQ (ATL-DH-EN-0010) 11

F S S S F? S F,S S Requirement Applicability to new framework

F F,S S 13

14 F F,S F F F S S obsolete F F F

15 F F F F F S F S

FFReq Mandate 1. Summarise the requirements from both HLT and reconstruction for configuring, scheduling and monitoring algorithms, and other related functionality that is felt to be relevant. These may be documented in old documents that need checking for current relevance and completeness, or they may need to be reverse engineered using the skill and experience of the group. 2. Consider how these might be accommodated in a *common* framework that supports concurrency and helps to achieve high throughput on many-core computers, such as the GaudiHive prototype. 3. In particular, consider how to minimise the need for extensions or layers to the framework specific to one or other use case, with the aim of making it straightforward to write algorithms to work well in both use cases. 4. Converge on the union of the HLT and reconstruction requirements for a future framework, and an analysis of the technical feasibility of satisfying them with a single common framework. 5. The study group is encouraged to think beyond current implementations, recognising that some decisions made a long time ago and in the context of the Gaudi framework may not be applicable in the future. 16