KAHIBARO
8.3. Positioning Volumes
Table of Contents
Translation
Once you have created solids and logical volumes, you place them in the geometry by creating physical volumes. Positioning is always defined with respect to the mother volume. The basic tool is G4PVPlacement, whose constructor has a parameter for the volume’s position.
Translations are given as a G4ThreeVector measured in the global Geant4 unit system. For example, a detector element placed 5 cm along the positive x axis of its mother volume can be positioned with a translation vector like G4ThreeVector(5*cm, 0, 0).
The key point is that the position you specify is the center of the daughter volume in the coordinate system of its mother. If you place a box of size 2 cm by 2 cm by 2 cm at (0, 0, 0) inside the world, its center will coincide with the world center. If you place it at (0, 0, 5*cm), the whole box shifts so that its center moves 5 cm along the world z axis.
You should always keep track of which coordinate system you are using. If a logical volume is used in different mothers, each placement can have a different translation, but the shape and material remain the same. This is one of the advantages of separating logical and physical volumes.
It is also important to consider clearances when placing objects. Children must be fully contained in their mother without touching or crossing the mother boundary. If you place a daughter volume so that it extends beyond the mother, or two daughters overlap in space, you will encounter geometry overlap problems that can spoil the simulation. When you compute translations, build in a small margin so that volumes do not share a boundary surface exactly, for example, shift by 0.1*mm instead of exactly touching.
Always specify translations in the coordinate system of the mother volume, and ensure that every daughter volume is fully contained and does not overlap with other daughters.
In more complex detectors, it is common to build hierarchical structures. For instance, you might have a module logical volume that is placed in the world with one translation, and then several sensors placed inside the module with additional translations relative to the module center. The final absolute position of each sensor is the combination of all translations and rotations applied along the hierarchy, but you usually work only in the local coordinates of the current mother.
You can also dynamically compute translations in C++ using loops and arithmetic. This is particularly useful for arrays of detector elements that are placed at regular intervals. A simple example is placing several identical volumes along one axis with a spacing given by a parameter. Each G4PVPlacement then receives a translation computed from the loop index, the element size, and the desired gap.
Rotation
Rotations let you orient a volume relative to its mother. Geant4 uses the G4RotationMatrix class to describe a rotation, and you pass a pointer to such a matrix to G4PVPlacement. A null pointer indicates no rotation and means that the daughter’s local axes are parallel to the mother’s axes.
A G4RotationMatrix represents a 3D rotation in terms of its action on the x, y, and z axes. The most common way to create a simple rotation is with methods like rotateX(angle), rotateY(angle), or rotateZ(angle). The angle is given in Geant4 angle units such as deg or rad. For example, if you want to rotate a detector crystal by 90 degrees around the y axis, you define a rotation matrix and apply rotateY(90*deg) before using it in a placement.
Rotations are always applied before the translation when the geometry is evaluated. Conceptually, you first rotate the daughter volume in the coordinate system of the mother, then you translate the rotated volume to the specified center position. This means the apparent direction of translation depends on the rotation if you think in terms of local axes. In practice, you normally think in the mother coordinates: you choose the rotation to orient the daughter and the translation to place its center.
Rotations can be combined by applying multiple rotation methods in sequence. The order of these calls matters, since rotations in three dimensions do not commute. For example, rotateX(30deg); rotateZ(45deg); produces a different orientation than rotateZ(45deg); rotateX(30deg);. For simple geometries, you can keep the sequence fixed and use clear comments to document the intended orientation.
You can also construct a rotation matrix directly from unit vectors that define the new x, y, and z directions. This is useful when you want to align a detector element along a particular direction vector instead of thinking in Euler angles. In any case, it helps to visualize axes in the viewer and verify that volumes point where you expect.
Rotations are defined in the mother coordinate system, applied before translations, and the order of sequential rotations is significant for the final orientation.
When you place many detectors at different angles, such as in a ring, you can compute each rotation in a loop. For a detector at angle $\phi$ in the x–y plane, a common pattern is to rotate around the z axis by $\phi$ and then translate outward along the x axis to the ring radius. The result is a regularly spaced set of rotated detectors, each facing inward or outward according to how you define the rotation.
If you combine rotation and translation incorrectly, you may end up with volumes pointing the wrong way or intersecting each other. Whenever you introduce new rotations, check the geometry visually, use overlap checking tools, and refine the angles or translation distances until the layout matches your design.
Views: 10