As was suggested at the G4 workshop, this is now a formal bug-report: When using G4IntersectionSolid the navigator behaves real strange. I have put a compressed tar-ball of this example at: http://trshare.triumf.ca/~gum/makonyik.tar.Z The problem is that the G4Navigator sometimes fails to make a zero-length step (in the next volume beyond the boundary) upon reflection. Instead, the step is much longer and after that the tracking stops all together. G4OpBoundary has reflected the track direction though the volume identified is that of what's beyond the surface. An example from test.out in the tar-ball: ********************************************************************************************************* * G4Track Information: Particle = opticalphoton, Track ID = 1, Parent ID = 0 ********************************************************************************************************* Step# X Y Z KineE dEStep StepLeng TrakLeng Volume Process 0 0 fm 0 fm -0 fm 3 eV 0 eV 0 fm 0 fm guide initStep Photon at Boundary! Old Momentum Direction: (-0.76093104,-0.09179635,-0.6423063) Old Polarization: (-0.99500417,-0.099833417,0) theLocalNormal: (0.9949054,0.10081294,-0) New Momentum Direction: (0.7638782,0.062711314,-0.6423063) New Polarization: (-0.99480567,-0.10179237,-0) *** SpikeReflection *** 1 -22.2 cm -2.68 cm -18.7 cm 3 eV 0 eV 29.2 cm 29.2 cm guide Transportation 2 -14.1 cm -2.01 cm -25.6 cm 3 eV 0 eV 10.6 cm 39.8 cm World Transportation Track (trackID 1, parentID 0) is processed with stopping code 2 Besides the line that prints 'theLocalNormal' the above printout is the default from G4OpBoundaryProcess verbose=1. You see that G4OpBoundaryProcess calculates a new direction from the old direction and the normal. You can verify that the angle of incidence with the normal is the same as the angle on reflection and the directions are opposite, thus we have 'SpikeReflection'. In this case, the next step should be in the 'World' but with zero length, instead it is 10.6cm and then the track just stops. There are also cases in test.out where reflection behaves normally: ********************************************************************************************************* * G4Track Information: Particle = opticalphoton, Track ID = 1, Parent ID = 0 ********************************************************************************************************* Step# X Y Z KineE dEStep StepLeng TrakLeng Volume Process 0 0 fm 0 fm -0 fm 3 eV 0 eV 0 fm 0 fm guide initStep Photon at Boundary! Old Momentum Direction: (0.17897827,-0.98157815,0.066866421) Old Polarization: (-0.99500417,-0.099833417,0) theLocalNormal: (-0.15602987,0.85572124,-0.49335163) New Momentum Direction: (-0.10214757,0.56021228,-0.82202681) New Polarization: (0.97321591,0.21932769,-0.068892405) *** SpikeReflection *** 1 4.41 cm -24.2 cm 1.65 cm 3 eV 0 eV 24.6 cm 24.6 cm guide Transportation 2 4.41 cm -24.2 cm 1.65 cm 3 eV 0 eV 0 fm 24.6 cm World Transportation A picture of the solid can be found at the URL below (thanks to Karoly Makonyi). You can run the program with: /bin/Linux-g++/LG_Main optPhoton.mac > test.out & Best regards, Peter Gumplinger
Dear Peter, Thank you for the comprehensive problem report. This is under active investigation. I am reassigning it to the relevant component and to Vladimir Grichine who is working on this.
The problem requires a revision of some implementations in solids (in particular SurfaceNormal method) before resolving of some inconsitency in Boolens (f.e., Inside method).
Since Geant4 7.1 the SurfaceNormal() method for all CSG solids and booleans has been reviewed according to a new specification and algorithm for the treatment of normals on edges and verteces. We believe that now the Inside() method in boolean solids covers all cases and provides correct response for optical photons. Therefore, this problem report is closed. Please, verify and inform us.
I have tested the latest code using the example I provided when I first reported the problem, and indeed, the bug seems to be fixed. Thanks!