Dear GEANT4 developers. I'm currently working with Mokka (http://polzope.in2p3.fr:8081/MOKKA) but the problem I have found is more general and concerning GEANT4 itself. First of all I would like to say that I have a differences it timing of secondaries generated in hadElastic processes in GEANT4 versions: 9.4.p03 and 9.5.p01. Detailed analysis of tracks and steps shows the 9.4.p03 gives _correct_ GetGlobalTime() of secondaries from hadElastic but 9.5.p01 put as global time something like the local time of a given secondary from a time at postStepPoint of parent track where the particle (neutron mostly) has been created. To illustrate this there is an example of /track/verbose printout from 9.5.p01: ********************************************************************************************************* * G4Track Information: Particle = neutron, Track ID = 425, Parent ID = 409 ********************************************************************************************************* Step# X(mm) Y(mm) Z(mm) KinE(MeV) dE(MeV) StepLeng TrackLeng NextVolume ProcName 0 -1.73 46.1 1.91e+03 1.01 0 0 0 AbsorberLayerPhys7 initStep Track global time 9.328911271832824 ns 1 7.4 62.9 1.91e+03 1.01 0 19.6 19.6 WholeScinCassettePhys6 Transportation 2 10.2 68 1.9e+03 1.01 0 5.94 25.5 HcalScinHousPhys Rear Transportation 3 14.6 76.2 1.9e+03 1.01 0 9.5 35 HcalSensLayerPhys Transportation 4 14.8 76.7 1.9e+03 1.01 0 0.546 35.6 HcalSensLayerPhys6 Transportation 5 25.9 97.1 1.9e+03 1.01 0 23.7 59.3 HcalSensLayerPhys Transportation 6 26.2 97.5 1.9e+03 1.01 0 0.546 59.9 HcalSensLayerPhys Transportation 7 27.7 100 1.9e+03 0.562 0 3.39 63.3 HcalSensLayerPhys hadElastic 8 28.3 101 1.9e+03 0.562 0 0.643 63.9 HcalCFmix_LayerPhys Transportation 9 31.1 102 1.9e+03 0.562 0 3.37 67.3 HcalScinHousPhys Front Transportation 10 34.9 103 1.89e+03 0.562 0 4.5 71.8 WholeScinCassettePhys6 Transportation 11 37.3 104 1.89e+03 0.562 0 2.81 74.6 AbsorberLayerPhys6 Transportation 12 42.4 106 1.89e+03 0.55 0 6.08 80.7 AbsorberLayerPhys6 hadElastic 13 45 107 1.89e+03 0.55 0 4.11 84.8 WholeScinCassettePhys6 Transportation 14 46.2 108 1.89e+03 0.55 0 1.9 86.7 HcalScinHousPhys Front Transportation 15 48.1 110 1.9e+03 0.55 0 3.03 89.7 HcalCFmix_LayerPhys Transportation 16 49.5 110 1.9e+03 0.55 0 2.28 92 HcalSensLayerPhys Transportation 17 50.4 111 1.9e+03 0.55 0 1.52 93.5 HcalSensLayerPhys Transportation 18 50.5 111 1.9e+03 0.55 0 0.175 93.7 HcalSensLayerPhys6 Transportation 19 52.1 112 1.9e+03 0.527 0 2.57 96.2 HcalSensLayerPhys6 hadElastic 20 53 112 1.9e+03 0.527 0 3.42 99.7 HcalSensLayerPhys Transportation 21 53 112 1.9e+03 0.527 0 0.119 99.8 HcalScinHousPhys Rear Transportation 22 53.5 112 1.9e+03 0.527 0 2.07 102 WholeScinCassettePhys6 Transportation 23 53.8 112 1.91e+03 0.527 0 1.29 103 AbsorberLayerPhys7 Transportation 24 54.6 111 1.91e+03 0 0 3.32 106 AbsorberLayerPhys7 NeutronInelastic ... then after ... ********************************************************************************************************* * G4Track Information: Particle = C12[0.0], Track ID = 432, Parent ID = 425 ********************************************************************************************************* Step# X(mm) Y(mm) Z(mm) KinE(MeV) dE(MeV) StepLeng TrackLeng NextVolume ProcName 0 52.1 112 1.9e+03 0.0222 0 0 0 HcalSensLayerPhys6 initStep 1 52.1 112 1.9e+03 0 0.0222 0.000212 0.000212 HcalSensLayerPhys6 ionIoni Step in HcalWholeSensLayerLogical6 neutron from trackID = 425, Energy registered: 2.386724340070652 keV , Time postStep: 7.323298874313955 ns , Time trk: 7.323298874313955 ns , Time parentTrk: 9.328911271832824 ns The last printout is from UserSteppingAction, parentTrk time has been kept on the previous track (exactly the same as for neutron Track ID = 425 at initial step - see a printout above made from PreUserTrackingAction). So something has been changed from 9.4.p03 to 9.5.p01 in hadElastic timing of secondaries.
May be this can help. I have found a change here: source/processes/hadronic/management/src/G4HadronicProcess.cc in 9.4.p03: ------------------------------------------------------------------------------- for(G4int i=0; i<aR->GetNumberOfSecondaries(); ++i) { G4LorentzVector theM = aR->GetSecondary(i)->GetParticle()->Get4Momentum(); theM.rotate(rotation, it); theM*=aR->GetTrafoToLab(); aR->GetSecondary(i)->GetParticle()->Set4Momentum(theM); G4double time = aR->GetSecondary(i)->GetTime(); if(time<0) time = aT.GetGlobalTime(); G4Track* track = new G4Track(aR->GetSecondary(i)->GetParticle(), time, aT.GetPosition()); ------------------------------------------------------------------------------ in 9.5.p01: ------------------------------------------------------------------------------ // check secondaries: apply rotation and Lorentz transformation G4int nSec = aR->GetNumberOfSecondaries(); theTotalResult->SetNumberOfSecondaries(nSec); if(nSec > 0) { G4double time0 = aT.GetGlobalTime(); for(G4int i=0; i<nSec; ++i) { G4LorentzVector theM = aR->GetSecondary(i)->GetParticle()->Get4Momentum(); theM.rotate(rotation, it); theM *= aR->GetTrafoToLab(); aR->GetSecondary(i)->GetParticle()->Set4Momentum(theM); G4double time = aR->GetSecondary(i)->GetTime(); if(time<time0) { time = time0; } G4Track* track = new G4Track(aR->GetSecondary(i)->GetParticle(), time, aT.GetPosition()); ------------------------------------------------------------------------------
Well, as I see from 9.6.b01 (beta version) this piece of code has been improved: ----------------------------------------------------------------------------- // time of interaction starts from zero G4double time = aR->GetSecondary(i)->GetTime(); if (time < 0.0) { time = 0.0; } // take into account global time time += time0; G4Track* track = new G4Track(aR->GetSecondary(i)->GetParticle(), time, aT.GetPosition()); ----------------------------------------------------------------------------- So GEANT4 knows about this problem and fixed it for the future releases..
Hi The problem has been reported #1305 http://bugzilla-geant4.kek.jp/show_bug.cgi?id=1305 The fix will be included in following patch and future release. Thanks *** This problem has been marked as a duplicate of problem 1305 ***
