PixelDigitization

Author

fredr.nosp@m.ik.t.nosp@m.egenf.nosp@m.eldt.nosp@m.@cern.nosp@m..ch

Introduction

The package PixelDigitization provides the simulation of the pixel detector response. It reads the pixel detector hits generated by Geant4 and 'digitizes' the information. In addition several other detector effects not necessarily related to hits are treated. The result is output as so called RDO objects. These are then read by e.g the clustering and tracking algorithm further upstream of the processing.

Classes

The package consists of three groups of classes:

1. main class PixelDigitization : the user interface, reads the input hits and generates the output RDOs
2. surface charge generator : generates the initial charge collection from the Geant4 hits
3. charge processors : simulates various detector effects and operates on the current collection of charges

Together with SCT_Digitization, the package inherits functionality from SiDigitization. Briefly they are:

1. SiDigitization	: contains common framework with SCT_Digitization
2. SiChargedDiodeProcessor	: charged diode processor; all charge modifiers must inherit from this class
3. SiChargedDiode	: a class that contains the charge of a given pixel element
4. SiChargedDiodeCollection	: the container used internally to keep track of the generated charges
5. SiHelper	: static class with members operating on the SiChargeDiode status flag
6. SiRandomDisabledCellGenerator	: disables random pixels according to a given probability

NOTE: the current software design of the charge processors should be migrated to using (private) AlgTools (F.T, 26/7/2007)

In the table below, all the classes in the package are summarized. Columns 2-4 refers to how they operate on the collection of charged diodes.

Class	Modifies	Adds	Removes	Description
PixelDigitization	X	X	X	main class
PixelSimpleSurfaceChargesGenerator		X		generates the initial charge collection from the G4 hits
PixelChargeSmearer	X			adds random gaussian noise to existing charges
PixelDiodeCrossTalkGenerator		X		generates cross talk
PixelGangedMerger	X		X	merges ganged pixels
SpecialPixelGenerator			X	simulates special pixels using special pixel maps, simulated or from cond. DB
PixelTimeWalkGenerator	X		X	simulates the timing of the RDOs
PixelCellDiscriminator			X	simulates the discrimination

From TOT to RDO

The order of the following subsections follow the actual order they are executed.

1. Surface charge

Uses class PixelSimpleSurfaceChargesGenerator

The algorithm finds the entry and exit points of the track in the detector element. This distance is divided into a number of steps (default = 5). It is then assumed that an equal fraction of the total charge is deposited at each step. The obtained charge is then split into several charges (default = 100), each of which are then diffused to the surface of the detector. It takes into account the Lorentz angle and the stochastic nature of the diffusion.

2. Cross talk

Uses class PixelDiodeCrossTalkGenerator

Cross talk is generated if the original pixel has a minimum charge of 3 times the discriminator threshold. If that is true, the neighboring pixels with one side in common will be given a charge. The length of the common side is referred to as intersection length. For a neighbor with the same column number this length will be 400 microns (600 for long pixels). If the row number is the same, the length is then 50 microns. The deposited charge is proportional (jobOpt DiodeCrossTalk) to the product of this length and the original charge.

3. Thermal noise

Uses class PixelChargeSmearer

Each charge created up to this point is smeared with a gaussian of a given amplitude (currently 200e-). This does not create any new charged pixels.

4. General noise

Uses class PixelNoisyCellGenerator

The purpose with this is to add noise to random pixels irrespective if they have hits or not. As with the thermal noise, this adds a gaussian. However, in this case the mean is 3 sigma over the discriminator threshold with the same spread as the threshold. This will both modify existing charges and create new charged pixels.

5. Merge ganged pixels

Uses class PixelGangedMerger

This modifier merges ganged pixels and masks out the pixel not corresponding to the read out electronics (is the mask out really needed??).

6. Special pixels

Uses class SpecialPixelGenerator

In reality the detector will have problematic pixels that either will be completely silent or noisy. They are masked out using special pixel maps. The maps may be obtained from conditions database or simulated using a set of probabilities. If they are simulated, there is the option of simulating various Interval Of Validity (IOV) scenarios. All types of special pixels are defined here.

In addition to the special pixel maps, pixels may also be randomly disabled independently of the special pixel map. This is to simulate random inefficiencies. The frequency is controlled through a single probability.

7. Random disabling

Uses class SiRandomDisabledCellGenerator

The purpose of this modifer is to randomly disable pixelson an event-by-event basis. This simulates random inefficiences arising from non-masked pixels being temporarily disabled. A pixel is declared as disabled if a flat random number is below RndDisableProb.

8. Timing and discrimination

Uses class PixelTimeWalkGenerator and PixelCellDiscriminator

The timing is simulated as follows:

1. set time to an offset value (jobOption: TimeZero)
2. calculate time walk using the threshold and intime threshold (parametrised); the result is smeared by a gaussian
3. add random jitter (jobOption: TimeJitter - flat distribution [-jitter/2, +jitter/2] )
4. add G4Time and subtract ComTime (if used)
5. BCID = time/TimePerBCO

If the obtained BCID is outside the range [0,timeBCN-1], the pixel is flagged as below threshold and thus removed from further processing.

The discrimination compares the charge of the pixel with a threshold drawn randomly from a gaussian with mean and width from conditions database. Optionally, they may be set in jobOptions (DiscrThresh and DiscrThreshVar). If the charge is below the obtained threshold, the pixel is flagged as such.

9. ToT calculation and RDO

The TOT is calculated using a paremtrization where the parameters are either supplied by the user or taken from cond DB.

For each valid charge collection, a RDO is created and stored in storegate.In addition a collection of SDO objects (not clear if they are used??). The collection contains a map between the deposited charge and the truth (InDetSimData).For debugging purposes there exists an option RDOfromSPM. If set, a RDO collection will be created containing just the special pixel map. The RDOs in this collection will have a fixed ToT and time. Its name is derived by adding the postfix "_SPM" to the RDO collection name. Both RDO collections can be viewed using for example the PixelMonitoring package.

Extra Pages