Opticalphoton TRACK003 error when RINDEX, REALRINDEX, IMAGINARYRINDEX specified for dielectric_metal interface

Hi all, I think I’ve managed to pinpoint a surprising error that has to do with opticalphoton reflection off of a dielectric_metal interface. I’m not sure if this is a bug, but I wanted to create a topic here because this has been a big headache to figure out. I am running Geant4 10.07.p02.

The geometry is this: a 2cm x 2cm x 2cm cube of cerium bromide with refractive index n = 2.09, and a 1mm thick shell of aluminum around the material with one end open. There is a 1mm vacuum (low-density hydrogen) gap between the two. The geometries are not overlapping.

When I specify only the REALRINDEX and IMAGINARYRINDEX for the aluminum (from Cheng et al. 2016), and then wrap the aluminum shell in a G4LogicalSkinSurface, reflection and absorption occur as one would expect. Below is the code used to attach the skin surface, and a screenshot of the expected behavior.

void attachAlOpticalSurface(G4LogicalVolume* lv) 
{
  static G4OpticalSurface* as = nullptr;
  if (as == nullptr) {
    as = new G4OpticalSurface("al_optical_surf");
    as->SetModel(unified);
    as->SetType(dielectric_metal);
    as->SetFinish(polished);
    as->SetMaterialPropertiesTable(
      G4Material::GetMaterial(OptDebugMaterials::kAL)->
      GetMaterialPropertiesTable());
  }   
  (void) new G4LogicalSkinSurface("al_skin_surf", lv, as);
}


An opticalphoton is launched from the center of the cerium bromide cube and has multiple Spike reflections off of the aluminum until it is ultimately absorbed.

Now, when I also specify the RINDEX for the aluminum and its G4OpticalSurface, I consistently receive the following TRACK003 error that the photon is traveling at a velocity greater than c_light and its momentum/energy change is invalid, accompanied by a step length of 0 femtometers:

### Run 1 starts.
G4WT1 > ### Run 1 starts on worker thread 1.
G4WT0 > ### Run 1 starts on worker thread 0.
G4WT1 >   G4ParticleChange::CheckIt    : the velocity is greater than c_light  !!
G4WT0 > Thread-local run terminated.
G4WT1 >   Velocity:  2.94179
G4WT1 > opticalphoton E=3e-06 pos=-0.0105, 0.000304477, -0.00273335
G4WT0 > Run Summary
G4WT1 >       -----------------------------------------------
G4WT0 >   Number of events processed : 0
G4WT1 >         G4ParticleChange Information  
G4WT0 >   User=0.000000s Real=0.000003s Sys=0.000000s [Cpu=0.0%]
G4WT1 >       -----------------------------------------------
G4WT1 >         # of 2ndaries       :                    0
G4WT1 >       -----------------------------------------------
G4WT1 >         Energy Deposit (MeV):                    0
G4WT1 >         Non-ionizing Energy Deposit (MeV):                    0
G4WT1 >         Track Status        :                Alive
G4WT1 >         True Path Length (mm) :                    0
G4WT1 >         Stepping Control      :                    0
G4WT1 >     First Step In the voulme  : 
G4WT1 >         Mass (GeV)   :                    0
G4WT1 >         Charge (eplus)   :                    0
G4WT1 >         MagneticMoment   :                    0
G4WT1 >                 :  =                    0*[e hbar]/[2 m]
G4WT1 >         Position - x (mm)   :                -10.5
G4WT1 >         Position - y (mm)   :                0.304
G4WT1 >         Position - z (mm)   :                -2.73
G4WT1 >         Time (ns)           :                0.139
G4WT1 >         Proper Time (ns)    :                    0
G4WT1 >         Momentum Direct - x :                0.983
G4WT1 >         Momentum Direct - y :               0.0204
G4WT1 >         Momentum Direct - z :               -0.183
G4WT1 >         Kinetic Energy (MeV):                3e-06
G4WT1 >         Velocity  (/c):                 2.94
G4WT1 >         Polarization - x    :               -0.184
G4WT1 >         Polarization - y    :                0.109
G4WT1 >         Polarization - z    :               -0.977
G4WT1 >         Touchable (pointer) :       0x7f9df0cc3a10
G4WT1 > 
-------- EEEE ------- G4Exception-START -------- EEEE -------
*** G4Exception : TRACK003
      issued by : G4ParticleChange::CheckIt()
momentum, energy, and/or time was illegal
*** Event Must Be Aborted ***
G4WT1 > G4Track (0x7f9df0cc3530) - track ID = 1, parent ID = 0
G4WT1 >  Particle type : opticalphoton - creator process : not available
G4WT1 >  Kinetic energy : 3 eV  - Momentum direction : (0.982861,0.0204087,-0.183213)
G4WT1 >  Step length : 0 fm  - total energy deposit : 0 eV 
G4WT1 >  Pre-step point : (-10.5,0.304477,-2.73335) - Physical volume : al_phys (aluminum)
G4WT1 >  - defined by : Transportation - step status : 1
G4WT1 >  Post-step point : (-10.5,0.304477,-2.73335) - Physical volume : al_phys (aluminum)
G4WT1 >  - defined by : Transportation - step status : 1
G4WT1 >  *** Note: Step information might not be properly updated.
G4WT1 > 
-------- EEEE -------- G4Exception-END --------- EEEE -------

G4WT1 >   G4ParticleChange::CheckIt    : the velocity is greater than c_light  !!
G4WT1 >   Velocity:  2.94179
G4WT1 > opticalphoton E=3e-06 pos=-0.0105, 0.000304477, -0.00273335
G4WT1 >       -----------------------------------------------
G4WT1 >         G4ParticleChange Information  
G4WT1 >       -----------------------------------------------
G4WT1 >         # of 2ndaries       :                    0
G4WT1 >       -----------------------------------------------
G4WT1 >         Energy Deposit (MeV):                    0
G4WT1 >         Non-ionizing Energy Deposit (MeV):                    0
G4WT1 >         Track Status        :                Alive
G4WT1 >         True Path Length (mm) :                    0
G4WT1 >         Stepping Control      :                    0
G4WT1 >     First Step In the voulme  : 
G4WT1 >     Last Step In the voulme  : 
G4WT1 >         Mass (GeV)   :                    0
G4WT1 >         Charge (eplus)   :                    0
G4WT1 >         MagneticMoment   :                    0
G4WT1 >                 :  =                    0*[e hbar]/[2 m]
G4WT1 >         Position - x (mm)   :                -10.5
G4WT1 >         Position - y (mm)   :                0.304
G4WT1 >         Position - z (mm)   :                -2.73
G4WT1 >         Time (ns)           :                0.139
G4WT1 >         Proper Time (ns)    :                    0
G4WT1 >         Momentum Direct - x :                0.983
G4WT1 >         Momentum Direct - y :               0.0204
G4WT1 >         Momentum Direct - z :               -0.183
G4WT1 >         Kinetic Energy (MeV):                3e-06
G4WT1 >         Velocity  (/c):                 2.94
G4WT1 >         Polarization - x    :               -0.184
G4WT1 >         Polarization - y    :                0.109
G4WT1 >         Polarization - z    :               -0.977
G4WT1 > 
-------- EEEE ------- G4Exception-START -------- EEEE -------
*** G4Exception : TRACK003
      issued by : G4ParticleChange::CheckIt()
momentum, energy, and/or time was illegal
*** Event Must Be Aborted ***
G4WT1 > G4Track (0x7f9df0cc3530) - track ID = 1, parent ID = 0
G4WT1 >  Particle type : opticalphoton - creator process : not available
G4WT1 >  Kinetic energy : 3 eV  - Momentum direction : (0.982861,0.0204087,-0.183213)
G4WT1 >  Step length : 0 fm  - total energy deposit : 0 eV 
G4WT1 >  Pre-step point : (-10.5,0.304477,-2.73335) - Physical volume : al_phys (aluminum)
G4WT1 >  - defined by : Transportation - step status : 1
G4WT1 >  Post-step point : (-10.5,0.304477,-2.73335) - Physical volume : World (vacuum)
G4WT1 >  - defined by : Transportation - step status : 1
G4WT1 >  *** Note: Step information might not be properly updated.
G4WT1 > 
-------- EEEE -------- G4Exception-END --------- EEEE -------

G4WT1 > Thread-local run terminated.
G4WT1 > Run Summary
G4WT1 >   Number of events processed : 1
G4WT1 >   User=0.050000s Real=0.048872s Sys=0.010000s [Cpu=122.8%]
 Run terminated.
Run Summary
  Number of events processed : 1
  User=0.070000s Real=0.069784s Sys=0.010000s [Cpu=114.6%]

Again, I’m not sure if this is a bug or just unexpected (but appropriate) behavior.

For now the solution is to not specify the RINDEX of dielectric_metal interfaces and only specify REALRINDEX and IMAGINARYRINDEX. This being said, I think this surprising behavior warrants further investigation and discussion.

Hi. I’m not sure if this is applicable, but if I am understanding it correctly, the following suggests that RINDEX should not have an effect for an optical surface.

From Erik Dietz-Laursonn, “Peculiarities of Geant4 Optical Processes”, arXiv:1612.05162v1, 2016:
“The refractive index is not a surface property but a material property. Therefore, assigning
it to a G4OpticalSurface has no effect. However, exceptions are G4OpticalSurfaces
with the surface finishes named “-backpainted”. Here, a refractive index has to be
defined, which is interpreted as the refractive index of the medium in the gap between
the painted volume and the paint.”

It’s not clear to me what’s going on.

  • As John notes, a surface doesn’t have an RINDEX unless it is backpainted.
  • Specifying REALRINDEX and IMAGINARYRINDEX for a material (volume) doesn’t specify a complex index of refraction for the material. Rather, it calculates the absorption at the surface (as an approximation to the real absorption at a shallow depth in the material).
  • Thus, specifying REALRINDEX and IMAGINARYRINDEX for both the surface and material is redundant, or worse.
  • There is an open bug report, and one recently fixed, about the velocity being set incorrectly after boundary interaction. I don’t know if it’s related.

Can you clarify for me what is specified when the error occurs? It looks like RINDEX, REALRINDEX, IMAGINARYRINDEX for both the Al volume and the surface.

Hi John, Daren, thanks for the replies.

  • In the situation with no errors, REALRINDEX and IMAGINARYRINDEX are set for both the G4Material and the G4OpticalSurface.
  • In the situation with errors, REALRINDEX, IMAGINARYRINDEX, and RINDEX are set for both the material and the optical surface.
  • A third situation I have tested but did not mention in the original post is specifying RINDEX only for the G4Material, and then IMAGINARYRINDEX and REALRINDEX only for the surface. This leads to the same TRACK003 error. So maybe this is the real issue here.

As John pointed out, assigning an RINDEX to the surface of type dielectric_metal and finish polished should have “no effect,” so that’s why I’m confused by the associated TRACK003 error.

I will update my Geant installation to 11.0 and see if it resolves this issue. It could be that same velocity calculation bug that you’ve mentioned Daren. I was just surprised by the behavior and thought it could be useful information to post here for others who might run into similar issues.

Updating to v11.0 seems to resolve this issue. Maybe it was related to that group velocity issue #2438 that you alluded to. Thanks for the tip!

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.