Difference: PixelRadDamage (1 vs. 14)

Revision 142016-04-26 - RebeccaCarney

Line: 1 to 1
 
META TOPICPARENT name="BenjaminNachman"

PixelRadDamage

Line: 168 to 168
 

Neighbouring pixels

Changed:
<
<
>
>
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.
  neighboringPixels.png

Structure summary

Changed:
<
<
structure.png
>
>
How each of the steps above sits in the actual code is shown in the slide below. TODO add more after restructure
 
Added:
>
>
structure.png
 

Testing

Added:
>
>
TODO: PLOTS HERE
 

Setup environment

The svn location of the code is here:

Revision 132016-04-26 - RebeccaCarney

Line: 1 to 1
 
META TOPICPARENT name="BenjaminNachman"

PixelRadDamage

Line: 101 to 101
 
  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
Changed:
<
<
  • 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 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

    Line: 119 to 119
      drift.png
    Changed:
    <
    <
    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. And they not only generate a signal on the electrode they will eventually reach, but also in all the electrodes in their closest neighborhood. Usually, the way to model such a response is by using the Ramo potential for the desired electrode geometry. In principle after having taken into account these effects, one should see that the clusters in the pixel will become larger, resulting in an improvement of the resolution. The correct description of the signal formation process becomes even more important when there is charge trapping present. In that case, the charges will contribute to the final signal even if they result trapped, since they are inducing signal as they travel through the sensor.

    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.
    • Charge trapping:
      • The probability that a charge is trapped in the sensor has an exponential dependence with the charge z position in the sensor volume:

    $ P = 1 - e^{t/ \tau} = 1 - e^{(z/v\lambda)}$

    >
    >

    Trapping

     
    Changed:
    <
    <
    where t is the drift time, $\tau$ is the trapping constant, $\lambda$ is the mean free path and v is the drift velocity of the charge.
      • The trapping constant is proportional to 1/flux, so that the trapping probability increases with the received dose. $1/tau = \beta/\phi$ The constant, $beta$, has been measured in the ATLAS test beam and depends on the annealing time [Ref.] * Electric field:
      • The charge trapping is related to the electric field in the junction through the drift velocity v. Therefore, an accurate description of the electric field is essential for a realistic model.
      • After irradiation it has been measured that the electric field will evolve to a double-junction electric field [Refs CMS, others, Dortmund measurements!] for fluences up to 10^15 neq/cm^2. For higher fluences some measurements show that other charge transport models will be needed [Ref]

    • Depletion depth:
      • As the irradiation dose increases, the voltage required to fully deplete the sensor will increase. It is expected that it might increase up to 600 V during the whole LHC operation.
      • Eventually, in the least years of operation, we might reach voltages for which the detector cannot be fully depleted, when the applied bias voltage will be smaller than the depletion voltage.
      • In that case, as a consequence of the reduction of the active volume, the charge collected will decrease.

    • Lorentz angle:
      • The charges will experience a force $F_{L}=q(ExB)$ so that they will drift along a direction at an angle $\theta_{L}$, called the Lorentz angle.
      • The Lorentz angle can also be expressed as a function of the magnetic field B and the Hall mobility $\mu_{H}$ as $tan\theta_{L}=\mu_{H}B$
      • The Hall mobility is related to the drift mobility as $\mu_{H}=r\mu_{d}B$, where r is the mean free time between collisions and its value is ~1 for silicon.
      • Since the mobility depends on the electric field and the temperature, and the electric field will depend on both the received dose and the bias voltage, the Lorentz angle will also change.
      • It is important to accurately simulate this dependence, since the Lorentz angle will affect the cluster size and therefore the tracking resolution and other derived quantities.
    >
    >

    Overview

     
    Added:
    >
    >
    trapping.png
     
    Added:
    >
    >
    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:
     
    Added:
    >
    >
    1. Is the charge trapped?
    2. Where is it trapped (and why this matters)?
    3. What signal is induced on this and neighboring electrodes?
     
    Added:
    >
    >
    In the following subsections each of these steps will be explored in more detail.
     
    Changed:
    <
    <

    Trapping

    >
    >

    Is it trapped?

     
    Changed:
    <
    <

    Overview

    >
    >
    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:
     
    Changed:
    <
    <
    trapping.png
    >
    >
    isItTrapped.png
     
    Changed:
    <
    <

    Is it trapped?

    >
    >
    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.
     
    Changed:
    <
    <
    isItTrapped.png
    >
    >
    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

    Added:
    >
    >
    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
    Added:
    >
    >
    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

    Added:
    >
    >
     neighboringPixels.png

    Structure summary

    Revision 122016-04-22 - RebeccaCarney

    Line: 1 to 1
     
    META TOPICPARENT name="BenjaminNachman"

    PixelRadDamage

    Line: 99 to 99
     Inside this tool the analogue signal creation is divided into two parts:

      Changed:
      <
      <
    1. Energy deposition: 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. >
      >
    3. 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
    4.  
    5. 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.
    6. Added:
      >
      >

      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.

       
      Changed:
      <
      <

      Charge transport models

      The goal of our work is to provide a more realistic description of the signal formation in the electrodes while including radiation damage effects. In ATLAS the chain works as follows. We start with the simulation of a physics process in the usual way, and obtain the Geant output, which are HITS. The process of the signal formation is simulated in the digitization step to save computing time, and requires as an input the hits from the simulation process. After the digitization the output DIGITS are used as an input for the final reconstruction of the events.
      >
      >
      diffusion.png
       
      Changed:
      <
      <
      In the digitization the Geant hits are divided into several steps, their length depending on the length of the Geant segment. Then 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.
      >
      >
      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:
       
      Added:
      >
      >
      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.

      drift.png

        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. And they not only generate a signal on the electrode they will eventually reach, but also in all the electrodes in their closest neighborhood. Usually, the way to model such a response is by using the Ramo potential for the desired electrode geometry. In principle after having taken into account these effects, one should see that the clusters in the pixel will become larger, resulting in an improvement of the resolution. The correct description of the signal formation process becomes even more important when there is charge trapping present. In that case, the charges will contribute to the final signal even if they result trapped, since they are inducing signal as they travel through the sensor.
      Line: 143 to 152
       
      Deleted:
      <
      <

      Charge transport: drift and diffusion

       
      Deleted:
      <
      <
      diffusion.png drift.png
       

      Trapping

      Line: 295 to 301
       
      META FILEATTACHMENT attachment="Athena_chain.png" attr="" comment="" date="1461240642" name="Athena_chain.png" path="Athena_chain.png" size="4620222" user="rcarney" version="1"
      META FILEATTACHMENT attachment="digitizationStep.png" attr="" comment="" date="1461249232" name="digitizationStep.png" path="digitizationStep.png" size="4064177" user="rcarney" version="1"
      META FILEATTACHMENT attachment="bichsel.png" attr="" comment="" date="1461265387" name="bichsel.png" path="bichsel.png" size="36522" user="rcarney" version="1"
      Added:
      >
      >
      META FILEATTACHMENT attachment="diff_eqn.png" attr="" comment="" date="1461327450" name="diff_eqn.png" path="diff_eqn.png" size="147953" user="rcarney" version="1"

      Revision 112016-04-21 - RebeccaCarney

      Line: 1 to 1
       
      META TOPICPARENT name="BenjaminNachman"

      PixelRadDamage

      Line: 95 to 95
        PixelDigitization.png
      Added:
      >
      >
      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: 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 models

      The goal of our work is to provide a more realistic description of the signal formation in the electrodes while including radiation damage effects. In ATLAS the chain works as follows. We start with the simulation of a physics process in the usual way, and obtain the Geant output, which are HITS. The process of the signal formation is simulated in the digitization step to save computing time, and requires as an input the hits from the simulation process. After the digitization the output DIGITS are used as an input for the final reconstruction of the events.
      Line: 286 to 294
       
      META FILEATTACHMENT attachment="Example_TestStruct_Appliance.png" attr="" comment="" date="1461238389" name="Example_TestStruct_Appliance.png" path="Example_TestStruct_Appliance.png" size="45545" user="rcarney" version="1"
      META FILEATTACHMENT attachment="Athena_chain.png" attr="" comment="" date="1461240642" name="Athena_chain.png" path="Athena_chain.png" size="4620222" user="rcarney" version="1"
      META FILEATTACHMENT attachment="digitizationStep.png" attr="" comment="" date="1461249232" name="digitizationStep.png" path="digitizationStep.png" size="4064177" user="rcarney" version="1"
      Added:
      >
      >
      META FILEATTACHMENT attachment="bichsel.png" attr="" comment="" date="1461265387" name="bichsel.png" path="bichsel.png" size="36522" user="rcarney" version="1"

      Revision 102016-04-21 - RebeccaCarney

      Line: 1 to 1
       
      META TOPICPARENT name="BenjaminNachman"

      PixelRadDamage

      Line: 75 to 75
       

      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.
      Changed:
      <
      <
      Athena chain.png
      >
      >
      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.
      Line: 86 to 86
       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

      Changed:
      <
      <
      digitizationStep.png
      >
      >
      digitizationStep.png
       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:

      Added:
      >
      >
      PixelDigitization.png
       

      Charge transport models

      Line: 131 to 134
       
        • It is important to accurately simulate this dependence, since the Lorentz angle will affect the cluster size and therefore the tracking resolution and other derived quantities.
      Deleted:
      <
      <
      PixelDigitization.png
       

      Charge transport: drift and diffusion

      Line: 283 to 285
       
      META FILEATTACHMENT attachment="isItTrapped.png" attr="" comment="" date="1460638921" name="isItTrapped.png" path="isItTrapped.png" size="2402867" user="rcarney" version="1"
      META FILEATTACHMENT attachment="Example_TestStruct_Appliance.png" attr="" comment="" date="1461238389" name="Example_TestStruct_Appliance.png" path="Example_TestStruct_Appliance.png" size="45545" user="rcarney" version="1"
      META FILEATTACHMENT attachment="Athena_chain.png" attr="" comment="" date="1461240642" name="Athena_chain.png" path="Athena_chain.png" size="4620222" user="rcarney" version="1"
      Added:
      >
      >
      META FILEATTACHMENT attachment="digitizationStep.png" attr="" comment="" date="1461249232" name="digitizationStep.png" path="digitizationStep.png" size="4064177" user="rcarney" version="1"

      Revision 92016-04-21 - RebeccaCarney

      Line: 1 to 1
       
      META TOPICPARENT name="BenjaminNachman"

      PixelRadDamage

      Line: 25 to 25
       

      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.

      Changed:
      <
      <
      The code contents in its current form was put together by Matheiu Benoit, Callie Bertsche, and Ben Nachman. These most recent efforts have been verified and developed in the Allpix framework: a G4 based standalone simulation tool. Special TCAD maps for Silicon Pixel and IBL planar sensors have been produced specifically for this work.
      >
      >
      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.
       

      AllPix

      Added:
      >
      >
      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)
       
      Changed:
      <
      <
      This is the software we use to run our simulations. It is a wrapper around Geant4 that is very flexible. You can install it from here:
      >
      >
      Allpix is a Geant4 based standalone simulation tool. Source code and installation instructions are available via github:
        https://github.com/ALLPix/allpix
      Changed:
      <
      <
      (they just recently made a significant update which has some very nice features that I have not tested out yet - more on this shortly)
      >
      >
      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!
       
      Changed:
      <
      <
      The README (which you can also see on the github) is very good and should hopefully work out of the box for an installation on lxplus. Our digitizer is in src and is called
      >
      >
      If you source the setup script and compile with make, you should then be able to run allpix macros/EUDETtelescope_RadDamage_batch1_vis.in
       
      Changed:
      <
      <
      AllPixFEI4RadDamageDigitizer.cc
      >
      >
      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.
       
      Changed:
      <
      <
      I've spent a lot of time cleaning it up so hopefully it is readable (if not, please let me know and we should change something! ...it has come a long ways from where we started). You can see that there are a few files that are inputs (efile, tfile, and rfile). These are the E-field TCAD map, the time-to-the-electrode map (which is computed from the E-field beforehand) and the Ramo-potential map (independent of the fluence). The Ramo map is here:

      /afs/cern.ch/user/b/bnachman/work/public/RadDamage/allpix/share/absRamo3D-map-200um-output.root

      You may need to change that line yourself (I think with the new version, I lost permissions to edit so I'll fix that asap).

      If you source the setup script and 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. One pro tip is that if you are going to run a lot of events, it is very slow because Allpix needs to write out textfiles and if you are running on afs this is not particularly fast. To get around this, you can write to a scratch area, which is much faster. One new feature in this version of allpix is that some root files are automatically written with some basic information about the hits. From what I understand, these contain enough information for some quick comparisons.

      To reconstruct tracks from the telescope, we use EUTelescope which Mathieu has already installed so you don't need to go through that pain:

      >
      >
      To reconstruct tracks from the telescope, we use EUTelescope:
        https://github.com/ALLPix/AllPixTelescopeSimulationReco
      Line: 59 to 50
        https://github.com/pyEudetAnalysis/pyEudetAnalysis
      Added:
      >
      >
      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

      Added:
      >
      >
       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:

      Line: 74 to 68
       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.
      Deleted:
      <
      <
       The design and geometry of the pixel detector is not detailed here. For that see the Detector Introduction talk by Markus Keil.
      Added:
      >
      >

      RadDamage integration in Athena (from release 21)

      Overview

      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

      digitizationStep.png 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:

       

      Charge transport models

      Line: 117 to 131
       
        • It is important to accurately simulate this dependence, since the Lorentz angle will affect the cluster size and therefore the tracking resolution and other derived quantities.
      Deleted:
      <
      <

      RadDamage integration in Athena (from release 21)

      Overview

       PixelDigitization.png

      Charge transport: drift and diffusion

      Line: 272 to 281
       
      META FILEATTACHMENT attachment="step2.png" attr="" comment="" date="1460638921" name="step2.png" path="step2.png" size="1738293" user="rcarney" version="1"
      META FILEATTACHMENT attachment="ramo.png" attr="" comment="" date="1460638921" name="ramo.png" path="ramo.png" size="2483082" user="rcarney" version="1"
      META FILEATTACHMENT attachment="isItTrapped.png" attr="" comment="" date="1460638921" name="isItTrapped.png" path="isItTrapped.png" size="2402867" user="rcarney" version="1"
      Added:
      >
      >
      META FILEATTACHMENT attachment="Example_TestStruct_Appliance.png" attr="" comment="" date="1461238389" name="Example_TestStruct_Appliance.png" path="Example_TestStruct_Appliance.png" size="45545" user="rcarney" version="1"
      META FILEATTACHMENT attachment="Athena_chain.png" attr="" comment="" date="1461240642" name="Athena_chain.png" path="Athena_chain.png" size="4620222" user="rcarney" version="1"

      Revision 82016-04-21 - RebeccaCarney

      Line: 1 to 1
       
      META TOPICPARENT name="BenjaminNachman"

      PixelRadDamage

      Line: 9 to 9
       !! NB: Page under construction! Check back April 18th !!

      Introduction

      Changed:
      <
      <
      This TWiki concerns the description of the work that it is currently in progress to address the effects of the radiation damage in the ATLAS Pixel detector and implement them in simulation.
      >
      >
      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.
      Changed:
      <
      <
      Much of the motivation content of this twiki is ported over from a legacy page.
      >
      >
      Much of the background content on this Twiki page is ported over from a legacy page.
       

      Background and motivation

      Changed:
      <
      <
      The pixel detector is the ATLAS closest subsystem to the LHC beam, and therefore it will be the one that will receive the largest irradiation doses in ATLAS. The very high and unprecedented energy and luminosities expected for the LHC will require to operate the detectors under conditions never experienced before. During the whole ATLAS detector operation it is expected that the pixel detector will receive an irradiation fluence of $10^{15} n_{eq} cm^{-2}$ or radiation doses up to 50 Mrad. The detector is carefully designed to perform well under this conditions, even when radiation will change its physical properties. Not only the detector performance, but also the operations conditions must be subjected to the evolution of the detector's properties as radiation dose increases.
      >
      >
      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.
       
      Changed:
      <
      <
      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.
      >
      >
      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

      Changed:
      <
      <
      This work has been ongoing for at least the past 10 years with contributions from many people within ATLAS. The most recent effort of the work however has been verified in the Allpix framework.
      >
      >
      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. These most recent efforts have been verified and developed in the Allpix framework: a G4 based standalone simulation tool. Special TCAD maps for Silicon Pixel and IBL planar sensors have been produced specifically for this work.
       

      AllPix

      Revision 72016-04-14 - RebeccaCarney

      Line: 1 to 1
       
      META TOPICPARENT name="BenjaminNachman"

      PixelRadDamage

      Line: 22 to 22
        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.
      Added:
      >
      >

      History of work and aims

      This work has been ongoing for at least the past 10 years with contributions from many people within ATLAS. The most recent effort of the work however has been verified in the Allpix framework.

      AllPix

      This is the software we use to run our simulations. It is a wrapper around Geant4 that is very flexible. You can install it from here:

      https://github.com/ALLPix/allpix

      (they just recently made a significant update which has some very nice features that I have not tested out yet - more on this shortly)

      The README (which you can also see on the github) is very good and should hopefully work out of the box for an installation on lxplus. Our digitizer is in src and is called

      AllPixFEI4RadDamageDigitizer.cc

      I've spent a lot of time cleaning it up so hopefully it is readable (if not, please let me know and we should change something! ...it has come a long ways from where we started). You can see that there are a few files that are inputs (efile, tfile, and rfile). These are the E-field TCAD map, the time-to-the-electrode map (which is computed from the E-field beforehand) and the Ramo-potential map (independent of the fluence). The Ramo map is here:

      /afs/cern.ch/user/b/bnachman/work/public/RadDamage/allpix/share/absRamo3D-map-200um-output.root

      You may need to change that line yourself (I think with the new version, I lost permissions to edit so I'll fix that asap).

      If you source the setup script and 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. One pro tip is that if you are going to run a lot of events, it is very slow because Allpix needs to write out textfiles and if you are running on afs this is not particularly fast. To get around this, you can write to a scratch area, which is much faster. One new feature in this version of allpix is that some root files are automatically written with some basic information about the hits. From what I understand, these contain enough information for some quick comparisons.

      To reconstruct tracks from the telescope, we use EUTelescope which Mathieu has already installed so you don't need to go through that pain:

      https://github.com/ALLPix/AllPixTelescopeSimulationReco

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

      https://github.com/pyEudetAnalysis/pyEudetAnalysis

       

      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.
      Line: 80 to 116
       
        • Since the mobility depends on the electric field and the temperature, and the electric field will depend on both the received dose and the bias voltage, the Lorentz angle will also change.
        • It is important to accurately simulate this dependence, since the Lorentz angle will affect the cluster size and therefore the tracking resolution and other derived quantities.
      Deleted:
      <
      <

      History of work and aims

      AllPix

       
      Deleted:
      <
      <
      This is the software we use to run our simulations. It is a wrapper around Geant4 that is very flexible. You can install it from here:
       
      Changed:
      <
      <
      https://github.com/ALLPix/allpix
      >
      >

      RadDamage integration in Athena (from release 21)

       
      Changed:
      <
      <
      (they just recently made a significant update which has some very nice features that I have not tested out yet - more on this shortly)
      >
      >

      Overview

       
      Changed:
      <
      <
      The README (which you can also see on the github) is very good and should hopefully work out of the box for an installation on lxplus. Our digitizer is in src and is called
      >
      >
      PixelDigitization.png
       
      Changed:
      <
      <
      AllPixFEI4RadDamageDigitizer.cc
      >
      >

      Charge transport: drift and diffusion

       
      Changed:
      <
      <
      I've spent a lot of time cleaning it up so hopefully it is readable (if not, please let me know and we should change something! ...it has come a long ways from where we started). You can see that there are a few files that are inputs (efile, tfile, and rfile). These are the E-field TCAD map, the time-to-the-electrode map (which is computed from the E-field beforehand) and the Ramo-potential map (independent of the fluence). The Ramo map is here:
      >
      >
      diffusion.png drift.png
       
      Changed:
      <
      <
      /afs/cern.ch/user/b/bnachman/work/public/RadDamage/allpix/share/absRamo3D-map-200um-output.root
      >
      >

      Trapping

       
      Changed:
      <
      <
      You may need to change that line yourself (I think with the new version, I lost permissions to edit so I'll fix that asap).
      >
      >

      Overview

       
      Changed:
      <
      <
      If you source the setup script and make, you should then be able to run
      >
      >
      trapping.png
       
      Changed:
      <
      <
      allpix macros/EUDETtelescope_RadDamage_batch1_vis.in
      >
      >

      Is it trapped?

       
      Changed:
      <
      <
      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. One pro tip is that if you are going to run a lot of events, it is very slow because Allpix needs to write out textfiles and if you are running on afs this is not particularly fast. To get around this, you can write to a scratch area, which is much faster. One new feature in this version of allpix is that some root files are automatically written with some basic information about the hits. From what I understand, these contain enough information for some quick comparisons.
      >
      >
      isItTrapped.png
       
      Changed:
      <
      <
      To reconstruct tracks from the telescope, we use EUTelescope which Mathieu has already installed so you don't need to go through that pain:
      >
      >

      Induced signal

       
      Changed:
      <
      <
      https://github.com/ALLPix/AllPixTelescopeSimulationReco
      >
      >
      ramo.png step2.png
       
      Changed:
      <
      <
      There is also a nice python-based analysis framework for making plots from the EUTelescope output:
      >
      >

      Neighbouring pixels

       
      Changed:
      <
      <
      https://github.com/pyEudetAnalysis/pyEudetAnalysis
      >
      >
      neighboringPixels.png

      Structure summary

      structure.png

       
      Deleted:
      <
      <

      RadDamage integration in Athena (from release 21)

       

      Testing

      Setup environment

      Line: 225 to 263
       
      META FILEATTACHMENT attachment="typeInversion.png" attr="" comment="" date="1460627584" name="typeInversion.png" path="typeInversion.png" size="115661" user="rcarney" version="1"
      META FILEATTACHMENT attachment="sb_raddamage.gif" attr="" comment="" date="1460629176" name="sb_raddamage.gif" path="sb_raddamage.gif" size="20809" user="rcarney" version="1"
      Added:
      >
      >
      META FILEATTACHMENT attachment="structure.png" attr="" comment="" date="1460638920" name="structure.png" path="structure.png" size="224731" user="rcarney" version="1"
      META FILEATTACHMENT attachment="trapping.png" attr="" comment="" date="1460638920" name="trapping.png" path="trapping.png" size="92110" user="rcarney" version="1"
      META FILEATTACHMENT attachment="drift.png" attr="" comment="" date="1460638920" name="drift.png" path="drift.png" size="58127" user="rcarney" version="1"
      META FILEATTACHMENT attachment="diffusion.png" attr="" comment="" date="1460638920" name="diffusion.png" path="diffusion.png" size="61736" user="rcarney" version="1"
      META FILEATTACHMENT attachment="PixelDigitization.png" attr="" comment="" date="1460638920" name="PixelDigitization.png" path="PixelDigitization.png" size="130784" user="rcarney" version="1"
      META FILEATTACHMENT attachment="neighboringPixels.png" attr="" comment="" date="1460638920" name="neighboringPixels.png" path="neighboringPixels.png" size="2982064" user="rcarney" version="1"
      META FILEATTACHMENT attachment="step2.png" attr="" comment="" date="1460638921" name="step2.png" path="step2.png" size="1738293" user="rcarney" version="1"
      META FILEATTACHMENT attachment="ramo.png" attr="" comment="" date="1460638921" name="ramo.png" path="ramo.png" size="2483082" user="rcarney" version="1"
      META FILEATTACHMENT attachment="isItTrapped.png" attr="" comment="" date="1460638921" name="isItTrapped.png" path="isItTrapped.png" size="2402867" user="rcarney" version="1"

      Revision 62016-04-14 - RebeccaCarney

      Line: 1 to 1
       
      META TOPICPARENT name="BenjaminNachman"

      PixelRadDamage

      Line: 6 to 6
       
      Changed:
      <
      <

      AllPix

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

      Introduction

      This TWiki concerns the description of the work that it is currently in progress to address the effects of the radiation damage in the ATLAS Pixel detector 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 motivation content of this twiki is ported over from a legacy page.

      Background and motivation

      The pixel detector is the ATLAS closest subsystem to the LHC beam, and therefore it will be the one that will receive the largest irradiation doses in ATLAS. The very high and unprecedented energy and luminosities expected for the LHC will require to operate the detectors under conditions never experienced before. During the whole ATLAS detector operation it is expected that the pixel detector will receive an irradiation fluence of $10^{15} n_{eq} cm^{-2}$ or radiation doses up to 50 Mrad. The detector is carefully designed to perform well under this conditions, even when radiation will change its physical properties. Not only the detector performance, but also the operations conditions must be subjected to the evolution of the detector's properties as radiation dose increases.

      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.

      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.
        typeInversion.png
        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.

      Charge transport models

      The goal of our work is to provide a more realistic description of the signal formation in the electrodes while including radiation damage effects. In ATLAS the chain works as follows. We start with the simulation of a physics process in the usual way, and obtain the Geant output, which are HITS. The process of the signal formation is simulated in the digitization step to save computing time, and requires as an input the hits from the simulation process. After the digitization the output DIGITS are used as an input for the final reconstruction of the events.

      In the digitization the Geant hits are divided into several steps, their length depending on the length of the Geant segment. Then 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.

      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. And they not only generate a signal on the electrode they will eventually reach, but also in all the electrodes in their closest neighborhood. Usually, the way to model such a response is by using the Ramo potential for the desired electrode geometry. In principle after having taken into account these effects, one should see that the clusters in the pixel will become larger, resulting in an improvement of the resolution. The correct description of the signal formation process becomes even more important when there is charge trapping present. In that case, the charges will contribute to the final signal even if they result trapped, since they are inducing signal as they travel through the sensor.

      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.
      • Charge trapping:
        • The probability that a charge is trapped in the sensor has an exponential dependence with the charge z position in the sensor volume:

      $ P = 1 - e^{t/ \tau} = 1 - e^{(z/v\lambda)}$

      where t is the drift time, $\tau$ is the trapping constant, $\lambda$ is the mean free path and v is the drift velocity of the charge.

        • The trapping constant is proportional to 1/flux, so that the trapping probability increases with the received dose. $1/tau = \beta/\phi$ The constant, $beta$, has been measured in the ATLAS test beam and depends on the annealing time [Ref.] * Electric field:
        • The charge trapping is related to the electric field in the junction through the drift velocity v. Therefore, an accurate description of the electric field is essential for a realistic model.
        • After irradiation it has been measured that the electric field will evolve to a double-junction electric field [Refs CMS, others, Dortmund measurements!] for fluences up to 10^15 neq/cm^2. For higher fluences some measurements show that other charge transport models will be needed [Ref]

      • Depletion depth:
        • As the irradiation dose increases, the voltage required to fully deplete the sensor will increase. It is expected that it might increase up to 600 V during the whole LHC operation.
        • Eventually, in the least years of operation, we might reach voltages for which the detector cannot be fully depleted, when the applied bias voltage will be smaller than the depletion voltage.
        • In that case, as a consequence of the reduction of the active volume, the charge collected will decrease.

      • Lorentz angle:
        • The charges will experience a force $F_{L}=q(ExB)$ so that they will drift along a direction at an angle $\theta_{L}$, called the Lorentz angle.
        • The Lorentz angle can also be expressed as a function of the magnetic field B and the Hall mobility $\mu_{H}$ as $tan\theta_{L}=\mu_{H}B$
        • The Hall mobility is related to the drift mobility as $\mu_{H}=r\mu_{d}B$, where r is the mean free time between collisions and its value is ~1 for silicon.
        • Since the mobility depends on the electric field and the temperature, and the electric field will depend on both the received dose and the bias voltage, the Lorentz angle will also change.
        • It is important to accurately simulate this dependence, since the Lorentz angle will affect the cluster size and therefore the tracking resolution and other derived quantities.

      History of work and aims

      AllPix

        This is the software we use to run our simulations. It is a wrapper around Geant4 that is very flexible. You can install it from here:
      Line: 38 to 113
        https://github.com/pyEudetAnalysis/pyEudetAnalysis
      Changed:
      <
      <

      ATHENA

      >
      >

      RadDamage integration in Athena (from release 21)

       
      Added:
      >
      >

      Testing

       

      Setup environment

      The svn location of the code is here:

      Line: 148 to 222
       BenjaminNachman - 2016-02-15

      RebeccaCarney - 2016-02-18

      Added:
      >
      >
      META FILEATTACHMENT attachment="typeInversion.png" attr="" comment="" date="1460627584" name="typeInversion.png" path="typeInversion.png" size="115661" user="rcarney" version="1"
      META FILEATTACHMENT attachment="sb_raddamage.gif" attr="" comment="" date="1460629176" name="sb_raddamage.gif" path="sb_raddamage.gif" size="20809" user="rcarney" version="1"

      Revision 52016-02-25 - RebeccaCarney

      Line: 1 to 1
       
      META TOPICPARENT name="BenjaminNachman"

      PixelRadDamage

      Line: 132 to 132
       

      Checking out the code

      #Now, let's start looking at the code

      Changed:
      <
      <
      pkgco.py PixelDigitization
      >
      >
      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.
      setupWorkArea.py
      Line: 145 to 145
        InnerDetector/InDetDigitization/PixelDigitization/src/PixelECChargeTool.cxx
      Deleted:
      <
      <
      -- BenjaminNachman - 2016-02-15 -- RebeccaCarney - 2016-02-18
       \ No newline at end of file
      Added:
      >
      >
      BenjaminNachman - 2016-02-15

      RebeccaCarney - 2016-02-18

      Revision 42016-02-22 - RebeccaCarney

      Line: 1 to 1
       
      META TOPICPARENT name="BenjaminNachman"

      PixelRadDamage

      Line: 144 to 146
       InnerDetector/InDetDigitization/PixelDigitization/src/PixelECChargeTool.cxx

      -- BenjaminNachman - 2016-02-15 \ No newline at end of file

      Added:
      >
      >
      -- RebeccaCarney - 2016-02-18
       \ No newline at end of file

      Revision 32016-02-16 - RebeccaCarney

      Line: 1 to 1
       
      META TOPICPARENT name="BenjaminNachman"

      PixelRadDamage

      Line: 123 to 121
       [me@lxplusxxx dir]$
      Changed:
      <
      <
      #Now, just to run once to make sure things work
      Reco_tf.py --inputHITSFile user.stsuno.mc15_13TeV.361107.PowhegPythia8EvtGen_AZNLOCTEQ6L1_Zmumu.evgen.EVNT.e3601_ATLAS-R2-2015-03-15-00.v1_EXT0.59780745/user.stsuno.7335511.EXT0._001310.HITS.pool.root.3 --outputRDOFile user.bnachman.test.RDO.pool.root
      #It worked!
      >
      >
      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.

      Revision 22016-02-16 - RebeccaCarney

      Line: 1 to 1
       
      META TOPICPARENT name="BenjaminNachman"
      Added:
      >
      >

      PixelRadDamage


       

      AllPix

      This is the software we use to run our simulations. It is a wrapper around Geant4 that is very flexible. You can install it from here:

      Changed:
      <
      <
      https://github.com/ALLPix/allpix
      >
      >
      https://github.com/ALLPix/allpix
        (they just recently made a significant update which has some very nice features that I have not tested out yet - more on this shortly)

      The README (which you can also see on the github) is very good and should hopefully work out of the box for an installation on lxplus. Our digitizer is in src and is called

      Changed:
      <
      <
      AllPixFEI4RadDamageDigitizer.cc
      >
      >
      AllPixFEI4RadDamageDigitizer.cc
        I've spent a lot of time cleaning it up so hopefully it is readable (if not, please let me know and we should change something! ...it has come a long ways from where we started). You can see that there are a few files that are inputs (efile, tfile, and rfile). These are the E-field TCAD map, the time-to-the-electrode map (which is computed from the E-field beforehand) and the Ramo-potential map (independent of the fluence). The Ramo map is here:
      Changed:
      <
      <
      /afs/cern.ch/user/b/bnachman/work/public/RadDamage/allpix/share/absRamo3D-map-200um-output.root
      >
      >
      /afs/cern.ch/user/b/bnachman/work/public/RadDamage/allpix/share/absRamo3D-map-200um-output.root
        You may need to change that line yourself (I think with the new version, I lost permissions to edit so I'll fix that asap).

      If you source the setup script and make, you should then be able to run

      Changed:
      <
      <
      allpix macros/EUDETtelescope_RadDamage_batch1_vis.in
      >
      >
      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. One pro tip is that if you are going to run a lot of events, it is very slow because Allpix needs to write out textfiles and if you are running on afs this is not particularly fast. To get around this, you can write to a scratch area, which is much faster. One new feature in this version of allpix is that some root files are automatically written with some basic information about the hits. From what I understand, these contain enough information for some quick comparisons.
      Line: 34 to 40
       

      ATHENA

      Added:
      >
      >

      Setup environment

       The svn location of the code is here:

      https://svnweb.cern.ch/trac/atlasoff/browser/InnerDetector/InDetDigitization/PixelDigitization

      Changed:
      <
      <
      setupATLAS
      >
      >
      setupATLAS
       asetup AtlasProduction,20.7.3.8,here
      Changed:
      <
      <
      #Now, just to run once to make sure things work
      Reco_tf.py --inputHITSFile user.stsuno.mc15_13TeV.361107.PowhegPythia8EvtGen_AZNLOCTEQ6L1_Zmumu.evgen.EVNT.e3601_ATLAS-R2-2015-03-15-00.v1_EXT0.59780745/user.stsuno.7335511.EXT0._001310.HITS.pool.root.3 --outputRDOFile user.bnachman.test.RDO.pool.root
      >
      >

      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
      Info: Set RUCIO_ACCOUNT to MYACCOUNT
      >>>>>>>>>>>>>>>>>>>>>>>>> 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 user.stsuno.mc15_13TeV.361107.PowhegPythia8EvtGen_AZNLOCTEQ6L1_Zmumu.evgen.EVNT.e3601_ATLAS-R2-2015-03-15-00.v1_EXT0.59780745/user.stsuno.7335511.EXT0._001310.HITS.pool.root.3 --outputRDOFile user.bnachman.test.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.

      Changed:
      <
      <
      #Now, let's start looking at the code
      pkgco.py PixelDigitization
      #CMT--->
      Info: Working on InnerDetector/InDetDigitization/PixelDigitization (PixelDigitization-02-00-20)
      #Checked out revision 723915.
      setupWorkArea.py
      cd WorkArea/cmt
      cmt bro cmt config
      cmt bro gmake
      cd ../..
      >
      >

      Checking out the code

      #Now, let's start looking at the code
      pkgco.py PixelDigitization
      #CMT---> Info: Working on InnerDetector /InDetDigitization/PixelDigitization (PixelDigitization -02-00-20)
      #Checked out revision 723915.
      setupWorkArea.py
      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:
      Changed:
      <
      <
      InnerDetector/InDetDigitization/PixelDigitization/src/PixelECChargeTool.cxx
      >
      >
      InnerDetector/InDetDigitization/PixelDigitization/src/PixelECChargeTool.cxx
        -- BenjaminNachman - 2016-02-15

      Revision 12016-02-15 - BenjaminNachman

      Line: 1 to 1
      Added:
      >
      >
      META TOPICPARENT name="BenjaminNachman"

      AllPix

      This is the software we use to run our simulations. It is a wrapper around Geant4 that is very flexible. You can install it from here:

      https://github.com/ALLPix/allpix

      (they just recently made a significant update which has some very nice features that I have not tested out yet - more on this shortly)

      The README (which you can also see on the github) is very good and should hopefully work out of the box for an installation on lxplus. Our digitizer is in src and is called

      AllPixFEI4RadDamageDigitizer.cc

      I've spent a lot of time cleaning it up so hopefully it is readable (if not, please let me know and we should change something! ...it has come a long ways from where we started). You can see that there are a few files that are inputs (efile, tfile, and rfile). These are the E-field TCAD map, the time-to-the-electrode map (which is computed from the E-field beforehand) and the Ramo-potential map (independent of the fluence). The Ramo map is here:

      /afs/cern.ch/user/b/bnachman/work/public/RadDamage/allpix/share/absRamo3D-map-200um-output.root

      You may need to change that line yourself (I think with the new version, I lost permissions to edit so I'll fix that asap).

      If you source the setup script and 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. One pro tip is that if you are going to run a lot of events, it is very slow because Allpix needs to write out textfiles and if you are running on afs this is not particularly fast. To get around this, you can write to a scratch area, which is much faster. One new feature in this version of allpix is that some root files are automatically written with some basic information about the hits. From what I understand, these contain enough information for some quick comparisons.

      To reconstruct tracks from the telescope, we use EUTelescope which Mathieu has already installed so you don't need to go through that pain:

      https://github.com/ALLPix/AllPixTelescopeSimulationReco

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

      https://github.com/pyEudetAnalysis/pyEudetAnalysis

      ATHENA

      The svn location of the code is here:

      https://svnweb.cern.ch/trac/atlasoff/browser/InnerDetector/InDetDigitization/PixelDigitization

      setupATLAS
      asetup AtlasProduction,20.7.3.8,here

      #Now, just to run once to make sure things work
      Reco_tf.py --inputHITSFile user.stsuno.mc15_13TeV.361107.PowhegPythia8EvtGen_AZNLOCTEQ6L1_Zmumu.evgen.EVNT.e3601_ATLAS-R2-2015-03-15-00.v1_EXT0.59780745/user.stsuno.7335511.EXT0._001310.HITS.pool.root.3 --outputRDOFile user.bnachman.test.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.

      #Now, let's start looking at the code
      pkgco.py PixelDigitization
      #CMT--->

      Info: Working on InnerDetector/InDetDigitization/PixelDigitization (PixelDigitization-02-00-20)
      #Checked out revision 723915.
      setupWorkArea.py
      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:

      InnerDetector/InDetDigitization/PixelDigitization/src/PixelECChargeTool.cxx

      -- BenjaminNachman - 2016-02-15

       
      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