overlap checking in 10.3 gives warnings and is very slow

[Jochem Snuverink]

In geant4 10.3 beta many tests are timing out. This is due to the overlap checking being extremely slow (compared to the other releases). This is not important for the moment since it is only a beta release (and it might be fixed in the proper release), but I thought it would be good to already open an issue report.

There are also some warnings (this one is from 2_ironmagfields), which might or might not be related:

Checking overlaps for volume sb1_1_of_1_beampipe_pv ... OK! 

-------- WWWW ------- G4Exception-START -------- WWWW -------
*** G4Exception : GeomSolids1001
      issued by : G4ExtrudedSolid::G4ExtrudedSolid()
The following vertices have been removed from the polygon in sb1_1_of_1_outer_sq_container_solid
as collinear or coincident with other vertices: 0,11
*** This is just a warning message. ***
-------- WWWW -------- G4Exception-END --------- WWWW -------

[Jochem Snuverink]

This is also true for the official 10.3 version. It only seems to happen with the overlap checking of thinmultipoles, rbends or sbends.

[Jochem Snuverink]

The warning has been fixed in commit f1376b9, the collinear vertices have been removed.

However this has not reduced the time. Here is a typical backtrace:

(gdb) bt
#0  CLHEP::HepJamesRandom::flat() ()
    at /afs/psi.ch/user/s/snuverink_j/scratch/CLHEP/2.3.3.1/CLHEP/Random/src/JamesRandom.cc:273
#1  0x00007ffff025df2a in G4VSolid::EstimateSurfaceArea(int, double) const ()
   from /home/scratch/geant4.10.03-build/BuildProducts/lib64/libG4geometry.so
#2  0x00007ffff02b67cd in G4BooleanSolid::GetPointOnSurface() const ()
   from /home/scratch/geant4.10.03-build/BuildProducts/lib64/libG4geometry.so
#3  0x00007ffff03c041e in G4PVPlacement::CheckOverlaps(int, double, bool, int) ()
   from /home/scratch/geant4.10.03-build/BuildProducts/lib64/libG4geometry.so
#4  0x00007ffff03c20cf in G4PVPlacement::G4PVPlacement(CLHEP::HepRotation*, CLHEP::Hep3Vector const&, G4LogicalVolume*, G4String const&, G4LogicalVolume*, bool, int, bool) ()
   from /home/scratch/geant4.10.03-build/BuildProducts/lib64/libG4geometry.so
#5  0x00000000006542a8 in BDSBeamPipeFactoryBase::PlaceComponents(G4String) ()
    at /home/scratch/bdsim/src/BDSBeamPipeFactoryBase.cc:123
#6  0x0000000000653a4a in BDSBeamPipeFactoryBase::CommonConstruction(G4String, G4Material*, G4Material*) ()
    at /home/scratch/bdsim/src/BDSBeamPipeFactoryBase.cc:63
#7  0x00000000006127fb in BDSBeamPipeFactoryElliptical::CommonFinalConstruction(G4String, G4Material*, G4Material*, double, double, double, double) () at /home/scratch/bdsim/src/BDSBeamPipeFactoryElliptical.cc:136
#8  0x000000000061454b in BDSBeamPipeFactoryElliptical::CreateBeamPipe(G4String, double, CLHEP::Hep3Vector, CLHEP::Hep3Vector, double, double, double, double, G4Material*, double, G4Material*) ()
    at /home/scratch/bdsim/src/BDSBeamPipeFactoryElliptical.cc:110
#9  0x000000000060fc53 in BDSBeamPipeFactory::CreateBeamPipe(BDSTypeSafeEnum<beampipetypes_def, int>, G4String, double, CLHEP::Hep3Vector, CLHEP::Hep3Vector, double, double, double, double, G4Material*, double, G4Material*) ()
    at /home/scratch/bdsim/src/BDSBeamPipeFactory.cc:150
#10 0x000000000060fdff in BDSBeamPipeFactory::CreateBeamPipe(G4String, double, BDSBeamPipeInfo*) ()
    at /home/scratch/bdsim/src/BDSBeamPipeFactory.cc:95
#11 0x00000000005efd6b in BDSMagnet::BuildBeampipe() () at /home/scratch/bdsim/src/BDSMagnet.cc:85

Presumably Geant4.10.3 is not very effective in checking the overlaps for our elliptical beampipe (and others), and draws a lot of random numbers. I don't think this is on our side.

[Laurie Nevay]

I see this also with elliptical beam pipes. I've broken apart the geometry and put in their most basic B1 geant4 example and it reproduces the behaviour.

In Geant4.10.3 they've completed rewritten a lot of the boundary checking code for each solid. I think it's the combination of elliptical tube and boolean solid. If I don't see any way round this after a little bit of testing today, I'll submit a bug report.

[Laurie Nevay]

I've submitted a bug report to Geant4.

https://bugzilla-geant4.kek.jp/show_bug.cgi?id=1943

[Laurie Nevay]

They acknowledge and closed my bug report as solved. Apparently, the GetSurfaceArea for G4CutTubs is incredibly inefficient and this has been fixed for the next patch release of Geant4. It takes around 10 minutes to check for one cut tubs.

This of course makes Geant4.10.3 unusable for geometry overlap checking, but later versions should be fine.

[Jochem Snuverink]

Okay that is good news. Should we disable overlap checking for those 10.3 versions that are affected? We can put a version check in GlobalConstants::checkOverlaps().

[Laurie Nevay]

This is a good work around, but I would expect the tracking in physics studies will be similarly slow. We have cut tubs everywhere throughout our geometry and the check overlaps just fires particles and tests out the tracking with them so it's indicative of general behaviour. A single overlap check has gone from < 0.2s per check to ~10mins. A single check usually uses around 10k geantinos.

We can try without the overlap checking though. This would be acceptable as we'll have overlap checking with other versions.

I would propose though that we recommend to users through the manual etc that they don't use Geant4.10.3.

[Jochem Snuverink]

I have disabled overlap checks for 10.3.0 in commit 9fa258d. The test time is greatly reduced and seems similar to other Geant4 versions again. In a future 10.3.1 the overlap checks will be present again.

[Jochem Snuverink]

Geant4 just released version 10.3.1 where this issue is fixed.