32.3. Nested Geometry

Table of Contents

Concept of Nested Geometry

Nested geometry in Geant4 means placing one or more volumes completely inside another volume to build hierarchical structures. You already use a basic form of this when you place a detector crystal inside an air box, or an air volume inside the world. The term "nested geometry" usually refers to deeper and more systematic hierarchies, such as modules inside submodules inside a detector mother volume, with different levels of grouping and repetition.

The key idea is that every physical volume can act as a "mother" volume for other "daughter" volumes. A daughter must lie fully inside its mother, and its position and orientation are always defined relative to the mother. By nesting volumes, you can represent complex detectors as a tree of geometrical components, each one built from simpler parts.

Mother and Daughter Volumes

In a nested geometry, each $G4VPhysicalVolume$ has a clear role in a tree structure. At the top is the world volume. Every other physical volume has exactly one mother volume, and may have zero or more daughters.

The world volume is a special mother, because it contains everything else and has no mother of its own. When you place a volume with G4PVPlacement, you specify which logical volume acts as its mother. That mother logical volume is associated with a physical volume that defines where the daughters are actually located in space.

You must respect a strict containment rule. A daughter volume must be fully contained inside its mother volume. Geant4 does not allow partial or external placement. The position and rotation of the daughter are specified in the coordinate system of the mother. This creates a hierarchy of coordinate systems, with each level nested inside its parent.

In a nested detector, you often use several levels of mothers and daughters. For example, the world contains a detector hall. The hall contains a calorimeter housing. The housing contains modules. Each module contains layers. Each layer contains cells. Each of these is a mother for the next level.

Coordinate Systems in Nested Volumes

Every physical volume defines a local coordinate system. The origin of that coordinate system is at the center of the volume by default, and its axes are aligned according to any rotation you apply during placement. When you nest volumes, you build a chain of transforms from the local coordinates of a daughter all the way back to the global coordinates of the world.

Positions in Geant4 are always stored and reported in the global coordinate system. However, when you construct and place nested geometry, you think in the local coordinates of each mother volume. This means that the translation you use in G4PVPlacement is relative to the mother, not the world.

If a volume $B$ is placed inside volume $A$ with some translation and rotation, and a third volume $C$ is placed inside $B$, then the global position of a point in $C$ depends on the transforms from $C$ to $B$, from $B$ to $A$, and from $A$ to the world. Geant4 handles these transformations internally during navigation and tracking.

You can also transform between global and local coordinates programmatically with methods on G4TouchableHistory and related classes when you need to interpret positions in a particular local frame, for example within a repeated detector element.

In nested geometry, all daughter placements are defined in the local coordinates of their mother volume, not in world coordinates. A daughter must be fully inside its mother volume. Violating this containment rule can lead to navigation errors or undefined tracking behavior.

Building Hierarchies of Volumes

Nested geometry is most useful when you create structured hierarchies that reflect the design of your detector. Instead of placing every small element directly in the world, you group related elements into intermediate mother volumes. This provides several practical advantages.

First, it matches the physical design. Real detectors are built from modules, layers, and subassemblies. Representing this directly in your geometry makes it easier to maintain and modify. You can change a module once, and all its copies update.

Second, it simplifies placement. Rather than computing absolute positions of many small pieces, you can define them once relative to a simple mother volume, then place that mother multiple times. Each instance of the mother carries all its nested daughters automatically.

Third, it makes it easier to assign different sensitive detectors or materials to different levels. You might assign a sensitive detector only to the innermost cells, while the surrounding structure remains passive.

Finally, a clear hierarchy helps you interpret simulation results. Volume names and copy numbers reflect the nested structure, so when you see a hit in a certain volume with a particular hierarchy path, you can understand which physical element that corresponds to.

Pattern: Module, Submodule, and Cell

A common pattern in nested geometry is a three level structure of module, submodule, and cell. Imagine a calorimeter where you have large modules arranged in a ring, and each module contains several layers, and each layer contains many small cells.

At the top level, you define a module logical volume that represents the full size of the module housing. Inside this module, you place one or more submodules or layers. Each submodule describes a repeating pattern of absorber and active material, for example sheets of lead and scintillator. Finally, inside each submodule, you place individual cells, such as scintillator tiles or silicon pads.

When you arrange these modules around your detector, you only need to place the module logical volume repeatedly using G4PVPlacement or repetition techniques that belong to other chapters. Every submodule and cell is placed relative to the module, so you never need to compute the global positions of the thousands of cells. The module acts as a container that transports all its nested geometry with it.

Nested geometry is therefore a way to express repetition and order without complex mathematics for every small component. It also lets you introduce new structure later. For example, you can insert an extra support layer inside the module volume without changing how the modules are arranged in the world.

Navigation and Nested Geometry

Geant4 navigation is the system that determines which volume a particle is in, and where a step will intersect the next boundary. In a nested geometry, navigation walks the volume hierarchy. For each step, it finds the deepest daughter volume that contains the point, then looks for the next boundary. This is done by considering the shapes and placements of all the nested volumes.

Because of this hierarchical navigation, nested geometry must obey certain rules. Volumes must not overlap in an inconsistent way, and a daughter must be contained inside its mother. If two daughters overlap, or if a daughter sticks outside its mother, the navigator can become confused and tracking may produce incorrect results or even step limit loops.

The step information that you access later reflects the nested structure. For a given G4Step, the pre and post step points include the volume that the particle is in at that point. These volumes belong to the deepest level of the hierarchy that contain the point. If you care about higher levels in the hierarchy, such as which module or layer a cell belongs to, you use the touchable history to climb up through the nested volumes. That allows you to identify not only the cell, but also its parent layer and module.

Identifying Volumes and Copy Numbers

Nested geometry is most useful when you can identify exactly which instance of a nested volume a particle has interacted with. Geant4 uses volume names and copy numbers to distinguish between different instances of the same logical volume.

When you place a volume with G4PVPlacement, you can assign a copy number. If you do not set one explicitly, a default is used. In a nested hierarchy, you often have repeated modules, each containing repeated cells. The copy number at each level then forms a set of indices that identify the position of a cell within the nested structure.

You can access these copy numbers through the touchable history associated with a step or a track. The deepest level index corresponds to the local copy number of the cell. The next level up gives the index of the layer or submodule. Higher levels identify the module, and so on. By reading these indices, you can build a unique detector ID that encodes the nested position of the interaction.

This approach keeps your code independent of absolute coordinates. You do not need to check where in space a hit occurred. Instead, you read the nested copy numbers and use them to route the data to the correct histogram, ntuple column, or detector channel.

Design Tips for Nested Geometry

To use nested geometry effectively, it is important to design your hierarchy before writing code. Think in terms of physical components and how they fit together. Each physical component that can be moved, copied, or changed as a unit is usually a good candidate for a separate logical volume that can act as a mother.

Keep the hierarchy clear and not unnecessarily deep. Too many small levels can make the geometry difficult to understand and maintain. On the other hand, having only one or two very large volumes with many directly placed small daughters can be hard to manage and modify. Aim for a balance that reflects real detector structure.

Pay attention to sizes and placements. Make sure that daughters are slightly smaller than their mothers so that they are fully inside and do not touch or cross boundaries unintentionally. This is particularly important in deep hierarchies where accumulated numerical tolerances can cause edge cases.

Finally, use meaningful volume names and systematic copy numbering to reflect the nested structure. This will make debugging geometry and interpreting hits much easier, especially in complex detectors where thousands or millions of small volumes are involved.

In nested geometry, design the volume hierarchy first and then implement it. Use clear mother daughter relationships, ensure strict containment, and assign consistent names and copy numbers at each level. This greatly simplifies debugging, analysis, and later modifications of your detector model.