pyAML workshop: Working Group "Remote" feedback

[yhidaka]

Feedback from Working Group "Remote"

[samihabetpositron]

Concerning the SOLEIL's example to measure the chromaticity we have to manually input a wait_time. Would it be possible for PyAML to monitor the Tango State (waiting for it to return to ON or RUNNING) instead of a fixed sleep? I'm not a Tango expert, but this could make the measurement more robust and faster.

[TeresiaOlsson]

This should eventually be implemented at the device level. In ophyd-async this functionality has been implemented as a Status object which has attributes successful and done which I personally really like because it doesn't just say when a device is finished doing something but also if it was successful (or for example timed out). I think it would be nice if we could have the same in pyAML.

[samihabetpositron]

For the calculation of the chromaticity, we need αc​ (alphac). Instead of passing it as an argument or reading it at each iteration, wouldn't it be more efficient to store it in the p.yaml configuration file? This would centralize the machine parameters and simplify the measure() call. It was mentioned during Jean-Luc's talk yesterday

[samihabetpositron]

ESRF examples: Dispersion unit is confusing

[samihabetpositron]

Need to be normalized in meters (divided by the energy deviation

[marlibgin2]

pyaml/SOLEIL-example/01-SOLEIL_II_tune_example almost OK, the end is

[gubaidulinvadim]

@marlibgin2 It's the tqdm package (it gives a progress bar for for-loops) that gives you this error. You need to either

• install ipywidgets
• remove tqdm import and use from examples

[marlibgin2]

thank you Vadim! I checked that in fact, during the remote section, the guys helped me find the problem, but I do not have the notes taken today with me so I do not recall if it was the tdqm thing. Indeed in the ipyb code I still see this line

"from tqdm.notebook import tqdm\n",

and yet it seems to work

Just as a side note: all the tests for SOLEIL worked for me )after some help from within the "remoters" group)

[marlibgin2]

pyaml/examples/SOLEIL_examples/02-chromaticity_measurement.ipynb seems to work quite OK

[yhidaka]

During the run of pyaml/examples/ESRF_ORM_example/measure_ideal_ORM.py, we encountered this error:

...
03 Feb% 2026, 03:36:49 | INFO | Measured response of SH3E-C03-V.
Traceback (most recent call last):
  File "/nsls2/users/yhidaka/git_repos/pyaml/examples/ESRF_ORM_example/measure_ideal_ORM.py", line 19, in <module>
    ormdata = ebs.get()
              ^^^^^^^
AttributeError: 'Simulator' object has no attribute 'get'

[samihabetpositron]

It shouldb ebs.orm.get()

[yhidaka]

The line should be ormdata = ebs.orm.get() instead.

[samihabetpositron]

The manual construction of the ideal_ORM_data dictionary is prone to errors. It would be great if PyAML had a built-in method like ebs.orm.export_with_dispersion() to automate this merging process

[marlibgin2]

esrf_tune_Example ... initially coul not find

sr: Accelerator = Accelerator.load("./tests/config/EBSTune.yaml")

so I commented this line and put a temporary explicit path pointing at my directory:
sr: Accelerator = Accelerator.load("/gpfs/offline1/staff/common/marapo/pyAML_WORKSHOP_2026/pyaml/tests/config/EBSTune.yaml")
it works better but still crashes

[marlibgin2]

... sorry for the gigantic line, it was the sharp/diesis symbol ...

[samihabetpositron]

the .yaml file is in Accelerator.load("../../tests/config/EBSTune.yaml")

[marlibgin2]

yes it is ... thank you!

[yhidaka]

pyaml/examples/SOLEIL_examples/01-SOLEIL_II_tune_example.ipynb

Issues and fixes, as suggested by Vadim:

• tqdm had to be removed
• Manual tune response measurement for-loop: tunemat[idx] = dq / delta instead of dq * delta

[samihabetpositron]

For Bessy's example in the .yaml files the ( prefix: "a3744:") should be replaced by the Username

[TeresiaOlsson]

Maybe we need to add some option in the yaml file to specify an environment variable to read to fix this problem?

[yhidaka]

Presentation

Common

• Written feedback on pyaml / accml (preferably using GitHub    discussions with the title "pyAML workshop: working group X    feedback")
     - feedback on configuration with yaml / json files, on manual creation of pyaml objects
     - feedback on the documentation / lack thereof
     - feedback on running examples
     - feedback on the present interface to pySC
     - any other feedback
  • Based on the feedback, try to create GitHub issues, following the existing template. 
  • Cherry-picking of functionality / interfaces of pyaml /  accml. What would you really like to see in the final product?
  • Short presentation (~10 minutes) elaborating on the main points from above (to be presented on the last day of the workshop)

pyaml & accml

• Installation was difficult. Requirements need to be well defined and tested. Examples need testing to make sure all file paths are correct.
• Preferably, we should come up with a single environment that works with all control systems (EPICS & Tango for now).
• An overview presentation would have been helpful for beginners who are not actively involved in the code development.
• More explanation on how apptainer & virtual accelerators (VAs) work together with pyaml would have been helpful. The apptainer VA for EPICS didn't work for some users.

pyaml

• Very usable. Pythonic and intuitive to use.
• Didn't have much time to investigate beyond just running the example files.
• pySC not visible at the example file level. Had no time to dig in to check its interface.
• The provided configuration files were already well prepared, which made it difficult to understand a new user on how to start creating such a config file from scratch.

accml

• Not so usable. The examples were hard to understand, compared to pyaml.
• Not sure, but it seems to have an asynchronous run capability in Jupyter, which is good, while pyaml doesn't seem to.
• Too many example files/folders, which made it hard to figure out which ones to run.
• Only one notebook worked for some and zero for others. Other notebooks depended on some missing configuration files.

Unit Conversion

The primary aim of this working group is to discuss handling of unit conversion in pyAML (Ampere to strength unit; simple conversion mm to m; strength to integrated strength, etc)

Input

• Implementation in PAMILA code 
• Pint package (https://pint.readthedocs.io/en/stable/)
• Existing implementations in accml and pyaml
• Design pattern from accml

Objectives and deliverables

 - Update to the documentation regarding the unit conversion
 - GitHub discussion or issue describing the proposal
 - Draft pull request (PR) with implementation suggestion

Comments

• We discussed how pint / astopy.units work.
• Fernando explained how unit conversion is handled in pyacal: concatenation of atomic conversions. This allows flexible unit conversion without any package source modification.
• Some facility may need live updating of magnetic rigidity for unit conversions.
• pint seems quite flexible and promising to be integrated into pyaml.
• Concerns:
  • whether pint is sustainable (long-term maintenance)
  • adaptable
  • save/load
  • performance overhead
  • initial friction to users unfamiliar with unit conversion packages
  • compatibility to old data saved by MML
• Should we make units mandatory or optional or not adopted at all? Steering Committee should decide.

Set & Wait Functionality

Description

The aim will be to discuss the handling of wait times in pyAML (set and wait functionality). 

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 replace the functionality of the
   MML WaitFlag fully?

Objectives and deliverables

 - Update to the documentation regarding set_and_wait()
 - GitHub discussion or issue describing the proposal
 - Draft pull request (PR) with implementation suggestion

Comments

• Currently pyaml relies only on fixed wait times. We think the asynchronous / adaptive wait feature is mandatory.
• The configuration file should allow users to add monitoring PVs/attributes to enable this set & wait feature.
• Properties to be specified in the config file (These should be overridable by end users.):
  • method (no wait, fixed wait time, tolerance, etc.)
  • tolerance within which the setpoint-readback difference should fall
  • additional settle time (fixed wait time after crossing the tolerance window for the first time)
  • max wait time (fixed or adaptive from the ramp rate, which could be another PV to be monitored)
• ophyd-async has the set & wait feature already. So, only a thin wrapper may be needed to enable this feature if ophyd-async is used as the backend.
• Complicated cases probably need to be handled by facility-specific custom packages.

[yhidaka]

I've slightly added / modified the "Unit Conversion" Comments section as below:

Comments

• We discussed how pint / astopy.units work.
• Fernando explained how unit conversion is handled in pyacal: concatenation of atomic conversions. This allows flexible unit conversion without any package source modification.
• Some facility may need live updating of magnetic rigidity for unit conversions.
• pint seems quite flexible and promising to be integrated into pyaml. astropy is probably too big.
• Concerns:
  • whether pint is sustainable (actively maintained)
  • adaptable / flexible
  • how to save/load
  • performance overhead (i.e., speed)
  • initial friction to users unfamiliar with unit conversion packages
  • compatibility to old data saved by MML
• Should we make units mandatory (i.e., with units only) or optional (with units or without units) or not adopted at all? Steering Committee should decide.
• If adopting units, it is better to transition as soon as possible before too many scripts are written without units.

[samihabetpositron]

Some of us struggled with firewall issues and were unable to use the BESSY Apptainer, for example.

[TeresiaOlsson]

Some of us struggled with firewall issues and were unable to use the BESSY Apptainer, for example.

This I think is something worth investigating further to see if there is some general EPICS solution which doesn't require permissions to change the firewall. Did you have the problem when running on your own local computer or only on some centrally managed service run by your IT department? For @marlibgin2 the problem seemed to only be for the centrally managed service and on local computer it worked.

Also seems like the error messages when this happens is impossible to understand unless you are an EPICS expert. At least I would never understand from them that it's a problem with the firewall.

[TeresiaOlsson]

In the steering committee today we discussed the option to use SI units as standard inside the core and then keep unit conversion only on the border to translate to and from the units used in the different backends. @yhidaka and @fernandohds564 what is your take on that? Do you see use cases for having the unit everywhere? The idea was otherwise to inside the core have the unit as a doc string and some unit conversion package (or our own lightweight implementation) would be just used for the input/output to the core.

[yhidaka]

@TeresiaOlsson Sorry I didn't quite understand the plan. Can you elaborate more on the options suggested by the committee?

Dimensionality check, in addition to simple prefix scaling conversion, can sometimes save us in a big way. For example, when dealing with orbit response matrices, you may get [mm/A] or [m/rad]. Use of quantity objects can prevent end users from applying ridiculously large or small corrections to the machine.

People are fallible. In safety systems, engineering control is generally preferred over administrative control. Enforcing quantity objects is similar to engineering control, instead of relying on users to always do the right thing.

With that said, astropy does not appear to have a global policy requiring the use of astropy.units.Quantity across all core APIs. Instead, unit handling and enforcement are determined at the subpackage or API level. Where strict unit validation is required, astropy provides opt-in mechanisms such as astropy.units.quantity_input; elsewhere, units may be implicit, provided via separate arguments, or treated as metadata. So, optional adoption may be a more sensible approach for us, too.

But, if we do adopt quantity objects, I'd be against in-house implementation. I don't see a point of reinventing wheels, when we are already thin in terms of actual FTEs. pint is more than a decade old, and has ~200 contributors, which is on par with h5py. I'd say, if we're comfortable depending on h5py, why not also pint?

[marlibgin2]

yes I thought it was mentioned, wasn' it ? I could though make it run on a WSL - Ubuntu machine created on the fly so in general other labs could experience similar issues with firewalls Marco

…

________________________________ From: Sami Habet ***@***.***> Sent: Wednesday, February 4, 2026 8:59 AM To: python-accelerator-middle-layer/governance ***@***.***> Cc: Marco Apollonio ***@***.***>; Mention ***@***.***> Subject: Re: [python-accelerator-middle-layer/governance] pyAML workshop: Working Group "Remote" feedback (Discussion #38) Some of us struggled with firewall issues and were unable to use the BESSY Apptainer, for example. — Reply to this email directly, view it on GitHub<#38 (reply in thread)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/A2VQ5FVJ7JI6IIO55HEIPVD4KGRF5AVCNFSM6AAAAACTZEIGA2VHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTKNRZGEZDGOA>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[yhidaka]

Presentation (Final Version)

Common

• Written feedback on pyaml / accml (preferably using GitHub    discussions with the title "pyAML workshop: working group X    feedback")
     - feedback on configuration with yaml / json files, on manual creation of pyaml objects
     - feedback on the documentation / lack thereof
     - feedback on running examples
     - feedback on the present interface to pySC
     - any other feedback
  • Based on the feedback, try to create GitHub issues, following the existing template. 
  • Cherry-picking of functionality / interfaces of pyaml /  accml. What would you really like to see in the final product?
  • Short presentation (~10 minutes) elaborating on the main points from above (to be presented on the last day of the workshop)

Comments for pyaml & accml

• Installation was difficult. Requirements need to be well defined and tested. Examples need testing to make sure all file paths are correct.
• Preferably, we should come up with a single environment that works with all control systems (EPICS & Tango for now).
• An overview presentation would have been helpful for beginners who are not actively involved in the code development.
• More explanation on how apptainer & virtual accelerators (VAs) work together with pyaml would have been helpful. The apptainer VA for EPICS didn't work for some users.

Comments for pyaml

• Very usable. Pythonic and intuitive to use.
• Didn't have much time to investigate beyond just running the example files.
• pySC not visible at the example file level. Had no time to dig in to check its interface.
• The provided configuration files were already well prepared, which made it difficult to understand a new user on how to start creating such a config file from scratch.

Comments for accml

• Not so usable. The examples were hard to understand, compared to pyaml.
• Not sure, but it seems to have an asynchronous run capability in Jupyter, which is good, while pyaml doesn't seem to.
• Too many example files/folders, which made it hard to figure out which ones to run.
• Only one notebook worked for some and zero for others. Other notebooks depended on some missing configuration files.

Unit Conversion

The primary aim of this working group is to discuss handling of unit conversion in pyAML (Ampere to strength unit; simple conversion mm to m; strength to integrated strength, etc)

Input

• Implementation in PAMILA code 
• Pint package (https://pint.readthedocs.io/en/stable/)
• Existing implementations in accml and pyaml
• Design pattern from accml

Objectives and deliverables

 - Update to the documentation regarding the unit conversion
 - GitHub discussion or issue describing the proposal
 - Draft pull request (PR) with implementation suggestion

Comments

• We discussed how pint / astopy.units work.
• Fernando explained how unit conversion is handled in pyacal: concatenation of atomic conversions. This allows flexible unit conversion without any package source modification.
• Some facility may need live updating of magnetic rigidity for unit conversions.
• pint seems quite flexible and promising to be integrated into pyaml. astropy is probably too big.
• Include "uncertainties" as well?
• Concerns:
  • whether pint is sustainable (actively maintained)
  • adaptable / flexible
  • how to save/load
  • performance overhead (i.e., speed)
  • initial friction to users unfamiliar with unit conversion packages
  • compatibility to old data saved by MML
• Should we make units mandatory (i.e., with units only) or optional (with units or without units) or not adopted at all? Steering Committee should decide.
• If adopting units, it is better to transition as soon as possible before too many scripts are written without units.

Set & Wait Functionality

Description

The aim will be to discuss the handling of wait times in pyAML (set and wait functionality). 

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 replace the functionality of the
   MML WaitFlag fully?

Objectives and deliverables

 - Update to the documentation regarding set_and_wait()
 - GitHub discussion or issue describing the proposal
 - Draft pull request (PR) with implementation suggestion

Comments

• Currently pyaml relies only on fixed wait times. We think the asynchronous / adaptive wait feature is mandatory.
• The configuration file should allow users to add monitoring PVs/attributes to enable this set & wait feature.
• Properties to be specified in the config file (These should be overridable by end users.):
  • method (no wait, fixed wait time, tolerance, etc.)
  • tolerance within which the setpoint-readback difference should fall
  • additional settle time (fixed wait time after crossing the tolerance window for the first time)
  • max wait time (fixed or adaptive from the ramp rate, which could be another PV to be monitored)
• ophyd-async has the set & wait feature already. So, only a thin wrapper may be needed to enable this feature if ophyd-async is used as the backend.
• Complicated cases probably need to be handled by facility-specific custom packages.

[gupichon]

Very impressive work! Well done!

[marlibgin2]

Yoshi without changing the final version, just a note. My inability at using the apptainer for bessy2 was due to a firewall we have at maxiv, I tested on a WSL Ubuntu linux machine and it worked. It would be worth for users to know about this possible problem. Cheers Marco

…

________________________________ From: yhidaka ***@***.***> Sent: Wednesday, February 4, 2026 9:05 AM To: python-accelerator-middle-layer/governance ***@***.***> Cc: Marco Apollonio ***@***.***>; Mention ***@***.***> Subject: Re: [python-accelerator-middle-layer/governance] pyAML workshop: Working Group "Remote" feedback (Discussion #38) Presentation (Final Version) Common * Written feedback on pyaml / accml (preferably using GitHub discussions with the title "pyAML workshop: working group X feedback") - feedback on configuration with yaml / json files, on manual creation of pyaml objects - feedback on the documentation / lack thereof - feedback on running examples - feedback on the present interface to pySC - any other feedback * Based on the feedback, try to create GitHub issues, following the existing template. * Cherry-picking of functionality / interfaces of pyaml / accml. What would you really like to see in the final product? * Short presentation (~10 minutes) elaborating on the main points from above (to be presented on the last day of the workshop) * pyaml & accml * Installation was difficult. Requirements need to be well defined and tested. Examples need testing to make sure all file paths are correct. * Preferably, we should come up with a single environment that works with all control systems (EPICS & Tango for now). * An overview presentation would have been helpful for beginners who are not actively involved in the code development. * More explanation on how apptainer & virtual accelerators (VAs) work together with pyaml would have been helpful. The apptainer VA for EPICS didn't work for some users. pyaml * Very usable. Pythonic and intuitive to use. * Didn't have much time to investigate beyond just running the example files. * pySC not visible at the example file level. Had no time to dig in to check its interface. * The provided configuration files were already well prepared, which made it difficult to understand a new user on how to start creating such a config file from scratch. accml * Not so usable. The examples were hard to understand, compared to pyaml. * Not sure, but it seems to have an asynchronous run capability in Jupyter, which is good, while pyaml doesn't seem to. * Too many example files/folders, which made it hard to figure out which ones to run. * Only one notebook worked for some and zero for others. Other notebooks depended on some missing configuration files. Unit Conversion The primary aim of this working group is to discuss handling of unit conversion in pyAML (Ampere to strength unit; simple conversion mm to m; strength to integrated strength, etc) Input * Implementation in PAMILA code * Pint package (https://pint.readthedocs.io/en/stable/) * Existing implementations in accml and pyaml * Design pattern from accml Objectives and deliverables - Update to the documentation regarding the unit conversion - GitHub discussion or issue describing the proposal - Draft pull request (PR) with implementation suggestion Comments * We discussed how pint / astopy.units work. * Fernando explained how unit conversion is handled in pyacal: concatenation of atomic conversions. This allows flexible unit conversion without any package source modification. * Some facility may need live updating of magnetic rigidity for unit conversions. * pint seems quite flexible and promising to be integrated into pyaml. astropy is probably too big. * Include "uncertainties" as well? * Concerns: * whether pint is sustainable (actively maintained) * adaptable / flexible * how to save/load * performance overhead (i.e., speed) * initial friction to users unfamiliar with unit conversion packages * compatibility to old data saved by MML * Should we make units mandatory (i.e., with units only) or optional (with units or without units) or not adopted at all? Steering Committee should decide. * If adopting units, it is better to transition as soon as possible before too many scripts are written without units. Set & Wait Functionality Description The aim will be to discuss the handling of wait times in pyAML (set and wait functionality). 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 replace the functionality of the MML WaitFlag fully? Objectives and deliverables - Update to the documentation regarding set_and_wait() - GitHub discussion or issue describing the proposal - Draft pull request (PR) with implementation suggestion Comments * Currently pyaml relies only on fixed wait times. We think the asynchronous / adaptive wait feature is mandatory. * The configuration file should allow users to add monitoring PVs/attributes to enable this set & wait feature. * Properties to be specified in the config file (These should be overridable by end users.): * method (no wait, fixed wait time, tolerance, etc.) * tolerance within which the setpoint-readback difference should fall * additional settle time (fixed wait time after crossing the tolerance window for the first time) * max wait time (fixed or adaptive from the ramp rate, which could be another PV to be monitored) * ophyd-async has the set & wait feature already. So, only a thin wrapper may be needed to enable this feature if ophyd-async is used as the backend. * Complicated cases probably need to be handled by facility-specific custom packages. — Reply to this email directly, view it on GitHub<#38 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/A2VQ5FRFXGHYDXTKARPPG2L4KGR43AVCNFSM6AAAAACTZEIGA2VHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTKNRZGEZDSMI>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[yhidaka]

Thanks and sorry, I just read this now...

[marlibgin2]

no worries, no worries focus was on the presentation (thanks for doing it)

…

________________________________ From: yhidaka ***@***.***> Sent: Wednesday, February 4, 2026 11:34 AM To: python-accelerator-middle-layer/governance ***@***.***> Cc: Marco Apollonio ***@***.***>; Mention ***@***.***> Subject: Re: [python-accelerator-middle-layer/governance] pyAML workshop: Working Group "Remote" feedback (Discussion #38) Thanks and sorry, I just read this now... — Reply to this email directly, view it on GitHub<#38 (reply in thread)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/A2VQ5FV2EBH2W4EYPNVQIJ34KHDKFAVCNFSM6AAAAACTZEIGA2VHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTKNRZGI4DQNI>. You are receiving this because you were mentioned.Message ID: ***@***.***>