New muon EF trigger with offline supertools Sergio Grancagnolo INFN Lecce & Salento University

Summary Current status of the muon trigger EF Current ESD/AOD content Proposal for ESD/AOD content

Event Filter: follow up with the new Moore style for A new package: Trigger/TrigAlgorithms/TrigMuonEF hosts 4 HLTalgorithms: –TrigMuonEFSegmentFinder wrapper for MooSegmentCombinationFinder (offline tool invoked 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 – from a very first look at the performance in comparison with old TrigMoore and offline Moore some mis-configuration of the tools has been identified 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

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 At least combined match  2 fit must be stored –Fit  2 could be saved at different track building steps 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) More space needed?

Muon EF info in AOD: now One independent object for each istance of MooHLTAlgo muon code used to distinguish between them Size: 44 bytes + size of the string / EF muon Total for all 3 instances, w/ and w/o improvements: 117 bytes and 132+3*string size bytes intdoublestring codecharge 1/pT cot(  )  mass RoI Possible improvements: charge: double  bool RoI : string  unsigned short int Required 3 bytes for both Improved size: 39 bytes Store charge with 1/pT sign? Saves 1 more byte/istance but no abs(Pt) allowed See Attila’s talk - 13 Dec Trigger AOD Discussion

Muon EF in AOD: proposal (1/3) Only one object keeping information for all muon EF steps Avoid duplicate information Avoid muon code Reuse space saved to store other useful info Note: I verified that it is possible to attach a feature to a TE in a trigger algorithm and update the same feature in another trigger algorithm  the same object can be updated many times, with all the muon trigger information, before to be stored in AOD

Muon EF in AOD: proposal (2/3) Minimal implementation: –One istance of TrigMuonEFInfo –One component of the vector of TrigMuonEFTrack for each step of the trigger TrigMuonEFTrackBuilder TrigMuonEFExtrapolator TrigMuonEFCombiner Total space: 101 bytes –With same information amount as current version P4IPtCotThPhiM double IPt double CotTh double Phi double Mass TrigMuonEFTrack:: P4IPtCotThPhiM bool m_charge TrigMuonEFInfo unsigned short int m_RoI std::vector

Muon EF in AOD: proposal (3/3) Additional information: –N segment/layer (6 bytes) –Fit  2 for each step (24) –Match  2 for CB step (8) –ID info for CB track (21 bytes) double d0, pT unsigned short int SCT hits, pixel hits bool B layer Total space: 160 bytes –information needed for  /K rejection do not require segments or fit  2 –Strictly needed for  /K are 130 bytes  less than now TrigMuonEFCbTrack:: TrigMuonEFTrack double chi2match ID Info TrigMuonEFInfo unsigned short int m_RoI unsigned short int nSegments[3] std::vector TrigMuonEFTrack:: P4IPtCotThPhiM double chi2fit

Conclusions New muon EF trigger working in –Firsts checks on performances up to extrapolation already possible Possibility to optimize muon EF current information in AOD –Reduce space for current information –Add more information required for  /K rejection I am not a real expert on AOD: input, support and suggestions are more than welcome! Going to 14.X.0 nigthlies as soon as temporary extra muon trigger sequences are defined in TriggerCommon (help from Takanori) –Template defined already in place and tested