2. CAE data landscape for ML

Before any surrogate model, classifier, or anomaly detector can be trained on CAE results, the data itself must be understood as a heterogeneous, multi-format, multi-resolution artifact. Crash simulations, NVH runs, thermal analyses, and CFD jobs each produce different file families, different discretization conventions, and different metadata. A model that performs well on one solver's output frequently fails on another's because the underlying data contract was never made explicit. This section maps the CAE data landscape that ML pipelines must ingest, and shows how to normalize it into a schema that downstream training can trust.

Solver Outputs: What Actually Comes Out of a Run

CAE solvers do not emit a single tidy table. They emit a set of result files whose structure depends on the solver and the analysis type. The most common families in automotive CAE are:

• LS-DYNA: d3plot (binary state database, time-step snapshots), binout (nodal/rigid-body time histories), nodout, elout, and glstat/matsum for global and material energy summaries.
• Nastran / OptiStruct: .op2 (binary results), .f06 (ASCII punch/summary), .pch, and .h3d for modal and frequency response.
• Abaqus: .odb (output database), .dat, .msg, and .sta for convergence and status.
• OpenFOAM / Fluent: time directories with U, p, k, epsilon fields, plus log files and postProcessing function-object output.

For ML, the critical distinction is between field data (per-node or per-element values at each time step) and scalar history data (a single curve per entity over time). Field data is high-dimensional and spatially structured; history data is low-dimensional and temporally structured. Mixing them into one flat feature vector without preserving that structure is a common early mistake.

Mesh Formats and the Connectivity Problem

Meshes are the geometric backbone of every result. The same physical part may appear as a shell mesh in one run and a solid mesh in another, with different node ordering and element types. Common formats include:

• Nastran bulk data (.bdf/.nas): GRID, CTRIA3, CQUAD4, CTETRA, CHEXA cards.
• LS-DYNA keyword (.k): *NODE, *ELEMENT_SHELL, *ELEMENT_SOLID, *PART.
• Abaqus input (.inp): *NODE, *ELEMENT, *ELSET.
• Neutral exchange: .stl, .obj, .vtk/.vtu, .cgns.

Two meshes are compatible for ML only if their node sets can be mapped. In practice this means either (a) identical mesh topology across runs, which holds for parametric DOE studies, or (b) a registration step that maps nodes by coordinates and part ID. For crash DOE datasets, topology is usually fixed, so a stable node_id is a valid feature index. For shape-optimization datasets, topology changes and a graph-based or point-cloud representation is required.

Boundary Conditions and Load Cases as Structured Metadata

Boundary conditions (BCs) and load cases are not results — they are inputs that determine what the result means. A displacement field from a frontal impact is meaningless without knowing the prescribed velocity, the rigid wall position, and the contact definition. For ML, BCs and load cases must be captured as structured, queryable metadata, not buried in solver decks.

Typical BC/load-case attributes worth extracting:

The load case ID is the single most important join key in automotive CAE ML. It links a result to the physical scenario it represents, and it is the label most models ultimately predict or condition on.

Metadata Schemas: Making the Data Contract Explicit

A metadata schema is the formal contract between the CAE data producer and the ML consumer. It should be versioned, machine-readable, and enforced at ingestion. A minimal but practical schema for a single CAE run sample looks like this:

{
  "schema_version": "1.2",
  "run_id": "crash_frontal_50kph_0007",
  "solver": {"name": "ls-dyna", "version": "R13.1"},
  "analysis_type": "explicit_dynamics",
  "load_case": {
    "id": "FRONTAL_50",
    "velocity_kmh": 50.0,
    "impact_direction": [1.0, 0.0, 0.0],
    "barrier_type": "rigid_wall"
  },
  "mesh": {
    "format": "lsdyna_keyword",
    "n_nodes": 482113,
    "n_shells": 476902,
    "n_solids": 1204,
    "topology_hash": "a3f9c1..."
  },
  "boundary_conditions": {
    "spc_sets": ["BIW_REAR", "POWERTRAIN_MOUNT"],
    "initial_velocity_node_set": "ALL_NODES"
  },
  "outputs": {
    "field": ["d3plot"],
    "history": ["binout/glstat", "binout/nodout"]
  },
  "units": {"length": "mm", "mass": "kg", "time": "ms"},
  "provenance": {"engineer": "jdoe", "date": "2024-11-03", "plm_rev": "B2"}
}

Three fields deserve emphasis. topology_hash is a hash of the sorted node coordinates and element connectivity; it lets a pipeline detect whether two runs share a mesh without loading both. units prevents the classic mm–m and kg–tonne mismatch that silently corrupts features. provenance supports traceability when a model's prediction must be explained to a CAE engineer.

From Raw Files to a Training-Ready Store

The ingestion path that works in practice has four stages. First, parse solver-specific files into neutral arrays (nodes, elements, fields, time steps) using tools such as lasso-python, pyNastran, pyvista, or meshio. Second, extract BCs and load-case attributes from the deck or the PLM process sheet into the metadata schema. Third, validate the schema — check units, topology hash consistency, and that every declared output file exists. Fourth, write to a columnar or array store: Parquet for scalar history and metadata, Zarr or HDF5 for field snapshots, with the run_id as the common index.

A useful validation check is a per-run energy balance from glstat: total energy should be conserved within a few percent for an explicit crash run. If it is not, the run is likely diverged and should be excluded from training rather than treated as a valid sample.

Practical Failure Modes and How to Catch Them

Three ingestion failures account for most silent corruption in CAE ML datasets. Unit mismatch: a run stored in tonnes–mm–s mixed with one in kg–m–s produces features off by orders of magnitude; catch it by asserting the units block and cross-checking a known quantity such as total mass against the PLM record. Topology drift: a mesh update changes node count, so a model trained on the old index misaligns; catch it by comparing topology_hash before joining. Diverged runs: an explicit crash run that blew up early still writes d3plot states, but the energy balance is wrong; catch it by checking glstat total energy against initial kinetic energy and rejecting runs outside a tolerance band.

When these three checks are enforced at ingestion, the downstream ML pipeline receives samples that are comparable, correctly scaled, and physically plausible. That is the precondition for any decision-support model to be trusted by the CAE engineers who will use it.