Problem 321

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.