Hello, I provide you a program with a simple geometry (there is one polycone), a uniform magnetic field of 4 tesla along the Z axis. Then I shoot a charged geantino with 0.1 MeV from a given point and in a given direction. The geantino makes some progress and then starts to loop. The stepper is SimpleHeum and minimum epsilon step is 1.e-7 mm. You have just to compile, run and /run/beamOn 1 It is possible to reproduce the problem with other steppers an energies. greetings, V. Lara
Hello V. Lara: I apologize for keeping you waiting for so long on this issue. Here is the difficulty: when an infinite loop or other issue appears in the transportation of a particle, is it the fault of the solid or of the navigator? When I first received your bug report, I tried your code with the BaBar transportation code (see http://geant4.slac.stanford.edu/UsersWorkshop/PDF/DavidW/bgstransport.pdf) for more information) and it ran fine. This does not, however, prove that the G4Navigator is the source of your problems, since the G4Navigator and the Bogus transportation use solids in different ways. To locate your problem, therefore, requires me to get into the debugger and trace the source of the infinite loop. To debug my own code is simple, but I did not write the navigator, and it is very complex. It will take me some time. Also, may I ask, has the recent geant4 tags solved your problem?
Hello John: Sorry to have to throw this on your lap, and sorry also for not getting to it earlier. As far as I can see, the navigator is working fine, it is just that particle being transported is a looper that is difficult to handle using the standard steppers. The result is a rather large CPU overhead (at least in the old version of geant4 I'm using). Perhaps you can confirm my suspicions. At least, it doesn't seem that G4Polycone is at fault. In any case, I think you may be able to give this person much better advice than I can. Perhaps one of the new helical steppers would work much better? - Dave P.S. I couldn't resist trying BgsTransportation on the example, and it seemed to cope fairly well (not surprising). I've included that log file also, in case you were interested. ----------------------- ********************************************** Geant4 version $Name: geant4-03-01-ref-00 $ (06-Apr-2001) Copyright : Geant4 Collaboration ********************************************** Idle> run/beamOn 1 [snip] ********************************************************************************************************* * G4Track Information: Particle = chargedgeantino, Track ID = 1, Parent ID = 0 ********************************************************************************************************* Step# X(mm) Y(mm) Z(mm) KinE(MeV) dE(MeV) StepLeng TrackLeng NextVolume ProcName 0 39.294 2.443 -2643.320 0.100 0.000 0.000 0.000 cmsBeamPipeIn2 initStep Warning (G4MagIntegratorDriver): The stepsize for the next iteration=0.00125469 is too small - in Step number 1. Requested step size was 8.90458 . Previous step size was 8.90458 . The minimum for the driver is 0.01 The integrations has already gone 0.000890458 [snip] G4PropagateInField: Warning: Particle is looping - tracking in field will be stopped. It has performed 10000 steps in Field while a maximum of 10000 are allowed. 1 39.209 2.423 -2651.005 0.100 0.000 9.126 9.126 cmsBeamPipeIn2 Transportation [snip] G4PropagateInField: Warning: Particle is looping - tracking in field will be stopped. It has performed 10000 steps in Field while a maximum of 10000 are allowed. 62 39.278 2.478 -3119.778 0.100 0.000 9.126 565.805 cmsBeamPipeIn2 Transportation 63 39.218 2.411 -3120.000 0.100 0.000 0.264 566.069 cmsBeamPipe Transportation [snip] G4PropagateInField: Warning: Particle is looping - tracking in field will be stopped. It has performed 10000 steps in Field while a maximum of 10000 are allowed. 1517 39.277 2.479 -14293.708 0.100 0.000 9.126 13835.121 cmsBeamPipe Transportation 1518 39.281 2.414 -14300.000 0.100 0.000 7.472 13842.592 cmsWorld Transportation [snip] G4PropagateInField: Warning: Particle is looping - tracking in field will be stopped. It has performed 10000 steps in Field while a maximum of 10000 are allowed. 2916 39.231 2.403 -26968.878 0.100 0.000 34.909 28887.195 cmsWorld Transportation 2917 39.275 2.481 -27000.000 0.100 0.000 36.958 28924.153 OutOfWorld Transportation [snip] Run Summary Number of events processed : 1 User=3989.58s Real=3992.82s Sys=1.53s ----------------------- ----------------------- ********************************************************************************************************* * G4Track Information: Particle = chargedgeantino, Track ID = 1, Parent ID = 0 ********************************************************************************************************* Step# X(mm) Y(mm) Z(mm) KinE(MeV) dE(MeV) StepLeng TrackLeng NextVolume ProcName 0 39.294 2.443 -2643.320 0.100 0.000 0.000 0.000 cmsBeamPipeIn2 initStep 1 39.218 2.411 -3120.000 0.100 0.000 566.069 566.069 cmsBeamPipe BgsTransportation 2 39.281 2.413 -14300.000 0.100 0.000 13276.523 13842.593 cmsWorld BgsTransportation 3 39.277 2.479 -27000.000 0.100 0.000 15081.561 28924.153 OutOfWorld BgsTransportation [snip] Run Summary Number of events processed : 1 User=0.03s Real=0.03s Sys=0.00s -----------------------
We will investigate this issue, with a view to recommending an alternative stepper which is more appropriate for low energy particles in strong slow- varying fields (in which looping particles can take large computation times to integrate with the simple integration steppers). ( This investigation is dependent on obtaining copy of the problem report's source code - which is no longer located as above. )
The problem seen appears indeed to be an issue of large computational time when utilising the default stepper for a very low energy electron (0.1 MeV) in a strong magnetic field (4 Tesla) in a vacuum. In this case the Runge Kutta integration is not very suitable, as the particle drifts large distances, while looping very tightly causing significant ('macroscopic' ie seconds) of CPU time to be spent for a single tracking step of the particle. A general solution for such a problem is under investigation. However it is possible to avoid utilising the Runge Kutta stepper in such volumes by creating a separate G4ChordFinder and stepper for volume with a vacuum and a strong field. For these volumes a 'helical' stepper that takes into account the known analytical solution in a constant field and uses as a first order solution even for varying fields will give excellent performance. This can be substituted as follows: G4MagIntegratorStepper *pStepper; // pStepper = new G4SimpleHeum(fEquation); // pStepper = new G4ClassicalRK4(fEquation); // pStepper = new G4HelixImplicitEuler(fEquation); pStepper = new G4HelixExplicitEuler(fEquation); and results in very fast performance for the case of this problem report. In particular it produces the following output: Geant4 version $Name: geant4-04-00-ref-02 $ (28-Feb-2002) Copyright : Geant4 Collaboration ********************************************** Idle> /run/beamOn 1 Start Run processing. ===================================== G4EventManager::ProcessOneEvent() ===================================== 1 primaries are passed from G4EventTransformer. !!!!!!! Now start processing an event !!!!!!! ### pop requested out of 1 stacked tracks. ******************************************************************************** ************************* * G4Track Information: Particle = chargedgeantino, Track ID = 1, Parent ID = 0 ******************************************************************************** ************************* G4SteppingManager::SetInitialStep pathNo Touchable Found Step# X(mm) Y(mm) Z(mm) KinE(MeV) dE(MeV) StepLeng TrackLeng NextVolume ProcName 0 39.3 2.44 -2.64e+03 0.1 0 0 0 cmsBeamPipeIn2 initStep 1 39.3 2.44 -3.12e+03 0.1 0 566 566 cmsBeamPipe Transportation 2 39.3 2.44 -1.43e+04 0.1 0 1.33e+04 1.38e+04 cmsWorld Transportation 3 39.3 2.44 -2.7e+04 0.1 0 1.51e+04 2.89e+04 OutOfWorld Transportation Track (trackID 1, parentID 0) is processed with stopping code 2 ### pop requested out of 0 stacked tracks. ### 0 waiting tracks are re-classified to 0 urgent tracks and 0 waiting tracks. NULL returned from G4StackManager. Terminate current event processing. Run terminated. Run Summary Number of events processed : 1 User=0s Real=0s Sys=0s Idle>
This problem is about low energy particle in strong Magnetic Field in vacuum. In this case tracking with default stepper G4ClassicalRK4 is very slow. But if HelicalSteppers are used the tracking is very fast. The solution is use new G4HelixMixedStepper. This stepper automaticly chose between G4ClassicalRK4 or G4HelixExplicitEuler.
