Stage H: py3.9 / numpy 1.22 / scipy 1.8 / control 0.9 compatibility + a py3.9 CI leg
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 42/100
Research direction
Start with the named CDS-relevant test subset and the compatibility sites in src/system_ident/darm_actuation.py, closed_loop_id.py, mimo_loop.py, mimo_plant.py, sos_closed.py, and backends/darm_adapter.py. Check .github/workflows/ci.yml and tests/test_mimo.py, then verify the subset on Python 3.9 and control 0.10.2; done means the compatibility fixes, import-order issue, and Python 3.9 CI leg are covered.
Written by the indexing model from the issue text.
Description
Stage H (spec §8). Deliberately not on the critical path — see the measurement below.
The hardware path is pinned to the site CDS baseline (python 3.9.13 / numpy 1.22.4 / scipy 1.8.1 /
control 0.9.2 / slycot 0.4.0.0) because the working environment is a clone of the site CDS environment
and the compiled extensions are built against that ABI.
The decisive measurement
The CDS-relevant half of this repo already passes on that baseline. test_step5_safety,
test_step7_loop, test_step8_cli, test_periodic_measurement, test_rtsfreerun_backend,
test_excitation, test_step4_twin, test_step6_estimator, test_step12_ml_estimator,
test_resolution → 61 passed / 1 skipped.
The full suite does not (250 passed / 35 failed / 12 skipped / 4 errors), but every failure is in the
DARM / MIMO / SOS / arcade / playground half, which this campaign does not touch. So the deployment gate is
that named subset, not "the suite passes".
Four root causes — and two need no shim
| break | resolution | sites |
|---|---|---|
FrequencyResponseData.frdata absent before control 0.10.2 (it was .fresp) |
the one genuine shim — a _frd(sys, w) helper trying frdata then fresp (prefer frdata; .fresp emits FutureWarning on 0.10) |
src/system_ident/darm_actuation.py:144, src/system_ident/darm_actuation.py:208, src/system_ident/closed_loop_id.py:37 + 4 test sites → 7 calls collapse to 1 |
control.tf2ss(StateSpace) rejected on 0.9.2, accepted on 0.10 |
control.ss(x) — works on both |
src/system_ident/mimo_loop.py:31, src/system_ident/mimo_plant.py:40, src/system_ident/mimo_plant.py:72, src/system_ident/sos_closed.py:70, src/system_ident/darm_actuation.py:124, tests/test_mimo.py:236 — 11 failures |
np.trapezoid is numpy ≥ 2 only |
from scipy.integrate import trapezoid (scipy ≥ 1.6) — already this repo's src/ convention (src/system_ident/design/pintelon.py:18) |
zero src/ sites; tests/test_arcade.py:50, tests/test_playground.py, experiments/realistic/*.py, docs/*_reference.py |
plotly absent |
environment, not version | 3 collection errors |
Plus: fix the order-dependent circular import at src/system_ident/backends/darm_adapter.py:14
← src/system_ident/darm.py:506 (bottom-imports DARMBackend). Move it into the function that needs
it or a TYPE_CHECKING block. Verified order-dependent, not version-dependent — it reproduces
identically on py3.12, and it will bite whoever first writes import system_ident.backends.darm_adapter
at the top of a script.
Do not
- Raise the floor — impossible, CDS 3.1.2 is py3.9-only.
- Build a general
_compat.py— one three-line helper plus two mechanical renames. Version-conditional
code at 7 sites would drift; a single helper cannot.
Also
After the control.ss rename, run tests/test_mimo.py on control 0.10.2 too, to confirm the
LinearIOSystem vs StateSpace return type does not matter downstream.
CI
Add a py3.9 leg. CI runs 3.12 only (.github/workflows/ci.yml:26) and executes exactly one test
file, so a 3.9 regression is invisible until it fails on deployment.
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
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
conda-forge/conda-forge-bot#7025 ·
Maintainers usually reply within 1 day
-
area:ci
Difficulty 1/5 Under an hour Newbie friendliness 74/100
catincloud-labs/dagster-dex#149 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
home-assistant/core#188424 ·
Maintainers usually reply within 1 day
-
Review backlog (docs-currency): README 'CI run' link lands on a run whose overall badge is cancelledOpenagent/reviewer needs-kind needs-triage
Difficulty 2/5 1-3 hours Newbie friendliness 63/100
projectbluefin/utah#880 · 2 comments ·
Maintainers usually reply within 1 day
-
LSan reports obj_gen leak on post-parse usage() exits (aarch64)Possibly taken A pull request linked to this issue is open or already merged. Open
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
redis/memtier_benchmark#850 ·
Maintainers usually reply within 1 day