su2live <-> live residual plots in the terminal

[Syphonicc]

I've been doing a lot of convergence tuning on test cases lately and got tired of waiting for runs to finish before plotting history.csv, so I wrote a small tool that plots residuals live while the solver runs.

https://github.com/Syphonicc/su2live

su2live inv_channel.cfg # runs SU2_CFD and plots as it goes
su2live --file history.csv # follow a run already in progress

Pure Python, no dependencies, works over SSH. It reads the history file rather than stdout, so it picks up all the residual columns an SST run writes rms[k] and rms[w] to the CSV whether or not they show on screen.

Besides plotting, it tries to say what the run is doing: converging with a rate in decades per 1000 iterations and an estimated number of iterations to CONV_RESIDUAL_MINVAL, or stalled / limit-cycling / frozen / diverging. The cycling case is the one I found most useful a case oscillating about −7 looks a lot like slow convergence if you're watching a single number scroll past.

Happy to take suggestions. If it'd be more useful living in SU2_PY rather than as a separate package, I'm open to that too.

[bigfooted]

Nice that it's completely terminal based :-)
I wrote a tutorial on how to show the results in realtime in paraview,
https://su2code.github.io/tutorials/paraview_live/
and I also have a python realtime viewer that plots in a window that I use a lot. Adding some monitoring scripts to su2 could be a nice addition I think.

[Syphonicc]

Thanks I hadn't seen the ParaView live tutorial, that's a nice setup for the field data. Your viewer looks like it covers the windowed case well.

Happy to put together a monitoring script for SU2_PY if that's wanted. Terminal-only makes sense as the complement to what you already have it works over SSH on a cluster where you can't get a window, and it doesn't need matplotlib.

If it'd help I could strip su2live down to a single self-contained script in SU2_PY (no packaging, no dependencies) and keep the standalone repo for anything more elaborate. Or if you have a shape in mind for what the monitoring scripts should look like, I'm happy to work to that instead.

[pragyaangaur]

Nice tool @Syphonicc, the braille plotting over SSH is a good call. Three things I hit reading the source:

1. A run that goes to nan reports as converging. SU2 writes nan into history.csv when a case blows up, and float("nan") parses fine. In analyse, span < 1e-9, m > 0.01 and abs(m) < 0.005 are all False for NaN, so it falls through to the converging return. Filtering non-finite values before classification fixes it.

2. Unsteady runs get misread. _adopt_header prefers Inner_Iter, which resets every physical time step. If one row is written per time step the column is constant, den in slope is zero, slope returns 0.0, and a healthy run shows as stalled. If inner iterations are written, the sawtooth x values gave me "diverging +1.69 dec/1k" on a residual that was falling monotonically. Preferring Time_Iter when it exists, or plotting against row index, would handle both.

3. it/s and the wall-time ETA are wrong in --file mode. run_follow sets started at attach, then build_frame uses elapsed / len(hist.iters), so every pre-existing row is charged to the time since attach. Following your own example history gives 2165 it/s ~1s. Timing the gaps between newly appended rows would be more accurate.

None of these are hard fixes, and the idea is good. Would happily use it once the unsteady case works

[Syphonicc]

Good catches, all three reproduced. Fixed in v0.3.0:

nan now short-circuits to diverging before the numeric comparisons you were right that it fell straight through.
The axis column is now checked for monotonicity once enough rows arrive, and falls back to Time_Iter or the row index. Both the constant and sawtooth cases were broken exactly as you described.
Solver speed is measured from rows that arrive while watching rather than dividing the whole file by time since attach.

Added a test suite covering all of these plus the classification cases, so they stay fixed. Thanks that was a genuinely useful review.

[pragyaangaur]

Appreciate it, glad it helped to improve the work!