Forbid negative lattice or element energies

[swhite2401]

This PR solves issue #1039, atelem.c is reformatted to forbid negative energies, all passmethods requiring energy field are modified to correctly report errors.

[lfarv]

In python, the energy is taken only from the lattice, never from the element (when reading .mat files, the energy field is removed from all elements). So you need different versions for Matlab and python. The python version should be:

double atEnergy(double ringenergy, double elemenergy)
{
    if (ringenergy > 0.0)
        return ringenergy;
    else {
        atError("Energy must be positive. Check lattice or passmethod parameters.");
        return 0.0;
    }
}

[swhite2401]

This makes element_pass crash for passmethods requiring energy, any idea?

[lfarv]

Starting from your branch, I set this in the python section of atelem.c:

double atEnergy(double ringenergy, double elemenergy)
{
    if (ringenergy > 0.0)
        return ringenergy;
    else {
        atError("Energy not defined.");
        return 0.0;
    }
}

double atGamma(double ringenergy, double elemenergy, double rest_energy)
{
    if (ringenergy > 0.0) {
        if (rest_energy == 0.0)
            return 1.0E-9 * ringenergy / __E0;
        else
            return ringenergy / rest_energy;
    }
    else {
        atError("Energy not defined.");
        return 0.0;
    }
}

And I get the expected result (no crash):

(pyat) laurent@garou at % python
Python 3.10.20 | packaged by conda-forge | (main, Mar  5 2026, 17:06:34) [Clang 19.1.7 ] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import at
>>> import numpy as np
>>> dip = at.Dipole('D', 2.0, 1.0, k=0.0, PassMethod='BndMPoleSymplectic4RadPass')
>>> pout = dip.track(np.zeros(6))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Users/laurent/dev/libraries/at/pyat/at/tracking/track.py", line 419, in element_track
    rout = _element_pass(element, r_in, **kwargs)
  File "/Users/laurent/dev/libraries/at/pyat/at/tracking/utils.py", line 109, in wrapper
    return func(lattice, r_in, *args, **kwargs)
  File "/Users/laurent/dev/libraries/at/pyat/at/tracking/track.py", line 93, in _element_pass
    return _elempass(element, r_in, **kwargs)
ValueError: Energy not defined.
>>> 

[swhite2401]

Strange... with the RFCavity it did.... let me try again

[swhite2401]

I confirm that for me it crashes for dipole as well..., ringenergy is not defined in an element so in fact I don't know how if can work for you....

[swhite2401]

It does because you give the kw argument energy to the track() function. Shouldn't we allow the user to alternatively provide the Energy element attribute as in the example I provided above?

I don't think this costs anything in terms of efficiency since this second check is ran only when the ringenergy is not defined which basically never happens.

[lfarv]

It' a question of logic:

Defining the energy in element attributes introduces the risk of having different energies in different elements, that's why when starting pyat we removed it systematically. Of course this does not prevent from explicitly adding such an attribute, like any other custom attribute.

But when tracking comes in, I still think that the energy is related with the tracked particle rather than with the element itself. I very much prefer giving it as a keyword in Lattice.track or Element.track rather than as an element attribute… Similarly I would not set the particle as a element attribute, while it is accepted as a keyword in Lattice.track and Element.track. Even if it is still not used…

[swhite2401]

Ok understood as long as this is clearly defined this is fine for me, is there a way to set a meaningful error for element_pass, for instance if the ringenergy is really undefined (NaN)?

[lfarv]

The error message could be something like:
"Energy needs to be defined and positive. Check lattice parameters and tracking options."

Strictly speaking, the energy should be greater than the particle rest energy, but we may forget that…

[swhite2401]

Yes I have changed it to something similar

[lfarv]

For python, the macro as it is is enough (and more efficient).

[swhite2401]

I am not so sure about this, how about a simulation of energy ramp where the energy is set to negative during the ramp? I think we still need the energy check in atGamma()

[lfarv]

The test as it is was implemented by @oscarxblanco in #1016 to solve the same issue as you do.
What you write here is exactly what I suggested in #1016 (comment) but was not implemented. So it's ok for me

[swhite2401]

I have implemented the requested change

[lfarv]

That looks good !