Fast simulation of tracker material


NOTE: Legend of colors for this tutorial:

PINK background for the CMSSW and Unix commands to execute  (cut&paste)
GRAY background for the description of configuration files (by construction in python)
BLUE background for code description (either in python or in C++)
GREEN background for highlighted text

Introduction

The Fast Simulation of the CMS detector (henceforth FastSim) is an object-oriented system, written in C++ and steered by python configuration files, within the CMS software framework ( CMSSW). FastSim is complementary to the Geant4-based approach (customarily known as FullSim, the later including the electronic effects simulated by the relevant CMSSW modules), with respect to which it is regularly validated and tuned.

In the present attempt, we examine the content of the FamosSimHits.cfi configuration file, included as

process.load('FastSimulation.Configuration.FamosSequences_cff')

and what is left as a handle for the user is to switch on and off a number of effects, or even better, for the developer, for tuning and comparison with the GEANT-based simulation. Notice that not all the particles are actually processed through the FastSim (in the same way as not all the particles are processed through the FullSim ), meaning that not all the particles are saved in the SimTrack container so as to save disk space. The kinematics of the particles to be processed through FastSim are defined here.

More specifically, the FamosSimHit production is equivalent to the FullSim production, in the sense that it produces the same objects (a factor of 1000 quicker though), i.e. the

  • SimTrack collection: the simulated particles after the propagation and the interactions of all generated particles through/with the tracker material, all the way to the electromagnetic calorimeter entrance
  • SimVertex collection: the vertices out of which all aforementioned simulated particles had been generated
  • PSimHit collection: the position, energy loss and other information for all simulated hits in the silicon pixel and strip layers of the tracker
  • PCaloHit collection: the energy left in the calorimeters, i.e. both in the electromagentic ECAL (Barrel (EB), Endcap (EC) and Preshower (ES)) and the hadronic calorimeter HCAL (Barrel (HB and HO), Endcap (HE) and Forward (HF)).

Quasi-stable particles, together with their mothers and the corresponding origin vertices, are saved in the SimTrack and SimVertex container. It should be also noted that the production of hits and segments in muon sub-systems (Cathode Strip chambers (CS), Drift Tubes (DT) and Resistive Plate chambers (RP)) is separately stored, while it is possible to arrange the production of the SimTrack collection for muons.

After the stable or quasi-stable generated particles are selected, they are propagated in turn through the magnetic field all the way to the calorimeters. The propagation is consecutively done in steps, each step corresponding to a layer (sensitive or not) of the tracker.

Geometry of tracker material

The Tracker Interaction Geometry, included as

process.load('FastSimulation.Configuration.Geometries_START_cff')

is made of a list of infinitely thin nested cylinders aimed at reproducing the tracker material distribution as a function of r and z, assuming a complete φ symmetry. While the position (radius and length) of the sensitive layers are taken from the official geometries, aka Tracker Reconstruction Geometry,

from FastSimulation.Configuration.TrackerRecoGeomertryESProducer_cfi import *

their thickness and the characteristics of dead layers are configured by including

from FastSimulation.TrackerSetup.TrackerInteractionGeometryESProducer_cfi import * 

A simplified version of the tracker geometry is thus used, made of over 30 thin nested cylinders representing the sensitive layers of, as moving away from the LHC interaction point,

  • the silicon pixel detector, i.e. 3 barrel (PXB) layers and 2 endcap (PXF) disks and,

  • the silicon strip detector, i.e. 4 inner barrel layers (TIB), 3 tracker inner disks (TID), 6 tracker outer barrel layers (TOB) and the 9 tracker endcap disks (TEC),
interleaved with non-instrumented cylinders with dead material (cables, support, etc.). The material is assumed to be pure silicon, while the thickness of each layer is tuned to reproduce the amount of material viewed by particles when they traverse it and in particular the amount of Bremsstrahlung for electrons.

In conclusion,

While the interactions with the tracker material are simulated in this specific (nested-cylinder-based), yet simplified, 
tracker geometry, the products of the !FamosSimHit collection are placed instead in the real, official, tracker geometry. In other words, 
a particle is first propagated to one of the nested cylinders, in which it interacts, as described in the following sections. 
The coordinates (radii and lengths) of the sensitive interaction-geometry nested cylinders *are determined* from 
the Tracker Reconstruction Geometry, but their thicknesses are *hard coded*. In addition, the coordinates of dead-material 
cylinders are *hard coded* and must be compatible with, i.e. nested within, the sensitive cylinders.

Material effects

The interactions between particles and tracker material is modeled inside the class MaterialEffects. link to code link to configuration code

The main function of this class is

void MaterialEffects::interact(FSimEvent& mySimEvent, 
   const TrackerLayer& layer,
   ParticlePropagator& myTrack,
   unsigned itrack,
   RandomEngineAndDistribution const* random)

This function models the interactions between a particle with index itrack in mySimEvent and the tracker layer layer. The object myTrack represents the current state of the particle and is altered by the function according to the interactions. If, during the interactions, new particles are created, the proper new vertices and particles are added to mySimEvent.

The available interactions are

  • Energy loss (ionisation)
  • Pair production
  • Brehm strahlung
  • Multiple scattering (coulomb scattering)
  • Nuclear interactions
  • Muon brehm strahlung

These interactions can be configured and switched on and off on demand. A more detailed description for each of those interactions is provided below.

Energy loss

Description

process.famosSimHits.MaterialEffects.EnergyLoss = True 

Ionisation of molecules by charged particles is modeled by the class EnergyLossSimulator

The ionisation is modeled in the following function

void EnergyLossSimulator::compute(ParticlePropagator &Particle, RandomEngineAndDistribution const* random)

  • The object Particle represents the current state of the particle and is altered by the function according to the interactions.
  • The model for the energy loss is based on the PDG documentation. A more concrete description can be found here.
  • Energy loss through ionsiation is the one and only material effect that determines the energy of tracker PSimHits.
    • MaterialEffects::theEnergyLoss is calculated only taking into account ionisation. See link to code
    • MaterialEffects::theEnergyLoss is used in TrajectoryManager::createPSimHits to determine the energy loss variables of tracker PSimHits (returned by PSimHit::energyLoss()). see link to code and link to code
  • For particles below 10 MeV, energy loss is not calculated and Particle is left unchanged. See link to code. This leads to a small number of tracker PSimHits having zero energy loss (returned by PSimHit::energyLoss()).

Validation

The energy loss experienced by charged particles is being validated by the EnergyLossValidation class, which derives from the DQMEDAnalyzer class. The aim is to have a prompt overview of the behavior of the specific energy loss dE/dx as a function of particle momentum/energy and type. To that end the EnergyLossValidation class does routinely produce a series of 1D and 2D dE/dx distributions over three different sub-types of the CMS tracker,

  • Pixels (a merge of PXB and PXF)
  • StripsNoTEC5to7 (a merge of TIB, TID, TOB and TEC, excluding layers 5 to 7)
  • StripsOnlyTEC5to7 (a merge of TEC layers 5 to 7)
A detailed, i.e. from to A to Z, description of the validation class is given below.

The EnergyLossValidation class has been configured in order to process separately FastSim,


EnergyLossValidation = cms.EDAnalyzer( 'EnergyLossValidation',
SimHitTags = cms.VInputTag(
cms.InputTag("famosSimHits", "TrackerHits")
)

and FullSim events,


EnergyLossValidation = cms.EDAnalyzer( 'EnergyLossValidation',
SimHitTags = cms.VInputTag(
cms.InputTag("g4SimHits", "TrackerHitsPixelBarrelLowTof"),
cms.InputTag("g4SimHits", "TrackerHitsPixelBarrelHighTof"),
cms.InputTag("g4SimHits", "TrackerHitsPixelEndcapLowTof"),
cms.InputTag("g4SimHits", "TrackerHitsPixelEndcaplHighTof"),
cms.InputTag("g4SimHits", "TrackerHitsPixelTECLowTof"),
cms.InputTag("g4SimHits", "TrackerHitsPixelTECHighTof"),
cms.InputTag("g4SimHits", "TrackerHitsPixelTIBLowTof"),
cms.InputTag("g4SimHits", "TrackerHitsPixelTIBHighTof"),
cms.InputTag("g4SimHits", "TrackerHitsPixelTIDLowTof"),
cms.InputTag("g4SimHits", "TrackerHitsPixelTIDHighTof"),
cms.InputTag("g4SimHits", "TrackerHitsPixelTOBLowTof"),
cms.InputTag("g4SimHits", "TrackerHitsPixelTOBHighTof") )

It is possible only a list of particles to be analyzed with the particleSelection parameter set,

particleSelection = cms.PSet( 
particleTypes = cms.untracked.vint32(211),
selectAntiParticle = cms.utracked.bool(True)
)

For this example above, both positive and negative pions ( PDG Code +211 and -211 respectively) are going to be processed. Please notice the sign sensitivity; should the anti-particle be also considered, please simply set the selectAntiParticle parameter to True. The particle selection is disabled by simply leaving the particleTypes parameter empty.

In addition, one can define the phase-space over which the selection is restricted,

particleFilter = cms.PSet(
etaMin = cms.utracked.double(-2.5),
etaMax = cms.utracked.double(2.5),
pTMin = cms.utracked.double(0.05),
pTMax = cms.utracked.double.(100),
pMin = cms.utracked.double(0.),
pMax = cms.utracked.double(0.),
EMin = cms.utracked.double(0.),
EMax = cms.utracked.double(0.),
pdgIdsToFilter = cms.untracked.vint32(2211),
filterAntiParticle = cms.utracked.bool(True)
)

For this example above, the selection is performed over the full tracker acceptance, i.e. |η|<2.5, while all selected particles will be found of at least 50 MeV /c and up to 100 GeV /c in transverse momentum (pT). Kinematic requirements are raised by setting both Min and Max parameters to 0. This means that for the specific case above, momentum (p) and energy (E) cuts are disabled. Inversely, a narrow window around a kinematical variable is possible by setting both Min and Max parameters to the same non zero value. Last, in case that a minimum-bias sample is to be analyzed, it is possible to filter a list of particles. Once more, please notice the sign sensitivity; should the anti-particle be also filtered, please simply set the filterAntiParticle parameter to True.

In the current form, the EnergyLossValidation class can handle two different types of bin edges; the first is concerned with momentum binning,

bins_p = cms.untracked.vdouble(0.4, 1.2, 1.5, 1.9, 2.1)

or with energy binning,
bins_E = cms.untracked.vdouble(0.4, 1.2, 1.5, 1.9, 2.1)

It should be noted that the binning examples above are only indicative and one is able to make use of their own proper 
binning preference, matching with their studies. More specically, in the example above, and assuming that momentum
bins have been opted for, particles in the (0.4, 1.2),(1.2, 1.5), (1.5, 1.9) and (1.9, 2.1) GeV /c ranges are plotted. Morover, 
it is not necessary for the numbers to be typed in ascending order, which protects against accidental mystyping. Last, 
in case that both parameters are present, the EnergyLossValidation class will only pick up the momentum bins by default.
Finally, formating the 1D and 2D histograms that the EnergyLossValidation class routinely produces is achieved with
 
histo1DFormating = cms.VPSet(
cms.PSet(
title = cms.utracked.string('histo1D_title_1'),
name = cms.utracked.string('histo1D_name_1'),
labelx = cms.utracked.string('dEdX'),
labely = cms.utracked.string(''),
rangex = cms.untracked.vdouble(200, 0., 1e-2)
)
and 
histo2DFormating = cms.VPSet(
cms.PSet(
title = cms.utracked.string('histo2D_title_1'),
name = cms.utracked.string('histo2D_title_1'),
labelx = cms.utracked.string('p'),
labely = cms.utracked.string('dEdX'),
rangex = cms.untracked.vdouble(60, 0., 100),
rangey = cms.untracked.vdouble(200, 0., 1e-2) )
 
 
respectively. 
Again, it should be noted that the histogram formating examples above are only indicative. Interestingly, 
one has a direct and straightforward handle over the reserved histograms. For instance, by adding to 
the histo1DFormating vector of parameters a second parameret set,

histo1DFormating = cms.VPSet(
cms.PSet(
title = cms.utracked.string('histo1D_title_1'),
name = cms.utracked.string('histo1D_name_1'),
labelx = cms.utracked.string('dEdX'),
labely = cms.utracked.string(''),
rangex = cms.untracked.vdouble(200, 0., 1e-2)
),
cms.PSet(
title = cms.utracked.string('histo1D_title_2'),
name = cms.utracked.string('histo1D_tiltle_2'),
labelx = cms.utracked.string('dEdX'),
labely = cms.utracked.string(''),
rangex = cms.untracked.vdouble(100, 0., 1e-2) )
 

will result in formatting the 1D histograms meant for the two first momentum edges, i.e. (0.4, 1.2) and (1.2, 1.5) GeV/c. 
At that point, it should be clarified that each parameter set in the 1D histogram formating indiscriminately 
corresponds to all three tracker sub-types, meaning that up to 4 parameter sets could be added 
for our fictitious (0.4, 1.2), (1.2, 1.5), (1.5, 1.9) and (1.9, 2.1) GeV/c example above. In the opposite case, 
a warning will be issued. Related to this, if the rangex vector parameter sets were not be initialized with three
elements, a warning would be released and the default binning for the respective set of 1D histograms 
would be selected.
Concerning the 2D histogram formating, the situation is quite similar, namely by adding to the histo2DFormating 
vector of parameters a second parameter set, i.e.   
 
histo2DFormating = cms.VPSet(
cms.PSet(
title = cms.utracked.string('histo2D_title_1'),
name = cms.utracked.string('histo2D_name_1'),
labelx = cms.utracked.string('p'),
labely = cms.utracked.string('dEdX'),
rangex = cms.untracked.vdouble(60, 0., 100),
rangey = cms.utracked.vdouble(200, 0., 1e-2)
),
cms.PSet(
title = cms.utracked.string('histo2D_title_2'),
name = cms.utracked.string('histo2D_tiltle_2'),
labelx = cms.utracked.string('dEdX'),
labely = cms.utracked.string(''),
rangex = cms.untracked.vdouble(50, 0., 120),
rangey = cms.untracked.vdouble(220, 0., 1e-2)
)
 

will result in formatting the 2D histograms meant for Pixels and StripsNoTEC5to7. This means that up to 3 parameter 
sets could be added for the 2D histogram formatting, each for the 3 different tracker sub-types. In the opposite case, 
a warning will be issued. Once more, if either the rangex or the rangey vector parameter sets were not be initialized 
with three elements, a warning would be released and the default binning for the respective set of 2D histograms 
would be selected, i.e. both rangex and rangey would be initialized with default parameters.

 

Pair production

please write me

Brehmsstrahlung

please write me

Multiple Scattering

please write me

Nuclear Interactions

please write me

Muon Brehmsstrahlung

please write me

-- LukasVanelderen - 2015-04-20

Edit | Attach | Watch | Print version | History: r12 < r11 < r10 < r9 < r8 | Backlinks | Raw View | WYSIWYG | More topic actions
Topic revision: r12 - 2015-11-29 - GeorgiosKrintiras
 
    • 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