Pointing hand Link to the DPG Tracker Simulation twiki


The Pixel digitizer reads the collection of SimHit and writes a collection of Pixel Digi and a collection of links between digi and simhits. The source code of the PixelDigitizer is available at SimTracker/SiPixelDigitizer.

From Geant-4 simulations we get for each track so called SimHits: the entrance and exit points ($P_{in}$, $P_{out}$) and the deposited energy in keV (ΔE). Only the pixel detector geometry is needed to obtain this. To convert SimHits to something that looks similar to the experimental raw data (Digis) we need the digitizer. The pixel digitizer knows the pixel pitch, signal thresholds, ADC bits, noise, ....

SimHits.png Track_split.png

  • 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.
  • 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 pixel limit are collected to give the pixel 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).
  • Inefficiencies and miss-calibration are applied.

Steps in the pixel digitizer

(from Danek, November 28, 2009)


  • Smear pixel thresholds with a Gaussian, given the sigma. Separate for bpix and fpix.
  • Generate pixel charge using: primary_ionization(), drift() and induce_signal(). Pixel signal is in electrons.
  • Delete pixels in dead modules. Use either the config files or the DB (The list of official dead pixel modules accessible via the Database can be found here). Presently the list from the config files is used.
  • Apply the smearing of the signal due to the VCAL variation. The smearing is a Gaussian where the sigma depends on the pixel charge.
  • Add noise to the hit pixels and add new "noisy" pixels.
  • Delete random hit pixels to simulate the effect of dynamical efficiency losses. Important only at higher luminosities.
  • Delete hits in known "dead" pixels. It is not used for the moment. It uses the SiPixelGainCalibrationOfflineSimService() object to call ->isDead().


  • Check threshold, keep only pixels above the threshold. Separate for bpix and fpix.
  • Apply the signal response. Convert electrons to VcalLow and than use the TANH function to obtain ADC values. The same parameter are used for all pixels (no pixel2pixel variation). Separate for bpix and fpix.
  • Saturate the ADC count at the maximum value (255).
  • Construct the sim-links for the MC association.

Signal response in the simulation

A more realistic parameterization of the signal response has been implemented. The analog response is simulated (with distinction between Fpix and Bpix) as:

p3 + p2 * tanh(p0*signal - p1) with signal(in VCAL units)= (signalInElectrons - electronsPerVCAL_Offset) / electronsPerVCAL

where signalInElectrons is the signal in electrons for a hit pixel, electronsPerVCAL = 65.5 and electronsPerVCAL_Offset = -414.

The two sets of parameters (from Danek's results) to be used for the new parameterization are shown in the following table. These are average of all ROCs. There are variations of course but we decided a while ago to ignore them.

Bpix_analog_signal = 126.5 + 97.4 * tanh(0.0035*signal - 1.23)   Fpix_analog_signal = 134.6 + 93.6 * tanh(0.0043*signal - 1.31)
bpix_vs_elec_lin.gif   fpix_vs_elec_lin.gif

We also update the gain calibrations in MC as well. We update the DB payload with the following input numbers: bpix_gain= 3.501, bpix_ped=25.520, bpix_rmsgain=0.513, bpix_rmsped=8.149 and fpix_gain=2.915, fpix_ped=28.030, fpix_rmsgain=0.475, fpix_rmsped=9.534. We don't need to update the clusterizer to read the separate numbers for bpix and fpix because the differentiation is already in the payload. The clusterizer just reads it from the DB.

Result of the new parameterization in the pixel digitizer: V02-17-08 (Nov. 20th 2009)

Pixel thresholds in electrons

The official 2009 pixel threshold in electrons (obtained from Cosmic data) are:
  • ThresholdInElectrons_FPix is 2483e (RMS 163e)
  • ThresholdInElectrons_BPix is 2733e (RMS 196e)
  • All is 2666 (RMS 218)

Contributions that smear the pixel charge

  • The readout noise from the electronics is a "permanent" contribution. (The upper limit would be 500e)
  • The VCAL contribution is a "permanent" contribution. Even if we find a way to correct each ROC the pixel2pixel contribution is still there. Following the study made by D. Kotlinski on the VCAL calibration, we implemented a smearing of the pixel charge using an RMS value (obtained from that study) which is a function of the pixel charge value as shown in the plot below:
The pixel charge smearing is defined in 3 regions: 
charge < 3000           RMS = 543.6  0.093*charge
3000 < charge < 6000    RMS = 307.6  0.01*charge
charge > 6000           RMS= -432.4 + 0.123*charge

Time of flight of simhits

The ToF of simhits was measured in a cosmic sample (look at the pixel simhit TOF in a SimHits root file). They peak around 31nsec. For the cosmics we use 31 $\pm$ 12.5 nsec window. For collisions the TOF peak is at zero so the window is $\pm$ 12.5.
  • Cosmics: process.simSiPixelDigis.TofLowerCut = 18.5 and process.simSiPixelDigis.TofUpperCut = 43.5
  • Collisions: process.simSiPixelDigis.TofLowerCut = -12.5 and process.simSiPixelDigis.TofUpperCut = 12.5

Pixel inefficiency (mostly due to Luminosity)

The pixel inefficiency is defined below. Basically we can consider that the efficiency is 100%. Or we can include only the static inefficiency: static means that no readout related luminosity dependent losses are considered. But, we can include the readout losses for low-luminosity (2 10^33) or high luminosity (10^34). All this is needed because the MC productions will be done most likely not for the so called "low" luminosity (2 10^33) but for some very low lumi where there will be no readout losses, however some "static" losses comming from bad pixels, bad bump-bonds etc. will be present.

The three inefficiency are: PixelEfficiency (pixels), PixelColEfficiency (columns) and PixelChipEfficiency (readout chips): | thePixelEfficiency[i] | thePixelColEfficiency[i] | thePixelChipEfficiency[i] | where the first 3 settings [0], [1], [2] are for the pixel barrel layer 1, 2, 3 and the next 3 settings [3], [4], [5] are for the endcaps. Different scenarios have been implemented:

  • If AddPixelInefficiency = -1: All is 100% efficient.
for (int i=0; i<6;i++) {
      thePixelEfficiency[i]     = 1.;  // pixels = 100%
      thePixelColEfficiency[i]  = 1.;  // columns = 100%
      thePixelChipEfficiency[i] = 1.; // chips = 100%
  • If AddPixelInefficiency = 0: We include only the static (non rate depedent) inefficiency. This is useful for very low rates (luminosity). For both barrel and endcaps, we will assume the following settings:
for (int i=0; i<6;i++) {
      thePixelEfficiency[i]     = 1.-0.001;  // pixels = 99.9% (Assume 1% inefficiency that is given by faulty bump-bonding and seus.)
      thePixelColEfficiency[i]  = 1.-0.001;  // columns = 99.9% (Make 0.1% default)
      thePixelChipEfficiency[i] = 1.-0.001; // chips = 99.9% (A flat 0.1% inefficiency due to lost ROCs)
  • If AddPixelInefficiency > 0: We include also luminosity rate dependent inefficiency. For both barrel and endcaps, we will assume the following settings:
for (int i=0; i<6;i++) {
      thePixelEfficiency[i]     = 1.-0.01;  // pixels = 99% (Assume 1% inefficiency that is given by faulty bump-bonding and seus.)
      thePixelColEfficiency[i]  = 1.-0.01;  // columns = 99% (Make 0.1% default)
      thePixelChipEfficiency[i] = 1.-0.0025; // chips = 99.75% (A flat 0.25% inefficiency due to lost data packets from TBM)
  • If AddPixelInefficiency = 10: Special cases ( High-lumi for 4cm layer ) where the readout losses are higher. This case is for high luminosity and affects the Barrel layer1.
      thePixelColEfficiency[0] = 1.-0.034; // (Make 3.4% inefficiency for pixel barrel layer 1)
      thePixelEfficiency[0]    = 1.-0.015; // (Make 1.5% inefficiency for pixel barrel layer 1)

Pixel dead modules

Default pixel digitizer parameters and configuration

Parameter Default value CommentSorted ascending
ElectronPerAdc 135 ADC calibration
AdcFullScale 255 ADC saturation value is 255 = 8bit adc
AddNoise True Add noise to the pixel signal
AddNoisyPixels True Add pixels generated by noise
AddThresholdSmearing True Add threshold gaussian smearing
ElectronsPerVcal 65.5 Calibration electrons/adc: electrons to VCAL conversion needed in misscalibrate()
AddPixelInefficiency 0 Controls the pixel inefficiency
ThresholdInElectrons_FPix 2483 CRAFT09 result
ThresholdInElectrons_BPix 2733 CRAFT09 result
ThresholdSmearing_FPix 160 CRAFT09 result
ThresholdSmearing_BPix 200 CRAFT09 result
DeltaProductionCut 0.03 GeV Delta ray cutoff in MeV, has to be same as in OSCAR. Max = 0.030 MeV.
ElectronsPerVcal_Offset -414 electrons to VCAL conversion Offset needed in misscalibrate()
MissCalibrate True Enable miss-calibration (pixel gain)
GainSmearing 0 Get the constant for the miss-calibration studies: Sigma of the gain smearing.
OffsetSmearing 0 Get the constant for the miss-calibration studies: Sigma of the offset smearing.
TanLorentzAnglePerTesla_FPix 0.106 Lorentz angle per unit B field
TanLorentzAnglePerTesla_BPix 0.106 Lorentz angle per unit B field
Alpha2Order True  
GeometryType 'idealForDigi'  
useDB True  
LorentzAngle_DB True  
DeadModules_DB True  
killModules True  
DeadModules VPSet()  
NoiseInElectrons 175 Pixel cell noise in electrons, relevant for generating noisy pixels
ReadoutNoiseInElec 350 Readout noise from the electronics in front of the ADC, including all readout chain, relevant for smearing
ChargeVCALSmearing True Smear the pixel charge with a gaussian which RMS is a function of the pixel charge (Danek's study)
TofUpperCut 12.5 Time of flight cut in nanoseconds
TofLowerCut -12.5 Time of flight cut in nanoseconds

Still hard-coded: Fluctuate generated charge along track subsegments: fluctuateCharge=conf_.getUntrackedParameter("FluctuateCharge",true); (SimTracker/SiPixelDigitizer/src/SiPixelDigitizerAlgorithm.cc)

More details are given in the CMSSW reference manual for the SiPixelDigitizer package.

How to run the pixel digitizer

You will need a file of SimHits. Usually you can choose a file containing SimHits on DBS, e.g /store/relval/CMSSW_3_3_3/RelValSingleMuPt10/GEN-SIM-RECO. In
there is a python script named testPixelDigitizer.py. This scripts has been implemented ( tested with CMSSW_3_3_3) with several process that you can run depending on what you want. You can choose among the following process:
Run the digitizer
process.p1 = cms.Path(process.mix*process.simSiPixelDigis)
Run the digis validation
process.p1 = cms.Path(process.mix*process.simSiPixelDigis*process.pixelDigisValid)
Look at cluster charge
process.p1 = cms.Path(process.mix*process.digis*process.siPixelRawData*process.siPixelDigis*process.pixeltrackerlocalreco)
Make DQM occupancy maps
process.p1 = cms.Path(process.mix*process.simSiPixelDigis*process.siPixelRawData*process.siPixelDigis)
followed by
cmsRun DQM_Pixel_digi.py
Look at residuals and pulls
process.p1 = cms.Path(process.mix*process.digis*process.siPixelRawData*process.siPixelDigis*process.rechits*process.tracks

with the following path for process.simhits, process.digis, process.rechits, process.tracks and process.trackinghits:

Simulation of hits in the tracker
process.simhits = cms.Sequence(process.g4SimHits*process.trackerHitsValidation)
Pixel digitization
process.digis = cms.Sequence(process.simSiPixelDigis*process.pixelDigisValid)
Pixel reconstruction-clusterisation
process.rechits = cms.Sequence(process.pixeltrackerlocalreco*process.siStripMatchedRecHits*process.pixRecHitsValid)
Tracker reconstructed hits
process.tracks = cms.Sequence(process.offlineBeamSpot*process.recopixelvertexing*process.trackingParticles
process.trackinghits = cms.Sequence(process.TrackRefitter*process.trackingRecHitsValid)

Validation plots

Configuration parameters: results (by M. Pioppi - Feb. 2006)

Created on 21-Oct-2009 by VesnaCuplov, Merged all informations from the old pixeldigitizer twiki page on 05-Dec-2009.

Topic attachments
I Attachment History Action Size Date Who Comment
PDFpdf MCIssues_35x.pdf r9 r8 r7 r6 r5 manage 3155.6 K 2010-03-02 - 07:30 UnknownUser  

This topic: CMSPublic > CMSCommunicationsGroup > CMSCommunicationsProjects > WebHome > SWGuide > SWGuideSimulation > SWGuideTrackerDigitization > SWGuidePixelDigitization
Topic revision: r20 - 2010-03-29 - unknown
This site is powered by the TWiki collaboration platform Powered by PerlCopyright & 2008-2020 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
or Ideas, requests, problems regarding TWiki? use Discourse or Send feedback