Allpix > Athena Student Instrumentation Weekly Update March 18th - - PowerPoint PPT Presentation

18/03/16

1

Mathieu Benoit, Philippe Grenier, Lingxin Meng, Ben Nachman, Veronica Wallangen

Allpix —> Athena

Rebecca Carney Student Instrumentation Weekly Update March 18th

RMD Carney 18/03/16

Overview

2

Allpix radiation damage digitizer migration

ATLAS Reconstruction chain Digitization: step-by-step Digitization: radiation damage considerations PixelDigitization in Athena Next steps

RMD Carney 18/03/16

Atlas Reconstruction Chain

3

From physics events to detector hits to reconstructed interactions

Generation HepMC Simulation G4 Hits Digitization G4 Digits Reconstruction Create AOD ESD AOD Analysis Real Data Atlfast

Event generation G4 MonteCarlo Digitization Track reconstruction

RMD Carney 18/03/16

Digitization step

4

Create an analog signal, add noise, create digit

Ionising interactions liberate free charge carriers in the depleted bulk of the material. The bias across the device creates an electric field which the charge carriers move within, holes in one direction, electrons in the

• ther.

This movement within the bulk induces a current on the collecting electrodes. This current continues until the free charge carriers recombine at their respective electrodes. Before the digitizer ‘digitizes’ it must create an analog signal in the detector based on the particle type, energy, and path length within the detector volume.

RMD Carney 18/03/16

Pixel digitizer: step-by-step

5

Step 1: Segment path

The basic setup is the same for both the current and new charge() functions: energy deposited over the entire path length of the particle’s trajectory is divided up into equal segments.

RMD Carney 18/03/16

6

+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + -

Pixel digitizer: step-by-step

For each step along the path, segment the energy deposited into a finite number of chunks (~50 per step by default).

Step 2: Segment charge created / energy deposited in each step

RMD Carney 18/03/16

7

+

• .

. Pixel digitizer: step-by-step

Step 3: diffuse charge in plane

The charges are diffused parallel to the electrode (i.e. in x and y) and in one of those directions (assuming a given orientation) the charges will also get a contribution from the Lorentz force.

RMD Carney 18/03/16

8

+

• Pixel digitizer: step-by-step

If no charge is trapped the induced signal on the electrode integrated in time is equal to the total charge recombining at the electrode: so the original digitizer just drifts the charge parallel to the electrode and establishes the pixel where that charge would be collected, then passes it to the digitizing portion of the code.

Step 4: drift charge in E-field to electrode

RMD Carney 18/03/16

slide title

9

Subtitle

RMD Carney 18/03/16

10

• 1. From the electric field at the charge carrier’s starting depth and the mobility of the charge

carrier: the time-to-electrode is looked up (LUT).

• 2. The drift time of this particular charge chunk is also calculated - this involves the probability

that the charge will be trapped and is dependent on fluence.

• 3. If the drift time < time-to-electrode, the charge is trapped.
• 4. The depth at which the carrier is trapped is checked in a LUT.
• 5. The Weighting (Ramo) potential for the initial position (creation) and final (trapped) position of

the charge carrier is checked in a LUT.

• 6. And hence the induced signal up to the point of trapping is calculated and added to the

chargedDiodes collection.

• 7. The effect of moving charge carriers on neighboring pixels (i.e. charge sharing) is also

provided from an LUT.

Rad damage: step-by-step

Step 5: Trapping and LUTs

RMD Carney 18/03/16

Ramo (weighting field)??

11

What did we assume? How is this better?

• 1. The Electric field determines the charge trajectory and velocity. Neither of these have

anything to do with the weighting field, so if you want to know them at a particular point you must go through the entire process using Gauss’s law, etc.

• 2. The weighting field depends only on the geometry of the electrodes and determines

how the charge’s motion couples to a specific electrode to induce a signal.

• 3. Only in 2-electrode configurations are the weighting field and Electric field the same

shape (and they are still only proportional not identical)![2]

First, some key points

So, that’s what this picture is! It’s the weighting field for a pixel. It’s interesting because it shows that the majority of contribution to the signal is localized directly under the pixel.

The weighting field for smaller electrodes is weird

Weighting potential: 2 ∞-planar electrodes Weighting potential: ∞ strip Weighting potential: A single pixel

RMD Carney 18/03/16

12

Subtitle

• 1. From the electric field at the charge carrier’s starting depth and the mobility of the charge

carrier: the time-to-electrode is looked up (LUT).

• 2. The drift time of this particular charge chunk is also calculated - this involves the probability

that the charge will be trapped and is dependent on fluence.

• 3. If the drift time < time-to-electrode, the charge is trapped.
• 4. The depth at which the carrier is trapped is checked in a LUT.
• 5. The Weighting (Ramo) potential for the initial position (creation) and final (trapped) position of

the charge carrier is checked in a LUT.

• 6. And hence the induced signal up to the point of trapping is calculated and added to the

chargedDiodes collection.

• 7. The effect of moving charge carriers on neighboring pixels (i.e. charge sharing) is also

provided from an LUT.

Pixel digitizer: step-by-step

RMD Carney 18/03/16

13

• 1. From the electric field at the charge carrier’s starting depth and the mobility of the charge

carrier: the time-to-electrode is looked up (LUT).

• 2. The drift time of this particular charge chunk is also calculated - this involves the probability

that the charge will be trapped and is dependent on fluence.

• 3. If the drift time < time-to-electrode, the charge is trapped.
• 4. The depth at which the carrier is trapped is checked in a LUT.
• 5. The Weighting (Ramo) potential for the initial position (creation) and final (trapped) position of

the charge carrier is checked in a LUT.

• 6. And hence the induced signal up to the point of trapping is calculated and added to the

chargedDiodes collection.

• 7. The effect of moving charge carriers on neighboring pixels (i.e. charge sharing) is also

provided from an LUT.

Pixel digitizer: step-by-step

Step 5: Induced charge contribution

RMD Carney 18/03/16

Pixel Digitization: workflow

14

Rough (relevant) workflow: Pixel digitization

PixelDigitization PixelDigitizationTool::processAllSubEvents() (PDT)::digitizeNonHits() (PDT)::digitizeAllHits() (PDT)::createAndStoreRDO() (PDT)::createRDO() (PDT)::digitizeElement() SurfaceChargeTools::process() <Technology>::charge() (PDT)::applyProcessorTools()

In PDT::initialize(), all of the tools and services are linked and added by ‘StoreTool()’ and ‘retrieve()’ and then an ‘add’ function that calls the process() method in each tool. Only SurfaceChargeTools does not get added at this stage. The <Technology> is the specific element type, e.g. PixelECChargeTool, Ibl3DChargeTool, etc. Each of these classes contain a ‘charge()’ method that adds diffusion, propagates the charge in steps, and adds sensor efficiency maps (if necessary). applyProcessorTools() calls the various services that add to the signal (noise, ‘smearing’), and also pass the analog signal through a discriminator. The PDT::createRDO method is where mask/sub-threshold/disabled-element/corrupted flags are applied and where ToT is calculated via a call to CalibSvc.

RMD Carney 29/02/16

15

Athena structure

applyProcessorTools() calls an instance of each derived class of ISiChargedDiodesProcessorTool interface: all of which are the discriminator/noise/crosstalk tools! A service serves many clients, a tool only one. A service typically has one instance but a tool may have many. It is appropriate that we use a tool for this work.

Pixel digitizer: tools in Athena

RMD Carney 18/03/16

RadDamage Tools

16

Additional charge tool and utility

Introduction

The Allpix team have produced a standalone test bench for, among other things, a digitizer that models the effects of radiation damage in Silicon: notably by considering the effects of trapping and partial signal loss that comes with it, as well as charge sharing. I’ve been tasked with migrating the relevant parts of that digitizer into Athena.

class IblPlanarRadDamageTool : SubChargesTool

Creates the analog signal using overloaded charge() method from base class. Format is almost identical to equivalent unirradiated uniform & Bichsel versions but includes some checks for trapping.

class RadDamageUtil : AthAlgTool

A collection of function used to calculate the radiation damage effects and process trapping/induced current. Like Bichsel, a separate tool is needed as these calculations are independent of sensor geometry and conditions - parameters can be fed in as arguments (e.g. pointer to Ramo weighting map and sensor bias). Two classes added to: InnerDetector/InDetDigitization/ PixelDigitization/ This first draft only includes a class for the IBL planar modules but it seems feasible (given that the classes are near identical) that I can produce the equivalent for the Pixel Barrel/EC as well. The IBL 3D models in Allpix are not yet ready but are a tiny fraction of the detector anyway.

RMD Carney 18/03/16

Gitlab: radDamage_athena_20.21

17

Follow progress + leave comments & suggestions!

Have a runnable ‘empty shell’ tool to make sure the structure makes sense Adapt the code for athena Include conditionsDB values and fluency maps. Validate functionality through full chain. Check tags work.

Todo list

https://gitlab.cern.ch/radiationDamageDigitization/radDamage_athena_20.21

RMD Carney 18/03/16

Conditions

18

Accessing information

Calculations depend on fluence: this will change both over the course of the simulation. We will also need to take into consideration any LS or periods of no cooling as annealing will change the effective fluence. Currently (from what I can see in the code) the mobility of the charge carriers does not feature in the ChargeTools. 
 The rad damage calculations need to access certain data about charge carriers (temperature of module to calculate the Lorentz angle and also the probability of being trapped). There is a service (via Simone) at InnerDetector/InDetConditions/SiLorentzAngleSvc/ src/SiLorentzAngleSvc.cxx - perhaps it would be worth adding a separate function for holes and electrons?

RMD Carney 18/03/16

What are our next steps?

19

Next steps

Usability: simple flag in python reco_tf (et. al.), something like: - - withRadDamage , so all fluency and conditions need to be passed to the class in the background! 
 John Chapman set this tag up this morning! Need to put LUT (In the form of TH1/TH2/TH3 i.e. c-arrays) in a common area. Zach suggests: 
 http://acode-browser.usatlas.bnl.gov/lxr/source/atlas/External/AtlasDataArea/cmt/ requirements End-to-end validation:

• the code currently compiles using Athena rel. 20.7.3.8.
• Need to make sure it can be merged with other intended changes for rel. 20.21
• Physics validation also needed of course, suggestions welcome: google doc link

Thanks!