[us-commits] [ehb54/ultrascan3] 7578f3: somo/grpy: GRPY_SHELL_MAX_BEADS override, and repo...

[emre brookes]

  Branch: refs/heads/ehb54-issue-984
  Home:   https://github.com/ehb54/ultrascan3
  Commit: 7578f39c336cf8e683897592b08a4377d280cfed
      https://github.com/ehb54/ultrascan3/commit/7578f39c336cf8e683897592b08a4377d280cfed
  Author: ehb54 <brookes at uthscsa.edu>
  Date:   2026-08-07 (Fri, 07 Aug 2026)

  Changed paths:
    M us_somo/develop/src/us_hydrodyn_grpy.cpp
    M us_somo/somo/doc/manual/somo/somo_hydro.html

  Log Message:
  -----------
  somo/grpy: GRPY_SHELL_MAX_BEADS override, and report the cap every run

The shell-reduction bead cap was derived solely from physical RAM, with no way
to move it. That made the memory-capped path effectively untestable: the ladder
can only reach the cap by FAILING on the rung below it, so on a model large
enough to have a cap at all, exercising it means paying for that rung first --
5h44m on a real 11328-bead model, which then converged one rung short of the
cap anyway and never exercised it.

GRPY_SHELL_MAX_BEADS in the environment, or grpy_shell_max_beads as a script
parameter, now overrides it. With a small value the same model reaches the cap
in seconds. Env/script only with no GUI control, matching grpy_ooc_dir: a
diagnostic and shared-machine knob rather than a user setting. It is also the
only way to hold GRPY under a chosen footprint on a machine shared with other
work, which the 70%-of-RAM rule cannot express.

Honoured in both directions. A value above what memory supports is flagged
rather than silently clamped -- overriding is deliberate, and clamping would
make the reported cap a lie.

Reported every run, which is the point: an override changes which results are
obtainable, and a stale environment variable would otherwise silently bound
every calculation with nothing on screen to say so. With no override and shell
reduction on, the memory-derived cap and the RAM it came from are printed
instead, so the limit is never a mystery. Both go to the progress window, once
per run.

The guard and the ladder resolve the cap through one shared function. If they
resolved it separately the guard could admit a run the ladder then refuses to
compute, or refuse one it could have done.

Manual documents the variable in the shell-reduction section; the parameter is
also added to the gui_script reference ticket (ultrascan-tickets#990).

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