Created attachment 490 [details] The example B4a modifications to reproduce the problem Hi, We observe stopping of particles by a special cuts process, when a particle kinetic energy goes beyond the energy limit (defined in G4UserLimits), without depositing the remaining kinetic energy. This happens when the special cuts process is invoked in the world volume. The problem can be reproduced with the basic B4a example, with the modifications provided in the patch attached. The patch is based on geant4-10-04-ref-02 tag, but the problem is also observed with Geant4 10.01.p03. An example of the output with this wrong case: ********************************************************************************************************* * G4Track Information: Particle = e-, Track ID = 110, Parent ID = 6 ********************************************************************************************************* Step# X(mm) Y(mm) Z(mm) KinE(MeV) dE(MeV) StepLeng TrackLeng NextVolume ProcName 0 45.1 45.3 -19.5 2.37 0 0 0 Gap initStep 1 44.7 45.8 -18.3 2.17 0.205 1.33 1.33 Gap msc 2 44.1 46.4 -17.5 1.97 0.198 1.25 2.57 Gap msc 3 43.2 47 -16.8 1.69 0.277 1.47 4.04 Gap msc 4 43.1 48.2 -16.6 1.5 0.198 1.36 5.4 Gap msc 5 42.2 49.1 -16.8 1.19 0.302 1.29 6.69 Gap msc 6 42.3 50 -17 0.987 0.207 1.18 7.87 World Transportation 7 42.3 50 -17 0.987 0 0 7.87 OutOfWorld UserSpecialCut As this behaviour affects the ALICE simulation, I marked the severity of the problem as major. Thank you,
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
