3. Simulation data modeling and metadata schemas

CAE artifacts are not just result files. A single simulation study typically produces a mesh, a solver deck, material definitions, boundary condition sets, solver logs, and one or more result databases — each with its own format, version, and provenance. Without an explicit data model, these artifacts become a pile of files whose relationships exist only in the memory of the engineer who created them. Simulation data modeling makes those relationships machine-readable: it defines what entities exist, which attributes describe them, how they connect, and what vocabulary is used to name them consistently across tools and teams.

This chapter builds a working metadata schema for CAE artifacts, moving from entity identification through attribute design, relationship modeling, and finally ontology-level vocabulary control. The goal is a schema that a data management system can enforce and a query engine can traverse.

From Files to Entities

The first modeling decision is what counts as an entity. A naive approach treats every file as a record, but files are storage artifacts, not conceptual objects. A more useful model identifies entities by what they represent in the engineering process. A typical CAE schema distinguishes at least the following:

• Study — the top-level container for a simulation intent, e.g., "front crashworthiness, 50 km/h full frontal, baseline body-in-white."
• Model — the discretized representation (mesh plus properties) used by one or more studies.
• LoadCase — a named combination of boundary conditions and solver settings.
• Material — a reusable definition with its own version history.
• Run — one execution of a solver on a specific model and load case, with a timestamp, solver version, and host.
• Result — the output dataset produced by a run, including field data and scalar summaries.

Each entity needs a stable identifier that survives file renaming and migration. A common pattern is a UUID plus a human-readable business key, such as STUDY-CRASH-FRONT-001. The UUID guarantees uniqueness across systems; the business key supports human communication and traceability in reports.

Attribute Design: What Must Be Captured

Attributes fall into three groups. Identity attributes describe what the entity is: name, type, owner, creation timestamp. Technical attributes capture engineering content: element count, element type, solver, units system, material model. Provenance attributes record lineage: parent entity, source tool, transformation applied, approval status.

Provenance is where most ad hoc schemas fail. Consider a mesh that was cleaned and re-meshed three times before a run. If the schema only stores the final mesh file, the intermediate geometry repairs and their rationale are lost. A practical schema stores a derivedFrom reference on each Model entity and a transformation attribute describing the operation, e.g., geometry_cleanup: remove_small_fillets, tolerance=0.5mm. This makes the lineage graph queryable: given a result, you can walk backward to the original CAD revision.

Units deserve explicit treatment. CAE data mixes mm-tonne-s, m-kg-s, and inch-lbf-s systems, often within the same organization. Store the unit system as a mandatory enumerated attribute on Model and Material, and validate it at ingestion. A result whose unit system is unknown should be flagged rather than silently accepted.

Relationships and Cardinality

Entities become useful when connected. The core relationships in a CAE schema are:

Cardinality choices have downstream consequences. If referencesMaterial is modeled as many-to-one, a model cannot mix materials — clearly wrong for assemblies. If it is many-to-many without version pinning, a material update silently changes the meaning of historical results. The correct pattern is a junction entity, ModelMaterialAssignment, carrying the material version and the part or region it applies to.

Ontologies and Controlled Vocabulary

A schema defines structure; an ontology defines meaning. In practice, ontology work in CAE data management means establishing controlled vocabularies for the values that recur across entities. Solver names, element types, analysis types, and failure criteria should come from enumerated lists rather than free text. Otherwise "Abaqus/Explicit," "abaqus explicit," and "ABAQUS-EXPL" become three incompatible values in the same database.

A lightweight approach is sufficient for most organizations: define a SKOS-style concept scheme for each vocabulary domain, with preferred labels, alternate labels, and a stable concept ID. For example, the analysis-type scheme might contain AT-STRUCT-STATIC, AT-STRUCT-MODAL, AT-STRUCT-BUCKLING, and AT-CRASH-EXPLICIT. Attributes then store the concept ID, and display layers resolve the preferred label. This keeps queries exact while allowing human-friendly rendering.

Schema in Practice: A Minimal JSON Schema Fragment

The following fragment shows how the Model entity can be expressed as a JSON Schema, with mandatory provenance and unit-system validation. It is illustrative and uses representative field names.

{
  "$id": "cae:Model",
  "type": "object",
  "required": ["uuid", "businessKey", "unitSystem", "elementCount", "derivedFrom"],
  "properties": {
    "uuid":        { "type": "string", "format": "uuid" },
    "businessKey": { "type": "string", "pattern": "^MODEL-[A-Z0-9-]+$" },
    "unitSystem":  { "enum": ["mm-t-s", "m-kg-s", "in-lbf-s"] },
    "elementCount":{ "type": "integer", "minimum": 1 },
    "elementType": { "type": "string" },
    "derivedFrom": { "type": "string", "format": "uuid" },
    "transformation": { "type": "string" },
    "materialAssignments": {
      "type": "array",
      "items": {
        "type": "object",
        "required": ["materialUuid", "materialVersion", "region"],
        "properties": {
          "materialUuid":    { "type": "string", "format": "uuid" },
          "materialVersion": { "type": "integer", "minimum": 1 },
          "region":          { "type": "string" }
        }
      }
    }
  }
}

Two design choices in this fragment matter. First, derivedFrom is required, forcing every model to declare its lineage — a root model uses a self-reference or a sentinel value. Second, material assignments carry an explicit materialVersion, so historical results remain interpretable after a material is revised.

Validating the Schema Against Real Data

A schema is only useful if it rejects bad data at ingestion. A practical validation loop works as follows. Take a sample of ten existing CAE jobs from the archive. For each, attempt to populate the schema from available metadata. Record every field that cannot be filled and every value that fails enumeration. Fields that are consistently empty indicate either a missing source system or an over-specified schema; values that fail enumeration indicate vocabulary gaps. Iterate the schema until the sample passes with no more than a small, documented exception list.

Typical failure symptoms during this exercise are informative. If unitSystem is missing for most legacy models, the organization needs a backfill rule — for example, inferring from solver deck headers and flagging ambiguous cases for manual review. If derivedFrom is absent because meshes were created outside the managed toolchain, the schema should permit an explicit externalSource marker rather than forcing a false lineage claim.

The diagram above shows the entity set, the cardinality-bearing relationships, the material-assignment junction, and the lineage chain that makes provenance queryable. The dashed bindings to the vocabulary panel indicate that enumerated attributes store concept IDs rather than free text.

Practical Takeaways

• Model entities by engineering meaning, not by file format; give each a UUID plus a business key.
• Make provenance mandatory. A model without a declared lineage is a model whose results cannot be defended.
• Pin material versions through a junction entity; never let a material update silently reinterpret historical results.
• Enforce unit systems and solver/analysis vocabularies at ingestion, using concept IDs from a controlled scheme.
• Validate the schema against a real sample of archived jobs before rollout; treat empty mandatory fields and enumeration failures as design feedback, not as data-entry errors.

A schema that passes this validation loop becomes the contract between CAE tools, the data management platform, and downstream consumers such as reporting and optimization workflows. Once entities, attributes, relationships, and vocabularies are fixed, the remaining quality-control work — completeness checks, consistency rules, and automated gating — can be expressed as queries and constraints over a well-defined graph rather than as manual inspection of folders.