4. Simulation data management for surrogate training

A surrogate model is only as trustworthy as the dataset behind it. In occupant CAE, that dataset is assembled from dozens or hundreds of explicit solver runs — frontal impacts, side pole, rear sled, roof crush — each producing time histories for head acceleration, chest deflection, femur force, and restraint loads. Before a single Gaussian process or neural network is trained, the team must answer three questions with evidence: Which runs exist and what do they cover? What exactly was simulated in each run? Are the outputs physically valid and comparable? Simulation data management (SDM) is the discipline that makes those answers auditable. This chapter treats the run matrix as a designed artifact, metadata as a schema, and quality checks as a gate that blocks bad data from entering the training set.

The run matrix as a designed experiment, not a folder listing

A run matrix is a table whose rows are simulation runs and whose columns are the design variables (DVs) that the surrogate will consume as inputs. For an occupant restraint study, typical DVs include impact velocity v_impact (e.g., 48–56 km/h), pulse scaling factor, seat belt anchor height, pretensioner force limit, airbag vent diameter, and seat pan angle. Each row must be a deliberate point in that space — a Latin hypercube sample, a full factorial corner set, or a validation hold-out — not an accidental by-product of ad-hoc debugging runs.

Two structural rules matter. First, the matrix must record design intent: a column such as role with values train, validation, corner, or screening prevents leakage later. Second, the matrix must record execution status separately from design values, because a run that was designed but never converged is not a data point. A minimal matrix schema looks like this:

run_id,case_family,v_impact_kph,pulse_scale,belt_anchor_mm,pretension_kN,vent_mm,seat_angle_deg,role,status
R0041,frontal_50,50,1.00,180,3.5,30,22,train,complete
R0042,frontal_50,50,1.00,180,4.5,30,22,train,complete
R0043,frontal_50,50,1.00,180,3.5,40,22,train,diverged
R0044,frontal_50,50,1.00,180,3.5,30,26,validation,complete

Note that R0043 is retained with status=diverged rather than deleted. Deleting failed runs destroys the evidence needed to detect sampling bias — if all high-vent cases failed, the surrogate will silently extrapolate there. The matrix should also carry a case_family key so that load cases with different boundary conditions (frontal vs. side) are never pooled into one response surface without a categorical input.

Metadata: the provenance layer that makes a run reproducible

Design variables describe the intent; metadata describes the execution. Without it, a run ID is an opaque folder. The metadata record should capture, at minimum: solver and version (e.g., LS-DYNA R13.1), deck revision or Git commit hash, occupant model variant (Hybrid III 50th vs. THOR), restraint subsystem revision, units system, output sampling rate, and the post-processing script version used to extract injury metrics. A practical format is a sidecar JSON per run:

{
  "run_id": "R0041",
  "solver": {"code": "LS-DYNA", "version": "R13.1", "deck_commit": "a3f9c21"},
  "model": {"dummy": "HybridIII_50M", "restraint_rev": "belt_v7.2"},
  "units": "mm-ms-kg-kN",
  "outputs": {"sample_dt_ms": 0.1, "channels": ["head_acc_res", "chest_defl", "femur_L", "femur_R"]},
  "postproc": {"script": "extract_metrics.py", "version": "1.4.0"},
  "wall_clock_h": 6.2,
  "status": "complete"
}

The critical discipline is immutability: once a run is marked complete, its metadata and raw outputs are frozen. If the belt model is revised, that is a new run with a new restraint_rev, not an in-place edit. Surrogate training sets that mix revisions without a categorical feature will learn revision artifacts as if they were physics. A lightweight content hash over the extracted channel files, stored alongside the record, lets you detect silent overwrites months later.

Quality checks: gating outputs before they reach the trainer

Occupant CAE outputs fail in characteristic ways, and each failure mode has a cheap automated check. The checks below are ordered from cheapest to most expensive so that a pipeline can reject bad runs early.

The physical plausibility thresholds are not universal constants — they are calibrated per dummy and load case, and should be stored in a versioned config so the gate is reproducible. The cross-run consistency check is the most valuable and the most often skipped: it catches unit errors and mislabeled runs that pass every per-run test. A simple implementation fits a local linear trend over the k nearest neighbors in DV space and flags residuals beyond a robust threshold; a single flagged run is inspected manually, a cluster of flags usually indicates a systematic modeling error.

Putting it together: the data flow from run to training set

The figure below traces a single run through the pipeline: design intent from the matrix, execution metadata, raw time histories, automated quality gates, and finally admission to the frozen training snapshot. The key architectural point is that the training set is a versioned snapshot — a manifest listing exactly which run_ids and which metadata hashes were used — so any surrogate can be traced back to its evidence.

In practice, the snapshot manifest is the artifact you hand to the surrogate trainer and to any reviewer asking "where did this model come from?" A minimal manifest entry pairs each admitted run with its metadata hash and the gate configuration version:

snapshot_id: occ_frontal_v3
created: 2025-03-14T09:20:00Z
gate_config: quality_gate_v2.1.yaml
runs:
  - {run_id: R0041, meta_hash: 9c1e..., status: complete}
  - {run_id: R0042, meta_hash: 4b7a..., status: complete}
  - {run_id: R0044, meta_hash: e2d0..., status: complete}
excluded:
  - {run_id: R0043, reason: energy_error}

Common failure symptoms and how to diagnose them

When a surrogate trains but generalizes poorly, the cause is frequently upstream in the data layer. Three symptoms recur. Validation error much worse than training error often means the validation rows were not truly held out — check that role was assigned before sampling, not after. Surrogate predicts implausible peaks at design-space corners usually indicates that corner runs were rejected by the quality gate and never replaced, leaving the surrogate to extrapolate; inspect the excluded list for corner run_ids. Sudden accuracy drop after a model update points to mixed restraint_rev or deck_commit values inside one snapshot; the metadata hash comparison will localize the offending runs immediately.

The payoff is straightforward: when every training run carries its design intent, its execution provenance, and a recorded pass/reject decision, surrogate accuracy becomes a property you can defend and debug rather than a number you hope holds on the next load case.