2 handle serialized magnets

[gupichon]

Description

Handling serialized magnets. Changing one of the serie changes all of them, by passing by the model as the current is common. Specific corrections factors can be set by element.

Related Issue

• Fixes Handle serialized magnets #2

Features/issues described there are:

• Serialized magnets model
• Linear model for serialized magnet with he possibility to fine tune each element with a specific curve and/or factors.

Testing

The following tests (compatible with pytest) were added:

• test_serialized_magnets.py

[gubaidulinvadim]

Side note. I think the difference files in this merge request clearly show that we already need some formatted and pre-commit hooks. @yhidaka made it for https://github.com/python-accelerator-middle-layer/pyaml-cs-oa repository. I would suggest that we simply copy his setup until there are some alternatives (a copier template or something else).

[JeanLucPons]

I'm a bit confused with this implementation.
If i understand well, you can handle several set of serialized magnets and you create 1 set of virtual magnet per power supplies with a matrix to make the relation between power supplies and set of magnet that share the same power supply ?

    Class managing serialized magnets: a set of magnet with the same set point.
    The set point is usually managed by only one power supply but it can be covered by several ones.
    If several power supplies

But then it is unclear in your serialized_magnets configuration on how you define the names of each set ?

Here is what i supposed:

  - type: pyaml.magnet.serialized_magnet
    name: mySeriesOfMagnets
    function: B1
    elements:   # name in the lattice and name of virtual magnet in pyaml
      - QD2E-C01
      - QD2E-C02
      - QD2E-C03
      - QF1A-C01
      - QF1A-C02
      - QF1A-C03
    model:
    type: pyaml.magnet.linear_serialized_model
        calibration_factors: [...]                             # 1 factor magnet (6)
        calibration_offsets: [...]                             # 1 offset per magnet (6)
        unit: m-1
        curves: sr/magnet_models/quadcurve.yaml    # 1 curve per magnet (6)
        matrix: [  [1,1,1,0,0,0]
                       [0,0,0,1,1,1]  ]                                     #  For QD2E and QF1A
        powerconverters:                                             # 1 ps per set  (here 2)
          - type: tango.pyaml.attribute
            attribute: srmag/vps-qd2/e/current
            unit: A
          - type: tango.pyaml.attribute
            attribute: srmag/vps-qf1/a/current
            unit: A

But now, how to access the QD2E family ?
I need to set randomly QD2E-C01, QD2E-C02 or QD2E-C03 ?
I would prefer to be able to set QD2E.

When several magnets having different models are powered by a single power supply, then you are forced to work in hardware unit (RW) and update your strengths accordingly (strengths are then read only). It is unclear for me how this is handle ?

I also would like also to have a simple implementation with a set of magnet that share the same name in the lattice which is a typical way of using families.

It is necessary to have a class that can handle a multiple set of serialized magnets ? only one set is already enough complex...

Thanks

[JeanLucPons]

Side note. I think the difference files in this merge request clearly show that we already need some formatted and pre-commit hooks. @yhidaka made it for https://github.com/python-accelerator-middle-layer/pyaml-cs-oa repository. I would suggest that we simply copy his setup until there are some alternatives (a copier template or something else).

I agree, Guillaume also corrected lots of typos i made (thanks to him) but this make the review more difficult. It would be cool to correct typos, in separate PR that does not affect the code.
Thanks for understanding.

[gupichon]

To answer your question, @JeanLucPons, it can manage several magnets with separate power supplies to emulate magnets in series. Of course, this is not the main use case, and the matrix is not mandatory.
I also corrected some typos along the way. A dedicated PR should indeed be created.
Also, I will bump the version with a patch increment since it doesn’t break any interfaces. It’s a brand-new feature.

[gupichon]

When several magnets having different models are powered by a single power supply, then you are forced to work in hardware unit (RW) and update your strengths accordingly (strengths are then read only). It is unclear for me how this is handle ?

Even with different models, you can work with strength, but you will set a strength for a specific magnet, which will provide the corresponding hardware value for the entire series. But it’s true that all magnets are linked through the hardware, so the hardware part is mandatory for magnets in series.

[gupichon]

@JeanLucPons, i am adding your example to the tests.

[JeanLucPons]

Magnets with the same name will be an issue because not everyone uses the famName. We don’t expect to have more than one matching element for a given name at Soleil for example.

pyaml has to handle both case.
I don't see issue in handling several magnet that share the same AT name if you need.
If you don't need it and if you want to use unique name in your AT lattice you can also.

[gupichon]

Ok, I think I need more explanations about magnets sharing the same name. I’d like to have an example for testing. I don’t have enough knowledge on these topics. Would one of you be available to explain how it works to me?

[JeanLucPons]

Ok, I think I need more explanations about magnets sharing the same name. I’d like to have an example for testing. I don’t have enough knowledge on these topics. Would one of you be available to explain how it works to me?

This quite is easy. You just have to weight each AT magnet strength by element_length/total_length where total length is the sum of all elements length.
If you want, i do a commit on your branch tomorrow, but i would prefer that you do it (and understand it) yourself.

[JeanLucPons]

We can even go further and handle split magnet with non constant magnet core shape (as we had in the old ESRF DBA) and weight by KL/sum(KL).

[JeanLucPons]

@gubaidulinvadim
I proposed to @gupichon to wait that he returns from leave and that he ends his work.
But I saw that you want to merge before merging you pre-commit branch ?
Should we finish the work here or that can wait ?

[gubaidulinvadim]

That can wait. But for me, there's no problem applying the pre-commit for formatting. When @gupichon returns to SOLEIL (early January), he will have to merge main into this branch in any case. I could also try to merge the formatting changes here to make his life easier.

[gupichon]

I've done the merge with the main.

[JeanLucPons]

Sorry I didn't have time yesterday to finish the review, may be you have corrected it but there are few issues:

• Duplicate CombinedFunctionMagnet case in controlsystem.py
• During your absence, the magnet model changed due to CS refurbishement
  • Now DeviceAccess should be attached to the CS and device handle passed to control system abstract implementations.
  • Removal of following functions from MagnetModel

   def read_hardware_values(self) -> np.array:
   def readback_hardware_values(self) -> np.array:
   def send_hardware_values(self, currents: np.array):

[gupichon]

It's corrected

[JeanLucPons]

Thanks
Would it be possible to rename:

class SerializedMagnetsModel(Element):

to

class SerializedMagnets(Element):

I have to check the lattice abstract implementations , it should be possible to use RWStrengthScalar instead of RWStrengthIntegratedScalar. RWStrengthScalar has been recently adapted to handle serialized BESSY magnets.

For the time being in pyAML Strength are integrated strength.
We should discuss during the next workshop if we support the K and KL convention.

[gupichon]

Yes, i've seen they updated the RWStrengthScalar object. They migth be used instead. I'm looking to it.

[gupichon]

It should be ok now.

[JeanLucPons]

It seems fine.
thanks.