
ID	0121
Class	TEST
Severity	1
Status	blocked

Models: Net/NetStructureWithConstraints

Found: 2026-09-27, one failure observed on the integration branch and reported to the lead; re-run and filed by the lead's merge agent at f370c09

Decision needed: Needs info (the tracker has no needs-info status): the log, commit and conditions (ctest -j, load, OMP_NUM_THREADS) of the observed failure. Without a reproduction there is nothing to fix.

Evidence

Observed once (reported, log not attached): ExpectIdenticalOutput(defaultRun, run100) in tests/NetStructureWithConstraints_Test.cpp:171-184 failed on angularvel4_2, sample 9: 0.0002699517 vs 0.000269952. The test runs the same model twice (the default SolverFrequencyCoefficient and an explicit 100) and requires bit-identical output.

Not reproduced at f370c09: 10 consecutive runs of test_fhsim_marine_elements <tests> 0 4 n . --gtest_filter=SimObject.NetStructureWithConstraints_SolverFrequency from build/no_vis/Release/playpen/bin all passed (0/10 failures), as did the full ctest run.

Unconfirmed hypothesis: the class's node loops are #pragma omp parallel for (src/net/NetStructureWithConstraints.cpp, see MARE-0119), and unlike NetStructureWithConstraints_CablesThreadIndependent and the MARE-0114 wake tests this test does not pin the OpenMP team; any order-dependent summation under a varying team or schedule would change the last bits. MARE-0059's thread-independence test covers the cable forces only.

Effect

A spurious red ctest, if it recurs.

Possible fix

None until reproduced. If it is thread-order dependent, either find the order-dependent sum in the class (a real determinism defect) or pin one thread in the test as the wake tests do.

Test that would prove it

A loop of the test (e.g. 100 runs, also under ctest -j and with OMP_NUM_THREADS varied) that fails before a change and never after.

Risk

None from filing; a fix that only pins threads would hide a real determinism defect.

Progress (2026-09-30)

Not reproduced: 15 of 15 consecutive runs of SimObject.NetStructureWithConstraints_SolverFrequency pass, also with OMP_NUM_THREADS=8. The suspected cause, the solver's hardware_concurrency()-sized thread pool whose results were not reproducible (MARE-0075, MARE-0317), is gone since Net/NetStructureWithConstraints runs its solver inline by default (MARE-0317). Still no failure log, so the item stays open for one: if a failure is seen, record the log, commit and ctest -j load.