3. CAE data lifecycle

CAE data is not a single artifact but a chain of dependent states. A crashworthiness model, for example, begins as CAD geometry, becomes a meshed assembly, is consumed by a solver, produces a result database, and finally becomes a signed-off engineering conclusion. Each transition changes the data's form, owner, and meaning. If any transition is untracked, the final conclusion loses its evidentiary value — you can no longer prove which geometry, which material card, or which solver version produced the number in the report.

This chapter treats the CAE lifecycle as five stages — model build, solver execution, post-processing, result interpretation, and archival — and defines the traceability checkpoint that must be satisfied before data is allowed to move to the next stage. The checkpoints are the enforcement mechanism; the stages are just where work happens.

Stage 1 — Model Build

Model build converts design intent into a solvable discretization. Typical inputs are CAD in STEP or JT, a meshing specification, material and section definitions, and boundary/loading conditions. The output is a solver deck (for example, a .key or .inp file) plus its include tree.

The traceability problem here is provenance of the mesh. A mesh is only meaningful relative to the geometry revision it was generated from. Practical discipline:

• Record the CAD revision and the exact export timestamp in the model metadata, not in a filename alone.
• Keep the include hierarchy explicit. A deck that pulls *INCLUDE files from a shared library is only reproducible if those library files are versioned.
• Hash the final deck. A SHA-256 checksum of the assembled input is the cheapest possible identity for a model.

Checkpoint MB-1: the assembled deck must be hashable, and its geometry/material references must resolve to immutable revisions. If a material card is edited after the hash is taken, the hash is invalid and the model must be re-baselined.

Stage 2 — Solver Execution

Solver execution is where the model meets physics. The critical traceability objects are the solver identity and the run environment. Two runs of the same deck on different solver builds can produce different results, especially for contact, explicit time integration, or nonlinear material routines.

Capture at minimum:

A common failure symptom is a run that terminates "normally" but at an earlier time than requested — often caused by a negative volume or an energy error. The checkpoint must therefore verify termination time equals requested end time, not merely that the job exited with code 0.

Checkpoint SE-1: the run manifest binds deck hash, solver build, and termination status. A result without a manifest is treated as an orphan and cannot be promoted to interpretation.

Stage 3 — Post-Processing

Post-processing extracts physical quantities from the result database: displacement, stress, intrusion, energy, and derived metrics. The traceability risk shifts from "what was run" to "what was extracted and how."

Two engineers can open the same d3plot and report different peak intrusions because they used different cross-sections, different time windows, or different element selections. The extraction recipe must therefore be captured as data, not as tribal knowledge. A practical approach is a scripted post-processing session where the selection set, the time range, and the filtering (for example, SAE 60 Hz or CFC 600) are written into a configuration file that is versioned alongside the result.

# post_config.yaml (example)
result: d3plot
metric: intrusion_B_pillar
section: node_set "BPILLAR_INNER"
time_window: [0.000, 0.150]
filter: SAE_CFC600
output: intrusion_peak_mm

Checkpoint PP-1: every reported number must be reproducible from the result database plus a versioned extraction configuration. If the number cannot be regenerated by re-running the script, it is not traceable.

Stage 4 — Result Interpretation

Interpretation converts numbers into engineering judgment: pass/fail against a target, root cause of a deviation, or a design recommendation. This is the stage where human reasoning enters, and it is the hardest to make traceable because the output is prose and opinion.

The workable discipline is to separate observation from inference. An observation is a measured quantity with its extraction reference ("peak intrusion 142 mm at t=0.087 s, per PP-1 config v3"). An inference is a claim built on observations ("the B-pillar exceeds the 120 mm target because the lower hinge reinforcement buckled"). Each inference should cite the observations it depends on, so that if an observation is later corrected, the affected inferences can be found and re-evaluated.

Checkpoint RI-1: every conclusion references the observation IDs and the extraction configuration that produced them. Conclusions without a traceable observation chain are marked as preliminary.

Stage 5 — Archival

Archival is not "copy the folder to the NAS." It is the creation of a durable, self-describing record that a future engineer — or an auditor — can reconstruct without asking the original analyst. The archive must contain the deck, the include tree, the run manifest, the result database (or a documented reduction of it), the extraction configuration, and the interpretation record.

Practical constraints: result databases are large (tens to hundreds of GB), so many organizations archive a reduced set of time steps plus the full manifest. That is acceptable only if the reduction is itself documented and the reduction script is archived. Silent reduction destroys traceability.

Checkpoint AR-1: the archive is self-contained and self-describing. A test of archival quality is simple: can a different engineer, given only the archive, reproduce the reported number? If not, the archive is incomplete.

How the Checkpoints Fit Together

The five stages and their checkpoints form a dependency chain. Data flows forward; traceability flows backward. The diagram below shows the stages, the artifacts each produces, and the checkpoint that gates promotion to the next stage.

Applying the Lifecycle in Practice

Consider a side-impact simulation. The analyst builds the deck from CAD revision B.7, hashes it, and runs LS-DYNA R13.1.1 on 32 ranks. The run terminates normally at the requested 0.150 s. Post-processing extracts B-pillar intrusion using a versioned configuration, yielding 142 mm. Interpretation compares this to the 120 mm target and concludes a failure, citing the observation. Archival bundles the deck, manifest, reduced d3plot, config, and interpretation record.

Six months later, the CAD is revised to B.8 and the mesh changes. Because the original archive is self-contained, the engineer can re-run the old deck and confirm the 142 mm figure is unchanged — proving the new result difference is due to geometry, not to a solver or extraction change. Without the checkpoints, that comparison would be guesswork.

The lifecycle is therefore best understood not as a sequence of tools but as a sequence of commitments: each stage commits to a specific, hashable state, and each checkpoint is the gate that makes the commitment enforceable. When the commitments hold, the final engineering conclusion is defensible; when any one is skipped, the conclusion becomes an opinion that happens to be printed in a report.