DetectorField: Perform Field Lookup on Per-Pixel Basis

This MR fundamentally changes how we perform the lookup of field values (electric field, doping profile, weighting potential).

Status quo

Currently, the respective field is replicated in regular patterns over the full pixel matrix, ignoring the position of individual pixels. Offset and size parameters control how large they are and how they are aligned with respect to the local coordinate system.

This has worked fairly well and allowed for a flexible assignment of fields to pixels, but it immediately breaks down when going to other pixel patterns (staggered rectangles, hexagons, ...).

Changes implemented in this MR

This MR changes how field values are looked up. The offset parameter is replaced by a mapping parameter which indicates how the provided field should be mapped to the pixel. The following figures and explanation is taken from the updated user manual:

Depending on the symmetries of the pixel unit cell and the pixel grid, different geometries are supported. The field for a quarter of the pixel plane (a), for half planes (b) as well as for full planes (c). The size of the field is not limited to a single pixel cell, however, for some quantities such as the electric field only the volume within the pixel cell is used and periodic boundary conditions are assumed and expected. Larger fields are for example useful for the weighting potential, where also potential differences to neighboring pixels are of interest.

A special case is the field presented in (d). Here, the field is not centered at the pixel unit cell center, but at the corner of four adjacent rectangular pixels.

The parameter field_mapping of the respective module defines how the map read from the mesh file should be interpreted and applied to the cell, and the following possibilities are available:

• field_mapping = FULL - the map is interpreted as field spanning the full Euclidean angle and aligned on the center of the pixel unit cell. No transformation is performed, but field values are obtained from the map with respect to the pixel center.
• field_mapping = FULL_INVERSE - the map is interpreted as full field, but with inverse alignment on the pixel corners as shown above. Consequently, the field value lookup from the four quadrants take into account their offset.
• field_mapping = HALF_LEFT - the map represents the left Euclidean half-plane, aligned at the y axis through the center of the pixel unit cell. Field values in the other half-plane are obtained by mirroring at the y axis as indicated in (a).
• field_mapping = HALF_RIGHT - the map represents the right Euclidean half-plane, aligned at the y axis through the center of the pixel unit cell. Field values in the other half-plane are obtained by mirroring at the y axis as indicated in (b).
• field_mapping = HALF_TOP - the map represents the top Euclidean half-plane, aligned at the x axis through the center of the pixel unit cell. Field values in the other half-plane are obtained by mirroring at the x axis as indicated in (c).
• field_mapping = HALF_BOTTOM - the map represents the bottom Euclidean half-plane, aligned at the x axis through the center of the pixel unit cell. Field values in the other half-plane are obtained by mirroring at the x axis as indicated in (d).

• field_mapping = QUADRANT_I - the map represents the quadrant of the plane where both vector components have a positive sign. Field values in the other three quadrants are obtained by mirroring at the axes of the coordinate system as show in (a).
• field_mapping = QUADRANT_II - the map represents the quadrant of the plane where the vector component x has a negative and y a positive sign. Field values in the other three quadrants are obtained by mirroring at the axes of the coordinate system as show in (b).
• field_mapping = QUADRANT_III - the map represents the quadrant of the plane where both vector components have a negative sign. Field values in the other three quadrants are obtained by mirroring at the axes of the coordinate system as show in (c).
• field_mapping = QUADRANT_IV - the map represents the quadrant of the plane where the vector component x has a positive and y a negative sign. Field values in the other three quadrants are obtained by mirroring at the axes of the coordinate system as show in (d).

All axes mentioned here are Cartesian axes aligning with the local coordinate system of the sensor and passing through the center of the pixel unit cell regarded. It should be noted that some of these mappings are equivalent to rotating or mirroring the field before loading it Allpix Squared, and are only provided for convenience.

Open issues / discussion points

• This new system is much more flexible and will also allow for hexagonal pixels and their fields - but it cannot reproduce one feature the old system had: since we only mirror fields within the pixel cell, we cannot simulate e.g. even/odd pixel columns with reversed electric fields. Or, more generally speaking: no electric fields larger than single pixel can be used (well, they can be used but the outer part extending beyond the pixel won't ever be looked at). Is this a problem? How could we re-introduce the possibility similar to this without creating a configuration mess?

• Currently, the size of the field is treated differently in different reader modules:

  • In the DopingProfileReader and ElectricFieldReader, the size of the field is user-defined via the field_size parameter in units of the pixel pitch
  • In the WeightingpotentialReader, the field extent is calculated automatically from the physical extent in microns found in the field file and the pixel pitch.

  I think both are viable options and we could think of defaulting to something sensible? My suggestion would be to - by default - take the physical extent from the field map file and allow overwriting that value with field_size. That would also avoid having to specify both

  field_mapping = QUADRANT_III
  field_scale = 0.5 0.5

  in order to get proper mapping of the field to a quarter pixel.

• Testing with all different options. @asimanca agreed to produce the relevant TCAD fields and @hwennlof to test them all out. Thanks! ❤

• Eventually we should get !350 going and then also add proper tests for all the field loading and usage with the nice reference fields from @asimanca. I'd leave this for a future MR.

• Feedback from @rmunker and @kdort would be appreciated - does this work for your current use case?

• Fix the annoying issue with the LaTeX compilation of the user manual