Child pages
  • Iterative L3 Trigger Reconstruction
Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 6 Next »


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


1)   Seeding: One inside-out seeding algorithm using

2)   Regional (track) reconstruction

3)   Matching

4)   Final fit and parameter assignment

5)   Filter



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 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.



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.

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:




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:


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/ Test/Muons/.
cp /afs/ Test/Muons/src/.
cp /afs/ Test/Muons/interface/.
cp /afs/ Test/Muons/test/.
cp /afs/* RecoMuon/L3TrackFinder/plugins/.
scram b -j8



  • No labels