Problem 2047

Thanks for the clear report with code to reproduce it.

A first inspection of the process and its Particle Change did not find the source of the problem.

From my trials, it seems that this occurs only if the step is marked as ending up at a point outside the world volume (Status 'OutOfWorld').

So I suspect that the cause is in the tracking logic, not the process - which sets the correct value of energy loss.

I've changed the importance in minor, as at the end we do not score in ALICE the energy deposited in the world volume so the bug does not affect the simulation results.
On the other hand the fix may be still important for radiation studies where all energy depositions are scored.

I tested the B4a program with the provided patch. The following are conditions
and results of the tests.

[Test environment]
   - OS: CentOS7 on VMware (Machine: Mac OSX with Intel Core i7)
   - Geant4 version: 10.4.0

[Test #1]
   - Processed 10**5 events without any modification to the patched program. 
   - With TrackingVerbose=1 the size of the output file is about 1.2GB.
     (# of total tracks processed ~ 1.2*10**6)
   - 'grep'ed the file and tried to find a step which has the reported 
     characteristics:
        - 'ProcName=UserSpecialCut' and 'NextVolume=OutOfWorld'
   - Test results:
        - No step with the reported characteristics are found.
        - Found ~49K steps with 'ProcName=UserSpecialCut' and 'NextVolume=World'
               ~599K steps with 'ProcName=UserSpecialCut' and 'NextVolume=Abso'
               ~284K steps with 'ProcName=UserSpecialCut' and 'NextVolume=Gap'
          This means'UseSpecialCut' works in all defined volumes.
   - Observation:
        - The reported step occurs quite rarely.

[Test #2]
   - Processed 61.7*10**6 events to try to catch the claimed step.
   - For this test I turned off TrackingVerbose and added to B4aSteppingAction
     the code to catch the condition:
       'ProcName=UserSpecialCut' and 'NextVolume=null'
         (note) In G4SteppingVerbose 'OutOfWorld' is set by checking whether 
                the pointer to 'NextVolume' is null or not.  
   - It took almost 20 hours to complete the run under the above mentioned 
     computer environment.
     (# of total tracks processed ~ 0.7*10**9) 
   - Test results:
        - No step with the reported characteristics are found.

[Conclusions]
   - Could not reproduce the claimed step afer processing 60M events with 
     geant4 10.4.0.

[Comments]
   - I'd like to ask you check the reproducibility of the problem either on
     geant4 10.4.0 or 10.4.patch-01. This is because the problem seems to 
     occur very rarely and it is important to use an officially released version.
   - Once you find the claimed step, could you provide the random number staus
     of the corresponding event?

Hi Katsuya,

I checked that the problem is present with the Geant4 10.04.p01 version, too.
From the posts by John, I understood that he was able to reproduce the problem also.
Did you run the example with the modified run1.mac macro?
On my side, the output file run1.out produced by:
./exampleB4a -m run1.mac > run1.out
contains 17 cases. (The macro launches just 100 events.) 

Cheers,

Hi Ivana,

I didn't know that I needed to use run1.mac to reproduce the problem.
The macro I used in the test (reported on 2018-04-10) is as simple as follows:
  /run/initialize
  /track/verbose xxx
  /run/beamOn xxx

My simple macro didn't generate any illegal step you claimed. The essentail 
difference between my macro and run1.mac (patched) is that whether 
the magnetic field is on or off. So I run the patched B4a using run1.mac
with/without magnetic field. I generated 10000 events for these two cases.
The following are results:

Case_1: Magnetic_field = ON (10000 events)
 - ProcName='UserSpecialCut' and 'NextVolume=OutOfWorld'  (i.e. illegal steps)
    - 1689 steps found (i.e. reproduced your claimed steps)
    - the previous step of each illegal step alway has ProcName='Transportation'
      and 'NextVolume=World'. Also it has kinetic energy of below the cutoff.
  
Case_2: Magnetic_field OFF (10000 events)
 - ProcName='UserSpecialCut' and 'NextVolume=OutOfWorld'  (i.e. illegal steps)
    - 0 steps found
      (Note) all steps which have ProcName='UserSpecialCut' and 'NextVolume=World'
             correctly stop and deposit their entire kinetic energies in 'World'.

From above observations my conclusions are as follows:

 - Transportation behaves incorrectly for a particle in the following conditions:
     o in a magnetic field
     o has UserSpecialCut (energy cut)
     o has just gotten into the 'World' and its kinetic energy is 
       below the energy cut value.          

 - We need an expert to study this issue in
    o G4TransportationProcess
    o G4UserSpecialCuts

Ivana, could you confirm in your environment that you find no illegal steps
using 'run1.mac' with no magnetic field?
Once you confirm this, I'll send back the issue to John.

Created attachment 493 [details]
updated B4PrimaryGeneratorAction class

Created attachment 494 [details]
another macro to reproduce problem

Hi Katsuya,

The wrong case happens also without magnetic field; I tried with gps with random track start point (the modified primary generator action and a new macro are attached), and the new macro runGPS.mac gives 57 case like this one:

*********************************************************************************************************
* G4Track Information:   Particle = mu+,   Track ID = 1,   Parent ID = 0
*********************************************************************************************************

Step#    X(mm)    Y(mm)    Z(mm) KinE(MeV)  dE(MeV) StepLeng TrackLeng  NextVolume ProcName
    0     5.82    -85.1     38.8         1        0        0         0       World initStep
    1     5.82    -85.1     38.8         1        0        0         0  OutOfWorld UserSpecialCut

Cheers,

Ivana

Hi Ivana,

Your new macro (runGPS.mac) generates muons in high probability from 'OutOfWorld'.
If a particle is shot from 'OutOfWorld' there is no guarantee in its behavior 
as far as I know. Anyway according to 'tracking verbose' each muon invokes
'UserSpecialCut' (because it energy is 1MeV) and stops immediately at
'OutOfWorld'. I think this behavior is resonable.

In your runGPS.mac you use GPS with parallelpipe and set its size twice bigger
that 'World' - I don't know if you intentionally set this way. I changed the
parallelepipe parameters in the following way and generated 1000 events. 
I found no illegal steps in this case. I turned on and off the magnetic field 
and the results are same.

 (original)
  /gps/pos/halfx 12 cm
  /gps/pos/halfy 12 cm
  /gps/pos/halfz 15 cm

(changed)
  /gps/pos/halfx 6 cm
  /gps/pos/halfy 6 cm
  /gps/pos/halfz 7.5 cm

Cheers,
Katsuya

Indeed, there was a mistake in my macro. I can confirm, that I don't see the wrong case when magnetic field in off, too.

Thank you,

Ivana

Hi Ivana,

Thanks for confirming about the magnetic field.

I'm going to study further the behavior of G4UserSpecialCut in your program. 
It may take a whole so please be patient!

Cheers,
Katsuya

Created attachment 495 [details]
Tracking verbose output - flawed step

Created attachment 496 [details]
Tracking verbose output: Normal step

Hi John,

I've studied the problem Ivana reported (Problem# 2047). My conclusion is that
the reported flawed-step is caused by an erratic behavior of 'Transportation'
when it tries to transport a particle with 'zero step length'. 

I explain below how I drew this conclusion. I've changed the assignee of the
current problem to you.

For the study I compared the behavior of the following two steps:  
 - Flawed step:  EventID= 2、TrackID= 110 (particle= e-)、ParentID= 6、StepID= 7
    [Note] This is the step Ivana pointed out in her first report.
 - Normal step:  EventID= 2、TrackID= 111 (particle= e-)、ParentID= 6、StepID= 2
    [Note] This is a step of another e- which belongs to the same event in the 
           Ivana report. Here e- is in 'Abs' and has the energy below the cutoff.

For details of the behavior of the above two steps, please refer the accompanied 
two files:
   1) TrackVerbose_FlawedStep.txt
   2) TrackVerbose_NormalStep.txt

[Comparison of GPIL Behavior]
 - Flawed step: Winner process = UserSpecialCut
 - Normal step: Winner process = UserSpecialCut
    [Note]  Because the energy of two particles is below the cutoff value, these 
            steps are determined by 'UserSpecialCut' and StepLength = 0 mm.

[Comparison of AlongStepDoIt Behavior]   
 - Flawed step:  Involved processes are 1) Transportation, 2) msc, 3) eIoni
 - Normal step:  Same as the above
    [Note]  Both have the same behavior

[Comparison of PostStepDoIt Behavior] 
 - Flawed step: 
     1) 1st invoked process = Transportation 
        [Returned conditions]  TrackStatus = StopAndKill, Volume = null (OutOfWorld)
   
    [Note]
          * Because of this 'StopAndKill' the tracking stops immediately 
          * Energy deposit: no energy registered
          * No change in the particle position <--- inconsistent with 'OutOfWorld'
     2) 2nd invoked process = none   (because of above 'StopAndKill')
 - Normal step: 
     1) 1st invoked process = Transportation 
        [Returned conditions]  TrackStatus = Alive, Volume = Abs
     2) 2nd invoked process = UserSpecialCut
        [Returned conditions]  TrackStatus = StopAndKill, Volume = Abs
        [Note] 
          * Tracking stops immediately 
          * Energy deposit: registered correctly
          * No change in the particle position

[Observations]
- Transportation(PostStepDoIt) returns ’StopAndKill’ when a particle is in the 
  following conditions:
    * just relocated to ‘World’ volume from a non-world volume,
    * its step length is given to ‘zero’  
        <--- transportation is going to transfer ‘zero’ length
    * in a magnetic field 
        <--- confirmed that the problem disappears when the magnetic field is off
- Because of this ‘StepAndKill’ the method UserSpecialCut(PostDoIt) is not invoked 
  and no energy deposit is left to the world volume.

- Transportation is not expected to move a particle when the given step length is
  'zero', though here it relocates the particle to 'OutOfWorld'. 
- Despite of above 'relocation' the position of the particle is not changed 
  according to the 'ParticleChange' from 'Transportation'. 
  
[Conclusion]
  By fixing the flawed behavior (incorrectly returns 'StopAndKill') in 
 'Transformation', the 'PostDoIt' of 'UsrSpecialCut' will not be skipped and the
  energy deposit will be correctly handled.

Cheers,
Katsuya