4. Simulation data management

A multi-solver assembly is not a single file. It is a graph of models, meshes, solver decks, material libraries, boundary-condition sets, and coupling definitions that only becomes meaningful when every node in that graph is pinned to an exact revision. Simulation data management (SDM) is the discipline that keeps this graph consistent, reproducible, and auditable across solvers such as Abaqus, ANSYS Mechanical, LS-DYNA, and STAR-CCM+. Without it, a "result" is an artifact whose provenance cannot be reconstructed, and any comparison between two runs is scientifically meaningless.

What Versioning Must Capture

Versioning in simulation is not the same as versioning source code. A solver deck can change in ways that are semantically identical (reordered keywords, reformatted floats) or semantically critical (a changed contact stiffness, a shifted node coordinate). Effective SDM distinguishes three layers:

• Content revision — the immutable hash of the actual file bytes or a normalized canonical form. This is the ground truth for "did anything change."
• Semantic revision — a solver-aware diff that reports which keywords, cards, or named selections changed. This is what engineers actually review.
• Assembly revision — a manifest that binds specific content revisions of all constituent parts into one addressable unit, e.g. asm-brake-thermal@r17.

The assembly revision is the unit that gets baselined, reviewed, and referenced in reports. Individual part revisions may advance independently; the assembly manifest records exactly which combination was used for a given result.

Traceability as a Directed Graph

Traceability means that from any result you can walk backward to the exact inputs, and from any input you can walk forward to every result it influenced. In practice this is a directed acyclic graph with typed edges: derived-from (mesh generated from CAD), consumes (solver run consumes mesh + material + BC), coupled-with (co-simulation participants), and supersedes (revision lineage).

The critical engineering requirement is that traceability links are created automatically at run time, not reconstructed by hand afterward. A solver wrapper should emit a run manifest containing the assembly revision, solver version, license feature, host, wall-clock start/end, and the content hashes of every input. If a link is missing, the run is marked unverified and excluded from regression baselines.

Metadata Schemas: The Contract Between Tools

A metadata schema defines which fields must accompany every artifact so that downstream tools can index, compare, and validate it. For multi-solver assemblies, a practical schema separates identity, provenance, physical context, and quality fields. The following example uses a JSON representation that can be embedded in a sidecar file or stored in a database:

{
  "artifact_id": "mesh-v4.inp",
  "content_hash": "sha256:b7c2...",
  "schema_version": "sdm/1.3",
  "identity": {
    "type": "mesh",
    "solver_format": "abaqus_inp",
    "units": "mm-N-s"
  },
  "provenance": {
    "derived_from": ["cad-brake.stp@h3a1"],
    "tool": "HyperMesh 2023.1",
    "operator": "jdoe",
    "timestamp": "2025-03-11T09:14:22Z"
  },
  "physical_context": {
    "part_number": "BRK-4410",
    "material_ref": "mat-steel.mat@e9f0",
    "coordinate_system": "global_cartesian"
  },
  "quality": {
    "element_count": 184320,
    "min_jacobian": 0.42,
    "max_aspect_ratio": 8.7,
    "warnings": ["12 elements below jacobian 0.5"]
  }
}

Two schema rules matter most in practice. First, content_hash must be computed over a canonicalized form so that trivial formatting differences do not create false revisions. Second, schema_version must be present so that a validator can reject or migrate records written by an older tool. A schema without versioning becomes unmaintainable within two release cycles.

Practical Workflow: Baselining a Coupled Run

Consider a brake-disc thermal analysis where an Abaqus thermal model is coupled to a STAR-CCM+ CFD model through a co-simulation interface. The steps below show how versioning, traceability, and metadata interact:

1. Freeze inputs. Tag CAD, mesh, material, BC, and coupling files with content hashes. Record them in the assembly manifest asm-brake-thermal@r17.
2. Validate metadata. Run a schema check against sdm/1.3. Reject any artifact missing units or coordinate_system, because unit mismatches are the most common cause of silent coupling errors.
3. Execute with a wrapper. The wrapper writes a run manifest containing solver versions, license features, and the assembly revision. It also records the coupling time-step and exchange variables.
4. Link results. Each output file (e.g. res-a.odb, res-b.sim) is registered with a consumes edge to its run and a derived-from edge to the assembly manifest.
5. Baseline. If all edges resolve and quality checks pass, promote the assembly revision to a baseline. Future regression runs compare against this baseline using the same schema.

Common Failure Modes and How to Detect Them

Designing the Schema for Your Team

Start from the smallest schema that answers three questions: What is this? (identity), Where did it come from? (provenance), and Is it fit for use? (quality). Add physical-context fields only when they are actually consumed by a downstream tool or a review gate. Every field you add must have an owner and a validation rule; fields without validation become stale and misleading.

For multi-solver assemblies, the assembly manifest is the single most important artifact. It is the contract that binds independent solver decks into one reproducible unit. Treat it as a first-class deliverable: version it, review it, and never let a result reference an assembly revision that no longer exists in the repository.