Computing beam parameters for a transfer line instead of a ring

[tfs563]

Hi,

I'm trying to use AT to calculate linear properties such as Twiss parameters, tunes, chromaticities, etc. of a lattice for a transfer line rather than a storage ring. I know the function get_optics does this for a ring, and I've been told that I can use pyAT to do the same for a transfer line (essentially just a fodo cell) as well, but I cannot seem to figure out what function(s) I would use to do this? I tried looking through the sub-packages found here: https://atcollab.github.io/at/p/index.html but I don't see an answer (unless I missed it).

Any help would be appreciated.

[lfarv]

Hello @tfs563
For transfer lines, you can use the same functions as for ring (get_optics, linopt2, linopt4, linop6…) but you need to specify the initial conditions with the keyword argument twiss_in.
twiss_in is a "mapping" (a directory, for instance, or a record array as output by get_optics) with the following keys:

• R: (beam matrix as output by get_optics)
  or alpha and beta: (2,) arrays
• closed_orbit: (6,) array giving the initial orbit coordinates (optional, defaults to (0, 0, 0, 0, 0, 0)),
• dispersion: (4,) array giving the initial dispersion (optional, defaults to (0, 0, 0, 0)).

The details are here.

[tfs563]

Many thanks @lfarv

I do have a follow up question since I'm having a bit of trouble with the first key of twiss_in. I'm not entirely sure if the R or alpha, beta keys are something I need to personally input from information I should know about the transfer line or if those parameters can also be generated by AT with another function? I am aware that the descriptor for the twiss_in key gives the following statement "Record array as output by linopt6(), or dictionary" but I'm just not sure if I'm supposed to use AT to generate those inputs for me to use, and which function will do that for me.

[lfarv]

@tfs563 :
In a transfer line, you have to give alpha and beta at the entrance of the line. They will then be propagated along the line. They are defined by what is upstream the transfer line (extraction from a ring, for instance). It can be anything.

The simplest input is to use the alpha and beta keywords: they define a beam without any H/V coupling. The alternative way is the more general R keyword which can describe a fully coupled beam, but usually, you get the R matrix from the output of get_optics on the upstream ring or transfer line: building a R matrix by hand is tricky…

[tfs563]

@lfarv:

Sorry, but I'm just not quite understanding how to define alpha and beta in the transfer line code I have. I don't know what's upstream of the transfer line, because I'm just trying to model an energy filter magnet and get a general idea of the twiss functions. So far I have the following:

Dr1 = at.Drift('Dr', 0.079)
Dr2 = at.Drift('Dr', 0.016)
Dr3 = at.Drift('Dr', 0.024)
Dr4 = at.Drift('Dr', 0.095)
Dr5 = at.Drift('Dr', 0.095)
Dr6 = at.Drift('Dr', 0.032)
Dr7 = at.Drift('Dr', 0.016)
Dr8 = at.Drift('Dr', 0.063)
QF1 = at.Quadrupole('QF', 0.055, 1.0)
QF2 = at.Quadrupole('QF',0.079, 1.0)
QF3 = at.Quadrupole('QF', 0.055, 1.0)
QD1 = at.Quadrupole('QD',0.055, -1.0)
QD2 = at.Quadrupole('QD',0.055, -1.0)
Bend1 = at.Dipole('Bend', 0.24, 2pi/6)
Bend2 = at.Dipole('Bend', 0.24, 2pi/6)

Energy_Filter = at.Lattice([Dr1, QF1, Dr2, QD1, Dr3, Bend1, Dr4, QF2, Dr5, Bend2, Dr6, QD2, Dr7, QF3, Dr8],
name='Energy Filter Lattice', energy=1e9)

and now I'm trying to do

[elemdata0, beamdata, elemdata] = at.get_optics(Energy_Filter, range(len(Energy_Filter)+1), twiss_in = beta)

A colleague used MADX to model the same lattice and got these results, which I'm trying to replicate or get close to

[lfarv]

The Twiss functions along the line depend on the initial value at the entrance of the line! Apparently , the 2 plots correspond to two different sets of initial beta values: betax=10, beta-10 on the1st plot, betax~= 1.6, beta~=2.1 on the 2nd plot.
But in the 2nd plot, the final values are equal to the initial ones, which suggests that your FODO cells has been treated as a ring.
Look at the MADX input to reproduce it in AT. Side remark: in the plots, it looks like the order of the quadruples is opposite to yours:
QD, QF, dipole,QD,dipole, QF,QD.

So:

• if you don't put the twiss_in keyword, the line is considered as a closed ring, and the initial values are computed so that the ring closes: final values == initial values. This looks like the 2nd plot.
• if you put the twiss_in keyword, you can set any initial values for alpha and beta, and they will just be propagated along what is considered as a transfer line. This looks like the 1st plot. In that case, the syntax should then be:

  twiss_in = dict(beta=(betax, betay), alpha=(alphax,alphay))
  [elemdata0, beamdata, elemdata] = at.get_optics(Energy_Filter, range(len(Energy_Filter)+1), twiss_in = twiss_in)

[tfs563]

Okay, that helped tremendously! I'm now getting results when I add in the twiss_in key with a defined alpha and beta, however, when I don't include it I get an unstable ring error. Would this possibly be something to do with my lattice components then? I ran into this error before, which prompted me to ask my initial question, because using get_optics without a twiss_in key considered my lattice as a closed ring but running it would produce an unstable ring output error.

I also checked with my colleague about the order of the quadrupoles and the lattice they used was: lattice = [Dr1, QF1, Dr2, QD1, Dr3, Bend1, Dr4, QF2, Dr5, Bend2, Dr6, QD2, Dr7, QF3, Dr8], and that's the same as mine.

[lfarv]

With the data you posted above, your lattice is indeed unstable. But I insist: on the plots you show above, when crossing the 1st quadrupole, β_x increase, that's a proof that the quadrupole is defocusing. And it's the opposite when crossing the 2nd quadrupole.

Also, MADX identifies the defocusing quads with a bow below the axis (on top). So there is some confusion in your data.

As a test, I just inverted the sign of all quadrupoles:

Dr1 = at.Drift('Dr', 0.079)
Dr2 = at.Drift('Dr', 0.016)
Dr3 = at.Drift('Dr', 0.024)
Dr4 = at.Drift('Dr', 0.095)
Dr5 = at.Drift('Dr', 0.095)
Dr6 = at.Drift('Dr', 0.032)
Dr7 = at.Drift('Dr', 0.016)
Dr8 = at.Drift('Dr', 0.063)
QF1 = at.Quadrupole('QF', 0.055, -1.0)
QF2 = at.Quadrupole('QF',0.079, -1.0)
QF3 = at.Quadrupole('QF', 0.055, -1.0)
QD1 = at.Quadrupole('QD',0.055, +1.0)
QD2 = at.Quadrupole('QD',0.055, +1.0)
Bend1 = at.Dipole('Bend', 0.24, 2*pi/6)
Bend2 = at.Dipole('Bend', 0.24, 2*pi/6)

Energy_Filter = at.Lattice([Dr1, QF1, Dr2, QD1, Dr3, Bend1, Dr4, QF2, Dr5, Bend2, Dr6, QD2, Dr7, QF3, Dr8],
name='Energy Filter Lattice', energy=1e9)

and plotted the twiss parameters:

Energy_Filter.plot_beta()

That's still different from your plot, so cross-check all the quadrupole strengths!

[lfarv]

Running in transfer line mode:

twiss_in = dict(alpha=(0.0, 0.0), beta=(10.0, 10.0))
Energy_Filter.plot_beta(twiss_in=twiss_in)

I get:

which is similar your 1st plot

For an energy filter, I would revert to your initial polarities to get a dispersion bump, but you need to tune the quad strengths

[tfs563]

I get a very similar plot when reversing the initial polarities.

When I plot

twiss_in = dict(beta=(5, 5), alpha=(0, 0))
Energy_Filter.plot_beta(twiss_in=twiss_in)

I get a similar plot:

Still no dispersion bump though