4. Verification activities

Verification answers a narrow but essential question: are we solving the equations correctly? It is distinct from validation, which asks whether the equations themselves represent the physical reality of interest. In a crash simulation credibility plan, verification is the first gate. If the solver contains a coding defect, or if the discretized solution has not converged, then any subsequent comparison against physical test data is contaminated by numerical error that cannot be separated from modeling error. This chapter covers the three verification activities that must be planned and documented for explicit crash solvers: code verification, solution verification, and mesh convergence studies.

Code Verification: Establishing That the Solver Implements the Intended Equations

Code verification is a software-quality activity. Its purpose is to demonstrate that the implementation matches the mathematical model — no more, no less. For explicit crash solvers, the most rigorous and widely accepted technique is the Method of Manufactured Solutions (MMS). The procedure is straightforward in principle: choose a smooth analytical solution, substitute it into the governing partial differential equations to derive the required source terms and boundary conditions, run the code with those terms imposed, and measure the discretization error against the known exact solution as the mesh is refined. The observed order of accuracy should match the theoretical order of the spatial discretization scheme.

For an explicit dynamic solver, MMS is applied to the semi-discrete momentum equation. A representative manufactured displacement field for a 1D elastic bar is:

u(x,t) = A · sin(kx) · sin(ωt)
with A = 1.0e-3 m, k = 2π/L, ω = 2π/T, L = 1.0 m, T = 1.0e-3 s

Required body force from momentum balance:
  f(x,t) = ρ·ü − E·u_xx
         = ρ·(−A·ω²·sin(kx)·sin(ωt)) − E·(−A·k²·sin(kx)·sin(ωt))
         = A·(E·k² − ρ·ω²)·sin(kx)·sin(ωt)

With ρ = 7850 kg/m³, E = 210 GPa, the source term is fully determined. The analyst then runs a sequence of uniform meshes (e.g., 20, 40, 80, 160, 320 elements) with a fixed CFL number, computes the L2 norm of the displacement error at a fixed time, and fits the convergence rate p from log(error) versus log(h). For a consistent second-order element formulation, the observed rate should approach 2.0. A rate significantly below the theoretical value — say 1.2 instead of 2.0 — signals a defect in the element formulation, the time integration, or the boundary condition application.

Beyond MMS, code verification for explicit solvers should include regression tests against analytical benchmarks: the Taylor bar impact (rigid-plastic wave propagation), the 1D elastic bar wave speed check (c = √(E/ρ)), and energy conservation in an undamped free-vibration case. These are cheap to run and catch gross errors quickly.

Solution Verification: Quantifying Numerical Error in a Specific Simulation

Solution verification asks: for this model, how large is the numerical error? It does not require an exact solution. The standard approach is Richardson extrapolation applied to a systematic mesh refinement study. The analyst runs the same model on three meshes of increasing refinement (coarse, medium, fine) with a constant refinement ratio r (typically 1.5 or 2.0), extracts a scalar quantity of interest (QoI) — peak intrusion, peak acceleration, energy absorption, or a specific nodal displacement — and computes the observed order of convergence and the discretization error estimate.

Given QoI values: Q1 (coarse), Q2 (medium), Q3 (fine), r = 2.0

Observed order:  p = ln[(Q1 − Q2)/(Q2 − Q3)] / ln(r)
Extrapolated value: Q_ext = Q3 + (Q3 − Q2)/(r^p − 1)
Relative discretization error on fine mesh: e = |Q3 − Q_ext| / |Q_ext|

For crash simulations, the QoI is rarely smooth in time — peak acceleration is notoriously noisy and may not converge monotonically. In such cases, use a time-averaged or filtered QoI (e.g., 50 ms moving average of acceleration, or total internal energy at a fixed time) and report the convergence behavior honestly. If the three-mesh sequence does not show monotonic convergence, the mesh study is inconclusive and a fourth mesh or a different QoI should be selected. The credibility plan should state the acceptance criterion explicitly: for example, "discretization error on the fine mesh shall be below 5% for peak intrusion and below 10% for filtered peak acceleration."

Mesh Convergence Studies for Explicit Crash Models

Explicit crash models present specific mesh convergence challenges that differ from implicit static analysis. The time step is governed by the smallest element (Δt ≤ L_min/c), so uniform refinement of the entire model is computationally prohibitive. Practical convergence studies therefore focus on the crush zone — the region that undergoes large plastic deformation and folding — while keeping the non-critical regions at a fixed mesh density. The refinement ratio should be applied consistently within the crush zone, and the transition region must be far enough from the QoI extraction location that it does not influence the result.

A defensible mesh convergence study for a frontal impact model might proceed as follows. The baseline crush-zone element size is 8 mm. Two additional meshes at 5.3 mm and 4 mm (r ≈ 1.5) are generated by refining only the front rail, bumper, and crash box. The QoIs are peak intrusion at the firewall, total energy absorbed at 80 ms, and filtered peak deceleration at the B-pillar base. The study is run with the same material cards, contact definitions, and time step control (mass scaling disabled or held constant). Results are tabulated and the observed convergence rate is computed. If the fine mesh differs from the medium mesh by less than the acceptance threshold, the medium mesh may be adopted for production, provided the extrapolated error is documented.

The figure above summarizes the three verification activities as a sequential gate structure, with a representative convergence plot and QoI table. Note that the table values are illustrative and would be replaced by actual run results in a project credibility plan.

Documenting Verification in the Credibility Plan

Each verification activity must leave a traceable record. For code verification, record the solver version, the MMS case definition, the mesh sequence, the observed order of accuracy, and the pass/fail judgment against the theoretical order. For solution verification, record the three mesh definitions, the QoI extraction method (including any filtering), the computed p, Q_ext, and relative error, and the acceptance threshold with its justification. For mesh convergence, record the refinement strategy, the element sizes, the QoIs, and the selected production mesh with the supporting error estimate.

A common failure mode in crash simulation projects is to perform a mesh convergence study on a simplified model and then apply the resulting mesh density to a different, more complex model without re-verification. The credibility plan should explicitly state the scope of each verification result — which model configuration, which QoIs, and which loading condition it covers — and require re-verification when the model topology or the dominant deformation mode changes. Verification is not a one-time checkbox; it is a documented, scoped, and repeatable activity that underpins every subsequent validation claim.