I am able to run the DICOM example correctly with the given input files. I then tried making the voxel dimension smaller in the input files to better match the data that I plan to use. To do this I changed the x and y start positions in the g4dcm files.
The original files had x and y positions starting at -196 and ending at 196, with 128 x 128 pixels per slice. This represents a voxel size of 3.06 mm x 3.06 mm x 5 mm, and the example runs correctly.
Next, I changed the x and y extents to range from -100 to 100, while keeping 128 x 128 pixels, representing a voxel size of 1.5625 mm x 1.5626 x 5. The example runs correctly.
Next, I changed the x and y extents to -64 to 64, while keeping 128 x 128 pixels, representing a voxel size of 1 mm x 1 mm x 5 mm. The example does not run to completion. I have multiple warnings about track stuck as shown below.
I have tried this using geant 4.10.7 and geant 4.11.01, with both having the same behavior. I need to resolve this because I’d like to run similar simulations on geometries with small voxels.
Help is much appreciated!
-------- 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: ‘phantom’
at position : (-4,0.3343033836104761,94.85337598977979)
in direction: (-0.9890178232735505,0.1477913358529212,0.001210906295663006)
(local position: (-0.5,-0.1656966163895239,2.353375989779792))
(local direction: (-0.9890178232735505,0.1477913358529212,0.001210906295663006)).
Previous phys volume: ‘phantom’
Likely geometry overlap - else navigation problem !
*** Trying to get unstuck using a push - expanding step to 1e-07 (mm) … Potential overlap in geometry !
Thank you for the response. Is there a setting that will improve precision or is it better to combine voxels to be larger? The job hangs in the middle of an event and does not complete. Here is a portion of screen output just before the job hangs:
-------- 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: ‘phantom’
at position : (-4,0.3343033836104761,94.85337598977979)
in direction: (-0.9890178232735505,0.1477913358529212,0.001210906295663006)
(local position: (-0.5,-0.1656966163895239,2.353375989779792))
(local direction: (-0.9890178232735505,0.1477913358529212,0.001210906295663006)).
Previous phys volume: ‘phantom’
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 -------
G4WT1 > → Event 97 starts with initial seeds (50004346,57284234).
G4WT1 > → Event 98 starts with initial seeds (26774279,52091547).
G4WT1 > → Event 99 starts with initial seeds (90282064,7958963).
This is where it stops and does not finish running
Thanks, Pedro. The code is one of the examples that comes with Geant4 examples/extended/medical/DICOM
I only changed the three input files 1.g4dcm, 2.g4dcm, and 3.g4dcm, by changing the -196 and 196 on lines 13 and 14 to -64 and 64, respectively. Please let me know if you’d still like me to send the code.
I found a solution for your problem: make that G4Navigator.cc pushes the track by a small step (this is a usual solution of G4Navigator, but I modified it to make the step bigger each time, until it exits the loop). You just have to change in G4Navigator.cc
Step += 100kCarTolerance;
by
Step += 100kCarTolerancestd::pow(10.,fNumberZeroSteps);
And if you want to avoid the warning messages comment them out, or add an extra push before (right after G4bool inform = false;):
Step += kCarTolerancestd::pow(10.,fNumberZeroSteps);
so that it never reaches a big number of contiguous zero steps.
This solution has some risk, although I used it without detecting any problem. But you have to use it under your responsibility.
This problem has been perplexing me because in the past I know we have worked with smaller voxels and the AAPM Task Group 195 Monte Carlo Benchmarking report has an example with 1 mm^3 voxels that we previously used as a benchmark. I think I have figured out the issue. In the past we used the Nested Parameterisation, and this seems to work fine for small voxels. This is what was used for the TG 195 report as well. The example I described above works fine for small voxels when the Nested Parameterisation environment variable is set. Thank you for your help.
Prof. Acre,
G4Navigator problems solved and your solution worked for me. SetSkipEqualMaterials(TRUE); in the phantomparameterize. Thanks so much for sharing the solution here.
Best Regards
Prof. Acre,
Hi, I have used your solution in my small voxel DICOM(0.97656250.97656253mm). However, there will be a wrong dose depoited when the direciton of primary particles is negative. The first one or two layer will have much more dose while the interface of patient have nearly 0 Gy. Could you please tell me some ideas to solve the problem? I will appreciate it sincerely!
Best wishes
Hi all,
I was having the same issue with DICOM/Parameterised voxel geometries, where the simulation got stuck on certain events depending on the set seed, and implemented the change suggested. In doing so I came across this in G4Navigator.cc (v11-1-p2):
#ifdef G4VERBOSE
if ( fWarnPush ) { CheckOverlapsIterative(motherPhysical); } #endif
which starts an iterative overlap check in case the track was pushed more often than the threshold for zero steps. For a CT with millions of voxels or a mesh with very many faces, an overlap check can take a very long time, hence it seems to me this could be what has caused the OP’s “stops and does not finish running” issue. For me, getting rid of the overlap check solved the issue of the unfinished simulations.
For my purposes (medical research), simply abandoning an event is better than having the simulation get stuck for a long time, especially when running on a cluster with specified user runtime. Is there a G4 internal reason the overlap check needs to be performed automatically at this point?
I remember this happened to me long time ago. I think Geant4 should send a message telling users that it is entering in a very long check. Could this be done, John Apostolakis?
