Geant4 User's Guide For Application Developers Geometry

Volumes are often positioned within other volumes with the intent that one is fully contained within the other. If, however, a volume extends beyond the boundaries of its mother volume, it is defined as overlapping. It may also be intended that volumes are positioned within the same mother volume such that they do not intersect one another. When such volumes do intersect, they are also defined as overlapping.

The problem of detecting overlaps between volumes is bounded by the complexity of the solid model description. Hence it requires the same mathematical sophistication which is needed to describe the most complex solid topology, in general. However, a tunable accuracy can be obtained by approximating the solids via first and/or second order surfaces and checking their intersections.

In general, the most powerful clash detection algorithms are provided by CAD systems, treating the intersection between the solids in their topological form.

Geant4 provides some built-in run-time commands to activate verification tests for the user-defined geometry:

     geometry/test/grid_test [recursion_flag]
     --> to start verification of geometry for overlapping regions
         based on standard lines grid setup. If the "recursion_flag" is
         set to 'false' (the default), the check is limited to the first
         depth level of the geometry tree; otherwise it visits recursively
         the whole geometry tree. In the latter case, it may take a long
         time, depending on the complexity of the geometry.
     geometry/test/cylinder_test [recursion_flag]
     --> shoots lines according to a cylindrical pattern. If the
         "recursion_flag" is set to 'false' (the default), the check is
         limited to the first depth level of the geometry tree; otherwise
         it visits recursively the whole geometry tree. In the latter case,
         it may take a long time, depending on the complexity of the geometry.
     geometry/test/line_test [recursion_flag]
     --> shoots a line according to a specified direction and position
         defined by the user. If the "recursion_flag" is set to 'false'
         (the default), the check is limited to the first depth level of the
         geometry tree; otherwise it visits recursively the whole geometry 
         tree.
     geometry/test/position
     --> to specify position for the line_test.
     geometry/test/direction
     --> to specify direction for the line_test.
     geometry/test/grid_cells
     --> to define the resolution of the lines in the grid test as number
         of cells, specifying them for each dimension, X, Y and Z.
         The new settings will be applied to the grid_test command.
     geometry/test/cylinder_geometry
     --> to define the details of the cylinder geometry, by specifying:
             nPhi - number of lines per Phi
             nZ   - number of Z points
             nRho - number of Rho points
         The new settings will be applied to the cylinder_test command.
     geometry/test/cylinder_scaleZ
     --> to define the resolution of the cylinder geometry, by specifying
         the fraction scale for points along Z.
         The new settings will be applied to the cylinder_test command.
     geometry/test/cylinder_scaleRho
     --> to define the resolution of the cylinder geometry, by specifying
         the fraction scale for points along Rho.
         The new settings will be applied to the cylinder_test command.
     geometry/test/recursion_start
     --> to set the initial level in the geometry tree for starting the
         recursion (default value being zero, i.e. the world volume).
         The new settings will then be applied to any recursive test.
     geometry/test/recursion_depth
     --> to set the depth in the geometry tree for recursion, so that
         recursion will stop after having reached the specified depth (the
         default being the full depth of the geometry tree).
         The new settings will then be applied to any recursive test.
 

Figure 4.1.4 Different cases of placed volumes overlapping each other.

Here we have a line intersecting some physical volume (large, black rectangle). Belonging to the volume are four daughters: A, B, C, and D. Indicated by the dots are the intersections of the line with the mother volume and the four daughters.

This example has two geometry errors. First, volume A sticks outside its mother volume (this practice, sometimes used in GEANT3.21, is not allowed in Geant4). This can be noticed because the intersection point (leftmost magenta dot) lies outside the mother volume, as defined by the space between the two black dots.

The second error is that daughter volumes A and B overlap. This is noticeable because one of the intersections with A (rightmost magenta dot) is inside the volume B, as defined as the space between the red dots. Alternatively, one of the intersections with B (leftmost red dot) is inside the volume A, as defined as the space between the magenta dots.

Each of these two types of errors is represented by a line segment, which has a start point, an end point, and, a length. Depending on the type of error, the points are most clearly recognized in either the coordinate system of the volume, the global coordinate system, or the coordinate system of the daughters involved.

Also notice that certain errors will be missed unless a line is supplied in precisely the correct path. Unfortunately, it is hard to predict which lines are best at uncovering potential geometry errors. Instead, the geometry testing code uses a grid of lines, in the hope of at least uncovering gross geometry errors. More subtle errors could easily be missed.

Another difficult issue is roundoff error. For example, daughters C and D lie precisely next to each other. It is possible, due to roundoff, that one of the intersections points will lie just slightly inside the space of the other. In addition, a volume that lies tightly up against the outside of its mother may have an intersection point that just slightly lies outside the mother.

To avoid spurious errors caused by roundoff, a rather generous tolerance of 0.1 micron is used by default. This tolerance can be adjusted as needed by the application through the run-time command:

   geometry/test/tolerance <new-value>

Finally, notice that no mention is made of the possible daughter volumes of A, B, C, and D. To keep the code simple, only the immediate daughters of a volume are checked at one pass. To test these "granddaughter" volumes, the daughters A, B, C, and D each have to be tested themselves in turn. To make this more automatic, an optional recursive algorithm is included; it first tests a target volume, then it loops over all daughter volumes and calls itself.

Pay attention! For a complex geometry, checking the entire volume hierarchy can be extremely time consuming.

Since release 8.0, the Geant4 geometry modeler provides the ability to detect overlaps of placed volumes (normal placements or parameterised) at the time of construction. This check is optional and can be activated when instantiating a placement (see G4PVPlacement constructor in Section 4.1.4.1) or a parameterised volume (see G4PVParameterised constructor in Section 4.1.4.2).
The positioning of that specific volume will be checked against all volumes in the same hierarchy level and its mother volume. Depending on the complexity of the geometry being checked, the check may require considerable CPU time; it is therefore suggested to use it only for debugging the geometry setup and to apply it only to the part of the geometry setup which requires debugging.

The classes G4PVPlacement and G4PVParameterised also provide a method:

   G4bool CheckOverlaps(G4int res=1000)

The Geant4 visualization offers a powerful debugging tool for detecting potential intersections of physical volumes. The Geant4 DAVID visualization tool [2] can infact automatically detect the overlaps between the volumes defined in Geant4 and converted to a graphical representation for visualization purposes. The accuracy of the graphical representation can be tuned onto the exact geometrical description. In the debugging, physical-volume surfaces are automatically decomposed into 3D polygons, and intersections of the generated polygons are investigated. If a polygon intersects with another one, physical volumes which these polygons belong to are visualized in color (red is the default). The figure 4.1.5 below is a sample visualization of a detector geometry with intersecting physical volumes highlighted:

Figure 4.1.5 A geometry with overlapping volumes highlighted by DAVID.

At present physical volumes made of the following solids are able to be debugged: G4Box, G4Cons, G4Para, G4Sphere, G4Trd, G4Trap, G4Tubs. (Existence of other solids is harmless.)

Visual debugging of physical-volume surfaces is performed with the DAWNFILE driver defined in the visualization category and with the two application packages, i.e. Fukui Renderer "DAWN" and a visual intersection debugger "DAVID". DAWN [1] and DAVID [2] can be downloaded from the Web.

How to compile Geant4 with the DAWNFILE driver incorporated is described in Section 8.3.

If the DAWNFILE driver, DAWN and DAVID are all working well in your host machine, the visual intersection debugging of physical-volume surfaces can be performed as follows:

Run your Geant4 executable, invoke the DAWNFILE driver, and execute visualization commands to visualize your detector geometry:

     Idle> /vis/open DAWNFILE
     .....(setting camera etc)...
     Idle> /vis/drawVolume
     Idle> /vis/viewer/update

Then a file "g4.prim", which describes the detector geometry, is generated in the current directory and DAVID is invoked to read it. (The description of the format of the file g4.prim can be found from the DAWN web site documentation.)

If DAVID detects intersection of physical-volume surfaces, it automatically invokes DAWN to visualize the detector geometry with the intersected physical volumes highlighted (See the above sample visualization).

If no intersection is detected, visualization is skipped and the following message is displayed on the console:

     ------------------------------------------------------
     !!! Number of intersected volumes : 0 !!!
     !!! Congratulations ! \(^o^)/         !!!
     ------------------------------------------------------

If you always want to skip visualization, set an environmental variable as follows beforehand:

     %  setenv DAVID_NO_VIEW  1

To control the precision associated to computation of intersections (default precision is set to 9), it is possible to use the environmental variable for the DAWNFILE graphics driver, as follows:

     %  setenv G4DAWNFILE_PRECISION  10

If necessary, re-visualize the detector geometry with intersected parts highlighted. The data are saved in a file "g4david.prim" in the current directory. This file can be re-visualized with DAWN as follows:

     % dawn g4david.prim

It is also helpful to convert the generated file g4david.prim into a VRML-formatted file and perform interactive visualization of it with your WWW browser. The file conversion tool prim2wrml can be downloaded from the DAWN web site download pages.

For more details, see the document of DAVID mentioned above.

OLAP is a tool developed in the CMS experiment at CERN to help in identifying ovelapping volumes in a detector geometry. It is placed in the area for specific tools/examples, in geant4/examples/extended/geometry. The technique consists in shooting geantinos particles in one direction and the opposite one, and verifying that the boundary crossings are the same.
The tool can be used for any Geant4 geometry, provided that the user geometry to be debugged is available as a subclass of G4VUserDetectorConstruction and is used to construct the OlapDetConstr class of the tool. A dummy class RandomDetector is provided for this purpose in the tool itself.
Run-time commands are provided by the tool to navigate in the geometry tree. UNIX like navigation of the logical volume hierarchy is provided by the /olap/cd command. The root of the logical volume tree can be accessed by the character '/'. Any node in the volume tree can be accessed by a '/' separated string of regular expressions. If '/' is at the beginning of the string, the tree hierarchy is transversed from the root, otherwise from the currently chosen logical volume. Further the command /olap/goto [regexp] can be used to jump to the first logical volume matching the expression [regexp]. Every successful navigation command (/olap/cd, olap/goto) results in the construction of a NewWorld, the mother volume being the argument of the command and the daughter volumes being the direct daughters of the mother volume.
/olap/pwd always shows where in the full geometrical hierarchy the current NewWorld and mother volume are located.
For more detailed information, view the README file provided with the tool.

[1]	http://geant4.kek.jp/GEANT4/vis/DAWN/About_DAWN.html
[2]	http://geant4.kek.jp/GEANT4/vis/DAWN/About_DAVID.html