3. Crash CAE data generation

A surrogate model is only as good as the dataset it learns from. In automotive crash CAE, that dataset is produced by running hundreds or thousands of LS-DYNA explicit simulations, each corresponding to a distinct combination of design variables such as sheet-metal gauge, material yield strength, bead depth, or barrier offset. The engineering challenge is not simply "run more simulations" — it is to design a sampling plan that covers the design space efficiently, parameterize the LS-DYNA deck so that each run is reproducible and traceable, and orchestrate the resulting jobs on an HPC cluster without losing track of a single case. This section walks through the four interlocking pieces: DOE strategy, sampling for highly nonlinear responses, deck parameterization, and job orchestration.

DOE Strategy: Matching the Design to the Response

The choice of DOE depends on the number of variables, the expected smoothness of the response, and the budget. For crash responses — peak intrusion, HIC, chest deflection, acceleration pulse — the response surface is rarely smooth. It contains kinks where a structure switches buckling mode, and cliffs where a spot weld fails. This rules out naive factorial designs at high dimension and pushes practitioners toward space-filling designs.

Three families dominate practice:

• Full and fractional factorial — useful for screening when the variable count is small (≤ 5) and interactions matter. A 2^5-1 resolution-V design needs only 16 runs and can separate main effects from two-factor interactions.
• Latin Hypercube Sampling (LHS) — the workhorse for 5–30 variables. Each variable's range is divided into N equal-probability bins, and one sample is drawn per bin per variable, then randomly paired. LHS guarantees marginal coverage but not joint coverage; two LHS designs with the same N can have very different space-filling quality.
• Optimal Latin Hypercube / Sobol sequences — LHS augmented with an optimization criterion such as maximin distance or centered L2-discrepancy. Sobol sequences are deterministic low-discrepancy designs that give better uniformity at low sample counts and are reproducible without a random seed.

For crash CAE, a practical rule of thumb is to budget N ≈ 10 × d to 20 × d runs for a first-pass surrogate, where d is the number of active variables. If the surrogate will later be refined with adaptive sampling, start with 5 × d and add points where the model is uncertain.

Sampling for Highly Nonlinear Responses

Crash responses violate the assumptions of classical DOE in three ways: they are non-stationary (variance changes across the design space), discontinuous (mode switching), and heteroscedastic (some regions are far noisier than others). Uniform space-filling alone will waste runs in flat regions and under-sample the cliffs.

Two techniques address this directly:

1. Stratified sampling on a proxy response. Run a cheap coarse-mesh or reduced-order model first, then stratify the fine-mesh sampling by the proxy's predicted response. Regions where the proxy shows a steep gradient receive more samples.
2. Adaptive / sequential sampling. Fit an initial surrogate (e.g., Kriging or Gaussian Process), then add new points where the predicted variance or the expected improvement is highest. This concentrates runs near discontinuities without prior knowledge of their location.

A concrete example: suppose the design space has three variables — A-pillar gauge (1.2–2.0 mm), B-pillar yield (340–780 MPa), and rocker bead depth (0–8 mm). A 60-run maximin LHS gives good marginal coverage, but if the intrusion response has a sharp transition around B-pillar yield ≈ 600 MPa, the surrogate will smooth over it. Adding 20 adaptive points near that transition — selected by maximum predicted variance from a Kriging model — typically reduces leave-one-out RMSE by 30–50% compared with a uniform 80-run design. These numbers are illustrative; actual improvement depends on the response and the surrogate.

LS-DYNA Deck Parameterization

Parameterization is where DOE meets the actual solver. The goal is a single master deck that can be driven by an external parameter file, so that each run is a deterministic function of its input vector. Three approaches are common:

• *PARAMETER + *PARAMETER_EXPRESSION. LS-DYNA's native parameterization. Variables are declared in the keyword deck and referenced with &varname. This is the cleanest method because the deck remains a single file and the parameter values can be overridden from the command line.
• Include-file templating. The master deck contains *INCLUDE statements pointing to a generated file (e.g., params_0001.k) that holds the variable definitions. A Python or shell script writes this file per run.
• Full deck generation. A script reads a template and emits a complete deck per run. Most flexible but hardest to maintain; use only when the topology itself changes (e.g., adding or removing a bead).

A minimal parameterized snippet looks like this:

*PARAMETER
r_gauge_a     &ga
r_yield_b     &yb
r_bead_depth  &bd
*PARAMETER_EXPRESSION
r_thickness_a = &ga
*INCLUDE
params_&runid.k

Each run then invokes LS-DYNA with the parameter overrides:

ls-dyna i=master.k ncpu=32 memory=200m \
  p=params_0001.k jobid=run_0001

Two practical cautions. First, always verify that the parameter actually reaches the intended card — a typo in the variable name silently falls back to the deck default, producing a run that looks valid but is not. Second, keep a manifest that maps each run ID to its input vector; without it, post-processing becomes archaeology.

HPC Job Orchestration

Running 500 LS-DYNA jobs on a cluster requires more than a shell loop. The orchestration layer must handle queue submission, dependency management, failure detection, and result collection. A typical stack uses a scheduler (Slurm, PBS, or LSF) plus a lightweight workflow tool.

A Slurm array job is the simplest scalable pattern:

#!/bin/bash
#SBATCH --job-name=crash_doe
#SBATCH --array=1-500
#SBATCH --ntasks=32
#SBATCH --time=04:00:00
#SBATCH --output=logs/run_%a.out

RUNID=$(printf "run_%04d" $SLURM_ARRAY_TASK_ID)
PARAM=params/${RUNID}.k
ls-dyna i=master.k ncpu=32 memory=200m \
  p=${PARAM} jobid=${RUNID}

For more complex dependencies — e.g., a coarse proxy run that must finish before adaptive sampling selects the next batch — use a workflow engine such as Snakemake, Nextflow, or a custom Python DAG. The key requirements are: idempotent job submission (re-running the orchestrator does not duplicate work), per-run logging, and a status table that distinguishes completed, failed, and still running.

Putting It Together

The four pieces form a pipeline: DOE defines where to sample, nonlinear sampling refines where it matters, deck parameterization makes each run reproducible, and HPC orchestration makes the whole thing scalable. A well-designed pipeline for a 10-variable crash problem might produce 200 runs in 24–48 hours on a 500-core allocation, yielding a dataset sufficient for a first-pass Kriging or neural-network surrogate. The next section builds on this dataset to construct and validate the surrogate itself.