!! NB: Page under construction! Check back April 18th !!


This TWiki concerns work currently in progress to address the effects of the radiation damage in the ATLAS Pixel and IBL detectors and implement them in simulation. Work to this effect is being done on two fronts:

  • Modeling and test beams by the Allpix collaboration
  • Integration of these results in the Atlas simulation and reconstruction chain via Digitization in Athena.
Much of the background content on this Twiki page is ported over from a legacy page.

Background and motivation

The Pixel detector is the ATLAS subsystem closest to the LHC beam and therefore it will receive the largest irradiation doses. Up to its replacement in LS3, the Pixel detector will receive a fluence of $10^{15} n_{eq} cm^{-2}$ or a dose of up to 50 MRad. The detector is carefully designed to perform well under this conditions, even when radiation will change its physical properties. As such, not only will the detector performance change with increasing dose, but so too will the operating conditions need to evolve.

The monitoring and simulation of these effects is therefore crucial not only for understanding the detector performance and for validating our Monte Carlo simulations, but also to be able to operate the detector to guarantee the best Physics results during all operational phases.

History of work and aims

Studies into the effects of high-intensity and high-energy radiation damage in Silicon has been published for at least 60 years, and efforts in the collaboration to include and validate these models has been ongoing for at least the past 10 years with contributions from many people within ATLAS. The code contents in its current form was put together by Matheiu Benoit, Callie Bertsche, and Ben Nachman and more recently added to the Athena framework by Rebecca Carney. These most recent efforts have been verified and developed in the Allpix framework. Special TCAD maps for Silicon Pixel and IBL planar sensors have been produced specifically for this work.


Example TestStruct Appliance.png
Timepix Detector with Lead brick (gray) and Am241 source holder( Cylinder) (test Structure) and Chip Board protector attached to Timepix PCB (Red, Appliance)

Allpix is a Geant4 based standalone simulation tool. Source code and installation instructions are available via github:


The digitizer that was used as a basis for the Athena code is the AllPixFEI4RadDamageDigitizer.cc. A quick way to see the effects of this digitizer is to run one of the Allpix macros!

If you source the setup script and compile with make, you should then be able to run allpix macros/EUDETtelescope_RadDamage_batch1_vis.in

This will generate a 120 GeV pion beam going through a telescope with our sensor as a DUT. Its worth playing around a little in the .in file to see how easy and versatile it is to e.g. change the beam type, size, energy, sensor tilt angle, etc. Tip: if you are going to run a lot of events, Allpix might run slow as it needs to write out textfiles and if you are running on afs it's not particularly fast. To get around this, you can write to a scratch area, which is much faster.

To reconstruct tracks from the telescope, we use EUTelescope:


There is also a nice python-based analysis framework for making plots from the EUTelescope output:


Please note that none of the above is necessary to run radiation damage in Athena but serves as an alternative platform on which to develop alternative digitizers. Since it was used to develop the techniques in athena, it is included here for completeness.

Effects of radiation damage

Radiation damage effects can be caused by ionizing loses, which result in damage in the sensor surface, and non-ionizing energy loses, which damage the bulk of the sensor, resulting in crystal defects that will change the physical properties of the detectors. The pixels are well insulated to prevent short-circuits due to ionizing loses, and therefore, the most important effects to study and characterize are those related to the bulk of the detector.

The bulk damage is mainly caused by neutrons and charged hadrons, as the energy transfer of electrons and photons to the crystal atoms is not enough to produce significant damage. The most relevant effects are:

  • Type inversion: The introduction of acceptor centers will change the doping concentration. As the absorbed radiation dose increases the effective doping concentration will evolve creating a double junction and the bulk will go under type-inversion. After type inversion occurs, the voltage needed to fully deplete the sensor ($V_{dep}$) will increase continuously, affecting the operation of the detector. It is expected that the b-layer will go under type-inversion when ATLAS reach ~10 $fb^{-1}$ of integrated luminosity.
    Dependence of Neff on the accumulated 1 MeV neutron equivalent fluence for standard and oxygen enriched FZ silicon irradiated with reactor neutrons (Ljubljana), 23 GeV protons (CERN PS) and 192 MeV pions (PSI).http://rd48.web.cern.ch/RD48/status-reports/RD48-3rd-status-report.pdf

  • Increase of the leakage current: The creation of recombination/generation centers due to the impurities in the crystal will lead to an increase of the leakage current in the bulk, increasing the electronic noise and the power consumption. This will affect the signal to noise ratio of the detector. The leakage current has a strong dependence with the temperature, and minimizing its effects is a good motivation for cooling detectors down $ I(T) \approx \exp^{-E/2kT}$ (where k is the Boltzman constant).

  • Charge trapping: The impurities in the crystal will act as charge carrier trapping centers, leading to a reduction of the total collected charge. This will affect the detector performance, the tracking resolution and the b-tagging efficiencies.

In general, radiation damage effects will lead to an decrease of the signal/noise ratio, as described by the figure below:

sb raddamage.gif
Signal to Noise ratio reduction due to radiation damage effects.

The design and geometry of the pixel detector is not detailed here. For that see the Detector Introduction talk by Markus Keil.

RadDamage integration in Athena (from release 21)


Athena: overview

The Athena reconstruction chain can be broken down into explicit sections, each of which produce a different file type - a snapshot of the reconstruction step. Whilst the Athena framework is used for reconstructing real data from the LHC from digits to tracks and finally to particle signatures, it is also used to provide a realistic simulation of the data.

Athena chain.png

The figure above shows the various stages and snapshots of the Athena chain. In simulating data we start at the top of this flow chart, if we were reconstructing real data from the detector it would be fed into the 'reconstruction' step of the workflow. The Athena chain consists of the following steps:

  1. Event Generation: particles are generated from proton-proton collisions. At this point in the simulation there is no sense of where the particles are with respect to the detector. A HepMC file is output from this stage.
  2. Simulation: In this step the particles from the event generator are put into the context of a G4 simulation of ATLAS. In this step the composition of each element of the detector by element and proportion is considered and how much energy loss, how the path of the particles produced deviates in the material, and hence the entry and exit points of the the particle in the detector material are recorded. This step produces a HITS file.
  3. Digitization: This is the part of the simulation chain where the radiation damage code is included and much more detail will be covered in sections that follow this. Taking the entry and exit point from the HITS file, a the path of the particle in the detector is constructed and along that path energy is deposited. The signal in the detector is then formed in 2 major steps: first the detector properties are used to simulate the analog signal, then the detector DAQ, be it front-end chip or other, is used to create the 'digits' or digital representation of that analogue signal that the real detector produces. An RDO is produced from this step.
  4. Reconstruction: In this step the simulation data is treated identically to the real data and tracks are reconstructed from the data.

There's of course much more going on in this last step and subsequent steps but it is not relevant to our work here.

Digitization: overview


The digitization step can be broken down into 2 distinct steps. First an analogue signal is generated (which is what the slide above motivates for depleted Silicon detectors) and then passed to (again, in the case of pixels) a signal threshold which allows the position and the charge deposited to be recorded digitally.

Let's break this down further and start using Athena classes in our description:


The creation of the 'analogue' signal from the generated particle is done in a subclass of the SubChargesTool class. This allows there to be a slightly different implementation of the class for different detector types Please note that this is going to change in the next few months, these multiple subclasses will be merged where possible as the differences between them e.g. the Pixel and IBL classes differ only by sensor depth and pixel size. Inside this tool the analogue signal creation is divided into two parts:

  1. Energy deposition distribution: in this step the total energy loss in the detector is distributed across the bulk. The way this was done up to release 21 is uniformly across the path traversed by the particle - however this is very unphysical even if it is easy to implement! A BichselDeposition model has now been added additionally to the digitizer, details for which can be found in this presentation: https://indico.cern.ch/event/497385/contributions/2010266/attachments/1257103/1856249/PixelWeek.pdf
  2. Charge transport model: Once we've decided how the energy is distributed across the sensor, the charge carriers created by the ionising radiation have to be drifted to their corresponding electrodes. It is this drift across the bulk that ultimately produces the signal in the detector. The radiation damage model will affect this part of the code.

Charge transport: drift and diffusion

In the digitization, without including rad damage, every sub-charge is drifted to the electrode plane, taking into account the diffusion and the Lorentz angle effects. In this model it is assumed that all sub-charges will finally arrive to the electrodes, and that they generate a signal only in the electrode they have reached. Before we go into how the rad damage changes this, let's consider the drift from the Lorentz force and the diffusion components.


Random thermal movement of carriers in the case of a gradient of carrier concentration will spread the distribution, this is shown in the cartoon above as the pink arrows. There is also a drift contribution from external magnetic field interacting with the current in the sensor (Lorentz force), which deviates the drift direction by an angle (the Lorentz angle). The components of this are shown in blue in the cartoon above. We are currently working to change the formula for the diffusion:

diff eqn.png

TODO: please add more to this subsection. Of course the distance from collection side scales the amount of diffusion and distance of the drift due to the Lorentz force. There is also a drift across the depth of the sensor, perpendicular to the plane of the collecting electrode for the planar sensors, caused by the biasing of the sensor to create an electric potential across the bulk. This contribution to the trajectory of the charge carrier is shown in yellow. These contributions are combined to give the final position of the drifted charge carrier over the electrodes, shown in the cartoon below.





The previous section shows a cartoon where the chunk of like charge carriers are unimpeded in their motion and drift fully to the collecting electrode - but how does this picture change when radiation damage is included? Trapping literally stops a chunk of charge carriers before it reaches the electrode (as you can see in the cartoon above), so only part of the energy deposited in the bulk is recorded. The new chargeTool models this in three steps:

  1. Is the charge trapped?
  2. Where is it trapped (and why this matters)?
  3. What signal is induced on this and neighboring electrodes?

In the following subsections each of these steps will be explored in more detail.

Is it trapped?

The first part of modeling trapping is, for a specific chunk of charges (representing a proportion of energy deposited): are they trapped or do they make it all the way to their collecting electrode. To figure this out we must first understand the distribution of charges that are trapped! Let's look at the slide below to see how this is done:


Let's discuss step 1b in a little more detail. The condition for trapping states that if the trapping time (i.e. the time the charge carriers drift before being trapped) is greater than the time it takes for them to reach their collecting electrode: the charge is NOT trapped. Otherwise it is. But how do we determine the time to electrode? Look at the TH1 in the slide above. The x-axis shows the depth of the charge carrier chunk from its collecting electrode, the y-axis is the time it will take the charge carrier to reach the electrode. This map is constructed using information about the charge carrier type (hole or electron) and the detector geometry (size of pixels, depth of sensor bulk, doping type) and the detector conditions (bias, temperature, fluence): so you can imagine that many versions of such a map are needed for the many different conditions each sensor may be subjected to. How this is accounted for will be explained later in the twiki.

For now it suffices to know that such a mapping, between charge carrier chunk starting depth and time-to-electrode, exists for each detector type and condition. Now we know if a chunk of charge is trapped in the bulk or not, we need to know how this affects the signal in the detector!

Induced signal

Without trapping every sub-charge is drifted to the electrode plane, in this model it is assumed that all sub-charges will finally arrive to the electrodes and that they generate a signal only in the electrode they have reached. However in reality the charges generated when a charged particle goes through the sensor induce a signal in the electrode some time before they have reached it. The slide below explains:

ramo.png step2.png

The main components of the model we are implementing are:

  • Ramo potential:
    • The Ramo potential (Vr) models how the signal will be formed in the electrodes.
    • It is obtained by numerically solving the Laplace Eq. for a charge with boundary conditions Vr = 1 for the electrode subtending the charge, and zero for the rest.

As with the time-to-electrode this Ramo (weighting) potential is pre-calculated but, unlike the time-to-electrode, is independent of detector conditions and so only one map needs to be generated per sensor type. Now that the partial signal induced on the collecting electrode, before the charge chunk is trapped, is known is there anything left to do?

Neighbouring pixels

Adjacent electrodes are not isolated from the bulk material where the charge carriers are moving and so a signal is induced on neighbouring electrodes as on the collecting electrode. Just as with the collecting electrode we may calculate how much signal is induced using the Ramo potential. The induced signal on the neighbouring electrodes has a very different shape: a bipolar signal that is first positive then negative and so the total integrated charge, if the charge travels all the way to its collecting electrode, is zero. However, in the case that part of the charge is trapped: the signal does not fully integrate to zero. This means that in the case of trapping part of the signal is lost but is also spread out amongst the neighbouring electrodes. This final step caluclates this charge sharing effect.


Structure summary

How each of the steps above sits in the actual code is shown in the slide below. TODO add more after restructure




Setup environment

The svn location of the code is here:


asetup AtlasProduction,,here

Dataset for testing

We are currently using this dataset to run tests:

For completeness: to download make sure your VOMS proxy is working:

[me@lxplusxxxx dir]$ voms-proxy-init -voms atlas
Picked up _JAVA_OPTIONS: -Xms64m -Xmx128m
Enter GRID pass phrase for this identity:
Contacting voms2.cern.ch:xxxx [/DC=ch/DC=cern/OU=computers/CN=voms2.cern.ch] "atlas"...
Remote VOMS server contacted succesfully.=

Created proxy in /tmp/x509up_ux.xxxX

Your proxy is valid until Tue Jan 26 06:12:57 CET 2016

Setup rucio:

[me@lxplusxxxx dir]$ localSetupRucioClients
Requested:  rucio ...
 Setting up emi 3.14.0-1_v4c.sl6 ...
 Setting up rucio 1.2.4 ...
Info: Setting compatibility to slc6
Warning: missing 32-bit kerberos externals dir
Info: Set RUCIO_AUTH_TYPE to x509_proxy
>>>>>>>>>>>>>>>>>>>>>>>>> Information for user <<<<<<<<<<<<<<<<<<<<<<<<<
emi: Your proxy has 11h:59m:32s remaining ************************************************************************ [me@lxplusxxxx dir]$

Best to check if your account is active too:

[me@lxplusxxxx dir]$ rucio whoami
status     : ACTIVE
account    : myName
account_type : USER
created_at : DATE
suspended_at : None
updated_at : DATE
deleted_at : None
email      : myEmail@something
 [me@lxplusxxxx dir]$

Now just download your file!

[me@lxplusxxx dir]$ rucio download mc15_13TeV:HITS.07289242._000021.pool.root.1
2016-01-25 18:56:32,761 INFO [Starting download for mc15_13TeV:HITS.07289242._000021.pool.root.1 with 1 files]
2016-01-25 18:56:32,839 INFO [Starting the download of mc15_13TeV:HITS.07289242._000021.pool.root.1]
File downloaded. Will be validated
File validated
2016-01-25 19:01:18,459 INFO [File mc15_13TeV:HITS.07289242._000021.pool.root.1 successfully downloaded from TRIUMF-LCG2_DATADISK]
2016-01-25 19:01:18,507 INFO [File mc15_13TeV:HITS.07289242._000021.pool.root.1successfully downloaded. 2.4 GB bytes downloaded in 285.666765928 seconds]
2016-01-25 19:01:19,202 INFO [Download operation for mc15_13TeV:RDO.07434882._000001.pool.root.1 done]=
Download summary

DID mc15_13TeV:RDO.07434882._000001.pool.root.1
Total files :                                 1
Downloaded files :                            1
Files already found locally :                 0
Files that cannot be downloaded :             0
[me@lxplusxxx dir]$

Now, just to run once to make sure things work
Reco_tf.py --inputHITSFile HITS.07289242._000021.pool.root.1 --outputRDOFile myTest.RDO.pool.root
It worked!

There are a lot of other options that Soshi gave us to include, which we should do for the full validation, but for testing we only need a minimal command that includes the digitizer.

Checking out the code

#Now, let's start looking at the code
pkgco.py PixelDigitization Only do this if you want to work from a specific revision. We might need to work from trunk, in which case 'cmt co InnerDetector /InDetDigitization/PixelDigitization' should work.
#CMT---> Info: Working on InnerDetector /InDetDigitization/PixelDigitization (PixelDigitization -02-00-20)
#Checked out revision 723915.
cd WorkArea /cmt
cmt bro cmt config
cmt bro gmake
cd ../..

You only need to check out the code once, but every time you change something, you need to repeat the cmt bro gmake bit (can also compile in the package, which is often easier if we need to check out more than one). The code we need to modify is this:


BenjaminNachman - 2016-02-15

RebeccaCarney - 2016-02-18

Topic attachments
I Attachment History Action Size Date Who Comment
PNGpng Athena_chain.png r1 manage 4511.9 K 2016-04-21 - 14:10 RebeccaCarney  
PNGpng Example_TestStruct_Appliance.png r1 manage 44.5 K 2016-04-21 - 13:33 RebeccaCarney  
PNGpng PixelDigitization.png r1 manage 127.7 K 2016-04-14 - 15:02 RebeccaCarney  
PNGpng bichsel.png r1 manage 35.7 K 2016-04-21 - 21:03 RebeccaCarney  
PNGpng diff_eqn.png r1 manage 144.5 K 2016-04-22 - 14:17 RebeccaCarney  
PNGpng diffusion.png r1 manage 60.3 K 2016-04-14 - 15:02 RebeccaCarney  
PNGpng digitizationStep.png r1 manage 3968.9 K 2016-04-21 - 16:33 RebeccaCarney  
PNGpng drift.png r1 manage 56.8 K 2016-04-14 - 15:02 RebeccaCarney  
PNGpng isItTrapped.png r1 manage 2346.5 K 2016-04-14 - 15:02 RebeccaCarney  
PNGpng neighboringPixels.png r1 manage 2912.2 K 2016-04-14 - 15:02 RebeccaCarney  
PNGpng ramo.png r1 manage 2424.9 K 2016-04-14 - 15:02 RebeccaCarney  
GIFgif sb_raddamage.gif r1 manage 20.3 K 2016-04-14 - 12:19 RebeccaCarney  
PNGpng step2.png r1 manage 1697.6 K 2016-04-14 - 15:02 RebeccaCarney  
PNGpng structure.png r1 manage 219.5 K 2016-04-14 - 15:02 RebeccaCarney  
PNGpng trapping.png r1 manage 90.0 K 2016-04-14 - 15:02 RebeccaCarney  
PNGpng typeInversion.png r1 manage 113.0 K 2016-04-14 - 11:53 RebeccaCarney  
Edit | Attach | Watch | Print version | History: r14 < r13 < r12 < r11 < r10 | Backlinks | Raw View | WYSIWYG | More topic actions
Topic revision: r14 - 2016-04-26 - RebeccaCarney
    • Cern Search Icon Cern Search
    • TWiki Search Icon TWiki Search
    • Google Search Icon Google Search

    Main 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