| Summary: | Stuck particles with G4ScoringManager /score/create/boxMesh | ||
|---|---|---|---|
| Product: | Geant4 | Reporter: | Iwan Cornelius <iwancornelius> |
| Component: | processes/scoring | Assignee: | Gabriele Cosmo <Gabriele.Cosmo> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | asai, Gabriele.Cosmo, perl |
| Priority: | P5 | ||
| Version: | 9.6 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Attachments: | example simulation to reproduce problem | ||
I believe this is the same bug that appears in the user forum as: http://hypernews.slac.stanford.edu/HyperNews/geant4/get/geometry/1243.html I think it's a fairly basic problem that we just didn't realize because we are generally focused on external beams hitting our detectors rather than point sources within our detectors. Here's what I do to reproduce the problem. Place an isotropic point source at the center of the world. Place a nested parameterization box at the center of the world. If the box is undivided, no problem. If the box is divided into an even number of voxels, I see many track stuck warnings. If the box is divided into an odd number of voxels, I do not see track stuck warnings. The behavior is consistent whether I divided the box by a small even number, such as 2 x 2 x 2 (gives problems) or 3 x 3 x 3 (no problems), or by a large even number, such as 200 x 200 x 200 (gives problems) or 201 x 201 x 201 (no problems). If the box is divided into an even number of voxels, but I offset my box from the center of the world, even by a tiny bit, the warnings go away. In my case, I am using 200 MeV protons with a modular physics list consisting only of g4em-standard_opt0. But I do not believe the particle type or physics list is the issue. Thank you for reporting this problem. It seems the problem is for a track whose initial location is exactly on the boundary of parallel world replicas. We will look into this. Added work-around in G4Navigator and G4ReplicaNavigation to relax condition for zero or almost-zero steps and allow for faster convergence. Verified that provided test-case now no longer loops. The fix will be included in patches to release 10.1 and 10.2 series. |
Created attachment 202 [details] example simulation to reproduce problem A student came across a problem whilst using the scoring manager (/score/create/boxMesh) to create a cartesian scoring mesh. The problem arises when the particle trajectory lies on one of the planes that define the mesh. In this situation a very small step length is returned (1e-16 in our case). The particle isn't considered stuck, but effectively it is. I have attached a simple simulation to reproduce the problem. In this case (for beam along z-axis) the problem is alleviated by either shifting the primary beam a little so that it doesn't lie on the plane, or having an odd number of scoring volumes in directions orthogonal to beam direction (again to avoid this condition). I hope this helps. Best Regards, Iwan