[deferred] Guardian / lock-state abort, and full filter-module snapshot/restore
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 15/100
Research direction
Review src/system_ident/safety.py, especially Watchdog and snapshot_state/restore_state, then read docs/tutorial/safety-and-ops.qmd and the Phase-C section of notes/strategic-roadmap-2026-07-draft.md. Check pyproject.toml for the missing hardware dependencies and resolve the open question about filter history. This is ready only after Component 1, plan review, and explicit operator sign-off define the permitted writes and restore behavior.
Written by the indexing model from the issue text.
Description
Component 2 — deferred. Blocked on Component 1 and on operator sign-off.
Guardian / lock-state abort
Add a lock-state / Guardian hook on top of the existing Watchdog
(src/system_ident/safety.py:59), so a lock loss aborts the campaign through the same idempotent
handoff rather than continuing to inject into a changed plant. Today the watchdog keys only on physical
limits — actuator saturation and per-DoF output RMS — by design
(docs/tutorial/safety-and-ops.qmd), which is right for what it covers but says nothing about the
interferometer's state.
Full snapshot / restore
Component 1 implements snapshot_state / restore_state honestly but minimally: live-excitation state
only, with the docstring stating that filter-module switch/gain/offset state is not captured.
Completing it means capturing and restoring the filter-module state — and that is a real escalation:
- It needs
ezca/pyepics, absent frompyproject.toml:21. - It means writing to the front end, so it needs explicit operator sign-off on exactly what may be
written. - Open question from
notes/strategic-roadmap-2026-07-draft.md§Phase-C: must the snapshot capture
filter-module history (i.e. isfm_clear_historyrequired), not just switch positions and gains?
On hardware restore_state is the "hand control back to the existing damping loops" step
(src/system_ident/safety.py:9), so getting it wrong is a safety issue, not a convenience one.
Campaign: CDS hardware backend · branch feat/cds-hardware-backend
· spec · plan · handoff
Code is deferred until the plan and issues have been reviewed.
- Dominant language
- Python
- Stars
- 0
- Forks
- 1
- PR merge metrics
- No merged PRs in 30d
Getting set up
This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from CaltechExperimentalGravity/system_ident
-
Difficulty 4/5 3-5 days Newbie friendliness 35/100
-
enhancement
Difficulty 5/5 Over a week Newbie friendliness 15/100
-
enhancement
Difficulty 5/5 Over a week Newbie friendliness 35/100
-
enhancement
Difficulty 5/5 Over a week Newbie friendliness 35/100
-
enhancement
Difficulty 5/5 Over a week Newbie friendliness 25/100
All issues in CaltechExperimentalGravity/system_ident
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
Arekkazu/sgpmp-backend#744 ·
Maintainers usually reply within 1 day
-
agent/reviewer
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
projectbluefin/utah-packages#634 ·
Maintainers usually reply within 1 day
-
enhancement good first issue help wanted
Difficulty 2/5 1-2 days Newbie friendliness 78/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
home-assistant/core#188613 ·
Maintainers usually reply within 1 day
-
WebsiteOpengood first issue
Difficulty 2/5 1-3 hours Newbie friendliness 91/100
TanbirRamim/open-source-radar#314 ·
Maintainers usually reply within 1 day