Energy ramp

[carmignani]

I was doing simulations about the injection efficiency in the ESRF booster and I quickly realised that I needed to ramp the energy. So I wrote a pass method called EnergyRampPass.c that changes at each turn the energy property in the struct parameters that is passed to each pass method. The ramp is defined by two arrays and the pass method does linear interpolations. I also modified RFCavityPass to allow to define a voltage ramp, similarly to how we define the energy ramp.
I then changed the main rad and quant pass methods for the dipoles and multipoles to use the energy stored in the struct parameters and not the one in the Energy field of the element.
The pull request is far to be mergeable, because I did not update all the passmethods using the energy and I did not write an element creator for python. But then we should decide if we accept to completely remove the energy field from the elements or if we want to keep both the energy in the structure and the energy in the element. In that case we have to choose which one has higher priority.

In the figure I put an example of horizontal and vertical emittance, energy spread and bunch length evolution during the ramp in the ESRF booster. The ramp ends at about 135000 turns, but the simulation continues until 200000 with fixed energy.

[carmignani]

I notice that several tests are not passed and also that I forgot some debugging commented "printf" in the code that I will remove. But I will work on this after holidays.

[swhite2401]

This is a very nice and useful development.

I haven't looked at the code. For what concerns you question: since we cannot suppress the element attribute Energy for backward compatibility I tend to think that it should have the priority if it exists, otherwise take the ring property.

@lfarv what do you think?

[lfarv]

@carmignani and @swhite2401 : indeed very interesting and useful.

Now for the "energy" problem:

• in python, the Energy field of the elements is useless: the energy is always be taken from the lattice, and consequently from the Param structure in C. In this PR, since the energy will be varied during the tracking, we must find a way to put back the final value into the lattice at the end of tracking.
• in Matlab, this cannot be done for compatibility reason: the RingParam element is not mandatory (even if it is now recommended), so the energy must be available in the elements in there is no RingParam. This energy field is used in the *RadPass or *QuantPass integrators and in findmpoleraddiffmatrix. With opposite priorities: RadPass methods give priority to the element field, findmpoleraddiffmatrix to the ring energy !

Practically, Energy is still present in python elements, and even reset to the right value on each enable_6d. This is in case the lattice is saved to be open in Matlab. This could be avoided since a lattice saved by python will always have a RingParam element!

All this should be clarified ! I propose to do this in 2 steps:

1. Make sure that Matlab works without energy field in elements when there is a RingParam element. Integrators are ready (I think…), findmpoleraddiffmatrix is ready (and is being replaced in another PR). Just the priority should be set consistent (preferably to the ring energy: there is no guarantee the all the Energy fields are consistent). Tracking should already be OK, but ohmienvelope does not yet send the ring energy to findmpoleraddiffmatrix. This looks like a simple addition, but one needs to be very careful.
2. Once this is done, completely remove the Energy field from elements in python. I don't think is is used anywhere, but one has to make sure that if there is a remaining Energy field, it is ignored. Again, it needs a lot of care.

These two steps are very critical: they affect the core of the tracking engine and there may be unexpected places where the Energy field is used.