[us-commits] [ehb54/ultrascan3] 8dcc49: somo/grpy: exclude the overwrite prompt from the G...

[emre brookes]

  Branch: refs/heads/ehb54-issue-984
  Home:   https://github.com/ehb54/ultrascan3
  Commit: 8dcc49382cade039accd9f266f8b37ac37448176
      https://github.com/ehb54/ultrascan3/commit/8dcc49382cade039accd9f266f8b37ac37448176
  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

  Log Message:
  -----------
  somo/grpy: exclude the overwrite prompt from the GRPY timer

"Time to process" spans the whole run, and the results-writing path prompts
for a filename whenever an output file exists and overwrite_hydro is false.
That prompt is modal, so the operator's response time was counted as compute.
Measured directly: the same binary, model and settings gave 5m 00s answering
slowly and 3m 49s answering quickly -- 71 s of pure click latency, varying per
run, which makes interactive GRPY timings incomparable with each other.

It also cost real analysis time here: a 21% gap between two runs was
attributed to machine contention on the strength of a microbenchmark that
bounded the alternative explanation at ~3%. The bound was right; the
conclusion was wrong. The missing time was the operator.

US_Timer already supports this exactly: stop_timer banks the interval so far
WITHOUT counting a completion, and start_timer restarts from zero, so
stop/start is pause/resume and the paused span is never accumulated. No change
to US_Timer. An RAII guard applies it at the four prompt sites that fall inside
the timed region; the fifth call runs before the timer starts and is untouched.

The prompt itself is deliberately unchanged -- this only stops it being counted
as compute.

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