1. 7 October 2004Steve Armstrong ATLAS Overview Week Freiburg1 Online Physics Event Selection: The e /  Slice Steve Armstrong Brookhaven National Laboratory on behalf of the ATLAS Trigger community 6 October 2004 ATLAS Overview Week Freiburg, Germany

2. 7 October 2004Steve Armstrong ATLAS Overview Week Freiburg2 OUTLINE ¶OVERVIEW OF THE HIGH-LEVEL TRIGGER (HLT) ¶COMPONENTS OF E/GAMMA SELECTION ¶PERFORMANCE: STAND-ALONE AND ANALYSIS-LEVEL ¶DEPLOYMENT CHALLENGES ¶COMBINED TESTBEAM ACTIVITIES ¶SUMMARY

3. 7 October 2004Steve Armstrong ATLAS Overview Week Freiburg3 High-Level Trigger LEVEL-1 TRIGGER Hardware-Based (FPGAs ASICs) Coarse granularity from calorimeter & muon systems 2  s latency (2.5  s pipelines) THE ATLAS TRIGGER SYSTEM: THREE LEVELS LEVEL-2 TRIGGER Regions-of-Interest “seeds” Full granularity for all subdetector systems Fast Rejection “steering” O(10 ms) target CPU time EVENT FILTER “Seeded” by Level 2 result Full event access Offline-like Algorithms O(1 s) target CPU time FIRST PART OF ATLAS RECONSTRUCTION AND PHYSICS EVENT SELECTION 40 MHz ~75 kHz ~2 kHz 200 Hz Rates See P. Conde Muíño’s talk from Monday

4. 7 October 2004Steve Armstrong ATLAS Overview Week Freiburg4 HIGH-LEVEL TRIGGER OUTPUT RATE COMPOSITION ObjectPhysics coverage Low Luminosity 2 × 10 33 cm -2 s -1 Rates (Hz) Electrons Higgs, new gauge bosons, extra dimensions, SUSY, W, top e25i, 2e15i ~40 PhotonsHiggs, extra dimensions, SUSY  60, 2  20i ~40 Muons Higgs, new gauge bosons, extra dimensions, SUSY, W, top  20i, 2  10 ~40 Rare b-decays (e.g., B  X, B  J  (  ’)X) 2  6 +  +  - + mass cut ~25 JetsSUSY, compositeness, resonancesj400, 3j165, 4j110 ~20 Jet+missing E T SUSY, leptoquarksj70 + xE70 ~5 Tau+missing E T Extended Higgs models (e.g., MSSM), SUSY  35i + xE45 ~10 OthersPrescaled, calibration, monitoring ~20 Total HLT Output Rate~200

5. 7 October 2004Steve Armstrong ATLAS Overview Week Freiburg5 H  ZZ  2e2  TRIGGER EVENT SELECTION (e.g., ELECTRONS) LVL1 Calo RoI LVL2 Calo Algorithm LVL2 Tracking Algorithms EF Calo Algorithm EF Tracking Algorithms HLT STEERING PROVIDES FAST REJECTION Step-based execution of sequences of seeded Algorithms This flexibility has direct impact upon physics performance potential Event Accepted Reject or Accept

6. 7 October 2004Steve Armstrong ATLAS Overview Week Freiburg6 HIGH-LEVEL TRIGGER DATA ACCESS MODEL

7. 7 October 2004Steve Armstrong ATLAS Overview Week Freiburg7 OUTLINE ¶OVERVIEW OF THE HIGH-LEVEL TRIGGER (HLT) ¶COMPONENTS OF E/GAMMA SELECTION ¶PERFORMANCE: STAND-ALONE AND ANALYSIS-LEVEL ¶DEPLOYMENT CHALLENGES ¶COMBINED TESTBEAM ACTIVITIES ¶SUMMARY

8. 7 October 2004Steve Armstrong ATLAS Overview Week Freiburg8 TRACK FIT Fit Track Parameters GROUP CLEANER Groups form track candidates; remove noise SCT Pixels HIT FILTER SP groups compatible with track from z v LEVEL-2 TRACK RECONSTRUCTION ALGORITHMS (Pixel & SCT) Z VERTEX FINDING Determine interaction z v position (3   17 cm)   97%,   200  m Reconstructed Track IDSCAN algorithm processing steps SiTrack algorithm uses 3-point combinations from Pixel and SCT – tuned for b-tagging and B physics Preliminary

9. 7 October 2004Steve Armstrong ATLAS Overview Week Freiburg9 LEVEL-2 TRACK RECONSTRUCTION: EXAMPLE OF IDSCAN WITH ELECTRON RoI (  ×  = 0.2 × 0.2)    Only ~7 good hits in ~200

10. 7 October 2004Steve Armstrong ATLAS Overview Week Freiburg10 LEVEL-2 TRACKING ALGORITHMS (TRT) TRTxK TRTLUT Initial Track Finding with Look- Up Table (LUT) considering all TRT hits belonging to number of predefined tracks Local Maximum Finding with 2D histogram in  and 1/p T Track Splitting by analyzing pattern of hits for a Track Track Fit using third-order polynomial Core of algorithm is set of utilities from xKalman++ Based on Hough-transform Track candidates identified from peaks in histogram Tracks must pass quality cuts and must lie on maximal number of drift circle positions with drift information

11. 7 October 2004Steve Armstrong ATLAS Overview Week Freiburg11  00 LEVEL- 2 CALORIMETER RECONSTRUCTION ALGORITHM E 3x7 /E 7X7 in EM Sampling 2 (E1-E2)/(E1+E2) in EM Sampling 1 Total Electromagnetic Energy Hadronic (Tile & EM HEC) Energy Photon Selection Strategy Shower shape analysis to reject dominant background from jets with a leading  0 Possibility to use track veto - identify conversions first Processing steps of T2CALO at each step via HLT Steering mechanism, data request is made and accept/reject decision is possible

12. 7 October 2004Steve Armstrong ATLAS Overview Week Freiburg12 LEVEL- 1 “POSTDICTION” AT LEVEL-2 (CALORIMETER) Level-1 “postdiction” implemented inside Level-2 Calorimeter algorithm (T2CALO) Monitoring/cross-checking/comparisonMonitoring/cross-checking/comparison of Level-1 trigger decisions EM Cluster Energy EM Isolation Energy Had Core Energy Had Isolation Energy In Level-2 Software

13. 7 October 2004Steve Armstrong ATLAS Overview Week Freiburg13 OUTLINE ¶OVERVIEW OF THE HIGH-LEVEL TRIGGER (HLT) ¶COMPONENTS OF E/GAMMA SELECTION ¶PERFORMANCE: STAND-ALONE AND ANALYSIS-LEVEL Electron and photon triggers Higgs Searches Studies with Z→e + e − ¶DEPLOYMENT CHALLENGES ¶COMBINED TESTBEAM ACTIVITIES ¶SUMMARY

14. 7 October 2004Steve Armstrong ATLAS Overview Week Freiburg14 PERFORMANCE STUDIES: ELECTRON TRIGGER e25i at Low Luminosity Efficiency %Rates L1 95.5  0.2 8.6 kHz L2Calo 92.9  0.3 1.9 kHz EFCalo 90.0  0.4 1.1 kHz EFID 81.9  0.4 108 Hz EFIDCalo 76.2  0.4 46(±4) Hz HLT Steering Configurable and Flexible Selection (i.e., which algorithms to run where) allows tuning of rates within resource limits and efficiencies HLT Steering Configurable and Flexible Selection (i.e., which algorithms to run where) allows tuning of rates within resource limits and efficiencies 10 34 cm -2 s -1 2e15i at Low Luminosity Efficiency %Rates L1 94.4  0.5 3.5 kHz L2Calo 82.6  0.9 159 Hz EFCalo 81.2  1.0 110 Hz EFID 69.2  1.0 5.6 Hz EFIDCalo 57.3  1.5 1.9 (±2) Hz Preliminary

15. 7 October 2004Steve Armstrong ATLAS Overview Week Freiburg15 ELECTRON/PHOTON TRIGGER STUDIES FOR STANDARD MODEL HIGGS BOSON SEARCHES Higgs Search Channel Low Luminosity High Luminosity Kinematic Criteria H  ZZ*  4e e25i or 2e15ie30i or 2e20i2e p T >7 GeV/c & 2e p T >20 GeV/c in  < 2.5 H  ZZ*  2e2  e25i or 2e15ie30i or 2e20i2ℓ p T >7 GeV/c & 2ℓ p T >20 GeV/c in  < 2.5 H  WW*  e e (VBF) e25i or 2e15i 2e p T >15 GeV/c in  < 2.5 H    60i or 2  20i 1  p T >40 GeV/c & 1  p T > 25 GeV/c in  < 2.4 (barrel/endcap crack excluded) Trigger efficiencies are for leptons in acceptance of  < 2.5 Event sample simulation: Pythia 6.2 and with Geant3 full simulation and reconstruction including electronic noise and pile-up.

16. 7 October 2004Steve Armstrong ATLAS Overview Week Freiburg16 ELECTRON TRIGGER STUDIES FOR HIGGS BOSON SEARCHES: ANALYSIS-LEVEL RESULTS Trigger Element Luminosity H  4e (130 GeV/c 2 ) H  2e2  (130 GeV/c 2 ) H  e e (170 GeV/c 2 ) H  (120 GeV/c 2 ) e25i or 2e15iLow96.7 %76.9 %89.5 % e30i or 2e20iHigh95.5 %71 %  60i or 2  20i Low83 % First complete study of trigger and offline selection of Higgs boson search efficiencies with full detector simulation Preliminary: trigger performs adequately for low mass Higgs searches with e/  final states More studies of this type are needed across all Physics Groups (Trigger-aware analyses are essential)! Low Luminosity H  4e 100 98 96 94 92 90 0 100 200 300 400 Higgs Mass (GeV/c 2 ) Efficiency (%) H → 4e Preliminary Muon triggers (i.e.,  20i, 2  10,  10 + e15i) not yet included Low Luminosity

17. 17 TRIGGER EFFICIENCY FROM DATA with Z→e + e − Level2 offline SINGLE TAG: e25i DOUBLE TAG: 2e25i Level2 offline == =1 Efficiencies (%)This MethodMC TruthTDR Level-2 Calo & ID Track Matching 87 ± 187 ± 0.686.6 ± 0.6 Assumptions which need further study

18. 7 October 2004Steve Armstrong ATLAS Overview Week Freiburg18 OUTLINE ¶OVERVIEW OF THE HIGH-LEVEL TRIGGER (HLT) ¶COMPONENTS OF E/GAMMA SELECTION ¶PERFORMANCE: STAND-ALONE AND ANALYSIS-LEVEL ¶DEPLOYMENT CHALLENGES ¶COMBINED TESTBEAM ACTIVITIES ¶SUMMARY

19. 7 October 2004Steve Armstrong ATLAS Overview Week Freiburg19 DEPLOYMENT CHALLENGES SYSTEM PERFORMANCE OFFLINE SOFTWARE HLT INFRASTRUCTURE RAW DATA HLT is strongly coupled to Offline software – Avoids duplication of work (e.g., similar reconstruction algorithms) – Simplification of migration of selection power – Simplification of performance studies – Common database access tools – Raw Data Converters written by experts from detector groups Software development instability makes progress difficult Within limits of Level-2 and EF processing time: – Data Transfer over network – Software framework overhead – Raw data conversion – Algorithm processing time Evaluate concurrently with software development Algorithms and core software must run on HLT Infrastructure Level-2 should be multithreaded Interaction with Online DataFlow software HLT software must run for at least several hours (millions of events!) without difficulty (e.g., memory leaks, crashes) HLT (especially Level-2) is very sensitive to ROD data formats and functionality and associated decoding software Incomplete/corrupt/imperfect detector data must be anticipated (fault tolerance)

20. 7 October 2004Steve Armstrong ATLAS Overview Week Freiburg20 High-Level Trigger Software: Stability and Time required for… Highly Active Offline Software Development → Frequent Releases OFFLINE RELEASES AND HLT SOFTWARE 8.1.0 27 April 8.2.0 27 May 8.3.0 18 Jun 8.4.0 7 Jul 8.5.0 23 Jul 8.6.0 14 Aug. 8.7.0 2 Sept. 8.8.0 Early Oct. 8.0.1 16 Apr 8.0.2 8 May 8.0.3 19 May 8.0.4 30 May 8.0.5 14 Jun 8.0.6 26 Jul 8.0.7 27 Aug. 8.0.0 31 Mar. Integration: 1-2 weeks Development, Testing, Deployment: t(FTEs) > few weeks Heavy use Offline Services/Tools (e.g., ByteStream Converter for Data Preparation, some only used by LVL2) Validation (or even development) work starts when most other tools (including reconstruction) are validated Feedback loop is needed (e.g., reconstruction does not work with seeding or is too slow,…) HLT/Offline lag: HLT developers using old releases Difficult to achieve fixes in these releases (Offline already moved on, sometimes more than two cycles) Time e.g., HLT/SPMB interactions on this issue are on-going – propose adding more frequent and detailed HLT-related tests to development cycle.

21. 7 October 2004Steve Armstrong ATLAS Overview Week Freiburg21 SYSTEM PERFORMANCE OF LEVEL-2 ALGORITHMS Algorithm has smallest contribution to processing time!! Data Preparation is largest consumer of processing time, hence essential that data access granularity be as fine as possible and processing be restricted (RoI) LVL2 Calorimeter Algorithm Performance Timing is under control, especially when extrapolated to expected 2007 CPU performance, but every 1 ms of “first stage” Level-2 processing requires O(100) Processing Units!

22. 7 October 2004Steve Armstrong ATLAS Overview Week Freiburg22 LEVEL-2 SOFTWARE DEPLOYMENT STRATEGY athenaMT: Offline Level-2 Development Environment Emulates complete L2PU environment Supports multiple threads No need to setup Data Flow systems Run like normal offline application Level-2 Developers must follow a set of Coding guidelines which are more strict than Offline development guidelines Online Sequence Diagram for Level-2 Event Selection Processing

23. 7 October 2004Steve Armstrong ATLAS Overview Week Freiburg23 SOFTWARE TESTS WITHIN HLT INFRASTRUCTURE TESTBEDS ARE THE HLT EQUIVALENT OF TESTBEAM(S) Event Selection SW Confirmed and validated functionality of full HLT slice (LVL2+EF). i.e., transfer Level-2 result to EF and compare (inside EF) that it matched with what the EF reconstructed Building 32 CERN Network ROS LVL2 Event- Builder Event Filter Test made on e/  Slice using configuration above including: ROS containing calorimeter data for simulated LVL1 selected events Level-2 result successfully transmitted to EF selection Level-2 ran Calorimeter (T2Calo) algorithm, Event Filter ran CaloRec Algorithm Buildin g 513

24. 7 October 2004Steve Armstrong ATLAS Overview Week Freiburg24 Online DSP code for calculation of E, t,  2 from ADC counts Level-2 needs this functionality for Calorimeter Trigger data access and preparation (in progress for CTB) 5 ADC Samplings RAW DATA FORMAT AND DATA PREPARATION Recent Example LAr ROD FUNCTIONALITY IN CTB FAULT TOLERANCE HLT faults are likely to be in one of four categories Hardware problems in processing node Operating system problem in processing node Communication problems Problems in Event Selection Software Experience from CTB with Event Selection Software: Incomplete data received Corrupted, noisy, too large data Converter problems, crashes

25. 7 October 2004Steve Armstrong ATLAS Overview Week Freiburg25 OUTLINE ¶OVERVIEW OF THE HIGH-LEVEL TRIGGER (HLT) ¶COMPONENTS OF E/GAMMA SELECTION ¶PERFORMANCE: STAND-ALONE AND ANALYSIS-LEVEL ¶DEPLOYMENT CHALLENGES ¶COMBINED TESTBEAM ACTIVITIES ¶SUMMARY

26. 7 October 2004Steve Armstrong ATLAS Overview Week Freiburg26 LEVEL-2 EVENT RECONSTRUCTION OF CTB DATA

27. 7 October 2004Steve Armstrong ATLAS Overview Week Freiburg27 HLT ALGORITHM STUDIES WITH CTB DATA ARE IN PROGRESS: EXTREMELY PRELIMINARY IDSCAN SiTrack TRTxK “Offline” analysis of CTB data with HLT Algorithms: these recent results are extremely preliminary and are still being interpreted and understood. Very recent work with AthenaMT and ROD Data Preparation may allow Algorithms to run in “Real-Time” mode within CTB soon.

28. 7 October 2004Steve Armstrong ATLAS Overview Week Freiburg28 SUMMARY AND CONCLUSIONS Trigger has three-level architecture with software-based High-Level Trigger Events not selected by Trigger are not available for Physics Analyses Development and testing of components of e/gamma selection are on-going Eight Inner Detector Tracking and Calorimeter HLT reconstruction algorithms Stand-alone trigger studies involve unification of many components of both Core Software and Algorithms Physics Analysis-level studies have been done with encouraging preliminary results, but more are needed and essential! Several challenges exist to e/gamma (and all HLT) slice deployment Alignment with Offline Software development cycle System performance Integration within Testbeds Raw data format and preparation Progress is being made on several fronts Experience of CTB has been valuable and is on-going Infrastructure tests are being done Algorithms run in Offline mode on CTB data - preliminary results being studied – with hopes for “real-time” test of some algorithms