0058 — InternalCableWithAttractor::AddElementForce is non-const and never overrides the const base

ID	0058
Class	BUG
Severity	2
Status	ready
Models	Seine/Cable
Found	2026-09-25, while writing the FISH-0017 example
Decision needed	Should the net-bin element force in InternalCableWithAttractor::AddElementForce take effect (make it override), or is it dead code to delete?

Evidence

src/seine/InternalCableWithAttractor.h:42-49 declares

void AddElementForce(int cableElement, const double adPosA[3], ..., double dT);

without const. The base it means to override, fhsim_marine_elements 3.2.0 cable/subroutines/InternalCable.h:299-306 and InternalCableWithBottomContact.h:29, is

virtual void AddElementForce(int cableElement, ..., double dT) const;

The signatures differ in const, so the derived function hides the base name instead of overriding it. Every call site is in the base, through the virtual (InternalCable::AddEndForcesAndInertia, InternalCable.cpp:667-671, and the internal-node loop), so they all reach InternalCableWithBottomContact::AddElementForce. The body at src/seine/InternalCableWithAttractor.cpp:113-137 never runs: its second AddEndForces call, with the node velocity set to zero for ends inside the attractor (m_attractor->IsActive), has no effect on any simulation.

Effect

A Seine/Cable element with an end inside the warp attractor (the vessel's net bin) gets the same hydrodynamic force as anywhere else. Whatever the net-bin treatment was meant to do (the body calls AddEndForces a second time on top of the base call, with a still-water velocity and a literal 1025.0 density, so it would also double the element force) is absent today. The FISH-0017 baseline tests/in/SeineCable/ freezes today's behaviour.

Possible fix

1. Delete the function and its declaration: no behaviour change, no baseline moves.
2. Make it override (... double dT) const override;), after deciding whether the second AddEndForces call should replace the base call rather than add to it. This changes the warp forces near the vessel and moves the SeineCable baseline.

Adding override to the declaration as it stands makes the compiler report the mismatch.

Test that would prove it

With option 2, a SeineCable variant whose warp attractor radius covers the first warp element: the element's end force changes against the option-1 baseline. With option 1, nothing changes and the SeineCable baseline still passes.

Risk

Option 1 none. Option 2 changes Seine/Cable results, and the literal 1025.0 ignores FluidRho.

Owner decision 2026-09-25

Karl-Johan Reite: make InternalCableWithAttractor::AddElementForce const ... override so the net-bin element force runs. Re-record the SeineCable baseline; CHANGELOG entry saying Seine/Cable results change.