1 / 18

The ATLAS High Level Trigger, designed for a broad discovery potential at LHC

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

vondra
Download Presentation

The ATLAS High Level Trigger, designed for a broad discovery potential at LHC

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


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

  2. LHC Challenges: Trigger View 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 S.Sushkov, ATLAS EF, IFAE Barcelona

  3. Triggering Physics: “Basic Objects” The foreseen computing power does not allowfora full event reconstruction of all LVL1-acceptedevents • 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: S.Sushkov, ATLAS EF, IFAE Barcelona

  4. 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 S.Sushkov, ATLAS EF, IFAE Barcelona

  5. 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 S.Sushkov, ATLAS EF, IFAE Barcelona

  6. 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 stepis seeded by results of previous step andrefines 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) S.Sushkov, ATLAS EF, IFAE Barcelona

  7. e15i e15i + Signature Iso lation Iso lation STEP 4 + e15 e15 Signature pt> 15GeV pt> 15GeV STEP 3 + Signature e e t i m e track finding track finding STEP2 Signature ecand ecand + Cluster shape Cluster shape STEP1 + EM15i EM15i Example of Steering Mechanism: Z  e+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 S.Sushkov, ATLAS EF, IFAE Barcelona

  8. 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 S.Sushkov, ATLAS EF, IFAE Barcelona

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

  10. Features of using Offline algorithms in HLT • Advantages & design aims: • base on / use the same detector-specificofflinereco/analysis algorithmsboth in offline data analysis & in online triggering (no code duplications) • selection/trigger algorithmscan 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 S.Sushkov, ATLAS EF, IFAE Barcelona

  11. 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 algorithmsare 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) S.Sushkov, ATLAS EF, IFAE Barcelona

  12. 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) S.Sushkov, ATLAS EF, IFAE Barcelona

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

  14. BACK-UP SLIDES

  15. Event Filter: Modularity & flexibility

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

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

  18. Trigger rates per objects (TE)

More Related