2. CAE data landscape

Before any AI system can draft a credible CAE report, it must first understand what a solver actually produces. The CAE data landscape is heterogeneous by design: each major solver grew up with its own file conventions, its own vocabulary for element types, and its own way of separating model definition from computed results. A report-generation pipeline that treats all solver output as "just text" will fail on the first mixed-format project. This section maps the four dominant ecosystems — Nastran, Abaqus, ANSYS, and OpenFOAM — and shows how to extract the metadata that downstream automation depends on.

Two Families of Output: Input Decks and Result Databases

It helps to separate model definition from computed results. Model definition describes geometry, mesh, materials, boundary conditions, and load cases. Results describe what the solver computed: displacements, stresses, temperatures, pressures, residuals, and convergence history. Some formats bundle both; others split them across files.

Nastran is the classic example of a text-based input deck. A bulk data file (*.bdf, *.dat, or *.nas) contains GRID, CTETRA, PSHELL, MAT1, and FORCE entries, while the executive and case control sections define the solution sequence (SOL 101 for statics, SOL 103 for normal modes). Results land in a separate *.f06 (or *.op2 for binary) file. The .f06 is human-readable but notoriously column-sensitive; the .op2 is compact and machine-friendly but requires a parser such as pyNastran.

Abaqus uses an input file (*.inp) with keyword blocks like *NODE, *ELEMENT, *MATERIAL, and *STEP. Results are written to an *.odb (output database), a binary container that holds field output (stress, strain, displacement) and history output (force–displacement curves, energy). The *.dat and *.msg files carry solver messages and convergence diagnostics.

ANSYS is more fragmented. Classical ANSYS uses *.inp or *.dat for the model and *.rst (result file) for results, with *.out for the log. Workbench projects wrap everything in a *.wbpj container with a files/ directory holding the actual solver artifacts. Mechanical APDL scripts (*.mac, *.inp) are common in automated workflows.

OpenFOAM is the outlier: it is directory-based and case-oriented. A case directory contains 0/ (initial and boundary conditions), constant/ (mesh in polyMesh/, turbulence properties), and system/ (controlDict, fvSchemes, fvSolution). Results are written as time directories (0.5/, 1.0/, …) containing fields like U, p, and k. There is no single "result file" — the result is the directory tree itself.

What Metadata Actually Matters

Not every field in a solver output is worth extracting. For report generation, the high-value metadata falls into five categories:

• Analysis identity: solver name and version, analysis type (static, modal, transient, CFD), solution sequence or step name, and the date/time of the run.
• Model summary: node count, element count, element types used, material names and IDs, and unit system (critical — Nastran and Abaqus are unit-agnostic).
• Load case definition: subcase ID, load set name, boundary condition description, and applied magnitudes.
• Result quantities: which field outputs were requested (displacement, stress, strain, temperature, pressure), at which time points or modes, and in which coordinate system.
• Convergence and warnings: residual norms, iteration counts, and any solver warnings or errors that affect confidence in the result.

In practice, a metadata extractor is a small parser per format. For Nastran .f06, you scan for the SUBCASE header, then the DISP or STRESS block, and read fixed-width columns. For Abaqus .odb, you use the odbAccess Python module to iterate steps and frames. For ANSYS .rst, PyMAPDL or the DPF (Data Processing Framework) API gives you result sets by load step and substep. For OpenFOAM, you read controlDict for time controls and parse the time directories for field files.

from pyNastran.op2.op2 import OP2
op2 = OP2()
op2.read_op2("wing_modal.op2")
for subcase, modes in op2.eigenvectors.items():
    for mode_id, mode in modes.modes.items():
        print(f"Subcase {subcase} | Mode {mode_id} | "
              f"Freq = {mode.freq:.2f} Hz | "
              f"Max disp = {mode.data[0].max():.4e}")

Normalizing Across Solvers

The real engineering challenge is not parsing one format but reconciling four. A Nastran CTETRA and an Abaqus C3D4 are both four-node tetrahedra, but their node ordering and integration scheme differ. A pressure load in ANSYS may be applied as a surface load on a face, while in OpenFOAM it is a boundary condition patch. A report generator that does not normalize these differences will produce inconsistent comparisons.

A practical normalization layer maps each solver's vocabulary to a common internal schema. For example, a unified ElementType enum might map CTETRA, C3D4, SOLID185, and tet all to TET4. Similarly, a unified ResultField enum maps DISP, U, and UX/UY/UZ to DISPLACEMENT. This schema becomes the contract between the extraction layer and the AI report generator.

Common Pitfalls in Metadata Extraction

Three failure modes appear repeatedly in production pipelines:

1. Unit ambiguity. Nastran and Abaqus do not enforce units. A model in mm–N–MPa and one in m–N–Pa produce identical-looking numbers. The extractor must read the unit system from the input deck or a companion metadata file, or flag the result as unit-unknown.
2. Subcase/step confusion. Nastran subcases and Abaqus steps are not one-to-one. A single Abaqus step can contain multiple frames; a Nastran subcase can reference multiple load sets. The extractor must preserve the hierarchy, not flatten it.
3. Binary format version drift. .op2 and .odb formats change between solver versions. A parser that works on Nastran 2019 may fail on 2023. Pin the parser version and validate against a known-good sample.

From Raw Files to Report-Ready Metadata

The output of this stage is a structured metadata record — typically JSON — that captures the analysis identity, model summary, load cases, result quantities, and convergence status. This record is the single source of truth for everything downstream: the AI report generator, the technical review checklist, and any automated comparison against previous runs.

A minimal metadata record for a static Nastran run might look like this:

{
  "solver": "Nastran",
  "version": "2023.1",
  "analysis_type": "SOL 101 - Static",
  "model": {
    "nodes": 48210,
    "elements": 39104,
    "element_types": ["CTETRA", "CQUAD4"],
    "materials": ["AL2024", "TI6AL4V"],
    "units": "mm-N-MPa"
  },
  "subcases": [
    {
      "id": 1,
      "name": "Wing tip load",
      "result_fields": ["DISPLACEMENT", "STRESS"],
      "max_displacement": 12.47,
      "max_stress": 318.6
    }
  ],
  "convergence": {
    "status": "converged",
    "iterations": 1,
    "warnings": []
  }
}

With this record in hand, the AI report generator no longer needs to understand Nastran syntax. It receives a clean, solver-agnostic description of what was analyzed and what was found. The next section builds on this foundation by showing how to turn that metadata into structured report sections.