Orbit and optics corrections

[swhite2401]

This is a continuations of #538 and is again a proposal as a basis for discussion.

It implements the possibility to compute arbitrary response matrices, the design is strongly inspired from the matching module with some changes to make object "pickable" and allow parallelization.

With this it is then possible to correct the lattice based on any outpout of find_orbit, linopt or lattice_pass and restore trajectory, orbit or optics of a lattice with errors.

A possible nice addition would be the analytical ORM from @simoneliuzzo.

The ORM derivative w.r.t. to quads to implement the LOCO type of correction is not implemented but we may easily add an additional layer at a later stage.

Again I leave this as draft for discussion, once we agree on the code design we may proceed with discussion on the details of the implementation.

[swhite2401]

Here is a code for example usage:

quads = ring0.get_refpts(at.Quadrupole])                                                                                               
bpms = ring0.get_refpts(at.Monitor)

rm = LinoptResponseMatrix(ring0, bpms, quads, ['beta', 'mu', 'dispersion'], [[0, 1], [0, 1], 0], fit_tune=True, obsw=[1.0, 1.0, 1000.0])
rm.compute_fullrm(ring0, use_mp=True)
target, _ = rm.get_vals(ring0)
dk, exp = rm.correct(ring_err, target, apply_correction=True)

!!!Warning!!! for this to work ring and ring_err MUST have the same element sequence because variables and observables are based on their refpts

[swhite2401]

At some point I considered to add attributes to hold the correction in a similar fashion as errors are handled in #546. This could be very convenient because the same lattice would allow to compute quantities for the ideal, ideal+err, ideal+err+corr cases.

To be discussed...

[simoneliuzzo]

the functions for the computation of analytic derivatives are available for ESRF staff here: https://gitlab.esrf.fr/BeamDynamics/commissioningsimulations/-/tree/main/commissioningsimulations/correction/optics_coupling/analytic*

also a thick-steerers version of the ORM analytic formulas is available here: https://gitlab.esrf.fr/BeamDynamics/commissioningsimulations/-/blob/main/commissioningsimulations/correction/ClosedOrbit.py

[lfarv]

Hi @swhite2401. I just started looking at this branch. It's promising, and here are my 1st comments:

The Variables and Observables objects are very similar to the ones used for matching

• For Variables, it looks very easy to go to a single object to be used in both cases. We should go to that
• An Observable object here is also similar to the Constraint object (that mainly differ by the presence of a "target" attribute for constraints). May be that also deserves some unification. However you try here another implementation: you define an "Observable" object (which should be specialised to avoid the ugly "if /elseif/elsif/else" sequences), and use a generic container to store them. On the other hand in matching, there is no real Constraint object, but you have specialised containers for optics, orbit,.. constraints. This makes the evaluation cleaner so I made an attempt to go to that way an defined several containers: OrbitObservables, OpticsObservables, TrajectoryObservables, RingObservables (steerer strengths for instance). I'm not fully satisfied with the results, so I'd like to try the other way (as initiated in this branch). Give me some more time.

Otherwise, I like the idea of RingObservable: it's similar to an OpticsObservable: refpts, attribute name and optional index, but refers to ring elements and returns an array

For sommation, I added to all observables a 'statfun' post-processing function attribute (None by default). By assigning any numpy function like np.sum, np.min, np. max, np.mean…, the observable returns its result instead of the array. Could also be useful for constraints!

For orbit response matrices, you should use the KickAngle attribute rather than thePolynomA/B[0]:

• it works for all magnets: Corrector class, all LongMultipole subclasses including dipoles, and thin elements,
• its name is self-explanatory,
• it has the right sign, while PolynomB[0] > 0 gives a negative angle

[swhite2401]

Thanks to both for your feedback, in fact I did start by using the matching module objects but then had to rewrite large parts of it so i ended up with this. The idea was to not modify existing pyAT parts until this had been found useful. If we decide to proceed we should indeed try to unifiy these 2 as much as possible.

I can do it for variables as this looks really simple. For constraints/observables it is a bit more complicated as different design choices where adopted. I can start by differentiation the various observable and remove the if/else blocks in this branch. We may see from there whether to port it to the matching or not.

Using KickAngle is not an issue, it is true that it makes the comparison with measurements easier, I can change this.

So @lfarv, it is not clear to me whether you started working on this branch? Is it the case, who has the hand on this one?

[lfarv]

If we decide to proceed we should indeed try to unifiy these 2 as much as possible.

Yes, so my advice would be to setup here new variables and observables suitable for matching. Without modifying anything im matching at this time. And update matching in a second step.

@swhite2401 : I don't change anything in this branch, I'm testing different architectures for observables, as I said, in another branch. My idea is to propose you soon a simple and flexible structure for observables. Can hold on on that for 1 or 2 days? Go on for variables!

[swhite2401]

Can hold on on that for 1 or 2 days? Go on for variables!

Sure, I am quite busy with other stuff right now, so very little chance of pushing anything in the coming 2 weeks!

[swhite2401]

I close this PR, observables and variables and corrections will be treated separately.