Sometimes, when I send pions to my calorimeter, program goes into infinite loop. It happens on Redhat6.1 and Redhat5.1 with geant4.1.0 and geant4.1.1 You can find output from job with infinite loop in event 113 in /afs/cern.ch/user/s/solodkov/geant4/run/tst/pi_35_200_1.out script which produces this file (on atlinux5) is /afs/cern.ch/user/s/solodkov/geant4/run/batch/pi_35_200_1.bat I suspect that there is a problem in "processes/electromagnetic/lowenergy" (see below), but I must say that I never saw such a problem when I sent electron to the calorimeter. ********************************************************************************************************* * G4Track Information: Particle = gamma, Track ID = 20464, Parent ID = 20418 ********************************************************************************************************* Step# X(mm) Y(mm) Z(mm) KinE(MeV) dE(MeV) StepLeng TrackLeng NextVolume ProcName 0 3.45e+03 38.9 849 1.07e-12 0 0 0 Scintillator 8 initStep 1 3.46e+03 31.1 846 1.07e-12 0 11.1 11.1 Absorber 107 Transportation 2 3.46e+03 31.1 846 1.07e-12 0 2.62e-34 11.1 Absorber 107 phot 3 3.46e+03 31.1 846 1.07e-12 0 1.34e-34 11.1 Absorber 107 phot 4 3.46e+03 31.1 846 1.07e-12 0 5.12e-35 11.1 Absorber 107 phot 5 3.46e+03 31.1 846 1.07e-12 0 1.72e-35 11.1 Absorber 107 phot [skip] 543103 3.46e+03 31.1 846 1.07e-12 0 3.69e-34 11.1 Absorber 107 phot 543104 3.46e+03 31.1 846 1.07e-12 0 3.21e-35 11.1 Absorber 107 phot 543105 3.46e+03 31.1 846 1.07e-12 0 1.23e-35 11.1 Absorber 107 phot 543106 3.46e+03 31.1 846 1.07e-12 0 1.96e-34 11.1 Absorber 107 phot 543107 3.46e+03 31.1 846 1.07e-12 0 9.96e-36 11.1 Absorber 107 phot 543108 3.46e+03 31.1 846 1.07e-12 0 4.28e-35 11.1 Absorber 107 phot
This problem report has nothing to do with the lowenergy category I am responsible of (together with P. Nieminen).
The low energy photon in question has been incorrectly generated starting during the following step: #Step# X(mm) Y(mm) Z(mm) KinE(MeV) dE(MeV) StepLeng TrackLeng NextVolume ProcName 16 3.45e+03 38.9 849 0 1.77 0.0521 30.9 Absorber 107 hIoni **List of AtRestDoIt invoked: # 1 : PiMinusAbsorptionAtRest Generated secondries # : 13 -- List of secondaries generated : (x,y,z,kE,t,PID) -- 3.45e+03 38.9 849 90.7 12.3 neutron 3.45e+03 38.9 849 15.7 12.3 proton 3.45e+03 38.9 849 8.53 12.3 proton 3.45e+03 38.9 849 0.906 12.3 gamma 3.45e+03 38.9 849 1.07e-12 12.3 gamma 3.45e+03 38.9 849 5.46 12.3 gamma 3.45e+03 38.9 849 0.428 12.3 gamma 3.45e+03 38.9 849 0.591 12.3 gamma 3.45e+03 38.9 849 1.19 12.3 gamma 3.45e+03 38.9 849 0.848 12.3 gamma 3.45e+03 38.9 849 1.33 12.3 gamma 3.45e+03 38.9 849 1.43 12.3 gamma 3.45e+03 38.9 849 1.43 12.3 Cr52[0.0] The condition causing this has been trapped. However, it is also possible to ensure that particles below a certain energy are discarded, by setting a threshold for the energy of secondary particles produced. This serves to ensure consistency and would also avoid such a problem.
The excited nucleus is evaporating photons with an energy 1.07e-12 MeV and it doesn't seem to be correct. When this energy is substracted the energy of the excited nuclus doesn't change and the nucleus returned to G4ExcitationHandler is exactly the same (plus a photon) and of course G4ExcitationHandler try to deexcite the nucleus again. I don't know why G4GammaEvaporation is emitting such low energy photons, but it would be better don't evaporate anything in such cases. It would help to stop the deexcitation process better than setting a threshold for the energy of secondary particles.
The problem derives from intrinsic inconsistencies in the data of the ENSDF database, used by PhotonEvaporation. A fix was implemented by H.-P. Wellisch in the G4ExcitationHandler of the Geant4 2.0 release (June 2000), that provides correct physics results to the user. A more elegant solution, implying a re-evaluation of the ENSDF inconsistencies and an improvement of how to handle them in the PhotonEvaporation package, is foreseen for a future Geant4 release.
