DICOM example Stuck Track error for small voxels

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 !


These warnings are due to precicsion. But they will not stop your run. Why did your job get stopped?

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

Thank you for the help

I would have to run your code to find the problem. You may send it to me privately to pedro.arce@ciemat.es

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 += 100
kCarTolerancestd::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 += kCarTolerance
std::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.

Thank you for your help! Yes, I can see how it can be risky to modify G4Navigator.cc. It may be safer to use larger voxels.

You can check by the messages in G4Navigator how big the push is, and likely it will be harmless. I have used it for my applications without problem.

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.

G4PhantomParameterisation is optimized for fast navigation in 3D voxels, specially if you use SkipEqualMaterials