Fix the energy loss computation

[lfarv]

In some circumstances, the energy loss computation with the ELossMethod.TRACKING method gives crazy results. This was the reason for the problems reported in #858.

They PR replaces the tracking over the whole lattice with element-by-element tracking, which was up-to now used only as a fallback solution. This eliminates the reported problem and gives more generally a better agreement with the
ELossMethod.INTEGRAL method.

Because of some optimisations, this also reduces by ~45% the time taken by the computation.

[lfarv]

Unfortunately, this induces a small change in the "guess" orbit used as a starting point for find_orbit6. And consequently, the very small change in the resulting closed orbit affect the results of emittance and chromaticity computations.

The Matlab/python comparison is slightly worse, so the unit tests have been once again modified.

[lfarv]

In my understanding, the problem occurs only for the hmba test lattice, where the chromatic closed orbit is computed at a point of ~zero dispersion. As a consequence, the accuracy of the result is bad: the closed orbit for any $\delta$ is almost the same. In these conditions, the accuracy can be significantly improved by increasing the DPStep use for dispersion and chromaticity computation. Changing it from 3.0E-6 to 3.0E-5 brings the Matlab/python divergence of horizontal chromaticity to more that a factor 10 smaller.

So should we envisage to change the DPStep default value?

[lfarv]

@swhite2401 and @simoneliuzzo : running the FCCee_v23.mat test script with this branch completely avoids the "Missing RF voltage" error. find_orbit6 returns either a valid orbit or NaNs. In lots of runs, I never got the LinAlg error. Tell me if you still see it.

[lfarv]

There may still be errors when computing the "guess" orbit, if the RF voltage is really insufficient. It is now watched in find_orbit and re-raised so that the full information is available:

---------------------------------------------------------------------------
AtError                                   Traceback (most recent call last)
File [~/dev/libraries/at/pyat/at/physics/orbit.py:326] in _orbit6(ring, cavpts, guess, keep_lattice, **kwargs)
    325 try:
--> 326     _, dt = get_timelag_fromU0(ring, method=method, cavpts=cavpts)
    327 except AtError as exc:

...

AtError: Not enough RF voltage: check RF settings

The above exception was the direct cause of the following exception:

AtError                                   Traceback (most recent call last)
Cell In[7], line 1
----> 1 a, b = ring2.find_orbit()

File [~/dev/libraries/at/pyat/at/physics/orbit.py:510] in find_orbit(ring, refpts, **kwargs)

...

AtError: Could not determine the initial synchronous phase

As it is now, find_orbit stops. Alternately, one could choose to continue with 0.0 synchronous phase. What is you advice ?

[swhite2401]

As it is now, find_orbit stops. Alternately, one could choose to continue with 0.0 synchronous phase. What is you advice ?

I think I could be useful to give some more advice on how to fix the issue...if the reason is really the voltage it should appear in the error message, with maybe a printout of the energy loss/turn and voltage

[lfarv]

if the reason is really the voltage it should appear in the error message

As you can see in the error report above, the "Not enough RF voltage: check RF settings" message clearly appears as the origin of the subsequent errors.

In the case of a single RF system, I can easily add a printout of losses and voltage. In the case of several cavities with different frequencies, it would need an additional computation of the maximum voltage, which is not obvious. In that case the present message is "No solution found for Phis: check RF settings". I would rather replace it by the same message as in the single cavity case…

[swhite2401]

Ah sorry, I read only the second error, do you really want to print out this much?

[lfarv]

python has a standard way of dealing with chained errors: raise exception2 from exception1. This causes what you see here: it displays exception1, the origin of the problem, then mentions "this was the direct cause of the following exception", then displays exception2 and so on. Which is exactly what happened.

I agree that this is very verbose. One could bypass this by catching exception1, rewriting a new combined error message and then raising exception2 from None. But the standard way gives the full chaining, which is useful for understanding the problem. Otherwise you loose the backtrace of the origin of the problem. So my preference is to stick to the normal way: error messages are intended to be carefully read!

But it may be discussed…

[swhite2401]

Fine for me