3. Identifying AI training data requirements

Before a single LS-DYNA deck is parameterized or a batch of simulations is launched, the most consequential engineering decision is already being made: what exactly will the surrogate model learn? A surrogate model is only as useful as the mapping it is asked to approximate, and that mapping is defined entirely by the choice of input features, output targets, and dataset specifications. Getting this definition wrong is expensive — not because the data is hard to generate, but because it is easy to generate thousands of simulations that answer the wrong question. This chapter establishes a disciplined process for translating a simulation objective into a concrete, machine-readable data contract that downstream ML pipelines can consume without ambiguity.

From Engineering Question to Learnable Mapping

Every surrogate model approximates a function f: X → Y, where X is a vector of design or operating parameters and Y is one or more quantities of interest (QoIs). The first task is to state this mapping explicitly in engineering terms. Consider a crashworthiness study: the question "how does the front rail design affect occupant intrusion?" must be rewritten as a precise mapping, for example f: (rail thickness t, rail gauge g, material grade, impact velocity v) → (peak acceleration a_max, maximum intrusion d_max, energy absorbed E_abs).

Two failure modes appear at this stage. The first is feature leakage: including an input that is not actually available at prediction time, or that already encodes the answer. A common example is using the simulated peak force as an input feature when the goal is to predict peak force. The second is target ambiguity: defining a QoI that depends on post-processing choices (filtering, windowing, node selection) without fixing those choices in the specification. If a_max is extracted with a CFC 60 filter in one batch and unfiltered in another, the labels are inconsistent and the model will learn noise.

Defining Input Features

Input features fall into three practical categories, and each carries different preprocessing obligations.

• Continuous design variables — thicknesses, radii, angles, velocities. These require a declared sampling range, a sampling strategy (Latin Hypercube, Sobol, or full factorial for small dimensions), and a units convention. Store them in SI units internally even if the deck uses millimetres and tonnes; conversion errors are a leading cause of silent label corruption.
• Categorical variables — material grades, element formulations, connection types. These must be encoded consistently (one-hot or ordinal with an explicit mapping table) and the encoding must be stored alongside the dataset, not reconstructed later.
• Derived or geometric features — mass, section properties, or mesh statistics computed from the deck. These are legitimate features only if they are deterministic functions of the primary variables; otherwise they introduce redundancy and collinearity.

A useful discipline is to maintain a feature manifest: a table listing each feature's name, type, unit, range, sampling method, and the exact keyword card or Python expression that produces it. The manifest is the contract between the simulation engineer and the ML engineer, and it should be version-controlled with the dataset.

Defining Output Targets and Extraction Procedures

Output targets are where most surrogate projects quietly fail. LS-DYNA produces enormous volumes of time-history data; the surrogate needs a small, well-defined set of scalars or short vectors. Each target must specify four things: the physical quantity, the spatial location (node set, part, or cross-section), the temporal reduction (peak, time-averaged, value at a fixed time, or a resampled curve), and the post-processing filter.

For example, a target might be defined as: "maximum acceleration at the seat-track node set, extracted from nodout using a CFC 60 SAE filter, over the interval 0–120 ms." That definition is reproducible. A definition such as "peak acceleration" is not. When targets are curves rather than scalars — for instance a force–displacement response — the specification must fix the resampling grid (e.g., 200 points on a uniform displacement axis from 0 to 300 mm) so that every sample produces a fixed-length label vector.

It is also worth distinguishing primary targets (what the model is asked to predict) from diagnostic outputs (quantities recorded for validation, anomaly detection, or physics-consistency checks, such as total internal energy or hourglass energy). Diagnostics do not enter the loss function but are invaluable when a sample looks suspicious.

Dataset Specifications: Size, Split, and Coverage

The dataset specification translates the mapping into numbers. Three quantities matter most: the design of experiments (how many samples and where), the train/validation/test split, and the coverage guarantee.

Sample count should be driven by the input dimensionality and the smoothness of the response, not by a round number. As a working heuristic for smooth crashworthiness responses with 4–8 inputs, 150–400 well-distributed samples often suffice for a Gaussian-process or gradient-boosted surrogate, while neural surrogates on curve-valued outputs typically need 500–2000. These are starting points, not guarantees; a learning-curve check (train on 50%, 70%, 90% of the data and observe validation error) is the only reliable way to confirm sufficiency.

Splitting requires care. A random split leaks information when samples are spatially or parametrically correlated. Prefer grouped splits: hold out entire material grades, entire velocity bands, or entire geometric families so that the test set measures extrapolation, not interpolation. Record the split assignment as a column in the manifest so it is reproducible.

Worked Example: Specifying a Bumper Rail Surrogate

Suppose the objective is a surrogate for a bumper rail under frontal impact. The mapping is defined as: predict peak acceleration a_max (g), maximum intrusion d_max (mm), and absorbed energy E_abs (kJ) from rail thickness t ∈ [1.2, 2.4] mm, gauge g ∈ [0.8, 1.6] mm, material grade ∈ {DP590, DP780, DP980}, and impact velocity v ∈ [30, 60] km/h.

The engineer generates a 200-point Latin Hypercube over the three continuous variables, crosses it with the three grades (600 candidate decks), and selects 240 decks by maximin distance to keep the simulation budget bounded. Each deck is run to 120 ms termination. Post-processing extracts a_max from the seat-track node set with a CFC 60 filter, d_max as the maximum nodal displacement of the rail rear flange, and E_abs as the final internal energy of the rail part. Diagnostics — hourglass energy ratio and added-mass percentage — are recorded; any run exceeding 5% hourglass or 1% added mass is flagged for review rather than silently included.

The split is grouped by material grade: DP590 and DP780 form the training and validation sets, while DP980 is held out entirely as the test set. This choice deliberately measures whether the surrogate can extrapolate to a stiffer grade, which is the realistic deployment scenario. A learning-curve check on the training set confirms that validation error plateaus before the full sample count is reached, indicating the dataset is adequately sized.

Validating the Specification Before Generation

A specification is ready when three checks pass. First, reproducibility: a second engineer can regenerate any sample's inputs and labels from the manifest alone. Second, coverage: a projection of the sampled inputs onto each pair of dimensions shows no large empty regions within the declared range. Third, label sanity: a handful of pilot runs produce target values within physically plausible bounds, and the diagnostics show no systematic anomalies. Only after these checks should the full simulation campaign begin — because at this stage, fixing a mistake costs an afternoon, while after generation it costs the entire dataset.

The figure above summarizes the complete data contract for this example: the input feature block with its sampling strategy, the simulation campaign with its diagnostic flags, the output targets with their extraction procedures, the grouped split policy, and the three readiness checks that gate the full run. Each element corresponds to a field in the feature manifest, and together they form the specification that the ML pipeline consumes. Once this contract is locked, data generation becomes a mechanical, auditable process — which is precisely the condition under which surrogate models trained on LS-DYNA data become reliable engineering tools rather than expensive curve fits.