About the edge_effects option in the CSBEND element

[Siwei_Wang]

Dear all,

When I used ELEGANT to calculate the chromaticity of our storage ring and compared the result with AT, I found a little difference in the chromaticity with a deviation of about 0.1. Then I found that the problem comes from the dipole fringe field. If I turn off the edge field in both AT and ELEGANT(by setting fint=0), then the results from AT and ELEGANT fit very well. I realized that it might be the different methods for dealing the edge field that caused the problem. Then I read from the ELEGANT manual that the parameters "edge1_effects" and "edge2_effects" in the CSBEND element can be set to 1 or 2 or other numbers to change the methods. Problems come when I try to set these two parameters :

1. If I set both these parameters to 1 or 2 or other positive integers, there is no difference in the results.
2. If I set both these parameters to 0, it should have turned off the edge effects with the same effect by setting the "fint=0" in my understanding, but it gave a wrong answer with no chromaticity calculated at all. The edge_order is set to 2 in the calculation.

Could you help me look into the problem? The lattice file and the running file are attached. Thanks very much!

Siwei

[michael_borland]

Siwei,

Sorry that this is so confusing. To get the best modeling, you should set

Code: Select all

EDGE1_EFFECTS=2, EDGE2_EFFECTS=2, EDGE_ORDER=2

on the CSBEND elements. Also, ensure that you are using a sufficiently large N_KICKS parameter on the CSBEND, KQUAD, and KSEXT elements to get good modeling.

The attached example shows more details. For your lattice, I see good agreement between the tunes and chromaticities for tracking vs twiss computations, so I think elegant's results are reliable.

--Michael

[Siwei_Wang]

Hello Michael

Thanks for the reply. I tried the scripts and found that when setting the "edge1_effects=2" and "edge2_effects=2" in the CSBEND element, the calculated tunes and chromaticities agree well with the tracking datas, while when I set the "edge1_effects=1" and "edge2_effects=1" in the CSBEND element, it got the same tunes and chromaticities in Twiss calculation but different tracking datas. This explains well why I should use "edge1_effects=2" and "edge2_effects=2". The chromaticity has a little difference with AT and MAD-X of about 0.1, and this difference might comes from the different calculation methods for the edge field of these softwares. Could I ignore this small difference in the chromaticity calculation?
Sorry I still have another question that when I set the "edge1_effects=0" and "edge2_effects=0" in the CSBEND element, there comes a failure in the Twiss parameter calculation, as the attached picture shows. Why doesn't the 0 act as the way to turn off the edge effect, as the manual says.
The lattice with the "edge1_effects=0" and "edge2_effects=0" and the program are attached. Could you help me see this problem? Thank you very much.

Siwei

[michael_borland]

Siwei,

I think the difference between AT and elegant at this point is pretty small. In particular, if you put in a 3D field map and did tracking with that, you'd probably get an answer that was not the same as either of those results, but close to both. (It's worth trying that. You can use the BRAT element in elegant to do that.)

As for the undefined lattice functions when you set EDGE1_EFFECTS=0 and EDGE2_EFFECTS=0: Your lattice has a rectangular dipole with a bending radius of about 2.2 m. This gives significant vertical focusing at the two ends with a focal length (rho/tan(theta/2)) of 5.2 m. When you set EDGE1_EFFECTS=0 and EDGE2_EFFECTS=0, the magnet is converted to a sector dipole, which has all that focusing in the horizontal plane instead. The result is that both planes are unstable because the quadrupoles are designed to deal with the vertical end focusing and not horizontal sector focusing.

--Michael

[Siwei_Wang]

Hello Michael

Now I get the point and will be careful with the dipole edge field options. Thank you very much for the reply. It helps me a lot.

Siwei

[Björklund]

Hi,

So, I have run into a related problem, I think. I didn't see any change in my beta functions when I increased the three edge parameters to 2 from the default 1. I have the same fint = 0.4 as in both OPA and MAD-X and there I see a clear change between fint = 0 and fint = 0.4 for the vertical beta function. In elegant, I get the same beta functions as for fint = 0 in OPA and MAD-X regardless of what I try. This goes for both elegant and pelegant (v 34) and I'm using CSRCSBENDs.

Any ideas how to solve this?

Best regards
Jonas

[michael_borland]

Jonas,

Have you also set the HGAP parameter? It is zero by default in elegant.

--Michael

[Björklund]

Hi,

Yes, it is set, but I saw just now that it has been set to a value that's too small... What a stupid mistake. Good catch, thanks!

All the best
//Jonas

[Björklund]

Hi!

So, another addition to this thread.

It seems that I had accidentally removed the EDGE1_ORDER = 2 option (and also for edge 2) from my dipoles, so that it just used the default value 1. I used the T- and U-terms (mainly T166 and U1666) to calculate higher order dispersion (aka horizontal offset as a function of energy spread only), and tracking and matrix element calculations corresponded well w.r.t the remaining offset in the bending plane. So far so good.

Then I realized that I had removed this edge option, so I added it back. I (naïvely?) thought that the difference wouldn't be so big, and then I had to start optimizing the compressors, so I went ahead and did that using the matrix terms again, assuming that the correspondence would still be good. However, when I now track my lattice, there is a HUGE linear (+ other terms?) transverse offset w.r.t. the axis, about 15-25 times larger than the matrix terms suggest and what tracking with the old setting produce.

Thus, it would seem like the symplectic stuff for the edge effects is not implemented in the matrix representation, not even to first order. The R16 term is O(1e-7) in my lattice matrix output, but I still have a dominant linear effect with energy spread when the options are set to 2, as suggested above in the thread, for maximum realism. I should also say that I am not using the CSBEND element directly, but the CSRCSBEND one.

Is this a bug, or can I combat this effect in some other way?

Best regards
Jonas