Problem 465

Summary: Particle disappearance on the boundary
Product: Geant4 Reporter: novikova
Component: geometryAssignee: Gabriele Cosmo <Gabriele.Cosmo>
Status: CLOSED FIXED    
Severity: minor    
Priority: P2    
Version: 4.1   
Hardware: PC   
OS: Windows   

Description novikova 2003-03-06 09:52:09 CET
I have a case of disappearing of an energetic muon at the boundary of a volume:

Step#    X(mm)    Y(mm)    Z(mm) KinE(MeV)  dE(MeV) StepLeng TrackLeng
NextVolume ProcName
    0     -151    -32.4  -1e+003       500        0        0         0
worldVolumePhysical initStep
    1     -151    -32.4      -85       500        0      915       915
CsIPhysical Transportation
    2     -151    -32.6    -55.3       484     15.4     29.7       945
CsIPhysical MuIoni
    :----- List of 2ndaries - #SpawnInStep=  1(Rest= 0,Along= 0,Post= 1),
#SpawnTotal=  1 ---------------
    :      -151     -32.6     -55.3       0.9                 e-
    :-----------------------------------------------------------------
EndOf2ndaries Info ---------------
    3     -152    -30.3       85       412     71.3      140 1.09e+003
worldVolumePhysical Transportation
    4     -152    -30.3       85       412        0        0 1.09e+003
OutOfWorld MuIoni

My word volume is 5m x 5m x 5m and is filled with vacuum (H with the lowest
possible density). In the middle of it, a rectangular box of CsI (35cm x 35cm x
17cm) is located. The z-face (z=-85mm) of this chunk is illuminated with a beam
of muons with uniform density. Muons are shot in the direction parallel to z-
axis, towards increasing z.  The propagation of one of this muons is
illustrated in the printout shown above.

At z = -85 mm the muon passes into CsI chunk.  At z = 85 mm (the boundary
between CsI and the vacuum) the muon is
expected to come out of the CsI into the world.  But it doesn't. It experiences
an ionization interaction, in which is doesn't loose any energy (see the
printout) and doesn't produce any secondaries (see the printout).  Instead, it
disappears right then and there, together with 412MeV of kinetic energy it
possessed.  Step #4 was the last step for this particle.

The conditions in the "if" statement identify the case when the particle
disappears on the boundary. If you have such UserSteppingAction() function,
just shoot energetic muons into a chunk of something heavy.  I think that
sooner or later you will find a disappearing particle.

I want to add more to the discussion of this bug.  First, I did see this
disappearance not only for muons, but for electrons only.  I think the bug
doesn't depend on the particle type.  I am pretty sure that the reason for the
bug is somehow related to the fact that when a particle is trying to cross a
boundary, for example, exit from a heavy chunk, it sometimes ends up having
coordinates EXACTLY on the edge of a heavy chunk, but the pointer pStepData-
>GetPostStepPoint()->GetPhysicalVolume() points to the world volume.  Thus, the
particle is still considered to be INSIDE the chunk by some parts of the code,
and outside the chunk by other parts of the code.

I observed another phenomenon related (I think) to the same bug.  We here (at
NRL) are calling it "virtual reflection" of a particle (as opposed to "particle
disappearance" bug).  The printout (verbose level 2) is shown below, the file
with verbose level 5 is attached (output-tracking5-virtualReflection.txt).

Step#    X(mm)    Y(mm)    Z(mm) KinE(MeV)  dE(MeV) StepLeng TrackLeng
NextVolume ProcName
    0    -46.3     -174  -1e+003       100        0        0         0
worldVolumePhysical initStep
    1    -46.3     -174      -85       100        0      915       915
CsIPhysical Transportation
    2    -46.4     -174    -66.6      87.3       12     18.4       933
CsIPhysical MuIoni
    :----- List of 2ndaries - #SpawnInStep=  1(Rest= 0,Along= 0,Post= 1),
#SpawnTotal=  1 ---------------
    :     -46.4      -174     -66.6     0.773                 e-
    :-----------------------------------------------------------------
EndOf2ndaries Info ---------------
    3    -46.2     -175    -45.7      74.4     12.9     20.9       954
CsIPhysical MuIoni
    4      -46     -175    -28.9      62.2     12.2     16.8       971
CsIPhysical MuIoni
    5      -46     -175      -25      58.9     2.43      3.9       975
CsIPhysical MuIoni
    :----- List of 2ndaries - #SpawnInStep=  1(Rest= 0,Along= 0,Post= 1),
#SpawnTotal=  2 ---------------
    :       -46      -175       -25     0.824                 e-
    :-----------------------------------------------------------------
EndOf2ndaries Info ---------------
    6    -45.7     -175    -12.8      49.8      9.1     12.3       987
CsIPhysical MuIoni
    7    -44.1     -175    -3.12      41.7     8.15     9.79       997
CsIPhysical MuIoni
    8    -43.2     -175     3.68      35.2     6.49     6.88    1e+003
worldVolumePhysical Transportation
    9    -43.2     -175     3.68      35.2        0        0    1e+003
CsIPhysical Transportation
   10    -42.7     -175     8.34        31     4.19      4.7 1.01e+003
CsIPhysical msc
   11    -41.8     -175     12.9      26.2     4.75      4.7 1.01e+003
CsIPhysical msc
   12    -41.3     -175     15.2      23.5      2.7     2.35 1.02e+003
worldVolumePhysical Transportation
   13      546     -751 2.5e+003      23.5        0 2.62e+003 3.63e+003
OutOfWorld Transportation

 Here is how it happens.  The muon enters the CsI block close to one of the
edges and is doing ionization and multiple scattering while propagating very
close to one of the volume boundaries (generally going in the increasing Z
direction). Then in one (or more) of the interactions, it ends up exactly on
the edge of the block, but this time it approaches the boundary practically
sliding along it (as oppose to the perpendicular approach in the case of the
first bug ("disappearing particle")).

The printout above shows what was happening to the particle that entered the
CsI block going along z axis. The entrance point happened to be close to the xz
plane of the CsI chunk, so that the particle propagates close edge of the chunk
which is located at y=-175.00.

Now pay attention to the steps 8 and 9 in the printout above.  After ionization
in step 8, the particle appears to have the  coordinates EXACTLY on the edge of
the chunk (y=-175).
(Btw, I checked in the debugger, the y-coordinate are exactly -175., i.e.,
(the_current_y - (-175)) = 0 (it is exactly zero, and not 1e-10 or some such
number.))
In a way, it still belongs to the chunk, but the pointer to the current volume
at step 8 shows "worldVolumePhysical."  During the next step, the
particle "reenters" the chunk (although it never quite left it), and the
pointer of the current volume is back to "CsIPhysical."  What PHYSICAL process
turned the particle around?  If it DID exit and was in
the "worldVolumePhysical," how could it go back to "CsIPhysical"?  If we
consider it as staying inside the chunk and never making it to the outside,
then how come the current volume was "worldVolumePhysical" in one of the
steps?

This phenomenon of "virtual reflection" off the boundary is probably related to
the "disappearance" bug.  Taken by itself, the "virtual reflection" phenomenon
makes following the propagation of single particles more complex that it
probably should be.

My conclusion, at this time, is that the interpretation of the pointer to the
current volume and the coordinates of the particle at any given time should be
consistent and treated consistently by different parts of Geant code.

Suppose there is a particle that is leaving a volume and ** at this moment **
having coordinates exactly at the boundary of this volume.  If the current
volume for such a particle is the one it is going to enter (not the one it just
left), then all the code has obey by this fact. What happens now is that,
although the current volume of a particle "on the boundary" is "outside"
volume, the physical processes are still processing this particle as if  it
is "inside."  As a result, we have such things as virtual reflections and
disappearance.

Sincerely,
-- Elena.
Comment 1 Gabriele Cosmo 2003-03-06 10:43:59 CET
The problem is currently under investigation.
Comment 2 Gabriele Cosmo 2003-04-30 11:15:59 CEST
The problem is now fixed in internal tag "procman-V05-00-01"
and the fix is included in public release 5.1.
Thanks again for the detailed report.