Extended Tracking for Phase 2 in Fast Simulation

Introduction

The current FastSim has been developed during several years to achieve a good realism for the current detector. This introduced a strong dependence on the geometry in several places.

The goal of this wiki is to document a general extension of the FastSim to a Phase 2 Tracker detector.

People involved: Andrew Levin, Patrizia Azzi, Luca Malgeri, Andrea Giammanco

Creating a geometry with tkLayout

Note: this section is only for experts. Normal users, when the tool will be complete, will be encouraged to use geometries produced and validated by experts.

Log into lxplus5 and do this:

source /afs/cern.ch/sw/lcg/app/releases/ROOT/5.34.00/x86_64-slc5-gcc43-dbg/root/bin/thisroot.sh;
source /afs/cern.ch/sw/lcg/contrib/gcc/4.3/x86_64-slc5/setup.sh;
svn checkout -r 696 http://tkgeometry.googlecode.com/svn/trunk/ tkgeometry-readonly

The checked out directory should be named something different from "tkgeometry" because a "tkgeometry" directory will be used for a different purpose later.

Remove the following lines from tkgeometry-readonly/Makefile:

#COMPILERFLAGS+=-Wno-narrowing
#COMPILERFLAGS+=-Wno-delete-non-virtual-dtor

Go into tkgeometry-readonly and do:

make clean && make -j4 && make install

Give the suggested answer to all of the questions:

Where should I install the binary?
(Choose a directory in your PATH) [ /afs/cern.ch/user/a/anlevin/bin ]: /afs/cern.ch/user/a/anlevin/bin

*** What is the web server directory where you want to
    place your output?
    Example: /afs/cern.ch/user/a/anlevin/www/layouts : /afs/cern.ch/user/a/anlevin/www/layouts

*** What is the standard output directory?
    xml files and other various output will be put here
    Example: /afs/cern.ch/user/a/anlevin/tkgeometry : /afs/cern.ch/user/a/anlevin/tkgeometry

*** Specify the list of transverse momenta to be used for the
    tracking performance test (in GeV/c)
    Example: 1, 10, 100 : 1, 10, 100

*** Specify the list of transverse momenta to be used for the
    trigger efficiency performance test (in GeV/c)
    Example: 1, 2, 5, 10 : 1, 2, 5, 10

*** Specify the list of trigger efficiency to be used for the
    pt threshold find test (in percent: write 100 for full efficiency)
    Example: 1, 50, 90, 95 : 1, 50, 90, 95

Copy all of the files in /afs/cern.ch/user/a/anlevin/public/OurTrackerPt_tklayout_cfg_files_27May2013/ into the directory tkgeometry-readonly.

Then do

./bin/tklayout OurTrackerPt --xml

tklayout will then produce the xml files for the geometry described in the configuration files and put them in the directory tkgeometry/xml/OurTrackerPt/

Running with the new FastSim with a new geometry

First attempt with Phase1 (porting HC code from 428slhc) - SUPERSEDED NOW

A first attempt in using a modern release (CMSSW_6_1_2_SLHC4) is reported here. Few files needed a porting from the work done by Harry for the release 4_2_8, but the rest seems ok and we are able to see a simulation geometry matching the pixel phase1. All files needed to run (including a change in PFRootEvent) are in CVS under UserCode/TrackerFlexSim directory. A script to create a working area with all patches is attached here. The script asks you for a tag. The current version of the tag to be used is phaseIstdConf_v3. This includes all patches to run up to the tracking validation step (and FamosWithEverything sequences)

Once downloaded the script you can:

createarea phaseIstdConf_v3
cd CMSSW_6_1_2_SLHC4/src
scram b
cd FastSimulation/Configuration/test
cmsRun patest_cfg.py

It produces an histos.root file which contains the cylinder based geometry and the simulation geometry (histograms 3x0 and 3x1, respectively). Other outputs (display.root, edm file, etc) can be enabled in the cfg file.

An example plot is given here:
phase1_closeup.png

Note: I have not found an easy way to checkout directly the files from usercode to a working CMSSW directory (matching problem) so I took the shortcut of dumping the usercode area and copying it over....it can/should be changed by experts...

Current unified recipe for both phase1 and phase2

export SCRAM_ARCH=slc5_amd64_gcc472
scram p CMSSW CMSSW_6_2_0_SLHC8
cd CMSSW_6_2_0_SLHC8/src/
cmsenv
git init
git remote add my-cmssw https://github.com/AndrewLevin/cmssw.git
git fetch -t my-cmssw
git cms-sparse-checkout CMSSW_6_2_0_SLHC8 TrackerFlexSimV0.4
git checkout TrackerFlexSimV0.4
git cms-checkdeps -a
scram b -j4
cd FastSimulation/Configuration/test/

You can determine which geometry to use by commenting or uncommenting the following lines in FSIM_upgtracker_cfg.py

GEOM="phase1"
#GEOM="phase2BE"
#GEOM="phase1forward"
#GEOM="phase2BEforward"

Note that the BE geometries still use the barrel-endcap geometry with 7 forward strip layers, instead of 5 as in the most recent version.

Then to run the simulation do the following:

cmsRun FSIM_upgtracker_cfg.py

This produces all files as described in the previous section. The latest version of the tag recovers hits in the endcap tracker that were missing in the v1. The missing hits were due to:

  • a definition of the endcap sub-blades as trapezoid but with bottom and top edge identical (i.e. rectangular) and this creates problems to the estimator
  • a navigation strategy not compatible with the endcap geometry

The following plot shows the same tt bar event in three different steps:

  • hit map just fixing the trapezoid/rectangle discrepancy (only 5 hits in the endcap)
  • hit map adding new binfinder for the PixelBlade
  • hit map adding a radius based matching for blades in PixelForwardLayer Screen_Shot_2013-06-14_at_Fri_Jun_14_5.28.06_PM.png

IMPORTANT: No validation has been completed on this, it could be that still many hits are missing..... it is just a starting point.

Performance

As a starting point we have checked the tracking efficiency vs eta and vs pt using the MTV and comparing with standard detector fastsim. The comparison is NOT on the same footing given that for phase 2 we are running basically only one step of the iterative tracking with seeds coming only from triplets in the phase1 pixel. This means that especially in the low pt region and in the displaced tracks the efficiency is by construction lower.
Plots for single muon events standard detector/full iterative,phase 2 detector/step0 only:
Screen_Shot_2013-07-03_at_11.23.54_AM.png Plots for single tt-bar events standard detector/full iterative,phase 2 detector/step0 only:
Screen_Shot_2013-07-03_at_10.53.09_AM.png Screen_Shot_2013-07-03_at_10.56.25_AM.png

Timing info. In the following is a comparison of time-per-module info in the two configurations above for ttbar events (threshold=5ms/event).
Standard detector/full iterative time info:

Timing per module 
================= 
   1                               MultiTrackValidator : 1.48e+03 ms/event
   2                                FastjetJetProducer :     225 ms/event
   3                          MuonAssociatorEDProducer :     178 ms/event
   4                                     TrackProducer :     162 ms/event
   5                                    MuonIdProducer :     154 ms/event
   6                                      MixingModule :     111 ms/event
   7                              EcalTrigPrimProducer :    55.3 ms/event
   8                                     FamosProducer :    47.4 ms/event
   9                         TrackAssociatorEDProducer :    40.2 ms/event
  10                            Pythia6GeneratorFilter :    32.9 ms/event
  11                                   RPCDigiProducer :    29.4 ms/event
  12                                  GoodSeedProducer :      21 ms/event
  13                             TrackingTruthProducer :    20.8 ms/event
  14                      EcalSelectiveReadoutProducer :    20.8 ms/event
  15                             PrimaryVertexProducer :    20.4 ms/event
  16                                    RecoTauCleaner :    20.2 ms/event
  17                PFRecoTauDiscriminationByIsolation :    16.6 ms/event
  18                                 RecoTrackSelector :    16.2 ms/event
  19                           SecondaryVertexProducer :    15.1 ms/event
  20                                  GsfTrackProducer :      13 ms/event
  21                                   RecoTauProducer :    11.4 ms/event
  22                                 TrackExtrapolator :    11.3 ms/event
  23          SiTrackerGaussianSmearingRecHitConverter :    10.7 ms/event
  24                            StandAloneMuonProducer :    10.6 ms/event
  25                            TrackCandidateProducer :    9.46 ms/event
  26                            TrajectorySeedProducer :    9.42 ms/event
  27                                       METProducer :    8.49 ms/event
  28                                MultiTrackSelector :    7.39 ms/event
  29                                 CaloTowersCreator :    7.26 ms/event
  30                                   TevMuonProducer :    7.14 ms/event
  31                        GenericPFCandidateSelector :    5.88 ms/event
  32                                   CSCDigiProducer :    5.77 ms/event
  33                             PFSimParticleProducer :    5.42 ms/event
  34                                ConversionProducer :    5.21 ms/event
  35                                   TrackIPProducer :    5.05 ms/event
  36                         PFDisplacedVertexProducer :    5.05 ms/event
Upgraded detector/only one iteration time info:
Timing per module 
================= 
   1                               MultiTrackValidator :     778 ms/event
   2                                FastjetJetProducer :     257 ms/event
   3                                     FamosProducer :     203 ms/event
   4                                      MixingModule :     120 ms/event
   5                                    MuonIdProducer :     112 ms/event
   6                          MuonAssociatorEDProducer :    88.2 ms/event
   7                                  GsfTrackProducer :      67 ms/event
   8                              EcalTrigPrimProducer :    53.4 ms/event
   9                         EcalUncalibRecHitProducer :    38.5 ms/event
  10                                     TrackProducer :    37.6 ms/event
  11                                   RPCDigiProducer :    35.3 ms/event
  12                                   CSCDigiProducer :    32.9 ms/event
  13                            Pythia6GeneratorFilter :    31.8 ms/event
  14                                     EcalDigiToRaw :    24.1 ms/event
  15                         TrackAssociatorEDProducer :      22 ms/event
  16                      EcalSelectiveReadoutProducer :    20.8 ms/event
  17                             PrimaryVertexProducer :    18.7 ms/event
  18                                       METProducer :    18.3 ms/event
  19                             TrackingTruthProducer :    16.4 ms/event
  20                                  GoodSeedProducer :    15.8 ms/event
  21                           SecondaryVertexProducer :      15 ms/event
  22                                 CaloTowersCreator :    14.2 ms/event
  23                                 TCRecoTauProducer :    13.6 ms/event
  24                            TrajectorySeedProducer :    12.7 ms/event
  25                            StandAloneMuonProducer :    12.1 ms/event
  26                                    PhotonProducer :    11.6 ms/event
  27                                 RecoTrackSelector :    10.9 ms/event
  28                                   TrackIPProducer :      10 ms/event
  29                                   RecoTauProducer :    9.85 ms/event
  30                               CaloRecoTauProducer :    9.76 ms/event
  31                                 PFClusterProducer :    9.28 ms/event
  32                                   TevMuonProducer :    8.24 ms/event
  33                                ConversionProducer :    8.15 ms/event
  34          SiTrackerGaussianSmearingRecHitConverter :     7.1 ms/event
  35                      InputGenJetsParticleSelector :    5.77 ms/event
  36                                  PFElecTkProducer :    5.69 ms/event
  37                               CaloRecHitsProducer :    5.65 ms/event
  38                              JetPlusTrackProducer :    5.52 ms/event
  39                                   PFBlockProducer :    5.09 ms/event

Configuration of the purely simulation part

Configuration of the RecHits smearing

In the FastSim there is no digitization of the Silicon Tracker. The RecHits are then obtained from a simple smearing of the SimHits. For the current (RunI) detector a layer-dependent Gaussian resolution is applied to strips, and templates taken from FullSim are applied to pixels. Moreover bad channel removal can also be applied. See the code in: FastSimulation/TrackingRecHitProducer/python/SiTrackerGaussianSmearingRecHitConverter_cfi.py.

For an upgrade configuration and generic geometry the resolution are not known, the type of layers might be different as well. In order to mantain flexibility the code has been modified with additional switches so that a simple resolution can be input by a cfg.

In this version of the code there is a Gaussian smearing equal for pixels and strips, all layers and disks. The validation shown at the bottom of this page is for a smearing of 0.003 cm on X and 3 cm on Y.

To keep things clean, I created a different cfi for Phase 2 conditions, and added a switch in some places in FamosSequences between "normal" and "phase2".

  • Add here validation plots with ResX for Pixel layers/disks rechitsval.png

Configuration of the tracking

In the FastSim there is no pattern recognition performed as it would be too slow. Instead the Rechits belonging to a SimTrack are all collected and passed to the standard fit routine. In order to emulate efficiencies though the track is kept only if its hits pass the emulation of the various iterative tracking steps.

For an upgraded detector the iterative tracking has not been optimized yet, so for these studies we will start from a simplified one-iteration tracking approach. In the current case this is iteration 0 of the current tracking. (of course now that we have the Phase I geometry we will need to modify the pixel seeding to take advantage of the new detector)

Comparison with cand1 SLHC7 release

It was decided to implement the above changes in a candidate SLHC7 release prepared by David. Meanwhile Giuseppe C. provided fixes needed for full sim tracking in phase2. One of the fixes is in PixelForwardLayer.cc (in RecoTracker/TkDetLayers) that was also modified in the fastsim branch in order to get tracking in the forward region in phase2. The two implementations are totally different so here is also an attempt to see if they are compatible/interchangeable.
All tests reported here compare the Upgrades_v6 tags above (stand alone fastsim changes) with the SLHC7 cand1 release according to David's recipe:
scram p CMSSW CMSSW_6_1_2_SLHC6_patch1
cd CMSSW_6_1_2_SLHC6_patch1/src
cmsenv
git cms-merge-topic davidlange6:SLHC7_Cand1
scram b -j 8

Test1: comparison of results using the "private" top level cfg (FSIM_upgtracker_cfg.py)

The top level config contains local customization that should be propagated to a proper cmsdriver command (this is tested in the next step). The results shows good agreement for Phase1 geometry. For Phase2 geometries an improvement for low Pt tracks is seen (below 2 GeV). This is not expected but a nice surprise. For completeness I've tested the Upgrades_v6 tags on top of a SLHC6_patch1 release (instead of the SLHC4 where most of the code was developed) to verify if the improvements comes from a change between SLHC4 and SLHC6_patch1, but this is not the case
.

Tracking efficiency vs eta and pt for Phase1 ( Upgrades_v6 , SLHC7_cand1 )
comp_v5_SLHC7_ph1_eta.png comp_v5_SLHC7_ph1_pt.png

Tracking efficiency vs eta and pt for Phase2 ( Upgrades_v6 , SLHC7_cand1 )
comp_v5_SLHC7_ph2_eta.png comp_v5_SLHC7_ph2_pt.png

Test2: comparison of results using the cmsdriver commands

Following David's recipe we have tested the full chain with the cmsdriver command:
cmsDriver.py FastSimulation/Configuration/python/ttbar_cfi.py --step GEN,SIM,RECO,VALIDATION --fast --conditions auto:upgradePLS3 --eventcontent FEVTDEBUGHLT,DQM --datatier GEN-SIM-DIGI-RECO,DQM --geometry Phase2  --customise SLHCUpgradeSimulations/Configuration/combinedCustoms.fastsimPhase2  -n 10

The results show good agreement between the cmsdriver output and the standalone top level cfg (i.e. the customization are propagated correctly).
Tracking efficiecy vs eta and pt for Phase2 using FSIM_Upgtracker_cfg.py and cmsdriver command ( FSIM_Upgtracker_cfg, cmsdriver ):
comp_SLHC7_ph2_cmsdriver_eta.png comp_SLHC7_ph2_cmsdriver_pt.png

Test3: comparison using the two implementations of PixelBarellLayer.cc and PixelForwardLayer.cc

The two implementations of the navigation (CompatibleDets) in the forward pixel layer for phase2 were written in a totally independent way in the FastSim studies and by Giuseppe C. This is an attempt to vrify if the two implementations are compatible/ give the same results. For the comparison, the files in:
http://cerati.web.cern.ch/cerati/dummyplots/phase2/PixelBarrelLayer.cc
http://cerati.web.cern.ch/cerati/dummyplots/phase2/PixelForwardLayer.cc
were used as suggested by Kevin Stenson. The results show that they are in perfect agreement and can be both used.
Tracking efficiency vs eta and pt using the Upgrades_v6 Pixel*Layer.cc implementation vs Giuseppe's Pixel*Layer.cc implementation in Phase1 ( Upgrades_v6 , Giuseppe's )
comp_SLHC7_GCPBLPFL_ph1_eta.png comp_SLHC7_GCPBLPFL_ph1_pt.png Tracking efficiency vs eta and pt using the Upgrades_v6 Pixel*Layer.cc implementation vs Giuseppe's Pixel*Layer.cc implementation in Phase2 ( Upgrades_v6 , Giuseppe's )
comp_SLHC7_GCPBLPFL_ph2_eta.png comp_SLHC7_GCPBLPFL_ph2_pt.png

Example geometries

This section includes tkLayout configurations (for experts) and xml files (for users).

....please put configurations here....

Validation tools

  • RecHit validation: Since the FastSim RecHits are a different object than the Standard one we cannot use the DQM code already available. A simple code is available in FastSimulation/TrackingRecHitProducer/test/GSRecHitValidation.cc. There are plots of the position, resolution, pulls for the various layers of the Tracker.

process.load("FastSimulation.TrackingRecHitProducer.GSRecHitValidation_cfi")
process.testanalyzer.outfilename = cms.string('rechitvalidation.root')

  • Multitrack validator

  • Full Validation sequence

....please put instructions here....

Old private code

More Less

IMPORTANT: instructions kept as "historical" reference, not recommended for users.

I made all tests in CMSSW_6_1_0. Please notice that there have been some technical modifications (by Vincenzo Innocente et al.) to some of the concerned packages already on top of this release. Nevertheless, my remarks stay valid also in CMSSW_6_2_1_pre1

Creating PSimHits with an extended tracker

Goal: extend geometry adding more pixel disks, and make sure that hits are created up to η<4.

As a side note: There has been work already, by Upgrade people, to adapt things to Phase 2 "long barrel". This was made in a branch of 4_2_X (slhcupgrade_LB_branch_4_2_X), never ported to a recent development release. But I don't think this is the way to go. My proposal is to make this code much more general, so that things like the number of layers and disks can be defined in a cfi. At that point, it would become trivial to switch between very different geometries by changing cfi (e.g. with a cmsDriver flag), even without having to implement a db or xml file of a realistic geometry. At that point we would have a tool as flexible as Delphes or PGS, in what geometry is concerned.

Tracker geometry

A lot of hard-coding.

A useful although very old (1_8_0) guide is available here.

This configuration file is where all the thicknesses of active and passive materials are set.
For each piece of material a vector of 5 values is defined; this is because previous developers wanted to switch easily between different tunings of the same detectors:

        # version 0 = Tracker geometry used between CMSSW_1_2_0 and CMSSW_1_4_10. Works for CSA07;
        # version 1 = Tuned to CMSSW_1_7_0 geometry
        # version 2 = Tuned to CMSSW_1_8_0 geometry
        # version 3 = Tuned to CMSSW_3_0_0 geometry
        # version 4 = Tuned to CMSSW_3_1_2 and CMSSW_3_3_0 geometries
        TrackerMaterialVersion = cms.uint32(4),

        #**********************************************************************
        # Thickness of all (sensitive and dead) layers in x/X0
        #**********************************************************************
        # Beam Pipe
        BeamPipeThickness = cms.vdouble(0.0038, 0.00265, 0.00265, 0.00265, 0.00240 ),
        (etc.)
Clearly this is not so useful nowadays, but we might recycle this functionality to switch easily between upgrade scenarios.

In FastSimulation/TrackerSetup/src/TrackerInteractionGeometry.cc the current sub-detector structure is heavily hard-wired. For example, the pixels disks:

  // Pixel disks
  // First Pixel disk: Z pos 35.5 radii 5.42078, 16.0756
  double innerRadius = (**fl).specificSurface().innerRadius()-1.0;
  double outerRadius = (**fl).specificSurface().outerRadius()+2.0;
  const SimpleDiskBounds PIXD1(innerRadius, outerRadius,-0.0150,+0.0150);
  const Surface::PositionType PPIXD1(0.0,0.0,(**fl).surface().position().z());
  // Second Pixel disk: Z pos 48.5 radii 5.42078, 16.0756
  ++fl;
  innerRadius = (**fl).specificSurface().innerRadius()-1.0;
  outerRadius = std::max( (**fl).specificSurface().outerRadius()+2.0, outerRadius+0.000 );
  const SimpleDiskBounds PIXD2(innerRadius, outerRadius,-0.0150,+0.0150);
  const Surface::PositionType PPIXD2(0.0,0.0,(**fl).surface().position().z());

In FastSimulation/TrackerSetup/interface/TrackerInteractionGeometry.h the numbering of the nested cylinders is hard-coded as

enum FirstCylinders { PXB=0,PXD=3,TIB=5,TID=9,TOB=12,TEC=18 };

In my private code I added 3 more pixel disks per side, so in addition to their addition to the .cc I had to modify that line in the .h:

enum FirstCylinders { PXB=0,PXD=6,TIB=8,TID=12,TOB=15,TEC=21 };

Other necessary modifications

The TrajectoryManager currently hard-codes a limit on the simulated particles:

    // The particle has a pseudo-rapidity (position or momentum direction) 
    // in excess of 3.0. Just simply go to the last tracker layer
    // without bothering with all the details of the propagation and 
    // material effects.
    // 08/02/06 - pv: increase protection from 0.99 (eta=2.9932) to 0.9998 (eta=4.9517)
    //                to simulate material effects at large eta 
    // if above 0.99: propagate to the last tracker cylinder where the material is concentrated!
    double ppcos2T =  PP.cos2Theta();
    double ppcos2V =  PP.cos2ThetaV();
    if ( ( ppcos2T > 0.99 && ppcos2T < 0.9998 ) && ( cyl == 0 || ( ppcos2V > 0.99 && ppcos2V < 0.9998 ) ) ){ 
      if ( cyliter != _theGeometry->cylinderEnd() ) { 
	cyliter = _theGeometry->cylinderEnd(); 
	--cyliter;
      }
    // if above 0.9998: don't propagate at all (only to the calorimeters directly)
    } else if ( ppcos2T > 0.9998 && ( cyl == 0 || ppcos2V > 0.9998 ) ) { 
      cyliter = _theGeometry->cylinderEnd();
    }

Trivially this can become:

    double ppcos2T =  PP.cos2Theta();
    double ppcos2V =  PP.cos2ThetaV();
    if ( ppcos2T > 0.9998 && ( cyl == 0 || ppcos2V > 0.9998 ) ) { 
      cyliter = _theGeometry->cylinderEnd();
    }

Validation tools

To quickly check whether the hits where created at the right places, previous developers had inserted in the TrajectoryManager code the possibility (commented out) to create 2D histograms for the "tracker radiography".
Tracker radiography with 1000 single muon events, with the current FastSim:

radio_standard.gif

Note: to go quick in testing this part, you can execute only the "sim" part of FastSim, with the new syntax that became available in 6_1_X; for example:

cmsDriver.py SingleMuPt10_cfi.py -s GEN,FASTSIM:sim --pileup=NoPileUp --conditions auto:startup_GRun --beamspot Realistic8TeVCollision --eventcontent=FEVTDEBUGHLT --datatier GEN-SIM-DIGI-RECO -n 1000

Current status: HELP NEEDED

Creating RecHits with no (or reduced) dependence on geometry

A useful (but very old) guide is here.

All the switches and resolutions are declared in FastSimulation/TrackingRecHitProducer/python/SiTrackerGaussianSmearingRecHitConverter_cfi.py.

Option 1: no hit smearing at all

Interestingly, it contains a switch trackingPSimHits which allows to apply no smearing at all. Hit uncertainty is therefore only given by material effects (e.g. multiple scattering). This option still works, luckily!

Option 2: simple smearing, same for all layers and disks

In the current FastSim, a layer-dependent Gaussian is applied to strips, and templates taken from FullSim are applied to pixels.
In my private code, I added a Gaussian smearing equal for pixels and strips, all layers and disks.
The validation shown at the bottom of this page is for a smearing of 0.003 cm on X and 3 cm on Y.

Current status: OK

To keep things clean, I created a different cfi for Phase 2 conditions, and added a switch in some places in FamosSequences between "normal" and "phase2".
(Same as for tracking below.)

The following recipe also considers the modifications to tracking (see next section):

cmsrel CMSSW_6_1_0
cd CMSSW_6_1_0/src
cmsenv
cvs co -r CMSSW_6_1_0 FastSimulation/TrackingRecHitProducer
cvs co -r CMSSW_6_1_0 FastSimulation/Tracking
cvs co -r CMSSW_6_1_0 FastSimulation/Configuration
# my private files
cp /afs/cern.ch/user/g/giamman/public/phase2/TrackingRecHitProducer/SiTrackerGaussianSmearingRecHitConverter_Phase2_cfi.py FastSimulation/TrackingRecHitProducer/python/SiTrackerGaussianSmearingRecHitConverter_Phase2_cfi.py
cp /afs/cern.ch/user/g/giamman/public/phase2/TrackingRecHitProducer/SiTrackerGaussianSmearingRecHitConverter.h FastSimulation/TrackingRecHitProducer/src/SiTrackerGaussianSmearingRecHitConverter.h
cp /afs/cern.ch/user/g/giamman/public/phase2/TrackingRecHitProducer/SiTrackerGaussianSmearingRecHitConverter.cc FastSimulation/TrackingRecHitProducer/src/SiTrackerGaussianSmearingRecHitConverter.cc
cp /afs/cern.ch/user/g/giamman/public/phase2/Tracking/GeneralTracks_Phase2_cfi.py FastSimulation/Tracking/python/FastSimulation/Tracking/python/GeneralTracks_Phase2_cfi.py
cp /afs/cern.ch/user/g/giamman/public/phase2/Tracking/IterativeTracking_Phase2_cff.py FastSimulation/Tracking/python/FastSimulation/Tracking/python/IterativeTracking_Phase2_cff.py
cp /afs/cern.ch/user/g/giamman/public/phase2/Tracking/IterativeInitialStep_Phase2_cff.py FastSimulation/Tracking/python/FastSimulation/Tracking/python/IterativeInitialStep_Phase2_cff.py
cp /afs/cern.ch/user/g/giamman/public/phase2/Tracking/globalCombinedSeeds_cfi.py FastSimulation/Tracking/python/FastSimulation/Tracking/python/globalCombinedSeeds_cfi.py
cp /afs/cern.ch/user/g/giamman/public/phase2/Configuration/FamosSequences_cff.py FastSimulation/Configuration/python/FamosSequences_cff.py
cp /afs/cern.ch/user/g/giamman/public/phase2/Configuration/simulationSwitch_cff.py /FastSimulation/Configuration/python/simulationSwitch_cff.py

Simplified tracking

It was agreed to do these studies with a simplified tracking with no iterations.
I made this only iteration equal to the "iteration 0" of current tracking.

Special cases: electrons and HLT

Currently, gsfElectrons are seeded by some specific iterations of the tracking:

iterativeTrackingBeginning = cms.Sequence(
    iterativeInitialSeeds+
    iterativePixelPairSeeds+
    iterativeMixedTripletStepSeeds+
    iterativePixelLessSeeds
    )

In my code I had to reduce this to just one iteration.

In the case of HLT, the latest (most time-consuming) tracking iterations are not executed. For simplicity, in my private code I made hltTracks equal by construction to generalTracks.

To be understood: should we bypass the fitting? A TrackCandidate object has already values for the 5 track parameters.

Current status: OK

To keep things clean, I created a different cfi for Phase 2 conditions, and added a switch in some places in FamosSequences between "normal" and "phase2".
(Same as for RecHits above.)

The recipe is exactly the same as for RecHits (see previous section).

Validation

Simulation part

This will come when I will have something that runs.

Reconstruction part

I produced 1000 single muon events (pt = 10 GeV), with different configurations.
The comparison is made for the first iterative step, in order to be apples-to-apples.

With the standard RecHit smearing and the standard tracking (but here only the first iteration is plotted):

eff_std_iter0.gif

With no RecHit smearing ("option 1" in the previous section) and the simplified tracking (only first iteration):

eff_phase2_nosmearing.gif

There is a huge drop of efficiency, of which I don't know the cause.

But it is sufficient to add a simplified (geometry-independent) smearing ("option 2" in the previous section; here 0.003 cm in X and 3 cm in Y) to recover efficiency:

eff_phase2_withsmearing.gif

  • closeup of cylinder based and simulation geometry (Phase1):
    phase1_closeup.png

  • createarea2: shell script to create working area with local+track reco
Topic attachments
I Attachment History Action Size Date Who Comment
PNGpng Screen_Shot_2013-06-14_at_Fri_Jun_14_5.28.06_PM.png r1 manage 35.2 K 2013-06-14 - 18:04 LucaMalgeri fastsimulation phase2 (different steps in fixin endcap hits)
PNGpng Screen_Shot_2013-07-03_at_10.53.09_AM.png r1 manage 22.6 K 2013-07-03 - 11:18 LucaMalgeri  
PNGpng Screen_Shot_2013-07-03_at_10.56.25_AM.png r1 manage 23.2 K 2013-07-03 - 11:18 LucaMalgeri  
PNGpng Screen_Shot_2013-07-03_at_11.23.54_AM.png r1 manage 22.4 K 2013-07-03 - 11:25 LucaMalgeri  
PNGpng comp_SLHC7_GCPBLPFL_ph1_eta.png r1 manage 9.0 K 2013-08-02 - 11:58 LucaMalgeri  
PNGpng comp_SLHC7_GCPBLPFL_ph1_pt.png r1 manage 8.7 K 2013-08-02 - 11:59 LucaMalgeri  
PNGpng comp_SLHC7_GCPBLPFL_ph2_eta.png r1 manage 9.0 K 2013-08-02 - 11:59 LucaMalgeri  
PNGpng comp_SLHC7_GCPBLPFL_ph2_pt.png r1 manage 8.7 K 2013-08-02 - 11:59 LucaMalgeri  
PNGpng comp_SLHC7_ph2_cmsdriver_eta.png r1 manage 9.4 K 2013-08-02 - 11:56 LucaMalgeri  
PNGpng comp_SLHC7_ph2_cmsdriver_pt.png r1 manage 8.8 K 2013-08-02 - 11:56 LucaMalgeri  
PNGpng comp_v5_SLHC7_ph1_eta.png r1 manage 9.5 K 2013-08-02 - 11:54 LucaMalgeri  
PNGpng comp_v5_SLHC7_ph1_pt.png r1 manage 8.6 K 2013-08-02 - 11:55 LucaMalgeri  
PNGpng comp_v5_SLHC7_ph2_eta.png r1 manage 9.4 K 2013-08-02 - 11:55 LucaMalgeri  
PNGpng comp_v5_SLHC7_ph2_pt.png r1 manage 8.9 K 2013-08-02 - 11:55 LucaMalgeri  
Unknown file formatext createarea r2 r1 manage 0.7 K 2013-05-28 - 12:16 LucaMalgeri shell script to create area
Unknown file formatext createarea2 r2 r1 manage 0.6 K 2013-05-27 - 14:00 PatriziaAzzi shell script to create working area with local+track reco
Unknown file formatext createarea24 r1 manage 0.7 K 2013-05-27 - 14:58 AndrewLevin shell script to create working area with local+track reco
Unknown file formatext createarea_ph2 r6 r5 r4 r3 r2 manage 1.8 K 2013-07-16 - 14:13 AndrewLevin  
GIFgif eff_phase2_nosmearing.gif r2 r1 manage 5.8 K 2013-01-29 - 14:28 AndreaGiammanco  
GIFgif eff_phase2_withsmearing.gif r1 manage 5.3 K 2013-01-29 - 15:35 AndreaGiammanco  
GIFgif eff_std_iter0.gif r2 r1 manage 5.2 K 2013-01-29 - 14:26 AndreaGiammanco  
PNGpng phase1_closeup.png r1 manage 47.1 K 2013-05-24 - 12:18 LucaMalgeri closeup of cylinder based and simulation geometry (Phase1)
GIFgif radio_standard.gif r2 r1 manage 11.1 K 2013-01-28 - 14:13 AndreaGiammanco  
PDFpdf rechitsval.pdf r1 manage 38.7 K 2013-05-24 - 17:26 PatriziaAzzi Some RecHits validation plots
PNGpng rechitsval.png r1 manage 15.4 K 2013-05-24 - 17:30 PatriziaAzzi Some RecHits validation plots
Edit | Attach | Watch | Print version | History: r38 < r37 < r36 < r35 < r34 | Backlinks | Raw View | WYSIWYG | More topic actions
Topic revision: r38 - 2014-03-04 - AndrewLevin
 
    • Cern Search Icon Cern Search
    • TWiki Search Icon TWiki Search
    • Google Search Icon Google Search

    CMSPublic All webs login

This site is powered by the TWiki collaboration platform Powered by PerlCopyright & 2008-2019 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback