Issue with simulating with very small voxels

[maryamr123]

Hello,

I am having issues with simulating with very small voxels. I input an egsphant into my program with a 0.1 mm x 0.1 mm x 1 mm rectangular scoring geometry. However, I get many stuck particle messages and the doses are recorded as zero. When I visualize the scoring geometry, the voxels are overlapped and only cover a small portion of the actual geometry. When I make the voxels bigger, the visualization of the voxels looks correct, but I still get the stuck particle messages.

I thought it could be that the tolerance value defining the accuracy of tracking on the surfaces was too large so I set it to be relative to my world volume and made the world slightly bigger than my volume so that they would be on the same scale. However, this did not change how the voxels overlap when they are very small.

I am not sure what is going on. Is there a lower limit on voxel size that is causing this or could it be something else? I am using version 10.02.p03. Below is an one of the stuck particle messages.

-------- EEEE ------- G4Exception-START -------- EEEE -------
*** G4Exception : GeomNav0003
issued by : G4Navigator::ComputeStep()
Stuck Track: potential geometry or navigation problem.
Track stuck, not moving for 26 steps
in volume -phantom_phys_real- at point (-0.166564,8.99999e-05,-11.5611)
direction: (-0.956312,0.00057387,0.292348).
*** Event Must Be Aborted ***
G4WT27 > G4Track (0x2b03a0391270) - track ID = 8, parent ID = 2
G4WT27 > Particle type : e- - creator process : RadioactiveDecay, creator model : Undefined
G4WT27 > Kinetic energy : 416.934 keV - Momentum direction : (-0.956312,0.00057387,0.292348)
G4WT27 > Step length : 1 Ang - total energy deposit : 0 eV
G4WT27 > Pre-step point : (-0.166564,8.99999e-05,-11.5611) - Physical volume : phantom_phys_real (Water__0.992752 g/cm3)
G4WT27 > - defined by : CoupledTransportation - step status : 1
G4WT27 > Post-step point : (-0.166564,8.99999e-05,-11.5611) - Physical volume : phantom_phys_real (Water__0.992752 g/cm3)
G4WT27 > - defined by : msc - step status : 7
G4WT27 > *** Note: Step information might not be properly updated.
G4WT27 >
-------- EEEE -------- G4Exception-END --------- EEEE -------

Thanks so much!

[JDecunha]

Hi Maryam,

In my experience, when tracks get stuck the way you describe, it is because of overlapping geometries. This can happen in Geant4 when curved surfaces are coplanar with each other, but since you are working with rectangular prism voxels (which have flat surfaces), it is unexpected.

Your observation that the voxel grid does not span the entire geometry sounds to me like the user code you are working with is somehow defining the voxels on top of each other. Is it possible that your user code is not handling the situation that your voxels have differing X/Y/Z dimensions correctly? I am wondering if you will run into the same issue if you use cubic 1 mm x 1 mm x 1 mm voxels instead.

A potential workaround solution if your geometries have only “small” overlaps is just to introduce a minor buffer region between them. I have had to do this in the past with spherical or cylindrical shell geometries. But because you mention your voxels don’t span the entire geometry the way you expect them to, I expect that you have voxels right on top of each other and just introducing a buffer between them won’t solve the issue.

To address your question about whether Geant4 has a lower limit on voxel size, it does not. Geant4 has a “smart voxel” based internal voxelization system. Something that I am not an expert in, but it should be able to handle voxels regardless of their size.

Some additional information that might be useful for us to troubleshoot the problem includes:

• Further information about how your voxel grid is created (i.e. code snippets)
• Whether your voxel grid resides in a parallel world

Best,

Joseph

[maryamr123]

Hi Joseph,

Thanks so much with your help! I was able to get a good output, it was the visualization system that I was using that was making the voxels look overlapped.

Best,
Maryam