[us-commits] [ehb54/ultrascan3] e3c383: somo/grpy: an exact result must not carry a stale ...

[emre brookes]

  Branch: refs/heads/ehb54-984-exact-rung
  Home:   https://github.com/ehb54/ultrascan3
  Commit: e3c383d31f14f5e15aee3d8705a9d3bbc5f15031
      https://github.com/ehb54/ultrascan3/commit/e3c383d31f14f5e15aee3d8705a9d3bbc5f15031
  Author: ehb54 <brookes at uthscsa.edu>
  Date:   2026-08-08 (Sat, 08 Aug 2026)

  Changed paths:
    M us_somo/develop/grpy/grpy_shell.hpp
    M us_somo/develop/grpy/tests/test_shell.cpp

  Log Message:
  -----------
  somo/grpy: an exact result must not carry a stale error estimate

When the rung just solved is the full model the answer is exact and every bar should be
zero, but the loop tested the tolerance first and the full-model case second. If the full
rung also happened to satisfy the tolerance, the run exited as merely "converged", kept
the inter-rung gap as its estimate, and left `unreduced` false. Measured on a 216-bead
model at tol=0.5%: the ladder reached all 216 beads, the value was bit-identical to the
unreduced solve, and the report claimed 0.159% on a true error of zero.

The value was never wrong and the estimate was conservative rather than misleading, but
"converged, 0.16% estimated error" is a false statement about an exact calculation, and
`unreduced` is the flag the report and the results file use to say the answer is exact.

Test the full-model condition first, and widen it to cover n_used >= n_full so it does not
depend on the nominal fraction matching the realised bead count.

The existing exhaustion test missed this because it used tol=1e-12: unsatisfiable by
construction, so the tolerance branch could never win the race. The new test uses a
satisfiable tolerance on a ladder ending at 1.0 and asserts the full rung is flagged
unreduced, that err_max and every per-observable estimate are zero, that the result equals
the plain unreduced solve, and that viscosity is not flagged unreliable.

Found by a smoke run of the re-validation driver, which prints the retained fraction beside
the estimate: a row reading keep_frac=1.0, true error 0.000000, estimate 0.159% cannot all
be true at once. Worth landing before those runs, since full-rung rows would otherwise be
scored as an 0.16% estimate against a true error of zero -- inflating the reported
conservatism and hiding that the answers are exact.

Fixes ehb54/ultrascan-tickets#984



To unsubscribe from these emails, change your notification settings at https://github.com/ehb54/ultrascan3/settings/notifications