Common working group topic for everyone on Tuesday morning
Description
The working group session will be dedicated to trying out the existing use cases and examples in order to provide their feedback.
Input
- pyaml / accml examples
- pyaml / accml documentation
- specification documents
- resources on pyAML GitHub
Objectives and deliverables
- 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)
Working group: use case implementation
Description
The main idea of this working group is to try implementing some new use case (for example, a chromaticity tuning tool).
Input
- pyaml/accml examples
- pyaml/accml documentation
- specification documents
Objectives and deliverables
- Discuss among yourselves what kind of measurement / tuning tool is already possible to do with the existing code base
- Make a GitHub issue(s) describing what you want to implement
- Make a short description of the measurement in the specification document
- A working measurement script / tuning tool for a selected use case(s),
- **Draft pull request** with a new measurement/tuning tool (partially) implemented
- Short presentation (5 - 10 minutes) on the work done so far
- Feedback on the experience of implementing a use case (GitHub discussion)
Working group: set and 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
Working group: Metadata
Description
Currently, pyAML documentation and code do not define a clear format to store measurement data and metadata. Metadata is also not generated automatically. The working group should brainstorm what type of data is necessary to store and come up with a first technical solution to this problem.
**Input**
- MML experience
- Experience with other codes
- Operational experience at different facilities
Objectives and deliverables
- Define measurement data format(s), associated metadata
- GitHub discussion/issue on the metadata format
- GitHub discussion/issue on the data storage
- Update of pyAML documentation
- An example script demonstrating data storage and metadata generation
Working group: Unit conversion
Description
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
Working group: Measurement standard
Description
The primary objective of the working group is to establish a pyAML standard for performing measurements. In general, there are two ways to do measurements: simple measurement scripts and a more generic way for standard measurements. The generic way can allow for the reuse of existing code snippets in a transparent way and orchestrate a complex measurement. Both ways exist in the PAMILA toy project of Y.Hidaka, including OPTIONAL compatibility with BlueSky. The working group can brainstorm how to adapt this solution or come up with a different one.
Input
- User interface specification document (Chapter 6)
- Implementation in the PAMILA code (https://github.com/NSLS2/pamila)
Objectives and deliverables
- Update on the documentation relating to generic measurements
- Proposal of a generic way to do measurements (preferably in the form
of GitHub discussions)
- A code example with one of the already existing use cases done in
both ways
- Short presentation (~10 minutes) elaborating on the points above
Working group: ecosystem approach to packaging pyAML
Description
One potential future development path for pyAML is to build a software ecosystem. The idea is that instead of having a single package having a set of compatible packages where facilities can choose which ones they want to use or even develop their own package to add to the ecosystem. The working group should brainstorm how such an ecosystem could look like and come up with a suggestion for the next steps in case the collaboration decides to go in this direction.
Input
- How other research communities have structured their ecosystems
- The existing packages in the pyAML GitHub organisation
- Experience of what might be facility, control system, accelerator type etc specific where different facilities want/need different implementations or functionality
Objectives and deliverables
- A figure showing the different parts in the ecosystem and how they are connected.
- A suggestion for how the existing packages can be restructured to facilitate the ecosystem development. What needs to be in a common core, what needs to be more modular, what can be separated out into separate repositories etc.
- Initial description of the interfaces between packages and an example showing how that can be implemented.
Working group: CI/CD and tests
Description (this one is written by AI:) be careful)
The CI/CD and Testing working group will focus on improving the continuous integration/continuous deployment (CI/CD) pipeline and testing framework. The goal is to ensure the codebase is reliable, maintainable, and easy to contribute to by automating testing, linting, and deployment processes.
Input:
- Existing
pyaml/accmlCI/CD pipelines (GitHub Actions, GitLab CI, etc.) - Current test suite (unit tests, integration tests, etc.)
- Documentation on testing practices
- Examples of CI/CD pipelines from other scientific projects
Objectives and Deliverables
-
Review and Improve the CI/CD Pipeline
- Assess the current CI/CD setup (e.g., GitHub Actions).
- Identify bottlenecks, missing tests, or inefficiencies.
- Propose improvements.
-
Enhance the Testing Framework
- Review the existing test suite.
- Identify gaps in test coverage (e.g., edge cases, new features).
- Propose new tests or improvements to existing ones.
-
Automate Code Quality Checks
- Integrate linting (e.g.,
flake8,black,pylint) into the CI pipeline. - Ensure consistent code formatting and style.
- Integrate linting (e.g.,
-
Document the CI/CD and Testing Process
- Update the documentation to explain how to run tests locally.
- Document how the CI/CD pipeline works and how to contribute.
-
GitHub Discussions/Issues
- Open a GitHub discussion or issue summarizing findings and proposals.
- Create issues for specific improvements (e.g., "Add integration tests for X").
-
Draft Pull Request (PR)
- Implement at least one improvement (e.g., new test, CI workflow update).
- Ensure the PR follows the project’s contribution guidelines.
-
Short Presentation (~10 minutes)
- Summarize the working group’s findings and proposals.
- Highlight key improvements and next steps.
