[us-commits] [ehb54/ultrascan3] 1f3f09: somo/grpy: report the computed and extrapolated va...

[emre brookes]

  Branch: refs/heads/ehb54-issue-984
  Home:   https://github.com/ehb54/ultrascan3
  Commit: 1f3f0914dc98e58ec78212b658a4011fc39a54f9
      https://github.com/ehb54/ultrascan3/commit/1f3f0914dc98e58ec78212b658a4011fc39a54f9
  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
    M us_somo/somo/doc/manual/somo/somo_hydro.html

  Log Message:
  -----------
  somo/grpy: report the computed and extrapolated values side by side

The shell report gave the estimated error but only one value, and an audit of the
development benchmarks turned up why that matters: the research harness that produced
them accepted the Richardson-extrapolated value as the answer and scored the error
estimate against ITS deviation, while the shipped solver returns the finest rung's own
value and delivers the extrapolated one separately. Those are two different claims. On
the same archived runs the estimate covers the extrapolated value's deviation in 92 of
92 cases but the finest rung's in 82 of 92, so which value is reported decides what the
error estimate means. The module's own tests happened to score the finest rung, which is
why the divergence went unnoticed.

Reporting both settles it. The scalars keep the computed value -- a reported result
should be one the program computed, not one inferred from a trend -- and the report now
prints the extrapolated value beside it, with the estimate stated as the distance
between the two and a sentence saying which column the results elsewhere in the file
are. A reader shown one column alone cannot tell what the estimate applies to, which is
the entire content of the estimate.

ShellReport gains `reported`, the finest rung's value per requested observable, parallel
to the existing `extrapolated`. It is what Results carries, and a test asserts that
equality exactly -- if they ever diverge, the report and the returned scalars would be
describing different answers. A further test asserts the two columns are genuinely
distinct, so the block cannot pass by printing one number twice.

Manual updated to describe both columns and to say plainly that they are two answers
rather than a value and a correction to it.

Fixes ehb54/ultrascan-tickets#984

Co-Authored-By: Claude Opus 5 <noreply at anthropic.com>



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