Back in 1990, Saul Youssef, now at Boston University but then at Florida State University, wrote a package designed to check a GEANT geometry for two particular types of errors: daughters not entirely contained in their mother volumes, and daughters which intersected. See his report at the SSC Symposium.
Since GEANT's tracking algorithm checks to see if the particle has exited the
daughter before checking to see if it has exited the mother, we can miss volumes.
As an example, look at this plot: PS here.
Volume D
is the overall containment (mother) volume, consisting of vacuum.
Containment/mother volume
A contains chunk of iron B, and containtment/mother
volume C contains chunk of iron E. The particle
being tracked is generated in top volume
D, and
eventually enters mother volume A (a daughter of D),
travels a while and then
enters B. The particle continues in B, eventually
exiting A; but GEANT does not realize this. When it finally exits
B, GEANT finds that the particle is also outside A,
and it finds itself in D. It now looks for the next boundary for a
daughter of D, which would be C--except that it
has already passed that boundary. Volume E is not a
daughter of D, so since GEANT does not see any further daughters
of D it tracks the particle as though there were nothing but
vacuum, ignoring the iron volume E.
Gverify was written based on Youssef's types package, which allowed OS-independent manipulation of various definable data types from within Fortran. It also required a few additional packages also written by him: gvols (generalized versions of the GEANT volume objects), ming1 (a minimizing package), and dfunc (a package of various utility functions). Some of these routines dealt with OS-specific issues such as command line parsing and file access, but a lot is pretty standard Fortran, and therefore portable, if not easily readable.
Types and Gverify were ported to SunOS, VMS, Ultrix, SGI, AIX, and Cray--but not Linux. I hacked at the SunOS version to get Linux working. I wanted to avoid problems with compilation flags and compiler-specific options, so I used the most forgiving compilers at hand: the Intel ifc and icc compilers. One side effect of this choice is that the executables aren't especially portable, unless you have version 6 of the compilers installed.
First you have to get a GFOUT file describing the GEANT structures and volumes. I hacked geant_i/Geant3GeometryInterface.cc to include the following:
int ier=0; int ipick=70; int icase=1; int blocksize=1024; char outputflag='O'; gopen_(&ipick,&outputflag,&blocksize,&ier); std::cout<<"Error return from gopen was "<<ier<<"\n"<<std::flush; int idvolu=0; char* volu="INIT"; gfout_(&ipick,&volu,&icase,&idvolu," ",&ier);
Naturally, this didn't work. I hacked Framework/src/APPMain.cc to call f_init(), and that still didn't work. I finally hacked gfout.F to set CHOBJ(1)='INIT' every time, and then it worked.
I used 4.11.2, though with development MuonGeometry.
Example summary files include:
It would undoubtedly be faster if experts looked at their own code to see how many of these are genuine out-of-bounds and overlaps.
As you can easily see from the detailed listings, some of the text is scrambled. I think this is because of byte-ordering issues, but I'm not certain; and I respect the rule that "Where you see one problem, look for another." These results could conceivably be entirely garbage. I haven't yet seen the IMU system show up, so I haven't been able to compare with a system I know well.
The run on split set number 5 crashed when it ran out of space in a buffer. I intend to relink with a larger buffer and rerun, but I want to wait until the current job finishes.