| Summary: | steplength less than kcarTolerance causes assertion failure | ||
|---|---|---|---|
| Product: | Geant4 | Reporter: | dcasper |
| Component: | processes/transportation | Assignee: | John Apostolakis <John.Apostolakis> |
| Status: | CLOSED REMIND | ||
| Severity: | critical | CC: | Simone.Giani, Vladimir.Grichine |
| Priority: | P4 | ||
| Version: | 2.0 | ||
| Hardware: | All | ||
| OS: | All | ||
Thanks for the detailed report submitted. The problem is under investigation. This check in G4Transportation has existed for the purpose of helping to identify problems in the geometry/Navigator module or in the user's definition of his/her geometry. We believe that for production usage it is unneccessary and, as this report demonstrates, also dangerous. As such, it was protected by the G4VERBOSE flag - whereas for production use we encourage compiling the Geant4 libraries with a G4_NO_VERBOSE environment variable - so it should not appear in the production code if these guidelines are followed. Given the well documented issues from this report we have decided to further protect and reevaluate this check. First we will ensure that it is utilised only where the user or developer specifically requests them. To do this we have changed the flag from G4VERBOSE to G4DEBUG_TRANSPORT to ensure that only those wishing to check whether their application or the geometry module is experiencing difficulties at boundaries will encounter them. This change is being tested, and will, once passed, be released with the next patch or public release. We will also provide it promptly to any affected users. The relevant code has been deleted - as the navigator worked better without it. Thank you for the report. |
I have found a problem which originates with the assertion in G4Transportation ("ERROR: A relocation within safety has caused a volume change!...") The transportation code is complex, but here is a summary of what I think is the problem. Suppose I am generating many Cherenkov photons (the problem could happen with any type of particle, I think). For the purposes of explanation, let's suppose there are two nested volumes - an inner one which is totally transparent (such that nothing but transportation happens inside it) and an outer one which is almost totally absorbing (such that photons are absorbed almost immediately when they enter it). Thus a photon entering the outer (absorbing) volume will have a very small PhysicalStepLength. No matter what I set the numerical tolerance to, there is always a finite probability that some process (absorption in this case, but it could be any physical process on any type of particle) will return a step size which is less than the tolerance, because as far as I can see, there is no minimum step size. In the case of a water cerenkov detector, there are can be millions of photons tracked per event, and 10's of thousands of events generated in a MC production, so if the probability of interaction in a distance less than the tolerance is greater than about 1.e-10, the program will fail. Once a particle interacts within a distance less than tolerance after crossing a boundary between two volumes, the assertion in G4Transportation will fail, because it eventually calls G4Navigator::LocateGlobalPointAndUpdateTouchable which calls G4NormalNavigation::LevelLocate which calls G4AuxiliaryNavServices::CheckPointOnSurface which decides the point (which is really in the outer volume) is in the *inner* volume because the step was not geometry limited and the new point is within tolerance of the edge of the inner volume. I may be missing something, but it seems like there should be a check that no physical stepsize smaller than the tolerance is ever used (in G4Transportation?). If a process returns a stepsize less than tolerance, it should be rounded up to tolerance, I think.