Feedback from tests at MAX IV

[TeresiaOlsson]

Last week @marlibgin2 and I tested the current implementation at MAX IV. The week before Marco and Ali had tried to understand the tune correction example and set it up for MAX IV but it was difficult and therefore we decided to start with something much simpler. We thought since there is TANGO bindings we could try the most basic first test case: create a single quadrupole device and read the current of it. For this simple case we thought we didn't even need the yaml file but could make the configuration directly in python by creating objects from the config classes.

It didn't go especially well. We spent like half of a day trying to do it without any success. Then we gave up and switched to using pytango directly instead. Without previous experience of pytango it took us perhaps 10-15 minutes to do it. This feel concerning because to us pyAML in it's most basic form should just be a control system agnostic layer to pytango and pyepics where the user doesn't need to remember the control system names but can use the physics names instead. So we think it has to be simplified somehow so it's as easy to get started as pytango and pyepics.

The detailed feedback:

• It is too much work to set up the configuration for tests. We need to write a helper function which extracts the required information from the MML AO. I can try to do that.

• Documentation is needed for how to get started. Just a simple readme like there is for the tango-pyaml repository would already help a lot.

• The implementation doesn't seem to be sufficiently modular to use it purely as a hardware abstraction layer if the user isn't interested in physics units or the simulator. Or at least we didn't manage to understand how to use it like that.

• Is it possible to create the configuration directly in python or it's always required to parse it in externally? We didn't manage to understand how to do it directly in python because it wasn't clear to us which config classes we needed and which we could skip.

  We tried to create a device following this: https://github.com/python-accelerator-middle-layer/pyaml/blob/main/pyaml/control/device.py but that module doesn't seem to be used? At least tango-pyaml uses the base class DeviceAccess and not this device class. What is the purpose of the device class?

  Then there is the control system class https://github.com/python-accelerator-middle-layer/pyaml/blob/main/pyaml/control/controlsystem.py. How is this class related to creating the devices? Do you somehow need to create first a device object and then add it to the control system before it can be used? But it seems like the control system requires elements and not devices despite that there is a method called fill_device?

• What is the relation between element and device? Do you need to create an element if you just want to read an attribute from the control system? We thought we could just create a device directly and the element is only required if you want to use the simulator but maybe that's not the case?

• How is the tango-pyaml repository connected to the pyaml repository? After failing to try to understand how to make a device in pyaml and tell it that it should use the TANGO bindings we instead tried to use tango-pyaml directly by following the usage example https://github.com/python-accelerator-middle-layer/tango-pyaml?tab=readme-ov-file#usage-example but then we ran into problems because it seemed like we also needed configuration for the control system?

  We also were confused for a long time about why tango-pyaml should be imported as tango.pyaml and not as tango_pyaml. I have never seen that for a python package before, where do you specify that it should be imported like that? Is it perhaps this part in the pyproject.toml:

  [tool.setuptools.packages.find]
  include = ["tango.*"]
  

• We were missing a functionality like the AO in MML where it's possible to get the list of families and their current configuration. Basically it's a registry from where the configuration is extracted. Is there already some kind of registry functionality like that and we just didn't understand it?

[gupichon]

Hello, thanks for the report.
I think we could use it as a starting point to create other issues, such as:

• Adding a README.md with examples
• Creating an API (and documentation) to load an instrument without a configuration file
• And so on...

[gupichon]

About this point:

It is too much work to set up the configuration for tests. We need to write a helper function which extracts the required information from the MML AO. I can try to do that.

We are doing something similar at Soleil by generating a pyaml configuration file from a lattice and a set of rules that gives the device's name in the tango cs. I think thats the way to go but the possiblity to generate the configuration by code without any file will be necessary at some point (for tests and small developpements).

[gubaidulinvadim]

@TeresiaOlsson, I think it could be good if you or MAX IV colleagues, can report on this at the next maintainer meeting. And discuss who can handle the different sub-issues created by Guillaume. I agree that without documentation, it takes a lot of time to understand things. It was the same for me. The reason for lack of documentation is basically very few active developers...

[TeresiaOlsson]

We could but at the moment we are at the stage where we feel that a lot of refactoring needs to be done for it to work for us. So it might not be so constructive without a suggestion for what we think needs to be refactored and how.

I'm working on that together with the MAX IV colleagues, starting with the configuration and a replacement of the functionality of the MML AO which we think has been lost (or maybe it's there but we just didn't understand it...). But it will likely take some weeks until I have a suggestion because we have start-up of BESSY at the moment so not much time to code except fixing bugs in MML :/

After testing the yaml file approach, I don't really like it anymore. It's nice for quick test with a minimal configuration (for example for new users who just want to test if the code is for them) but as soon as you have a real machine you will anyway have to write a piece of code to generate the yaml file. After looking at the MML configuration for MAX IV, I also realised how many things they have configured there which we don't have at HZB but we likely want in the future. So now I'm considering the option to generate the required config objects directly in code instead. As long as the config dataclasses are sufficiently separated from the input parsers I think there shouldn't be any problem to also do it that way depending on what the user prefers.

[gubaidulinvadim]

Okay, could you write an issue describing the functionality of MML AO that you think is required for pyAML? Many people in our community are not using the MATLAB middle layer at all (SIRIUS, ESRF, software engineers,..). Otherwise this feedback will get lost.

[TeresiaOlsson]

Okay, I will try to do that later this week.

[JeanLucPons]

I'm sorry that the test at MaxIV was not fruitful. This was likely because the identity model was not yet implemented which means that access to magnet are only possible using a model and calibration curves.
The DeviceAccess class is an abstract class and cannot be used without an implementation.
For this a configuration is needed that will provide a bindings to the used control system.

Today if you want to access a Tango device with pyAML directly you can do:

from tango.pyaml.attribute import Attribute,ConfigModel
from pyaml.control.deviceaccess import DeviceAccess

dev:DeviceAccess = Attribute(ConfigModel.model_validate({"attribute":"srmag/vps-sd1/c01-a/current","unit":"A"}))
dev.set(59.41)
print(dev.get())

[TeresiaOlsson]

I still don't understand why an identity model is required if you want to use the code in it's most basic configuration where it's just an abstraction layer for the users to be able to use physics names instead of control system names? It sounds to me like unnecessary complexity and that there must be an easier option for the implementation.

So what would have been the correct way to create a single quadrupole magnet and read the current at MAX IV? The option using DeviceAccess directly could maybe have worked but what we wanted was to create a Quadrupole object and test it as the first step towards translating the tune correction example for ESRF to MAX IV. It looked like there was the possibility to read the strength of the magnet but not to set it since the magnets are powered in series and then you had to set the current for the power supply.

[JeanLucPons]

you should have created a complete model with a quad (including its calibration curve).

The minimum:

type: pyaml.pyaml
instruments:
  - type: pyaml.instrument
    name: sr
    energy: 6e9
    controls:
      - type: tango.pyaml.controlsystem
        tango_host: ebs-simu-3:10000
        name: live
    data_folder: /data/store
    devices:
    - type: pyaml.magnet.quadrupole
      name: QF1AC01
      model:
        type: pyaml.magnet.linear_model
        calibration_factor: 1.00054
        crosstalk: 1.0
        curve:
          type: pyaml.configuration.csvcurve
          file: sr/magnet_models/QF1_strength.csv
        unit: 1/m
        powerconverter:
          type: tango.pyaml.attribute
          attribute: srmag/vps-qf1/c01-a/current
          unit: A

from pyaml.pyaml import pyaml,PyAML
from pyaml.instrument import Instrument
from pyaml.lattice.element_holder import MagnetType
from pyaml.magnet.quadrupole import Quadrupole

ml:PyAML = pyaml("config/jlp_conf.yaml")
sr:Instrument = ml.get('sr')
quad: Quadrupole = sr.live.get_magnet(MagnetType.QUADRUPOLE,"QF1AC01")
print(quad.strength.get())
print(quad.hardware.get())

[TeresiaOlsson]

Okay, and a yaml file would also be required? Or there is already some way to generate the configuration objects directly without having to go via the yaml parser? It looks like the following line creates a config object that could be used to initialize without needing to go via a text file but I don't entirely understand how the data model looks for that config object.

https://github.com/python-accelerator-middle-layer/pyaml/blob/bc26a3a16f45ed4984c67c4df32a7ed5563a85c4/pyaml/pyaml.py#L47

@marlibgin2 knows best but after testing to set up the yaml file I think the conclusion from the MAX IV colleagues was that that they prefer to also have an option to generate the configuration directly in code as they currently do in MML.

[JeanLucPons]

A yaml file is not mandatory.
In your example, the load() function returns a dict.
This architecture was chosen especially for that, Instrument(s) can be constructed from a in memory dict.
Edit: I have of course some Java scripts that generate yaml files. For instance, I didn't edited the EBSTune.yaml file by hand ;)

[TeresiaOlsson]

That's good. We tried the approach to create the pydantic config objects directly. That felt easiest because then we could get the correct format and data validation automatically. Maybe that would have worked then if we just had figured out that we needed to create an Instrument and couldn't just make a Quadrupole.