kquad and csbend

Moderators: cyao, michael_borland

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

Re: kquad and csbend

Post by michael_borland » 10 Sep 2018, 12:29

Mina,

The problem appears to be incorrect setup of synchrotron radiation in the ringelement beamline. In particular, you have included SR1 (an SREFFECTS element), which gives lumped-element radiation. Meanwhile, the RING beamline includes CSBEND elements that have ISR=1, so you are getting twice the quantum excitation. You should remove SR1 from this beamline, then set ISR=1 and SYNCH_RAD=1 on all CSBEND, KQUAD, and KSEXT elements.

Another problem is that the rf cavity is at the start of the beamline. This means that on the first pass, the beam gets an energy increase that changes the time of flight through the beamline, resulting in an energy oscillation. This is different from the ILMATRIX tracking, where you have SR followed by RF (the recommended order). This will eventually damp out, but can add confusion. For better consistency, you should put the rf cavity after the RING beamline .

A less important issue is that the rf frequency should ideally be set based on the actual time of flight around the ring, which differs from the ideal value since the latter is computed without synchrotron radiation. You can get this by tracking a single turn and looking at the Ct quantity in the WATCH output file (use sdds2stream -col=Ct to get the value to full precision). That will diminish the synchrotron oscillation somewhat.

I've attached a modified version of your files that fixes the problems I found. Note that for faster testing, I reduced the number of particles and passes. As you can see, the agreement is now reasonable.
comparison.png
--Michael
Attachments
ILMATRIX-element.zip
(4.23 KiB) Downloaded 264 times

Akhyani
Posts: 16
Joined: 26 Jun 2018, 08:09

Re: kquad and csbend

Post by Akhyani » 15 Sep 2018, 01:19

Thanks Micheal. That was a big help. You are the best!

Best wishes,
Mina

Akhyani
Posts: 16
Joined: 26 Jun 2018, 08:09

Re: kquad and csbend

Post by Akhyani » 07 Jan 2019, 23:48

Dear Michael and all,

I am trying to find the ILMatrix for different values of chromaticity of the lattice. I use the method of "ILMatrix from tracking" which is available online in ELEGANT examples. The primary twiss parameters shows that the values of chromaticity have been changed to the desired value, but at last, after running ILMatrixFromFmap, the final chromaticies are different from the twiss values. I attached the lattice, twiss file and ILMatrix result file, which is for chromaticity x/y equal to 0/0 in twiss output and -2/-1 in ILMatrix. I will be appreciated if you could help me what is the real value of chromaticity.

Regards,
Mina
Attachments
ILMatrixFromTracking.rar
(79.55 KiB) Downloaded 209 times

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

Re: kquad and csbend

Post by michael_borland » 08 Jan 2019, 09:04

Mina,

One source of this discrepancy might be a bug that was introduced in KQUAD in version 35.0.1. Have you tried this with version 35.1.0?

--Michael

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

Re: kquad and csbend

Post by michael_borland » 08 Jan 2019, 09:52

Mina,

I found two problems:
  • You have SYNCH_RAD=1 and ISR=1 on all the magnetic elements. You'll need to turn this off as the decay of the energy and quantum excitation of the motion will confuse the analysis.
  • You have N_KICKS set to fairly small values. I increased these to 20 for quadrupoles and 60 for dipoles.
After making these changes, I get good agreement:
  • x tune: 0.2000 vs 0.2014
  • y tune: 0.1800 vs 0.1802
  • x chromaticity: 0 vs 0.02
  • y chromaticity: 0 vs 0.0006
Further improvement in the tune agreement can be obtained by increasing N_KICKS further.

--Michael

Akhyani
Posts: 16
Joined: 26 Jun 2018, 08:09

Re: kquad and csbend

Post by Akhyani » 21 Jan 2019, 05:40

Dear Michael,

Many thanks for the solution. It worked. Also, the same issue as mine exists in the ELEGANT examples. I think it would be beneficial to modify it too. Now, I realized a difference between the head tail modes appeared with the previous, less accurate method and the modified solution you mentioned above. Previously, the modes were clear enough to identify, but now it's a bit messy. I will be glad if I have your comment on this issue.
I attached the results and lattice files for you. It should be mentioned that I used NAFF algorithm embedded in ELEGANT to clarify the modes.


Bests,
Mina
Attachments
H-T modes.rar
(276.36 KiB) Downloaded 220 times

Post Reply