Solved right, or the right equations

Lead figure

Verification asks whether the mathematics was done correctly; validation asks whether the model matched reality. They are different questions.

Photo: Southwark-Emery Universal Testing Machine · Wikimedia Commons

What the words actually mean

The definitions have been settled for long enough that the computational mechanics community treats them as standard. Verification asks: was the mathematics solved correctly? Given the equations in the model, did the numerical method produce an accurate approximation of their solution? Validation asks something different entirely: are those equations the right ones? Does the mathematical model represent the physical system it is meant to describe?

The distinction sounds obvious until something goes wrong. A structural solver can march through a linear-elastic finite element problem and converge beautifully to the correct solution of the wrong constitutive law. The mesh refinement study is clean, the residuals drop, the iterative solver terminates within tolerance — and the answer is still unphysical, because the model assumed small strains in a regime where strains are not small. Verification passed. Validation would have failed, if anyone had run it.

The separation was codified in the AIAA Guide for the Verification and Validation of Computational Fluid Dynamics Simulations published in 1998, and has since been absorbed into standards used in aerospace, nuclear safety assessment, and medical device regulation. The shorthand V&V covers both, but the two legs of it involve entirely different kinds of evidence and entirely different kinds of error.

What validation needs

A physical measurement with its own uncertainty. Without it there is nothing for the model to be right or wrong about.

Verification in practice

Verification is, in principle, a mathematical question with a mathematical answer. The tool is the convergence study: refine the mesh, watch the solution change, and measure whether the rate of change matches the theoretical order of accuracy of the scheme. A second-order method should quarter its error when the mesh spacing halves; if the observed rate diverges significantly from the theoretical one, something is wrong in the implementation.

The most rigorous form of this is the method of manufactured solutions, where an exact answer is constructed first — often something analytically convenient but physically arbitrary — and the governing equations are modified to be consistent with it. The solver is then run on those modified equations, and its output is compared directly against a known answer. Error norms can be computed, convergence rates measured, and implementation bugs that would otherwise hide behind the complexity of a real problem are exposed cleanly.

A structural solver can march through a linear-elastic finite element problem and converge beautifully to the correct solution of the wrong constitutive law.

Verification also covers the solution of the algebraic system itself. A sparse linear system assembled from a finite element discretisation can be factored directly or solved iteratively; in either case, the residual is a computable quantity, and monitoring it is not optional. Round-off errors, ill-conditioning driven by mesh distortion, and preconditioner failures all show up here, not in the physics. Separating them from modelling error requires that verification be done first, on problems with known solutions, before validation is attempted.

What verification cannot do is say anything about reality. It only establishes that the computed solution is a faithful approximation to the mathematical model. That model might still be catastrophically wrong.

Validation and its limits

Validation is an empirical question, which means it requires measured data, and measured data always carry uncertainty. A simulation of turbulent flow in a pipe is validated not by showing that it converges, but by comparing velocity profiles and pressure drops against experiment — and then being honest about the uncertainty on both sides. The experimental measurements have instrumentation error and repeatability scatter; the simulation has modelling assumptions, numerical discretisation error, and sensitivity to boundary conditions that may not be precisely known.

This is where turbulence modelling makes V&V genuinely hard. A RANS model closes the Reynolds-averaged equations with empirical closure coefficients tuned to certain classes of flow. The model may validate acceptably for attached boundary layers on flat plates and fail without warning for separated flows over bluff bodies. The validation is not a binary pass or fail — it is conditional on the flow regime, the quantity of interest, and the range of Reynolds number tested. A model validated for subsonic aerodynamics tells you nothing about its accuracy in hypersonic shock-dominated flow.

The verification half

Whether the code solves the equations it claims to solve is a question that can be answered without an experiment at all.

The honest framing, developed most systematically by Patrick Roache in his 1998 text Verification and Validation in Computational Science and Engineering, is that validation builds a quantified statement of agreement between simulation and experiment over a specified range of conditions. Outside that range, the statement does not hold. Predictive use of a model beyond its validation domain is an extrapolation, and should be treated as one.

There is also the question of what is being validated. A complete CFD simulation involves a chain of choices: the governing equations, the turbulence model, the numerical scheme, the mesh, the boundary conditions, the geometry simplifications. An experiment that produces agreement with the final output validates the chain as a whole, not each link individually. If the experiment were run differently — different inlet turbulence intensity, different wall temperature, different measurement location — agreement might vanish. Validation that is not accompanied by sensitivity analysis is weaker than it looks.

Where they connect

The two activities are not independent. Validation requires that verification be established first; there is no point comparing a poorly converged simulation against experiment, because numerical error is indistinguishable from modelling error in the output. Conversely, a simulation that is well-verified but never validated has been shown only to solve equations faithfully — not to predict anything about the physical world.

In regulated industries, both must be formally documented. In aerospace certification, nuclear safety analysis, and computational modelling in medical devices ↗, regulators ask for evidence of both: convergence studies, code-to-code comparisons, and comparison against physical test data with uncertainty quantification on each side. The formalism can be burdensome, but the underlying logic is sound. A code that has never been wrong in a known-answer test gives a practitioner more justified confidence, not less, when it is deployed on a problem without one.

The deeper point is epistemological. Computational mechanics produces numbers. Whether those numbers represent anything real depends on a chain of reasoning that runs from the physical world through a mathematical model, through a discretisation, through an algebraic solver, to an output. Verification checks the back half of that chain. Validation checks the front. Neither check is sufficient alone, and skipping either one is not an efficiency — it is a decision to not know something that you could have known.