2. Experiment and run abstractions

In a CAE experiment tracking system, the fundamental unit of recorded work is the run. A run represents one execution of a solver or analysis job — a single CFD steady-state solve, one structural modal analysis, one thermal transient. A collection of related runs that share a common objective is an experiment. This two-level abstraction is not arbitrary: it mirrors how CAE engineers actually work. You define a study (experiment), then sweep mesh densities, turbulence models, or boundary conditions across multiple solver invocations (runs).

The tracking system must capture five categories of information for every run: parameters (inputs), metrics (scalar outputs), artifacts (files), tags (labels), and lineage (relationships). Getting these abstractions right determines whether your tracking system becomes a searchable engineering knowledge base or an expensive file dump.

Parameters: The Input Contract

Parameters are the knobs you turn before a solver starts. In CAE workflows they fall into distinct classes. Geometric parameters include chord length, fillet radius, or blade twist angle. Mesh parameters cover element size, boundary-layer growth rate, and y+ target. Physics parameters specify turbulence model, time-step size, or material properties. Solver parameters capture convergence criteria, relaxation factors, and parallel partition counts.

A critical design decision is parameter typing. Storing everything as strings destroys queryability. A well-structured parameter schema distinguishes:

• Continuous — inlet_velocity = 32.5 (m/s), queryable with range filters
• Discrete/categorical — turbulence_model = "k-omega SST", enabling group-by operations
• Boolean — compressible = true
• Structured — a JSON object for coupled multi-physics settings

Parameters should be logged before the solver launches, not reconstructed afterward. In practice, this means the run wrapper reads a configuration file (e.g., a YAML or JSON case definition), hashes it, and records both the parsed values and the raw file. The hash enables deduplication: if two runs share identical parameter hashes, they are either redundant or a reproducibility check.

Metrics: Scalar Outcomes for Comparison

Metrics are the numbers you compare across runs. In CAE they are typically extracted from solver output files after completion. Common examples include drag coefficient, maximum von Mises stress, pressure drop, mass flow imbalance, first natural frequency, and total solve wall-clock time.

The key discipline is metric extraction automation. Rather than manually copying values from a report, the run wrapper should parse solver logs or result files programmatically. For a CFD case, a Python post-processing script might read the .out file and extract:

metrics = {
    "cd": parse_force_coefficient("postProcessing/forces/0/coefficient.dat"),
    "cl": parse_force_coefficient("postProcessing/forces/0/coefficient.dat", component="lift"),
    "mass_imbalance_pct": compute_mass_imbalance("postProcessing/massFlow/0/surfaceFieldValue.dat"),
    "iterations_to_convergence": count_convergence("log.solver"),
    "wall_clock_seconds": read_timing("log.solver")
}

Metrics must be scalar and comparable. A full pressure field is not a metric — it is an artifact. The distinction matters because metrics drive dashboards, parallel-coordinate plots, and automated ranking, while artifacts require downloading and opening in a viewer.

Every metric should carry a step or iteration index when it evolves during the solve. A drag coefficient at iteration 500 is different from the final converged value. Tracking systems that store only the final number lose the convergence history that often reveals whether a solution is trustworthy.

Artifacts: Files with Provenance

Artifacts are the files a run produces or consumes: mesh files (.msh, .cas), solver input decks, result files (.dat, .odb, .rst), post-processing images, and validation reports. In CAE, artifacts are large — a single transient CFD result can exceed 50 GB.

Effective artifact management requires three properties:

1. Content addressing — store artifacts by a hash of their content (e.g., SHA-256), not by filename. This deduplicates identical meshes across runs and guarantees integrity.
2. Lazy materialization — record the artifact reference and metadata immediately, but defer actual upload or copy until needed. This keeps the run loop fast.
3. Role tagging — mark each artifact as input, output, or checkpoint. A mesh file is an input to the solver but an output of the meshing run.

Artifact metadata should include file size, creation timestamp, and the producing run ID. For CAE specifically, it is valuable to record the solver-native format version — an Abaqus .odb from 2022 may not open in 2020.

Tags: Human-Readable Organization

Tags are free-form labels that cut across the parameter/metric structure. They answer questions like "which runs used the baseline mesh?" or "which results have been reviewed by the stress team?" Common tag categories in CAE tracking include:

• Status tags — converged, diverged, running, queued
• Quality tags — mesh-independent, needs-remesh, validation-passed
• Project tags — winglet-study, thermal-baseline
• Review tags — approved, flagged, superseded

Tags should be mutable and auditable. When an engineer changes a run's tag from running to converged, the system should record who made the change and when. This audit trail is essential for regulated industries where simulation results feed into certification.

Lineage: The Dependency Graph

Lineage connects runs into a directed acyclic graph (DAG). In CAE, lineage is not optional — it is the difference between a result you can defend and a number of unknown origin. A typical lineage chain looks like:

Geometry preparation → Meshing run → Solver run → Post-processing run → Report generation

Each arrow represents a data dependency. The meshing run consumes a geometry artifact and produces a mesh artifact. The solver run consumes that mesh artifact plus a case setup artifact and produces result artifacts and metrics. If the geometry changes, the lineage graph immediately shows which downstream runs are invalidated.

Implementing lineage requires that every run records its parent run IDs and the artifact IDs it consumed. The tracking system can then reconstruct the full graph. In practice, this is often done by having the run wrapper accept a --parent-run argument or by resolving artifact references automatically when a run reads a file that was produced by a known run.

Putting It Together: A Practical Run Record

When these five abstractions are combined, a single run record in the tracking system looks like a structured document. Here is a representative example for a CFD solver run:

run_id: run-2024-03-15-0042
experiment: winglet-sweep-2024
status: converged
parameters:
  inlet_velocity: 32.5
  turbulence_model: "k-omega SST"
  mesh_cells: 4200000
  y_plus_target: 1.0
metrics:
  cd: 0.0312
  cl: 0.482
  mass_imbalance_pct: 0.03
  iterations: 847
  wall_clock_seconds: 1420
artifacts:
  - role: input
    path: mesh.msh
    sha256: 7c2e...
  - role: output
    path: result.dat
    sha256: f9b0...
tags: [converged, mesh-independent, winglet-study]
lineage:
  parent_runs: [run-2024-03-15-0038]
  consumed_artifacts: [7c2e...]
  produced_artifacts: [f9b0...]

This record is queryable, reproducible, and auditable. You can ask "show me all converged runs with cd < 0.035 and mesh_cells > 3M" and get an answer in milliseconds. You can trace any reported number back to the exact mesh and geometry that produced it. You can invalidate downstream results when an upstream input changes.

Common Pitfalls in CAE Tracking

Three mistakes recur when teams implement these abstractions. First, conflating parameters with metrics — mesh cell count is a parameter if you set it, a metric if the mesher reports it. Pick one role and be consistent. Second, ignoring artifact size — a tracking system that tries to upload every result file synchronously will bottleneck the solver queue. Use references and lazy transfer. Third, treating lineage as optional — retrofitting lineage after thousands of runs exist is painful and error-prone. Record parent-child relationships from day one.

The experiment and run abstractions are the foundation on which model registries, comparison dashboards, and automated validation pipelines are built. Getting the data model right at this layer determines what questions you can ask later.