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
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
4) Final fit and parameter assignment
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.
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:
cd CMSSW_6_1_2/src && cmsenv
mkdir Test && cd Test
#--> 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.
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.