30.3. Overlapping Volumes

Why Overlapping Volumes Are a Problem

In Geant4 every point in space must belong to one and only one physical volume, except at boundaries. When two or more placed volumes share a region of space, you have overlapping volumes. This violates a basic assumption of the geometry navigator and leads to ambiguous tracking.

Overlaps can cause particles to jump between volumes unpredictably, produce wrong step lengths, misassign material, and confuse sensitive detectors. In some cases tracking may even get stuck or terminate incorrectly. For a reliable simulation geometry, you must detect and fix overlaps early.

Overlaps are especially easy to introduce when you build complex geometries by hand, nest many volumes, or use Boolean solids without careful dimensions. Even if the simulation runs, you should not trust calculated energy deposition or dose until you have checked for overlaps.

Typical Causes of Overlaps

Overlaps usually arise from a handful of common mistakes that you can systematically look for.

A frequent cause is using inconsistent dimensions for nested volumes. For example a daughter volume that is too large for its mother volume in at least one direction will stick out, so some of its volume lies outside its parent. This is common when you change a mother size but forget to update all daughters.

Another standard mistake involves miscalculated translation or rotation. A volume may be positioned so that part of it leaves the mother or collides with another daughter. For example you space detector elements based on their width but forget a small gap or rounding error, so they overlap along a row or ring.

Boolean solids can also create overlaps indirectly. If the component solids themselves overlap or are placed so that the result of a union or subtraction intrudes into other volumes, you may end up with several volumes sharing the same region. Similarly an incorrect subtraction or intersection can leave a small unwanted piece overlapping a neighbor.

Copy and paste of placement code without adjusting indices or offsets often leads to repeated placements at identical or partially overlapping positions. Arrays of crystals or layers are particularly prone to this if the pitch does not match the physical size.

Finally, imported CAD or GDML geometries may contain small intersections, tiny gaps, or tolerances that Geant4 interprets as overlaps. Even if they seem visually acceptable, numerical precision and the Geant4 tolerance scale can expose hidden problems.

Using Geant4 Overlap Checks

Geant4 provides geometry checking tools that you can enable in your code to systematically look for overlaps. These checks are based on sampling points and boundary tests. They do not fix anything automatically, but they give you clear messages about where to look.

The basic idea is to ask Geant4 to test a placed volume for overlaps at construction time. For this, many placement constructors and Boolean solid constructors take a boolean argument to enable overlap checking. When this flag is true, Geant4 throws test points near surfaces and checks whether points that should belong only to one volume are actually inside more than one.

You can also perform global geometry checks using the geometry test commands in the user interface. These commands let you probe a region or the whole world with many random points and report all detected overlaps.

Overlap checks are not infinite precision. They rely on random sampling and a tolerance distance, so you may occasionally miss very small overlaps or see warnings for volumes that are almost touching. Still, they are very effective for normal detector geometries and should be part of your regular debugging routine.

Enabling CheckOverlaps in Code

The most direct method to detect overlaps is to turn on overlap checking for each placement in your DetectorConstruction. Many constructors of physical volumes and Boolean solids accept an optional final parameter called pSurfChk or checkOverlaps. Set this to true to ask Geant4 to verify that the newly created volume does not overlap with its neighbors.

For example, the common placement constructor for a single volume has the following final argument:

$$
\text{G4PVPlacement}(\dots, \text{G4bool }pSurfChk)
$$

If you pass true as this argument, Geant4 will automatically test for overlaps when you construct the geometry.

Using `checkOverlaps` with `G4PVPlacement`

To enable checking for a specific placement, you use the final boolean parameter of G4PVPlacement. A common call pattern in C++ looks like this:

G4bool checkOverlaps = true;
new G4PVPlacement(
  0,                        // rotation
  G4ThreeVector(),          // translation
  logicDetector,            // logical volume
  "Detector",               // name
  logicWorld,               // mother logical volume
  false,                    // no boolean operation
  0,                        // copy number
  checkOverlaps             // surface check
);

Here checkOverlaps is set to true. During initialization Geant4 samples points on the surface of the placed volume and where it touches the mother. If it finds that some points are also inside another daughter or outside the mother, it prints warnings or errors to the console.

For replica or parameterized volumes, you can similarly enable checks by using the corresponding constructor options or by applying dedicated geometry test commands. Although explicit checkOverlaps is not always available for every type of placement, the idea is the same: ask Geant4 to verify surfaces when you instantiate the geometry.

A practical pattern is to declare a single boolean at the top of your DetectorConstruction and pass it into all placements. For production builds you can set it to false to avoid the overhead, while for debugging you set it to true before compilation.

Checking Boolean Solids for Overlaps

Boolean solids that combine component shapes by union, subtraction or intersection have their own optional check parameter. When you use classes like G4UnionSolid, G4SubtractionSolid or G4IntersectionSolid, the last argument can request a surface check of the resulting solid with respect to the components.

For instance, the constructor usually looks like this conceptually:

$$
\text{G4SubtractionSolid}(\text{name},\, \text{solidA},\, \text{solidB},\, \text{transformB},\, \text{pSurfChk})
$$

A typical use in code is:

G4bool checkOverlaps = true;
auto solidA = new G4Box("A", 10*cm, 10*cm, 10*cm);
auto solidB = new G4Tubs("B", 0., 5*cm, 12*cm, 0., 360*deg);
auto subSolid = new G4SubtractionSolid(
  "AminusB",
  solidA,
  solidB,
  0,
  G4ThreeVector(),
  checkOverlaps
);

By enabling checkOverlaps here, Geant4 tests whether the Boolean operation is well defined and whether small surface inconsistencies appear due to numerical issues between the component solids. This helps you catch misaligned or overextended subtractions where a tool solid does not fully intersect as intended.

You should also combine this with checkOverlaps in the eventual G4PVPlacement that uses the Boolean solid, because even a perfect solid can overlap with neighbors if placed incorrectly. Checking at both the solid and placement levels gives the most robust validation.

Diagnosing Overlaps from Geant4 Output

When overlap checks find problems, Geant4 writes informative messages to the terminal. Learning to read these messages makes it much easier to identify where your geometry is wrong.

A typical message informs you that a placed volume overlaps with another daughter or is outside the mother. It mentions the names of the volumes involved, the depth in the geometry hierarchy, and often the approximate location or sample point where the issue occurred.

The message usually distinguishes between two kinds of issues. One is a daughter volume that extends beyond its mother, which means part of its volume has no valid container. The other is multiple daughter volumes that both claim the same region inside the mother, which means they overlap each other.

Sometimes the diagnostic also prints the transformation matrix and position information for the offending volume. Although the coordinates can be detailed, the volume names usually give you a clear hint about which part of your geometry to inspect in DetectorConstruction.

If you see a large number of similar warnings, for example many copies of the same message with varying sample point numbers, it often indicates a systematic problem. In that case, instead of trying to fix each reported location separately, look for a global error in dimensions or placement formulas.

Visual Techniques for Finding Overlaps

Text messages help you locate the problematic volumes, but visualization tools let you see overlaps directly. Combining both approaches is usually the most efficient debugging strategy.

First, draw your geometry using a wireframe visualization. This often reveals obvious intersections between volumes, especially when you rotate and zoom in. A small misplacement of a crystal or support structure can be visible as lines or surfaces crossing in unnatural ways.

Second, you can switch to a transparent solid rendering for selected volumes while leaving others opaque. This helps you see nested structures and whether daughters extend beyond the mother or collide with neighbors. For example, make the world or support structure semi transparent and fully render only the suspected volumes.

A very effective method is to draw only one logical volume and its daughters, or to filter by volume name in your visualization commands. This isolates the region of interest and reduces clutter so you can focus on potential overlaps.

You can also use clipping planes or zoom into specific coordinates to study areas mentioned in the overlap messages. If an overlap occurs near a particular corner or edge, try to orient the camera so that region is clearly visible.

Finally, if your visualization driver supports interactive picking or highlighting, you can click on a volume in the viewer and read its name. Cross referencing that with the console warnings lets you confirm which object is mispositioned.

Fixing Overlaps Systematically

Once you know where an overlap occurs, you should adjust the geometry rather than suppress the checks. A systematic approach helps prevent new overlaps when you modify the design.

Start by verifying the relationship between mother and daughter sizes. For each offending volume, compute the maximum extent of the daughter along each axis and ensure it is strictly smaller than the corresponding mother's half lengths. Correct the dimensions if necessary, leaving a small safety margin relative to the Geant4 tolerance.

Next, re examine placement translations. If you place volumes in arrays or rings, check that the pitch or angular spacing matches the physical size. Use simple formulas to confirm that the total width of all elements plus gaps does not exceed the available mother size. Consider computing offsets from the center of the mother, not from its edges, to avoid cumulative errors.

For Boolean solids, ensure that subtracted or intersected shapes actually overlap in the intended region. Visualize the component solids on their own before combining them. If tiny slivers or protrusions remain, adjust radii, lengths, or positions so surfaces either fully intersect or clearly separate by more than the tolerance.

When importing geometry from external sources, consider simplifying complex shapes into a smaller set of regular solids. If that is not possible, inspect the CAD or GDML with external tools and, where feasible, adjust dimensions slightly to remove unintended intersections. In some cases, re exporting with a coarser mesh or different tolerance can help.

After each modification, re enable or keep enabled the overlap checks and reinitialize the geometry. Only proceed when the checks report no overlaps and the visual inspection looks reasonable.

Common Pitfalls and Tolerance Issues

Even with careful design you may see messages that look like overlaps but are actually related to numerical tolerances. Geant4 uses a small geometry tolerance, often called kCarTolerance, to decide whether a point is inside, outside, or on a surface. Volumes that nearly touch within this tolerance can trigger warnings.

For example, if two volumes share a surface exactly, tiny floating point errors in rotations or translations can lead to one being considered slightly inside the other at some sample points. Similarly, Boolean operations that rely on exact coincidences of surfaces can produce microscopic fragments due to rounding.

To reduce these issues, avoid designing geometries where surfaces coincide perfectly over extended areas. Instead, introduce small but explicit gaps or overlaps that are larger than the tolerance. For instance, if two layers should meet, consider leaving a very thin air gap rather than exact contact.

Another pitfall is mixing units inadvertently when computing sizes or positions. A dimension given in mm combined with one in cm may create large unexpected shifts. Always write units explicitly in your code and double check composite expressions.

Array or ring constructions can also accumulate floating point rounding errors if you compute positions iteratively. Prefer analytic expressions based on indices and angles instead of repeated additions. This keeps each placement consistent and reduces the risk that the final elements drift enough to overlap.

If you still see questionable overlap messages that you suspect are false positives, try increasing the number of test points or adjusting your geometry slightly to create clear separations. But treat every message seriously until you have a strong reason to consider it a tolerance artifact.

Best Practices to Avoid Future Overlaps

Building robust geometries becomes easier if you plan for overlap avoidance from the start, rather than trying to patch problems later.

Use clear design rules for sizes and placements. For each mother volume, define its usable inner dimensions, then derive all daughter dimensions from those using explicit formulas. Avoid hard coding numbers that are only loosely related, since that makes it easy for changes in one place to break another.

Keep a small margin between daughters and the mother boundaries. For example, if the mother half length in $x$ is $L$, ensure no daughter extends beyond $L - \epsilon$, with $\epsilon$ larger than the geometry tolerance. Document your chosen margins in comments so you know why they exist.

When constructing repeated structures, base each position on the index and the known full size or pitch, not on incremental accumulation. This makes the geometry easier to reason about and adapt if you later change the number of elements or their dimensions.

Maintain a single boolean flag in DetectorConstruction that controls overlap checking for all placements and Boolean solids. Keep it enabled during development and testing. Only consider disabling it in high performance production runs after you have thoroughly validated the geometry.

Finally, treat any new geometry modification as a reason to rerun overlap checks. Even small additions, such as supports or cables, can interact with existing volumes. Building the habit of regular geometry validation will save you significant debugging time and help ensure that your simulation results are trustworthy.

Views: 10