KAHIBARO
8.5. Detector Arrays
Table of Contents
Repeating detector elements
Many detector systems consist of many identical elements. Examples include calorimeter cells, silicon strips, pixel sensors, and scintillator bars. In Geant4 you rarely want to copy and place each element by hand, because this is error prone and slow to simulate. Instead, you describe a single detector element once, then reuse it many times in a regular pattern.
The essential idea is to define one solid and one logical volume that represent a single detector cell. This cell can then be instantiated many times as physical volumes. For simple regular structures, you can use replica or parameterized volumes, which are discussed in more detail in the repeated geometry section of this course. Detector arrays are a special and very common use of those techniques.
For a one dimensional array, for example a row of identical strips, you can think of the array as a mother volume that contains many children, each child being one strip. The mother logical volume is filled completely and regularly by the repeated children. For two or three dimensional arrays, for example a matrix of crystals, you often build the structure hierarchically. You might create one row of crystals as a repeated structure along $x$, then repeat that row along $y$ to form a 2D array. In all these cases the geometry hierarchy is important. Each repeated element is a daughter of some mother logical volume, and its position is defined relative to that mother.
When you build an array, you must still keep the rules of geometry in mind. Each element must fit inside the mother volume, there must be no overlaps between adjacent elements, and the world volume must be large enough to contain the entire array. In practice, you choose the size of each cell, choose how many cells you need in each direction, then compute the mother volume size from these numbers. The placements of the individual cells can be computed from their index in the array. This indexing is also what you will later use for detector IDs.
Any regular pattern is a candidate for a detector array. For example, a simple 1D bar array could have its $i$-th bar center at position
$$x_i = \left(i + \tfrac{1}{2}\right) \, p$$
where $p$ is the pitch, that is, the center to center distance, and $i$ runs from $0$ to $N - 1$ for $N$ bars. For a 2D grid with indices $i$ and $j$ and pitches $p_x$ and $p_y$, a common choice is
$$x_{i,j} = \left(i + \tfrac{1}{2}\right) p_x - \tfrac{1}{2} N_x p_x,$$
$$y_{i,j} = \left(j + \tfrac{1}{2}\right) p_y - \tfrac{1}{2} N_y p_y,$$
so that the array is centered around the origin of the mother volume. You can implement these formulas in whatever positioning mechanism you use.
When you use parameterized volumes, Geant4 will ask your parameterization class for the position and dimensions of each copy, identified by its copy number. The copy number is a simple integer from $0$ to $N - 1$, and you can map it to indices like $(i, j)$ with integer arithmetic, for example
$$i = \text{copyNumber} \bmod N_x,$$
$$j = \left\lfloor \frac{\text{copyNumber}}{N_x} \right\rfloor.$$
This is useful when you design rectangular arrays where the total number of cells is $N_x \times N_y$. The logic is symmetric: you use the index to compute the position when building the geometry, and later you use the same relationships in your sensitive detector code to turn a copy number back into an $(i, j)$ pair.
You should treat the detector array as a geometrical object that hides the internal repetition. Outside code should not worry about the details of how many volumes there are or their exact positions. Instead, it should only care about the identification of a cell, its material, and its response. If you arrange your geometry hierarchically and keep the array logic inside a small number of classes, it becomes much easier to modify the number of elements or their spacing without changing the rest of the application.
Finally, when you build a very large detector array, you should think about performance and memory. Hundreds of thousands of individual placements can slow down geometry navigation. Replicas and parameterized volumes are specifically designed to keep the memory footprint small and the navigation efficient. For beginners, it is enough to know that such tools exist and that a detector array should almost always be built from a single logical cell repeated many times, not from many independent copies of the same cell.
A detector array should be built from one shared logical volume that is reused many times as physical volumes. Avoid creating many separate logical volumes with identical shapes and materials, because this wastes memory and slows down the simulation.
Detector IDs
Once you have a detector array, you need a way to know which individual element recorded a hit. In Geant4 this is done with detector IDs. An ID is an integer or a small set of integers that uniquely identifies one detector element among all elements of the array.
The simplest type of detector ID is the copy number of the physical volume. Every physical volume in Geant4 has an integer copy number, which can be assigned explicitly in placements or comes from the index in a replica or parameterized structure. When a particle deposits energy in a sensitive volume, you can retrieve this copy number from the step, and use it as the detector ID. For a one dimensional array, this often is enough. For example, if you have 100 strips, and copy numbers from 0 to 99, then the copy number itself is the strip ID.
In more complex geometries, the detector element identity may be defined by several indices, for example row and column in a matrix, or sector, layer, and cell in a tracking detector. In such cases you can either store each index separately or encode them into a single integer. There is no strict rule. The important requirement is that the mapping between geometry and IDs is consistent and easy to recover in analysis.
A convenient approach is to define a small integer geometry for each array. For a rectangular grid with $N_x$ columns and $N_y$ rows, you can encode a unique ID as
$$\text{ID} = j \cdot N_x + i,$$
where $i$ is the column index and $j$ is the row index. This is exactly the same arithmetic that Geant4 uses to map copy numbers to positions, and you can store $i$ and $j$ separately if that is helpful. The choice of mapping is up to you, but you must document it clearly, because it defines the connection between simulation and later data analysis.
The volume hierarchy also plays a role. In many detectors the same copy number is reused at different levels. For example, a module may contain crystals numbered from 0 to 9, but there may be many identical modules. To uniquely identify a crystal, you need the module index and the crystal index. Geant4 offers the concept of a touchable history, accessible from the pre step point. The touchable stores the full path from the world volume to the current volume, including the copy number at each level. By asking the touchable for the copy number at a given depth, you can reconstruct all indices that define your detector element.
Because detector IDs are central to later analysis, it is useful to decide on a naming and numbering scheme before you build the geometry. You can also store the ID structure directly in the hit class. For example, a hit might contain the total encoded ID, but also separate fields like layer, row, and column. This redundancy makes the downstream analysis clearer, especially in large projects where many people need to understand the mapping.
Geant4 does not enforce any specific ID scheme, but you must follow some practical rules to avoid confusion and errors.
Detector IDs must be unique, stable, and well documented. Do not change the ID scheme after generating data, and ensure that two different detector elements can never share the same ID in the same simulation.
In practice, you will often combine the geometry indexing and the ID scheme during detector design. When you choose the number of elements, their grouping into modules, and their placement, you should at the same time choose how indices like module, layer, row, and column are numbered, and how they are converted into integer IDs. If you maintain this consistency, your detector array will be straightforward to simulate and to analyze.
Views: 9