Repository navigation
Investigate core added-mass Transport Delay under published ode45 steps #599
Description
Observed core behavior
The pinned WEC-Sim core library at 0753b2e47f2457c078751dcfe5d251d1767b80ab supplies the block linked into both published Nonlinear_Hydro/ode45 ellipsoid cases. In local MATLAB R2025b, get_param reports:
ReferenceBlock:WECSim_Lib_Body_Elements/Rigid Body/Hydrodynamic Body/Transport DelayLinkStatus:implicitDelayTime:10e-8s (1e-7 s)
The published ode45 model has MaxStep=0.05 s. The solver step is therefore 500,000 times the delay. MathWorks documents that Transport Delay extrapolates when the delay is smaller than the step and can produce inaccurate results.
Paired evidence
With identical pinned wave inputs, changing MATLAB simu.dt from 0.05 to 0.005 s changes the full 150 s source heave by 17.09 mm for Regular and 17.92 mm for RegularCIC. Separate MaxStep-only and nonlinear-force-clock arms isolate substantial sensitivity to the source numerical clocks. Independent physical Python is within 1.85 and 2.02 mm of the refined source, but 18.94 and 19.93 mm from the published source. On all 3,001 published Regular output states, the independently reconstructed mesh/BEM right-hand side using the logged added-mass feedback matches source acceleration within 5e-13 m/s²; the logged feedback follows the two-sample delay law within 2.1e-8 N. See the parity ledger and PR #597.
This is evidence of numerical step sensitivity in a core added-mass loop, not proof that a particular replacement scheme is correct. Both published ellipsoid cases remain qualified, and no badge count changes.
Follow-up
Determine whether the core delay should be replaced by an implicit added-mass mass solve or another numerically convergent loop-breaking method. Compare corrected full-duration trajectories across solver and nonlinear-force clocks before proposing a WEC-Sim upstream change. Do not adjust Python's physical default just to match this coarse-step artifact.
Activity
cmccomb commentedon Oct 24, 2026
The heave-only added-mass loop experiment in PR #658 is now merged into this Python repository as
d2b48172; its pinned-source jobs and full Python CI passed. It uses disposable copies of the pinned MATLAB inputs and core, leaving the upstream repositories unchanged.The derived mass shift makes the active delayed heave force effectively zero while preserving effective heave mass. Over the full 150 s, corrected source 0.05 versus 0.005 s still changes heave by 21.268 mm (Regular) and 21.414 mm (RegularCIC). Independent physical Python versus corrected 0.05 s differs by 23.525/23.770 mm, beyond the retained 3/3.5 mm physical limits; Python versus corrected 0.005 s differs by 2.265/2.378 mm and passes its refined gate. Thus removing this delay alone does not stabilize the published 50 ms numerical clocks or close either original input.
The added fixture, regeneration workflow, positive refined test, and strict expected failures preserve these findings in-repo. The separate full-clock source-convergence work remains in progress. Issue #599, both qualified cases, and the original physical closeout gate remain open.
cmccomb commentedon Oct 24, 2026
PR #655 is merged. It archives and regenerates full-duration R2025b source screens for Regular and RegularCIC at 0.005, 0.0025, 0.00125, and 0.000625 s physical steps, plus independent public Python runs. The exact-head MATLAB convergence, output-grid A/B, and six-job Python workflows passed; fresh source histories, settings, BEM HDF5 data, and STL agree with the committed archive. Final source signed-work changes are 0.069817% and 0.073934%; direct Python/source work gaps are 0.069727% and 0.073878%. The finest source uses 0.005 s output with 0.000625 s physical clocks, so this is a derived reference. The unchanged published 0.05 s input still fails the retained strict physical gate. This issue remains open for that original-input numerical path; #624 counts do not change from #655.