3. Data modeling for CAE

CAE data is not a single artifact. A finished simulation is a web of interdependent objects: a geometry revision, a meshed idealization, a material definition with temperature-dependent properties, a set of load cases and boundary conditions, solver settings, and one or more result sets — each with its own provenance, units, and version history. Data modeling is the discipline of making that web explicit and machine-readable. Without it, CAE data degrades into a folder of files whose relationships exist only in an engineer's memory. This chapter covers the three layers that make CAE data queryable and governable: metadata schemas, ontologies, and the explicit relationship model that ties models, loads, materials, and results together.

Why a File-Centric View Fails

Consider a typical crashworthiness study. The solver input deck references a material card by ID, the material card lives in a separate include file, the load case is defined by a rigid wall and an initial velocity, and the results are a set of .d3plot states. If a colleague asks "which result sets were produced with the 2023 revision of material MAT_024 and a 50 km/h impact?", a file-centric repository cannot answer without manual inspection. The information exists, but it is embedded in solver syntax rather than expressed as structured metadata. Data modeling extracts that information into a schema so it can be indexed, validated, and queried.

Metadata Schemas: The Structured Layer

A metadata schema defines the fields, types, and constraints that describe a CAE object. It is the contract between data producers (analysts, automated pipelines) and data consumers (search, dashboards, downstream simulations). A practical schema for a CAE model artifact typically separates three concerns:

• Identity and provenance — a stable object ID, the authoring tool and version, the source geometry revision, and a timestamp.
• Physical description — unit system, coordinate system convention, mesh statistics (element count, element types, minimum quality metric), and the solver deck format.
• Classification — analysis type (static, modal, explicit dynamic), discipline (structural, thermal, CFD), and the program or vehicle variant the model belongs to.

Schemas are best expressed in a language that supports validation. JSON Schema is a common choice because it is readable, tooling-friendly, and can enforce enumerations and required fields. The following excerpt defines the core fields of a CAE model record; note that unitSystem and coordinateConvention are mandatory, because unit and frame mismatches are among the most common and most damaging CAE data defects.

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "title": "CAEModelRecord",
  "type": "object",
  "required": ["modelId", "revision", "solver", "unitSystem",
               "coordinateConvention", "meshStats", "analysisType"],
  "properties": {
    "modelId":        { "type": "string" },
    "revision":       { "type": "string", "pattern": "^R[0-9]+$" },
    "solver":         { "type": "string", "enum": ["Abaqus", "Nastran", "LS-DYNA", "ANSYS"] },
    "unitSystem":     { "type": "string", "enum": ["mm-tonne-s", "m-kg-s", "mm-kg-ms"] },
    "coordinateConvention": { "type": "string", "enum": ["global-Z-up", "global-Y-up"] },
    "meshStats": {
      "type": "object",
      "required": ["elementCount", "minJacobian"],
      "properties": {
        "elementCount": { "type": "integer", "minimum": 1 },
        "minJacobian":  { "type": "number", "exclusiveMinimum": 0 }
      }
    },
    "analysisType":   { "type": "string", "enum": ["static", "modal", "explicit-dynamic"] }
  }
}

Validation against this schema catches structural errors early — a missing unit system, an unrecognized solver, or a negative element count. It does not, however, capture that a model uses a particular material or is subjected to a particular load. That requires relationships, and relationships require an ontology.

Ontologies: The Semantic Layer

An ontology defines the classes of entities in a domain, their properties, and the allowed relations between them. Where a schema says "this field is a string," an ontology says "a LoadCase is applied to a Model, and a ResultSet is generated from a LoadCase." This distinction matters because ontologies support inference: if a ResultSet is generated from a LoadCase, and the LoadCase is applied to a Model, then the ResultSet transitively depends on that Model — a fact a query engine can derive without storing it explicitly.

For CAE, a compact ontology needs only a handful of core classes and relations to be useful. The classes are Model, Material, LoadCase, BoundaryCondition, ResultSet, and SimulationRun. The essential relations are:

• Model hasMaterial Material — a model may reference several materials, each assigned to a region.
• LoadCase appliedTo Model — a load case is meaningless without its target model revision.
• LoadCase includesBoundaryCondition BoundaryCondition — constraints and loads are grouped into a case.
• SimulationRun executes LoadCase — the run binds a load case to a solver configuration and produces results.
• ResultSet generatedBy SimulationRun — results inherit the full provenance chain.

These relations are directional and versioned. A load case applied to Model R3 is not automatically valid for R4; the ontology should carry the model revision on the relation, not only on the model node. This is the single most important modeling decision for CAE traceability, because geometry and mesh revisions change frequently while load definitions often persist across them.

Putting the Relationships Together

The figure below shows how the classes and relations compose into a traceable graph. Read it as a dependency structure: results sit at the top of the chain and inherit every upstream decision, so a defect in a material definition propagates to every result set that references it.

Practical Modeling Decisions

Three decisions determine whether a CAE data model survives contact with real projects. First, model the relation, not just the node. Storing modelRevision on the load case duplicates information and drifts; storing it on the appliedTo relation keeps the graph consistent when a model is re-revised. Second, treat units and coordinate conventions as first-class metadata. A result set in mm-tonne-s compared against one in m-kg-s will produce a stress ratio off by a factor of 10⁶ if the convention is ignored. Third, separate the material definition from its assignment. A material card is reusable across models; the assignment of that card to a region of a specific model revision is a distinct, versioned fact.

Validation and Failure Symptoms

A well-formed data model is testable. Run schema validation on every ingested record; a failure such as unitSystem: "mm-kg-s" (not in the enumeration) should reject the record rather than silently accept it. Then run graph integrity checks: every ResultSet must trace to exactly one SimulationRun, every SimulationRun to one LoadCase, and every LoadCase to a model revision that still exists. A dangling reference — a result set whose run points to a deleted load case — is the CAE equivalent of a broken foreign key and should be flagged, not ignored. Typical symptoms of an under-modeled dataset include results that cannot be reproduced because the material revision is unknown, load cases silently reused across incompatible geometry revisions, and unit mismatches discovered only after post-processing. Each of these is preventable at the schema and ontology layer, which is precisely why data modeling belongs at the front of a CAE data management program rather than as an afterthought.