Issue with integer tune

Moderators: michael_borland, soliday

Post Reply
wurtzw
Posts: 10
Joined: 16 Nov 2009, 16:50
Location: Canadian Light Source

Issue with integer tune

Post by wurtzw » 15 May 2020, 17:46

Hello All,

I am tinkering with a simple model for the second field integrals of an insertion device. I perform two kicks using FMULT, one at each end of the the device. The model is (kick, drift, counter-kick).

When I do this, I find that elegant is calculating an integer tune that is 1 integer higher than expected. I have put together a simple model to demonstrate this behaviour. The model contains two of CLS's DBA cells, with the insertion device in the upstream half of the straight, between the two cells (where it is in real life).

If I set the entrance and exit kicks to zero, I get a vertical phase advance of 4.482 rad = 0.7133 x 2 pi rad. Here is the resulting plot of the beta and psi.
twiss_no_kick.png
However, if I include the entrance and exit kicks, I get a vertical phase advance of 10.765 rad = 1.7134 x 2 pi rad. This is one tune integer more than expected. Here is the resulting plot of beta and psi. Note the discontinuity, which occurs at the second kick (the downstream end of the ID).
twiss_with_kick.png
I am using elegant version 2020.2.0. Note, when I try this example with an older version of elegant, 33.0.3, I do not see the integer tune jump.

I have attached my example to this post in nuy_integer_issue.tgz.
cls.lte: the lattice file
twiss.ele: the elegant instruction file
plotTwiss: calls sddsplot
no_kick: example directory where the kicks at the ends of the insertion device are set to zero
with_kick: example directory where the kicks at the ends of the insertion device are nonzero

Inside the two directories, you will find the following files:
second_field_integral_fmult1.sdds: non-linear kick at upstream end of the device
second_field_integral_fmult2.sdds: non-linear kick at downstream end of the device
runme: script with the commands to call elegant and sddsplot
output.txt: output from running elegant (version information is here)
cls.lte: output from &twiss_output
cls.mag: magnet output for making nice plots
twiss.png: the plots shown above

Kind Regards,
Ward Wurtz
Attachments
nuy_integer_issue.tgz
(52.14 KiB) Downloaded 213 times

michael_borland
Posts: 1796
Joined: 19 May 2008, 09:33
Location: Argonne National Laboratory
Contact:

Re: Issue with integer tune

Post by michael_borland » 18 May 2020, 18:09

Ward,

This is a problem of numerical accuracy in determination of the matrix for the FMULT element. For FMULT, elegant uses particle tracking to find an approximate matrix (linear and higher-order, if needed). In your case, the matrix for one of the FMULT elements has very small R34<0, which looks to elegant like a phase advance of nearly 2*Pi. That's where the extra integer originates.

You can "fix" the problem by changing the step factor for tracking-based matrix determination, using

Code: Select all

&global_settings
tracking_matrix_step_factor = 10
&end
before your &run_setup command.

You can also give the FMULT elements a small, nonzero length, e.g, 1e-6.

The reason you didn't see this in the previous version is that the previous version ignored FMULT elements for computation of twiss parameters (if I recall correctly).

--Michael

wurtzw
Posts: 10
Joined: 16 Nov 2009, 16:50
Location: Canadian Light Source

Re: Issue with integer tune

Post by wurtzw » 19 May 2020, 15:43

Hi Michael,

Thank you for your help with this issue and the explenation. It was very easy for me to give the FMULT elements a non-zero length and remove a corresponding length from the drift element. I now get the correct integer tune.

Thanks again,
Ward

Post Reply