Stokes_Constrained free-slip: the answer is partition-dependent (np2 iso -3.4%, np4 ti +2.8%) — not an environment-sensitive golden

[lmoresi]

Found during the #493 adversarial review: tests/parallel/test_1063_constrained_freeslip_parallel.py fails at np=2 on this macOS/arm64 environment on BOTH pre-#493 development and the #493 branch, with byte-identical iso L2 values across the two builds (0.5982807168536982 vs golden 0.6194547793955; the TI case differs between builds only at 6e-13, i.e. #493 is exonerated). The golden value appears environment- or partition-sensitive rather than wrong-code. Needs: re-derive the golden on CI vs locally, decide whether the assertion should be a cross-build invariant instead of an absolute golden.

Underworld development team with AI support from Claude Code

[lmoresi]

Retitled — the original framing was wrong, and the real finding is more serious.

Re-measured at development @ e475246f: serial reproduces the golden to 2.6e-12 (6.194547793939e-01 vs golden 6.194547793955e-01), so the golden is not environment-sensitive on this machine at all. What varies is the partition:

run	iso	ti
serial	0.6194547793939 (= golden)	passes
np=2	0.5982807168537 (−3.4%)	passes
np=4	0.6187878061677	0.4036468804591 (+2.8%)

A different answer at every rank count is a parallel-correctness defect in Stokes_Constrained, not test hygiene. It belongs with the known constrained-solver parallel-correctness work (#254: partition-dependent [p,λ] gauge, constraint-assembly drift) — plausibly the same root cause, and worth checking against it before treating this as separate.

Reclassified from "pre-existing test-infra chore" to a user-facing correctness issue: anyone running a constrained free-slip model gets a rank-count-dependent answer with no warning.

Underworld development team with AI support from Claude Code

[lmoresi]

Independent confirmation from a different direction: while re-reviewing PR #561, tests/parallel/test_1063_constrained_freeslip_parallel was found failing at np=2 and np=4 with 3.4% partition dependence in the multiplier free-slip path — the same magnitude this issue records for the iso case at np=2 (0.5983 vs 0.6195, −3.4%). Two different investigations reaching the same number is good evidence it is one defect in Stokes_Constrained's parallel path rather than a test artefact.

Also relevant to reproducing it: those parallel test files run at no rank count in CI (scripts/test.sh --p N runs only tests/parallel/test_075*py; the test_10*py line is commented out), so this has never been caught by CI. PR #561 fixes that line, which will make this failure visible on every run — worth being ready for.

[lmoresi]

Does not reproduce. tests/parallel/test_1063_constrained_freeslip_parallel.py passes today at np=1, 2 and 4 — both test_constrained_freeslip_partition_independent[iso] and [ti], which are the exact assertions reported failing here (iso −3.4% at np=2, ti +2.8% at np=4).

The question this issue raised — whether that assertion should be a cross-build invariant rather than an absolute golden — is recorded in #651 in case it recurs, but there is nothing failing to act on now.

Closed into #651, which consolidates the Stokes_Constrained backlog.

Underworld development team with AI support from Claude Code