opal: incorrect multipole units in element descriptions

[cchall]

For multipole elements in the OPAL interface (e.g.: quadrupole, sextupole, octupole, and multipole) the units listed in Sirepo are specified as normalized ([K1] = 1 / m^-2), however, OPAL uses absolute gradient values for these quantities (see: http://amas.web.psi.ch/opal/Documentation/2.2/OPAL_Manual.html#sec.elements.quadrupole)

[moellep]

This seems really odd - the same quad K1 value in elegant which claims to be m^-2 produces the exact same twiss report, so either OPAL K1 is m^-2 or the OPAL twiss calculation is treating it as that (or there is something I don't understand).

Here are equivalent lattices which have the same twiss report: https://www.sirepo.com/elegant#/lattice/45fQi4vy https://www.sirepo.com/opal#/lattice/4M6FzpV4

The online help text for OPAL shows K1 is m^-2:

==>help, quadrupole;
...
OPAL>   real            K1                        Normalised upright quadrupole coefficient in m^(-2)
OPAL>   real            DK1                       Normalised upright quadrupole coefficient error in m^(-2)
OPAL>   real            K1S                       Normalised skew quadrupole coefficient in m^(-2)
OPAL>   real            DK1S                      Normalised skew quadrupole coefficient error in m^(-2)

[cchall]

That is very interesting. I think it could be possible that OPAL gives the same result for the Twiss calculation as elegant, with no conversion of K1, depending on how the Twiss values are calculated. I wrote an elegant to OPAL lattice converter and I definitely re-scaled the K1 values based on Brho to get the answers to match up. But I only compared particle tracking results, not beam-independent Twiss calculations.

I imported my test setup into Sirepo: https://www.sirepo.com/elegant#/lattice/135XtasE https://www.sirepo.com/opal#/lattice/8tY4rm39 (elegant K1 [1/m^-2] saved as elegant_k1 and converted K1 [T/m] saved as opal_k1)

The elegant result I wanted to see in OPAL was:

Using the K1 values [1/m^-2] from elegant directly in OPAL causes divergence from the elegant result

Using the converted K1 values [T/m] in OPAL yields an excellent match

Which would suggest that, for particle tracking at least, the online OPAL manual units of T/m are correct.

[moellep]

Thanks Chris - the examples are very helpful.

We can change sirepo so it generates the lattice twiss simulation assuming K1 is m^-2 and the particle tracking simulation converting to T/m.

Chris, for the sirepo user interface, would you like to see the values as m^-2 or T/m? We can generate the lattices either way.

[cchall]

For the user interface I think T/m is probably the way to go. It is in line with the OPAL manual (including their own guidelines for converting from a normalized code like MAD-X: http://amas.web.psi.ch/opal/Documentation/2.2/OPAL_Manual.html#appendix.opal-madx-conversion-guide). So this is probably what users expect when entering values in OPAL.

It probably should be noted that while the conversion factor is just Brho, the Brho of a beamline is not always constant. So converting between the two representations in cases where there is energy gain from RF cavities, or losses from radiation, will require a calculation or simulation of the expected energy at each magnet.

[moellep]

I've verified that OPAL used to have the quad K1 values as m^-2 (version 1.1.9) but changed it to T/m later in 2.0. It looks like the TWISS command was not updated, so it still treats K1 values as m^-2. The documentation for the TWISS command doesn't exist in the 2.0 docs. As part of this fix, I'm going to remove all the twiss features from sirepo/opal and we'll just use the particle tracking features.