Muon Event Filter Status Report Sergio Grancagnolo for the muon EF working group INFN Lecce & Salento University

Outline Performance in releases 12, 13, 14 Robustness to misalignments Muon EF wrappers for offline supertools Converters Menus Muon trigger CSC note status

Muon Slice performance From CSC Note – Muon Rates - Convolution method trigger sw LVL1 emulation muFast+hypo muComb+hypo TrigMooreMS TrigMooreSA TrigMooreCB+hypo Pythia 6.4 for b,c  DPMJET for  /K  (conservative choice) large theoretical uncertainties at p T below 6 GeV must focus on  /K  rejection at low p T mu6 needs prescaling mu20/40 need isolation or prescaling at 10 34

Efficiencies a drop of the CB trigger eff. at low p T has been observed in – recovered in 14.x.0 nightlies – appears related to EFID rather than Muon Algos Stable eff. at high p T TrigMooreCB w.r.t. muComb single muons nightly nightly EFId w.r.t. muComb single muons Z  Single muons mc12.*.RDO.* ATLAS-CSC ATLAS-CSC – – –14.X.0 devval, rel_3 (12 Mar 2008)

Resolution 1/p T X.0 MuIdSA MuIdCB MuIdSA performance is more or less constant for all releases MuIdCB shows slight deterioration in 14.X.0 wrt previously

Resolution  and  X.0 MuIdCBMuIdSA  and  resolution stable with releases   MuIdSA MuIdCB  

 /K rejection single  single  min.bias  K  min.bias  K  From the CSC note with current set of cuts (not extensively optimized) –75% 4GeV for (1-eff BG )=35% –90% 20GeV for (1-eff BG )=25% Inner Detector d0 ≤ 0.15 ID n. of pixel hits ≥ 3 ID n. of B layer hits ≥ 1 ID n. of SCT hits ≥ 6 pT (ID) / pT (SA) ≤ 1.25 Combined match  2 ≤ 26 present cuts to be implemented in a new hypo algorithm for 14.x.x

Robustness against misalignments RDO reconstruction and AANT/AOD production performed with Athena Four reconstruction scenarios considered with different knowledge of ID and/or MS alignment: –Aligned ID and aligned MS –Aligned ID and aligned MS (perfect correction of misalignments) –Aligned ID and misaligned MS –Aligned ID and misaligned MS (crude MS misalignments ~1mm) –Misaligned ID and misaligned MS –Misaligned ID and misaligned MS (ID as in FDR1 + MS as above) –Misaligned ID and aligned MS –Misaligned ID and aligned MS (ID as in FDR1 + perfectly known MS) EF_InDet wrt LVL2 EF_MuidCB wrt LVL2 Dramatic loss of EF algos’ efficiency with misal ID. Misal MS even worse at high p T Event-based efficiencies applying lowest muon threshold Efficiencies

Resolution 1/p T Standard deviation of p T (Reco) / p T (Gen) EF InDet EF MuidSA EF MuidCB 3% 5% 3% 5% 3% 2% EF InDet p T reso 2-3 times larger with misal ID ID al -MS al ID al -MS misal ID misal -MS al ID misal -MS misal MuidCB p T reso below 10% with misal ID, out of control at >100 GeV with Misal MS

Resolution  Standard deviation of  (Reco) –  (Gen) EF InDet EF MuidSA EF MuidCB 3x x % 3% 5% 5x x x x x x10 -4 MuidCB  resolution 2-3 times larger with misal ID/MS MuidSA  performance unchanged EF_ID  resolution constant with misal ID ID al -MS al ID al -MS misal ID misal -MS al ID misal -MS misal

Resolution:  Standard deviation of  (Reco) –  (Gen) EF InDet EF MuidSA EF MuidCB 2% 3% 5x x x x x x x x x10 -4 MuidSA  performance unchanged EF_ID  resolution constant with misal ID MuidCB  worse at high p T with misal MS, resolution ~ mrad with misal ID ID al -MS al ID al -MS misal ID misal -MS al ID misal -MS misal

Robustness considerations  Tests on muon trigger robustness performed on (mis)aligned data, running the full Muon Slice shows that  With crude non-realistic (~mm) MS misalignments + realistic ID misalignments (FDR1):  EF efficiencies deteriorate significantly  EF spatial resolution under control, but p T gets worse above GeV (below 10% with ID misal. only)

Converters – state as today MuonCnv/MuonByteStream –bytestream Converter to RDO for Mdt, Rpc, Tgc, Csc –bytestream Converter to Mdt PrepData –bytestream Converter to Rpc PrepData but no ambiguity/redundancies solving For trigger technologies online data format very different wrt offline –no bytestream to PrepData Converter for Tgc, Csc today MuonCnv/MuonRdoToPrepData –Conversion Algorithms from RDO to PrepData for all technologies uniform in general structure among technologies implemented for the MC: input is the RDO ! can be run on bytestream: when the algorithm retrieve the RDO, the bytestream to RDO Converters are activated and the RDO become available in memory for further conversion (as in M5) converting full event even when working in a region of interest !! for RPC the reason is having clean RIO collections – no redundancies/ambiguities NEED to preserve the RoI driven data access

New data access schema for RPC the EF, the algorithm (FeX) requests RPC PRD in a  x  region (RoI) –get from the region selector a list of data collection hash id (offline) in the RoI –get from cabling service the corresponding list of pad identifiers –Retrieve from StoreGate the pad container and find (i.e. decode into RDO) each pad in the selected list  output is the RDO for the RoI i.e. just use the byte-stream to RDO converter –convert the RDO into PRD by applying the redundancy and ambiguity removal currently implemented in the offline algorithm for RDO  PRD First implementation of the schema proposed for RPC offline / Event Filter is ready / under test in the offline (re-use not duplicate code) MC and DATA –RDO to PRD delegate all the work to the new AlgTool used over the whole event  allow to use the StatusCode + an attached string describing the kind and severity of the problem in data preparation  robustness The schema can be adopted for all muon technologiesThe schema can be adopted for all muon technologies –uniform way of accessing the data embed all that into an AlgTool

TrigMoore implementation LVL2 (muFast) Moore Algs LVL1 MuIdStandAloneAlgs TrigMoore Seeding Algs MuIdCombinedAlgs Hypo Alg LVL2 (muComb) Inner Detector Algs Seeding Algorithms assume the seed from LVL1 or LVL2, barrel or endcap –Reconstruction only in the geometrical regions provided by the RoIs of previous levels 3 instances of TrigMoore are called by the steering for: –Reconstruction in MS –Extrapolation to the IP –Combination with ID tracks Each TrigMooreFeature is accessed by TrigMooreHypo to test hypotheses

Follow up with the new Moore style for A new package: Trigger/TrigAlgorithms/TrigMuonEF hosts 4 HLTalgorithms: –TrigMuonEFSegmentFinder wrapper for MooSegmentCombinationFinder (offline tool invoqued with vector of pointers to prd collections) DONE –TrigMuonEFTrackBuilder wrapper for the offline tool MuonCombiTrackMaker (invoqued with vector of pointers to segment combination) DONE –TrigMuonEFExtrapolator wrapper for MuidBackTracker DONE –TrigMuonEFCombiner wrapper TO BE DONE for the main tool of MuidCB (COMING SOON ?) Running with release producing standalone EF muons propagated to the interaction point Most work is just in configuration –requires dedicated configuration of the tools for running in trigger The new chain (up to the available implementation) will be in –defined temporary extra muon trigger sequences to be run concurrently with the standard EF (TrigMoore) –needs to revise the trigger AOD for the EF

New EF wrappers LVL2 (muFast) TrigMuonEFTrackBuilder LVL1 TrigMuonEFExtrapolator TrigMuonEF TrigMuonEFSegmentFinder TrigMuonEFCombiner Hypo Alg LVL2 (muComb) Inner Detector Algs MooSegmentCombinationFinder MuonCombiTrackMaker New implementation schema of muon EF code (to be implemented for ) With wrappers for offline tools MuidBackTracker Hypo Alg Combination tool In red: to be implemented The slow particle trigger TrigMuGirl will be also included in or

Revision of muon EF trigger AOD The separate step of segment finding allow for another early hypothesis algo –As an example if the number of segments in inner/middle/outer MS layers is stored –Fit  2 could be saved at different track building steps To implement hypo algos for  /K rejection –At least combined match  2 fit must be stored Link to the ID track used in combination –Use of ElementLink if ID info is already stored in AOD –Store ID info if missing (21 bytes) Proposal last Muon Slice Trigger Software (3 Apr) for a new schema –Possibility under study

Muon Trigger Menus A lot of effort has been put in cross checking the trigger rate estimated with the convolution method and with the counting method (on min. bias Pythia 6.4 samples) –a basic agreement is observed taking into account the different theory input for  /K rates –full details can be found in reports at Nov. Trigger and Physics week and at Dec.2007 TDAQ week Based on estimated trigger rates the muon trigger menus have been defined for and assuming standard muon slice algorithms (no isolation yet, no  /K rejection strategies) first though for based on extrapolation of –Need to account for minimum bias pile-up –Reliable samples needed –implications of luminosity at 75 ns bunch crossing spacing

PHYSICS MENU (TriggerMenuPython ) + rates SIGNATURESE32 LVL1LVL2EF RATES (Hz) PSPTPSPT PS rates PT rates Total rates mu415*10400* mu611*10200* mu *101* mu151120*101* mu mu40111* mu20_passHLT * ~ mu411*105* mu6111* mu4_mu6111* mu mu mu Menus ( ) & Rates for of (13 th February)

PHYSICS MENU rates SIGNATURESE32 LVL1LVL2EF RATES (Hz) PSPTPSPT PS rates PT rates Total rates mu415*10400* mu611*10200* mu *101*1001.8<1<2.8 mu151120*101* mu mu mu20_passHLT * ~ mu411*105* mu mu4_mu <1.5<2.9 2mu mu mu mu20i new PROPOSAL FOR OPTIMIZATION OF Very fast estimate of the cumulative rate gives : ~50 Hz (against 112 as before)

FDR-2 Release ( tag ) SIGNATURESLVL1E32E33 E32E33LVL2EFLVL2EF PSPTPSPTPSPTPSPT mu * mu20i/ mu20i_tight ( for10 33 ) mu40 / mu40_tight (for ) mu4 (E32)10No1010 2mu611 * mu10 (E32)1No1010 2mu15 (E33)No Not yet inside the menu definition

Status of Muon Trigger CSC Note Comments received from referees before Easter –Almost all comments have been implemented and the remaining ones are going to be finalized Mainly editorial work –Figures to be uniformed in style New draft sent to referees for further comments

Conclusions Muon EF performs satisfactory in releases 13 and 14 Several studies of robustness against misalignment –Need to better understand how much realistic are the considered scenarios –effort on-going for having realistic (day 0) MS misalignments for FDR2 (~100 microns) Muon EF wrappers for offline supertools planned to enter in release –Muon EF AOD under study Reenginering of Converters: common effort for different technologies Muon trigger under optimization –first thoughs for Muon trigger CSC note in final shape

Backup

p T (Reco) / p T (Gen) distributions 6 GeV Single Muons Resolution : p T MuIdCB X.0

p T (Reco) / p T (Gen) distributions 19 GeV Single Muons Resolution : p T MuIdCB X.0 Systematic underestimate for release This problem seems overcome in the subsequent releases

p T (Reco) / p T (Gen) distributions 100 GeV Single Muons Resolution : p T MuIdCB X.0 p T resolution looks stable wrt releases at high transverse momentum

Mean of p T (Reco) / p T (Gen) gaussian fit Mean 1/p T : EF MuidSA & MuidCB X.0 MuIdSA MuIdCB No offset appear in reconstructed EF p T

Beam halo Samples by A. Stradling: –/castor/cern.ch/user/s/stradlin/PileupNM/misal1_mc singlepart_empty/halo  The Muon Trigger seems unaffected by muons in beam halo (statistical significance to be evaluated according to the luminosity of the simulated sample) generated events 0 at LVL1 & HLT  gen p T gen (MeV)  gen (rad)

RPC Raw Data and Prep Raw Data On-line: RDO Offline: PrepRawData  on-line hits different from off-line hits  h.w. duplicated hits due to cabling overlap  s.w duplicated hits due to wired-or and logical-or  3 types of trigger hits in the readout We have to deal with a very different structure of the online and offline data model

Current path to RPC EF RPC bytestream  RDO  prep data i.e. running the offline algorithm for RDO  PRD conversion which, as first step, activates the converter bytestream  RDO –run before the steering (not trigger driven!!!) –converting full event even when working in a region of interest inefficient –the reason is having clean PRD collections no redundancies /ambiguities –current byte-stream to PRD converter does not solve overlaps/ambiguities because it scans sequentially the byte-stream and output a PRD for each relevant CM hit –data clean-up requires to apply some logic on top of raw hits (which must necessarily be organized and stored in some format) –the most natural and well tested format for that is the RDO