Child pages
  • Iterative L3 Trigger Reconstruction

Versions Compared


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


1)   Run at least as fast as the current version


7)   Use modern CMSSW framework features


1)   Seeding: One inside-out seeding algorithm using


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 new design should be able to successfully process close by muons and be highly efficient. The new design should be tested against different samples.



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.


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:


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



New TSG Design For OI

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