3. Vehicle crash simulation workflow

A vehicle crash simulation is not a single action but a chain of tightly coupled decisions. A model that looks correct in the preprocessor can still produce meaningless results if the solver setup violates explicit time-step stability, and a stable run can still mislead if the post-processing extracts the wrong signal or evaluates it against the wrong criterion. This section walks through the four stages of the LS-DYNA workflow and the key performance indicators (KPIs) that connect them.

Preprocessing: Building a Solvable Model

Preprocessing covers geometry cleanup, meshing, material definition, connection modeling, and boundary/initial conditions. The dominant cost driver is mesh size: the smallest element in the model sets the explicit time step through the Courant condition

Δt = L_c / c,   c = sqrt(E / ρ)

where L_c is the characteristic element length and c is the sound speed in the material. For steel (E ≈ 210 GPa, ρ ≈ 7.85e-9 t/mm³), c ≈ 5.17 mm/ms. A 5 mm shell element therefore gives Δt ≈ 0.97 µs, and a 100 ms event needs roughly 10⁵ cycles. Halving element size doubles the cycle count, so mesh refinement must be justified by the physics it resolves.

Typical practice for a full-frontal rigid-barrier model at 50 km/h:

  • Body-in-white (BIW) shell elements: 5–8 mm in crush zones, 10–15 mm in non-deforming regions.
  • Spot welds: *CONSTRAINED_NODAL_RIGID_BODY or *MAT_SPOTWELD with a failure strain, not rigid ties across the whole flange.
  • Materials: *MAT_PIECEWISE_LINEAR_PLASTICITY (MAT_024) with strain-rate curves for mild steel; *MAT_024 or *MAT_036 for high-strength steel.
  • Contact: *CONTACT_AUTOMATIC_SINGLE_SURFACE for self-contact, *CONTACT_AUTOMATIC_SURFACE_TO_SURFACE for barrier-to-vehicle.

Two preprocessing checks prevent most wasted solver time. First, run a mass-scaling audit: *CONTROL_TIMESTEP with DT2MS negative activates mass scaling, and the added mass should stay below 1–2% of total model mass. Second, verify initial penetration in contact with *CONTACT output; penetrations above roughly 0.5 mm cause artificial energy spikes at t = 0.

Solver Setup: Controls That Decide Accuracy

The solver deck is where the simulation either converges to a physically meaningful answer or silently drifts. The essential controls are:

KeywordPurposeTypical Setting
*CONTROL_TERMINATIONEnd time100–150 ms for full frontal
*CONTROL_TIMESTEPTime-step controlDTINIT = 0, TSSFAC = 0.9
*CONTROL_ENERGYHourglass/energy trackingHGEN = 2, RWEN = 2
*DATABASE_BINARY_D3PLOTState output frequencyEvery 1–2 ms
*DATABASE_ASCII_GLSTATGlobal energy historyEvery 0.1 ms

Hourglass control deserves explicit attention. Under-integrated shell elements (ELFORM = 2) are fast but prone to zero-energy modes. Set IHQ = 4 (stiffness-based) or IHQ = 5 and monitor hourglass energy in glstat; it should remain below 5% of internal energy. If it exceeds 10%, refine the mesh locally or switch to fully integrated elements (ELFORM = 16) in the affected region.

Energy balance is the primary sanity check. At any time, the sum of kinetic, internal, hourglass, and sliding interface energy should equal the initial kinetic energy minus external work, with total energy drift under 5%. A sudden jump in sliding interface energy usually indicates a contact problem; a growing hourglass term indicates a mesh or element formulation problem.

Post-Processing: From D3plot to Engineering Insight

LS-PrePost is the standard viewer. The workflow is: load d3plot, inspect deformation and stress fringe plots, then extract time-history curves from nodout, glstat, and secforc. For occupant safety, the critical signals are accelerations at the seat track, B-pillar, and steering column, filtered according to SAE J211 (CFC 60 for occupant response, CFC 180 for structural acceleration).

Filtering is not optional. Raw accelerometer data contains high-frequency noise that inflates peak values. SAE J211 specifies a low-pass Butterworth filter; applying CFC 60 to a chest acceleration signal typically reduces the peak by 10–20% compared with unfiltered data. Always report the filter class alongside the KPI.

Key Performance Indicators

Structural and occupant KPIs answer different questions. Structural KPIs assess whether the body absorbs energy without excessive intrusion; occupant KPIs assess injury risk.

KPIDefinitionTypical Target
B-pillar intrusionMaximum lateral displacement at beltline< 150 mm
Toe pan intrusionLongitudinal displacement at footwell< 200 mm
Steering column displacementRearward motion toward driver< 100 mm
HIC36Head injury criterion, 36 ms window< 700 (FMVSS 208)
Chest deflectionRib cage compression< 50 mm
Femur forceAxial load per leg< 10 kN

HIC is computed as

HIC = max[(t2 - t1) * (1/(t2-t1) * ∫ a dt)^2.5]

where a is the resultant head acceleration in g and the window t2 - t1 is at most 36 ms. A HIC of 700 corresponds roughly to a 5% probability of severe head injury (AIS 3+).

When a KPI misses its target, check the energy balance before changing the design. A 15% hourglass energy or a 20% energy drift often explains an anomalous intrusion or acceleration peak better than a genuine structural weakness.

Workflow Integration

The four stages are not sequential in practice; they form a feedback loop. A post-processing finding such as excessive hourglass energy sends you back to preprocessing for mesh refinement, while a contact energy spike sends you back to solver setup for contact parameter tuning. The SVG below summarizes the data flow and the decision points that connect the stages.

Preprocessing Mesh, materials, contacts Boundary & initial conditions Mass scaling audit Initial penetration check Solver Setup Termination, time step Hourglass control Energy tracking Output frequency Post-Processing D3plot inspection Time-history extraction SAE J211 filtering KPI computation Key Performance Indicators Structural: intrusion, energy absorption Occupant: HIC, chest deflection, femur force Energy: hourglass < 5%, drift < 5% Feedback: refine mesh, adjust contacts, re-run KPI met? Evaluate Yes → report No → iterate

The loop is the point: a crash simulation is rarely correct on the first run. The engineer's job is to read the energy balance, identify which stage introduced the error, and iterate with a specific correction rather than a blind re-run.