
ID	0033
Class	TEST
Severity	1
Status	blocked
Models	Cable/Branched
Found	2026-09-24 test-coverage audit of `f42360e`
Decision needed	MARE-0036/0037 (deferred by owner)

Evidence

Each of the five has exactly one gtest and it asserts only analytic-vs-numeric Jacobian agreement, with no behaviour or regression assertion:

tests/Sphere_Test.cpp — SimObject.Sphere_Jacobian
tests/Cable_Test.cpp — SimObject.Cable_Jacobian
tests/CableBranched_Jacobian_Test.cpp — SimObject.CableBranched_Jacobian (ExpectJacobiansMatch, bypasses TestSpec/RunTest)
tests/CableConnector_Test.cpp — SimObject.CableConnector_Jacobian
tests/TrawlBeam_Test.cpp — SimObject.TrawlBeam_Jacobian

Disk is the one object in this library with both a dedicated Jacobian test and a behavioural regression test (tests/Disk_Test.cpp, .ref/_ref.csv comparison); none of these five has the latter.

Effect

A Jacobian check only confirms that the analytic derivative matches a numeric derivative of whatever OdeFcn/force computation is currently in the tree — it says nothing about whether that computation is itself correct. A sign error in a force magnitude that cancels in its own derivative, for example, would pass every one of these five tests and only show up (if at all) downstream, in a system that happens to notice the wrong force. None of these five objects has a baseline to catch that.

Possible fix

Add a RunTest-based behavioural/regression test per object (a short sim, .ref/_ref.csv comparison), following the Disk_Test.cpp pattern. Because TestSpec defaults jacobianMode to Auto, each new regression scenario also re-checks the object's existing analytic Jacobian at the framework's default tolerance, as already happens incidentally for Disk.

Test that would prove it

A .ref/_ref.csv baseline plus a RunAndCompareRegressionXmlTiming-style test per object.

Risk

None to shipped code; this adds test-only files. A first baseline necessarily freezes whatever behaviour the current code produces, so it protects against future regressions but does not itself confirm today's numbers are correct.

Re-triage (fix pass 2026-09-24)

Re-confirmed at 8a1772d: the five objects still have Jacobian-only tests.

Not done, and why: each fix is a new .ref/_ref.csv regression baseline, which freezes whatever the current code produces. The issue's own Risk paragraph notes that a baseline does not confirm today's numbers; for Cable/Branched it would freeze behaviour affected by the open physics questions MARE-0036 and MARE-0037. Blessing baselines is the model owner's call, so this pass added none. No decision is needed for Sphere, CableConnector and TrawlBeam, which can be baselined whenever the owner is ready to review the numbers. Status stays ready.

Progress (2026-09-25)

Regression baselines for four of the five objects are in (280a002, fd5c401, 1c54ae2, 6b311ff): SimObject.Sphere_Regression, Cable_Regression, CableConnector_Regression and TrawlBeam_Regression, each a .ref/_ref.csv pair under tests/in/<object>/ compared by RunAndCompareRegressionXmlTiming at output_rms_max 1e-8, as the owner decided. They are characterisations: they freeze today's numbers and await the owner's review of the plots in doc/user/baselines/ (Regression baselines), so Status is now blocked and the issue stays open until the owner approves them. Cable/Branched has none; it waits for MARE-0036 and MARE-0037, as decided.

Each fixture was run twice with identical output, and a 1 % change of one force coefficient fails each test.
The Cable baseline skips the Jacobian check (the analytical Jacobian leaves out the drag by design); the other three also check the Jacobian at the default tolerances.
The hand checks found defects that the first baselines froze: Cable/LumpedMass carried twice its weight in water (MARE-0082), and Net/Sphere ignored the current (MARE-0084). Both are fixed, the owner having approved the fixes; Cable_Regression and Sphere_Regression are regenerated after them, and the Sphere fixture now has a 0.5 m/s current. They remain characterisations awaiting the owner's review.

Progress (2026-09-25, owner review)

The owner reviewed and approved the Sphere_Regression, Cable_Regression, CableConnector_Regression and TrawlBeam_Regression plots in doc/user/baselines/ (Regression baselines). Net/Sphere, Cable/LumpedMass, RbCable/CableConnector and TrawlBeam are done; their \xrefitem reviewissue "Review issues" "Review issues" \ref fhsim_marine_elements_issue_0033 annotations are removed from their headers. The issue stays open, as MARE-0028 did with its partial progress, narrowed to the one model still without a baseline: Cable/Branched, whose CableBranched.h keeps the annotation. It waits for MARE-0036 and MARE-0037, whose answers change its numbers, deferred by the owner; Status stays blocked on that decision.