Created attachment 707 [details] reduced example for the original G4Tubs and a G4Box (Problem discovered with https://github.com/hahnjo/G4FullEventSim and the default cms2018_gg2ttbar.mac when upgrading from 10.7-patch01 to -patch02, but the change in the default isomer production cut just leads to different RNG numbers exposing a problem in the solids.) For points very close to surfaces, if the transformation to local points exhibits different rounding errors, tracks might get stuck with a scary looking warning message: -------- WWWW ------- G4Exception-START -------- WWWW ------- *** G4Exception : GeomNav1002 issued by : G4Navigator::ComputeStep() Stuck Track: potential geometry or navigation problem. Track stuck, not moving for 10 steps. Current phys volume: 'TECICBCont8F2' - at position : (-128.6897741334133,-839.7022809450838,-2638.8919999995) in direction: (0.08728666264411181,0.672921708492526,-0.7345457186342814) (local position: (839.7022809450839,128.6897741334131,1.110999999500109)) (local direction: (-0.6729217084925259,-0.08728666264411176,0.7345457186342815)). Previous phys volume: 'TECPetalCont8F' Likely geometry overlap - else navigation problem ! *** Trying to get *unstuck* using a push - expanding step to 1e-07 (mm) ... Potential overlap in geometry ! *** This is just a warning message. *** -------- WWWW -------- G4Exception-END --------- WWWW ------- Upon closer investigation, the problem seems to be that slightly different points are passed to DistanceToOut and DistanceToIn: ToOut: (839.70228094508388, 128.68977413341307, 1.110999999500109) ToIn: (839.70228094508388, 128.68977413341307, 1.1109999994999855) As can be seen in the reduced example, this makes both methods return 0. This leads to the navigator popping in and out of the volume without making progress.
Hi Jonas, I've checked that if to pass the same points to DistanceToIn() and DistanceToOut() the the methods correctly return different values: From cms2018.gdml: DistanceToOut: 0 DistanceToIn: 0 DistanceToOut(pDistanceToOut) : 0 DistanceToIn (pDistanceToOut): 9e+99 DistanceToOut(pDistanceToIn) : 6.80713e-10 DistanceToIn (pDistanceToIn): 0 box DistanceToOut: 0 DistanceToIn: 0 DistanceToOut(pDistanceToOut) : 0 DistanceToIn (pDistanceToOut): 9e+99 DistanceToOut(pDistanceToIn) : 6.80713e-10 DistanceToIn (pDistanceToIn): 0 So, there is nothing to fix in the code of G4Tubs/G4Box. The bug is in passing "slightly different points to DistanceToOut and DistanceToIn". Evgueni
> So, there is nothing to fix in the code of G4Tubs/G4Box. The bug is in passing "slightly different points to DistanceToOut and DistanceToIn". Ideally yes, but with floating point arithmetic you can easily get rounding errors at some point when applying the transformations. That's exactly what is happening here, the global point is the same for the two code paths leading to DistanceToOut / DistanceToIn: in TECPetalCont8F -> transform global point local point in TECPetalCont8F -> when sampling DistanceToIn for TECICBCont8F2: transform local point in TECPetalCont8F to local point in TECICBCont8F2 -> DistanceToIn returns 0, so move into the daughter volume in TECICBCont8F2 -> transform global point to local point in TECICBCont8F2 (directly) -> DistanceToOut returns 0, so leave the volume again
It is a problem of the code that transforms the same point to the same local space by two different paths, but expects the same return values from DistanceToIn/Out. In reality it is two different points, which are located differently relative to the solids: pDistanceToOut is on Surface, pDistanceToIn is Inside. The solids work correctly for both of the points, the problem should be fixed in the navigation code.
