how to model overlapping corrector magnets and focusing elements

[GPenn]

I would like to model orbit correction elements which are overlapping more standard magnets. They don't have to be dynamically controlled. Is EKICKER the best way to combine a dipole kick with focusing fields if I do not want the kick to impact the coordinate system? It looks like I can't use separate MULTIPOLE files for quads and sextupoles because they don't include dipole components. I assume the multipole files work the same way for EKICKER as for other non-bending elements. Is there a limit to how high the order of the multipoles can be?

In a few cases, the correcting kicks overlap a weak dipole. I am happy to use CSBEND - with TILT set to 0 the coordinate system is set, and ETILT and FSE_DIPOLE allow control over the actual magnitude and direction of the field. But sometimes I will have to use a large value for ETILT, will the tracking still be accurate in that case?

Thanks,
Gregg

[GPenn]

I should add that I am doing this to match lattices constructed in Accelerator Toolbox. The fields of a given element can become quite complicated in AT depending on how errors and correctors are implemented. I'm working on a script to generate a nearly equivalent elegant lattice file.

[michael_borland]

Gregg,

The best way to combine quadrupoles with steering is to use the HKICK and VKICK parameters on the KQUAD element. There's no limit to how high the multipole components can be.

Using ETILT by itself shouldn't result in accuracy issues. The effects on the trajectory are computed with some analytical expressions that (I think) are exact. However, if combined with other errors it is probably not exact. It should be fine for physical errors. I'd suggest putting zero-length EHKICK and EVKICK elements at the ends of the device instead, since that seems more clear.

--Michael

[GPenn]

Thank you for the explanation Michael. That helped a lot, and I am pretty happy with the comparisons between AT and elegant using 'straight' magnets.

I am having issues with comparisons in bends involving ETILT, even involving a simple ideal bend magnet, which I think comes from how I am trying to translate that configuration into AT. I would like to understand better how elegant handles a dipole field that is rotated w.r.t. the coordinate system. If it's really modeling a uniform magnetic field that is not properly aligned, then there is inevitably going to be a solenoid component to the field, probably anti-symmetric about the center of the magnet. Is there a description of how that is modeled, especially for symplectic tracking? I don't suppose there is a simple approximation to deal with the extra kicks coming from the solenoid fields?

I also noticed that for an absolutely perfect dipole, when a particle has a vertical offset going in, the tracking in elegant gives a small horizontal kick. It does approach 0 as (N_KICKS)^(-4), like it should, but I was a little surprised given the symmetry that there was any numerical error at all of that form.

-Gregg

[michael_borland]

Gregg,

The effects of the ETILT parameter on the trajectory are computed very simply by assuming a pure dipole field that is rotated about the longitudinal axis at the entrance. The beam is then rotated into the tilted frame (which includes the TILT value) and propagated through the magnet (which now looks like a horizontal bend). At the end, we undo this rotation and add the coordinate offsets from the ETILT. It is almost certainly only good to first order.

I don't see a horizontal kick that depends on the vertical offset for a dipole with no edge effects. There are small, constant non-zero Cx and Cxp values, which originate in the imperfect nature of the integrator. You can suppress these using REFERENCE_CORRECTION=1, so long as you are sure you are using a large enough value of N_KICKS to get the right dynamics.

--Michael

[GPenn]

Thanks Mike,

I appreciate the REFERENCE_CORRECTION=1 suggestion. It makes a big improvement for moderate values of N_KICKS.

I am still confused about the sign convention for ETILT. A positive angle bend is making the coordinate system curve in the -x direction. If ETILT is acting in the same direction as TILT I would expect a small positive value for ETILT to result in a slightly weaker -x kick and a new -y kick. In reference to the coordinate system, that should give me a very small +x displacement and a -y displacement. What I see is the particle trajectory going in the +y direction.

It's not an ideal comparison, but if I look at an element
B1: CSBEND,L=1,ANGLE=0.02,K1=0,TILT=0,ETILT=0.01,SYNCH_RAD=0,N_KICKS=100
and compare it to
Q1: KQUAD,L=1,K1=1.e-5,TILT=0.01,HKICK=-0.02,SYNCH_RAD=0,N_KICKS=100
the vertical kicks have opposite signs. Moreover, if I take a positive momentum offset, both cases involve a positive change in py. Besides the sign issue, it doesn't make sense to me that in the CSBEND case a higher-momentum particle gets a larger magnitude vertical kick than an on-momentum particle (it winds up being proportional to 1+delta).

-Gregg

[michael_borland]

Gregg,

I agree that something doesn't make sense with ETILT in terms of the momentum-dependence of the effects. I'm looking into it.

--Michael

[michael_borland]

Gregg,

I think I found the problem. It appears to originate in inconsistent conventions for the meaning of the sign of ETILT in various parts of the code. I've modified the code and attach it here. If you build from source, please try it and let me know what you think.

You'll notice that the convention for TILT and ETILT signs is now the same, which is more intuitive.

Thanks for bringing this to my attention!

--Michael