2. Crash simulation fundamentals for operators

An operator running a crash CAE platform does not need to write a solver, but must understand what the solver is doing well enough to recognize when a job is healthy, when it is drifting, and when it will never finish. Crash simulation is dominated by explicit dynamics, and almost every operational symptom — a job that runs for days, a sudden negative volume error, a contact that "explodes" — traces back to four fundamentals: the explicit time-integration scheme, the stable time step, contact treatment, and model scale. This chapter builds the working mental model an operator needs before touching a queue, a license, or a restart file.

Why Crash Uses an Explicit Solver

A crash event lasts roughly 50–150 ms and involves large deformation, self-contact, buckling, and material failure. An implicit solver would need to assemble and factor a global stiffness matrix at every increment and iterate to convergence — expensive and fragile when elements invert. An explicit solver instead advances the solution with the central difference method: accelerations are computed from the current force balance, then velocities and displacements are updated directly. No global matrix is factorized, no equilibrium iteration is required, and each increment is cheap. The trade-off is that the scheme is only conditionally stable, so the time step is bounded.

The equation of motion solved at each node is M·a = F_ext − F_int, where M is the lumped mass matrix, F_ext the applied loads (rigid wall, barrier, gravity), and F_int the internal element forces. Because M is lumped (diagonal), the acceleration update is a trivial division per node — this is exactly why explicit scales across thousands of cores.

The Stable Time Step

The stability limit for a linear element is Δt ≤ 2/ω_max, where ω_max is the highest natural frequency in the mesh. In practice solvers use the Courant–Friedrichs–Lewy form:

Δt_crit = L_c / c
c = sqrt(E / ρ)          (wave speed, elastic bar)
Δt = TSSF · Δt_crit      (TSSF = time step scale factor, default 0.9)

Here L_c is the characteristic element length and c the dilatational wave speed. For steel, E ≈ 210 GPa, ρ ≈ 7.85e-9 t/mm³, giving c ≈ 5.2 mm/ms. A 5 mm shell element therefore yields Δt_crit ≈ 0.96 µs. Over a 100 ms event that is roughly 100,000 increments — the number an operator should expect to see in the solver log.

The operational consequence is severe: the smallest element in the model sets the time step for the entire job. One stray 0.5 mm element in an otherwise 5 mm mesh multiplies runtime by ten. This is why mesh quality control and mass scaling are operator-level concerns, not just analyst concerns.

Mass Scaling and Its Limits

Mass scaling artificially increases the density of small or stiff elements so their Δt_crit rises to match the rest of the mesh. Selective mass scaling targets only elements below a threshold; global mass scaling scales everything. The operator must watch the added mass percentage reported in the log. A common acceptance rule is to keep added mass below 1–2% of total model mass for crash, because added mass changes inertia and therefore the physical result. If a job needs 5% added mass to run, the mesh — not the scaling — is the real problem.

Contact: The Most Common Source of Failure

Crash models are full of contact: vehicle-to-barrier, occupant-to-airbag, panel self-contact during folding. Explicit solvers use penalty-based contact, where a penetration generates a restoring force proportional to a penalty stiffness. The key operational parameters are:

• Contact thickness — for shells, the physical thickness plus an offset; too small causes missed contact, too large causes premature forces.
• Penalty scale factor — multiplies the default stiffness; raising it reduces penetration but can shrink the stable time step.
• Friction coefficients — static and dynamic; a wrong value silently changes energy absorption.
• Search frequency — how often contact pairs are re-detected; too infrequent misses new contacts, too frequent wastes time.

Contact stiffness feeds back into stability: a very stiff penalty contact can lower Δt_crit below the element-based value. This is why a job that ran fine before a contact card edit may suddenly slow down or diverge.

Model Scale and What It Means for Operations

Model scale determines resource requirements more than any other factor. A full vehicle frontal impact model typically contains 5–15 million elements, 200–500 contact interfaces, and 50–200 material models. The operator should track three scale indicators:

Domain decomposition splits the model across cores. Poor decomposition — for example, cutting through a dense contact region — creates excessive inter-processor communication and can dominate runtime. When a job scales poorly from 64 to 256 cores, decomposition quality is the first thing to inspect.

Reading the Solver Log as an Operator

The solver log is the primary diagnostic instrument. The operator should scan for these signals in order:

1. Initial time step — confirms the smallest element and mass scaling are as expected.
2. Added mass percentage — flags excessive scaling.
3. Energy balance — total, kinetic, internal, and hourglass energy. Hourglass energy above ~5% of internal energy indicates under-integrated elements are behaving badly.
4. Contact energy — a spike suggests a penetration event.
5. Time step evolution — a steadily shrinking Δt means elements are distorting; a sudden drop means contact or element failure.

The energy plot is the single most useful health check. In a well-behaved crash, kinetic energy rises then falls as internal energy absorbs the impact, and total energy stays nearly constant. A rising total energy means energy is being created numerically — almost always a contact or hourglass problem.

Putting It Together: A Pre-Submission Checklist

Before submitting any crash job, the operator should confirm the following. This is not a substitute for analyst review, but it catches the majority of operational failures.

Understanding these four fundamentals — explicit integration, the stable time step, penalty contact, and model scale — turns the operator from someone who submits jobs into someone who can predict, diagnose, and correct them. The solver log is not a black box; it is a continuous report on exactly these quantities, and reading it with the right mental model is the core operational skill in crash CAE.