[us-commits] [ehb54/ultrascan3] cf4ff5: somo/grpy: pre-flight memory guard for oversized m...

[emre brookes]

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

  Changed paths:
    M us_somo/develop/src/us_hydrodyn_grpy.cpp

  Log Message:
  -----------
  somo/grpy: pre-flight memory guard for oversized models

The in-process GRPY solver holds the tiled upper triangle of the 11N x 11N
mobility matrix in RAM (peak ~ (11N)^2/2 * scalar bytes), so a model larger
than physical RAM cannot fit in-core -- e.g. 20k beads needs ~180 GB double /
~90 GB single. Because the solve runs synchronously on the GUI thread, such a
model previously sent the machine into heavy swapping with a frozen interface.

Add a pre-flight guard in calc_grpy_hydro() before the batch starts: estimate
peak memory for the largest selected model from its used-bead count and the
chosen precision, read physical RAM (macOS hw.memsize / Linux sysconf; unknown
-> no guard), and if the estimate exceeds ~70% of RAM:
  - interactive: a Cancel / Run-anyway dialog naming the estimate, the machine
    RAM, and the remedies (single precision, or a smaller model);
  - script mode (gui_script): never block on a dialog -- report the error to the
    editor and stderr and fail with a non-zero exit.

Verified: a headless run of a 20,000-bead model on a 32 GB machine reports
"~198.3 GB needed, 32.0 GB available" and exits non-zero pre-flight, instead of
thrashing.

Fixes ehb54/ultrascan-tickets#987

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



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