Things to discuss at the workshop

[TeresiaOlsson]

I think it would be useful to start gathering a list of things to discuss at the workshop so make use full use of the possibility to discuss in-person and try different solutions.

So far I have:

• Strength convention in pyAML: I learned from @JeanLucPons that pyAML works in KL but MML works in K. That would be a convention change affecting the existing MML users when transitioning from MML to pyAML. I would require both a translation of conversion factors and learning a new meaning of the physics unit for magnets. However, @JeanLucPons also have use cases where KL is required.

[TeresiaOlsson]

• Status object/some other way to handle sleeps at device level:
  • How should this be implemented?
  • What configuration is required (ramp rate, tolerance etc)
  • Which functionality is required to fully replace the functionality of the MML WaitFlag?

[gubaidulinvadim]

For me, the discussion should focus on the work (macroscopically) that needs to be done in the coming years. I would think, that it is the steering committe who should actually select / limit the topics for discussion. And this GitHub dicsussion should only serve as an input. @TeresiaOlsson is it planned in one of your meetings to discuss this? Avenues for future work:

1. Measurements / tuning tools. I would use "tuning tool" for something like changing chromaticity or tunes using a response matrix, i.e. changing some rather macroscopic parameter based on some model. Measurement is somethink like measuring the chromaticity by chanding the RF frequency (I cannot convince myself to call this "tuning tool"). Presently, we have a few tuning tools implemented and a few measurements. However, this is not done in a general way with some abstract class for a measurement / tuning tool. Also, in the user interface specification we have some outline from @yhidaka on two ways to do measurements. One is writing a measurement script and another one is more strict and somewhat closer to the infamous Measurement Executing Engine concept. It is clear that there should be some way to do measurements in this way in pyAML / interface to pyAML to fulfill the requirements of HZB.
2. Anything about metadata: format, automatic saving, etc. I, personally, would like to not be involved in anything related to metadata discussion.
3. Measurements / tuning tool / model data storage and saving. Format of the data, where to store it, etc. I know some people at SOLEIL who are eager to talk about this topic. I, personally, would like to not be involved in anything related to data storage discussion.
4. Feedbacks (slow). In SOLEIL MML, I think slow orbit feedback is implemented. I am not a fan of this personally, but the need for MML-like feedback could be discussed at the workshop.
5. pySC integration level. Currently we have an interface to pySC as a temporary solution. I think we need to discuss what should be in the scope of pyAML and what should be in the scope of pySC. @kparasch, do you think it is a good idea to discuss it at the workshop?
6. Graphical user interfaces. Is this in the scope of pyAML or each facility could write a GUI in their prefered way that runs pyAML under the hood?
7. Digital twin. What kind of digital twin / virtual accelerator is in the scope of pyAML. We need something to run CI/CD pipelines with and something to assist in the manual testing during the development. Is HZB solution available and generic enough?
8. Feedback (human) on the development process so far, interactions, meeting organisation, GitHub projects, etc.

I would also say that there should be an update on the commited human resources to the project from different labs.

[TeresiaOlsson]

This was discussed a bit at the last steering committee meeting. The conclusion was to first have a community discussion during the sessions at the last day of the workshop and then that would be the input to the following steering committee meeting where it will be discussed.

I think your list is a very good starting point for what to discuss. I want to add to it:
Ecosystem development: The idea is to develop the code in a modular way, separate in different repositories etc to allow labs to pick-and-choose what they want to use and be able to integrate with potential lab-specific tools and ways to do things without those things having to go into pyAML affecting all other labs. This is an idea used by other communities and an approach I think could solve many of our issues as well as allowing labs to gradually migrate from their existing tools to pyAML.

[TeresiaOlsson]

@gubaidulinvadim

Suggestions for working groups:

• Conventions and potential PALS compatibility. One thing especially important to discuss before migration from MML is started is https://github.com/orgs/python-accelerator-middle-layer/discussions/37#discussion-9259875
• Unit conventions - both hardware to physics and nm to m etc. @yhidaka has things in PAMILA that could be interesting to look at and include. For example, use of pint.
• Documentation
• Metadata and data storage. Here it could be interesting to look at how ophyd/ophyd-async automatically generates this from devices and perhaps do something similar.
• Status, set and wait etc to handle sleep times at device level. See https://github.com/orgs/python-accelerator-middle-layer/discussions/37#discussioncomment-15288456
• Repository structure and interfaces. How to separate parts into different repositories to support the ecosystem approach while still making it easy for users to install what they need. For example maybe there should be separate repositories for each tuning tool/measurement allowing to have several implementations using different approaches and a separate repository for the core?

[JeanLucPons]

I wrote a simple Tango server to run an ORM scan.
https://github.com/python-accelerator-middle-layer/pyaml/tree/main/examples/ORM_Tango_server

@patrickmadela @gupichon
Do you think it would be possible to make it run in your Tango env during the workshop ?
It just require a Tango DB and the scan is done on the design so no need of virtual accelerator.
It should be possible to make it run without a DB but i never used that Tango feature.
Thanks

[kparasch]

These kind of errors usually happen for me when I run examples from a new version of pyaml, while an old version of pyaml is installed in the environment. Maybe it is this?

[patrickmadela]

@JeanLucPons : I have the same version of pydanctic as you
@kparasch : Thanks, I didn't update my environment, I will try that

[patrickmadela]

I confirm that it works with the latest version on the main branch, but it doesn’t work with the tagged version accelerator-middle-layer 0.2.3.
I always use the tagged version to build the image. I’ll continue my tests.

[patrickmadela]

@JeanLucPons I successfully created an Apptainer image that includes the Tango database and the ORM device.

[JeanLucPons]

Thank you @patrickmadela