2. Verification vs. validation in CAE

In computational mechanics, the words verification and validation are frequently used interchangeably in casual conversation, yet they answer two fundamentally different questions. Confusing them is one of the most common root causes of misplaced confidence in simulation results. This section establishes precise terminology, introduces the standard V&V frameworks that govern the discipline, and explains why the distinction has direct consequences at the program-management level.

The Two Core Questions

Verification asks: "Are we solving the equations right?" It is a mathematics-and-software concern. Verification confirms that the discretized equations are solved correctly and that the numerical error is quantified and controlled. It says nothing about whether the governing equations themselves represent physical reality.

Validation asks: "Are we solving the right equations?" It is a physics-and-application concern. Validation compares simulation predictions against experimental measurements of the real system to determine whether the mathematical model adequately represents the intended application.

Code Verification vs. Solution Verification

Verification itself splits into two distinct activities that are often conflated:

• Code verification — establishes that the software correctly implements the numerical algorithms. The primary tool is the Method of Manufactured Solutions (MMS): a smooth analytical solution is substituted into the governing PDE to derive a source term, the code is run with that source term, and the observed order of accuracy is compared against the formal order of the discretization scheme. A second common check is the grid-convergence index (GCI) study using systematically refined meshes.
• Solution verification — estimates the numerical error for a specific simulation. It quantifies discretization error, iterative convergence error, and round-off, typically through mesh-refinement studies and residual monitoring.

For example, in a linear-elastic static analysis, a code-verification test might impose a manufactured displacement field u(x,y) = sin(πx)cos(πy) on a unit square, derive the corresponding body force, and confirm that the L2 error norm decreases at the theoretical rate (e.g., second order for quadratic elements). If the observed slope on a log-log plot is 1.2 instead of 2.0, the implementation contains a defect that must be resolved before any validation claim is credible.

Validation and the Role of Experiments

Validation requires a validation metric — a quantitative measure of agreement between simulation and experiment. Common choices include relative error in a scalar quantity of interest (e.g., peak stress, drag coefficient, natural frequency), or a norm-based comparison over a field. Crucially, validation must account for both simulation uncertainty (numerical + input parameter) and experimental uncertainty (measurement + boundary condition). A validation statement without uncertainty bounds is incomplete.

The validation hierarchy matters: a component-level validation (e.g., a single lap joint under tension) does not automatically validate a full-system model (e.g., an automotive body-in-white under crash loading). Program managers must therefore define the validation domain explicitly and track which sub-models have been validated and to what extent.

Standard V&V Frameworks

Three frameworks dominate professional practice:

These frameworks share a common spine: separate verification from validation, quantify uncertainty, document evidence, and define the intended use of the model. The choice of framework is often dictated by industry — aerospace leans on NASA-STD-7009, pressure-vessel and nuclear work on ASME, and automotive CFD on AIAA G-077 — but the underlying logic is transferable.

Program-Level Implications

The verification/validation distinction is not academic; it reshapes how a CAE program is planned, resourced, and audited.

• Budget and schedule. Verification activities (MMS tests, mesh studies, regression suites) are predictable and can be automated. Validation activities require physical tests, instrumentation, and often iterative test-simulation correlation — they are schedule-critical and expensive. A program that budgets only for "simulation" without separating these lines will underfund validation.
• Evidence and traceability. Each claim of credibility must trace to a specific verification or validation activity. Program managers should maintain a V&V evidence register that links each model to its verification status, validation domain, and uncertainty bounds.
• Risk management. A model used outside its validated domain is a program risk. The register makes that risk visible and allows informed decisions about additional testing or conservative margins.
• Acceptance criteria. Contracts and internal gates should specify verification deliverables (e.g., grid-convergence report, code-verification log) and validation deliverables (e.g., correlation report with uncertainty) as separate line items.

Worked Example: A Pressure-Vessel Nozzle

Consider a program assessing a cylindrical pressure vessel with a reinforced nozzle. The quantity of interest is the peak von Mises stress at the nozzle-shell intersection under internal pressure.

1. Code verification: Run an MMS test on the same element type and solver settings. Confirm second-order convergence. Record the observed order and the GCI.
2. Solution verification: Perform a three-mesh refinement study (e.g., 0.5 mm, 0.25 mm, 0.125 mm characteristic length at the intersection). Compute the GCI and report the discretization error band on the peak stress.
3. Validation: Compare against a strain-gauge measurement from a physical burst test or a benchmark from a recognized code case. State the experimental uncertainty (e.g., ±3% gauge accuracy) and the simulation uncertainty (e.g., ±5% from mesh and material scatter). The validation metric is the relative difference in peak stress, judged against the combined uncertainty.
4. Decision: If the difference falls within the combined uncertainty band, the model is validated for this domain. If not, investigate material model, boundary conditions, or mesh before extending the model to other geometries.

Typical failure symptoms and troubleshooting: if the observed order of accuracy is below theoretical, check for insufficient mesh resolution in high-gradient regions or a bug in the source-term implementation. If validation disagreement is large but verification passes, suspect the constitutive model, boundary conditions, or experimental setup rather than the solver.

The diagram above summarizes the two evidence streams and their program-level consequences. Verification and validation are not sequential phases to be checked off; they are parallel, ongoing evidence streams that together support a credibility claim. A program that treats them as a single "simulation task" will systematically underinvest in one or the other — usually validation, because it is the more expensive and less automatable of the two.

In the next section, we will examine how these concepts map onto specific CAE disciplines and how to structure a V&V plan that satisfies both technical and programmatic requirements.