Skip to content

3D Implants, Many

Simon Spannagel requested to merge implant_class into master

This MR is a complete rework of !583 (closed) with a different approach. Instead of defining a single implant as part of the detector model, it is now possible to define as many implants as necessary, in a similar fashion as currently implemented for support layer:

type = "monolithic"
number_of_pixels = 3 3
pixel_size = 250um 50um
sensor_thickness = 50um

[implant]
type = frontside
shape = ellipse
size = 13um 13um 50um
offset = 62.5um 0
material = lead

[implant]
type = backside
shape = rectangle
orientation = 45deg
size = 10um 40um 25um
offset = -62.5um 0
material = silicon

The following parameters are supported:

  • type: Type of the implant. This parameter can be set to either frontsize for an implant from the sensor front side, collecting charge carriers, or to backside for an implant connected to the ohmic contact at the sensor back side.
  • shape: Shape of the implant, supported shapes are rectangle and ellipse. Defaults to rectangle.
  • size: The size of the implant as 3D vector with size in x and y as well as the implant depth. Depending on the implant shape, the x and y values are either interpreted as the side lengths of the rectangle or the major and minor axes of the ellipse.
  • orientation: Rotation of the implant around its z axis. Defaults to 0deg, i.e. the implant axes are aligned with the local coordinate system of the sensor.
  • offset: 2D values in the x-y plane, defining the offset of the implant from the center of the pixel cell. This parameter is optional and defaults to 0, 0, i.e. a position at the pixel center be default.
  • material: The material of this implant. Defaults to silicon.

This system should be rather flexible in defining different sensor geometries and also to support additional ohmic backside columns often found in 3D sensor designs. It should be noted, that the computing time increases with more implants as al of them need to be checked for collision with charge carriers during propagation.

In addition, this MR also contains the new functionality to properly interpolate positions both at the sensor surface but also at the implant surface. This is especially important when running transient simulations where the weighting potential might be largest very close to the surface. For box volumes (sensor, rectangular implants) the Liang-Barsky line clipping algorithm is implemented to provide fast and efficient intersection calculations. For ellipsoid implants, intersections with the cylinder and its caps are considered.

image

Open Issues

There are three areas which still need attention:

Geant4

The current way of excising the implants from the sensor material and back-filling them with the chosen material does not work properly.

  • The excising is done using a G4MultiUnion, but since implants can overlap between pixel cells (think of an ohmic column in the pixel corner) they individual implants should be calculated from a G4IntersectionSolid between the pixel cell and the implant volume. With this, the G4MultiUnion at least fails to render, not sure if tracking is fine.
  • The placement of the implant material used to be done using the same G4MUltiUnion, however either all implants have to have the same material or multiple G4MultiUnion objects would have to be used. The latter doesn't work since they then overlap - something daughter volumes are not allowed. Instead, right now individual implants are placed - an approach that does not scale with the number of pixels.

Validation

We used to have code checking for basic validation of the implant with respect to the chosen pixel size. Now all implant-related matters are handled in the base DetectorModel class - which is nice but leaves us with a problem:

In the constructor of the DetectorModel, pixel sizes have not yet been configured - this is something derived model classes have to perform for themselves. This means we cannot run implant validation in the constructor. This leaves us with two options:

  • Either re-implement the implant addition in every detector model class
  • Or add some post-constructor validation mechanism. This would include making the contructor private and adding a public static creation method which calls the constructor plus the validation method afterwards:
    template <class T> static std::shared_ptr<T> create(...) {
        static_assert(std::is_base_of<DetectorModel, T>::value, "DetectorModel is not a base");
        auto* t = std::make_shared<T>(...);
        t->validate();
        return t;
    }

Neither of them is particularly attractive.

Non-Rectangular Pixels

While the collision detection and all should be working ™️ without issues for radial strips or hexagonal pixels, the question is if the current implementation of implants is enough. We should review this (cc @rprivara )

This fixes #65 (closed)

Edited by Simon Spannagel

Merge request reports