2. Crash simulation data landscape

Crash simulation is one of the most data-intensive workloads in automotive CAE. A single full-vehicle frontal impact model can contain 5–15 million shell elements, several hundred thousand solid elements, and dozens of contact definitions, and it produces time-history output at thousands of integration points across a 100–150 ms event. Before any machine-learning model can be trained on this data, the engineer must understand where the data comes from, what physical quantities it encodes, how it is stored, and how it must be reshaped into tensors that a learning algorithm can consume. This chapter maps that landscape and establishes a reproducible preprocessing pipeline.

Primary Data Sources

Crash-simulation data originates from three broad source families, each with distinct structure and fidelity characteristics.

• Solver input decks — LS-DYNA .k / .key files, PAM-CRASH .pc files, or Radioss .rad files. These contain the mesh (nodes, elements), material cards (e.g., *MAT_PIECEWISE_LINEAR_PLASTICITY), section properties, contact definitions, boundary conditions, and the initial velocity field. They are the ground truth for geometry and constitutive behavior.
• Solver time-history output — d3plot (LS-DYNA binary), binout, or ASCII nodout/elout files. These store nodal displacement, velocity, acceleration, element stress/strain, and section forces at each output state. A typical frontal impact writes 50–200 states.
• Post-processed scalar metrics — derived quantities such as intrusion, HIC (Head Injury Criterion), chest deflection, and peak acceleration, usually extracted with tools like LS-PrePost, Animator, or a Python lasso-python / pyDYNA reader.

In a production MLOps setting, these sources are registered in a metadata catalog. Each simulation run is identified by a run_id, and the catalog records the model variant, solver version, output frequency, and the list of extracted channels. This provenance is essential: a model trained on d3plot data from solver version A may not generalize to version B if contact algorithms changed.

Formats and Their Trade-offs

The choice of format determines the downstream model class. Tabular metrics feed gradient-boosted trees for intrusion prediction; full-field d3plot data feeds graph neural networks or convolutional autoencoders for surrogate modeling; time-series channels feed temporal models such as LSTMs or temporal CNNs.

Preprocessing Pipeline

Raw solver output is not directly trainable. The following pipeline converts a run into a model-ready sample. It is written as a sequence of concrete operations, each with an observable check.

1. Ingestion and validation. Read the d3plot with a binary reader (e.g., lasso-python). Verify that the number of states matches the expected output interval and that no state is truncated. A common failure is a solver crash mid-run, producing a d3plot with fewer states than requested; such runs must be flagged and excluded.
2. Channel selection. Extract only the channels relevant to the target. For a frontal impact intrusion model, this might be the Y-displacement of 200 nodes on the firewall plus the acceleration of 6 tunnel-mounted accelerometers. Selecting all 5 million nodes is wasteful and introduces noise.
3. Time alignment and resampling. Solver output is often non-uniform in time. Resample all channels onto a common uniform grid, e.g., 0.1 ms intervals over 0–120 ms, using linear interpolation. This yields a fixed-length tensor of shape (1200, C) where C is the channel count.
4. Filtering. Apply a low-pass Butterworth filter (e.g., 1 kHz cutoff) to acceleration channels to remove solver numerical noise. Document the filter order and cutoff; they become part of the model's input contract.
5. Normalization. Compute per-channel mean and standard deviation over the training set only, then apply z-score normalization. Store the statistics in the feature store so inference uses identical scaling.
6. Windowing / aggregation. For time-series models, slice the 1200-step sequence into overlapping windows of 200 steps with stride 50. For scalar models, reduce each channel to features such as peak value, time-to-peak, and integral.
7. Serialization. Write the processed tensor to Parquet or HDF5 with the run_id as the key, and register the artifact in the feature store with a content hash.

Common Pitfalls and Verification

Three failure modes recur in crash-simulation ML preprocessing. First, unit inconsistency: LS-DYNA decks may use mm/ms/kg while post-processors output m/s²; mixing them silently corrupts labels. Always record units in the catalog. Second, leakage across train/test splits: simulations of the same vehicle variant with slightly different mesh density are near-duplicates; split by variant, not by run. Third, truncated or diverged runs: a run that diverged at 80 ms has no valid 120 ms label; exclude it rather than imputing.

Verification is straightforward: after preprocessing, plot the resampled acceleration channel against the raw nodout curve for one run. They should overlay within interpolation error. If the peak is shifted or attenuated, the resampling or filter is wrong. This single check catches most pipeline defects before they reach training.

The diagram above summarizes the end-to-end flow: three source families feed a six-stage preprocessing pipeline, which produces a fixed-shape tensor and a label, both registered in a feature store. The verification check is shown as a side branch because it is not a transformation but a quality gate that must pass before the artifact is accepted.

With the data landscape mapped and the preprocessing pipeline defined, the next step is to build the feature store and dataset versioning layer that makes these artifacts reproducible across teams. That is the subject of the following chapter.