1. Course overview

This course addresses a practical bottleneck in modern simulation-driven product development: the gap between completing a finite element analysis (FEA) or computational fluid dynamics (CFD) solve and producing a report that a design team, a chief engineer, or a certification body can actually act on. AI-based CAE report generation sits at the intersection of three disciplines — numerical simulation, technical writing, and applied machine learning. The goal is not to replace the analyst's judgment, but to automate the mechanical, repetitive, and error-prone parts of report assembly so that engineering attention is spent on interpretation and decision-making.

What This Course Covers

The scope spans the full reporting lifecycle, from raw solver output to a signed-off document. Specifically, the course treats the following as first-class topics:

• Solver result ingestion. Reading native result files (for example, .odb from Abaqus, .rst from ANSYS, .op2 from Nastran, or VTK/HDF5 exports) and extracting the quantities that matter: displacement, von Mises stress, principal strains, reaction forces, modal frequencies, and convergence residuals.
• Result interpretation logic. Encoding the rules an experienced analyst applies — comparing peak stress against yield with a safety factor, checking mesh convergence, flagging singularities at constrained nodes, and distinguishing real hot spots from numerical artifacts.
• Automated narrative and figure generation. Producing contour plots, XY plots, deformed-shape overlays, and the accompanying prose that explains what each figure shows and why it matters.
• Traceability and review. Linking every claim in the report back to a specific result set, load case, and model revision, so a reviewer can audit the chain of evidence.
• Human sign-off. The approval gate where a qualified engineer accepts, rejects, or annotates the generated content before it becomes a controlled deliverable.

Out of scope are the upstream modeling decisions themselves — meshing strategy, material card selection, contact definition — except where they must be recorded in the report for traceability. This course assumes you already know how to set up and run a simulation; it teaches you how to turn its output into a defensible document.

Key Concepts and Terminology

Several terms recur throughout the course and are worth fixing now.

The distinction between an extraction template and a narrative block is central. The template is deterministic and data-driven; the narrative block is where language models contribute, but always constrained by the extracted numbers so that no figure or value is invented.

The CAE Reporting Workflow: From Simulation to Sign-Off

The workflow this course teaches has six stages. They are not a rigid waterfall — iteration between interpretation and extraction is normal — but each stage has a clear input, a clear output, and a clear failure mode.

1. Solve completion and result inventory. The solver writes its output files. The first automated step enumerates available result sets and confirms that every load case in the analysis plan is present. A missing load case here is the most common silent failure.
2. Quantity extraction. Using the extraction template, the pipeline pulls scalars (peak stress, max displacement, first natural frequency) and field data (nodal stress arrays, displacement fields) into a structured intermediate form, typically JSON or a Parquet table.
3. Automated checks. Each extracted quantity is compared against its acceptance criterion. The output is a set of pass/fail flags plus the margin, for example SF = 1.62 (PASS, margin +0.12).
4. Figure generation. Contour plots, XY curves, and deformed-shape images are rendered with consistent color scales and annotated with the location of the reported extreme value.
5. Narrative assembly. The language model drafts prose for each narrative block, conditioned on the extracted numbers, the pass/fail flags, and the figure captions. Every numeric token in the draft is validated against the extracted table before it is accepted.
6. Review and sign-off. A qualified engineer reviews the assembled report, resolves any flagged anomalies, and approves it. The provenance record travels with the document.

The following diagram shows the data flow through these six stages, including the two feedback paths that matter most in practice: the re-extraction loop when a check reveals a missing quantity, and the re-render loop when a figure's color scale obscures the hot spot.

A Concrete Example of the Extraction-to-Check Step

To make the workflow tangible, consider a bracket subjected to a 12 kN static load. The solver has completed and written bracket_v3.odb with two load cases: LC01_12kN and LC02_18kN. The extraction template specifies that for each load case the pipeline must pull the maximum von Mises stress, the node ID where it occurs, the maximum displacement magnitude, and the reaction force at the fixed end.

A representative extraction output (illustrative values, not measured results) might look like this:

{
  "model": "bracket_v3",
  "solver": "Abaqus 2023",
  "load_cases": [
    {
      "id": "LC01_12kN",
      "max_von_mises_MPa": 214.6,
      "critical_node": 18422,
      "max_disp_mm": 0.87,
      "reaction_N": 12004
    },
    {
      "id": "LC02_18kN",
      "max_von_mises_MPa": 321.9,
      "critical_node": 18422,
      "max_disp_mm": 1.31,
      "reaction_N": 18006
    }
  ]
}

With a yield strength of 350 MPa and a required safety factor of 1.5, the acceptance criterion is max_von_mises ≤ 350 / 1.5 = 233.3 MPa. LC01 passes with a margin of 18.7 MPa; LC02 fails with an overstress of 88.6 MPa. The automated check stage emits these flags, and the narrative stage is then constrained to state the failure explicitly rather than softening it. This is the core value of the pipeline: the language model cannot accidentally report a passing bracket when the numbers say otherwise.

What You Will Be Able to Do

By the end of this course you should be able to design an extraction template for a given solver and analysis type, define acceptance criteria that match your project's structural requirements, build a narrative-generation step that is numerically grounded, and set up a review gate that a certification reviewer would accept. The remaining chapters build each of these capabilities in turn, starting with the data structures that make the pipeline possible.