2. CAE data models and metadata schemas

An enterprise CAE data science platform lives or dies by the quality of its data model. Simulation data is heterogeneous by nature: a single load case may reference a mesh with millions of nodes, a set of boundary conditions tied to named selections, a material card with temperature-dependent curves, solver control parameters, and a result field defined on a different discretization than the input mesh. Without an explicit schema, every downstream analytics task — surrogate training, sensitivity studies, anomaly detection — becomes a bespoke parsing exercise. This chapter defines the core entities, their relationships, and the metadata conventions that make CAE data queryable, joinable, and reproducible.

Core Entity Model

A practical CAE data model separates five entity families: geometry/mesh, boundary conditions, material properties, solver settings, and results. Each family is versioned and linked through a common case_id and model_revision. The mesh is the spatial backbone; boundary conditions and results reference mesh entities by stable identifiers rather than by array index, because re-meshing invalidates positional indices.

The following schema fragment shows a minimal but production-viable representation using a document-oriented store (JSON-like), with explicit units and provenance fields:

{
  "case_id": "crash_frontal_0042",
  "model_revision": "r3",
  "mesh": {
    "mesh_id": "m_r3_hex",
    "node_count": 1842300,
    "element_types": ["C3D8R", "C3D6"],
    "coordinate_system": "global_cartesian_mm",
    "checksum": "sha256:9f2c..."
  },
  "boundary_conditions": [
    {
      "bc_id": "bc_fix_rear",
      "type": "displacement",
      "target": {"set_name": "NSET_REAR", "entity": "node"},
      "dof": [1, 2, 3],
      "value": 0.0,
      "unit": "mm"
    },
    {
      "bc_id": "bc_vel_front",
      "type": "velocity",
      "target": {"set_name": "NSET_FRONT", "entity": "node"},
      "dof": [1],
      "value": -15000.0,
      "unit": "mm/s"
    }
  ],
  "materials": [
    {
      "material_id": "steel_dp780",
      "model": "Johnson-Cook",
      "parameters": {"A": 450.0, "B": 780.0, "n": 0.35, "C": 0.014, "m": 1.0},
      "unit_system": "MPa_mm_s",
      "source": "material_db_v2.1"
    }
  ],
  "solver": {
    "solver": "Abaqus/Explicit",
    "version": "2023",
    "time_step": 1.2e-6,
    "mass_scaling": 0.0,
    "output_interval": 5.0e-5
  },
  "results": [
    {
      "result_id": "res_vm_stress",
      "field": "S_Mises",
      "location": "element_centroid",
      "mesh_id": "m_r3_hex",
      "frames": 240,
      "unit": "MPa"
    }
  ]
}

Two design decisions deserve emphasis. First, every physical quantity carries an explicit unit or unit_system; implicit unit assumptions are the most common source of silent errors when merging datasets from different teams. Second, boundary conditions and results reference set_name and mesh_id rather than raw indices, so that a re-meshed revision can be re-linked through named selections.

Mesh and Topology Metadata

The mesh entity stores topology and geometry metadata separately. Topology covers element type, connectivity, and node count; geometry metadata covers bounding box, characteristic element length, and quality metrics such as Jacobian ratio and aspect ratio. For data science workflows, the most valuable derived fields are element_centroid coordinates and element_volume, because they allow result fields to be resampled onto a common grid for cross-case comparison.

A common pitfall is treating the mesh as immutable. In practice, mesh convergence studies produce multiple revisions of the same model. The schema must therefore treat mesh_id as a first-class key and record the parent-child relationship between revisions, so that a query like "all results computed on meshes with element size below 2 mm" is expressible.

Boundary Conditions and Solver Settings

Boundary conditions are best modeled as typed records with a target, a dof list, a value, and a unit. The target resolves to a named set on the mesh. This indirection is what makes BCs portable across mesh revisions. Solver settings are stored as a flat parameter map keyed by solver name and version, because solver option names differ across codes and versions; storing them as free-form key-value pairs preserves fidelity without forcing a lossy normalization.

When ingesting legacy decks, resolve named sets to mesh entity IDs at ingestion time and store both the original set name and the resolved ID list. This preserves traceability while enabling fast spatial queries.

Results Representation

Results are the largest and most frequently queried entity. A result field is defined by four attributes: the physical quantity (field), the location (nodal, element centroid, integration point), the mesh it is defined on (mesh_id), and the time or frequency frames. Storing results as columnar arrays (Parquet or HDF5) keyed by result_id and frame keeps storage compact and enables predicate pushdown. For time-series analytics, a long-format table with columns case_id, frame, entity_id, value is often more convenient than wide per-frame arrays, at the cost of larger storage.

The diagram below summarizes how the five entity families connect through shared keys and how a query traverses from a case to a specific result field.

CAE Data Model: Entity Relationships and Query Path Case case_id + model_revision Mesh mesh_id, topology, centroids, quality Boundary Conditions target set, dof, value, unit Material model, parameters, unit_system, source Solver Settings solver, version, time_step, output Results field, location, mesh_id, frames Query path: case_id → mesh_id → result_id → frame → entity_id → value BCs and materials join on case_id; results join on mesh_id to guarantee spatial consistency.

Schema Validation and Ingestion

Before any analytics run, the ingestion pipeline should validate each case against the schema. A minimal validation checklist includes: every bc_id resolves to an existing named set; every result_id references a mesh_id present in the case; all physical quantities carry units; and solver version is recorded. Failures should be logged with the offending field path, not silently dropped.

For a reproducible example, consider ingesting a batch of 50 crash cases. The pipeline reads each solver deck, extracts the five entity families, resolves named sets to node/element ID lists, and writes one Parquet file per result field partitioned by case_id. A validation query then checks that the number of frames in each result matches the solver's declared output interval. If a case fails — for example, a result field references a mesh revision that was overwritten — the pipeline quarantines that case and emits a structured error record. The observable success criterion is a validation report showing 50/50 cases passing all checks and a query returning consistent element counts across all cases.

Do not normalize solver-specific option names into a generic vocabulary during ingestion. Solver semantics differ subtly (for example, mass scaling in explicit dynamics has no direct equivalent in implicit codes). Preserve the original key-value pairs and add a separate normalized view only when a specific analytics task requires it.

Practical Takeaways

  • Model the five entity families as separate, versioned records linked by case_id and mesh_id.
  • Reference mesh entities through named sets, never through positional indices.
  • Attach explicit units to every physical quantity and record provenance for materials and solver settings.
  • Store results in columnar format partitioned by case and field to keep queries fast and storage compact.
  • Validate at ingestion and quarantine failures with structured error records rather than dropping them silently.

With this schema in place, the platform can answer cross-case questions — comparing peak stress across materials, correlating mesh density with result variance, or training a surrogate on aligned feature vectors — without re-parsing solver decks. The next step is to build the ingestion and validation pipeline that enforces these contracts automatically.

← Previous 📖 Contents Next →