2. CAE data lifecycle

CAE analytics rarely fails because of a lack of simulation data. It fails because the data that exists is fragmented across disciplines, formats, and storage tiers, and because the relationships between a mesh, a solver deck, a result file, and a report are implicit rather than recorded. Understanding the CAE data lifecycle is therefore not an academic exercise — it is the prerequisite for building any production analytics service that can answer questions such as "which designs exceeded the thermal limit?" or "how did mesh quality correlate with solver convergence?"

This chapter traces a single simulation through four lifecycle stages: model generation, solver execution and outputs, post-processing artifacts, and metadata extraction. The goal is to make explicit what each stage produces, what identifiers link the stages together, and which fields are worth persisting for downstream analytics.

Stage 1 — Model Generation

Model generation covers everything from CAD import through meshing and the assembly of a solver input deck. The artifacts produced here are the definition of the simulation: they describe what was analyzed, not what happened.

Typical artifacts include:

• Geometry — native CAD, neutral formats (STEP, Parasolid), or a defeatured/topology-cleaned derivative. The defeatured version is usually what the solver actually sees, so it must be versioned separately from the source CAD.
• Mesh — node and element connectivity, plus quality metrics (aspect ratio, Jacobian, skewness, minimum orthogonality). Mesh files are large and are usually stored as binary (e.g., .cgns, .bdf, .msh, .inp).
• Solver deck / input file — boundary conditions, material cards, load cases, solver control parameters. This is the smallest but most analytically valuable artifact, because it encodes the engineering intent.
• Model manifest — the human- and machine-readable record of what was assembled: part revisions, material assignments, unit system, coordinate system conventions.

A critical practice at this stage is assigning a stable model ID and recording the unit system and coordinate frame explicitly. Unit mismatches (mm vs. m, N vs. lbf) and sign conventions for normals or rotations are among the most common causes of downstream analytics errors, because a result value without a declared unit is not a measurement — it is a number.

Stage 2 — Solver Execution and Outputs

When the deck is submitted, the solver produces two fundamentally different classes of output: run-level records and field results.

Run-level records include the solver log, convergence history, wall-clock time, iteration count, and exit status. These are small, structured, and extremely valuable for analytics — they let you correlate convergence behavior with mesh quality or load case severity. A typical convergence record might look like:

# residual_history.csv (excerpt, illustrative)
iteration, continuity, x_velocity, y_velocity, energy, wall_time_s
1,   1.00e+00, 1.00e+00, 1.00e+00, 1.00e+00, 12.4
50,  3.21e-02, 4.07e-02, 3.88e-02, 1.12e-02, 318.7
120, 8.90e-05, 1.44e-04, 1.31e-04, 6.02e-06, 902.1
150, 4.12e-06, 7.03e-06, 6.55e-06, 2.88e-07, 1187.5
# status: CONVERGED (all residuals < 1e-5)

Field results are the large volumetric or surface datasets: pressure, temperature, displacement, stress tensor components, velocity vectors. They are typically written to formats such as .rst (ANSYS), .op2 (Nastran), .odb (Abaqus), .foam (OpenFOAM), or .vtu/.vtk (ParaView). These files are the payload of the lifecycle and dominate storage cost.

Two identifiers must be captured at this stage: the run ID (unique per solver invocation) and the model ID it consumed. Without this link, a result file is orphaned — you can open it, but you cannot say which mesh or boundary conditions produced it.

Stage 3 — Post-Processing Artifacts

Post-processing transforms raw fields into engineering quantities. This is where the lifecycle becomes semantically rich, because post-processing encodes judgment: which contour, which probe, which derived quantity matters.

Common post-processing artifacts include:

• Scalar extracts — max von Mises stress, peak temperature, drag coefficient, mass flow rate. These are the numbers that appear in reports and are the primary targets for analytics.
• Probe / monitor data — time histories at specific points or surfaces.
• Contour images and animations — visual evidence, usually stored as PNG or MP4 with a caption describing the view, scale, and units.
• Derived fields — safety factor, fatigue life, margin to yield, computed from primary fields plus material allowables.

The key discipline here is traceability: every scalar extract should record the run ID, the field it was derived from, the extraction method (e.g., "max over all nodes" vs. "max over named selection BOLT_HOLES"), and the unit. A peak stress value of 412.7 is meaningless without knowing whether it is MPa or psi, and whether it was taken over the whole part or a subregion.

Stage 4 — Metadata for Analytics

Metadata is the connective tissue that turns a pile of files into a queryable dataset. It should be extracted automatically at each stage and stored in a structured form — typically a relational table, a JSON document, or a graph — separate from the bulk binary data.

A practical metadata schema for a single simulation record might include the following fields:

With this schema, analytics queries become straightforward: "find all steady-state thermal runs on bracket v3 where min orthogonality < 0.2 and peak temperature > 380 K" is a single SQL or document query, not a manual file hunt.

How the Stages Connect

The diagram below shows the four lifecycle stages and the identifiers that link them. Note that metadata is extracted at every stage, not only at the end — this is what makes the dataset analytics-ready rather than merely archived.

Practical Implications for Production Services

Three engineering decisions determine whether this lifecycle supports analytics or collapses under its own weight.

First, extract metadata at write time, not read time. Parsing a 40 GB result file to find the peak temperature every time a dashboard loads is not viable. Extract the scalar at the moment post-processing runs, store it in the metadata record, and keep the bulk file for deep-dive inspection only.

Second, enforce identifier propagation. The model_id must flow into the solver deck, the solver must stamp the run_id into its log, and post-processing must carry both forward. If any stage drops an identifier, the chain breaks and the record becomes unqueryable. A simple validation rule — reject any post-processing job whose input lacks a run_id — prevents most orphaned data.

Third, version the schema, not just the data. As analytics requirements evolve, new metadata fields appear (e.g., fatigue_life_cycles, thermal_margin_K). A schema registry with backward-compatible evolution lets old records remain queryable while new fields are populated going forward. Without this, every schema change forces a full re-extraction of historical data.

The lifecycle described here is the foundation for everything that follows in this course. Once model, run, and post-processing records are linked by stable identifiers and enriched with units, regions, and convergence status, the CAE dataset becomes a first-class analytics asset — queryable, joinable, and trustworthy.