[us-commits] [ehb54/ultrascan3] 4e14d5: somo/grpy: keep the UI alive during assembly, fact...

[emre brookes]

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

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

  Log Message:
  -----------
  somo/grpy: keep the UI alive during assembly, factor and solve

The GUI froze for seconds at a time during "INVERTING MATRICES", and was dead
outright either side of it. Two causes.

The calling thread is a compute worker: QtConcurrent::blockingMap both blocks
the caller and uses it to run tasks, so the event loop cannot turn for the
whole duration of any for_range. Progress -- and therefore the processEvents()
that keeps the GUI breathing -- only ran between for_range calls.

And progress was emitted from exactly one place in the numeric core: once per
tile column of the Cholesky. Assembly (one for_range over ~4M pair blocks on a
2832-bead model) and solve reported nothing whatsoever. Within the factor, the
trailing update costs O((nt-k)^2), so the earliest columns are by far the
longest -- measured ~5 s each at dim 31152, decaying to milliseconds.

Assembly and the factor's trailing update are now chunked, with the chunk
self-tuning toward ~80 ms per slice (double under 40 ms, halve over 160 ms) so
the granularity holds across machines and model sizes rather than being a
constant tuned here. The factor retunes within a column, not just between
columns, because the first columns are exactly where the freeze was worst.
Solve reports per tile. The bar now spans 0-30 assemble, 30-90 factor,
90-100 solve.

The factor bar is also cost-weighted by trailing-update work completed instead
of being linear in the column index; since cost per column is quadratic, the
old bar crawled at the start and raced at the end.

With no callback -- the CLI and every test -- the work runs as a single chunk,
exactly as before.

Tests assert the chunked path is numerically INERT: same Dt, same eta, and a
byte-identical report versus the unchunked path. That check is the real guard,
since the goldens only ever exercise the no-callback path. It earned its place
immediately: the first version advanced the loop by `chunk`, which is retuned
inside the loop, so a doubling silently skipped beads and corrupted the matrix.
Both loops now advance by what was actually processed. Also asserts progress is
monotone, stays in 0..100, and that no phase is silent.

Tick count is deliberately not asserted tightly -- the chunker targets a wall
time, so a small model that finishes fast correctly uses few large chunks.

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