Proposal for working with currents instead of strengths

[JeanLucPons]

At the ESRF we call a "pseudo current" , a current associated to a single multipole (Ih,Iv,..). It can be a linear combination of power supply currents (PS) as illustrated in Fig 1. For a simple magnet this "pseudo current" is then the current circulating in the coil (Fig 2).
So i propose to expose these pseudo currents as read/write for the control system in order to be able to work with currents.
We can keep current for the python attribute name.

sr.live.quad.strenght.set(0.7) # 1/m
sr.live.quad.current.set(75.2) # A

sr.live.sh_h.strength.set(2.3e-5)  # rad
sr.live.sh_h.current.set(0.12)     # A (pseudo current)
sr.live.sh_v.strength.set(7e-6)    # rad
sr.live.sh_v.current.set(0.07)     # A (pseudo current)

Problem: This will failed with our sextupole model that do not expose these pseudo currents. Very roughly speaking, this model integrates calibration curves in a tensor and look for a working point to drive as best as possible correctors while minimizing the variation on the main current. In that case, access to a pseudo current will fail with an error.

[JeanLucPons]

For high level application, we can also define a global mode that tells if we want to work with current or strength without breaking compatibly with existing specifications. The mode has no impact if you specify quad.strength.set() or quad.current.set(). The mode can be specified in the configuration file as well.

sr.live.mode.set('current')
sr.live.quad.set(value) # Sets a current
sr.live.mode.set('strength')
sr.live.quad.set(value) # Sets a strength

[JeanLucPons]

As example, 2 magnets we use for EBS, both of them are able to perform 4 functions: H,V,SQ,S. Both of them need 5 power supplies but have a totally different model for computing coil currents.

SH magnet:

Sextupole:

The arrow color indicates corrector channels, there are 4 corrector channels and 1 main current. Corrector power supplies are bipolar, so arrows can change their direction.

[TeresiaOlsson]

I'm not entirely sure that I understand your magnets at ESRF because that seems very complicated. But for running measurements using currents I would say this is what we would like to be able to do:

• In case you machine has very bad conversion factors (e.g. because the machine is 30 years old and some documentation has been lost or was never measured) it should be possible to run measurements on the live machine in hardware units. And especially if it's a measurement which you might run with the purpose to determine beam-based conversion factors.

• If you don't have a lattice model for your machine, e.g. if you have a linac and we haven't yet implemented abstraction for a simulation code that can handle linacs, you should still be able to use the code for interacting with the live machine. And ideally then without having to configure unit conversions which you can't use anyway.

So there needs to be some way for applications to be able to run both in hardware and physics units in a seamless way and for the developers of the high-level applications to be able to write them in some unit independent way.

[JeanLucPons]

Yes, our magnet are rather complex and I even skip the FOFB. In fact our SH corrector power supplies have 2 setpoints (1 for SOFB and 1 one for FOFB) with different ranges and different dynamics.

With my proposal, if you are able to isolate 1 current per function, yes you will be able to measure a tune response matrix (for instance) in current and use it for tune correction. If you have only quad without correctors I do not see blocking point. Now for ORM, I don't know how you handle multipole separation if you have correctors in sextupole and what model you are using. For old ESRF ring, we had sextupoles with various functions and we worked using currents (in fact pseudo currents).

[TeresiaOlsson]

In our case we just assume the sextupole and corrector to be independent. They already have independent power supplies in the control system with different PV names. I guess because the corrector is extra trim coils on the magnet but that I need to check.

If the idea of "pseudo currents" can work for you, I think that's a good option. I now also understand why you prefer to run everything in physics units. For us physics units are a bit "fake" because of the bad conversion factors whereas for you hardware units are a bit "fake" because you need to use the pseudo currents.

[JeanLucPons]

If they are independent, no problem, pseudo currents become true currents.
So in that case i suggest that you use the linear_cfm_unit conv with only calibration curves (you keep identity for the separation matrix) and the the .current.set() will directly map to the underlying power supply. For instance:

type: pyaml.magnet.cfm_magnet
name: A_SEXT        #Name of the element in the lattice model
mapping:
  - [B2, A_SEXT]
  - [B0, A_HCORR]
  - [A0, A_VCORR]
unitconv:
  type: pyaml.magnet.linear_cfm_unitconv
  multipoles: [B2,B0,A0]
  units: [m-2,rad,rad]
  curves:
    - type: pyaml.configuration.csvcurve
      file: sr/unitconv/sext_strength.csv
    - type: pyaml.configuration.csvcurve
      file: sr/unitconv/v_strength.csv
    - type: pyaml.configuration.csvcurve
      file: sr/unitconv/h_strength.csv
  powerconverters:
    - type: epics.pyaml.pv
      setpoint:  VA:A_SEXT:CURRENT_S
      readback:  VA:A_SEXT:CURRENT
      unit: A
    - type: epics.pyaml.pv
      setpoint:  VA:A_HCORR:CURRENT_S
      readback:  VA:A_HCORR:CURRENT
      unit: A
    - type: epics.pyaml.pv
      setpoint:  VA:A_VCORR:CURRENT_S
      readback:  VA:A_VCORR:CURRENT
      unit: A

ex:

sr.live.A_HCORR.current.set(value) # write value on VA:A_HCORR:CURRENT_S an bypass calibration curves

sr.live.mode.set('current')
sr.live.A_HCORR.set(value) # do exactly the same thing as above

Orbit response matrix measurement will use sr.live.A_HCORR.set() / get().

[simoneliuzzo]

Dear @JeanLucPons and @TeresiaOlsson,

how to distinguish then between real coil-currents and pseudo-currents?

In particular for the sextupoles at ESRF as Jean-Luc mentioned there is no pseudo-current, but we will want to access the coil currents nevertheless.

What would be the advantage of the pseudo-currents? Having to tune one single current knob for each multipole?

For current/strength mode switch (that I find a limiting feature of MML, extended in pyAML to have always available both coil-currents and strengths) the proposal by @yhidaka during the meeting was in my opinion a nice solution. As I understood it:

• pyaml provides for every element strength and coil currents (linked by the calibration/magnet model). Those may be arrays and are not forced to be in one-one relation (ex: ESRF sextupoles).
• the high level applications define a set and get function as inputs
• the user decides to run the high level application either with current.set()/get() or with strength.set()/get().

However, if we want to add pseudo-currents as they help development in some way, I have nothing against it.

best regards
Simone

[TeresiaOlsson]

I also really like that solution. Then there is no "switching", the developer of a high-level application doesn't have to make a choice which option to use when doing the implementation and the user can freely choose which way to run depending on their needs.