Migrate to uv, fix bugs and deprecated scipy APIs

[TAJD]

Summary

• Migrate build system from setup.py + requirements.txt to pyproject.toml (hatchling) + uv.lock
• Modernize CI: test workflow uses astral-sh/setup-uv with Python 3.11/3.12 matrix; publish workflow uses uv build + PyPI trusted publishers (OIDC)
• Fix string raise bug — raise "string" is invalid Python 3, replaced with RuntimeError (fixes if not self.upToDate in run does not work since the excpetion is not derived from a BaseException #46)
• Fix README install instructions — incorrect pip install requirements.txt replaced with pip install -e ".[dev]" and uv sync (fixes fix incorrect dependency install instructions in readme #43)
• Replace deprecated scipy APIs — interp1d → make_interp_spline, interp2d → RegularGridInterpolator (addresses Update dependencies to latest versions #36)
• Add comprehensive docstrings — NumPy-style docstrings for all classes: Sail, Jib, Kite, Yacht, Keel, Rudder, Bulb, AeroMod, HydroMod (addresses Add documentation on parameters to the documentation #53)
• Expand Sphinx documentation — autodoc now covers all 6 source modules, not just VPPMod
• Lint cleanup — ruff auto-fix for import sorting and whitespace across src/ and tests/
• Add Daring 5.5m yacht — yacht definition, Streamlit preset, and baseline performance results
• Iterative depowering — sail flattening and reefing with configurable heel limit (phi_max), making flat and RED tuneable parameters
• Expose depowering in Streamlit UI — new Flat & RED polar plots and expandable data table after running the VPP
• Input validation and error handling — guard against empty TWS/TWA ranges and API errors in Streamlit UI
• Move flask and streamlit to base dependencies — required for Streamlit Cloud deployment

Issues addressed

Issue	Action
#53 - Document parameters	Fixed — full docstrings on all classes, especially Jib (I, J, LPG, HBI)
#46 - String raise bug	Fixed
#43 - Incorrect pip install	Fixed
#36 - Update dependencies	Fixed (unpinned lower bounds + uv.lock)
#25 - Python package release	Unblocked (proper pyproject.toml + publish workflow)
#24 - Roadmap (docs + CI)	Addressed (docstrings, Sphinx expansion, CI, ruff)
#21 - Refactor into package	Partially addressed (proper packaging)

Supersedes PR #51 and PR #41.

Test plan

• All tests pass (including validation and error handling tests)
• runVPP.py runs end-to-end producing correct output
• No scipy deprecation warnings
• Streamlit UI displays depowering (Flat & RED) polar plots and data table
• Verify CI passes on GitHub Actions
• Verify publish workflow (owner needs to configure PyPI trusted publishers)
• Build Sphinx docs and verify all modules render correctly

Notes

• requires-python set to >=3.11 (CI tests 3.11-3.12)
• flask and streamlit moved to base dependencies (needed for Streamlit Cloud)
• ruff replaces black + isort (faster, single tool)

🤖 Generated with Claude Code

[TAJD]

@marinlauber - was able to get this one off, please lmk what you think, I think it covers main feedback points plus upgrades CI

I'm going to probably do some hobby modelling of the Daring yacht class (one design in cowes) to model the impact of potential sail changes but hard to find time ofc

[TAJD]

Short Keel vs Fin Keel — Physics Differences for Daring VPP

The Daring has a short/integrated keel, not a modern separated fin. The current Keel class assumes a trapezoidal fin, which mis-models the Daring in four key ways:

1. Geometry

A short keel is defined by its fore-aft length along the hull and depth below the canoe body, not root/tip chord of a separated trapezoid. Aspect ratio is much lower (0.2–0.5 vs 1.0–2.0 for a fin).

2. Lift Efficiency

At very low aspect ratio, the Prandtl correction (2π / (1 + 0.5·AR)) over-predicts lift. Low-AR foils follow the Jones formula: dCL/dα = π·AR/2 — lift-curve slope is proportional to AR, not corrected from 2π. This means a short keel generates much less side force per degree of leeway, so the boat needs more leeway to balance sail forces.

3. Form Drag

Higher than a fin (cof ~1.4–1.6 vs 1.31) because the keel–hull junction runs along a long chord, and the sections are thicker relative to their depth.

4. Residuary Resistance

A short keel's wave-making is largely captured by the hull's ORC resistance surface (since it's integrated with the hull). The separate appendage residuary term from rrk.dat (calibrated for discrete fins) should be reduced or zero for a short keel.

Impact

These differences compound — the Daring model currently over-predicts side force (too little leeway), under-predicts form drag, and may double-count residuary resistance. A ShortKeel appendage subclass is needed to capture these effects properly.

[marinlauber]

@TAJD Lots of great stuff going on here, thanks!
From what I get, it also sorts things from #51? Should I merge 51 first and then we check what's going on here?

[TAJD]

It does - I think merge in #51 and then I'll rebase can continue

[marinlauber]

@TAJD I'm going through those slowly, as there is a lot of stuff. I'm testing as I go, and everything looks nice.

[TAJD]

Good to hear! Any concerns just shout, as you can see I'm using Claude and whilst I'm adding tests and thinking through the logic I'm not checking all the code line by line yet.