Serge Sushkov ATLAS Event Filter IFAE Barcelona The ATLAS High Level Trigger, designed for a broad discovery potential at LHC Serge Sushkov ATLAS Event Filter IFAE Barcelona Outline LHC physics & trigger ATLAS Trigger overview Features of High Level Trigger Additional functionality A few words on status Based on ATLAS TDAQ overview talks

LHC Challenges: Trigger View process (pp), nb / rate, Hz events/year mini bias ~ 108 ~ 1015 jets @ pT > 200 GeV ~ 100 ~ 100 M top pairs 0.85 ~ 10 M WW pairs 0.08 ~ 1 M ZZ pairs 0.011 ~ 12 k s = 14 TeV L = 1034 cm-2 s-1 Bunch spacing = 25 ns  collision rate 40 MHz Interactions / bunch crossing ~ 20 # readout channels @ ATLAS ~ 108 Event size ~ 1.5 MB Writing to mass storage ~ 300 MB/s  accept rate 200 Hz 2005-09-10 Corfu Workshop S.Sushkov, ATLAS EF, IFAE Barcelona

Triggering Physics: “Basic Objects” The foreseen computing power does not allow for a full event reconstruction of all LVL1-accepted events analyse & make decisions on part of event data layered/stepwise architecture: refine at each next layer Based on identified “physics object” (distinguished from mini-bias signals) and thresholds: type reconstruction starts from… resulting objects jets cluster of Calo cells above threshold Jets, missing ET, electrons, muons, taus, photons with parameters above thresholds, improved by calibration corrections and cross-detector matching missing ET vector sum of E in Calo cells electrons narrow “jet” w/o hadronic E, matching track in Inner Tracker muons track in Inner Tr. & Muon Ch & E in Calo taus narrow “jet” with hadronic E & track (IT) photons narrow “jet” w/o track in In. Tr. 2005-09-10 Corfu Workshop S.Sushkov, ATLAS EF, IFAE Barcelona

ATLAS Trigger/DAQ: three level architecture Level-1: Hardware coarse granularity MU & CALO simplified signature finding determines Regions Of Interest High Level Trigger: Software-implemented Level-2: full detectors granularity guided by & operates on ROI fast => simplified analysis Event Filter: full event data is available seeded by LVL2 results 1 s latency => more elaborate offline reco & analysis tools additional: calibr’n & monit’g 2005-09-10 Corfu Workshop S.Sushkov, ATLAS EF, IFAE Barcelona

Physics Channels & Trigger Elements Identified & recon’d “physics objects” with certain thresholds: Trigger Elements (TE) Label: #<obj>[thresh]<iso> Combination of TEs corresponding to physics channels: Trigger Signatures Set of signatures: Trigger Menus Requirements: be as inclusive as possible to include unknown new physics not to bias accepted data samples 2005-09-10 Corfu Workshop S.Sushkov, ATLAS EF, IFAE Barcelona

HLT Concept: Steering Mechanism HLT works using two types of algorithms: Feature Extraction: find/identify “physics objects” (Trigger Elements) using detector-specific reco algorithms Hypothesis Validation: requirements on TEs (obj type & thresholds) Steering mechanism: Repeat/refine TE reconstruction & Hypothesis Validations in iterative steps next step starts only if requirements at previous step are satisfied then next step is seeded by results of previous step and refines the event selection Steering is organized by: Trigger Element (TE): #<obj>[thresh]<iso> Trigger Signature: combination of TEs Trigger Menu: list of signatures for which an event can be accepted at a given step Sequence Table: specifies collection of algorithms to be run on a given input TE (and specifies resulting TE) 2005-09-10 Corfu Workshop S.Sushkov, ATLAS EF, IFAE Barcelona

Example of Steering Mechanism: Z  e+e- Iso lation pt> 15GeV Cluster shape track finding EM15i + e15i e15 e ecand Signature  STEP1 STEP 4 STEP 3 STEP2 t i m e Advantages of Steering: rejection of “bad” events occurs as early as possible, thus only “good physics events” reach full analysis allows to use only ROI fragments @ LVL2, thus only “good” events go through event building network and are built as full events each next step continues and refines reconstr’n using results of previous step (optimal use of time/resources) LVL1 seed  2005-09-10 Corfu Workshop S.Sushkov, ATLAS EF, IFAE Barcelona

Illustration of reco & analysis in HLT Take the LVL1 EM RoI seed. Use a LVL2 clustering algorithm for EM showers and compute shape variables: Shower containment in sampling 2 (E3x7/E7x7). Look for additional maximum in sampling 1 (E1-E2)/(E1+E2). EM and Hadronic Energy. Perform selection cuts on these variables. Reconstruct Tracks in the Inner Detector inside the RoI. Perform track/cluster matching criteria. Use the refined RoI to seed the EF (better calibration constants, complete event available, …) p0 g 2005-09-10 Corfu Workshop S.Sushkov, ATLAS EF, IFAE Barcelona

HLT Selection: based on Offline Algorithms HLTSSW Steering ROBData Collector Data Manager HLT Algorithms Processing Application EventData Model Offline EventDataModel Reconstruction StoreGate Athena/ Gaudi Event Filter Level2 HLT Core Software Offline Architecture & Core SW Offline Reconstruction HLT Algorithms HLT Selection Software HLT DataFlow Software TDAQ DataFlow Software 2005-09-10 Corfu Workshop S.Sushkov, ATLAS EF, IFAE Barcelona

Features of using Offline algorithms in HLT Advantages & design aims: base on / use the same detector-specific offline reco/analysis algorithms both in offline data analysis & in online triggering (no code duplications) selection/trigger algorithms can be developed in offline framework, without necessity to run TDAQ SW (emulating TDAQ in offline) independent development works on TDAQ/Online Infrastructure (emulating selection algorithms) HLT (EF) has access to all external tools/lib of Offline world: HLT can potentially run/use ANY Offline algorithm as additional functionality (calibration, physics & performance monitoring) Consequences for HLT & Offline: special interfaces between HLT & Offline components different implementations of data access in HLT & offline time/memory performance requirements for used Offline algorithms versions compatibility issues: HLT SW should match both Offline and TDAQ/Online SW versions 2005-09-10 Corfu Workshop S.Sushkov, ATLAS EF, IFAE Barcelona

Sets of trigger algorithms The work on trigger algorithms is argonized as: grouped into “families” according to basic types of “physics objects”: photons, electrons, muons, taus, jets, missing ET LVL2 & corresponding EF steering/trigger algorithms are combined into chains, called “vertical slices”, which are used for efficiency & performance studies within each “family/slice”, particular working groups optimise performance of selection/trigger algorithms, basing on physics analyses for typical physics processes cross-detector matching & calibration corrections are used for improving precision of reco parameters before applying thresholds results of trigger reco/selection will be available to physics analysis as stored in special L2/EF Result & L2/EF Fragment data objects, appended to event (under development now) 2005-09-10 Corfu Workshop S.Sushkov, ATLAS EF, IFAE Barcelona

Trigger  Physics Analysis Trigger efficiencies should be used in physics analysis and using common offline tools/framework is important benefit ! Physics analyses may also be useful for tuning trigger: sensitivity of physics channels to changing thresholds / lumi understanding BG & necessary statistics for given cuts (QCD) there are physics scenarios difficult for the trigger SUSY spectrum with small mass gaps (previous) … or long chains of consequent decays models with many jets but no missET (RP-V SUSY) perhaps, additional trigger may be useful & introduced ? Additional functionality of HLT / Event Filter: due to such benefits of Event Filter as access to full event data possibility to use potentially all/any tools/libs from Offline framework very good modularity & flexibility of EF Farms design it is possible to run in EF physics & detector performance monitoring algorithms based on Offline tools more complicated reconstruction to monitor simplest typical physics channels (fit masses, reconstruct decays, etc) 2005-09-10 Corfu Workshop S.Sushkov, ATLAS EF, IFAE Barcelona

Status & Summary Implementation of HLT (infrastructure) is nearly done… ATLAS Combined Test Beam 2004 - done first test of all detectors & TDAQ components - combined L2+EF trigger tested in real online readout/DataFlow Tests of TDAQ+HLT SW are carried out well periodically on dedicated test computer clusters (code development) special realistic Large Scale Tests (HLT on up to 700 hosts) TDAQ/HLT pre-commissioning in ATLAS P1 – recently started !! HLT follows & is used for commissioning of ATLAS detectors continue works on performance/stability & additional functionalities now – it’s time to activate integration of High Level Trigger with physics analyses e/gamma & muon triggers are already well implemented and used in tests tau and B-triggers are well on the way jets/Emiss trigger works started / ongoing

BACK-UP SLIDES

Event Filter: Modularity & flexibility

Main idea & motivation Event Filter has unique features: accessing full event data built by SFI ability to run Athena offline algorithms within TDAQ DataFlow framework On this basis EF can provide many additional useful functionalities: online monitoring and calibration Athena framework PTIO interf EFHLT interf EF PSC TileMon algo

RCD MobiDaq EF+Athena monitoring schema add Atlantis Event Display (LATER) RodCrateDaq MobiDaq RCD data file debug only RCD emu-EB oh_display (ONLINE !!) GNAM fileSampler OH Ev. Mon. Svc HistoSender Athena framework PTIO interf EFHLT interf EF PSC TileMon algo

Trigger rates per objects (TE) Selection 2*1033 cm-2s-1 Rates (Hz) Electron e25i, 2e15i ~40 Photon g60i, 2g20i Muon m20i, 2m10 Jets j400, 3j165, 4j110 ~25 Jet & ETmiss j70 + xE70 ~20 tau & ETmiss t35 + xE45 ~5 b-physics 2m6 with mB /mJ/y ~10 Others pre-scales, calibration, … Total ~200