2. Numerical quality dimensions
In CAE practice, "the model ran" and "the model is trustworthy" are separated by a structured set of quality dimensions. Release decisions cannot rest on a single convergence plot or a visually plausible contour. They require evidence that the numerical solution is correct for the equations being solved, that the equations represent the physical reality of interest, and that the remaining uncertainty is quantified and acceptable for the intended decision. These three concerns map onto verification, validation, and uncertainty quantification (UQ). Each answers a different question, and each contributes a distinct type of evidence to the release audit.
Verification: Solving the Equations Right
Verification is a mathematical and numerical activity. It asks whether the discrete model has been implemented correctly and whether the discretization error is controlled. It is independent of physical test data. Two subcategories are conventionally distinguished:
- Code verification — confirming that the software implements the intended numerical algorithms. The standard technique is the method of manufactured solutions (MMS): a smooth analytical solution is substituted into the governing equations to derive a source term, the code is run with that source term, and the observed order of accuracy is compared against the theoretical order. A typical acceptance criterion is that the observed order falls within roughly ±10% of the formal order across at least three systematically refined meshes.
- Solution verification — estimating the discretization error for the specific case at hand. This is where mesh convergence studies, Richardson extrapolation, and grid convergence indices (GCI) enter the audit record.
For a solution verification study, the practical procedure is concrete. Run the case on three geometrically similar meshes with a constant refinement ratio r (commonly 1.3–2.0), extract a scalar quantity of interest (QoI) — for example, peak von Mises stress at a weld toe, or total drag coefficient — and compute the observed order p from the differences between successive solutions. With QoIs f1 (fine), f2 (medium), and f3 (coarse):
p = ln( (f3 - f2) / (f2 - f1) ) / ln(r)
f_extrapolated = f1 + (f1 - f2) / (r^p - 1)
GCI_fine = Fs * |(f1 - f2) / f1| / (r^p - 1) with safety factor Fs = 1.25 (three meshes)
If the observed p is negative, oscillatory, or far from the formal order, the study is not converged in the asymptotic range and the mesh family must be revised before the result can be released. A common failure symptom is a QoI that changes monotonically with refinement but never stabilizes — often caused by a singular feature (sharp re-entrant corner, point load) where the true solution has unbounded gradients and pointwise convergence is not expected. In that case the QoI should be redefined as an integrated or averaged quantity.
Validation: Solving the Right Equations
Validation compares the computational model against experimental data representing the intended application. It is a physical activity, and its output is a statement of how well the model reproduces reality within a defined validation domain. A validation activity is only meaningful when the experimental uncertainty is itself characterized and when the comparison metric is defined in advance.
A defensible validation record includes: the validation domain (geometry range, load range, material condition), the experimental reference with its measurement uncertainty, the comparison metric (relative error in QoI, confidence-interval overlap, or area validation metric), and the acceptance threshold agreed with the decision-maker. For example, a bracket stiffness model might be validated against a static test with a measured tip deflection of 2.40 mm ± 0.08 mm (expanded uncertainty, k = 2). If the simulation predicts 2.55 mm, the relative error is 6.3%, but the difference of 0.15 mm exceeds the experimental uncertainty band of 0.08 mm — the model is not validated for that QoI without further justification. Reporting only the percentage error hides this distinction.
Uncertainty Quantification: Bounding What Remains
UQ aggregates the remaining sources of uncertainty into a defensible interval or distribution around the QoI. Sources fall into three families: input uncertainty (material properties, geometric tolerances, boundary conditions), model-form uncertainty (constitutive assumptions, turbulence closures, contact idealizations), and numerical uncertainty (the discretization error estimated during solution verification).
A practical workflow for a release audit is a first-order sensitivity screen followed by propagation. Take a weld-toe stress model with three dominant inputs: yield strength (350 ± 20 MPa), plate thickness (8.0 ± 0.15 mm), and fillet radius (2.0 ± 0.3 mm). A one-at-a-time perturbation of ±1σ on each input, run through the same verified model, gives local sensitivity coefficients. If thickness dominates, the audit can focus computational effort there. Propagation then uses either a first-order second-moment (FOSM) estimate or a small Latin hypercube sample (e.g., 50–100 runs) to produce a 95% coverage interval on the QoI. The numerical uncertainty from the GCI is then added in quadrature or as a conservative bound, and the model-form uncertainty is carried as a separate bias term with documented justification.
The output of UQ is not a single number but a statement such as: "peak weld-toe stress = 182 MPa, 95% interval [168, 197] MPa, including numerical discretization uncertainty of ±3.1 MPa and model-form bias of +4% (conservative)." That statement is what a release decision can actually consume.
How the Three Dimensions Feed the Release Decision
The three dimensions are not interchangeable, and a release decision must reference all three. Verification without validation produces a numerically clean answer to possibly the wrong question. Validation without verification can attribute a discretization error to a physical discrepancy. UQ without either is a distribution around an unverified, unvalidated number.
A practical release gate can be expressed as a decision table keyed to the intended use of the model:
| Release use | Verification evidence required | Validation evidence required | UQ requirement |
|---|---|---|---|
| Concept screening / trend ranking | Mesh convergence on QoI; GCI < 10% | Qualitative agreement with prior test or handbook | Sensitivity ranking of top three inputs |
| Design verification against a limit | GCI < 5%; observed order within tolerance | Quantitative validation within stated domain | 95% interval on QoI; margin vs. limit documented |
| Certification / safety-critical release | Code verification (MMS) + GCI < 2% | Validation with experimental uncertainty and metric | Full propagation incl. model-form bias; auditable record |
The decision logic is then a margin check: the upper bound of the QoI interval, including model-form bias, must remain below the allowable limit with the agreed safety margin. If it does not, the release is conditional or rejected, and the audit record must state which dimension is deficient — insufficient mesh convergence, out-of-domain validation, or unquantified input scatter.
Audit Implications
For the release auditor, the practical consequence is that each dimension must leave a traceable artifact: a convergence table with the computed GCI, a validation report with the experimental uncertainty and metric, and a UQ summary with the interval and its constituent contributions. When a release is challenged, the audit should be able to point to the specific dimension that is weak and the specific evidence that is missing. That traceability — not the elegance of the contour plot — is what makes a CAE model releasable.