Problem 2353

Summary:	Aborted Events with some EM Options
Product:	Geant4	Reporter:	Simon Spannagel <simon.spannagel>
Component:	physics_lists	Assignee:	Vladimir.Ivantchenko
Status:	RESOLVED FIXED
Severity:	minor	CC:	simon.spannagel, Vladimir.Ivantchenko
Priority:	P4
Version:	10.7
Hardware:	All
OS:	All
See Also:	https://bugzilla-geant4.kek.jp/show_bug.cgi?id=2542

Description Simon Spannagel 2021-03-31 17:13:45 CEST

Dear developers,

I have been instructed by a colleague in the forums to report my problem here. For reference, the forum thread can be found here: https://geant4-forum.web.cern.ch/t/after-10-6-10-7-update-event-must-be-aborted/4738

Since the update from 10.6 to 10.7 (latest patch, respectively) I am confronted with a small fraction of events which are aborted due to a negative local time and a kilometer long negative step. This seems to happen for hadrons only (pions, kaons, protons) and might always happen at volume boundaries:


-------- EEEE ------- G4Exception-START -------- EEEE -------
*** G4Exception : TRACK003
      issued by : G4ParticleChange::CheckIt()
momentum, energy, and/or time was illegal
*** Event Must Be Aborted ***
G4WT66 > G4Track (0x7f0ef3441fb0) - track ID = 38, parent ID = 1
G4WT66 >  Particle type : pi- - creator process : pi+Inelastic, creator model : Undefined
G4WT66 >  Kinetic energy : 2.77688 GeV - Momentum direction : (0.125509,-0.103605,0.986668)
G4WT66 >  Step length : -765.914 km  - total energy deposit : 0 eV 
G4WT66 >  Pre-step point : (1.4252,-0.256613,189.064) - Physical volume : World (G4_AIR)
G4WT66 >  - defined by : Transportation - step status : 1
G4WT66 >  Post-step point : (-9.61289e+07,7.93527e+07,-7.55703e+08) - Physical volume : World (G4_AIR)
G4WT66 >  - defined by : hIoni - step status : 3
G4WT66 >  *** Note: Step information might not be properly updated.
G4WT66 > 
-------- EEEE -------- G4Exception-END --------- EEEE -------



When testing different of the standard physics lists I realized that this only appears for certain EM options, namely _EMY and _EMZ. All others are fine, both for FTFP and QGSP lists:

    FTFP_BER_EMV - no aborted events
    FTFP_BER_EMX - no aborted events
    FTFP_BER_EMY - problem with aborted events
    FTFP_BER_EMZ - problem with aborted events
    FTFP_BER_LIV - no aborted events
    QGSP_BER_EMV - no aborted events
    QGSP_BER_EMX - no aborted events
    QGSP_BER_EMY - problem with aborted events
    QGSP_BER_EMZ - problem with aborted events
    QGSP_BER_LIV - no aborted events

A full tracking trace for a troublesome event can be found here:
https://sas.desy.de/index.php/s/43Lnxw3L36FmRNH

If I can provide you with more information that might help you in tracking down the issue, please let me know.

Best regards,
Simon

Comment 1 Simon Spannagel 2022-03-17 12:38:55 CET

Dear developers,

I have an addendum to this ticket, which is a bit tricky. I have users that came across Geant4 "hanging" at a single event. Investigating this in detail I found that what indeed happens is that we have the same problem as described above:

G4ParticleChange::CheckIt    : the local time goes back  !!  Difference:  0.00024951870999317[ns] 
e- E=0.00013508734175593 pos=0.00058141013010289, 0.00087916515918243, 0.15112251661936 global time=0.59230209636989 local time=0.02519550972273 proper time=0.024802160351758
G4ParticleChange::CheckIt    : the proper time goes back  !!  Difference:  0.0002494527648214[ns] 
e- E=0.00013508734175593 pos=0.00058141013010289, 0.00087916515918243, 0.15112251661936 global time=0.59230209636989 local time=0.02519550972273 proper time=0.024802160351758

However, this time the negative time step is just 0.0002 ns, which is below the hardcoded accuracyForException on G4VParticleChange of 0.001 ns - hence, no exception is thrown, the event is *not* aborted and Geant4 keeps tracking these particles back in time forever:


-----------------------------------------------
 G4ParticleChange Information  
-----------------------------------------------
 # of 2ndaries       :                    0
-----------------------------------------------
 Energy Deposit (MeV):                    0
 Non-ionizing Energy Deposit (MeV):                    0
 Track Status        :                Alive
 True Path Length (mm) :             -0.00172
 Stepping Control      :                    0
 Mass (GeV)   :                    0
 Charge (eplus)   :                    0
 MagneticMoment   :                    0
         :  =                    0*[e hbar]/[2 m]
 Position - x (mm)   :                0.581
 Position - y (mm)   :                0.879
 Position - z (mm)   :                  151
 Time (ns)           :               0.0249
 Proper Time (ns)    :               0.0246
 Momentum Direct - x :                 0.78
 Momentum Direct - y :               0.0756
 Momentum Direct - z :                0.621
 Kinetic Energy (MeV):             0.000135
 Velocity  (/c):                0.023
 Polarization - x    :                    0
 Polarization - y    :                    0
 Polarization - z    :                    0
 Touchable (pointer) :           0x27ba1428



This has been reported (and reproduced by me) with the standard physics list QGSP_BERT, but according to user feedback, other lists were affected as well.

For reference, the Geant4 10.7.2 event seeds for the above event were 7141275251643714399 413337079437031338.

Right now, I don't see any way of preventing this endless loop in the code - could you maybe help me out here or let me know what other information you need to debug this?

Best regards,
Simon

Comment 2 Vladimir.Ivantchenko 2023-04-12 20:17:50 CEST

Hello,

For Geant4 11.1 a review of G4ParticleChange classes was done. Codes were modernized and the set of G4Exception issued by these classes was updated. There is no more "Event Must Be Aborted" statements, instead the information about incorrect energy, momentum, or time is printed out.

It is not possible to backport these modifications to previous releases, because this concern of too many kernel classes.

This problem report will be closed but if a new problem will appear, then a new report should be opened.

VI