1 / 12

Muon EF and Common Muon reconstruction tool Interfaces

Muon EF and Common Muon reconstruction tool Interfaces. Stefania Spagnolo Dip. di Fisica, Univ. del Salento and INFN Lecce for the Muon HLT working group. Outline. The proposal for common Muon Reconstruction Tool interfaces details in http://indico.cern.ch/conferenceDisplay.py?confId=27404

fred
Télécharger la présentation

Muon EF and Common Muon reconstruction tool Interfaces

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. Muon EFand Common Muon reconstruction tool Interfaces Stefania Spagnolo Dip. di Fisica, Univ. del Salento and INFN Lecce for the Muon HLT working group

  2. Outline • The proposal for common Muon Reconstruction Tool interfaces • details in http://indico.cern.ch/conferenceDisplay.py?confId=27404 • Re-organization of the muon EF (TrigMoore) for release 14.x.x • Other sw upgrades required in rel 14.x.x by the muon EF Trigger Open Meeting (core sw and slices)

  3. Proposal for Common Muon Reco Tool interfaces • A proposal from C. Schiavi, mainly, discussed in a muon combined reconstruction meeting • agenda at http://indico.cern.ch/conferenceDisplay.py?confId=27404 • Aim • benefit from generality • exchange standard objects; re-use code for reading/writing standard objects • once algorithmic code is isolated in tools with common interfaces, it’s easy to play different reconstruction job configurations • an EF algorithms might easily be built out of generic pattern recognition / track fitting / track combination tools Trigger Open Meeting (core sw and slices)

  4. Proposal for Common Muon Reco Tool interfaces • The main points: • Algorithms that cannot be re-run on AOD (without using link to ESD) should not use AOD level objects as input/exchange data • TrackParticle currently widely used (MuTag, MuGirl, not in TrigMoore/Muid Algorithms) • Algorithms should produce the output (as collections of std EDM objects, Rec::TrackParticle, Analysis::Muon, etc.) with common tools • Use common tools for combining MS and ID information • track matching and track combination • muon tagging • track collections from Id Tracks + MS segments • track collections from Id Tracks + MS PrepRawData collections Trigger Open Meeting (core sw and slices)

  5. Proposal for Common Muon Reco Tool interfaces some examples of explicit proposal for common tool interfaces under negotiation most likely, final interfaces will be different (once/if agreed upon) C. Schiavi Trigger Open Meeting (core sw and slices)

  6. Proposal for Common Muon Reco Tool interfaces • The proposal is under evaluation in the muon offline community • The interest/use case from the EF side is clear • From first reactions, in the meeting(to my understanding) • the impact in the Moore/Muid packages would not been too large (already undergoing re-structuring for release 14.0.0 in the direction of separating algorithmic code into tools) • the MuGirl community has already put some effort in optimizing the code for online applications; need to understand how much the proposal would interfere with undertaken developments • last step of MuGirl logic (match of ID-track with MS segments/data) relatively easy to isolate • from the MuTag/ Staco side some objections to have separate steps for track matching and track combination have been raised; widely using TrackParticle at the moment • clear interest to provide track based interfaces for use in EF • for all: an agreement on the actual interfaces has to be achieved • http://indico.cern.ch/conferenceDisplay.py?confId=27886for updates on muon reco plans Trigger Open Meeting (core sw and slices)

  7. Re-organization of TrigMoore for release 14.x.x • A requirement for the offline community since a long time was the isolation of algorithm code into tools • EF would then deploy specific HLT algorithms performing data access on a regional base and use offline reconstruction tools • now: MooHLTAlgo execute offline algorithms as sub-algorithms and have a special copy of some of them where the RoI mechanism is used for limiting data access • benefit: trivial synchronization with latest algorithmic improvements • not anymore objects passed via StoreGate between sub-algorithms executed in sequence from the same FEX Trigger Open Meeting (core sw and slices)

  8. Re-organization of TrigMoore for release 14.x.x Moore plans for 14.0.0 by N. van Eldik Offline Algorithms purely read and write data Introduce three reconstruction ‘phases’ Segment finding, track finding, combined reconstruction Trigger Open Meeting (core sw and slices)

  9. Re-organization of TrigMoore for release 14.x.x Moore plans for 14.0.0 by N. van Eldik Current Moore Data Flow needs assembly of algorithms into three blocks (super-tools) • segment finding • track finding • combined reconstruction Internally super-tools will exchange intermediate objects via interfaces Prototypes for Segment and Track finding available for EF development: in MIG4 nightly builds (first build by tomorrow) until they become stable for use in offline Tools for MuidSA/MuidCB almost ready/coming in 14.x.x Trigger Open Meeting (core sw and slices)

  10. Re-organization of TrigMoore for release 14.x.x N. van Eldik • This change comes in addition to other underlying evolutions of the algorithm • Careful validation/perf. study of EF in rel. 14.x.x will be needed TrigMoore-00-00-88 very well known performances Muon Trigger CSC note TrigMoore-00-01-37 no detailed performances studies, but muon trigger rates match estimates in 12.0.6 Trigger Open Meeting (core sw and slices)

  11. Re-organization of TrigMoore for release 14.x.x • How to follow up in the EF • Restart from scratch, without interfering with the existing package • Currently TrigMoore contains a single HLTAlgo: • 3 instances created in a standard sequence MS(Moore), SA(MuidSA, i.e. track extrapolation to the IP), CB(MuidCB, i.e. track combination) • behaviour of each instance controlled by configuration flags (job-options) • Resume the long standing plan to separate the three instances into three HLTAlgorithms • three new packages • TrigMuonEFBuilder containing 2 algos or 1 algo using 2 tools (under study) • TrigMooSegmentFinder • TrigMooTrackFinder • TrigMuonEFExtrapolator • TrigMuonEFCombination • aim at providing the functionality for some release of the 14.x.x cloud while keeping current working implementation in 13.2.0 starting soon Trigger Open Meeting (core sw and slices)

  12. Other sw upgrades required in rel 14.x.x by the muon EF • items related to data preparation and geometry optimization • conversion from bytestream to preprawdata • define and implement a schema, common to all technologies, for a RoI driven data conversion (decoding) and preparation (ambiguities and redundancies resolution) pattern • time scale B (cosmics and first collision data) • control caching mechanism: enable/disable, fill init time, clear on demand • done – needs more testing • minimize memory usage • time scale A (FDR)/B • hypothesis algorithm for p/KX rejection at the EF • follows from CSC studies - time scale A (FDR, phase 2) • Tools for Validation / Robustness tests Trigger Open Meeting (core sw and slices)

More Related