2. Result data models

Every CAE result file, regardless of vendor, is an instance of a small number of conceptual data models. Understanding these models is the prerequisite for harmonization: you cannot map Nastran's OP2 output onto Ansys RST output, or align an Abaqus ODB with a CGNS file, until you know which entities each format uses to represent geometry, physical quantities, sampling axes, and provenance. This section defines the four canonical result data models — mesh, field, time/frequency, and metadata — and shows how the major solvers instantiate them differently.

The Mesh Model: Topology, Coordinates, and Result Location

The mesh model answers three questions: what are the nodes and elements, where are they in space, and where are results attached? Across solvers, the topology is broadly similar (nodes, elements, connectivity), but the result location differs fundamentally and is the most common source of harmonization errors.

Three location conventions dominate:

• Nodal results — values defined at grid points (e.g., displacement, temperature). Interpolation to any other location is well-defined.
• Element (centroid) results — values defined per element (e.g., element strain energy, some stress recovery outputs). These cannot be interpolated to nodes without a recovery scheme.
• Integration-point results — values at Gauss points inside elements (e.g., Abaqus ODB stresses, Ansys RST element stresses). Extrapolation to nodes is solver-specific and lossy.

For example, Nastran OP2 stores displacements at grid points but stresses at element centroids by default; Abaqus stores stresses at integration points and provides an extrapolation to nodes only when requested. If you compare a Nastran centroid stress against an Abaqus nodal-extrapolated stress without accounting for this, you will see discrepancies of 5–20% that are purely representational, not physical.

The Field Model: Physical Quantity, Components, and Units

A field is a named physical quantity sampled over the mesh. Its essential attributes are:

The component-order and coordinate-system conventions are the two most frequent silent errors. A tensor stored in Voigt order with YZ and ZX swapped will produce a plausible-looking but wrong von Mises stress. Similarly, a stress field expressed in a local cylindrical system (common for pressure vessels) must be rotated to global before comparison with a solver that reports global stresses.

The Time/Frequency Model: Sampling Axes and Domain

Results are rarely a single snapshot. The sampling axis defines how the field varies:

• Static — one or more load steps, no continuous axis.
• Modal / frequency — discrete eigenmodes or a frequency sweep; each sample has a natural frequency and possibly a damping ratio.
• Transient — time samples, often non-uniform; may be stored as real+imaginary pairs for harmonic analysis.
• Complex / harmonic — magnitude and phase, or real and imaginary parts.

Solvers differ in how they encode this axis. Nastran OP2 uses a Subcase + Mode or Time identifier; Abaqus ODB uses Step + Frame; Ansys RST uses LoadStep + Substep. A harmonization layer must map these onto a common (step, sample, domain) tuple. The domain (time vs frequency vs modal) must be explicit, because a mode number and a time value are not interchangeable even if both are integers.

The Metadata Model: Provenance, Units, and Solver Context

Metadata is what makes a result interpretable. It includes:

• Provenance — solver name, version, input deck hash, run timestamp.
• Units — the unit system used, ideally explicit rather than assumed.
• Coordinate frames — global origin, orientation, and any local systems referenced by fields.
• Solution context — analysis type, load case, boundary conditions summary.
• Mesh identity — a hash or checksum of the mesh so that results can be matched to the correct geometry.

Without metadata, two files with identical field names may be incomparable. A common practice is to embed a manifest alongside the result data, containing the fields above in a neutral schema such as JSON or CGNS Descriptor nodes.

Cross-Solver Representation Map

The following diagram summarizes how the four models are instantiated across three representative solvers and where harmonization must intervene.

Practical Harmonization: A Minimal Neutral Schema

To make the four models comparable, define a neutral result schema with explicit fields. A minimal JSON representation for a single field sample might look like:

{
  "mesh_id": "sha256:9f2c...",
  "location": "nodal",
  "quantity": "stress",
  "components": ["XX","YY","ZZ","XY","YZ","ZX"],
  "units": "MPa",
  "frame": "global",
  "domain": "frequency",
  "sample": { "mode": 3, "frequency_hz": 142.7, "damping": 0.02 },
  "values": [ ... ],
  "provenance": { "solver": "Nastran", "version": "2023.4", "subcase": 1 }
}

When ingesting a Nastran OP2, you would set location to "centroid" if reading element stresses, and "nodal" if reading grid point stresses. For Abaqus ODB, you would set location to "integration_point" and either extrapolate to nodes or keep the integration-point values with an explicit flag. The frame field must be resolved by reading the solver's local orientation definitions and rotating to global if needed.

Common Failure Modes and How to Detect Them

• Silent unit mismatch — a field in Pa compared against one in MPa yields a factor of 10⁶ error. Detect by checking the magnitude of a known reference value.
• Component-order swap — YZ and ZX exchanged produces a wrong but plausible von Mises. Detect by comparing individual tensor components, not just invariants.
• Frame mismatch — local cylindrical vs global Cartesian. Detect by checking the direction of the maximum principal stress against the expected load direction.
• Location mismatch — centroid vs nodal-extrapolated. Detect by comparing the spatial distribution: centroid values are piecewise constant per element, nodal values are smooth.
• Sampling-axis confusion — mode number treated as time step. Detect by checking the domain tag and the physical range of the sample values.

Each of these failures is representational, not physical. A robust harmonization pipeline records the four models explicitly, validates them against a reference case, and refuses to compare fields whose location, frame, or units are unresolved. The next section builds on this foundation by examining how to align meshes when the underlying discretizations differ.