4. Metadata modeling for CAE

In a cross-solver CAE data lake, geometry and mesh files are only the visible surface. The real engineering value lives in the metadata: which solver was used, how the model was set up, what boundary conditions were applied, which material cards were referenced, and — most importantly — why the simulation was run. Without a disciplined metadata model, a data lake degrades into an unsearchable file dump where two runs of the same bracket cannot be compared because nobody recorded whether the load was 5 kN or 5000 N, or whether the units were mm-tonne-s or m-kg-s.

This chapter defines a practical metadata schema for CAE, shows how to map solver-specific keywords into a solver-neutral representation, and demonstrates how simulation intent can be captured as first-class structured data rather than buried in a README file.

Why Solver-Neutral Metadata Matters

Each solver speaks its own dialect. Abaqus uses *BOUNDARY and *MATERIAL; ANSYS Mechanical uses D and MP commands; Nastran uses SPC and MAT1; LS-DYNA uses *BOUNDARY_SPC_SET and *MAT_ELASTIC. If the data lake stores only native input decks, cross-solver analytics become impossible — you cannot ask "show me every linear static run where a fixed support was applied to a steel part" without parsing four different syntaxes.

The solution is a two-layer model: a solver-neutral core schema that captures engineering meaning, plus a solver-specific extension that preserves the exact keyword and value for round-trip fidelity. The core schema answers analytical questions; the extension guarantees reproducibility.

Core Metadata Entities

A workable CAE metadata model revolves around five entities. Each is a record with a stable identifier, and relationships are expressed by reference rather than duplication.

The Intent entity is what distinguishes a CAE data lake from a generic file store. A simulation without recorded intent cannot be reused, only re-run.

Capturing Solver Settings

Solver settings fall into three groups: analysis procedure, numerical controls, and output requests. The core schema stores the procedure in a controlled vocabulary (static_general, modal, explicit_dynamic, thermal_steady, nonlinear_static), while numerical controls such as time increment, convergence tolerance, and solver type are stored as typed key-value pairs.

{
  "sim_id": "SIM-2024-0417-A",
  "solver": "abaqus",
  "solver_version": "2023",
  "analysis_type": "nonlinear_static",
  "unit_system": "mm_tonne_s",
  "controls": {
    "nlgeom": true,
    "initial_increment": 0.01,
    "max_increment": 0.1,
    "max_num_inc": 1000
  },
  "output_requests": ["S", "U", "RF", "PE"],
  "intent_id": "INT-0088"
}

Note the explicit unit_system field. Unit ambiguity is the single most common cause of silent errors in cross-solver analytics. Storing the unit system as metadata allows the lake to normalize values at query time — for example, converting all loads to newtons before comparison.

Boundary Conditions as Structured Records

A boundary condition is not just a number. It has a type (fixed, pinned, symmetry, pressure, concentrated force, gravity), a degree-of-freedom or surface association, a magnitude with units, a spatial region, and often a time-history reference. Storing these as separate fields enables queries such as "find all simulations where a 10 kN tensile load was applied along global X to a steel component."

Region references deserve special attention. A boundary condition applied to "face 17" is meaningless if the geometry is re-meshed. The robust approach is to store a persistent region identifier — a named selection, a CAD face ID, or a geometric query — alongside the transient mesh entity ID. When the mesh changes, the persistent ID allows re-association.

Material Properties and Provenance

Material metadata must capture not only the constitutive parameters but also their provenance. A yield strength of 355 MPa means different things if it comes from a mill certificate, a handbook, or a tensile test. The schema should include a source field with values such as mill_cert, handbook, test_data, or assumed, plus an optional source_ref pointing to a document or test ID.

For temperature-dependent or strain-rate-dependent materials, properties are stored as arrays of (independent variable, value) pairs rather than scalars. This keeps the schema uniform across elastic, plastic, hyperelastic, and creep models.

Simulation Intent: The Missing Dimension

Simulation intent answers the question "what decision does this run inform?" It is captured as a structured record linked to one or more simulations. A well-formed intent record contains:

• Question: "Does the bracket survive a 3g lateral load without yielding?"
• Acceptance criteria: "Max von Mises stress < 355 MPa; max displacement < 2 mm."
• Phase: concept, detailed_design, verification, or certification.
• Owner and date: who asked and when.

With intent captured, the data lake can answer questions that pure file metadata cannot: "Which simulations were run to verify the bracket design, and did any of them fail their acceptance criteria?" This transforms the lake from storage into an engineering knowledge base.

Mapping Solver Keywords to the Core Schema

The mapping layer is where solver-specific input decks are translated into core records. The following SVG illustrates the flow from native solver input through the mapping layer into the solver-neutral core, with the solver-specific extension preserved alongside.

Worked Example: Normalizing a Boundary Condition

Consider an Abaqus input deck containing the following lines:

*BOUNDARY
Nset=LOAD_FACE, 1, 1, 5000.0
*BOUNDARY
Nset=FIXED_END, 1, 3, 0.0

The mapping layer produces two BoundaryCondition records. For the first: type=concentrated_force, dof=1, magnitude=5000.0, units=N (after unit normalization from the deck's declared mm-tonne-s system, where force is in N), region_ref=LOAD_FACE. For the second: type=fixed, dof=[1,2,3], magnitude=0.0, region_ref=FIXED_END.

If the deck had declared units in m-kg-s, the same 5000.0 would be interpreted as 5000 N as well (since force in m-kg-s is also newtons), but a pressure of 5000.0 would be 5000 Pa in m-kg-s versus 5000 MPa in mm-tonne-s — a factor of 10⁶ difference. This is why unit normalization must happen at ingestion, not at query time.

Validation and Quality Gates

Metadata ingestion should enforce a set of quality gates before records enter the lake. A practical minimum set includes: every simulation must reference a valid intent_id; every boundary condition must have a resolved region; every material must have a source; and every simulation must declare a unit_system. Records failing these gates are quarantined with a diagnostic code rather than silently accepted.

The payoff is a data lake where an engineer can ask, "Show me all nonlinear static runs on the 2024 bracket revision where the intent was certification and the max stress exceeded 90% of yield," and receive an answer in seconds — across Abaqus, ANSYS, and Nastran runs alike. That capability depends entirely on the metadata model described here.