Problem 2314

Summary: G4RegularNavigation is broken
Product: Geant4 Reporter: Christian Körnig <ckoernig>
Component: geometry/navigationAssignee: Pedro.Arce
Status: RESOLVED FIXED    
Severity: major CC: shingyu.kim
Priority: P4    
Version: 10.7   
Hardware: All   
OS: All   
Attachments: G4RegularNavigation.cc

Description Christian Körnig 2021-01-22 14:16:35 CET
Created attachment 660 [details]
G4RegularNavigation.cc

The G4RegularNavigation is producing large amounts of Exceptions indicating that the track is stuck when small voxels (~100um edge length) are used.
This issue was introduced with the fix for issue 2196.
https://bugzilla-geant4.kek.jp/show_bug.cgi?id=2196

I had posted a possible solution over there, but I guess it was not seen as the problem is already marked as fixed.

Please find attached my approach for the bugfix.
I have used this is the last months with several hundred hours of runtime without issues, but I am not sure about the Geant4 naming conventions.
Comment 1 Pedro.Arce 2021-01-27 16:17:49 CET
The difference between your solution and mine is the following:

You: when there are more than 10000 small steps (< kCarTolerance) you abort the event)

Me: I loop 10000 steps, so there can never be more than those (if the step number reaches 10000, I abort the event)
Each step (after a few initial steps for which I push kCarTolerance) is pushed  std::min(101*kCarTolerance*pow(10,fNumberZeroSteps-2),0.1);

I think that my solution is better.
But every time there is a small step, I send a warning message, while you sent none. This is the difference that causes the big output

I will protect this message with a fWarnPush, which will only be active if the user has compiled with G4VERBOSE=ON

I consider the bug resolved, tell me if you do not agree
Comment 2 Pedro.Arce 2021-01-27 18:20:41 CET
I finally decided to protect the excessive warnings under @ifdef G4DEBUG_NAVIGATION. It is a safer choice to avoid you or other users having the screen filled with those messages
Comment 3 Christian Körnig 2021-01-27 18:33:12 CET
I am currently testing your solution. I think, it is also important to reset the fNumberZeroSteps to 0 when a correct step was made. 
Otherwise I got several tracks killed which got stuck a few times but could be recovered after each first consecutive push.

Additionally, I get a lot of the following Exceptions (2800 exceptions in 100000 events):
-------- WWWW ------- G4Exception-START -------- WWWW -------
*** G4Exception : GeomNav1002
      issued by : G4PhantomParameterisation::GetReplicaNo()
Corrected the copy number! It was negative or too big
          LocalPoint: (10.4,-11.8785,2.6816)
          LocalDir: (-0.695189,-0.625715,-0.353825)
          Voxel container size: 10.4 49.6 19
          LocalPoint - wall: -1.77636e-15 -61.4785 -16.3184
*** This is just a warning message. ***
-------- WWWW -------- G4Exception-END --------- WWWW -------


This happens with both my and your solution in 10.7 but not in 10.5.
Comment 4 Pedro.Arce 2021-03-11 20:57:02 CET
I do not understand your point: fNumberOfZeroSteps is set to 0 at the beginning of G4RegularNavigation::ComputeStepSkippingEqualMaterials

About the second point, it is just a warning that a precision problem has been corrected (see your LocalPoint - wall: -1.77636e-15 ). You can deactivate the warning: surround it by 
#ifdef G4DEBUG_NAVIGATION
 
Probably it is a good idea that I do the same for the release
Comment 5 Christian Körnig 2021-03-17 14:31:10 CET
I am not sure but I assume, this happened in an area of my voxel model where the material does not change over a longer path (which is quite typical for some medical voxel models), so the navigator stays in the same function call.

Regarding the message: If this is not an issue, it would be good to deactivate it for the next release. As a user, a flooded error log is hard to judge as normal and real errors are getting lost between all those debug messages.
Comment 6 Gabriele Cosmo 2021-04-20 17:35:42 CEST
*** Problem 2359 has been marked as a duplicate of this problem. ***
Comment 7 Pedro.Arce 2021-09-25 15:54:44 CEST
I have added 
    if( fabs(localPoint.x()-fContainerWallX) > kCarTolerance &&
        fabs(localPoint.y()-fContainerWallY) > kCarTolerance &&
        fabs(localPoint.z()-fContainerWallZ) > kCarTolerance ){    // only if difference is big                 
 
This I think would be enough. I will put it in the next release