Visual Debugging of Simulations
Rendering a simulation's internal state during a run exposes instabilities, boundary errors, and bugs that summary numbers hide.
Seeing the bug
A simulation can produce a plausible final number while going wrong internally: a boundary that leaks, a field that oscillates, a region that never converges. Visual debugging renders intermediate state so these failures become visible. Often the picture reveals in seconds what days of reading logs would not.
What to look at
- Residual fields: where the solver is not converging points at the trouble.
- Boundary and ghost cells: many bugs live at domain edges.
- Conserved quantities over time: drift signals a leak or scheme error.
- Extremes: rendering min and max locations catches overflow and instability.
Comparing against expectation
Debugging is comparison. Render the difference between two runs, between a run and an analytic solution, or between successive iterations. A difference field concentrates attention on what changed and where a method breaks, far more than viewing either field alone.
In-situ and lightweight
Because debugging happens during development runs, cheap, immediate rendering matters more than polish. In-situ extraction (see In-Situ Visualization) lets you watch a large run without storing everything, and can trigger detailed output only when a feature or an error appears.
Discipline
Visual debugging generates hypotheses; confirm them with numbers. A striking image can also mislead through a bad color scale or aliasing, so verify a suspected bug against quantitative checks before acting.
Kronos use
Development runs of plasma and transport simulations are inspected with residual and difference fields so numerical problems are found before results inform the design.