feat: compute longitudinal RDT fluctuations.

[wei0852]

Computation of the longitudinal RDT fluctuations.

Minimizing the longitudinal RDT fluctuations can effectively enlarge the DA area. This has been reported by Zhenghe Bai at the AT Workshop.

Z. Bai, "Minimizing the fluctuation of resonance driving terms for storage ring dynamic aperture optimization and its implementation on AT." AT Workshop, 2023.10.

And here is the function to compute RDT fluctuations.

[RDT,buildup_fluctuation,natural_fluctuation] = computeRDTfluctuation(ring, varargin)

computeRDTfluctuation.m is the function to compute RDT fluctuations, which calls RDTbuildupFluct.m and return three structs.

RDTfluctuationIndicator.m is a function that provides one example to quantitatively represents the RDT fluctuations.
People can try other quantitative representations.

We uploaded some example scripts in the repository: ATRDTfluctuation,

Features:

• Compute two kinds of longitudinal fluctuations of RDTs.

• Slice sextupoles.

  The number of sextupole slices affects the calculation of crossing terms, especially the ADTS terms.

• Faster calculation.

  This is because the RDT fluctuation data simplifies the calculation of crossing terms. The number of iterations is reduced from N^2 to N.

• multiple periods

  This function can calculate RDTs of multiple periods with the fluctuation data of one period.

Noting:

Two differences between computeRDT and computeRDTfluctuation

• opposite numbers

  These are just differences of notations. We don't think it is a problem. Our functions followed the notation in SLS-Note 09/97. Usually we only care about the absolute values.

• Initial phases

  The initial phase in computeRDT is the average phase of the initial element.

  But in computeRDTfluctuation, the initial phase is zero.
  This is because we think that the starting point should be a point and not a section.

  Therefore, the results of the two functions agree only when the length of the initial element is 0.

[lfarv]

Hi @wei0852, thanks for contributing

But in computeRDTfluctuation, the initial phase is zero. This is because we think that the starting point should be a point and not a section.

On this I agree with you.

That looks OK for me. Do you want to comment, @carmignani ?

[carmignani]

Hello,
I also agree that it is good to start from the beginning of the ring and not from the average of the first element.
I did not check the code in details, I just tried it and it looks nice.
I tried to run the code with the ESRF lattice, where the first element has zero length, and the results are very similar, except the sign, but not identical.
I don't know where the disagreement comes from. I tried to change the number of slices, but the value of the RDT in the first element does not change with the number of slices.

[wei0852]

Hello, I also agree that it is good to start from the beginning of the ring and not from the average of the first element. I did not check the code in details, I just tried it and it looks nice. I tried to run the code with the ESRF lattice, where the first element has zero length, and the results are very similar, except the sign, but not identical. I don't know where the disagreement comes from. I tried to change the number of slices, but the value of the RDT in the first element does not change with the number of slices.

Hello,
Thank you for agreeing.
I tried the ESRF lattice that I found in at/meachine_data (and added a BPM at the beginning).
Although my results are different from yours, on my computer the results are the same for both functions.
Have you tried using [RDTnew,~,~]=computeRDTfluctuation(r,'nslices',1, 'nperiods', 1)?
Or you can send me your lattice file and I will check my function.

[carmignani]

Hello @wei0852,
I'm sorry, in the test I wrote 'slices' instead of 'nslices', so the option 1 slice was ignored.
Ok, I confirm now that without slicing the agreement is good. The difference is about 10^-14 to 10^-10 for the esrf ebs lattice. The lattice in machine_data is the old machine.

[wei0852]

Hello @wei0852, I'm sorry, in the test I wrote 'slices' instead of 'nslices', so the option 1 slice was ignored. Ok, I confirm now that without slicing the agreement is good. The difference is about 10^-14 to 10^-10 for the esrf ebs lattice. The lattice in machine_data is the old machine.

Hello,
I'm sorry, the validation of input argument is not complete enough. I added more validation in the new commit.

[lfarv]

Thanks @wei0852 and @carmignani. I will now merge.