3. Simulation data modeling and metadata schemas

CAE artifacts are rarely just a mesh file or a solver output. A single design iteration typically produces a geometry revision, a meshing report, a solver deck, boundary-condition definitions, material cards, a results database, and a validation memo — each with its own format, owner, and lifecycle. Simulation data modeling is the discipline of turning that heterogeneous pile into a structured, queryable, and governable information model. The core question is not "where do we store the files?" but "what entities exist, what attributes do they carry, how are they related, and what vocabulary do we use to describe them consistently?"

From Files to Entities: The Modeling Mindset

A file-centric view treats wing_v3_modal.bdf as the unit of record. An entity-centric view treats it as an attachment to a Simulation Run entity, which in turn references a Model entity, a Load Case entity, and a Material Set entity. This shift matters because entities can be versioned, related, queried, and governed, while bare files cannot. In practice, most CAE data management platforms (Teamcenter Simulation, 3DEXPERIENCE, Ansys Minerva, open-source alternatives built on metadata stores) implement exactly this: a relational or graph backbone holding metadata, with bulk binary payloads delegated to a file store or object storage.

A workable entity model for CAE typically distinguishes four layers:

  • Product definition entities — Part, Assembly, Geometry Revision. These usually originate in CAD/PDM and are referenced, not duplicated.
  • Simulation setup entities — Model (mesh + idealization), Material Set, Property Set, Load Case, Boundary Condition Set, Solver Deck. These are the analyst's authored inputs.
  • Execution entities — Simulation Run, Solver Job, Solver Version, Run Status. These capture what was actually executed, when, on which hardware, with which license.
  • Result and evidence entities — Result Set, Scalar/Field Output, Report, Approval Record. These support downstream consumption and audit.

The relationships between these layers carry as much meaning as the entities themselves. A Simulation Run uses a Model, applies a Load Case, produces a Result Set, and is governed by an Approval Record. Modeling these as explicit typed relations — rather than free-text notes — is what enables traceability queries such as "which runs used material card MAT-17 revision C, and which of those were approved?"

Attributes: The Minimum Viable Schema

Attributes should be chosen for queryability and governance, not for completeness. A pragmatic minimum for a Simulation Run entity includes: a stable identifier, the referenced model and load-case IDs, solver name and version, run timestamp, executing user, status (queued, running, completed, failed, invalidated), and a content hash of the solver deck. The content hash is particularly valuable: it lets you detect that two nominally identical runs actually used different decks, a common source of irreproducible results.

Attributes also need controlled types and units. A wall thickness stored as the string "2.5" is useless for cross-model queries; stored as a quantity with value 2.5 and unit mm, it becomes comparable. The same discipline applies to load magnitudes, frequencies, and material properties. Where the platform supports it, store numeric values with an explicit unit field rather than embedding units in the attribute name.

A useful test for any proposed attribute: name three queries that would break if the attribute were removed. If you cannot, it is probably documentation rather than metadata and belongs in a report, not the schema.

Ontologies and Controlled Vocabularies

An ontology goes beyond a schema by defining the meaning of terms and the logical constraints between them. In CAE, lightweight ontologies are usually sufficient: a taxonomy of analysis types (structural static, modal, transient, thermal, CFD steady-state), a taxonomy of load types (force, pressure, displacement, thermal, gravity), and a taxonomy of result quantities (von Mises stress, principal stress, displacement magnitude, temperature). These vocabularies prevent the classic drift where one team writes static_struct, another STRUCT_STATIC, and a third linear static — three labels for one concept, invisible to any query.

Standards provide ready-made anchors. STEP AP209 defines an information model for structural analysis and composites, covering finite-element models, materials, and results. ISO 10303-243 extends this toward simulation data management. The W3C PROV model offers a general vocabulary for provenance (Entity, Activity, Agent) that maps cleanly onto Simulation Run, Solver Job, and User. Adopting these where they fit saves design effort and improves interoperability; extending them locally where CAE-specific concepts are missing is normal and expected.

Product Definition Simulation Setup Execution Result & Evidence Part part_id, rev Assembly asm_id, config Geometry Revision geom_id, rev, hash Model mesh, idealization Material Set mat_id, rev Load Case type, magnitude, unit Solver Deck deck_hash, format Simulation Run run_id, status, ts Solver Job solver, version, host Result Set quantity, location Report report_id, rev Approval Record approver, decision derives contains references uses executes produces summarized in governed by

Implementing the Schema: A Concrete Example

Consider a bracket modal analysis. The analyst creates a Model entity referencing Geometry Revision BRK-0042 rev C, attaches a Material Set containing an aluminum card with E = 71000 MPa, ν = 0.33, ρ = 2.70e-9 t/mm³, and defines a Load Case of type modal requesting the first six modes with fixed boundary conditions at the mounting holes. The solver deck is exported and hashed. A Simulation Run is created with status queued, then transitions to running and completed. The Result Set records the first six natural frequencies and mode shapes, and a Report is generated and routed for Approval.

A minimal JSON representation of the run entity might look like this:

{
  "run_id": "RUN-2024-0871",
  "model_ref": "MOD-BRK-0042-C",
  "load_case_ref": "LC-MODAL-01",
  "material_set_ref": "MAT-AL6061-C",
  "solver": { "name": "Abaqus", "version": "2023" },
  "deck_hash": "sha256:9f2c...a71d",
  "status": "completed",
  "started_at": "2024-11-12T09:14:22Z",
  "completed_at": "2024-11-12T09:31:05Z",
  "executed_by": "j.chen"
}

With this record in place, a quality engineer can answer "which runs used material revision C and completed successfully?" with a single filtered query, and can verify that the deck hash matches the archived deck before trusting the results. Without the schema, the same question requires opening folders and reading filenames — a process that does not scale beyond a handful of runs.

Schema Governance and Evolution

Schemas drift. New solver types, new result quantities, and new regulatory fields appear. Two practices keep the model usable: first, treat the schema as a versioned artifact with a changelog, so that old records remain interpretable; second, distinguish required from optional attributes and enforce required ones at ingestion time via validation rules. A run record missing a deck hash should be rejected or flagged, not silently accepted. Where the platform supports it, encode these constraints as machine-checkable rules (SHACL for RDF-based stores, JSON Schema for document stores) so that validation is automatic rather than dependent on reviewer diligence.

A common failure mode is over-modeling: teams define fifty attributes, populate twenty, and query five. Start with the minimum set that supports traceability and quality gates, then extend only when a concrete query or audit requirement demands it.

The payoff of a well-designed metadata schema is not aesthetic. It is the ability to ask precise questions across thousands of runs — which models used an outdated material card, which results were approved before a geometry change, which solver versions produced outliers — and to get trustworthy answers. That capability is the foundation on which every subsequent quality-control mechanism in this course depends.

← Previous 📖 Contents Next →