Add CU HXR ZFEL virtual accelerator backend - #56
Open
hong274SLAC wants to merge 11 commits into
Open
Conversation
Add the ZFEL LUME backend, HXR undulator mapping, and CU HXR scalar model wrapper.
Add dedicated CU HXR ZFEL runner configuration and machine-style PV mapping. Lazy-load model backends so optional dependencies are only imported when selected.
Add unit tests for HXR-to-ZFEL mapping, ZFEL model behavior, CU HXR scalar controls, and runner PV configuration.
Add the ZFEL optional dependency pinned to the NumPy-compatible fork commit and document installation and CU HXR ZFEL runner usage.
Apply repository formatting, end-of-file, and Ruff lint fixes to the ZFEL backend and tests.
Refactor the ZFEL physics layer into a plain backend and keep the CU HXR wrapper as the single LUMEModel. Also standardize KAct/DSKAct naming.
Added VA model-evaluation synchronization
| config["update_rate"] = update_rate | ||
|
|
||
|
|
||
| for cell in HXR_CELLS: |
Collaborator
There was a problem hiding this comment.
these PV definitions should be specified in the LUMEModel subclass in addition to the variables that are already there. That way you can still use the real PV names to get() and set() stuff via the python interface
|
|
||
| # Run the model | ||
| runner = Runner(model) | ||
| if args.model != "cu_hxr_zfel": |
Collaborator
There was a problem hiding this comment.
this carve out is not ideal, we should be able to have a single location where the runner class is defined
| get_cu_hxr_zfel_runner, | ||
| ) | ||
|
|
||
| runner = get_cu_hxr_zfel_runner(Runner) |
Collaborator
There was a problem hiding this comment.
should return the model object here, not the runner object
return the zfel model from cu_hxr_zfel and construct runner in the shared runners path. preserve the mode-specific PV config and machine-style PV names
add machine PV aliases to ZFELPVModel as suggested, while keeping runners construction same as before
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Added the ZFEL backend model and HXR undulator mapping.
Added a CU HXR ZFEL model with scalar KAct/DSKAct controls.
Added machine-style virtual PV mappings, including:
Added cu_hxr_zfel as a selectable backend in the existing virtual-accelerator runner.
Use lazy backend imports so optional BMAD/PyTao dependencies are only required when those backends are selected.
Added unit tests for the HXR mapping, ZFEL model behavior, scalar control wrapper, and runner configuration.
Added ZFEL as an optional dependency and document installation/usage.
Related PR
Test
ZFEL model initialization and reset.
HXR K/DSK mapping to the ZFEL undulator profile.
Changes in KAct propagate through ZFEL and produce a corresponding change in pulse energy.
Machine-style CA PV read/write through LUME-PVA.
cu_hxr_zfel can run without importing BMAD/PyTao.
dependency
The ZFEL dependency is currently pinned to a compatibility-fix commit in hong274SLAC/zfel. Current NumPy versions reject one-element arrays assigned to scalar particle-array elements in the upstream ZFEL particle initialization.
A small upstream compatibility fix has been submitted separately as slaclab/zfel PR #10. Once that fix is available upstream, the dependency can be switched back to the main slaclab/zfel repository.