Dear all,
We run a simulation with optical photons, with the Stepping Action inspired by the LXe example in examples/extended/optical/LXe.
We run into the same problem as described in this thread: Error occurs when an optical photon hits the edge of a cubic scintillator
Sometimes the warning is triggered that the ExpectedNextStatus is StepTooSmall and the boundaryStatus isn’t.
With Geant4 11.2, this sometimes immediately happens after the warning
-------- WWWW ------- G4Exception-START -------- WWWW -------
*** G4Exception : OpBoun06
issued by : G4OpBoundaryProcess
G4OpBoundaryProcess: Opticalphoton step length: 3.00063e-09 mm.
This is larger than the threshold 1e-09 mm to set status StepTooSmall.
Boundary scattering may be incorrect.
*** This is just a warning message. ***
-------- WWWW -------- G4Exception-END --------- WWWW -------
but not always.
This is why I think both issues mentioned in the thread still happen:
Sometimes the step at the boundary is small but non-zero and bigger than the value fCarTolerance in G4OpBoundaryProcess
The photon traveling from volume A is hitting the surface between volume A and B. It is expected to be reflected in Volume A, but because it reflects on an edge, it is reflected into volume C
I see that the bug report for the first issue is marked as “RESOLVED FIXED”. Was there really a change in the simulation or was just a warning beeing added to the code? This still happens for me so it doesn’t appear as fixed for me.
I can’t find a bug report for the second issues, is it existing?
Thanks a lot!
Geant4 Version: 11.2.1. and 11.0.3 Operating System: Fedora 39 Compiler/Version: GNU 9.5.0 CMake Version: 3.25.2
Hi Alvaro,
Thank you very much for your reply.
Attached you can find the gdml files of a simplified geometry of the one I use. It is basically a cone in an open sphere. test_raw.gdml.txt (2.8 KB) test.gdml.txt (1.7 MB)
These are gdml files but I’m only allowed to upload txt files.
test_raw.gdml is the same as test.gdml but without optical properties.
Best,
Kolja
The boundary scattering algorithm uses a step size of 0 as a flag to indicate the photon is going back into the volume it came. For reasons unclear to me, sometimes this value isn’t precisely 0, and it’s not clear how to handle these.
I did investigate a while ago, and increased the tolerance such that the small steps were within the tolerance of 0. As you see, though, this method is problematic because it’s not clear what the tolerance should be. For any value X, some steps could have length > X but should be flagged as 0, and others may have steps < X but these are real steps.
If you find these anomalous steps are frequent and important enough that they affect your simulation (keeping in mind the surface model is phenomenological anyway), we should keep discussing. If so, please also open a bug report.
I expect there should be a boolean flag to indicate this status, rather than comparing a float to 0.
@atolosad , this behaviour can be seen from the OpNovice2 example, with macro boundary.mac, once the number of particles is increased.
@Kolja In your original post you mention volumes A,B and C. Is this a typo or are there really 3 volumes? Could you please explain more.
It isn’t affecting us very much right now because it only happen rarely, but it would still be nice if we wouldn’t have wrong steps for the photons.
I was speaking of the other forum post (Error occurs when an optical photon hits the edge of a cubic scintillator - #11 by dsawkey). There you described it with three volumes.
If you have photons hitting an edge, they could get “reflected” into another volume. This could also happen when you have only two volumes (as in the picture: volume A the inside square and volume B the border of the square). Then a photon could be “reflected” into the border volume when it hits an edge.
With a polyhedral volume (boxes or more complex), the edges and corners cannot have a well-defined surface normal, since the gradient is undefined at those locations. This does mess up the boundary processes for both reflection and refraction, but the “hope” is that the probabilty of hitting them is tiny.
If you want to try to implement a general solution (e.g., by subclassing G4Box or G4Polyhedra in your code) you could choose some convention for edges and corners. Maybe you have them return the outbound vector exactly (treat it like a corner reflector); or you sample points on the surfaces surrounding the “bad” location and take the average normal at those points; or some other convention.
