Issue with geometry overlaps

Geometry, Fields and Transportation
1

Hi,

I have a large geometry model in Geant4. The geometry itself is fairly simple and is modeled as concentric G4Orbs. The model comprises of Earth (as a G4Orb), atmospheric layers (consecutive G4Orbs), outer space and the world volume. I am checking for overlapping geometries with checkOverlaps in PVPlacement, and on execution, it results in the following error messages for each of the volume.

Checking overlaps for volume Space (G4Orb) …
-------- WWWW ------- G4Exception-START -------- WWWW -------
*** G4Exception : GeomVol1002
issued by : G4PVPlacement::CheckOverlaps()
Sample point is not on the surface !
The issue is detected for volume Space:0 (G4Orb)
generated point (-7.71258e+10,-5.09016e+10,8.77354e+10) is inside
*** This is just a warning message. ***
-------- WWWW -------- G4Exception-END --------- WWWW -------

Checking overlaps for volume upperAtmos (G4Orb) …
-------- WWWW ------- G4Exception-START -------- WWWW -------
*** G4Exception : GeomVol1002
issued by : G4PVPlacement::CheckOverlaps()
Sample point is not on the surface !
The issue is detected for volume upperAtmos:0 (G4Orb)
generated point (3.32755e+09,-4.12971e+09,5.11932e+09) is outside
*** This is just a warning message. ***
-------- WWWW -------- G4Exception-END --------- WWWW -------

Checking overlaps for volume atmos (G4Orb) …
-------- WWWW ------- G4Exception-START -------- WWWW -------
*** G4Exception : GeomVol1002
issued by : G4PVPlacement::CheckOverlaps()
Sample point is not on the surface !
The issue is detected for volume atmos:0 (G4Orb)
generated point (-2.09144e+09,6.49039e+08,6.05966e+09) is inside
*** This is just a warning message. ***
-------- WWWW -------- G4Exception-END --------- WWWW -------

The simulation still runs initially but breaks with the following messages.

-------- WWWW ------- G4Exception-START -------- WWWW -------
*** G4Exception : GeomNav1002
issued by : G4Navigator::ComputeStep()
Stuck Track: potential geometry or navigation problem.
Track stuck, not moving for 10 steps.
Current phys volume: ‘atmos’

  • at position : (190523759.0555951,-5472384326.528816,-3418525635.416105)
    in direction: (-0.02950943081761415,0.8477445949110948,0.5295831335039327)
    (local position: (190523759.0555951,-5472384326.528816,-3418525635.416105))
    (local direction: (-0.02950943081761415,0.8477445949110948,0.5295831335039327)).
    Previous phys volume: ‘atmos’

Likely geometry overlap - else navigation problem !
*** Trying to get unstuck using a push - expanding step to 1e-07 (mm) … Potential overlap in geometry !

*** This is just a warning message. ***
-------- WWWW -------- G4Exception-END --------- WWWW -------

-------- WWWW ------- G4Exception-START -------- WWWW -------
*** G4Exception : GeomVol1002
issued by : G4PVPlacement::CheckOverlaps()
Sample point is not on the surface !
The issue is detected for volume atmos:0 (G4Orb)
generated point (5.19447e+09,-2.64e+09,2.77804e+09) is inside
*** This is just a warning message. ***
-------- WWWW -------- G4Exception-END --------- WWWW -------

Radius of earth - re is defined as
static const G4double re=6371.20000*CLHEP::km;

I have attached my DetectorConstruction file. Please let me know if I’m making any obvious errors. I am still working on it so will update in case I resolve the issue.

Thanks in advance.

Geant4 Version: 10.07
Operating System: Lxplus (build - x86_64-centos7-gcc10-opt)

DetConstrFile.cc (13.0 KB)

2

We have seen the same problem in our experimental geometry with specific volumes, running under Geant4 10.7 (as you are). In particular, we see this error when using G4Polycones for shapes. We can confirm with manual calculations that there are no actual volume overlaps (the shapes involved are disjoint).

The problem appears to be with how random points are chosen internally to Geant4’s CheckOverlaps() function itself. In our case, we suspect it is related to having “corners” in our polycones.

In your case, I wonder if it’s a floating point resolution problem, since you’re building a full-sized Earth, and G4 might be generating points that appear to be more than 1e-9 mm away from the surface of the orb.

3

Geant4 has a concept of “surface thickness”, which by default is equal 1e-9 mm and is available in the G4VSolid base class as kCarTolerance.

In case of very large geometries, like yours, such tiny “surface thickness” makes no sense and should be redefined to a bigger value, please see Setting Geometry Tolerance to be relative

4

Hi Michael and Evgueni,

Thank you for your prompt replies
I had read through the geometry tolerance and in my main source file I am defining a new surface extent as 1e10*mm (for instance), that sets the radial tolerance to 0.1 (I’m assuming in units of mm?), and recompiling. But, it does not have an effect on the simulation. Is SetWorldMaximumExtent required to be redefined inside the DetectorConstruction class or something else, as it might not be setting the new value of the surface extent?

    G4double newSurfExtent= 1e10*mm;

    G4GeometryManager::GetInstance()->SetWorldMaximumExtent(newSurfExtent);

    G4double radTolNEW = G4GeometryTolerance::GetInstance()->GetRadialTolerance();
    G4cout << "new radial tolerance is : " << radTolNEW << G4endl;

Thanks for your help!
Aditya

5

Possibly 1e+10mm is not sufficient, SetWorldMaximumExtent() expects a value equal to the size of the World.