Stuck particles in ion track study with cylinder mesh

Hello everyone!

I’m relatively new, and am having a pretty large issue running a modified version of the microelectronics example where I have lost particle after 25 steps. My goal is to obtain ion radial track energy deposition models, so I am attempting to run an axisymmetric set of bins that run radially from the ion transport. Two major issues arise that may be related:

  1. Issue in dz: In all cases of cylinder mesh creation, the cylinder shown in viewer-0 extends in dz further than which I have defined it to as shown in the image below, notice in comparison to the macro definition. I have tried various sizes in dz ranging from 25nm to 100nm, and the entire dz of the world geometry is 2.5 um.
  2. Issue in dr: When I begin to add more fine mesh, with dr = r-mesh / nBins ~ 5nm/bin, 10nm/bin, I start to see the stuck electrons for both incident protons and heavy ions. At approximately 20nm/bin I have no lost or stuck particles, and hundreds of thousands of secondaries may be created without problem without any being stuck.

Error Output:
-------- EEEE ------- G4Exception-START -------- EEEE -------
*** G4Exception : GeomNav0003
issued by : G4Navigator::ComputeStep()
Stuck Track: potential geometry or navigation problem.
Track stuck, not moving for 25 steps
in volume -cylMesh_1_mesh3- at point (8.70539e-10,-6.36523e-11,-2.265e-05)
direction: (0.000573717,-4.0528e-05,1).
*** Event Must Be Aborted ***
G4Track (0x2b26e40) - track ID = 1, parent ID = 0
Particle type : proton - creator process : not available
Kinetic energy : 19.9974 MeV - Momentum direction : (0.000573717,-4.0528e-05,1)
Step length : 1 Ang - total energy deposit : 0 eV
Pre-step point : (8.70539e-10,-6.36523e-11,-2.265e-05) - Physical volume : World (G4_Si)

  • defined by : cylMesh_1 - step status : 3
    Post-step point : (8.70539e-10,-6.36523e-11,-2.265e-05) - Physical volume : World (G4_Si)
  • defined by : hIoni - step status : 7

I have seen another thread where a user had this sort of issue , but for user created geometries, not meshes per say. Below here is potentially other relevant info for troubleshooting for the mesh creation. Thank you all very much for your time.

Macro Entry
/control/execute vis.mac
/tracking/verbose 0

/gun/particle ion
/gun/ion 36 78 14
#/gun/particle proton
/gun/energy 420 MeV

/score/create/cylinderMesh cylMesh_1
/score/mesh/cylinderSize 500 25 nm
/score/mesh/translate/xyz 0 0 0.85 nm
/score/mesh/nBin 100 1 1
/score/quantity/energyDeposit eDep eV
/score/close

/score/drawProjection cylMesh_1 eDep logColorMap

Detector dimensions:
Detector Geometry:
fWorldSizeX = 10um;
fWorldSizeY = 10
um;
fWorldSizeZ = 2.5*um;

G4double TargetSizeX = 10um;
G4double TargetSizeY = 10
um;
G4double TargetSizeZ = 0.5*um;

Detector Cuts
G4double defCut = 1*nanometer;
cuts->SetProductionCut(defCut,“gamma”);
cuts->SetProductionCut(defCut,“e-”);
cuts->SetProductionCut(defCut,“e+”);
cuts->SetProductionCut(defCut,“proton”);

Try making the world bigger. It does not have to be tight up against the contents.

I will try that out, and thanks for the response.

Could it be that the score class hasn’t been maintained and that the minimum accepted value is that which is being drawn regardless of what value I enter in the macro file?

I have been able to create 15 separate meshes with 1 bin each at 0.2 nm, 0.4nm 0.6 nm … 100nm and annoyingly 15 text files which did not produce any lost particles…

Where creating 1 mesh with any size less than 20nm/bin does create lost particles.