[us-commits] [ehb54/ultrascan3] 308203: somo/grpy: cap the shell-reduction ladder by avail...

[emre brookes]

  Branch: refs/heads/ehb54-issue-984
  Home:   https://github.com/ehb54/ultrascan3
  Commit: 3082031334ff5eac0bcbb03be8bac89be4457614
      https://github.com/ehb54/ultrascan3/commit/3082031334ff5eac0bcbb03be8bac89be4457614
  Author: ehb54 <brookes at uthscsa.edu>
  Date:   2026-08-06 (Thu, 06 Aug 2026)

  Changed paths:
    M us_somo/develop/grpy/grpy_shell.hpp
    M us_somo/develop/grpy/tests/test_shell.cpp
    M us_somo/develop/src/us_hydrodyn_grpy.cpp
    M us_somo/somo/doc/manual/somo/somo_hydro.html

  Log Message:
  -----------
  somo/grpy: cap the shell-reduction ladder by available memory

Merging somo-dev brought in the issue-987 pre-flight memory guard, which
refuses a GRPY run whose mobility matrix would exceed RAM. It sizes that
matrix from the FULL bead count, in calc_grpy_hydro(), before shell reduction
is applied in grpy_process_next() -- so it would turn away precisely the large
models shell reduction exists to make feasible. The ladder normally stops well
short of the full model, and memory goes as the square of the bead count, so a
run that stops at ~25% of the beads needs ~6% of the refused matrix.

Rather than weaken the guard, the budget is now passed into the ladder:

- ShellOptions::max_beads caps the largest rung. Checked after building the
  subset (cheap) but before the solve (expensive), so a rejected rung costs
  nothing; the ladder ascends, so the first rung over budget ends it.
- A capped ladder reports mem_capped and does NOT claim convergence. The
  result stands on its error bar, which is stated as usual and will generally
  exceed the requested target. It is never passed off as converged.
- The guard defers to shell reduction only when the budget admits at least the
  smallest rung; below that there is nothing to compute and it still refuses.
  When shell reduction is off, its message now offers the option, noting that
  unlike ZENO it still yields rotational diffusion.

So an oversized model now gives the best result that fits, with a quantified
error, instead of nothing.

Two supporting cleanups, both forced by the above: truthy() is promoted from a
lambda local to grpy_process_next() to a file-static, so the guard and the
solver setup resolve the same scripting overrides (the guard previously read
hydro.grpy_single directly and would have ignored a grpy_single override); and
the matrix-size estimate is factored into grpy_matrix_bytes() with
grpy_max_beads_for_ram() as its inverse, so the guard and the cap cannot drift
apart about what fits.

Tests cover a slack cap (must not perturb the unreduced, exact path), a
binding cap (capped, non-converged, bar finite, budget respected, explained in
the report), and a cap below the smallest rung. The last of these found a
latent crash: with no rung run, err_est was empty while require was not, and
the report loop indexed past the end. Guarded, and that case now states
plainly that nothing was computed.

Manual documents the lifted refusal in the shell-reduction section.

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