exact drift code generates silent NaNs

[amereghe]

from @vkbo

Exact drift fails with a debug build, and proceeds with a NaN value, for the particle momentum from the exact drift calculation because the square root becomes negative due to the sum of the squared angles exceed 1e6 here (track_thin.f90 on line 734):

if(iexact) then ! EXACT DRIFT
do j=1,napx
pz       = sqrt(c1e6 - (yv1(j)**2 + yv2(j)**2))*c1m3 ! pz/p0
xv1(j)   = xv1(j)   + stracki*(yv1(j)/pz)
xv2(j)   = xv2(j)   + stracki*(yv2(j)/pz)
sigmv(j) = sigmv(j) + stracki*((one - rvv(j)/pz)*c1e3)
end do

There is nothing that checks for these kind of numbers being in range, that would slow down the drift code. I'm not sure this is really an issue in itself, but it may be interesting to see exactly why this particle gets such large angles. The standard drift calculation doesn't fail on it because it just sums the angles.

[amereghe]

from @rdemaria

Very large angles are caused by a particle entering in a nonlinear element with a large orbit. This is the mechanism of particles loss. We have an aperture check that somehow limits the orbit and therefore the kick to avoid overflows. The exact drift is suffering because being more physical it is does not accept nonphysical coordinates. A solution is to run using a tighter aperture check or rather add an angle check in the exact drift. I think the latter is the correct solution, it should not be expensive because it is enough to loose the particle when c1e6 - (yv1(j)**2 + yv2(j)**2) is negative which needs to be computed anyway.

What do you think?

[amereghe]

to be noted that, in principle, using an aperture more realistic than just 1m everywhere should automatically solve the issue. Nevertheless, I prefer the code to error in these case, but it is true that, if an sensible aperture profile is provided, these particles are lost on the aperture at a suitable moment.