Orbit correction: RF response for orbit correction and handling of weights

[kparasch]

Please remember to re-install pySC (accelerator-commissioning in pip)!

This PR comes with a new release of pySC (v1.1.0) which:

1. Allows using the rf_response to correct the orbit through the rf frequency
2. Fixes a bug when using the virtual bpm to constraint the sum of horizontal corrector strengths to 0
   (pySC orbit_correction function allows also setting it to non-zero for use with programmed orbit bumps)
3. Allows setting rf_weight (default value is inferred from the ORM with jean-luc's recommendation
4. Allows setting the weight of the virtual bpm mentioned above
5. Allows setting the weight of any BPM / corrector.

New methods:

1. element_holder.orbit.set_virtual_weight(1000)
2. element_holder.orbit.set_rf_weight(1e7)
3. element_holder.orbit.set_weight(my_bpm_name, w, plane="H")
4. element_holder.orbit.set_weight(my_corr_name, w)
5. element_holder.orbit.get_virtual_weight()
6. element_holder.orbit.get_rf_weight()
7. element_holder.orbit.get_weight(my_bpm_name, w, plane="H")
8. element_holder.orbit.get_weight(my_corr_name, w)

For BPMs, the name of the "horizontal signal" is the same as the one of the "vertical signal", in case of ambiguity, the get_weight function will throw an exception pointing to the conflicts.

Added several examples to illustrate use.

Also renamed outputs_plane to output_planes and inputs_plane to input_planes to be a bit more consistent.

[JeanLucPons]

Thanks Kostas !
May be I'm wrong, but i do not see arbitrary steerer sum to target.
May be later ?

[gubaidulinvadim]

@kparasch @JeanLucPons Perhaps we should release a new version once this is merged. This merge request also depends on the new pySC version 0.1.1

[kparasch]

Thanks Kostas ! May be I'm wrong, but i do not see arbitrary steerer sum to target. May be later ?

@JeanLucPons
It can be set in the orbit_correction function of pySC.
I am roughly aware how to use it for the orbit bumps but not 100% clear yet to me, that's why I didn't try to do more about it in pyaml.

Will we also want a target for the vertical bumps or do we just not put the virtual bpm there?

see virtual target here:

           trims_h = orbit_correction(
                interface=interface,
                response_matrix=self.response_matrix,
                method="svd_values",
                parameter=svH,
                virtual=True,
                apply=False,
                plane="H",
                reference=reference,
                rf=rf,
                # virtual_target=1e-6
            )

[JeanLucPons]

Steerer sum to target (using the virutla BPM) is for H parallel bump.
Doing an horizontal parallel bump is a bit like being off energy.
In vertical, we do not need this as there is no "free" degree of freedom (If vertical steerer sum is not 0, then the beam will move).
In horizontal the energy change, could be compensated by a non null steerer sum. This is what we want to avoid using this virtual BPM. However, we have also to handle parallel bump as bellow. Here a parallel bump is done in the injection zone.

[kparasch]

@JeanLucPons I have added an option to at least set the virtual target for now, that is by default equal to zero. Then we could revisit it when we start implementing orbit bumps.

There is an ambiguity on the 'sign' which I am not sure how to put. If you request virtual target of 1e-8, your steerer sum will have changed by -1e-8.

To constraint the steerer sum to always be equal to 1e-8,
you would have to do:

    virtual_target = 1e-8

    steerer_sum = np.sum(hcorr.strengths.get())
    element_holder.orbit.correct(virtual_target=steerer_sum-virtual_target)
    print(np.sum(hcorr.strengths.get()))

    steerer_sum = np.sum(hcorr.strengths.get())
    element_holder.orbit.correct(virtual_target=steerer_sum-virtual_target)
    print(np.sum(hcorr.strengths.get()))

output:

9.999979321348352e-09
9.999979880921822e-09

Including when we will be designing bumps, do you think it is more convenient like this or is it better to calculate the steerer sum inside orbit.correct?

[JeanLucPons]

I think that we should let the user being able to implement his algorithm, depending on machine, it can be different.
So how it is now it seems OK for me.

[JeanLucPons]

I cannot re-review this PR ? Why ?

[JeanLucPons]

That's OK now ?!