Digitizer for the PhaseII Tracker

Complete: 1

Goal of the page

We describe here the algorithm and the framework of the Digitizer used for the PhaseII Tracker.


The PhaseII tracker consists of Pixel, Pixel-Strip, Strip-Strip modules and four different types of electronics. Although basic physics processes within silicon are the same, due to different readout electronics independent tuning will be required. A framework has been developed to deal with different electronics set ups corresponding to each sensor type.

As described here the basic principle of the Digitizer is same. It reads the collection of hits (SimHit) from the simulated tracks (Geant-4) and convert them to something that looks similar to the experimental raw data (Digis). The Digitizer writes a collection of digitzed signals and a collection of links between Digi and SimHits. Each SimHit contains the entrance and exit points ($P_{in}$, $P_{out}$) and the deposited energy in keV (ΔE). Digitizer uses the deposited energy as well as track length traversed inside the sensitive volume of the detector information from the SimHit considering physics processes and using detector parameters like pitch, signal thresholds, ADC bits, noise, ....

  • The track segment is split into many parts (about 100) each with charge $q_i$ which is fluctuated according to the G4 dEdx fluctuation formula.
  • Charge is generated and transported using
    • Primary Ionization [dealt by primary_ionization() in the algorithm part of the code]
    • Drift [dealt by drift() in the algorithm part of the code]
    • Signal generation to nearby strips [dealt by induce_signal() in the algorithm part of the code]
  • Each point charge is drifted to the detector surface under the influence of the B-field ($2^{nd}$ order Lorentz force used).
  • The point charge is diffused with a Gaussian smearing.
  • All charges within a single detector cell (pixel or strip) limit are collected to give the cell charge $Q_n$.
  • Noise is added. There are two types of noise: detector noise & readout noise. The $1^{st}$ one determines which pixel is above threshold and is read out. The $2^{nd}$ one determines the noise contributions to the signal at the ADC input.
  • A threshold is applied and the charge is converted to ADC counts (integer). * threshold is smeared with a Gaussian, given the sigma
  • Inefficiencies and miss-calibration are applied.

The framework and the Implementation

The framework is described by a diagram below. There is a digitizer module Phase2TrackerDigitizer which uses the digitizer algorithm where the processes described above are activated. In the current framework there is an abstract base class Phase2TrackerDigitizerAlgorithm and four concrete implementation for each sensor type (with independent readout electronics)


The concrete classes are

  • PixelDigitizerAlgorithm : for Inner Pixel
  • PSPDigitizerAlgorithm : for pixel in the PS module (MPA chip)
  • PSSDigitizerAlgorithm : for strip in the PS module (SSA chip)
  • SSDigitizerAlgorithm : for 2S modules (CBS chip)

A few technical Details

  • In Phase2TrackerDigitizer class, two maps have been defined
    • map between DetId with corresponding StackedTrackerDetId : created in the beginRun
    • map between the algorithm type (a string) and the pointer of the specific algorithm object stored as abstract mother object: created inside the constructor
  • for a specific detector with a given DetId, the corresponding StackedTrackerDetId is retrieved from the first map to know the detector type using std::string getAlgoType(unsigned int detId method and corresponding algorithm specific object is accessed from the algorithm map.

Usage of the algorithm


The software can be found in the package SimTrack/SiPhase2Digitizer package and starting from CMSSW_6_2_0_SLHC20 onwards it is fully integrated in the official releaes

How to run

  • cmsrel CMSSW_10_1_7
  • cd CMSSW_10_1_7/src
  • cmsenv
  • runTheMatrix.py --what upgrade -l 20010.0

Info where 20010.0 in the runTheMatrix corresponds to FourMuExtendedPt_1_200 and the full chain (GEN/SIM,DIGI,RECO,Harvesting) steps are executed. One can use the option --dryRun to get the cmsDriver commands at each step.

Warning, important Note : One can use any CMSSW version in 9X, 10X series as the code is fully integrated into the release. The DQM histograms produced here do not include the validation plots corresponding to Phase2 digitizer. One needs to ru the validation step separately.


At step2 two separate digi collections are produced for inner pixel and outer detectors. These collections can be accessed from the edm output file by the input tags like
  • cms.InputTag("simSiPixelDigis", "Pixel")
  • cms.InputTag("simSiPixelDigis", "Tracker")

Validation Tool

There are two EDAnalyzer modules to test the digi properties. This modules produce DQM histograms which are organised in a folder structure based of the detector layers and discs.

  • SimTracker/SiPhase2Digitizer/test/Phase2TrackerMonitorDigi.cc : digi properties are plotted from the reconstruction level and can be used for data as well as simulated events
  • SimTracker/SiPhase2Digitizer/test/Phase2TrackerValidateDigi.cc : simulation information associated with the reconstructed digi are plotted and can ONLY be used for simulated events

The configuration file DigiTest_cfg.py can be found in the same area to run above two DQM modules.

Info Note : One needs to checkout the package (git checkout SimTracker/SiPhase2Digitizer) to be able to access this tool and corresponding configuration files in the test folder. The configuration file should be updated with correct PoolSource containing the Digi collection to create validation plots.

Parameters for the Digitizer

The parameters are defined in the new configuration file SimTracker/SiPhase2Digitizer/python/phase2TrackerDigitizer_cfi.py

Name Default Value Comment
accumulatorType "Phase2TrackerDigitizer"  
hitsProducer 'g4SimHits'  
ROUList 'TrackerHitsPixelBarrelLowTof', 'TrackerHitsPixelBarrelHighTof', 'TrackerHitsPixelEndcapLowTof', 'TrackerHitsPixelEndcapHighTof'  
GeometryType 'idealForDigi'  

Parameters common to all algorithms
Common parameters for individual algorithms are provided in a PSet called AlgorithmCommon
Name Default Value Comment
DeltaProductionCut 0.03  
ElectronPerAdc 135.0  
AdcFullScale 255  

Parameters for each Algorithm
Parameters specific to each algorithm are provided in a given PSet. There are four such parameter sets (PSPDigitizerAlgorithm, PSSDigitizerAlgorithm, PSSDigitizerAlgorithm, SSDigitizerAlgorithm) for four different types. At the moment the most optimised set is the one for SSDigitizerAlgorithm and for others same values are used as default. In future we shall update them following feedback from laboratory measurement as well as beam tests.

Name Comment SSAlgorithm(CBC) PSPAlgorithm(MPA) PSSAlgorithm(SSA) PixelAlgorithm
makeDigiSimLinks   True True True True
AddNoise   True True True True
ReadoutNoiseInElec function of strip capacitance, roughly: ReadoutNoiseInElec=500+(64*Cdet[pF]) ~= 500+(64*1.5[cm]), added on signal strips 350.0 1000.0 1000.0 1000.0
ThresholdInElectrons_Barrel 0.4MIP ~ 0.4*16000e [For OT] 1000. 6300.0 6300. 6300.
ThresholdInElectrons_Endcap 0.4MIP ~ 0.4*16000e [For OT] 1000. 6300.0 6300. 6300.
HIPThresholdInElectrons_Barrel 1.4 MIP considered as HIP [for PS] 1.0e10 21000.0 1.0e10 1.0e10
HIPThresholdInElectrons_Endcap 1.4 MIP considered as HIP [for PS] 1.0e10 21000.0 1.0e10 1.0e10
AddThresholdSmearing   True True True True
ThresholdSmearing_Barrel 10% of the Threshold 100. 630. 630.0 630.
ThresholdSmearing_Endcap   100. 630. 630.0 630.
AddNoisyPixels   True True True True
NoiseInElectrons 30% of the readout noise used to create NoisyPixels 175.0 300 300 300
DigitalReadout Flag to decide analog or digital readout True True True True
TofUpperCut   12.5 12.5 12.5 12.5
TofLowerCut   -12.5 -12.5 -12.5 -12.5
AddXTalk   True True True True
InterstripCoupling 5% coupling to nearest neighbour 0.05 0.05 0.05 0.05
SigmaZero 3.7um spread for 300um-thick sensor, renormalized in digitizerAlgo 0.0037 0.0037 0.0037 0.0037
SigmaCoeff   1.80 1.80 1.80 1.80
ClusterWidth used as number of sigmas for charge collection (+-3sigmas) 3 3 3 3
LorentzAngle_DB   False False False False
TanLorentzAnglePerTesla_Endcap   0.106 0.106 0.106 0.106
TanLorentzAnglePerTesla_Barrel   0.106 0.106 0.106 0.106
Alpha2Order   True True True True
KillModules   False False False False
DeadModules_DB   False False False False
DeadModules List of Dead modules (if any) in a VPset -- -- -- --
AddInefficiency   False False False False
Inefficiency_DB   False False False False
EfficiencyFactors_Barrel Values can be added as cms.vdouble for each layer 0.999 0.999 0.999 0.999
EfficiencyFactors_Endcap Efficiencies kept as Side2-Disk1, Side1-Disk1 and so on 0.999 0.999 0.999 0.999

Comments from Duccio

Sensor specification

  • the polarity is n-in-p and we assume for the time being a thickness of 200 microns
  • an operating voltage of -600V (with possibility to go to -800).
  • The sensor WG should be able to provide the information on the Lorentz angle that those parameters correspond to. I all applies to the 2S module as well as both sensors of the PS module
  • Addition from Andreas Nuernberg
    • tan(Lorentz angle) per Tesla values for 200 Micron sensors are
      • -300V, non-irradiated: 0.07
      • -600V, non-irradiated: 0.04 Tip, idea Need to update the configuration file
      • -600V, irradiated (1.5e15 neq/cm**2): 0.03
      • -800V, irradiated (1.5e15 neq/cm**2): 0.025
  • For the channel noise, we have predictions from the simulations of the CBC and the MPA, and also real measurements with the CBCs. For the SSA, I guess we could provisionally use the CBC and scale for the channel capacitance?
    • Work in progress, under construction We are using 1000 for CBC and same for others. The value should be re-confirmed for CBC and correct ones should be used for other three cases

Specifically for the digitizer

Then there are more subtle effects, concerning the correlations between neighboring channels. To my understanding the possible effects are:
  1. A positive correlation between signals in neighboring channels (in other words, whenever there is a signal in one channel, a fraction of it gets transferred onto the neighbors). This is a property of the chip. I think we have estimates for the CBC and the MPA. For the SSA we could provisionally invent a number somewhere in between.
    • Work in progress, under construction We are using 1000 for CBC and same for others. The value should be re-confirmed for CBC and correct ones should be used for other three cases
  2. A negative correlation between the noise in neighboring channels, which is due to the presence of the sensor. This was seen in the modules of the present tracker (see https://indico.cern.ch/event/22540/session/1/material/slides/1?contribId=1), and there are now already hints that something similar still applies to the new modules. [BTW: I think this is not even taken into account in the simulation of the present tracker!]. It should be one parameter for each sensor type - or two if we want to model also the correlation to the second neighbor. In the new strip sensors we have also neighboring channels in the z direction… but maybe there is no effect there? Also, I think we have no idea if the effect is present at all in the pixellated sensors. All this business requires further study, I am not sure if we want to simulate it already at this stage, but probably we will have to do it at some point.
    • Tip, idea Need to update the code to include this effect
  3. An overall common mode noise. This ideally should be negligibly small, in reality we don't know. It's probably useful to have a parameter through which we can introduce common mode in the simulation.
    • Tip, idea Need to update the code to include this effect


Detector Note

There is a Detector Note CMS DN-2016/024 on the Phase2 Tracker Digitizer

Responsible: SuchandraDutta, SubirSarkar, SuvankarRoyChowdhury

Topic attachments
I Attachment History Action Size Date Who Comment
PNGpng digitizer_FW.png r1 manage 31.8 K 2014-08-21 - 17:01 SuchandraDutta Phase2 Digitizer framework
PNGpng digitizer_scheme.png r1 manage 35.3 K 2014-08-22 - 14:02 SubirSarkar Phase2 Digitizer framework
Edit | Attach | Watch | Print version | History: r32 < r31 < r30 < r29 < r28 | Backlinks | Raw View | WYSIWYG | More topic actions
Topic revision: r32 - 2018-07-12 - SuchandraDutta
    • 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