Problem 1690

Summary: GPS Crashes GEANT4 with a ION
Product: Geant4 Reporter: Matthew Lund <matthewl.lund>
Component: geometry/navigationAssignee: Gabriele Cosmo <Gabriele.Cosmo>
Status: RESOLVED INVALID    
Severity: major CC: kurasige
Priority: P5    
Version: 10.0   
Hardware: Apple   
OS: Mac OS X   
Attachments: macro file to crash gps on run

Description Matthew Lund 2014-11-12 07:54:58 CET
Created attachment 291 [details]
macro file to crash gps on run

Using GEANT4.10.01 and GEANT4.10.00.p02, the General Particle Source crashes when using an ion, /gps/ion ..... with a source surface sphere. I'm attaching macro files below. Tested on both linux and MacOSX, both in multithread, every time a beamOn is started a segmentation fault occurs. I get a warning message below but it isn't the cause.
 
"/gps/ion 3 7
-------- WWWW ------- G4Exception-START -------- WWWW -------
*** G4Exception : PART11117
      issued by : G4ParticleTable::FindIon()
This method is obsolete and will be dropped from v10.0. Use G4IonTable::FindIon().
*** This is just a warning message. ***
-------- WWWW -------- G4Exception-END --------- WWWW -------"

Attached is the log file of the crashed thread:
"Thread 7 Crashed:
0   libG4geometry.dylib           	0x000000010b5580d4 G4VoxelNavigation::ComputeStep(CLHEP::Hep3Vector const&, CLHEP::Hep3Vector const&, double, double&, G4NavigationHistory&, bool&, CLHEP::Hep3Vector&, bool&, bool&, G4VPhysicalVolume**, int&) + 900
1   libG4geometry.dylib           	0x000000010b5347b4 G4Navigator::ComputeStep(CLHEP::Hep3Vector const&, CLHEP::Hep3Vector const&, double, double&) + 1428
2   libG4geometry.dylib           	0x000000010b54341b G4PathFinder::DoNextLinearStep(G4FieldTrack const&, double) + 283
3   libG4geometry.dylib           	0x000000010b54245a G4PathFinder::ComputeStep(G4FieldTrack const&, double, int, int, double&, ELimited&, G4FieldTrack&, G4VPhysicalVolume*) + 1258
4   libG4processes.dylib          	0x000000010a8a7507 G4CoupledTransportation::AlongStepGetPhysicalInteractionLength(G4Track const&, double, double, double&, G4GPILSelection*) + 999
5   libG4tracking.dylib           	0x000000010a092006 G4SteppingManager::DefinePhysicalStepLength() + 662
6   libG4tracking.dylib           	0x000000010a090595 G4SteppingManager::Stepping() + 373
7   libG4tracking.dylib           	0x000000010a09b221 G4TrackingManager::ProcessOneTrack(G4Track*) + 913
8   libG4event.dylib              	0x000000010a004622 G4EventManager::DoProcessing(G4Event*) + 1826
9   libG4run.dylib                	0x0000000109fa296e G4WorkerRunManager::ProcessOneEvent(int) + 46
10  libG4run.dylib                	0x0000000109fa28fe G4WorkerRunManager::DoEventLoop(int, char const*, int) + 222
11  libG4run.dylib                	0x0000000109f98a69 G4RunManager::BeamOn(int, char const*, int) + 89
12  libG4run.dylib                	0x0000000109fab163 G4MTRunManagerKernel::StartThread(void*) + 1683
13  libsystem_pthread.dylib       	0x00007fff841f62fc _pthread_body + 131
14  libsystem_pthread.dylib       	0x00007fff841f6279 _pthread_start + 176
15  libsystem_pthread.dylib       	0x00007fff841f44b1 thread_start + 13"
Comment 1 kurasige 2014-11-12 09:38:10 CET
Hi,

 G4Exception : PART11117 is just warning. It is not the origin of crush.   
 Which example you use ? I want to know physics list and main program.
Comment 2 Matthew Lund 2014-11-12 22:19:12 CET
The application I built from ground up, all other particle types work fine. The physics list is QBBC, the geometry is a GDML, and I’m using multifunctional detectors. I’ve tried a couple of different geometry files without problems, but run into issues with one that uses Boolean operations in the GDML. I can email you a copy of the application and geometry if it would be useful.

The GDML file that does crash it gives me another strange error I don't get any other time of:
"*** This is just a warning message. ***
-------- WWWW -------- G4Exception-END --------- WWWW -------

G4WT4 > 
G4WT4 > -----------------------------------------------------------
    *** Dump for solid - ICRUSphere15cm ***
    ===================================================
 Solid type: G4Sphere
 Parameters: 
    inner radius: 0 mm 
    outer radius: 150 mm 
    starting phi of segment  : 0 degrees 
    delta phi of segment     : 360 degrees 
    starting theta of segment: 0 degrees 
    delta theta of segment   : 180 degrees 
-----------------------------------------------------------

-------- WWWW ------- G4Exception-START -------- WWWW -------
*** G4Exception : GeomSolids1002
      issued by : G4Sphere::DistanceToOut(p,v,..)
Logic error: snxt = kInfinity  ???
Position:

p.x() = -127.5831469081562 mm
p.y() = -4.099297400684009 mm
p.z() = 78.7797190714615 mm

Rp = 150.0016924942709 mm

Direction:

v.x() = 0.8204060997372815
v.y() = 0.04750928422186836
v.z() = -0.5698040886362497

Proposed distance :

snxt = 9e+99 mm"
Comment 3 Matthew Lund 2014-11-12 23:18:19 CET
I have found the problem is that the source size was bigger than the world size. The interesting issue is that it only crashed with ions and not any other particles, so I didn't notice the issue. When I increased the world size larger than the source, it runs fine. It would be good to have an error message if source surface size exceeds the world volume.
Comment 4 kurasige 2014-11-13 01:08:30 CET
Hi, Matthew,

 Thank you for your report on the origin of the problem.
 I'll forward this to the Geometry coordinator for the further consultation.
Comment 5 Gabriele Cosmo 2014-11-13 09:20:46 CET
The error message you see printed by G4Sphere is symptomatic of the problem you found.
G4Sphere warns you about the fact that it is queried for DistanceToOut() while the point is -outside- the sphere itself. This is a condition which should never happen and is typical of a malformed geometry, likely with overlaps.
I would always suggest to run the overlaps checks when situations like this happen. The overlaps check will spot immediately such problems.
Comment 6 Matthew Lund 2014-11-21 05:29:33 CET
I've ran the geometry check several times, no overlaps. The same is occurring in several other GDML files with no overlaps either. I can recreate it with a simple sphere geometry independent of source sphere size in both 10.00.p2 and 10.01 Beta. The sphere's are set as sensitive detectors.


(In reply to comment #5)
> The error message you see printed by G4Sphere is symptomatic of the problem you
> found.
> G4Sphere warns you about the fact that it is queried for DistanceToOut() while
> the point is -outside- the sphere itself. This is a condition which should
> never happen and is typical of a malformed geometry, likely with overlaps.
> I would always suggest to run the overlaps checks when situations like this
> happen. The overlaps check will spot immediately such problems.