20th of November, 2024
presentation by Matias Guijarro, AWI dept
From to :
Control System Comparison and Perspectives
SLS 2.0 Beamline Scientist Expert Group
About the speaker
Software Engineer
20-year career at ESRF,
Beamline Control Unit
BLISS project responsible: 2017-2023
In sabbatical leave since 01/24
Joined BEC Development Team at Science IT Infrastructure and Services Department, PSI
Breaking news
January, 2025: will start at
Talk outline
Control System comparison
- Architecture
- Technical choices
- Configuration
- Scans
- Graphical Interfaces
- Data Saving
- Data Management
- Data Processing
Perspectives
- Symbiosis
- Introducing Blissdata
- Proposal
Control systems comparison
From "How Do Committees Invent?" (1968)
Organizations which design systems [...] are constrained to produce designs which are copies of the communication structures of these organizations.
Melvin Conway, circa 1968 and more recently.
VS.
scalar
Main components running within the same process (think of SPEC)
Hardware control is also part of it, mostly as direct connection or through
Device Server
Scan Server
Scan Bundler Service
Scihub Service
BEC shell
BEC core library
Main components running as services (multiple processes)
Hardware control is delegated to Ophyd (Bluesky project), mostly through
Written in Python
I/O based on gevent, cooperative multi-tasking
Built-in direct hardware control, or
Centralized architecture
ptpython shell
Written in Python
Services-oriented architecture
Multi-threading
Devices control via Ophyd (Bluesky)
Buffer and settings DB
Buffer and message broker
IPython shell
Qt graphical interfaces
Qt and web graphical interfaces
{..}
{..}
Human-readable, editable YAML configuration
Human-readable, editable YAML configuration
HDF5 file saving format
HDF5 file saving format
framework
library
Scan stubs
Scan class to write, with methods:
open, stage, pre_scan, core loop, complete, unstage, close
Maximum flexibility
Acquisition chain (tree)
Node devices trigger acquisition
Leaf node devices take data
Channels push data to Redis
Core loop is always the same
configuration
code
"one size fits all" online visualization
Has to be used with BLISS shell:
Region of Interest selection, basic user interaction
No scan launching, no device tweaking (motors...), no parameter forms
Flint
Daiquiri
Custom applications
Developed by engineers, adapted for the beamline technique/experiments
General concepts: device tweaking, scans launching, queuing, forms, logging, etc
ESRF GUI strategy towards
web apps
ptpython
interpreter
blissterm server
ptpython
interpreter
API
blissterm application
socket io
xtermjs
Daiquiri UI components library
logic
blissdata
Blissterm : enhanced web shell
Complete set of widgets and helpers to build advanced applications
BEC Widgets
BEC Designer, to quickly build applications with BEC widgets
Enable developers or power users to make their own UI with reusable components, connected to the control system
General purpose applications, i.e
beamline alignment
BEC dock areas brings better User Experience, allowing users to organize widgets as they want
Both systems have Writers as external processes, taking data and metadata from acquisition and writing Nexus compliant files
ESRF Nexus flavour is supposed to be compatible with the European consensus (ALBA, DESY, MAX IV, SOLEIL...)
BLISS does not implement Application Definitions yet
The file structure is unified at whole facility level - conversion to other formats can happen if absolutely necessary
BEC file structure can be adapted thanks to plugins
Current SWMR (Single Writer Multiple Reader) mode has shortcomings
HDF5 is best to archive data - it is not well suited to read while writing
Writers should lock the files they write, readers should disable locking
Users can interact with the ESRF Data Portal directly from the BLISS command line
Proposal
Datasets
Metadata
Gallery
Tape interface
newcollection("sample1")
IH-LS-3167: elemental distributions in microalgae
BLISS commands to submit comments, plots, execution output, logs
elog_add("...")
Automatic notifications from the control system
(in case of errors, beamline events...)
Manually editable from the Data Portal
searchable
The Scilog API can be invoked to push to the Electronic Logbook
(no high-level command from shell or automatic mechanism yet)
SciCat integration can be made similar to SwissFEL, automatic archival after experiment
Processing data is hard and takes time !
What processing do I need to do?
Where is my data ?
What software do I need to install? And how ?
There is too much data!
I will never be able to process it all !
Oh god, I forgot to apply the mask !
The software is not working and the PhD/post-doc who wrote it left !
How to improve data processing experience, and how to apply processing as soon as possible?
i.e, to go from this...
to this:
Acquisition control
Execute workflow on
Tasks can be rearranged or reused in other workflows without deep knowledge of the task content
Upload result to data portal
Persist result for further analysis
Visualization, feedback
Workflows are data processing pipelines composed of several steps (tasks)
EWOKS project : Esrf WOrKflowS
Raw parameter space
Workflow based on xraylarch
Parameter space in which scientific decisions are made
EXAFS visualization
Live fitting of data using LMFIT
Plugins for BEC DAP can be written to do some more advanced processing
Perspectives
In which areas both BEC and BLISS could benefit each other ?
Where is it worth collaborating ? "Return on investment"
What would be beneficial for the control system users ?
relies on blissdata to publish acquisition data to Redis
blissdata is a separate package with limited dependencies, easy to integrate in any Python project
Blissdata publishes data (producer)
Blissdata can also retrieve previously published data (consumers)
Support technology:
+ extensions RedisJSON, RedisSearch
Blissdata defines a model to represent scans, and provides acquisition streams to push data
For big data (mainly 2D), only references are published
1. Can be shipped with the event:
0D, 1D, small 2D... are within the Redis stream
2. Data is too large, or data is stored by acquisition in its own file:
JSON events are emitted, need a Blissdata plugin to reference (and de-reference) data
Retrieving data
2 cases when pushing data
ESRF relies on Blissdata to get access to data from acquisition for all its sub-systems:
archiving, display, processing...
There are on-going initiatives at ALBA and DESY to bring Blissdata to their existing control system
Even some attempts converting Bluesky documents to Blissdata model
Device Server
Scan Server
blissdata
PyMca:
A tool designed to assist with XRF data analysis and beyond.
Publishing BEC scans with blissdata would give access to ESRF HDF5 Writer, display and processing tools
Ending remarks
Through the eyes of a visitor...
French political thinker from
"Age of Enlightenment"
Fictional letters exchanged between Persian travelers and their friends to offer a satirical and critical perspective on French society, politics, and culture, exposing its contradictions and absurdities through the eyes of outsiders.
Through the eyes of a visitor...
Absence of dedicated Product Owner for BEC
Product Owner roles:
Through the eyes of a visitor...
Lack of Unified 2D detector control software:
a challenge for integration
Through the eyes of a visitor...
Absence of a dedicated Integrator role:
a coordination gap
Through the eyes of a visitor...
Technical responsibilities of Beamline Scientists
disclaimer: gut feeling, after 20 years at ESRF
Conclusion
PSI is a fantastic workplace, very stimulating environment
I am very grateful to have had the opportunity to participate to the development of BEC, and to have worked with such talented developers and committed professionals
Most features are there, but there is still a lot of work to do ; a Product Owner would be beneficial to join the team
Small development teams, existing software: let's mutualize data handling, visualization, processing, and archiving tools ! At least aim for interoperability to better serve users community