2. Crash simulation fundamentals

Automotive crash simulation is a transient, highly nonlinear structural dynamics problem. A vehicle body striking a rigid barrier at 56 km/h (35 mph) must be resolved over roughly 100–150 ms of physical time, during which sheet-metal panels fold, spot welds rupture, and contact conditions change thousands of times. This chapter establishes the computational foundation that the rest of the course builds on: why explicit finite element analysis (FEA) is the standard method, how LS-DYNA and Radioss implement it, and what a production crash model actually looks like in terms of size and cost.

Why Explicit Integration Dominates Crash Analysis

The governing equation is Newton's second law in discretized form: M a = F_ext − F_int, where M is the mass matrix, a the nodal acceleration vector, and F_ext and F_int the external and internal force vectors. The internal forces include element stresses, hourglass control, and contact penalties — all of which depend nonlinearly on displacement.

Implicit solvers (e.g., Abaqus/Standard, OptiStruct) solve this system by iterating on equilibrium at each time step, requiring the factorization of a large stiffness matrix. For crash, that approach fails for two reasons: contact and material nonlinearity cause frequent convergence failures, and the factorization cost scales poorly with model size. Explicit solvers instead use the central difference method, which is conditionally stable and requires no matrix inversion. The acceleration at time t_n is computed directly from known forces, then velocities and displacements are updated:

a_n = M⁻¹ (F_ext − F_int)
v_(n+1/2) = v_(n−1/2) + a_n · Δt
d_(n+1)   = d_n + v_(n+1/2) · Δt

The critical constraint is the Courant–Friedrichs–Lewy (CFL) condition: the stable time step is bounded by the smallest element in the mesh. For a shell element, Δt ≈ L_c / c, where L_c is the characteristic length and c is the wave speed in the material. In steel, c ≈ 5,000 m/s. A 5 mm shell element therefore yields Δt ≈ 1 μs, meaning a 120 ms crash event requires roughly 120,000 time steps. This is the defining cost driver of explicit crash simulation, and it explains why mesh quality — not solver choice — usually determines whether a job finishes overnight or over a weekend.

LS-DYNA and Radioss: Two Production Solvers

LS-DYNA (originally developed at Lawrence Livermore National Laboratory, now owned by Ansys) and Radioss (developed by Altair, now part of HyperWorks) are the two dominant explicit codes in automotive crash. Both implement the same core algorithms — central difference time integration, penalty-based contact, and a large library of material models — but differ in input format, element technology defaults, and parallel scalability characteristics.

LS-DYNA uses a keyword input deck (*KEYWORD cards) and is widely regarded as the reference implementation for crashworthiness, with the broadest material and contact model library. Radioss uses a block-structured input format and is tightly integrated with HyperMesh and HyperCrash for model assembly and checking. In practice, OEMs often run both: LS-DYNA for occupant safety and full-vehicle frontal impact, Radioss for side impact and pedestrian protection, depending on legacy model libraries and solver validation history.

Both codes support shared-memory (SMP) and distributed-memory (MPP) parallelism. MPP scaling is typically near-linear up to a few hundred cores for a 10–20 million element model, after which communication overhead in contact search and element force assembly becomes significant. This scaling behavior is the primary reason hybrid cloud bursting is attractive: on-premise clusters are sized for average load, while peak design iterations can be offloaded to cloud instances.

Typical Model Sizes and Their Cost Profile

Crash model size is usually expressed in millions of elements, dominated by shell elements representing stamped steel and aluminum panels. The table below summarizes representative model classes encountered in automotive practice. These figures are typical ranges, not fixed values; a specific program's model depends on mesh targets, weld representation, and whether the model includes a full interior.

The wall-clock estimates assume a well-balanced MPP decomposition and a model free of severe mass-scaling. In practice, engineers apply mass scaling — artificially increasing the density of small elements — to raise the stable time step. A common target is Δt ≥ 0.7 μs for full-vehicle models. Mass scaling is a trade-off: it adds non-physical inertia that can alter low-frequency structural response, so it must be applied selectively and its effect on energy balance verified.

Energy Balance as the Primary Sanity Check

Before interpreting any crash result, the analyst checks the energy balance. LS-DYNA and Radioss both report kinetic energy, internal energy, hourglass energy, and sliding interface energy. The sum of internal, kinetic, and hourglass energy should approximately equal the initial kinetic energy minus energy absorbed by boundary conditions. Two red flags are common:

• Hourglass energy exceeding 5% of peak internal energy — indicates under-integrated elements are behaving too softly; switch to fully integrated shells or refine the mesh in the affected region.
• Added mass from mass scaling exceeding 1–2% of total model mass — indicates the scaling is distorting the physics; reduce the scaling factor or remesh the offending elements.

These checks are not optional. A model that runs to completion but violates energy balance produces meaningless intrusion and acceleration results, and the error is often invisible in the contour plots.

Practical Implications for Hybrid Cloud HPC

Three properties of crash simulation shape every infrastructure decision in this course. First, the workload is bursty: a design team may run 20–50 full-vehicle variants in a week, then idle for days. Second, individual jobs are long-running and checkpoint-sensitive: a 24-hour MPP job that fails at hour 20 wastes substantial compute, so restart files and node-failure tolerance matter. Third, the jobs are tightly coupled: MPP decomposition requires low-latency interconnects, which constrains instance selection and placement on cloud.

A useful rule of thumb when planning capacity: a full-vehicle frontal model at 12 M elements with Δt = 0.7 μs and 120 ms simulated time requires approximately 170,000 time steps. At an observed throughput of 8–15 μs of simulated time per wall-clock hour per 256 cores (a typical range for well-scaled MPP runs), the job completes in 8–15 hours. Doubling cores rarely halves the time beyond ~512 cores; the scaling curve flattens as contact search and communication dominate. This is why hybrid cloud strategies emphasize job throughput — running more concurrent models — rather than chasing single-job speedup.

The next chapter moves from solver mechanics to model build and validation, where mesh quality, weld representation, and material card selection determine whether the explicit solver receives a physically meaningful problem to solve.