Child pages
  • Iterative L3 Trigger Reconstruction

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Table of Contents

Objectives and timeline:

1)   Run at least as fast as the current version

2)   Efficiency for triggering prompt muons should be at least as high as in current version

3)   Robust against high pile-up

4)   Simpler to debug

5)   Higher efficiency for long-lived particles

6)   Higher efficiency for  close muons

7)   Use modern CMSSW framework features

Design:

1)   Seeding: One inside-out seeding algorithm using

For now we will use 1 seed collection. When we need to know if the seed was IO or OI we can just ask for its direction. We need to think about how the ROI will be created for the seed finding.

 

The OI algorithm will be a combination of state based and hit based. For OI state based the errors are rescaled, including alignment. For OI hit based we need to consider how many layers should be used, especially in the overlap region.

 

For the IO hit based algorithm we will reuse all the current tracking code. We need to consider how the window size will be created and whether we use the error matrix when calculating the size.

 

2)   Regional (track) reconstruction

3)   Matching

4)   Final fit and parameter assignment

5)   Filter

 

Aim

This page aims to describe the general code design layout for the new L3 Muon Trigger code. The main concern with the L3 reconstruction is with the high PU runs that will seen post-LS1. There will be a higher tracker hit density and therefore creator number of combinatorics when creating tracks. The new design should be able to successfully process close by muons and be highly efficient. The new design should be tested against different samples.

 

Overview

The code is focused around 4 main steps: seeding, trajectory building, matching and fitting to the stand alone muon. The code will focus around two types of seeding: Outside-In (OI) and Inside-out (IO). The aim of the two types of seeding should be to effectively find both prompt and displaced muons, whilst rejecting fake tracks especially at high Pile Up (PU) conditions.

 

The OI seeding will be state based in order to quickly identify the majority of muon events efficiently. The use of a state based seeding algorithm will be important with the higher track density foreseen, producing a greater number of hit based seeds. However for the muons not correctly identified using the OI-state based seeding, the IO seeding will be based hi. This will be slower than the OI-state based. --> Think about if IOHit was sufficient at finding the displaced tracks: as this type of seeding was more sensitive to the generated distance from the beamspot was usually out.

 

Tasks/Concepts

The power of using iterative tracking within L3 reconstruction needs to be tested in order to see if it should be incorporated into the design. Even if the actual recipe for using online iterative tracking cannot be used, the general principle of first selecting the 'easy' tracks, and then attempting progressively more difficult tracks should be considered.

 

A tuneable test metric for each track or collection of tracks should be introduced, which can successfully stop the reconstruction when a suitable tracker track is found. This will be the equivalent of having the filters used in the current design.

 

One possibility is to have 6 iterations: 3 using OI state based seeding, followed by 3 IO hit based seeding. These 3 iterations for each seeding mechanism will first target high pT prompt muons, then low pT prompt muons and finally displaced muons. With this format of iterations, additional iterations can be included in the future, and iterations deemed to have poor performance can be removed.

Image Removed

The seeding for the IO-hit based algorithm could be based off of the same method as the current online iterative tracking; which takes pixel tracks.

 

Where the time is taken in the current and future designs needs to be understood in order for optimisation.

New Design 1

In New Design 1 for the production part there are 2 modules (EDProducers). The first produces a collection of L3 Tracks given a L2 muon track collection. The second produces L3 Muon track links collection are matching a L3 track with the L2 track. The following diagram describes the process:

 

 

Image Removed

 

Compared to the current design, described below there are fewer calls to read/write from the event bus (described by the blue bar in these diagrams). One of the motivations to have this in 2 modules instead of one is to perform the check on whether a seed generation algorithm needs to be activated or not by checking the currently available L3 tracks.

 

Comments from Current Design

The current design is as follows: for the the production there are 4 modules which call 4 classes (EDProducers). The following diagram describes the process:

 

Image Removed

Track Seed Generation

In the current design the TSG is performed in the following way: For each L2 muon track look at the current L3 tracks, take the seeds of these tracks and get the reference to the L2 track then see if this is the same as the original L2 muon, if so then do not process this L2 muon.

 

The trajectory seed builder for OIState uses: TSGForRoadSearch: class generates hit-less TrajectorySeed from a given Track (=L2 cand). the original error matrix of the Track is adjusted (configurable). In particular for OIState: TSGForRoadSearch::makeSeeds_3.

 

Running the New Code

Assuming bash on a system with CMSSW and afs:

 

export SCRAM_ARCH=slc5_amd64_gcc472
cmsrel CMSSW_6_1_2
cd CMSSW_6_1_2/src && cmsenv
addpkg RecoMuon/L3TrackFinder
mkdir Test && cd Test
mkedanlzr Muons
cd ../
#--> copy new code and test code to local copy
cp /afs/cern.ch/user/b/benjamin/public/NewL3Code/Testing/BuildFile.xml Test/Muons/.
cp /afs/cern.ch/user/b/benjamin/public/NewL3Code/Testing/src/MuTrigEff.cc Test/Muons/src/.
cp /afs/cern.ch/user/b/benjamin/public/NewL3Code/Testing/interface/MuTrigEff.h Test/Muons/interface/.
cp /afs/cern.ch/user/b/benjamin/public/NewL3Code/Testing/test/runNewL3.py Test/Muons/test/.
cp /afs/cern.ch/user/b/benjamin/public/NewL3Code/Code/* RecoMuon/L3TrackFinder/plugins/.
scram b -j8

 

 

New TSG Design For OI

We will combine the OIState and OIHit into one TSG: TSGForOI.

NewTSG.png

 

Idea is to run the OI State based algorithm unless it is deemed necessary to run the OI Hit based algorithm. Deciding whether to use hits in the algorithm comes from a fast analysis of two TSOS's. The first TSOS comes from a propagation from the Muons Detectors directly to a layer on the outside of the tracking system. The second TSOS comes from a propagation to the vertex with an updated error matrix, which is then propagated to the outside of the tracking system. The direction and position difference between the two TSOS's are measured.

 

From testing it appears the difference in the phi measurement should provide a useful variable to trigger the inclusion of hits in order to get a more precise seed, from which we create the tracks.

 

Timeline → TSG workshop at beginning of November  (MUO POG)  
  1. Need to have the new L3 reconstruction sequence implemented, following the previous work by Benjamin. 
    Status
    colourGreen
    titleDONE
  2. Once is implemented, it is needed to compare it with the current L3 sequence.  Minimal set of the studies for old/new L3 comparisons:  
    Status
    colourGreen
    titleDONE

    1. Efficiency versus eta, phi, pT, PU
      Status
      colourGreen
      titleDONE
        + vs dxy and dz in case of displaced muons  
      Status
      colourGreen
      titleDONE
    2. Timing (using Neutrino gun or HLT physics data, depending of what is recommended by STEAM now )  
      Status
      colourGreen
      titleDONE
    3. Track quality variable comparisons (Chi2, dxy, …) for DY and background like muons (QCDMuEnriched, HLTPhysics or ZeroBias if enough stat… )   
      Status
      colourGreen
      titleDONE
  3. Comparison of the new L3 tracking with the one used in the Tk muon reco  
    Status
    colourGreen
    titleDOne
Timeline → first month of 2017  (TSG)  
  1. Optimize the new L3 reconstruction:   
    Status
    colourGreen
    titleDONE
    1. IO algorithm – ROI    
      Status
      colourGreen
      titleDONE
    2. OI algorithm   
      Status
      colourGreen
      titleDONE
  2. More complete set of studies on performance comparisons using MuXX OR TkMuXX as a FOM, different signal samples should be tested in order to have all possible phase spaces covered: DY, ttbar, close-by-muon , displaced muons, low pT muon (from JPsi)    
    Status
    colourRed
    titlePENDING

    1. Efficiency versus eta, pT, PU,  (for the early studies using DY and displaced muons) + vs dxy and dz in case of displaced muons   
      Status
      colourRed
      titlePENDING
    2. Timing (using Neutrino gun or HLT physics data, depending of what is recommended by STEAM now )   
      Status
      colourRed
      titlePENDING
    3. Rate comparisons for tracks passing a given pT threshold (QCDMuEnriched, HLTPhysics or ZeroBias if enough stat… )  
      Status
      colourRed
      titlePENDING
    4. Track quality variable comparisons (Chi2, dxy, …) for DY and background like muons (QCDMuEnriched, HLTPhysics or ZeroBias if enough stat… )  
      Status
      colourRed
      titlePENDING
  3. Revise/design a smarter the combination of the out-in and in-out sequence.   
    Status
    colourYellow
    titleON-GOING
  4. Ideas/prelim studies on the combination between new L3 and Tk muon reconstruction   
    Status
    colourRed
    titlePENDING
  5. Have already in place in CMSSW the new L3 sequence using current geometry.   
    Status
    colourYellow
    titleON-GOING
    1. Including the new module which runs the TkMu path if the New L3 does not reconstruct the muon successfully.    
      Status
      colourRed
      titlePENDING
    2. List of unused classes that could be removed from CMSSW when switching to the new L3.    
      Status
      colourYellow
      titleON-GOING
Final deadline for having integrated in CMSSW, March 2017.   
  1. Switch to new geometry and test everything still works.   

    Status
    colourRed
    titlePENDING

  2. Clean-up CMSSW by removing unused classes.    
    Status
    colourRed
    titlePENDING

Task list for the next milestone:   

  •  Properly define efficiency
    Status
    colourYellow
    titleON-GOING
    •  removing all cuts from the filter to avoid including the filter efficiency on the calculation.  
    •  Check pattern recognition, by shared hits (probably not on every sample, just a cross-check of goodness)  
      Status
      colourYellow
      titleON-GOING
  •  Performance comparisons for the between Iterative L3 IO/OI and IOH/OIH/OIS:   
    Status
    colourYellow
    titleON-GOING
    •  efficiency vs eta, pT, PU, dxy, dz, chi2...  
      Status
      colourYellow
      titleON-GOING
  •  Put a combination in place: 
    Status
    colourYellow
    titleON-GOING
    •  Understanding current under-performance: revise sequence. 
      Status
      colourYellow
      titleON-GOING
  •  Performance comparisons for the IterL3 vs Cascade
    Status
    colourRed
    titlePENDING
    •  efficiency vs eta, pT, PU, dxy, dz, chi2... 
      Status
      colourRed
      titlePENDING
    •  timing measurements. (follow TSG recipe) 
      Status
      colourRed
      titlePENDING
    •  rate comparisons/ (follow TSG recipe) 
      Status
      colourRed
      titlePENDING
  •  Prepare a complete talk containing the full package ready to deliver 
    Status
    colourRed
    titlePENDING
  •  Performance comparisons for the IterL3 vs Mu50 OR TkMu 
    Status
    colourRed
    titlePENDING

    •  efficiency vs eta, pT, PU, dxy, dz, chi2... 
    •  timing measurements. (follow TSG recipe) 
    •  rate comparisons/ (follow TSG recipe) 
  •  Based on that, decide whether a combination procedure is needed or if we can drop TkMu50 once for all. 
    Status
    colourRed
    titlePENDING
    •  repeat performance comparisons.

 


  •  Switch to new geometry 
    Status
    colourRed
    titlePENDING
  •  Clean-up CMSSW by removing unused classes 
    Status
    colourRed
    titlePENDING
    •  List of unused classes that could be removed from CMSSW when switching to the new L3 

 

Design:

A two-sequence algorithm based on iterative tracking is being implemented:   (write here more details...) 

OI design and testing

The outside-in algorithm consist of four steps:

  1. Seed generation:   TSGforOI.cc
  2. TrajectoryCandidate:   CkfTrackCandidateMaker.cc
  3. TrackProducer:  TrackProducer.cc
  4. L3MuonProducer:  L3MuonProducer.cc

The important step to optimise/study is the seed generation, current implementation allows for a great number of combinations varying the number of seeds, the rescaling factors and a number of parameters, this is the default configuration as of 15/11/2016:  

UseHitlessSeeds = cms.bool(True), 
UseHybridSeeds = cms.bool(False),
adjustErrorsDyanmicallyForHitless = cms.bool(False),
adjustErrorsDyanmicallyForHits = cms.bool(False),
estimator = cms.string('hltESPChi2MeasurementEstimator100'),
fixedErrorRescaleFactorForHitless = cms.double(5.0),
fixedErrorRescaleFactorForHits = cms.double(2.0),
pT1 = cms.double(13.0),
pT2 = cms.double(30.0),
pT3 = cms.double(70.0),
eta1 = cms.double(1.0),
eta2 = cms.double(1.4),
SF1 = cms.double(3.0),
SF2 = cms.double(4.0),
SF3 = cms.double(5.0),
SF4 = cms.double(7.0),
SF5 = cms.double(10.0),
hitsToTry = cms.int32(5),
layersToTry = cms.int32(3),
maxEtaForTOB = cms.double(1.2),
maxSeeds = cms.uint32(15),
minEtaForTEC = cms.double(0.8),

First thing checked is the distance between the generated seed compared to the reconstructed hit: 

Image Added Image Added

Several parameters can be tuned in the seed generation step:

  • run hybrid / hit seeds
  • number of seeds
  • range of TOB, TEC
  • hits/layers to try
  • adjust errors dynamically or not
  • rescaling factors

Optimization 

Here is a list of checks to optimise the algorithm:

  •  number of seeds
  •  range of the TOB, TEC
  •  once on TEC, use the stereo layers only instead of a random hit? 
  •  hit/layers to try 
  •  adjust errors dynamically
  •  rescaling factors.

A number of checks have been performed to optimised the outside-in algorithm, after some basic tunes, we gain 3% w.r.t. the performance of OIS and OIH. All the plots here: https://folguera.web.cern.ch/folguera/private/MUO/161115/OI_Optimisation/

We check that increasing the number of seeds improves the efficiency, it somehow saturates at ~10 seeds (1 TSOS + 9 hit)  

Image AddedImage Added

Then we checked the overlap region between the TOB and the TEC.  In this region, after looping over TOB the maximum number of seeds is re-initialised to 0 and the count starts in the TEC, we narrowed the region with little impact in the efficiency (0.3%), this narrowing will be faster but we still need absolute numbers for that: 

Image Added          Image Added   

 

We tried using what was called Hybrid seeds (now HitlessAndHitSeeds), which is deciding whether to add a hit seed depending on the parameters of the L2:  3% gain w.r.t using only the TSOS and 5% w.r.t old L3.

Image Added

We'll now focus on the HitlessAndHitSeeds combination.  Now we will try to find an optimal choice of (dynamical) rescaling errors. 

 

Lastly we check if we can make use of stereo layer hits instead of mono-hits in the TEC.  

 

Performance results:  

IO design and testing

Taking all the parameters from the tracker community. Already in the current HLT menu, as it is used for the HLT_TkMu50 path: 

fragment.HLTHighPt50TrackerMuonSequence = cms.Sequence( fragment.HLTDoLocalPixelSequence + fragment.HLTDoLocalStripSequence + fragment.hltL1MuonsPt15 + fragment.HLTIterativeTrackingHighPtTkMu + fragment.hltHighPtTkMu50TkFilt + fragment.hltHighPtTkMuons + fragment.hltHighPtTkMuonCands )
fragment.HLTIterativeTrackingHighPtTkMuIteration0 = cms.Sequence( fragment.hltPixelLayerTriplets + fragment.hltIter0HighPtTkMuPixelTracks + fragment.hltIter0HighPtTkMuPixelSeedsFromPixelTracks + fragment.hltIter0HighPtTkMuCkfTrackCandidates + fragment.hltIter0HighPtTkMuCtfWithMaterialTracks + fragment.hltIter0HighPtTkMuTrackSelectionHighPurity )
fragment.HLTIterativeTrackingHighPtTkMuIteration2 = cms.Sequence( fragment.hltIter2HighPtTkMuClustersRefRemoval + fragment.hltIter2HighPtTkMuMaskedMeasurementTrackerEvent + fragment.hltIter2HighPtTkMuPixelLayerPairs + fragment.hltIter2HighPtTkMuPixelSeeds + fragment.hltIter2HighPtTkMuCkfTrackCandidates + fragment.hltIter2HighPtTkMuCtfWithMaterialTracks + fragment.hltIter2HighPtTkMuTrackSelectionHighPurity )
fragment.HLTIterativeTrackingHighPtTkMu = cms.Sequence( fragment.HLTIterativeTrackingHighPtTkMuIteration0 + fragment.HLTIterativeTrackingHighPtTkMuIteration2 + fragment.hltIter2HighPtTkMuMerged )

Optimization 

Things to be checked: 

  •  Test extreme cases to make sure things work Unknown User (sfolguer):  large/tiny region using TTBar or WJets
  •  Produce a ROC curve efficiency vs timing
  •  Define the working point and close this topic.

 

Need to optimise the definition of the ROI: the current choice seems to match no other choice in the HLT, check if it is the best choice:    
MasterMuonTrackingRegionBuilder = cms.PSet(
Rescale_eta = cms.double( 3.0 ),
Rescale_phi = cms.double( 3.0 ),
Rescale_Dz = cms.double( 4.0 ), #Normally 4
EscapePt = cms.double( 3.0 ), #Normally 1.5 but it should be at least 8 for us
EtaR_UpperLimit_Par1 = cms.double( 0.25 ), #Normally 0.25
EtaR_UpperLimit_Par2 = cms.double( 0.15 ), #Normally 0.15
PhiR_UpperLimit_Par1 = cms.double( 0.6 ), #Normally 0.6
PhiR_UpperLimit_Par2 = cms.double( 0.2 ), #Normally 0.2
UseVertex = cms.bool( False ), #Normally False
Pt_fixed = cms.bool( False ), #Normally True
Z_fixed = cms.bool( False ), #True for IOH
Phi_fixed = cms.bool( True ), #False for IOH
Eta_fixed = cms.bool( True ), #False for IOH
Pt_min = cms.double( 3.0 ), #Is 0.9 for Tau; normally 8 here
Phi_min = cms.double( 0.1 ),
Eta_min = cms.double( 0.1 ),
DeltaZ = cms.double( 24.2 ), #default for tau: 24.2, for old IOH: 15.9
DeltaR = cms.double( 0.025 ), #This changes for different iterations. for old IOH: ?
DeltaEta = cms.double( 0.04 ), #default 0.15
DeltaPhi = cms.double( 0.15 ), #default 0.2
maxRegions = cms.int32( 2 ),
precise = cms.bool( True ),
OnDemand = cms.int32( -1 ),
MeasurementTrackerName = cms.InputTag( "hltESPMeasurementTracker" ),
beamSpot = cms.InputTag( "hltOnlineBeamSpot" ),
vertexCollection = cms.InputTag( "pixelVertices" ), #Warning: I am not generating colleciton. Vertex is off anyway
input = cms.InputTag( 'hltL2Muons','UpdatedAtVtx' )
)
fragment.HLTPSetMuonTrackingRegionBuilder8356 = cms.PSet( 
  Rescale_eta = cms.double( 3.0 ),
  Rescale_phi = cms.double( 3.0 ),
  Rescale_Dz = cms.double( 3.0 ),
  EtaR_UpperLimit_Par1 = cms.double( 0.25 ),
  EtaR_UpperLimit_Par2 = cms.double( 0.15 ),
  PhiR_UpperLimit_Par1 = cms.double( 0.6 ),
  PhiR_UpperLimit_Par2 = cms.double( 0.2 ),
  UseVertex = cms.bool( False ),
  Pt_fixed = cms.bool( False ),
  Z_fixed = cms.bool( True ),
  Phi_fixed = cms.bool( False ),
  Eta_fixed = cms.bool( False ),
  Pt_min = cms.double( 1.5 ),
  Phi_min = cms.double( 0.1 ),
  Eta_min = cms.double( 0.1 ),
  DeltaZ = cms.double( 15.9 ),
  DeltaR = cms.double( 0.2 ),
  DeltaEta = cms.double( 0.2 ),
  DeltaPhi = cms.double( 0.2 ),
  maxRegions = cms.int32( 2 ),
  precise = cms.bool( True ),
  OnDemand = cms.int32( -1 ),
  MeasurementTrackerName = cms.InputTag( "hltESPMeasurementTracker" ),
  beamSpot = cms.InputTag( "hltOnlineBeamSpot" ),
  vertexCollection = cms.InputTag( "pixelVertices" ),
  input = cms.InputTag( 'hltL2Muons','UpdatedAtVtx' )
)
Making a ROC curve:

Efficiency (WJets) vs Timing (HLTPhysics)

## Eficiency:
ssh -X lxplus
/afs/cern.ch/user/f/folguera/workdir/MUO/CMSSW_8_0_19/src/MuonHLT/MuonHLTDebugger/test/ROI
cmsRun myHLT_Mu50_withL3_IO_0p6_0p6_0p6_Fix.py &>myHLT_Mu50_withL3_IO_0p6_0p6_0p6_Fix.log&
## Timing:
ssh -X vocms003
cd /data/user/folguera/CMSSW_8_0_19/src/TimingScripts/test/ROI
nohup taskset -c 1 cmsRun myHLT_Mu50_withL3_IO_0p2_0p2_0p2_Fix.py >& myHLT_Mu50_withL3_IO_0p2_0p2_0p2_Fix.log&

 

Image Added

16/10/10 22:49 :  picked dynamic 0p2 size, increasing pt_min to 3.0 GeV and improved timing, check if I can improve offs. 

Performance studies

All the plots can be found here:  https://folguera.web.cern.ch/folguera/private/MUO/161024/NewIOvsIOH/

Combination procedure

Other issues and tests

efficiency drop for phi ~ 2 rads.

A drop in efficiency around 2 radians have been observed in both algorithms:

Image Added

We