1. CAE simulation data landscape

Before a single table is created, a database designer working with CAE data must understand what that data actually is. Simulation results are not a uniform stream of numbers; they are a heterogeneous mix of scalar fields, vector and tensor fields, time histories, modal data, and derived quantities, each with its own dimensionality, sampling structure, and metadata dependencies. A schema that treats all of these as "results" will either collapse under its own generality or force every query to reconstruct meaning that should have been stored explicitly. This chapter maps the data landscape so that later design decisions — table granularity, key structure, indexing, and partitioning — rest on a clear model of the underlying objects.

Result types and their structural signatures

The first distinction that matters for storage is where a result lives and how many values it carries per location. A nodal displacement field, for example, is defined at every node of a mesh and carries three components per node. A von Mises stress field is typically defined at element integration points or extrapolated to nodes, and carries one scalar per location. A modal analysis produces eigenvectors (mode shapes) that are dense vectors over all degrees of freedom, plus eigenvalues that are a handful of scalars. A transient run produces the same field at many time steps, so the data volume scales with the number of steps.

These differences are not cosmetic. They determine whether a result can be stored as one row per location, one row per location per time step, or one row per mode per degree of freedom. They also determine the natural key: a scalar nodal result needs (result_id, node_id), a transient result needs (result_id, node_id, step_index), and a modal result needs (result_id, mode_index, dof_id). Getting this wrong at design time produces either enormous row counts with redundant columns or wide tables that violate normalization and make filtering expensive.

A practical taxonomy that holds across most solvers (Abaqus, ANSYS, Nastran, OpenFOAM, and their peers) separates results into four families:

• Field results — values defined over a spatial domain (nodes, elements, cell centers, integration points). Subdivided by tensor rank: scalar (temperature, pressure, von Mises), vector (displacement, velocity, flux), and tensor (stress, strain).
• History results — time series at a small set of monitored locations (a probe point, a reference node, a reaction force). Low cardinality in space, high cardinality in time.
• Modal results — eigenvalue/eigenvector pairs. The eigenvalues are scalars; the eigenvectors are dense vectors indexed by degree of freedom.
• Derived and summary results — maxima, minima, safety factors, mass, energy totals, convergence residuals. Often computed post hoc but frequently the values analysts query most.

Metadata: the part that makes results interpretable

A raw array of floats is meaningless without the context that produced it. The metadata layer is what allows a database to answer "which solver version, which mesh, which material, which boundary conditions, and which unit system produced this number?" In practice, CAE metadata falls into several tiers, and the tiers have very different cardinalities and update frequencies — a fact that should drive how they are stored.

Study-level metadata describes the analysis as a whole: study identifier, analyst, solver name and version, analysis type (static, modal, transient, explicit), start and end time, and the unit system. This is low-cardinality, high-value context that every result row implicitly depends on. It belongs in a parent table referenced by foreign key, not duplicated per result row.

Model-level metadata describes the discretized model: mesh identifier, node count, element count, element types present, coordinate system definition, and material assignments. Mesh identity is especially important because results are only comparable across runs that share a mesh, and because mesh topology is itself a substantial dataset (node coordinates, element connectivity) that may live in the same database or in an external file store.

Result-level metadata describes each individual result: its name, physical quantity, tensor rank, component count, location type (nodal, elemental, integration point), unit, and the step or time value it corresponds to. This is the tier that most directly shapes the results table design, because it determines the number of value columns and the meaning of each.

Where the storage challenges come from

The challenges in storing CAE results are not primarily about raw volume, although volume is real: a transient run on a million-node mesh with ten output steps and six components per node produces sixty million floating-point values before any indexing overhead. The harder problems are structural.

Sparsity and irregularity. Not every result is defined at every location. Contact results exist only on contact surfaces; element results exist only on elements of a given type; probe histories exist only at their probe points. A schema that assumes a dense rectangular grid wastes space and complicates queries.

Heterogeneous component counts. Displacement has three components, stress has six (in symmetric tensor form), temperature has one. Storing these in a single table forces either a fixed maximum component count with many nulls, or an entity-attribute-value (EAV) design that pushes type information into rows and makes numeric filtering awkward. The usual resolution is to separate result families into their own tables with explicit component columns.

Time and step semantics. "Step 5" means different things in a static multi-step analysis, a transient run, and a modal extraction. Storing a bare integer step index without a step-type discriminator and a physical time value makes downstream queries ambiguous. The step dimension should be modeled explicitly, with its own table carrying step index, physical time, and step type.

Unit and coordinate consistency. Results from different solvers or different studies may use different units and different coordinate systems. If units are not stored alongside values, comparisons and aggregations silently produce wrong answers. The safe pattern is to store the unit string with the result metadata and to normalize to a canonical unit at ingestion where feasible.

Provenance and reproducibility. Analysts need to trace a result back to the exact input deck, solver version, and mesh that produced it. Without a provenance chain, a database of results becomes a collection of numbers of unknown reliability. Provenance is metadata, and it must be captured at ingestion, not reconstructed later.

From landscape to schema: a worked example

Consider a static structural study on a bracket, solved in Abaqus, with a mesh of 120,000 nodes and 80,000 elements. The analyst extracts three results: displacement (vector, 3 components, nodal), von Mises stress (scalar, 1 component, extrapolated to nodes), and reaction force at a reference node (history, 3 components, 1 probe). Suppose the study has a single static step.

The displacement result produces 120,000 × 3 = 360,000 values. The stress result produces 120,000 values. The reaction history produces a small number of time samples — say 50 — times 3 components. If these were stored in one generic table with a fixed six-component layout, the displacement rows would carry three nulls each and the stress rows five nulls each, and every query filtering on stress would scan rows whose meaning depends on a type column. Splitting into field_value (with explicit c1..c3 columns for vector results and a separate scalar path or a component column for scalars) and history_value keeps each table's rows homogeneous and its indexes useful.

The metadata side is equally concrete. The study row carries the solver version and unit system (say, mm–N–MPa). The model row carries the mesh identifier and node/element counts. Each result row carries its location type and component count. The step table carries one row: index 1, time 1.0, type "static". A query such as "maximum von Mises stress at step 1" then becomes a straightforward aggregate over a homogeneous table joined to a single step row, rather than a type-dispatch exercise.

What this means for the chapters ahead

The landscape described here sets the constraints that the rest of the course works within. Result families determine table granularity and key structure. Metadata tiers determine the parent tables and foreign keys. The pressure points — sparsity, heterogeneous components, step semantics, unit and provenance consistency — determine where normalization, partitioning, and ingestion validation are needed. A designer who can classify a new result into one of the four families, name its location type and component count, and identify which metadata tier it depends on is already most of the way to a correct schema. The next step is to turn that classification into concrete tables, keys, and constraints, which is where the course proceeds.