Mixing ramp_elements with closed_orbit

[dondreka]

Hi,

I'm trying to ramp some elements in a ring lattice while at the same time including a computation of the closed orbit so I can use "center_on_orbit=1" in the track command. More specifically, I have some elements with values defined in the lattice which I want to ramp up from zero to their lattice-value over a certain number of terms. To this end, I specify "differential=0" and "multiplicative=1" in ramp_elements (what one could call "scaling mode"). However, it appears that the computation of the closed orbit interferes with the unperturbed lattice value during the tracking iterations for the orbit search. I'm then left with all values zero for the actual tracking. If I omit the calculation of the orbit, ramping the elements works as expected, but I no longer get the beam centered correctly on the (non-zero) orbit at the beginning of the lattice. Likewise, calculations suceed if I specify the ramp values explicitly (by using "differential=0", "multiplicative=0", "start_value=0.0", and "end_value=<value>", where <value> is the value from the lattice). I would want to avoid the latter option, however, since it forces me to look up the elements' values somehow in the lattice.

Technically, the issue seems to be that the tracking for the orbit search starts the ramp generator, setting pass=0 for every iteration, but then not restoring the original value of the ramped parameter. Thus, when using ramp_elements in "scaling mode" with "start_value=0.0", the "unperturbed" value of the ramped parameter becomes zero after the first orbit iteration. Consequently, the ramped parameter remains at zero for all further orbit iterations, but also for the ensuing tracking.

I attach an archive with a test lattice and an Elegant script to demonstrate the issue.

So my actual question is: Is there any way to get the combination of closed_orbit and ramp_elements (with scaling the lattice value) to work presently? If not, would it be possible to change Elegant's behavior to make it work?

Best regards,
David

[michael_borland]

David,

Thanks for reporting this bug and identifying the root of the issue. It will be fixed in the next release.

Meanwhile, I think the only option is to explicitly specify the starting and ending values, i.e., use differential=0 and multiplicative=0.

--Michael