🔍 Simulation Verification & Validation (V&V): Mesh Convergence & Model Credibility

Running the Software Correctly Is Not the Same as Being Right

A finite element or CFD solver will almost always return an answer. It will color a part blue and red, plot a velocity field, and report a peak stress value to four significant figures, regardless of whether the mesh was adequate, the boundary conditions were realistic, or the material model was appropriate for the loading regime. The software has no concept of whether its own answer is trustworthy — that judgment is entirely the engineer's responsibility, and the discipline for making that judgment rigorously and defensibly is called Verification and Validation (V&V). This is a different skill from operating ANSYS, Abaqus, or COMSOL competently, and it is the skill that separates a simulation result an organization can stake a design decision, a certification submission, or a safety case on from a simulation result that merely looks plausible.

V&V is not a footnote to simulation work; in regulated and high-consequence industries it is often the majority of the effort. A structural analysis submitted to support aircraft certification, a nuclear pressure-boundary calculation, or a medical-device finite element report is routinely expected to document its verification and validation evidence at least as thoroughly as the analysis results themselves, following frameworks such as ASME V&V 10 (solid mechanics) and ASME V&V 20 (CFD and heat transfer), or equivalent guidance in aerospace and automotive standards. Even outside formally regulated work, the underlying discipline — knowing the difference between a numerically sound result and a physically correct one, and being able to demonstrate both — is what a credible simulation engineer is actually expected to bring to the table.

Verification: Did We Solve the Equations Right?

Verification is a purely mathematical question, entirely internal to the numerical model, with no reference to physical reality at all. It asks whether the discretized model — the mesh, the element formulation, the time-stepping scheme, the convergence criteria — actually solves the governing equations it claims to solve, to an acceptable and known level of numerical error. Verification splits into two related activities.

Code verification checks whether the solver software itself correctly implements the numerical methods it claims to implement, typically done by the software vendor or a rigorous internal QA process using problems with known exact analytical solutions (a simply supported beam, a Poiseuille flow profile) and confirming the code reproduces them to the expected order of accuracy as the mesh is refined. Most practicing engineers rely on vendor-verified commercial codes (ANSYS, Abaqus, COMSOL, Fluent) and do not repeat code verification themselves, but it is worth knowing that this step exists and that a solver's credibility rests partly on its documented verification history and benchmark suite.

Solution verification is the part every practicing simulation engineer is directly responsible for on every analysis: confirming that the specific mesh, time step, and solver settings used for a specific model produce a result with acceptably small, ideally quantified, discretization error — the numerical error introduced purely by approximating a continuous field with a finite number of elements or cells. This is where mesh convergence studies live, and it is the single most commonly skipped step in simulation work performed under schedule pressure.

Mesh Convergence Studies in Practice

A mesh convergence study solves the identical model — same geometry, same loads, same boundary conditions, same material — at two or more progressively finer mesh densities and tracks how a specific output quantity of interest changes as the mesh refines. If that output value is still changing substantially between mesh levels, the coarser meshes are not yet trustworthy; the numerical answer has not separated itself from the noise of discretization error. As mesh density increases toward the theoretical limit of infinitely many, infinitely small elements, the numerical solution should approach the true, mesh-independent solution to the governing equations — this asymptotic approach is what a convergence study is trying to demonstrate has actually begun to happen at a practical, affordable mesh density.

The practical workflow is straightforward to describe and easy to skip under deadline pressure: build the model at a reasonable starting mesh density, solve it, refine the mesh (commonly by roughly halving the element size, or using a solver's automatic mesh-refinement tools), solve again, and compare the quantity of interest — peak von Mises stress at a fillet, drag coefficient on a body, first natural frequency of a structure — between the two runs. If the change is small relative to how the result will be used, the coarser of the two meshes is likely adequate; if the change is still large, refine again and repeat. A result reported from a single, unchecked mesh density carries an unknown and unquantified amount of discretization error, no matter how converged the solver's internal iteration residuals appear — internal solver convergence (the equations being solved to a tight numerical tolerance at a given mesh) and mesh convergence (the mesh itself being fine enough that further refinement would not change the answer) are two entirely different things, and confusing them is one of the most common mistakes junior analysts make.

The Grid Convergence Index and Richardson Extrapolation

A more rigorous version of a convergence study uses Richardson extrapolation, which exploits the fact that discretization error for a well-behaved numerical scheme decreases at a predictable rate (a known "order of convergence") as element size shrinks. By solving at three systematically refined mesh levels and comparing the results, it is possible to estimate the apparent order of convergence actually achieved and extrapolate toward the theoretical zero-cell-size answer. The Grid Convergence Index (GCI), developed from this method, converts that extrapolation into a standardized, reportable percentage uncertainty band around the finest-mesh result, giving a defensible number instead of a qualitative "the curve looked flat enough" judgment. Aerospace, defense, and increasingly automotive CFD work often requires a GCI or an equivalent formal discretization-uncertainty estimate precisely because it replaces a subjective call with a documented, repeatable calculation.

h-Refinement vs. p-Refinement

There are two distinct strategies for reducing discretization error, and understanding both is useful for knowing which convergence knob to turn.

h-refinement is the strategy most engineers reach for first: keep the same element type and polynomial order, and simply make the elements smaller (increase the element count), so that "h," the characteristic element size, shrinks. This is the strategy behind a standard mesh convergence study — halve the element edge length, re-solve, compare. It is intuitive and universally supported by every FEA/CFD package, but it scales poorly: in three dimensions, halving element size roughly increases element count (and thus solve time and memory) by a factor of eight.

p-refinement instead keeps the mesh (the element count and element size) fixed and increases "p," the polynomial order of the shape functions used within each element — moving, for instance, from linear to quadratic to cubic interpolation of displacement or velocity within an element. Higher-order elements can capture curved geometry and steep field gradients far more accurately per element than low-order elements, which means p-refinement can sometimes reach a converged, accurate answer with dramatically fewer elements and less solve time than pushing h-refinement alone, particularly for smooth stress or flow fields without singularities. Its practical drawback is that not every solver, element type, or problem class supports high polynomial orders equally well, and some geometric or material nonlinearities are harder to formulate accurately at high polynomial order. Many modern solvers offer adaptive p-refinement or combined hp-refinement, automatically raising polynomial order or subdividing elements specifically in regions where an internal error estimator detects the solution is changing rapidly, concentrating computational effort exactly where it is needed rather than uniformly refining the whole model.

Validation: Did We Solve the Right Equations?

Validation is the empirical counterpart to verification, and it asks a completely different question: does the mathematical model itself — the chosen physics, the material constitutive law, the boundary conditions, the assumed geometry simplifications — actually represent the real system well enough for the intended purpose? A model can be verified to extremely tight numerical tolerance (mesh-converged, solved to machine precision) and still be validated badly if, for example, it assumes linear-elastic material behavior for a load case that actually drives the part into plastic deformation, or assumes laminar flow for a regime that is actually turbulent, or omits a thermal boundary condition that turns out to dominate the real behavior.

Validation is fundamentally a comparison against physical reality: test data, instrumented prototype measurements, strain-gauge results, wind-tunnel data, or field performance history from a comparable existing design. Where direct test data on the exact configuration is not available, engineers often validate a simulation approach against a simpler benchmark case with a known analytical or well-established experimental result — for instance, validating a CFD turbulence-model setup against a published benchmark flow (flow over a backward-facing step, a standard NACA airfoil case) before trusting the same solver settings on a novel, un-tested geometry. The key discipline is that validation evidence should be documented and tied to the specific range of conditions it covers; a model validated against low-speed, low-temperature test data has not thereby been validated for high-speed or high-temperature operation, and extrapolating validation confidence beyond the tested regime is a subtle but common overreach.

Model Credibility and Uncertainty Quantification Basics

Beyond the verification/validation pair, mature simulation programs think in terms of overall model credibility: how much confidence is actually justified in this specific simulation result, for this specific decision, given everything that is and is not known about its accuracy. This depends on the "consequence" of the decision the simulation informs — a rough concept-selection trade study between two bracket geometries can tolerate a model with modest, loosely-quantified credibility, while a result that will directly justify removing a physical test or supporting a safety margin calculation needs a much higher, better-documented level of credibility, often assessed against a structured framework (such as the credibility factors laid out in ASME V&V 10 and V&V 20, or NASA-STD-7009 in aerospace) covering verification evidence, validation evidence, and the applicability of that validation evidence to the specific case at hand.

Uncertainty quantification (UQ) is the formal practice of tracking and combining the different sources of uncertainty in a simulation result rather than reporting a single deterministic number as if it were exact. Broadly, uncertainty splits into two categories: aleatory uncertainty, the inherent, irreducible randomness in a physical system (natural variation in material properties from batch to batch, manufacturing tolerances, real-world load variability), and epistemic uncertainty, uncertainty that exists because of incomplete knowledge or modeling simplification (an assumed but unmeasured boundary condition, a material model calibrated only over a limited temperature range, unquantified discretization error) — epistemic uncertainty can, in principle, be reduced with more testing, better data, or finer analysis, while aleatory uncertainty cannot. Full UQ analysis (Monte Carlo sampling of uncertain inputs, sensitivity analysis to identify which inputs matter most) is a substantial undertaking usually reserved for high-consequence programs, but the underlying mindset — reporting a result with an honest sense of its error bars and the specific assumptions it rests on, rather than a bare number with implied false precision — is a habit every simulation engineer should carry into every analysis, regardless of formality.

Common Red Flags in a Simulation Report

A handful of warning signs recur across weak simulation work, and any experienced reviewer learns to check for them immediately.

• No mesh convergence evidence at all. A single mesh, a single run, and a colorful contour plot presented as a final answer, with no indication the result was ever checked for mesh sensitivity.
• Undocumented or unjustified boundary conditions and loads. Fixed supports applied where a real structure actually has some compliance, symmetry boundary conditions applied to a geometry or load case that is not actually symmetric, or load magnitudes with no traceable source.
• Solver convergence criteria loosened to force a "converged" answer. A nonlinear structural solve or a CFD residual target relaxed specifically because the model would not converge at the default, tighter tolerance — often a sign of an underlying modeling problem (bad contact definition, an unstable mesh, an ill-posed boundary condition) being masked rather than fixed.
• A single-element or single-node peak value reported without context. Stress at a sharp reentrant corner, a point load, or a point constraint is mathematically singular — it increases without bound as the mesh refines rather than converging — so quoting a raw peak stress from such a location without acknowledging the singularity, or without using an appropriate technique (a fillet radius reflecting real geometry, a stress-linearization approach, or a hot-spot/notch-sensitivity method) is a classic way to report a numerically meaningless number as if it were a real engineering result.
• No comparison against anything independent of the simulation itself. No hand calculation, no test data, no comparison to a previous validated design — nothing tying the number back to a reality check outside the solver.

None of these red flags mean simulation results are untrustworthy by default; they mean the burden of proof sits with the analyst to show the convergence work, document the assumptions, and provide at least one independent sanity check. A simulation report that does this, even briefly, is worth far more than one that presents a beautifully rendered but unverified and unvalidated result as though the software's output were self-evidently the truth.