2. Crash simulation fundamentals for platform engineers

Platform engineers rarely write the constitutive equations themselves, but they own the infrastructure that executes them millions of times. To size clusters, tune solver defaults, and diagnose why one job finishes in 40 minutes while an identical-looking job runs for six hours, you need a working mental model of three things: how explicit dynamics advances time, how contact is detected and enforced, and how material models consume CPU. This chapter builds that model from the throughput perspective — every concept is tied to its cost.

Why Explicit Dynamics Dominates Crash Workloads

A crash event lasts roughly 50–150 ms of physical time, but the interesting physics — buckling, rupture, airbag deployment — happens at millisecond and sub-millisecond scales. Implicit solvers, which solve a global stiffness system K·Δu = f at every step, struggle here: severe nonlinearity, contact status changes, and near-singular stiffness from element distortion cause repeated Newton iterations and frequent convergence failures. Explicit dynamics sidesteps the linear solve entirely. It uses the central difference scheme:

u(n+1) = u(n) + Δt·v(n+1/2)
v(n+1/2) = v(n-1/2) + Δt·M⁻¹·(F_ext − F_int)

Because the mass matrix M is lumped (diagonal), M⁻¹ is a trivial element-wise division. There is no matrix factorization, no iteration, and no convergence check. Each step is cheap and predictable — which is exactly what makes throughput engineering tractable. The price is conditional stability: the Courant–Friedrichs–Lewy (CFL) condition requires

Δt ≤ Δt_crit = 2 / ω_max ≈ L_min / c

where L_min is the smallest element characteristic length and c is the dilatational wave speed √(E/ρ). This single inequality governs your entire cost model. Halving the smallest element doubles the step count. A single 0.5 mm sliver element in an otherwise 5 mm mesh can cut the stable time step by 10× and multiply wall-clock time accordingly.

Mass Scaling and Subcycling as Throughput Levers

Mass scaling artificially increases the density of small or stiff elements so their wave speed drops and the global stable step grows. Scaling density by factor f increases Δt_crit by √f. A common production target is a minimum time step of 1 µs; elements below that threshold get scaled. The trade-off is added kinetic energy — if the added mass exceeds roughly 1–2% of the model's total mass, inertial effects corrupt results. Platform tooling should therefore parse the solver's mass-scaling report and flag jobs where added mass crosses a configurable threshold.

Subcycling partitions the mesh into time-step hierarchies: small, stiff elements advance with their own smaller Δt while the bulk of the model advances with a larger one. This recovers much of the lost throughput without adding mass, at the cost of more complex bookkeeping and inter-partition force exchange. For platform engineers, subcycling is a solver flag and a memory-footprint consideration, not an algorithm to implement.

Contact: The Hidden Cost Center

Contact is where crash simulations diverge most from linear structural analysis. Two phases matter for cost: detection (finding candidate node–surface pairs) and enforcement (applying penalty forces or kinematic constraints).

Penalty-based contact is the default in most explicit codes because it is local and vectorizable. A penetrating node receives a restoring force proportional to penetration depth δ and a penalty stiffness k:

F_contact = k · δ,  with k ≈ α · (m / Δt²),  α typically 0.1–1.0

Choosing k too low allows visible penetration; too high forces a smaller stable time step, because the contact stiffness enters the CFL estimate. This coupling — contact stiffness feeding back into Δt_crit — is a frequent cause of "mysterious" slowdowns. When a job's time step collapses mid-run, suspect a newly engaged contact interface with an aggressive penalty scale factor.

Detection cost scales with the number of potentially interacting surface segments. Broad-phase algorithms (bucket sorting, bounding-volume hierarchies) reduce the candidate set, but self-contact in a folding structure can still generate large active contact sets. Platform observability should track contact interface counts and active contact element counts per time window.

Material Models and Their CPU Signature

Material models are evaluated at every integration point, every step. Their cost is not uniform, and the difference matters at scale. A linear elastic update is a few floating-point operations. A von Mises elastoplastic model with isotropic hardening requires a return-mapping iteration to project the trial stress back onto the yield surface — typically 5–20× the elastic cost. Johnson–Cook adds strain-rate and temperature dependence, and rate-dependent models may require sub-iterations when the strain rate changes rapidly.

For platform engineers, the practical implications are:

• Integration point count is a multiplier. A shell with 5 through-thickness integration points costs 5× a single-point shell for the material loop. Full-integration solid elements cost 8× a reduced-integration hex.
• Element formulation interacts with material cost. Reduced-integration elements need hourglass control, which adds a stabilization force computation — cheap per element but non-zero across millions of elements.
• Failure and erosion models add branching. Element deletion, damage accumulation, and tiebreak contact introduce conditional logic that reduces vectorization efficiency and can cause load imbalance across MPI ranks.

A Worked Throughput Diagnosis

Consider a full-vehicle frontal impact model: 8 million elements, initial stable time step 0.8 µs, simulated duration 120 ms. The naive step count is 120 ms / 0.8 µs = 150,000 steps. If the solver reports that the time step drops to 0.15 µs after 30 ms because a door latch detail engages contact with a high penalty scale, the remaining 90 ms runs at 0.15 µs — 600,000 additional steps. Total steps balloon from 150,000 to roughly 637,500, a 4.25× increase.

The fix is not more hardware. It is either (a) increasing the minimum time step target and letting mass scaling handle the latch detail, (b) reducing the penalty scale factor on that interface, or (c) subcycling the latch part. Each option has a result-quality cost that must be validated against a reference run. The platform's role is to make this diagnosis fast: surface the time-step history, correlate it with contact activation events, and let the engineer decide.

The through-line is that explicit crash simulation is predictable in structure but sensitive in parameters. The platform engineer's leverage comes from measuring the right quantities — time step, added mass, contact activation, per-rank load — and feeding them back to the analyst before the job wastes a node-hour. The next chapter moves from physics to the execution infrastructure that turns these measurements into automated decisions.