Problem 76

Summary:	Infinite loop when changing from one volume to the other
Product:	Geant4	Reporter:	Carlos.Lacasta
Component:	geometry/solids	Assignee:	Vladimir.Grichine
Status:	RESOLVED FIXED
Severity:	critical	CC:	Carlos.Lacasta
Priority:	P2
Version:	1.0
Hardware:	PC
OS:	Linux

Description Carlos.Lacasta 2000-03-28 13:28:31 CEST

I enter an infinite loop when changing from one volume to another in some
situations that I cannot specify. It does not happen everytime, but quite often.
 I managed to reproduce the problem with a simple program.
I put a compressed tar file with the source in the URL below. If you could tell
me what is wrong there I would be very grateful.

Thanks in advance,

		Carlos

Comment 1 Gabriele Cosmo 2000-04-10 04:36:59 CEST

The problem has been reproduced in the reference tag "geant4-01-01-ref-01".
The platform to be used is "Linux-g++".
The original code has been re-arranged to adapt it to the standard Geant4
configuration and build mechanism. Also the "user-defined" UIManager has been
deactivated since was causing an infinite loop in interactive-mode (it's very
bad practice to explicitly redefine/override in the user code classes/methods
belonging to the G4 kernel!).
The rearraged code is available in my public AFS area at CERN:
   ~gcosmo/public/bug76
An infinite loop occurs in G4Transportation/G4Navigator after 34 events and is
due to a zero step-length in the physical interaction length. It looks to me an
old problem. Here is a trace during the loop:

0x8130711 in G4Transportation::AlongStepGetPhysicalInteractionLength ()
          at src/Hit.cc:7
7	G4Allocator<GenHit> HitAllocator;
(gdb) where
#0  0x8130711 in G4Transportation::AlongStepGetPhysicalInteractionLength ()
                 at src/Hit.cc:7
#1  0x811d7fd in G4SteppingManager::Stepping () at src/Hit.cc:7
#2  0x81169fd in G4TrackingManager::ProcessOneTrack () at src/Hit.cc:7
#3  0x810c535 in G4EventManager::ProcessOneEvent () at src/Hit.cc:7
#4  0x80fbffa in G4RunManager::DoEventLoop () at src/Hit.cc:7
#5  0x80fbbb2 in G4RunManager::BeamOn () at src/Hit.cc:7
#6  0x8103729 in G4RunMessenger::SetNewValue () at src/Hit.cc:7
#7  0x81bae3e in G4UIcommand::DoIt () at src/Hit.cc:7
#8  0x81cc8fd in G4UImanager::ApplyCommand () at src/Hit.cc:7
#9  0x80e001f in G4UIterminal::ExecuteCommand () at src/Hit.cc:7
#10 0x80df0e8 in G4UIterminal::SessionStart () at src/Hit.cc:7
#11 0x804eb6b in main (argc=1, argv=0xbffff314) at loop.cc:71

Comment 2 John Apostolakis 2000-05-16 10:31:59 CEST

This problem is due to an incorrect behaviour of G4Tubs.
For the Tubs with the following parameters:

fRMin = 750, fRMax = 760, fDz = 350, fSPhi = 0.31415926535897931, fDPhi =
5.6548667764616276}

the ray with parameters

Point     = {dx = -388.20504321896431, dy = -641.71398957741451, dz =
332.85995254027955}
Direction = {dx = -0.47312863350457468, dy = -0.782046391443315, dz =
0.40565100491504164}

returns DistanceToIn and DistanceToOut equal to 0.0
This cannot be correct according to the specifications.

Comment 3 John Apostolakis 2000-05-16 11:38:59 CEST

*** Bug 91 has been marked as a duplicate of this bug. ***

Comment 4 Vladimir.Grichine 2000-05-17 11:59:59 CEST

bug fixed in G4Tubs::DistanceToOut

Comment 5 John Apostolakis 2000-05-17 13:08:59 CEST

I have verified that the fix in G4Tubs resolves the problem.

It should now be tagged and tested in the system tests, before being released.