Meeting 15th November 2024
Present: 32 participants out of 109 invited
Notes:
16.03 M.Apollonio presentation
first test of pyACAL at MAXIV
succesfull but slow.
Mix among machines (beam dump in 3GeV ring while working in 1.5GeV)! Avoiding such events should be among specifications.
Synchronization check for pyACAL might be needed.
Missing control of Tango commands within pyAML. Software workarround implemented.
pyACAL waits for readback.
The present version of pyACAL is missing scripting features.
Q&A
used tango binding from Simon White, quickly coded for the purpose of tests.
pyACAL is fully epics oriented, need more clean abstraction layer.
During the ORM measurement at MAXIV slow orbit feedback is called at each step. Such an orbit feedback should be exported as a service, otherwise graphical application will not work correctly, generating conflicts when requesting for resources (ex BPM, steerers). There is apparently the need to abstract servers and abstracting the server part of a Control System will be difficult. It is however needed, or operation will be difficult.
What about the configuration of PyACAL? Was it exported from middle layer for example. How was it set up for MAXIV.
Defined from scratch looking at existing ESRF implementation, listing all device names etc.. not needed to extract from Matlab Middle Layer.
For Python and EPICS there are few interfaces for client and server.
Thanks to those that have written it
* clinets
* pyepics
* acioca
* captro
* server
* softIoc
* p4p
* PyDevice
16.22 T.Olsson presentation
Easy to make families -> easy to use software.
configuration is key to make the code user friendly and thus widely used.
For test of pyTAC and pyACAL at HZB it has required a lot of time up to now. for future pyAML try to make it as easy as possible.
Separated configuration file.
Clear minimal configuration for each action/tool
Should be possible to share just a configuration file
(yaml, toml, database, ...)
A list of configurations needed from all fields of AO and AD of MML is being extracted.
It should take at most 1 day to get started.
Q&A:
configurations can be very lab specific
configuration should take in account also commands and properties not only set/get.
any middle layer should be able to run without any knowledge of hardware.
In model mode (simulations) it should be independent completely from the hardware. Should be split totally or it will be a nightmare and a failure. Make clear in specifications.
Tango database has been tested in the past as a possible configuration solution. but had to come back. not portable enough.
Simple text based is convenient but could be not enough. However very easy to share.
An other option could be to store the information in the lattice itself. For pyAT this is possible. If other codes are used as back-end, this might be more difficult.
16.41 J.Biernat presentation
LOCO measurement is being ported to python.
working anomaly detection tools are shown.
Q&A
A FAST data flow for anomaly detection is set up.
The authors can be contacted to share software.
16.57 Y.Hidaka
A new Middle Layer code called PAMILA is shown.
A hierarchical approach is adopted to avoid repetition of settings and properties.
"Flows" are implemented to run experiments
An easy switch among Digital Twin an Live is set up.
bluesky and tiled interaction are ready. Blueksy has a steep learning curve. Utility functions are provided to expose bluesky features to users.
Q&A:
bluesky/ophyd/tiled optional or requirement? optional only. can work without it.
17.18 DESY workshop June 2024 follow up
Ask for volunteers to draft: specification documents and use case document.
volunteers: VG, SW, SL, JLP, TO, PS
Specification document
First meeting among these smaller group to define specifications breakdown and share work: configurations, control system abstraction, architecture, available features from existing code, magnet model, algorithm configuration, tools for generic HLA, etc...
PS: architecture should be first
JLP: draw architecture, assign names. After a few iterations some good spec will come up. Will propose also simple calibration mode. Comunication at the workshop.
Control system abstraction specification is needed. JLP will work on this. This abstraction should guarantee also arrays in the abstraction layer. handling of disabled elements.
IA will look for DOOCS expert. In the future DOOCS will be used for everything at DESY, including PETRAIV upgrade.
17.30 next workshop
workshop will highly target discussion and try to take in account new technology.
workshop idea would be to meet in berlin and discuss in smaller groups and later in plenary sessions round all experience and needs.
1 full day will be dedicated to discussion. The committee members will write in a report the outcome of the workshop subgroups.
17.40 space for hosting documents:
TO HZB mettermost linked space for document storage. like dropbox but not dropbox. Or Zenodo.
next cloud HZB same login as mattermost.
Software is already in github https://github.com/python-accelerator-middle-layer
SL and TO will test this solution for specification document and use cases documents.
17.37 how to reference and quote pyAML
The present people at the meeting agree that:
Any publications shall be announced in meetings and/or via email-list accelerator_middle_layer@esrf.fr.
The possibility to review any publication shall be given to all collaboration members sharing the draft document at least 15 days before deadline on the accelerator_middle_layer@esrf.fr mailing list.
The procedure:
1. announce publication wish via mailing list
2. give access to review and comment (15 days before deadline)
3a. authors: for proceeding and specific documents: use author names for actual contributors and acknoweldge pyAML collaboration in the Aknowledgment section using the sentence: "The authors wish to acknowledge the contribution to this work by the python accelerator middle layer international collaboration." In the future, if COST action is approved this sentence will be replaced by COST Action aknowledgment.
3b. authors: for peer review papers. Put name of all pyAML collaboration members.
4. references. If pyAML related software is used, publish the software on zenodo and cite the code in the paper.