2. Data model for CAE iterations

Comparing CAE results across design iterations is only meaningful when every result can be traced back to a well-defined, self-describing record. A result file that contains only a stress contour is nearly useless for ranking: without knowing which geometry variant produced it, which mesh was used, which solver settings were active, and which version of the model it belongs to, any comparison risks mixing incompatible data. This section defines the data model that makes multi-iteration comparison reliable — the structured record that binds design variables, mesh and solver metadata, result fields, and versioning identifiers into a single comparable unit.

The iteration record as the atomic unit

Treat each simulation run as an iteration record: an immutable, self-contained object that captures everything needed to reproduce and compare that run. The record has four logical layers, and each layer answers a different question during comparison:

• Design variables — What design point does this run represent? These are the parameters that were varied (plate thickness, rib spacing, fillet radius, material grade), stored as named key–value pairs with units.
• Mesh metadata — How was the geometry discretized? Element type, element count, node count, average and minimum element quality, mesh seed sizes, and the mesh file hash.
• Solver metadata — How was the physics solved? Solver name and version, analysis type, load case identifier, boundary condition set, convergence criteria, and the actual achieved residuals.
• Result fields — What did the run produce? Named scalar or vector fields (max von Mises stress, first natural frequency, mass, max displacement) with values, units, and the location or entity where the extremum occurred.

A versioning identifier ties the record to a specific state of the model and result set. It is not merely a filename; it is a composite key that lets you detect whether two records are legitimately comparable.

Design variables: typed, named, and unit-aware

Design variables must be stored as a dictionary rather than positional columns, because different iterations may explore different parameter subsets. Each entry should carry a name, a numeric value, a unit, and optionally a lower/upper bound used during the study. For example:

design_vars:
  plate_thickness_mm: 4.0
  rib_spacing_mm:    60.0
  fillet_radius_mm:   8.0
  material_grade:    "AA6061-T6"
  mesh_seed_mm:       3.0

Storing units explicitly prevents the classic comparison error of ranking a 4 mm design against a 0.157 in design as if the numbers were directly comparable. When a variable is categorical (material grade, element formulation), store it as a string and keep a controlled vocabulary so that "AA6061-T6" and "6061-T6" do not silently become two different design points.

Mesh metadata: the comparability gate

Mesh differences are the most common source of misleading iteration comparisons. A design that appears 8% stiffer may simply have a finer mesh in the high-gradient region. The mesh metadata block should therefore record enough to judge comparability and to reproduce the discretization:

The mesh_hash is a content hash of the exported mesh file. Two records with the same hash share an identical discretization, so any result difference is attributable to design variables or solver settings — a powerful diagnostic when ranking designs.

Solver metadata: physics and convergence provenance

Solver metadata records the analysis context. At minimum it should include the solver product and version, the analysis type (static, modal, buckling, transient), the load case or step identifier, the boundary condition set name, and the convergence status with achieved residuals. A record whose solver did not converge must be flagged, because its result fields are not trustworthy for ranking. Store the convergence flag as a boolean plus the final residual so that a "converged but marginal" run can be distinguished from a clean one.

Result fields: named, located, and unit-tagged

Result fields should be stored as a list of named quantities, each with a value, a unit, and a location descriptor. The location matters: a maximum stress of 210 MPa at a sharp re-entrant corner is a different engineering signal from the same value in a smooth fillet. A practical schema:

results:
  - name: max_von_mises
    value: 212.4
    unit: MPa
    location: "fillet_R8, node 104882"
  - name: first_mode_hz
    value: 48.7
    unit: Hz
  - name: total_mass
    value: 2.31
    unit: kg
  - name: max_displacement
    value: 0.84
    unit: mm

Keeping the extremum location as text (or as a node/element ID) allows a reviewer to verify that the reported peak is physical rather than a mesh artifact at a constrained node.

Versioning identifiers: making records comparable

A robust versioning scheme combines several identifiers so that any two records can be checked for comparability before their numbers are compared. A practical composite key is:

iteration_id:  IT-014
model_version: v3.2.1
geometry_hash: 7d1e…9ab
mesh_hash:     a3f9…c21
solver_version: "SolverX 2024.2"
study_id:      ST-07
timestamp:     2024-11-08T14:22:31Z

The model_version follows semantic versioning: patch for mesh-only or solver-setting changes, minor for geometry changes that preserve topology, major for topology or load-path changes. The geometry_hash and mesh_hash provide content-level identity independent of human-assigned version labels, catching the case where someone edits a model without bumping the version. The study_id groups iterations that belong to the same design-of-experiments campaign, so that ranking is always performed within a coherent study.

Putting the model to work: a comparability gate

With the record defined, the comparison workflow becomes a deterministic gate rather than a judgment call. Before any two iterations enter the ranking table, run a comparability check: confirm they share the same study_id and load_case, that both are converged, that their units are consistent, and that their mesh resolution is comparable (for example, element counts within a stated tolerance or identical mesh_hash). Records that fail the gate are flagged and excluded, not silently averaged in.

Consider a study with four iterations. IT-014 uses a 3 mm mesh seed and converges cleanly; IT-012 uses a 5 mm seed; IT-009 is identical to IT-014 in design variables but has a different mesh_hash; IT-007 did not converge. The gate admits IT-014 and IT-009 for a mesh-sensitivity check, admits IT-012 only after noting the coarser mesh, and excludes IT-007 entirely. The ranking table then reports stress, frequency, and mass per admitted iteration, with the mesh and solver provenance visible in adjacent columns so that a reviewer can see whether a design's apparent advantage survives a mesh refinement.

The data model described here is deliberately minimal but complete: four content layers plus a composite versioning key. It is small enough to implement in a JSON or YAML sidecar file per run, yet rich enough to answer the only question that matters during multi-iteration comparison — are these two numbers legitimately comparable, and if so, which design is better? Every subsequent ranking, sensitivity, or trade-off analysis in this course depends on getting this record right.