Contact: Noah Kurinsky or Michael Kelsey
Introduction
The SuperCDMS Collaboration has used finite-element solvers (COMSOL, FEniCS) to generate models for the electric fields in the various CDMS detector crystals, surrounding space, and full detector stacks. The output of these solvers is meant to be read into the CDMS detector simulation, and used to control the trajectories and acceleration of the charge carriers from their production in energy deposits to the pickup electrodes on the detector faces. The details of the CDMS solvers are part of the Collaboration's internal documentation; this documentation has been adapted from those resources.
The charge example in the G4CMP repository demonstrates how to use an electric field mesh file with the G4CMP management classes for a device modelling charge transpoert.
Finite Element Mesh
The mesh of control points for the model should be constructed in three dimensions using either the full details of the electrode structure (obtained from lithography masks, for instance) or with simplifications to the electrodes where necessary. (There is support for a 2D axisymmetric mesh, but it has not been fully validation and has some known problems.) The mesh produced will in general not be a Delaunay triangulation, because you will be imposing constraints (such as constant voltage along electrodes or ground plane) which preclude some possible mesh simplices (tetrahedra or triangles). Consequently, for input to G4CMP, we require both the list of vertices, with the computed potential at each vertex, as well as the table of simplices generated by the meshing code from those vertices.
The original design of the G4CMP mesh handling class (G4CMPTriLinearInterp) used only the list of vertices as input, and constructed its own triangulation using QHull. This resulted in incorrect field behaviour, and hence incorrect particle trajectories, especially in the important region close to electrodes. Releases of G4CMP since Sep 2018 (V04-02-00) support passing both the vertex list and the table of simplices (tetrahedra) to avoid this situation.
Some experiments, including SuperCDMS, require normalized electric field meshes for each electrode individually (so-called "Ramo potential" models) in order to compute Shockley-Ramo pickup on electrode sensors. This is not directly implemented as part of G4CMP, and is the responsibility of the end user. COMSOL can produces tabulations of different electrode settings for the same optimized mesh, which can simplify this complication. The CDMS simulation, for example, uses a single shared instance of the mesh vertices, and updates the mesh handler as needed with the tabulated voltages for each normalized electrode. The total field is computed by multiplying each normalized electrode table by the actual voltage bias applied to that electrode, and summing them at each vertex.
Local vs. Global Electric Fields
Geant4 does all of its particle transport work in the global (World) coordinate system. COMSOL, or other finite element software, will produce the mesh using some local coordinate system for a single device. If you are modelling a single chip in isolation, the two frames will coincide, and you can just use the finite element coordinates directly. In general, for devices which are incorporated into housings, cryostats, or a large, multi-detector apparatus, the local and global coordinate systems are entirely different. G4CMP provides support for for handling this with its own G4CMPFieldManager and G4CMPLocalElectroMagField subclasses.
The field manager will wrap a registered "ordinary" field object in the "local field" class; at the start of tracking, it uses the track's touchable so that global coordinates can be transformed to local coordinates for interrogating the field model; the field manager also retrieves the G4LatticePhysical associated with the track's volume, and configures the EquationOfMotion instance to handle oblique electron transport correctly.
Text File Format from COMSOL
The sections below describe the file formats used with the SuperCDMS simulation, which may be a useful guide to other experiments. The format we have chosen aligns with the format exported by COMSOL, so no post-processing is required. Careful handling of the units associated with each column of data is vital, to ensure that you pass into G4CMPTriLinearInterp (and thence to Geant4) valid quantities for modelling your device.
Vertex and Potential Data
The points file format consists of zero or more comment lines beginning with '%', and containing information about the production of the file (software version, username, date, etc.). After the comments, the file should start with a non-commented column header line delimited with tabs:
X Y Z Qo0 Qi0 Qo1 Qi1 PTOP PBTM
For a full three-dimensional mesh, the first three columns are the coordinates of the mesh point, with the bottom face of the crystal at Z=0, and in units of meters. For an axisymmetric two-dimensional mesh, only the first two columns are coordinates, and the header line should contain "R Z" instead of "X Y Z".
Each subsequent column is the Ramo potential for the named electrode in normalized units (0 to 1 V). The Ramo potential is computed by modelling the detector with that electrode set to 1 V, and all other electrodes at ground (0 V). To produce this data, the _same mesh_ must be used for each electrode calculation. Here is an example, generated with COMSOL for the SCDMS Soudan "iZIP5" dark matter detector:
% Model: iZIP_extra.mph % Version: COMSOL 5.2.0.220 % Date: Aug 10 2018, 01:00 % Dimension: 3 % Nodes: 268533 % Elements: 1526087 % Expressions: 6 % Description: Electric potential % Length unit: m % Coordinates % Data (V (V) @ 1: Vit=1, Vot=0, Vib=0, Vob=0, Vpt=0, Vpb=0) % Data (V (V) @ 2: Vit=0, Vot=1, Vib=0, Vob=0, Vpt=0, Vpb=0) % Data (V (V) @ 3: Vit=0, Vot=0, Vib=1, Vob=0, Vpt=0, Vpb=0) % Data (V (V) @ 4: Vit=0, Vot=0, Vib=0, Vob=1, Vpt=0, Vpb=0) % Data (V (V) @ 5: Vit=0, Vot=0, Vib=0, Vob=0, Vpt=1, Vpb=0) % Data (V (V) @ 6: Vit=0, Vot=0, Vib=0, Vob=0, Vpt=0, Vpb=1) X Y Z Qi1 Qo1 Qi2 Qo2 PTOP PBTM -0.04363588866000002 7.825678365184781E-4 0 0 0 0 0 0 0 -0.04363588866000001 -7.484153970666152E-4 0 0 0 0 0 0 0 -0.04363588866000001 1.7360546518841585E-6 0.02609693457167141 0 0 0 0 0 0 -0.04363588866000001 7.825666341187424E-4 0.025404086000000003 0 0 0 0 0 0 -0.04363588866000001 0.0012041852305748877 0.026091756646233026 0 0 0 0 0 0 [...]
Simplices (Tetrahedra or Triangles)
The simplices file format also has comment lines (% ...) at the top, but does not require a column header line. Each row of data contains four integer (or three integers for the 2D axisymmetric case) numbers, correponding to the vertices which make up a single tetrahedron in the mesh. Files generated from COMSOL have the vertices counted from 1 to N; other software, such as FEniCS, may count the vertices from 0 to N-1. Either method is acceptable, and will be detected by the data reader.
Here is an example for the same SCDMS Soudan "iZIP5" detector, produced with COMSOL/FORTRAN-style numbering:
% Model: iZIP_extra.mph % Version: COMSOL 5.2.0.220 % Date: Aug 10 2018, 01:00 % Dimension: 3 % Nodes: 268533 % Elements: 1526087 % Expressions: 6 % Description: Electric potential % Length unit: m % Elements (tetrahedra) 149232 146584 148360 149876 139324 139258 139209 137365 140297 139258 141101 142980 139324 139209 139258 141678 145652 146584 144431 142980 [...]
Coordinate Frame, Units, and Index Handling
As noted earlier, Geant4 has built-in assumptions around the quantitative data related to the electric field. It is up to the user's application to ensure that all of those assumptions are satisfied, and that the field model being used matches reality.
Coordinate Frame
When setting up the geometry for meshing in COMSOL, FEniCS or other finite element software, the user may specify an origin of coordinates which is more convenient for engineering, such as Z=0 at the bottom face of a detector, or (0,0,0) at the lower right corner. Geant4 solids, especially simple ones such as parallelpiped (G4Box) and cylinder (G4Tubs) have their origin of coordinates at the center of the volumes, and Z is upward (e.g., along the axis of the cylinder). It can make handling the mesh files simpler for the user application if the mesh coordinate frame is aligned with the Geant4 solid to which it will apply; if that is not the case, the user input function must apply appropriate coordinate transforms.
Units
The text file output by COMSOL includes comment lines (see above) which indicate the units for the mesh coordinates and for the potential(s) at each mesh point. A sophisticated input function could parse those comment lines to pick up the unit names, and call G4UnitDefinition::GetValueOf() to convert the name string to G4 units. Or the user application could impose a requirement on the text file, and assume particular units which it multiples each value read in.
Vertex Index Handling
The G4CMPTriLinearInterp class takes three std::vector arguments, for the coordinates (std::array<G4double,3>), potentials, and mesh simplices (std::array<G4int,4>). The indices stored in the simplices array must match the indexing (0 to N-1) used for the std::vectors of coordinates and potentials. COMSOL generates those indices from 1 to N (FORTRAN style), while FEniCS generates C-style indices from 0 to N-1. It is the responsibility of the user input function to apply the necessary offset (for CDMS, we read in the simplices as is, scanning to find whether the smallest index is 0 or 1, then apply a subtraction to the filled vector of arrays if necessary).