AAppendix: verification & glossary

How we make sure the solvers on this site are right — and a dictionary of every term used.

"Make no mistakes" is a strong requirement for an educational site: a wrong sign in a numerical flux or a missing Jacobian produces pictures that look plausible but teach the wrong thing. Every numerical module in lib/core/ is therefore covered by automated tests, and every quantitative claim in the text (a convergence rate, a conservation property, an equivalence between two methods) is checked by one.

How the code is verified

  1. Exactness tests. Building blocks are tested against exact mathematical facts: Gauss rules integrate polynomials up to degree $2n-1$ exactly (and not $2n$), Legendre and Dubiner bases are orthonormal, differentiation matrices differentiate polynomials exactly, eigenvalue solvers recover known spectra (including complex pairs), sparse direct and Krylov solvers reproduce known solutions, Runge–Kutta methods show their design order.
  2. Invariants. Properties that must hold to round-off: conservation of mass in finite volume and DG methods, symmetry of SIPG/Nitsche matrices, equivalence of flux reconstruction with $g_{DG}$ and nodal DG, equality of hybridized and mixed solutions, GPU vs CPU agreement, zero row sums of stiffness matrices, the divergence theorem in the chapter 0 widget, …
  3. Convergence against manufactured solutions (MMS): choose an exact solution $u$, compute the data that produces it, solve on a sequence of meshes and fit the slope of $\log(\text{error})$ against $\log h$. A test passes if the observed rate lies in $[r - 0.2,\ r + 0.3]$ around the theoretical rate $r$. Errors are always measured with high-order quadrature, never only at nodes.
  4. Page self-tests. Each chapter page opened with ?selftest=1 reports widget errors and the results of built-in sanity checks (finite values, conservation, …). A script runs this for every page in headless Chrome.

The same test files run headless under Deno on every push (GitHub Actions) and in the browser, here:

The test suite, live. Each row is one test from tests/; the names say what is checked. Long convergence tests solve many problems, so the full run takes a while.
Why rates, not pictures

A bug rarely makes a solver explode; far more often it costs an order of convergence (slope 1 instead of 2) or a constant factor that is invisible on one mesh. Rates against exact solutions are the most sensitive bug detector numerical analysts have — the same reason graphics people compare renderers against analytic integrals or reference path tracers instead of eyeballing images.

Glossary