
ID	0017
Class	ARCHITECTURE
Severity	1
Status	blocked
Models	RbCable/Ring
Found	2026-09-15 audit (`e3f3107`)
Decision needed	Are variable-width connectors still wanted, and is the added-mass hack a public parameter, a renamed one, or one to remove?

Documentation part fixed

src/RMCable/Ring.h now documents the connector output range as ConnectorPos<1>…ConnectorPos<NumConnectors>, lists the ConnectorVel output family, gives the fixed width 3 for the Force, ConnectorPos and ConnectorVel ports, gives CentrePosInit its real width of 3 and NumInputsPerConnector its real default of 1 (all from src/RMCable/Ring.cpp:32-33, :47, :99-101). Two things remain.

Evidence

NumInputsPerConnector is read at src/RMCable/Ring.cpp:47 with default 1 and never used; its only other appearance is the commented-out line :95 (// int numExtlForces = m_numConnectors*m_numInputsPerConnector;). The row in Ring.h still describes it as the connector width, and the AdditionalConnectors row still says it "needs to be set".
Cm_IsAddedMassHack is read at src/RMCable/Ring.cpp:30 (default 0.0) and feeds m_AddMassHack at :56, so it changes the element mass and inertia; it appears in no @addoption row.

Possible fix

(a) For NumInputsPerConnector: implement it (make the connector port width follow it, which is what :95 was reaching for), or remove the parameter, the member (src/RMCable/Ring.h) and its documentation row.
(b) For Cm_IsAddedMassHack: document it as a parameter, or rename/remove it.

Owner question, open

was variable-width connector input intended, and is it still wanted? And is the added-mass hack meant to be a public parameter? Its name marks it as a stopgap, and documenting it makes it part of the interface. Removing a parameter that an existing input file sets is harmless for NumInputsPerConnector (it is ignored either way) but not for Cm_IsAddedMassHack, which changes results.

Test that would prove it

A test asserting the exact port-name set of a RbCable/Ring configured with NumConnectors = 2, plus an assertion that CentrePosInit = "1,2,3" lands in all three components of m_centrePosInit.

Risk

Implementing the width changes the public port surface; removing NumInputsPerConnector is safe but final; anything done to Cm_IsAddedMassHack is a results change for inputs that set it.

Why not solved (fix pass 2026-09-15)

Partially solved. Commit 147bfb9 in fhsim_marine_elements fixed the documentation in Ring.h: the connector output range now ends at ConnectorPos<NumConnectors>, the ConnectorVel family is listed, the connector port widths are given as 3, CentrePosInit has width 3 and NumInputsPerConnector its real default of 1; the OpenWiki page was corrected to match. Two things remain and both need the owner. NumInputsPerConnector is read at Ring.cpp:47 and never used (its only other appearance is a commented-out line), so the choice is between implementing variable-width connector input and removing the parameter. Cm_IsAddedMassHack is read at Ring.cpp:30 and changes element mass and inertia but appears in no @addoption row; documenting it would make a stopgap part of the public interface, and removing it changes results for any input that sets it. Smallest owner decision: whether variable-width connectors are still wanted, and whether the added-mass hack is a public parameter, a renamed one, or one to remove.