ExactCFBend model incompatible with Xsuite/MAD-X

[nikitakuklev]

As part of apollo benchmarks we try to find exact-ish model matches as safe converter paths. When doing so for ExactCFBend and xsuite Bend, assumption was that in the limit of large number of steps, any splitting scheme would converge.

However, this was only true for k1=0 case (pure dipole). For k1 != 0, there is a systematic difference. After some agent-assisted poking, this seems to be because the elements are modelling truly different fields.

• xsuite uses MAD-X definition of field and kick (B_y = k1·x exactly on midplane, with geometric feed-down). Specifically, Δpx += -k1·x + h·k1·(-x² + 0.5·y²)

• impactx follows Tim's paper, per @cemitch99 original PR, and does toroidal harmonics with terms like Δpx += -(1+hx)·log(1+hx)·(k1/h) = -k1·x - 0.5·h·k1·x² + ...

The difference between the two is sextupolar order and higher, cannot be compensated exactly by adjusting higher order terms.

I am not making an argument as to which is more 'correct'. But being realistic, MADX/Xsuite is the de facto standard for many many existing machines and it is mandatory to have elements that match their as-designed physics at least as an option, especially for an element as popular as a combined function bend.

---

Given I'm working on Genesis stuff, seems appropriate to include some LLM opinions after making agents argue about it. Don't have magnet design experience, so trustworthiness unknown.

Toroidal (ImpactX) = what you get if you bend a straight quadrupole into an arc — the natural field of curved hyperbolic poles. The gradient weakens on the outside because flux lines spread.

MAD-X (xsuite) = what you get after engineers deliberately shim the poles to force a perfectly linear gradient across the aperture. The outside gap is squeezed tighter to compensate for the natural spreading.

Real magnets are built to match MAD-X — designers specify k1 assuming polynomial fields, then engineers shim the iron in 3D FEA to cancel the curvature effects. So when you track with xsuite/MAD-X convention, you're modeling the actual shimmed hardware. ImpactX models the "unshimmed" natural curved pole.

[cemitch99]

Thanks @nikitakuklev . There are two separate issues here. First you state: "assumption was that in the limit of large number of steps, any splitting scheme would converge." Do you fail to see convergence in ImpactX with respect to the number of steps used in the splitting? If so, can you send us a minimal working example?

Second, there is the question of the physical model to which the algorithm should converge. It is true that ImpactX uses the model in Tim Zolkin's paper. The use case here is for modeling the FNAL Booster, per direct request from @egstern , as this is our highest priority as part of SciDAC-HEP. This is a larger discussion in which he should be involved.

I'm puzzled by the statement "I am not making an argument as to which is more 'correct'. But being realistic, MADX/Xsuite...", and I'm not sure what to make of the LLM's opinions. However, I agree that having the option of a direct analog to the MAD-X/XSuite element is valuable. We could add a helper function that enables conversion between the multipole series coefficients, to be discussed. Thanks for the suggestion.

[nikitakuklev]

Regarding question 1, no, up to accumulating numerical precision errors the splitting converges within Impactx. My point was had Impactx used any of the various splitting options on same field (see https://xsuite.readthedocs.io/en/latest/physicsguide.html page 18), they should converge, but didn't.

For second comment, I was trying to convey that for a code to be most useful it has to reflect as-built reality. LLM snippet made a point, with which I agree, that if the magnets were historically designed and built for MAD convention, then that is what should be modelled by default even if Tim's description seems more elegant.

Interested to hear @egstern opinion too. The models I have from our Booster experts is MAD-X (and know of PyOrbit one, which appears to do teapot slicing+MAD convention). Given how old Booster is and how complex the laminations, it would be surprising if either CF model is more appropriate or at all accurate.

[egstern]

My comment on your statement that Booster expects MAD-X behavior, is that the Booster lattice was modeled with MAD-8 until about 2008 and who knows how it was modeled when it was designed and built in 1969-70. The Booster magnets are actually rectangular. In that geometry, we could model the fields with normal cartesian multipole representations but modeling the trajectory through a combined function magnet of that sort and being able to split it for space charge is hard so we make the useful approximation that it is a parallel-faced sector bend.

I was not aware that combined function magnets are shimmed to achieve linear focusing. I haven't actually seen any design reports but I would be shocked if that happened for the Booster magnets, given how poorly they are understood today. Maybe newly constructed magnets are made as you suggest.

In conversations with Frank Schmidt, I understand that the MAD-X combined function model follows the famous SLAC-75 report by Karl Brown which expands and solves the nonlinearities in the propagation equations to second order in a Frenet-Serret coordinate system following the trajectory. A problem is that a linear focusing field in a curved coordinate system does not satisfy Maxwell's equations which is corrected by the +... that you allude to.

My feeling is that all these approaches are approximations to the whatever the real magnets are like. In the Booster, I don't think there is instrumentation, or data or stability of measurements that can distinguish between them.

[cemitch99]

On a related note, we will need to support--or implement a translation for--the model of curved multipoles as specified in the PALS standard here.

[cemitch99]

@nikitakuklev Is this a feature that you need now, in the short term, or did you flag this to us in order to improve the code?

[nikitakuklev]

@cemitch99 not a high priority, just something that would be useful for 1:1 lattice compatibility. It would help for cross-code benchmarking too.