We found that a primary particle at (0,0,0) is wrongly assigned to a volume (a polycone with a substructed box). The particle is tracked until it decays getting much farther that the World limits. Then when the secondary particle starts being tracked it crashes. The "tracking/verbose" is 0 -917 -930 -511 0.502 0 0 0 EBRY_42_E5AL initStep 1 -918 -930 -511 0 0.502 0.379 0.379 EBRY_42_E5AL eIoni ********************************************************************************************************* * G4Track Information: Particle = pi+, Track ID = 183, Parent ID = 0 ********************************************************************************************************* Step# X(mm) Y(mm) Z(mm) KinE(MeV) dE(MeV) StepLeng TrackLeng NextVolume ProcName 0 0 0 0 327 0 0 0 ESPM initStep 1 1.81 -7.42 -8.81 327 0.00102 11.7 11.7 ESPM hIoni 2 14.4 -59.1 -70.1 327 0.0138 81.2 92.8 ESPM hIoni 3 20.5 -84.4 -100 327 0.00623 39.7 133 ESPM hIoni .... 3134 1.6e+04 -7.21e+04 -8.3e+04 301 0.00318 14.9 1.11e+05 ESPM hIoni 3135 1.6e+04 -7.21e+04 -8.3e+04 301 0.00552 29.9 1.11e+05 ESPM hIoni 3136 1.6e+04 -7.22e+04 -8.3e+04 301 0.0012 9.19 1.11e+05 ESPM Decay ********************************************************************************************************* * G4Track Information: Particle = mu+, Track ID = 517989, Parent ID = 183 ********************************************************************************************************* Step# X(mm) Y(mm) Z(mm) KinE(MeV) dE(MeV) StepLeng TrackLeng NextVolume ProcName 0 1.6e+04 -7.22e+04 -8.3e+04 191 0 0 0 DDDWorld initStep *** Break *** segmentation violation Generating stack trace... /usr/bin/addr2line: cmsRun: No such file or directory /usr/bin/addr2line: cmsRun: No such file or directory 0x05e74ee0 in G4Navigator::ComputeStep(CLHEP::Hep3Vector const&, CLHEP::Hep3Vector const&, double, double&) + 0xeb0 from /afs/cern.ch/cms/external/lcg/external/geant4/7.1/slc3_ia32_gcc323/lib/libG4navigation.so 0x06f5b923 in G4Transportation::AlongStepGetPhysicalInteractionLength(G4Track const&, double, double, double&, G4GPILSelection*) + 0x41b from /afs/cern (EBRY_42_E5AL is a subvolume of ESPM) The solution that works for us is avoiding that for primary tracks the volume search is done relatively to the last step of the previous track (that indeed does not have any relationship with it). That is substitute fNavigator->LocateGlobalPointAndSetup( fTrack->GetPosition(), &direction, true, false ); by fNavigator->LocateGlobalPointAndSetup( fTrack->GetPosition(), &direction, false, false ); G4SteppingManager::SetInitialStep
I had a discussion on this problem with John in e-mail and beleive that investigation in the navigator is necessary.
It appears that there are several issues connected with this problem: - the pion track continues inside the ESMP volume, despite apparently crossing its boundary - the generated secondary (mu+, Track ID = 517989) is as a result created at (x,y,z)= (1.6e+04 -7.22e+04 -8.3e+04) mm, which is outside the world volume - No touchable for this point appears to be passed to the secondary - the SteppingManager asks for a relative location in the case of secondary without a touchable handle (which is generally good, as most tracks are created in the same or nearby volumes from the last track); - the position and the resulting volume as located. These are not rejected by the Tracking (because the current volume returned by touchable is not null.) - the Navigator finds a serious problem, resulting in the core dump from the ComputeStep method. It is not clear whether the Navigator correctly identifies the volume of the new track. There is a weakness in 'flagging' the out-of-world condition in the LocateGlobalPointAndSetup method, which I will work to correct. I expect that this should address the likely cause of this behaviour. Regards, John Apostolakis
Problem no longer applicable. Ticket being closed.
