
ID	0010
Class	KNOWN-LIMITATION
Severity	1
Status	blocked
Models	RbCable/RBCable, RbCable/Cable
Found	2026-09-15 audit (`e3f3107`)
Decision needed	Should `RBCable` expose a force at end A, and should the mixed `forceA`/`ForceA` case across the RbCable group be unified, in which direction?

Documentation part fixed

src/RMCable/Cable6Dof.h now documents forceA/forceB and src/RMCable/RBCable.h documents only forceB, matching what the code registers (src/RMCable/Cable6Dof.cpp:28-29, src/RMCable/RBCable.cpp:24). What remains is two owner questions.

Evidence

src/RMCable/RBCable.cpp:24 registers one output port:

creator->AddOutport("forceB", 3, PORT_FUNCTION(RBCable::forceB));

There is no forceA in RBCable.cpp under any spelling.

The earlier version of this item cited src/RMCable/Cable.cpp:96-100 as registering both cases of the port names as aliases. That is not what is at HEAD: those lines are an #ifdef RBCABLE_CLASSIC_INTERFACE choice between forceA/forceB and ForceA/ForceB, and the macro is not defined anywhere in the build (see 0025). So RbCable/Cable exposes ForceA/ForceB while RbCable/6DofCable and RbCable/RBCable expose forceA/forceB.

Possible fix

(a) Nothing further; the documentation now states the code.
(b) Implement and register forceA on RBCable.
(c) Unify the case across the group (a rename, or registering both spellings), which changes the public port surface.

Owner question, open

two. First, is RBCable's missing forceA an omission or by design — does the model have a well-defined force at end A to report? Second, is the mixed case across the RbCable group acceptable, or should it be unified — and if so, in which direction? Both change the port surface and cannot be decided from the code.

Test that would prove it

A test asserting the exact output-port name set of each class pins whichever answer is chosen.

Risk

None for (a). Option (b) adds a computed quantity and must be checked against the constraint solver's sign convention. Option (c) is a compatibility change for existing input files.

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

Partially solved. Commit 6cf95d6 in fhsim_marine_elements fixed the documentation: Cable6Dof.h now documents forceA/forceB and RBCable.h documents only forceB, matching what Cable6Dof.cpp:28-29 and RBCable.cpp:24 register. The fix pass also found that the audit's evidence that RMCable/Cable.cpp:96-100 registers both spellings as aliases is wrong at HEAD: those lines are an #ifdef RBCABLE_CLASSIC_INTERFACE choice, and the macro is defined nowhere (see MARE-0025), so RbCable/Cable exposes ForceA/ForceB while the other two classes expose forceA/forceB. The item text above has been rewritten accordingly. What remains are two owner questions: whether RBCable should expose a force at end A at all, and whether the mixed case across the group should be unified and in which direction. Both change the public port surface and cannot be decided from the code.