3D Implants, Many
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 eitherfrontsize
for an implant from the sensor front side, collecting charge carriers, or tobackside
for an implant connected to the ohmic contact at the sensor back side. -
shape
: Shape of the implant, supported shapes arerectangle
andellipse
. Defaults torectangle
. -
size
: The size of the implant as 3D vector with size inx
andy
as well as the implant depth. Depending on the implant shape, thex
andy
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 itsz
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 to0, 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.
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 aG4IntersectionSolid
between the pixel cell and the implant volume. With this, theG4MultiUnion
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 multipleG4MultiUnion
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
This fixes #65 (closed)