Spanning of variables in Tune Scan

Moderators: cyao, michael_borland

Post Reply
Faissal
Posts: 16
Joined: 11 Jan 2017, 14:53
Location: Diamond Light Source (UK)

Spanning of variables in Tune Scan

Post by Faissal » 26 Apr 2018, 15:06

Dear Sir,

In one of the elegant examples, which is also on this website ( https://www3.aps.anl.gov/forums/elegant ... +scan#p292 ), a tune scan for best dynamic aperture search is provided. I aim to use it as complementary information to the genetic optimization, which I have successfully and extensively used so far.

At first, I run the DATuneScan to benchmark against the picture in the above aps-forum link. I obtain the same result for the APS lattice, but looking more closely, something puzzles me a bit: when I extract the tunes from the files named "scan-tunex-tuney.twi", using a script called "plott" (because it also plot in addition of displaying parameters), I notice that the tune point do not match those indicated in the name of the file:

Code: Select all

[ DATuneScan_cluster_APS_benchmark]$ ./plott scan-36p37-19p40
Printout for SDDS file scan-36p37-19p40.twi

ex0 ($gp$rm) =          2.426441e-09
dnux/dp (1/(2$gp$r)) =  5.996089e+00  dnuy/dp (1/(2$gp$r)) =  6.007089e+00
nux (1/(2$gp$r)) =      3.638030e+01  nuy (1/(2$gp$r)) =      1.941797e+01
I would not have been surprised with a little discrepancy, since the daTemplate.ele introduces some quadrupole errors, but I am puzzled by the fact that here the difference is "large" compared to those indicated in the name of the file: 19.417 instead of 19.40, or 36.38 instead of 36.37 Is it normal or did I do something wrong? I did introduce modification to be able to run the example on Diamond cluster, but nothing that would involve the tune indexing.

Looking into the code, it seem that the discrepancy is abs(nuyChange) and abs(nuxChange) [nux/nuyChange are sometimes negative] although it's not clear why this is set up in scanTune main loop rather than daTemplate.ele. It look that the difference of tune is deliberate but then how to interpret it with respect the name of file?

any help would be most kindly appreciated,

regards,

- Faissal


PS: my attention was pointed to this because of problems I encountered with low-resolution tune scans for testing purposes: points were missing or even "distorded" and it seemed to be linked to this tune indexing mismatch.

(below: left : Michael's plot, right: my plot from the example)

Image
Attachments
test8888.png

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

Re: Spanning of variables in Tune Scan

Post by michael_borland » 27 Apr 2018, 12:08

Faissal,

I think the problem is simply that the tunes are adjusted using a response matrix in a single step. As the tune change gets larger and as the tune approaches the integer and half-integer resonances, this will be inaccurate. That's why I plotted the results as a function of the actual tunes, rather than the desired tunes.

This can be improved by including tune correction in the daTemplate.ele file, using the correct_tunes command, to bring the tunes closer to the desired values.

--Michael

Faissal
Posts: 16
Joined: 11 Jan 2017, 14:53
Location: Diamond Light Source (UK)

Re: Spanning of variables in Tune Scan

Post by Faissal » 30 Apr 2018, 07:35

Hello Michael,

many thanks for your useful explanation. I wanted to confirm that indeed, the correct_tune ELEGANT command seems to have resolved the issue, at least from a preliminary review of the results I ran on the cluster over the weekend. In line with the use of that command, in addition of the information provided in the manual, I used what was available in an old thread started by Marco about this very command ( https://www3.aps.anl.gov/forums/elegant ... 14a6#p2633 )

thanks again

regards,

- Faissal

Post Reply