Observed Order of Convergence — Troubleshooting Guide
By Sitemap
My Mms Convergence Rate simulation is giving me unexpected results — convergence issues, maybe. How do I diagnose this systematically?
Mms Convergence Rate troubleshooting follows patterns once you know what to look for. Most issues fall into three buckets: convergence failures, accuracy problems, and result misinterpretation. Let me give you a systematic diagnostic framework rather than a list of random fixes.
That framing helps. Before we dive in — what's the single most common mistake engineers make with Mms Convergence Rate?
Honestly, it's skipping the sanity checks. Engineers set up a Mms Convergence Rate model, it converges, and they trust the result without verifying it against a hand calculation or a known benchmark. The solver gives you an answer regardless of whether your model is physically correct. Always run a simplified version first.
When code verification is done with MMS (the method of manufactured solutions) or an exact-solution benchmark, the final pass/fail call rests on the observed order of convergence. Measuring the error norm \( E_h \) over a mesh sequence with refinement ratio \( r \) gives an observed order of
$$ p_{obs} = \frac{\ln(E_{rh}/E_h)}{\ln r} $$
and the test passes when this approaches the nominal (formal) order of the discretization scheme. In a healthy verification the \( \log h \)-\( \log E \) plot sits on a straight line of the theoretical slope, and the slope moves closer to the nominal value at every finer level. This page works symptom by symptom through the cases where that number refuses to appear, wanders, or simply cannot be trusted — with the focus on defects in how the error itself is measured. For causes on the equation side (boundaries, source terms, limiters) see also the NS edition and the source-term edition.
I measured the error on a coarse and a fine mesh, but the order comes out 1.3 one run and 2.8 the next — it's all over the place.
Before you suspect the equations or the code, audit the error-norm computation itself. Measuring an order is precision work — it resolves two to four decades of change in the error — so sloppiness in the measurement translates directly into a scattered order. Three checkpoints. ① Is the exact solution evaluated at the same location as the numerical solution (cell centers? nodes? integration points?). ② Does the norm carry weights — a plain average over a non-uniform mesh skews the contributions of coarse and fine regions. ③ Are you mixing cell averages with point values? A finite-volume solution is a cell average, so the exact solution must be compared as a cell average too (or with the \( h^2 \)-order correction included); otherwise that alone injects second-order noise.
The standard form of the discrete \( L^2 \) norm is volume-weighted.
$$ E_h = \left( \frac{\sum_i V_i \, (u_i - u_i^{exact})^2}{\sum_i V_i} \right)^{1/2} $$
Exactly as the formula says: ① evaluation at matching locations, ② volume weighting, ③ matching solution type (point value vs. cell average). Honoring those three alone makes a large share of "the order is erratic" problems disappear.
| Check | What to look for |
|---|---|
| Fully periodic test | Verify the interior scheme alone with a manufactured solution periodic in every direction. If the order appears here, the boundary treatment is the culprit (low-order boundary extrapolation, inconsistent boundary conditions) |
| Choice of norm | If only \( L^\infty \) is low, the order loss is local (corners, boundary layers). If \( L^2 \) is fine, the global behavior is healthy |
| Depth of iterative convergence | Was the iterative residual driven at least two decades below the discretization error at every level? The criterion bites hardest on fine meshes, where the error is smallest — watch for stalling |
| Accuracy of source terms and initial conditions | Check that the quadrature order for the source term and the projection accuracy of the initial condition are not below the scheme's order |
| Smoothness of the solution | If the manufactured or exact solution itself has a singularity (low regularity at a corner), the order loss is exactly what theory predicts — the code is innocent |
The two-point form \( p_{obs} = \ln(E_{2h}/E_h)/\ln 2 \) uses only a single adjacent pair, which makes it sensitive to noise. The remedy has two stages.
Case (a) is especially frequent on unstructured meshes. For verification runs specifically, uniform refinement of a structured grid (or self-similar refinement of an identical topology) is the single most reliable way to stabilize an order measurement.
Beyond discretization error, the measured error has a "floor" made of round-off and iteration-cutoff error, and the apparent order drops as refinement approaches that floor. The diagnosis is easy: look at the absolute value of the error. If \( E_h \) has fallen to the \( 10^{-10} \) range — near the limit of double-precision significance — no finer level is usable for measuring an order. The fixes are ① raise the amplitude of the manufactured solution so the floor sits relatively lower, ② evaluate the order on the coarser levels, ③ tighten the iterative solver's stopping criterion further. "Finer is better" does not hold for order measurement — the trick is to measure inside the usable window between the asymptotic regime and the floor.
When a second-order scheme reports three or four, hold the celebration and suspect ① you are not yet in the asymptotic regime (in the pre-asymptotic range, where higher-order error terms dominate, the apparent order swings either way), or ② accidental cancellation of error terms — the "superconvergence" that appears when a highly symmetric manufactured solution or a particular wavenumber kills the leading error term. To confirm, re-measure with a different manufactured solution whose wavenumber and phase are shifted. If the high order survives that, revisit your understanding of the scheme's nominal order instead (the truncation-error analysis). Attaching the confirmation "the same trend holds for a different manufactured solution" to the report is the discipline that prevents false claims of superconvergence.
Measuring temporal order on an unsteady problem is hard because spatial and temporal errors are mixed together.
That's a long checklist… If you had to name one mindset that matters most in order measurement, what would it be?
That measuring an order is an experiment. Just as an experiment requires instrument calibration and an error budget, an order measurement requires cross-checking the error norm (calibrating the instrument) and controlling the noise sources (controlling the environment). When a point misses the line, suspect the measurement procedure before you suspect a bug in the code — keeping that order alone cuts investigation time by an order of magnitude. And once the procedure is settled, script it and fold it into a regression test alongside automated source-term derivation. Order measurement pays off only when it stops being a one-time ritual and becomes an automated safety net that keeps guarding the code.
Related: MMS overview (consolidated), automated MMS source-term derivation, GCI troubleshooting (for the same observed order used in solution verification).