2. CAE simulation fundamentals for dataset engineers

Dataset engineers working on AI for engineering do not need to become CFD or FEA analysts, but they must understand what a simulation actually computes, because that determines what the resulting data means. A CAE solver is a numerical approximation of a physical field problem. Every sample you collect is a discrete solution of a partial differential equation (PDE) system, constrained by boundary conditions, discretized on a mesh, and produced by a solver whose numerical behavior shapes the dataset statistics. This section builds the minimum mental model needed to design, validate, and document simulation datasets.

Governing Equations: What the Solver Is Actually Solving

Most CAE problems reduce to conservation laws written in differential form. For incompressible fluid flow, the Navier–Stokes system is:

∇ · u = 0                                  (mass conservation)
ρ (∂u/∂t + (u · ∇)u) = -∇p + μ ∇²u + f     (momentum conservation)

For structural analysis, the static equilibrium form is ∇ · σ + f = 0, where σ is the Cauchy stress tensor. For heat transfer, the steady conduction equation is ∇ · (k ∇T) + q = 0. These are the fields your dataset will sample: velocity u, pressure p, stress σ, temperature T.

Two properties matter for dataset design. First, the equations are coupled: in conjugate heat transfer, the temperature field drives buoyancy in the momentum equation, and the velocity field advects energy. If your dataset samples only one field, you lose the coupling that a surrogate model may need to learn. Second, the equations are nonlinear when the convective term (u · ∇)u dominates, which is why high-Reynolds-number cases require turbulence modeling and produce chaotic, hard-to-learn fields.

Boundary and Initial Conditions: The Actual Inputs

Boundary conditions (BCs) are the parameters that vary across a dataset. A well-designed dataset treats BCs as the input vector and the resulting fields as the target. Common types:

Initial conditions matter only for transient simulations. For a transient case, the initial field is itself an input, and the dataset must record it. A common mistake is to sample only the final time step; a surrogate trained on that data cannot predict the transient evolution.

Solver Types and Their Numerical Signatures

The solver choice leaves fingerprints in the data. Three families dominate:

• Finite Volume (FV) — used in most CFD codes (OpenFOAM, Fluent, SU2). Conserves mass and momentum exactly at the cell level. Output fields are cell-centered or node-interpolated. Expect slight numerical diffusion in coarse regions.
• Finite Element (FE) — standard for structural and multiphysics (Abaqus, ANSYS Mechanical, CalculiX). Solves the weak form; stresses are computed at integration points and extrapolated to nodes, which introduces extrapolation error near boundaries.
• Lattice Boltzmann (LBM) — mesoscopic, explicit, good for complex geometries and multiphase. Output is distribution functions relaxed to macroscopic fields; transient data is dense and regular.

For dataset engineering, the practical consequence is that the same physical case solved by FV and FE will not produce identical fields. Mixing solvers in one dataset without recording the solver type introduces label noise that a surrogate model will silently absorb.

Output Fields Relevant to AI

Not every solver output is useful. Prioritize fields that are (a) physically meaningful, (b) spatially resolved, and (c) stable across parameter sweeps. Typical targets:

• Velocity vector field u(x,y,z,t) — primary CFD target.
• Pressure field p — often the hardest to learn due to gauge freedom; fix the reference.
• Temperature T — scalar, well-behaved, good for regression baselines.
• Von Mises stress σ_vm — scalar derived from the stress tensor; standard structural target.
• Turbulent kinetic energy k and dissipation ε — only meaningful if the turbulence model is recorded.

Derived quantities such as drag coefficient C_d, lift C_l, or maximum stress are scalar labels useful for classification or global regression. They are cheap to store and often the actual engineering objective.

From Physics to Dataset: A Worked Parameter Sweep

Consider a 2D channel with a heated block, solved with a steady incompressible FV solver. The dataset input vector is [u_in, T_block, k_fluid]; the target is the full temperature field on a fixed 200×80 mesh. A reproducible sweep:

u_in    ∈ {2, 4, 6, 8, 10} m/s
T_block ∈ {320, 350, 380, 410} K
k_fluid ∈ {0.1, 0.3, 0.6} W/(m·K)
→ 5 × 4 × 3 = 60 samples

For each sample, run the solver to convergence (residual < 1e-6), export the temperature field as a 200×80 float array, and store the input vector alongside. Verification: check that the outlet bulk temperature increases monotonically with T_block and decreases with u_in. If a sample violates this, the run likely diverged or hit the iteration cap — discard it rather than including a non-converged field.

Visualizing the Simulation-to-Dataset Pipeline

The diagram below shows how physical inputs, solver configuration, and output fields connect, and where dataset engineering intervenes.

Practical Takeaways for Dataset Engineers

Three habits separate usable simulation datasets from unusable ones. First, treat boundary conditions as first-class data: they are the input vector, and they must carry units, reference frames, and the solver's interpretation (e.g., whether a wall is no-slip or free-slip). Second, record solver provenance — solver family, turbulence model, convergence tolerance, mesh hash — because these determine whether two samples are comparable. Third, verify physical trends before training: if the outlet temperature does not respond monotonically to the inlet temperature, the sample is likely non-converged or misconfigured, and including it will degrade surrogate accuracy. The governing equations tell you what is physically possible; the solver configuration tells you what was actually computed; the dataset engineering layer is where you make both explicit and machine-readable.