4. Dataset generation from LS-DYNA and Radioss crash models

Graph neural networks for crashworthiness prediction are only as good as the datasets they are trained on. A GNN that predicts nodal displacement, intrusion, or acceleration histories must learn from thousands of simulation runs that faithfully represent the design space. This chapter covers the complete pipeline for converting LS-DYNA and Radioss crash models into structured, graph-ready datasets: preprocessing the finite element model, configuring and executing the simulation, and extracting time-series nodal data into a format suitable for GNN training.

4.1 Model Preprocessing

Raw crash models from LS-DYNA (.k or .key files) and Radioss (.rad or _0000.rad starter files) contain far more information than a GNN needs. Preprocessing serves three purposes: reducing model complexity, ensuring consistency across the dataset, and establishing the graph topology that the GNN will operate on.

Geometry simplification. Full vehicle models routinely contain 5–15 million elements. Training a GNN on graphs of this size is computationally prohibitive. A common strategy is to retain structural components that dominate crash energy absorption — front rails, bumper beams, shotguns, aprons, and the B-pillar — while removing or coarsening non-structural parts such as interior trim, HVAC ducts, and wiring harnesses. In LS-DYNA, this is done by selecting relevant *PART entries and writing a reduced keyword file. In Radioss, the equivalent operation uses /PART and /GRPART selections.

Mesh coarsening and element quality checks. After part selection, the remaining mesh may still be too dense. Coarsening via remeshing or element merging reduces node count while preserving the load paths. Before proceeding, run quality checks: LS-DYNA users can use *CONTROL_CHECK_SHELL to detect warped or inverted elements; Radioss provides /CHECK in the starter input. Elements with aspect ratios above 5:1 or Jacobian ratios below 0.6 should be flagged and repaired, as they cause unstable time steps and noisy nodal outputs.

Node and element renumbering. For dataset consistency, renumber nodes and elements sequentially across all models. This ensures that node ID i in model A corresponds to the same spatial location as node ID i in model B — a prerequisite for building a fixed-topology graph. LS-DYNA's *NODE and *ELEMENT_SHELL blocks can be rewritten with a Python script using lasso-python or pyDYNA. Radioss users can leverage radioss2py or the OpenRadioss Python API.

4.2 Simulation Setup and Execution

With the preprocessed model in hand, the next step is to configure the crash simulation. The goal is not merely to run a simulation, but to run it in a way that produces clean, consistent time-series data across the entire dataset.

Boundary conditions and initial velocity. A standard frontal impact setup applies an initial velocity to the entire vehicle via *INITIAL_VELOCITY (LS-DYNA) or /INIVEL (Radioss). For a 56 km/h frontal crash, the velocity vector is typically (−15.56, 0, 0) m/s in the vehicle coordinate system, where the X-axis points rearward. The rigid wall is defined with *RIGIDWALL_PLANAR or /RWALL/PLANE. Ensure the wall normal and the velocity vector are collinear and opposite — a mismatch here is a common source of non-physical results.

Time step and termination. Crash simulations typically run for 80–150 ms. The time step is governed by the smallest element size and material sound speed. For steel with a 5 mm element, the stable time step is approximately 1 μs. Set *CONTROL_TERMINATION to 0.120 (120 ms) and *DATABASE_BINARY_D3PLOT to output every 1–2 ms. In Radioss, use /RUN with Tfreq to control output frequency. A finer output interval (e.g., 0.5 ms) captures more detail but increases storage; 1 ms is usually sufficient for GNN training.

Mass scaling and hourglass control. To avoid excessively small time steps from tiny elements, apply mass scaling via *CONTROL_TIMESTEP with DT2MS set to a target value (e.g., −1e-6 for 1 μs). Monitor the added mass — it should remain below 5% of the total model mass. For under-integrated shell elements, activate hourglass control (*HOURGLASS with type 4 or 6) to suppress spurious zero-energy modes that corrupt nodal velocity fields.

Batch execution. For dataset generation, simulations must run in batch. A typical LS-DYNA batch command on a Linux cluster is:

ls-dyna i=model.k ncpu=16 memory=200m jobid=run_001

For Radioss:

radioss -i model_0000.rad -nt 16 -output run_001

Automate this with a shell script or job scheduler (SLURM, PBS) that iterates over design variations — different thicknesses, materials, or geometry parameters — and writes each run to a separate directory.

4.3 Extraction of Time-Series Nodal Data

The raw output from LS-DYNA (d3plot binary files) and Radioss (Annn animation files) is not directly consumable by a GNN. Extraction converts these binary results into structured arrays of node coordinates, displacements, velocities, and accelerations over time.

LS-DYNA extraction. Use lasso-python to read d3plot files. The following snippet extracts nodal displacement histories for all nodes:

import lasso
d3plot = lasso.dyna.D3plot('run_001/d3plot')
node_ids = d3plot.node_ids
disp = d3plot.get_node_displacement()  # shape: (n_timesteps, n_nodes, 3)
time = d3plot.get_time()               # shape: (n_timesteps,)

Radioss extraction. Use pyradioss or the OpenRadioss anim_to_vtk converter to first convert Annn files to VTK, then read with pyvista or meshio. Alternatively, Radioss can output nodal time history directly via /TH/NODE blocks, producing ASCII T01 files that are trivial to parse.

Data structuring for GNN training. The extracted data must be organized into a graph dataset. Each graph G = (V, E) has:

• Node features: initial coordinates (x, y, z), element type, material ID, and thickness.
• Edge features: connectivity from the finite element mesh (shared nodes between elements), plus relative position vectors.
• Targets: time-series displacement, velocity, or acceleration at each node.

A typical dataset is stored as a PyTorch Geometric Data object or a set of HDF5 files. For a dataset of 500 crash simulations with 50,000 nodes each and 120 time steps, the storage requirement is approximately 500 × 50,000 × 120 × 3 × 4 bytes ≈ 36 GB for displacement alone. Compression via h5py with gzip reduces this by 40–60%.

4.4 Quality Control and Validation

Before training, validate the dataset on three fronts. First, check for non-physical values: negative masses, NaN displacements, or velocities exceeding the initial impact speed. Second, verify energy balance — the total energy (kinetic + internal + hourglass) should remain approximately constant, with hourglass energy below 5% of internal energy. Third, confirm temporal consistency: the time vector should be monotonically increasing with uniform spacing. Any simulation failing these checks should be excluded or re-run with corrected settings.

4.5 Practical Considerations for Large-Scale Dataset Generation

Generating a dataset of 500–2000 crash simulations requires careful resource management. Each LS-DYNA run on 16 CPUs for a 120 ms frontal impact takes approximately 2–6 hours depending on model size. A 1000-run dataset therefore consumes 2000–6000 CPU-hours. On a 200-core cluster, this translates to 10–30 hours of wall-clock time if runs are perfectly parallelized.

Storage is equally important. A single d3plot file for a 50,000-node model with 120 output states is roughly 200–400 MB. After extraction and compression, each simulation's HDF5 file is 60–120 MB. Plan for 60–120 GB of storage for a 1000-run dataset, plus temporary space for raw outputs.

Finally, document the dataset with a metadata table. Include columns for run ID, design parameters (thickness, material grade, geometry variant), simulation settings (time step, termination time, output interval), and QC status. This metadata enables stratified sampling during training and supports ablation studies on design parameters.