Response matrices

[lfarv]

This PR adds the computation of response matrices. Please check the documentation here.

[swhite2401]

@lfarv, thanks for this very nice addtion. A predefined OpticsResponseMatrix would be very useful as well.

[swhite2401]

I think @ZeusMarti was also interested in RDT response matrix

[ZeusMarti]

Yes! Thanks @swhite2401 !

Also, now that you are developing this, I was wondering if the response matrix formula for thick elements (should be not much slower than the optics calculation but very close to the numerical much slower calculation) and the derivative w.r.t. quadrupole strengths could also be added. I'm not sure AT is the place but what do you think?

[swhite2401]

The analytical responses would certainly be a very nice addition to AT! I have discussed this with @simoneliuzzo who has already everything implemented in python, someone just has to find time to clean it up and make it work within AT

[simoneliuzzo]

Dear @lfarv, @swhite2401, @ZeusMarti,

the analytic orm and derivatives following the formulas by Zeus and Andrea are here:

orm analytic orm:
https://gitlab.esrf.fr/BeamDynamics/commissioningsimulations/-/blob/main/commissioningsimulations/correction/ClosedOrbit.py?ref_type=heads

disp derivative vs dipole:
https://gitlab.esrf.fr/BeamDynamics/commissioningsimulations/-/blob/main/commissioningsimulations/correction/optics_coupling/analytic_dispersion_with_dipole_errors.py?ref_type=heads

disp derivative vs quad:
https://gitlab.esrf.fr/BeamDynamics/commissioningsimulations/-/blob/main/commissioningsimulations/correction/optics_coupling/analytic_dispersion_with_quadrupole_errors.py?ref_type=heads

orm derivative vs normal quad:
https://gitlab.esrf.fr/BeamDynamics/commissioningsimulations/-/blob/main/commissioningsimulations/correction/optics_coupling/analytic_orm_with_normal_quad_errors.py?ref_type=heads

orm derivative vs skew quad:
https://gitlab.esrf.fr/BeamDynamics/commissioningsimulations/-/blob/main/commissioningsimulations/correction/optics_coupling/analytic_orm_with_skew_quad_errors.py?ref_type=heads

tune vs quad:
https://gitlab.esrf.fr/BeamDynamics/commissioningsimulations/-/blob/main/commissioningsimulations/correction/optics_coupling/analytic_tune_with_quadrupole_errors.py?ref_type=heads

[lfarv]

@swhite2401, @ZeusMarti, @simoneliuzzo: thanks for your remarks: a lot of interesting new developments!
Trying to sort out all this:

• RDT response matrix

  That looks nice. For this, one needs an RDTObservable, easy to implement. This can be the topic of another pull request,

• A predefined OpticsResponseMatrix would be very useful as well.

  Can you be more precise? For me, this may cover a large range of variables and observables… Again, that could be developed in other PRs, but the point here is to check that the generic ResponseMatrix interface is ready and convenient for implementing those various subclasses.

• ORM derivatives: this is a different topic. The generic tool here computes the "direct" response of a set of observables to a set of variables. For ORM derivatives, one should consider the ORM itself as an observable. This may not be the simplest way to handle the problem…

• Analytical ORM: the OrbitResponseMatrix has presently 2 methods for filling it: build to fill it with tracking, load to fill it from a file (measured data, previously computed data…). One could add a 3rd analytical method to compute it analytically. If there are better method names, it's the right time to choose!

• Analytical ORM derivatives: very interesting indeed, to be scheduled in another PR.

To progress step by step, I'd like to check here that the proposed generic interface is convenient.

[lfarv]

The ORM analytical computation is added as a new build_analytical method (only for OrbitResponseMatrix).

[lfarv]

Corrected a bug reported in #903.

[swhite2401]

• Can you be more precise? For me, this may cover a large range of variables and observables… Again, that could be developed in other PRs, but the point here is to check that the generic ResponseMatrix interface is ready and convenient for implementing those various subclasses.

Something that would be very interesting is to point to linopt outputs, in particular, phases, betas and dispersion that are generally used in linear optics correction algorithms.

[swhite2401]

• Analytical ORM: the OrbitResponseMatrix has presently 2 methods for filling it: build to fill it with tracking, load to fill it from a file (measured data, previously computed data…). One could add a 3rd analytical method to compute it analytically. If there are better method names, it's the right time to choose!

I would rather use: tracking, analytical and load

[lfarv]

The methods for filling a response matrix are renamed as;

• build_tracking
• build_analytical
• load

For optics responses: since all the outputs of get_optics are available as observables, it's very easy to implement them using the base ResponseMatrix class. But of course convenience subclasses may be added, if a simple syntax can be defined!

[swhite2401]

For optics responses: since all the outputs of get_optics are available as observables, it's very easy to implement them using the base ResponseMatrix class. But of course convenience subclasses may be added, if a simple syntax can be defined!

Subclasses would be very helpful for users

[lfarv]

1. The analytical trajectory response is implemented,
2. Ways to exclude variables and observables from the matrix inversion are implemented. They keep the dimensions of the matrix, pseudo-inverse, error and correction vectors unchanged so that it's transparent for the use,
3. the documentation and examples are improved.

For me, this version is ready for merging. Its the basis for the next steps. These could be:

• implement RDT observables so that RDTs can be used in response matrices
• Add specialised response matrices (to be discussed)

Please try and comment…