2_layout_one_of_each test failing

[Jochem Snuverink]

The "2_layout_one_of_each" test is failing consistently with:

-------- WWWW ------- G4Exception-START -------- WWWW -------
*** G4Exception : GeomField1001
      issued by : G4MagInt_Driver::AccurateAdvance()
Proposed step is zero; hstep = 0 !
*** This is just a warning message. ***
-------- WWWW -------- G4Exception-END --------- WWWW -------


-------- EEEE ------- G4Exception-START -------- EEEE -------
*** G4Exception : GeomNav0003
      issued by : G4PropagatorInField::ComputeStep()
Curve length mis-match between original state and proposed endpoint of propagation.
  The curve length of the endpoint should be: 6.61384e-25
  and it is instead: 2.61536e-22.
  A difference of: -2.60875e-22
  Original state =  (  X= 0 0 2500  P= 0 0 9955.88497  Pmag= 9955.88497 Ekin= 9061.72799 l= 0 m0= 938.272 (Pdir-1)= 0 t_lab= 8.37606 t_proper= 0.785902 PolV= (0,0,0)  ) 
  Proposed state =  (  X= 0 0 2500  P= 0 0 9955.88497  Pmag= 9955.88497 Ekin= 9061.72799 l= 2.61536122935e-22 m0= 938.272 (Pdir-1)= 0 t_lab= 0 t_proper= 0 PolV= (0,0,0)  ) 

I had a look, nothing conclusive but I thought I would share my findings. The beamline is as follows:

d1: drift, l=1*m;
q1: quadrupole, l=0.5*m, k1=1.31;
sex1: sextupole, l=0.5*m, k2=0.31;
oct1: octupole, l=0.5*m, k3=3.31;
sol1: solenoid, l=0.5*m, ks=1.31;
c1: rcol, l=1*m, ysize=5*mm, xsize=5*mm, material="Copper";
sb1: sbend, l=4*m, angle=0.3;
rb1: rbend, l=10*m, angle=-0.4;
endoftheline: marker;

l1: line = (d1,q1,d1,sex1,d1,oct1,d1,sol1,c1,d1,sb1,d1,rb1,d1,endoftheline);

There is a very strong and long rbend in the line. This is probably the culprit.

I added the options stopSecondaries and stopTracks to be sure it is not a low energy secondary particle.

If I make one of the following changes there is no crash:

• flip the sign of the angle of the rbend
• reduce the angle to -0.25
• reduce the length to 5 meters
• increase the drift in between to 3*m (now the poles get build)
• change the magnetGeometry, to e.g. "cylindrical", there is only a crash with "polessquare" and "polescircular" (default)
• change the line (d1,sb1,d1,rb1,d1) (probably now the reference particle has a slightly different position?)

My guess is that it has something to do with the magnetGeometry, but it is all fairly mystifying.

This happened between 29 and 30 January:

http://abp-cdash.web.cern.ch/abp-cdash/testSummary.php?project=11&name=2_layout_one_of_each&date=2017-01-29

http://abp-cdash.web.cern.ch/abp-cdash/testSummary.php?project=11&name=2_layout_one_of_each&date=2017-01-30

This was when the curvilinear world was added, though this seems to be such a rare case of parameters that it might have not much to do with it.

[Laurie Nevay]

Well, this was certainly interesting to fix.

• It happens by changing only the yokeOnInside parameter for the rbend, flipping the geometry.

I looked into the rbend geometry, which is the same as the sbend - 'dipole' for the poled geometry. Geant4 doesn't detect any overlaps but I figured something was wrong. I exaggerated the length safety large constant to 1 cm to see any overlaps and there were quite a few mistakes in the geometry. Note the slanted poles, and overlapping containers around the coils.

The containers and yoke are defined by a vector of points for an extrusion solid. There were inconsistencies in this that have since been fixed. Longitudinally, all solids were the same length too which was also a problem. With the magnet outer, we can afford a little more margin. This has now been fixed - screen shot here with exaggerated margins.

[Laurie Nevay]

This however, didn't fix issue for the failing test. I figured it must therefore be to do with tracking - we've certainly had problems with our dipole integrator in the past. Debugging the tracking, I found that the particle never makes it to the rbend - the dipole routine is never called before all the problems. This would seem to be quite at odds with the effect the rbend geometry has on the outcome.

It was in fact due to a transform look up issue in the sextupole further up stream. Recently, we've had a lot of boundary problems between parallel worlds. A given point on a boundary in the mass world is not found to be in an identical volume in a parallel world. This resulted in getting a transform from the wrong volume. To solve this, changes were made such that the full step was used for the lookup - the midpoint specifically.

Elsewhere, we also removed all the G4UserLimits instances throughout bdsim that were set to limit the step length to half the length of the object - a hangover and unnecessary. This had the effect of releasing the field numerical integrators to try much larger steps. If the integrators are robust, this isn't a problem.

Because of these changes, Geant4 will try large steps in the field - especially if a weak field - to see how far it could reasonably go in that field while meeting its required accuracy. This of course can be much much further than the boundary. The boundary limiter is another process that proposes a step length and geant4 chooses the shortest step length from all proposing processes.

In this test, Geant4 was querying a large step in the relatively weak sextupole field. The mid point of the step that was being requested for transforms lies somewhere in the rbend - hence the effect it's having.

I changed the transform look up for a step to lookup a maximum of 1mm ahead on the track to avoid such situations. We still have to look a wee bit ahead otherwise we'll hit boundary issues again.

I really wish Geant4's field tracking would request a default of 1 million mm as the first step. The world isn't even that big.