Hello Dennis, Alberto, During work on particle change clean-up the condition to print out warning was changed. With a good statistics ~10000 events form 5 GeV pion and FTFP_BERT_HP Physics List inside PbWO4 media following warning appears: TrackID=15715 tLocal(ns)=0.000400752 tGlobal=2.03533e+15 G4VParticleChange::CheckSecondary : Ekin(MeV)=-0.00063199 is negative !! nu_e created by model_RDM_KshellEC ----------------------------------------------- G4VParticleChange Information TrackID : 15715 ParentID : 15692 Particle : Ta178[0.000Y] Kinetic energy (MeV): 0 Position (mm) : (-16.843007,-27.563355,-60.945362) Direction : (0.8769536,-0.3310293,-0.34838481) PhysicsVolume : Target Material : G4_PbWO4 ----------------------------------------------- # of secondaries : 13 ----------------------------------------------- Energy Deposit (MeV): 0 NIEL Energy Deposit (MeV): 0 Track Status : StopButAlive TruePathLength (mm) : 0 Stepping Control : 0 First step in volume ----------------------------------------------- G4ParticleChangeForDecay proposes: Proposed local Time (ns): 0.00040075177 Initial local Time (ns) : 0.00040075177 Initial global Time (ns): 2.0353274e+15 Current global Time (ns): 2.0353274e+15 -------- WWWW ------- G4Exception-START -------- WWWW ------- *** G4Exception : TRACK001 issued by : G4VParticleChange::CheckSecondary() Secondary with illegal time/energy/momentum *** This is just a warning message. *** -------- WWWW -------- G4Exception-END --------- WWWW ------- Conclusion: nu_e may be created with small negative energy. This is not a problem for real simulation but only warning in run time but indicate some problem in radioactive decay module. Likely it is an old problem. Cheers, Vladimir
Looking at the code G4ECDecay.cc, line 166: G4double Q = transitionQ - eBind; and looking at the tabulated values for transitionQ and binding energy for Ta178, Q should be positive and therefore the neutrino energy should, too. One thing to check would be to uncomment the energy check code at the end of G4ECDecay.cc and re-run your test.
Hi Dennis, are you sure that the model "model_RDM_KshellEC" is implemented inside G4ECDecay.cc and any other class is not responsible? Vladimir
The only other RDM model that creates a nu_e is G4BetaPlusDecay, but that is not indicated by "model_RDM_KshellEC".
Hi Dennis, the problem is reproduced: transitionQ = 64.85 keV eBind = 65.48 keV Q = -0.63 keV final state Hf178[1772.150] For me it is unclear is it some inconsistency in data or there is no enough checks that K-shell capture is not possible. This happens not frequently, so the fix after the line 166 may be if(Q < 0.0) { ... warning ... Q = 0.0; } but it is kind of work around and you may have another solution. Vladimir
Hi Vladimir, If it is easy for you to do, would you put this warning in your local copy of G4ECDecay and run your simulation? Printing out transitionQ and eBind when the nu_e energy is negative will help me trace the problem before committing any code. If it's not so easy, I'll make a tag of RDM with this change and you can test it. Dennis
Hi Dennis, I already have protection locally. I may commit it as a temporary fix with the warning via standard G4Exception. Later when you will have a proper fix you may remove it. Cheers, Vladimir
OK. Please let me know what are the values of transitionQ and eBind the next time this occurs.
The fix is submitted in !3068.
