chromaticity calculations

Moderators: cyao, michael_borland

Post Reply
fanglei
Posts: 1
Joined: 22 Nov 2009, 11:40

chromaticity calculations

Post by fanglei » 25 Sep 2011, 13:03

Dear Michael,

How are you? Can you help me to figure out what happens when i calculate the chromaticities? The situation is following.

First of all, I have to claim that I use elegant for a proton ring with energy 60GeV. Therefore, I give "&change_particle name=proton &end" in the beginning of .ele file.
No sextupoles at this moment. I have an .lte file which bends are set as "sben", quads are "quad". I used the default_order=3 and concat_order=3. So I could get the natural chromacities from up to the 3rd order matrices, am I right? What I get was (-319.6, -396.9). However, occasionally, I set "sben" to "csbend" and "quad" to "kquad" in the .lte file (using the canonical elements definition). I was still using the same .ele file, it came out chromaticities (-319.6,-393.3), a 0.75% discrepancy in the vertical direction. You may say such a trivial off is acceptable. The problem is when I use two sextupoles families to correct this first order chromaticities, they make (-319.6, -396.9) to (0,0) exactly, but canonically get (0,+3). Actually, I do find this off-center when I plot nuy vs. dp/p after canonically tracking particles a few thousands turns. Therefore, this chromaticies were not corrected for off momentum particle, in stead of on momentum particle.

I compare this calculated chromaticities from MADX by using both matrices and PTC twiss. Both of them show (-319, -396) for a ring without sextupoles. I also find some discrepancy for an electron ring lattice. So could you please explain to me where I made mistake and how elegant obtain the natural chromaticies?

Thank you so much!

Best,

Fanglei

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

Re: chromaticity calculations

Post by michael_borland » 27 Sep 2011, 20:12

Fanglei,

My guess is that the discrepancy results from the default values for the order of the edge matrix in CSBEND vs SBEN. In SBEN, it defaults to the default_order value given in &run_setup. In CSBEND, it defaults to 1, because this is symplectic. You can try setting EDGE_ORDER=2 on the CSBEND elements. Also, check that you are using sufficiently large values of N_KICKS for the KQUAD, KSEXT, and CSBEND elements when tracking.

--Michael

Post Reply