2. CAE simulation workflow for crashworthiness

A crashworthiness CAE run is not a single action but a chain of dependent stages. Each stage consumes the output of the previous one, and a defect introduced early — a missing spot weld, a wrong material card, an unconverged initialization — will propagate silently until the solver either terminates abnormally or, worse, produces a plausible-looking but physically wrong result. This chapter walks through the four stages that define the workflow: model preparation, solver execution, post-processing, and data management. The emphasis is on what actually happens inside each stage, which inputs matter, and how to judge whether the stage succeeded before moving on.

Stage 1 — Model Preparation

Model preparation converts CAD geometry into a solver-ready deck. For a full frontal impact model, this typically means a mesh of 5–8 million elements, of which the vehicle body-in-white contributes the majority. The preparation sequence is: geometry cleanup, meshing, connection definition, material and property assignment, boundary and initial conditions, and finally output request configuration.

Geometry cleanup removes slivers, overlaps, and duplicate surfaces that would otherwise generate degenerate elements. A common practical threshold is to suppress features smaller than 3 mm on non-structural panels, while keeping all beads and ribs on crash-critical members such as the front rail and B-pillar. Meshing follows a target element size — 5 mm is a typical baseline for body structures, refined to 2–3 mm in the front crush zone where folding behavior must be captured. Shell elements dominate; solid elements are reserved for castings and thick brackets.

Connections are where most preparation errors occur. Spot welds are usually represented by either rigid beams (fast, less accurate for nugget pull-out) or solid hexa-weld clusters (slower, better for failure prediction). The choice must be consistent with the material failure model. Adhesive bonds use cohesive elements with a traction-separation law; bolts use rigid or deformable beam elements with defined preload. Every connection should be traceable to a weld map or a bill of materials — an untraceable connection is an unverifiable one.

Material cards deserve explicit attention. For crash, the essential data are density, Young's modulus, Poisson's ratio, yield curve (true stress vs. plastic strain), and a failure criterion such as equivalent plastic strain at rupture. A typical mild steel might use a yield curve up to 0.3 plastic strain with a rupture strain of 0.35; a high-strength steel might rupture at 0.12. Using nominal stress-strain instead of true stress-strain is a frequent and consequential error, because it under-predicts the energy absorbed in the plastic regime.

Stage 2 — Solver Execution

Crash simulations are almost universally explicit. LS-DYNA, Pam-Crash, and Radioss are the dominant codes. The explicit time step is governed by the Courant condition:

dt = L_min / c,  c = sqrt(E / rho)

where L_min = smallest element characteristic length
      c     = speed of sound in the material

For a 5 mm steel shell with E = 210 GPa and rho = 7.85e-3 g/mm³, the sound speed is approximately 5170 m/s, giving a stable time step near 1e-6 s. A 120 ms frontal impact therefore requires roughly 120,000 cycles. Mass scaling is commonly applied to elements below a threshold length — scaling a 1 mm element up to 5 mm equivalent adds mass, and the added mass must be monitored. A practical rule is to keep total added mass below 1–2% of the model mass; exceeding this invalidates the inertia balance.

Execution is typically launched in batch mode. A representative LS-DYNA invocation on an HPC cluster is:

lsdyna i=front_impact.k ncpu=64 memory=200m \
       jobid=FI_01 d=3

During the run, monitor three things: the energy ratio (hourglass energy and internal energy should stay below 5% of total energy), the time-step size (a sudden drop indicates element distortion), and the mass-scaling report. If hourglass energy exceeds 10%, switch to a more expensive hourglass control or refine the mesh in the affected region. If the run terminates with a negative volume error, the usual cause is a collapsed element in the crush zone — inspect the last d3plot frame before termination.

Stage 3 — Post-Processing

Post-processing answers the engineering questions: did the structure absorb the required energy, did the occupant compartment remain intact, and did the restraint systems deploy correctly? The primary outputs are the d3plot animation files, the nodout file (nodal displacements and velocities), and the glstat file (global energies).

A standard review sequence is: first, check the global energy balance in glstat — kinetic energy should rise then fall as the vehicle decelerates, internal energy should rise monotonically, and total energy should be conserved. Second, examine the intrusion into the occupant compartment: measure the B-pillar and door sill displacement relative to the undeformed position, with a typical target of less than 150 mm for a frontal offset impact. Third, inspect the deformation mode of the front rail — it should fold in a controlled accordion pattern, not buckle globally. Fourth, verify that the airbag and seatbelt models fired at the correct time.

Quantitative extraction uses cross-section forces and accelerations. The occupant compartment acceleration is filtered with a CFC 60 filter per SAE J211 before comparison with the injury criteria. A peak filtered acceleration above 50 g sustained for more than 3 ms is a warning sign that the restraint system or the front structure needs revision.

Stage 4 — Data Management

A single crash model generates a large and structured data footprint. A typical run produces 20–50 GB of d3plot files, plus the input deck, the solver log, and the post-processing session files. Without a disciplined naming and versioning scheme, reproducing a result six months later becomes impossible.

The recommended practice is to treat each run as an immutable record. The input deck is versioned in a repository (Git with Git-LFS for large binaries, or a dedicated PLM system). The run directory follows a fixed naming convention that encodes the model variant, the load case, and the solver version. A run manifest — a small text or YAML file — records the solver version, the number of CPUs, the mass-scaling factor, and the key result metrics. This manifest is what makes a run auditable.

The workflow is only as strong as its weakest stage. A perfectly meshed model run with an incorrect material card, or a correct run whose results cannot be traced back to its inputs, delivers no engineering value. The discipline of checking each stage before advancing is what separates a simulation that informs a design decision from one that merely produces colorful animations.