verification vs validation
Suppose you build a computer simulation of a bridge and it predicts the bridge will sag two centimetres under load. Two completely different questions decide whether you should trust that number. First: did my program correctly compute what the equations say? Second: do those equations actually describe the real bridge? The first question is VERIFICATION; the second is VALIDATION. The slogan that keeps them straight is: verification asks 'are we solving the equations RIGHT?', validation asks 'are we solving the RIGHT equations?'. They are different activities, use different tools, and you need both.
Verification is about the code and the math, with no reference to the real world. You are checking that your numerical solution converges to the exact solution of your chosen equations, and that bugs have not crept in. Its tools are internal: the method of manufactured solutions, order-of-accuracy studies that confirm the error shrinks at the predicted rate as the mesh refines, comparison against problems with known exact answers, and unit and regression tests. You can do all of verification with the real world switched off — it is mathematics and software engineering. Validation, by contrast, requires comparing your simulation's output to MEASUREMENTS from experiments or observations of the actual physical system. Its tools are experimental data, uncertainty quantification, and statistical comparison. Validation can only proceed AFTER verification: it is pointless to compare a buggy code to reality, because you cannot tell whether a mismatch is a coding error or a modelling error.
Why insist on the distinction? Because the two failure modes are independent and have different cures. A perfectly verified code (no bugs, correct convergence) can still be useless if its underlying model is wrong — say it ignores temperature effects that matter — and no amount of debugging will fix that; you must change the model. Conversely, a physically sound model implemented with a bug will disagree with reality for a reason that has nothing to do with the physics, and changing the model would be exactly the wrong response. Conflating the two is one of the most common and expensive mistakes in computational science. The honest summary: verification certifies the software, validation certifies the model, and a result that has passed neither is not yet science.
A team writes a heat-flow solver. VERIFICATION: they feed it a manufactured problem whose exact solution they invented, refine the mesh, and confirm the error falls like h^2 as predicted — the code is bug-free and second-order. VALIDATION: they then run it on a real metal bar, compare predicted temperatures to thermocouple readings, and find the model omitted radiative heat loss. The code was right; the equations were incomplete.
Verification caught no bug; validation revealed the model was missing physics. Two separate checks.
Order matters: verify first, validate second. If you validate a buggy code, a mismatch with reality is ambiguous — you cannot tell a coding error from a modelling error, so you learn nothing about your model.