Muon ef and common muon reconstruction tool interfaces
This presentation is the property of its rightful owner.
Sponsored Links
1 / 12

Muon EF and Common Muon reconstruction tool Interfaces PowerPoint PPT Presentation


  • 94 Views
  • Uploaded on
  • Presentation posted in: General

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

Download Presentation

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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Muon ef and common muon reconstruction tool interfaces

Muon EFand Common Muon reconstruction tool Interfaces

Stefania Spagnolo

Dip. di Fisica, Univ. del Salento and INFN Lecce

for the Muon HLT working group


Outline

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)


Proposal for common muon reco tool interfaces

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)


Proposal for common muon reco tool interfaces1

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)


Proposal for common muon reco tool interfaces2

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)


Proposal for common muon reco tool interfaces3

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)


Re organization of trigmoore for release 14 x x

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)


Re organization of trigmoore for release 14 x x1

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)


Re organization of trigmoore for release 14 x x2

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)


Re organization of trigmoore for release 14 x x3

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)


Re organization of trigmoore for release 14 x x4

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)


Other sw upgrades required in rel 14 x x by the muon ef

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)


  • Login