Order-of-Accuracy Tests
The strongest code-verification check: confirm that the error shrinks at the exact rate the numerical scheme promises.
Beyond Convergence
Showing that a solution converges is good; showing that it converges at the theoretical rate is much stronger. A scheme advertised as second order should have its error fall by a factor of four when the spacing is halved. The order-of-accuracy test measures the observed order and compares it to the formal order. A mismatch is one of the most sensitive bug detectors in scientific computing.
The Formula
With an exact solution available (from manufactured solutions or an analytic case), compute the error norm on a coarse and a fine mesh with refinement ratio r. The observed order is the logarithm of the error ratio divided by the logarithm of r. If errors E1 and E2 come from spacings h1 and h2, then p equals log(E1/E2) divided by log(h1/h2).
import math
# errors on three meshes with ratio r=2
E = [4.0e-2, 1.02e-2, 2.55e-3]
for i in range(len(E)-1):
p = math.log(E[i]/E[i+1]) / math.log(2.0)
print(f'observed order between level {i} and {i+1}: {p:.2f}')
Reading the Result
- Observed order near the formal order: the discretization is implemented correctly.
- Observed order one lower than expected: a classic symptom of a boundary condition or flux term implemented to lower order.
- Order that drifts or collapses on the finest mesh: round-off is contaminating the error, or the solution is not smooth.
Why It Catches Bugs
Many coding errors leave a method consistent (it still converges) but degrade its rate. A sign error in a high-order correction, a missing term at a boundary, or an incorrect stencil weight often leaves first-order convergence in a scheme meant to be second order. Only the rate test exposes these; a single-mesh comparison to data would not. This is why order-of-accuracy verification is regarded as the gold standard of code verification, and why Kronos treats a passing order test as a precondition before any physics comparison is reported.