Problem 532

Dear Luis,

I believe that there is an explanation, which can account for the behaviour
which you are seeing:  A particle can arrive at a boundary but have its momentum
pointing backwards (into the volume in which it originates).  The reason is a
combination of physical effects, the way in which we are modelling them and
choices that we have made in the implementation to obtain good cpu performance
in the most probable case (a particle that arrives at a boundary will cross it.)


Different physical effects can account for this depending on the particle
type and energy. For electrons it is typically our multiple scattering
and its implementation that can cause a particle to reach the boundary
and have a momentum point 'back' into the current volume.  Of course
for low energy electrons it is more likely to occur.

The second part of the 'equation' is the behaviour of the Transportation and the
geometry's Navigator sub-system on which it relies for the geometrical
navigation.  The Navigator determines the 'next volume'.

The "Next volume" is generally a prediction, and it is utilised for the next
volume.  If on the next step it is found to be wrong, that step will be 'zero
length' and likely the correct next volume will be found.  In very rare cases at
edges additional steps may be needed to identify the correct volume.  As I
mentioned this logic is intended to deliver the best possible cpu performance
for the dominant case of traversing a boundary that you arrive at.

One caveat: In the cases that I am aware in a step like your #8135 in which the
particle appears to start in the World, but it is actually in the previous
volume (Target in your case) the step length should be zero.  Yet it would
appear that the particle has moved ... which is very puzzling.

You can check whether this is the case by checking the momentum direction of the
track at the boundary - to ensure that it is crossing the boundary.  If this is
not the case, then you have found a problem that we will need to investigate!

I hope that this information will help you to evaluate the problem, and that it
will explain it.  However if the problem remains, it would be good to see also
the step length, the momentum direction, the particle's kinetic energy, delta
energy and the name of the process that determined the step for the steps 8134
through 8136.

Regards, John Apostolakis

Dear John,

I changed a little bit my detector construction to get more information. Now I
implemented another volume (called World2) filled with vacuum that encloses my
target. World2 is a rectangular box 10% larger than target with its center at
(0,0,0). I implemented this kind of construction in order to work around with
NULL pointers coming from NextVolume when some particle is going out of my
(mother)World. I run 2 simulations with different cut off.

First run had 5000 electrons events generated with 15keV energy, and 1 micron
cutoff was assigned to all particles. Please, for this run look at event 3645.
Starting at row 21063 you can see a backscattered electron being transported
from Target to World2 volume with positive Z momentum direction (pointing
towards to Target volume). But in the next step (21064) it actually reaches
World2 volume! Its energy deposited is zero, as expected, its momentum direction
does not change and its NextVolume is assigned to Target volume again. In the
next step (21065) it enters again in target. After that, it goes out definitly
to World2 volume with negative momentum direction.

************************************************************************************************************************************************************************
*    Row   *   EventID *   TrackID * track.x   * track.y   * track.y   * pdir.x
   * pdir.y    * pdir.z    *   Kenergy *  Edeposit *    Volume * NextVolum *
ProcessNa *
************************************************************************************************************************************************************************
*    21061 *      3645 *         1 * -0.000143 * 0.0002450 *   -0.0125 *
-0 *        -0 *         1 *        15 *         0 *    World2 *    Target *
Transport *
*    21062 *      3645 *         1 * -0.000218 * 0.0002788 * -0.012195 *
0.4990651 * 0.5467678 * -0.672293 * 9.5126118 * 1.4242150 *    Target *
Target *     eIoni *
*    21063 *      3645 *         1 * 7.902e-06 * 0.0005267 *   -0.0125 *
-0.533133 * 0.8434672 * 0.0658197 * 3.4465639 * 6.0660478 *    Target *
World2 * Transport *
*    21064 *      3645 *         1 * 7.902e-06 * 0.0005267 *   -0.0125 *
-0.533133 * 0.8434672 * 0.0658197 * 3.4465639 *         0 *    World2 *
Target * Transport *
*    21065 *      3645 *         1 * -1.53e-05 * 0.0005587 * -0.012497 *
0.2440108 * 0.2518843 * -0.936489 * 2.9874094 * 0.4591544 *    Target *
Target *       msc *
*    21066 *      3645 *         1 * -1.47e-05 * 0.0005593 *   -0.0125 *
0.3259348 * 0.2515479 * -0.911312 * 2.9348666 * 0.0525428 *    Target *
World2 * Transport *
*    21067 *      3645 *         1 * 0.0004323 * 0.0009044 *  -0.01375 *
0.3259348 * 0.2515479 * -0.911312 * 2.9348666 *         0 *    World2 *
World * Transport *
*    21068 *      3645 *         2 * -0.000286 * 0.0003930 * -0.012153 *
 1 *         0 *         0 *         0 * 8.1263462 *    Target *    Target *
LowEnergy *
************************************************************************************************************************************************************************

Second run had 10000 electrons events and 1 nanometer cutoff for all particles,
the others parameters are the same. Please, look at row 119060 and you can see
the same behaviour described above.

************************************************************************************************************************************************************************
*    Row   *   EventID *   TrackID * track.x   * track.y   * track.z   * pdir.x
   * pdir.y    * pdir.z    *   Kenergy *  Edeposit *    Volume * NextVolum *
ProcessNa *
************************************************************************************************************************************************************************
*   119052 *      7220 *         1 * 0.0002583 * 0.0004369 *   -0.0125 *
-0 *         0 *         1 *        15 *         0 *    World2 *    Target *
Transport *
*   119053 *      7220 *         1 * 0.0005274 * 0.0004733 * -0.011899 *
0.7895110 * 0.5685031 * -0.231249 * 12.754763 * 2.2452362 *    Target *
Target *       msc *
*   119054 *      7220 *         1 * 0.0007880 * 0.0006131 * -0.012073 *
0.2542395 * 0.8152012 * -0.520393 * 9.4390671 * 1.5373884 *    Target *
Target * LowEnergy *
*   119055 *      7220 *         1 * 0.0008402 * 0.0007833 * -0.012319 *
0.4970363 * 0.6621749 * -0.560784 *  8.244615 * 1.1944520 *    Target *
Target * LowEnergy *
*   119056 *      7220 *         1 * 0.0009863 * 0.0009332 * -0.012393 *
0.5480702 * 0.7333769 * -0.402215 * 5.7721157 * 2.4724993 *    Target *
Target * LowEnergy *
*   119057 *      7220 *         1 * 0.0010636 * 0.0009824 * -0.012470 *
0.8556608 * 0.4429040 * -0.267732 * 4.6836907 * 1.0884249 *    Target *
Target * LowEnergy *
*   119058 *      7220 *         1 * 0.0011214 * 0.0010229 * -0.012485 *
0.6840901 * 0.7254942 * -0.075357 * 3.8050326 * 0.8786581 *    Target *
Target * LowEnergy *
*   119059 *      7220 *         1 * 0.0011496 * 0.0010683 * -0.012487 *
0.7669725 * 0.5027377 * -0.398757 * 3.2197321 * 0.5853004 *    Target *
Target * LowEnergy *
*   119060 *      7220 *         1 * 0.0011740 * 0.0010843 *   -0.0125 *
0.2287653 * 0.9602858 * 0.1597420 * 1.9118793 * 1.3078528 *    Target *
World2 * Transport *
*   119061 *      7220 *         1 * 0.0011740 * 0.0010843 *   -0.0125 *
0.2287653 * 0.9602858 * 0.1597420 * 1.9118793 *         0 *    World2 *
Target * Transport *
*   119062 *      7220 *         1 * 0.0011762 * 0.0010994 * -0.012495 *
0.3732515 * 0.8984083 * -0.231399 * 1.7192433 * 0.1926359 *    Target *
Target *       msc *
*   119063 *      7220 *         1 * 0.0011793 * 0.0011106 * -0.012499 *
-0.182623 * 0.9742322 * -0.132363 * 1.0777169 * 0.6415263 *    Target *
Target * LowEnergy *
*   119064 *      7220 *         1 * 0.0011783 * 0.0011158 *   -0.0125 *
-0.321936 * 0.8372080 * -0.442085 * 0.9800803 * 0.0976365 *    Target *
World2 * Transport *
*   119065 *      7220 *         1 * 0.0002681 * 0.0034830 *  -0.01375 *
-0.321936 * 0.8372080 * -0.442085 * 0.9800803 *         0 *    World2 *
World * Transport *
************************************************************************************************************************************************************************

I am using this method to get the Volume where particle is being tracked:
aStep->GetTrack ()->GetVolume ()->GetName ()

As you warned me, the momentum direction is pointing to Target volume when
NextVolume is World2, but always in the next step the electron actually reaches
World2 volume, which seens to be strange and could lead wrong results when
counting electrons crossing boundaries.

Sincerely,

Luís A. Perles

Dear Luis,

Thanks once more for your report and the more detailed information.  Your new
information confirms that the particle arrives at a point on the boundary with
direction pointing back into the original volume.

So you have stumbled upon this issue, in which, due to the sequence of actions
and the current implementation of processes, the tracking believes that the
track will cross the boundary into the next volume, while in fact it does not --
 and Geant4 will recognise this at the next step (which will be a zero step)
and reset itself to move (back) into the original volume.

So, unfortunately, you see the 'phantom' boundary crossing, as you have
reported.  For the time being the only solution is to double check that the
particle is indeed entering in the new volume in your code before 'scoring' it.

We will look into this issue, though, to see whether it is possible either as
an option (if it is costly) or as standard we can insure better identification
of the next volume.

Best regards, John Apostolakis

We will attempt to investigate possible solution to this issue in 2004.  Since
the issue is understood, we will set the status to 'remind' and re-open if
other aspects are found or a solution is planned.

The simplest (potentially only) solution to this problem would be to enable the process which changes the direction of the particle also to change the touchable history.

The cost of this solution, though, is significant as it would require adding state to the Multiple Scattering to provide this and also to update the Navigator, and potentially revising the Transportation in addition (to ensure that it gets into sync with this change.)

Even a change where the track goes back into the volume of the current step would require such changes.

These changes would be significant and are not planned.