1. Reproducibility challenges in crash CAE

Reproducibility challenges in crash CAE 学习卡片

Crash CAE is one of the most demanding reproducibility problems in computational engineering. A full-vehicle frontal impact model may contain 8–15 million elements, dozens of material laws, multiple contact interfaces, spotweld and adhesive representations, and a solver deck that has evolved over years. When two engineers run "the same" model and obtain occupant injury values that differ by 5–10%, the disagreement is rarely caused by a single mistake. It is usually the superposition of several independent nondeterminism sources, each small on its own, that together exceed the tolerance of a regulatory or design decision.

This chapter establishes the vocabulary and mental model for the rest of the course: what actually varies between two crash CAE runs, why it varies, and how to tell the difference between a genuine model change and an environment-induced artifact.

Three Families of Nondeterminism

It is useful to separate reproducibility failures by their origin, because the mitigation strategy differs completely for each family.

  • Algorithmic / numerical nondeterminism. The solver itself does not guarantee bit-identical results across runs. Domain decomposition, contact search ordering, floating-point reduction order in parallel assembly, and adaptive time-step logic all introduce run-to-run variation. Explicit crash solvers such as LS-DYNA, Radioss, and Abaqus/Explicit are especially sensitive because the critical time step depends on the smallest element and the current wave speed.
  • Environment nondeterminism. Solver build, compiler version, math library (MKL, OpenBLAS, ACML), MPI implementation, thread count, and CPU instruction set all change the arithmetic path. A model run on 64 cores of one cluster and 64 cores of another can produce different hourglass energy and different peak forces.
  • Model / data nondeterminism. Includes unit systems, material card defaults, initial velocity application, gravity, contact thickness offsets, and — very commonly — silent differences in included files, keyword versions, or pre-processor export settings.
A practical rule: if two runs differ by less than ~1% in global energy and peak acceleration, the difference is usually numerical noise. If they differ by more than ~3%, suspect an environment or model difference before blaming the solver.

Where Solver Version Drift Bites

Solver version drift is the most under-estimated source of irreproducibility in crash CAE, because it is invisible in the input deck. The same *CONTROL_TIMESTEP or /DT/NODA card can behave differently after a minor release. Typical drift mechanisms include:

  • Changed default values for contact stiffness, penalty scale factors, or hourglass control coefficients.
  • New or modified material model formulations (e.g., strain-rate curves, failure criteria, damage regularization).
  • Different element formulations or default integration orders for shells and solids.
  • Changes in mass scaling logic and time-step estimation.
  • Compiler and vectorization changes that alter floating-point summation order.

Because these changes are documented only in release notes and sometimes not at all, the only reliable defense is to pin the solver build and record it as part of the model metadata. A version string such as ls-dyna smp s R11.1.0 is not sufficient; the exact build hash, compiler, and math library must be captured.

Hardware-Dependent Results

Hardware dependence is often confused with solver nondeterminism, but the mechanisms are distinct. The dominant hardware factors are:

Factor Effect on crash results Typical magnitude
Core count / MPI ranks Changes domain decomposition and reduction order 0.1–2% in peak force
CPU architecture (AVX2 vs AVX-512) Different FMA and vectorization paths 0.01–0.5%
Math library version Different BLAS/LAPACK kernels 0.01–0.3%
Thread count (SMP) Race conditions in contact and element loops 0–1%, occasionally larger
GPU vs CPU solver Different arithmetic precision and ordering 1–5%

These numbers are illustrative ranges observed in published crash CAE studies, not guarantees. The important point is that they are not zero, and they accumulate. A 0.5% difference in peak force can flip a pass/fail decision when the margin is small.

Why "Same Model, Same Result" Is a Myth

The following SVG summarizes the causal chain from a single input deck to divergent outputs. It is not a flowchart of steps; it is a map of where variation enters the pipeline.

Sources of Nondeterminism in a Crash CAE Run Input Deck .k / .rad / .inp Pre-processor export settings, units Solver Build version, compiler, math lib Hardware / Runtime cores, MPI, threads, GPU Numerical Path decomposition, reduction order Results forces, energy, injury deck model data build runtime solve accumulated variation Key insight: Each stage contributes a small, often invisible perturbation. Reproducibility is achieved by controlling all three families simultaneously — not by fixing one and hoping the others are negligible.

What This Means for Your Workflow

The practical consequence is that "reproducible" must be defined operationally. A useful definition for crash CAE teams is:

A result is reproducible if, given the same input deck, the same solver build, the same hardware class, and the same runtime configuration, the run produces outputs within a pre-declared tolerance (e.g., peak force within 1%, energy balance within 0.5%, and identical pass/fail status).

This definition forces three concrete actions:

  1. Capture the environment. Record solver build hash, compiler, MPI, math library, core count, and thread count alongside every result. A run without this metadata is not reproducible, even if the deck is perfect.
  2. Declare tolerances before comparing. Decide what "same" means numerically. Without a tolerance, every comparison becomes an argument.
  3. Separate model changes from environment changes. When two results differ, first re-run the same deck on the same environment to measure baseline noise. Only then attribute the remaining difference to the model.

A Minimal Reproducibility Record

The following is a compact, directly usable record that can be attached to any crash CAE run. It is intentionally small so that it is actually filled in.

run_id:           FRONTAL-50KPH-001
model_deck:       frontal_50kph_v12.k
deck_sha256:      3f9a...c21e
solver:           LS-DYNA smp s R11.1.0
solver_build:     build_2023-08-14_hash_a7c3
compiler:         Intel oneAPI 2023.2
math_lib:         MKL 2023.2
mpi:              Intel MPI 2021.10
cores:            64
threads_per_rank: 1
gpu:              none
os:               RHEL 8.8
tolerance_peak_force: 1.0%
tolerance_energy:     0.5%
result_peak_force:    182.4 kN
result_energy_error:  0.21%
status:           PASS

This record is not bureaucracy. It is the minimum evidence required to answer the question "did the model change, or did the environment change?" Without it, every discrepancy investigation starts from zero.

Common Failure Symptoms and First Checks

Symptom Likely cause First check
Peak force differs by 2–5% between runs Different core count or solver build Compare run metadata; re-run on identical config
Hourglass energy grows unexpectedly Changed hourglass control default or element formulation Diff solver release notes; check *HOURGLASS card
Contact penetration differs Contact stiffness default or penalty scale changed Compare *CONTACT defaults across versions
Time step collapses earlier Mass scaling or element distortion logic changed Check *CONTROL_TIMESTEP and mass scaling output
Results differ only on GPU Precision or reduction order difference Run CPU reference; declare GPU tolerance separately

The rest of this course builds on this foundation. Each subsequent chapter addresses one part of the reproducibility problem in depth: how to pin solver environments, how to structure model repositories, how to design regression tests for crash CAE, and how to audit results when tolerances are exceeded. The goal is not to eliminate nondeterminism — that is impossible in explicit dynamics — but to make it measurable, bounded, and documented.

← Previous 📖 Contents Next →