28.2. Checking Geometry

Why Geometry Checking Matters

Geometry mistakes are among the most common and most frustrating problems in Geant4. A tiny overlap, a misplaced rotation, or a wrong hierarchy can silently distort your physics results. Before trusting any simulation output, you should deliberately test and validate the geometry.

Geometry validation focuses on two questions. First, is the geometry internally consistent for the Geant4 kernel, with no overlaps or illegal configurations. Second, is the geometry the one you actually intended to build, with the right dimensions, positions, and materials.

In practice, you will combine visual inspection, built‑in overlap checks, and simple physical tests to gain confidence in your setup.

Visual Inspection of the Geometry

The first line of defense is to look at the geometry in a viewer. Visualization will not prove correctness, but it will often reveal large mistakes quickly.

After you have constructed your geometry and initialized the run manager, open a visualization driver and draw your geometry. For example, with OpenGL and a typical interactive session, you can use macro commands like /vis/open and /vis/drawVolume. In your first checks, show only a few key volumes instead of the full detector, for instance the world, the main detector, and a shielding layer. This avoids clutter that can hide problems.

Carefully inspect positions and orientations. If you place a cylindrical detector that should be centered on the beam axis, confirm that its center coincides with the origin or the intended point. If you rotate a volume, look at the geometry from several viewpoints to make sure the rotation is applied as expected.

Use visualization attributes to make inspection easier. Transparent outer volumes can reveal whether inner volumes are fully contained. Wireframe views often make overlaps or gaps easier to see than solid rendering. You can also temporarily enlarge or simplify some volumes in your code to exaggerate and reveal possible problems, then restore the correct dimensions once you are satisfied.

Visual inspection has limitations. Fine overlaps can be smaller than a pixel, and complex nested structures are hard to judge by eye. This is why you must complement visualization with programmatic checks.

Using Built‑in Overlap Checking

Geant4 provides automatic overlap detection when you construct physical volumes. Many placement constructors have an optional pSurfChk flag as their last argument. If you set this flag to true, Geant4 will test for overlaps between the new volume and its neighbors.

For example, when you create a placed volume:

auto phys = new G4PVPlacement(
  rotation,               // rotation matrix, or nullptr
  position,               // translation
  logicalVolume,          // logical volume to place
  "Detector",             // name
  motherLogical,          // mother volume
  false,                  // no boolean operation
  copyNumber,             // copy number
  true                    // pSurfChk: enable overlap check
);

With pSurfChk set to true, Geant4 samples points on the surface of the placed volume and checks whether these points are inside any other solid in the same mother volume. If an overlap is found, it prints diagnostic messages to standard output, including the name of the overlapping volumes and an estimate of the overlap depth.

You can also control more global geometry checks through the geometry manager and related commands. This lets you run deeper or repeated checks after construction. Overlap checking can be costly in CPU time if you have many volumes, but for validation runs this cost is usually acceptable.

Checking for Overlaps with Commands

In addition to per‑volume pSurfChk, Geant4 provides user interface commands to probe overlaps in a more systematic way. These are particularly useful for complex geometries or when you want to test volumes without recompiling.

One common approach is to use the command interface to sample points on a solid and test for overlaps. You can choose a specific physical volume by name and ask Geant4 to generate a number of random points on its surface. For each point, Geant4 checks whether that position lies within more than one volume at the same hierarchy level.

You typically proceed in three steps. First, initialize the run and geometry. Second, select the target physical volume in your macro. Third, run the overlap test with a chosen number of points and a tolerance. The tolerance defines how close two surfaces can be before they are treated as overlapping. For very tight geometries you may need to reduce this value, but be aware of numeric precision limits.

If overlaps exist, Geant4 prints messages that include the names of the overlapping volumes and a representative point where the problem occurs. Taking note of these names and positions will guide you to the corresponding placements in your DetectorConstruction class.

You can repeat these checks after each modification of the geometry. For example, if you are building a complex detector array, run overlap checks after adding a new layer or submodule. This incremental approach makes it much easier to identify which change introduced a problem.

A useful strategy is to automate some checks in your standard initialization macro. Add commands that perform overlap tests on your most important volumes. When you run a new build, you immediately see warnings in the console if something is wrong, without needing to remember to run checks manually.

Debugging Overlapping Volumes

Once an overlap is reported, you need to interpret the messages and fix the underlying cause. Overlaps usually come from one of a few typical sources: incorrect dimensions, inconsistent half‑lengths, coordinate mistakes, or imprecise rotations and translations.

Start by locating the individual G4PVPlacement or boolean solid creation in your DetectorConstruction that corresponds to the reported volume names. Compare the intended geometry with the parameters you actually used. For example, if you expect a volume to sit exactly against another without overlap, the sum of their half‑lengths along that axis must exactly match the separation of their center positions.

You can use simple algebra to reason about possible overlaps. Suppose two boxes share a mother volume, are aligned along the x axis, and are intended to be just touching. Let the first box have half length $a$ along x and center at $x = 0$. Let the second have half length $b$ and center at $x = a + b$. If you accidentally use $x = a + b - \epsilon$ for the second center, you create an overlap of depth $\epsilon$. The overlap checker will report this as a problem.

To debug, it often helps to temporarily exaggerate positions or sizes. Increase the suspected overlap by making one dimension clearly larger, recompile, and inspect the geometry visually. Once you are sure where the conflict lies, restore the correct dimensions with more care.

Rotations can be a more subtle source of overlaps. If you build a ring of detectors, small numeric errors in rotation angles or radii can make end volumes intrude into neighbors. In such cases, derive positions and angles from a single set of parameters and compute them programmatically, instead of hard coding slightly inconsistent values.

Geant4 prints a suggested overlap depth. This is an estimate based on the sampled points and is not exact, but it can give you a sense of scale. Overlaps comparable to or larger than the tracking step size are clearly dangerous. Even much smaller overlaps can confuse navigation, so aim to eliminate them rather than relying on their smallness.

Checking Volume Hierarchy and Containment

Correct geometry is not just about avoiding overlaps. The hierarchy and containment of volumes must also match your design. A volume must always be fully contained inside its mother volume. If any part lies outside, navigation may fail, and particles can be incorrectly transported.

When you define a solid and then place it as a physical volume, check that its maximum extent along each axis is smaller than the corresponding dimension of its mother. For axis aligned boxes, this means that the sum of the absolute value of the translation and the half length must be less than the mother half length. Concretely, for a box with half length $h$ inside a mother with half length $H$, and center offset $x_0$ along x, you should satisfy
$$
|x_0| + h \leq H.
$$
If this condition is violated by any coordinate, part of the volume falls outside the mother.

For other primitives such as tubes and spheres, use the outer radii and angular spans in a similar way. For example, a cylindrical volume with outer radius $r$ must lie within the mother radius or within its half lengths, depending on the chosen orientation.

Mathematically consistent hierarchy does not guarantee physical correctness. You must also check that the hierarchy reflects your detector concept. Inner detector elements should be children of the correct support structures, and sensitive volumes should not be assigned as mothers of structural components by mistake. You can use your detector diagram as a guide and compare it to the scene graph that Geant4 effectively constructs.

In some setups you will use assemblies or parameterized volumes. In that case, validate the contour of the whole assembly. Ensure that the assembled structure still fits within the intended mother volume and that parameterized placements do not exceed expected bounds. For example, the product of the number of repetitions and the pitch must not extend beyond the parent dimension.

Verifying Dimensions and Materials

Geometry validation also includes checking that each volume has the intended size and material. A mis‑typed unit or wrong constant can produce a detector that is off by orders of magnitude, which will invalidate all results even if no overlaps occur.

In Geant4, you usually specify dimensions with unit multipliers, such as 5cm or 10mm. If you accidentally use cm instead of mm, a volume can expand by a factor of ten. To catch such mistakes, systematically review your dimensions in the DetectorConstruction and compare them to your design document or drawings.

You can programmatically print diagnostic information at construction time. For example, after creating a G4Box, you can print its half lengths and the material name of the corresponding logical volume. Combine this with unit handling to obtain human readable outputs. A simple strategy is to add a method that loops over key volumes, retrieves their sizes and materials, and writes them to the log during initialization.

Materials can also be misassigned. If you use the wrong material pointer when constructing a logical volume, or if you search for a NIST material with a misspelled name, your detector might be built out of air instead of lead, or vice versa. Check all calls to G4LogicalVolume constructors and confirm that the material arguments are what you expect.

A useful consistency check is to use the geometry viewer to color volumes by material. Assign a distinctive color to each critical material, such as bright blue for water or dark gray for lead. Then visually inspect the geometry to see whether the colors appear in the correct regions. This is often faster and more intuitive than examining code alone.

Simple Physics Tests to Probe Geometry

After structural checks, run a few simple physics tests to probe the geometry behavior. The goal is not to validate the full physics model, but to confirm that particles move through the detector as intended, and that boundaries and regions are where you think they are.

One basic test is to send a monoenergetic pencil beam through your setup along a known direction, for example along the z axis, with no scattering physics or with minimal processes enabled. Record the positions where tracks enter and exit key volumes. If the geometry is correct, these crossing points should match the expected boundaries given by your dimensions.

For a homogeneous slab of thickness $d$, you can check that the path length inside the slab is close to $d$ for straight tracks. In other words, if a particle starts just before the front surface and travels perpendicularly, the difference between the positions at the entrance and exit along the beam axis should be $d$:
$$
L_{\text{slab}} \approx d.
$$
If you observe systematically shorter or longer path lengths than expected, this may indicate misplaced surfaces or incorrect thickness.

Another test is to look at the material sequence encountered by a track. You can print the material names at each step or boundary for a small number of particles. The sequence should match your mental picture, for instance air, then entrance window, then scintillator, then reflector, and so on. Any unexpected material in the sequence may reveal wrong mother volumes or misplaced components.

You can also use energy deposition patterns to probe geometry qualitatively. For example, in a layered structure, the fraction of energy deposited in each layer should roughly follow their thicknesses and material properties. While this is a physics dependent quantity, gross inconsistencies can hint at geometry problems.

By combining visual checks, overlap detection, hierarchy verification, and simple physics probes, you build a consistent picture of your geometry. Only when this picture is stable and aligned with your design should you proceed to detailed physics validation and quantitative analysis.

Views: 8