An ion is found to make very small steps in the ATLAS simulation when using the 9.6-beta release. #Step# X Y Z KinE/MeV dE StepL TrackLen NextVolume ProcName 1000001 318 25 5940 2.4e-05 0 1.2e-09 0.00702 FCAL::Module3::Rod msc 1000002 318 25 5940 2.4e-05 0 1.2e-09 0.00702 FCAL::Module3::Rod msc 1000003 318 25 5940 2.4e-05 0 1.2e-09 0.00702 FCAL::Module3::Rod msc Note the output above was reformatted for readability - the original output is copied below. Zach obtained the detailed output (verbose level 6) triggered using code in the User Action (the LooperKiller mentioned below). From this it is possible in principle to see what process is responsible for proposing the step of this size. It appears to be multiple scattering. #Step# X(mm) Y(mm) Z(mm) KinE(MeV) dE(MeV) StepLeng TrackLeng NextVolume ProcName 1000001 318 25.3 5.94e+03 2.43e-05 0 1.19e-09 0.00702 LArMgr::LAr::FCAL::Module3::Rod msc Set Driver verbosity to 2 >>AlongStepDoIt (process by process): Process Name = Transportation ++G4Step Information Address of G4Track : 0x2aaabbb21200 Step Length (mm) : 9.591879978409791e-11 Energy Deposit (MeV) : 0 ----------------------------------------------------------------------- StepPoint Information PreStep PostStep ----------------------------------------------------------------------- Position - x (mm) : 318.0960084063948 318.0960084063948 Position - y (mm) : 25.26939594394598 25.26939594394598 Position - z (mm) : 5940.940006576457 5940.940006576457 Global Time (ns) : 20.71188083790451 20.71188085680622 Local Time (ns) : 0.02198811777243127 0.02198813667413778 Proper Time (ns) : 0.02198811774523192 0.02198813664693842 Momentum Direct - x : -0.1983100416160954 -0.1983100416160954 Momentum Direct - y : 0.3404225079864919 0.3404225079864919 Momentum Direct - z : 0.9191222135550905 0.9191222135550905 Momentum - x (MeV/c): -0.5687989559649367 -0.5687989559649367 Momentum - y (MeV/c): 0.9764102995073255 0.9764102995073255 Momentum - z (MeV/c): 2.63625458001964 2.63625458001964 Total Energy (MeV) : 169446.2911297665 169446.2911297665 Kinetic Energy (MeV): 2.427538390396031e-052.427538390396031e-05 Velocity (mm/ns) : 0.0050746105785620140.005074610578562014 Volume Name : LArMgr::LAr::FCAL::Module3::RodLArMgr::LAr::FCAL::Module3::Rod Safety (mm) : 0.5685414887725684 0.5685414887725684 Polarization - x : 0 0 Polarization - y : 0 0 Polarization - Z : 0 0 Weight : 1 1 Step Status : AlongStep Proc. AlongStep Proc. Process defined Step: msc msc <=== ----------------------------------------------------------------------- !Note! Safety of PostStep is only valid after all DoIt invocations. Note: The line "Process defined Step" identifies the process which proposed the smallest step size limit to the Stepping Manager. Zach Marschall wrote: That is the first time I've ever seen a looper in the FCal in the wild... This is also, I think, the first time I've ever seen an ion looping. The thing has a mass of 169 GeV and kinetic energy of 24 eV (not a typo). Quick version of the super verbose print out is pasted [above]. I'd like to blame a new bug in the new ion ionization process or a modification to the ion multiple scattering, but the thing also isn't moving at all (steps of pm, also not a typo), so it's maybe not shocking that it's not losing energy very quickly. [ .. snip .. ] On Aug 24, 2012, at 6:38 PM, John Chapman wrote: As I mentioned earlier today, we are now in a position to start delving into the output of G4 9.6.beta00 in MIG0,r1. The AtlasG4_muons RTT job, seems to get stuck after a few events in the RTT, when I re-ran it locally with the LooperKiller switched on (this job uses athena + jo at the moment, so it isn't on by default), then I see that the LooperKiller is activated. I only ran 20 events, but you can see the output here on afs: ~jchapman/public/G4.9.6.beta00.atlas01_debugging/Looper/LooperInG49.6.log To reproduce the job do the following: asetup mig0,r1 athena ~jchapman/public/G4.9.6.beta00.atlas01_debugging/Looper/test_AtlasG4_muons.py NB mig0 is on a 4 release loop, so r1 will be overwritten on Monday. ============= Part of original output ====================== #Step# X(mm) Y(mm) Z(mm) KinE(MeV) dE(MeV) StepLeng TrackLeng NextVolume ProcName ... 1000004 318 25.3 5.94e+03 2.43e-05 0 1.19e-09 0.00702 LArMgr::LAr::FCAL::Module3::Rod msc 1000005 318 25.3 5.94e+03 2.43e-05 0 1.19e-09 0.00702 LArMgr::LAr::FCAL::Module3::Rod msc 1000006 318 25.3 5.94e+03 2.43e-05 0 1.19e-09 0.00702 LArMgr::LAr::FCAL::Module3::Rod msc 1000007 318 25.3 5.94e+03 2.43e-05 0 1.19e-09 0.00702 LArMgr::LAr::FCAL::Module3::Rod msc 1000008 318 25.3 5.94e+03 2.43e-05 0 1.19e-09 0.00702 LArMgr::LAr::FCAL::Module3::Rod msc 1000009 318 25.3 5.94e+03 2.43e-05 0 1.19e-09 0.00702 LArMgr::LAr::FCAL::Module3::Rod msc 1000010 318 25.3 5.94e+03 2.43e-05 0 1.19e-09 0.00702 LArMgr::LAr::FCAL::Module3::Rod msc From: John Chapman <chapman@hep.phy.cam.ac.uk> Subject: Looper observed with G4 9.6.beta (MIG0 RTT) job Date: August 24, 2012 6:38:42 PM GMT+02:00 We are now in a position to start delving into the output of G4 9.6.beta00 in MIG0,r1. The AtlasG4_muons RTT job, seems to get stuck after a few events in the RTT [automated testing system.] When I re-ran it locally with the LooperKiller switched on, then I see that the LooperKiller is activated. [ Some track took more than 1 million steps.] I only ran 20 events, but you can see the output here on afs: /afs/cern.ch/user/j/jchapman/public/G4.9.6.beta00.atlas01_debugging/Looper/LooperInG49.6.log To reproduce the job do the following: asetup mig0,r1 athena ~jchapman/public/G4.9.6.beta00.atlas01_debugging/Looper/test_AtlasG4_muons.py NB mig0 is on a 4 release loop, so r1 will be overwritten on Monday.
Hello, A simple test : low energy ion in similar media does not show any problem. Code inspection 9.4 versus 9.5 show no difference in step limitation by msc. My suspect is that the problem was always there but show up only now due to bad luck or as a side effect of modifications in other places. It is likely a situation when this ion is near geometry boundary. For low energy particle may be precision lost in computation of particle range and so-called transport cross section for msc. Before proposing a protection which may hidden the real problem would it be possible to have log file with verbose level 6? Only in that case the step limit of transportation will be seen. Vladimir
Vladimir reports that he has been able to create a less severe problem of this type, and has created protection to address the underlying issues.
The fix (protection) is included into current development tree of geant4. It is available with ref-09 and will be in the next public release 9.6. Also the fix is prepared for patch02 of existing 9.5 version of Geant4. VI
