4. Data generation and preprocessing

A surrogate model is only as trustworthy as the dataset it learns from. In a CAE-driven workflow, that dataset is produced by a chain of decisions: which design points to sample, how to mesh each geometry, which solver settings to hold constant, and how to extract and normalize the results. Errors introduced here are rarely visible during training — a surrogate will happily fit corrupted labels and report a low validation loss. This chapter focuses on the practical mechanics of turning a parametric CAD model and a solver into a clean, consistent, and reproducible dataset suitable for regression or classification.

From Design Space to Simulation Campaign

Start by defining the design space explicitly as a set of parameters with bounds and units. For a structural bracket example, parameters might be thickness (2–6 mm), fillet_radius (3–15 mm), and hole_offset (10–40 mm). Sampling strategy matters: Latin Hypercube Sampling (LHS) gives better space-filling coverage than uniform random sampling for the same budget, and Sobol sequences provide low-discrepancy coverage that is reproducible across runs. A typical campaign for three parameters uses 80–150 LHS points plus a handful of corner and center points to anchor the response surface.

Each design point must map to a deterministic simulation job. Store the parameter vector, a hash of the geometry, the solver version, and the mesh settings alongside every result. Without this provenance, you cannot distinguish a genuine outlier from a failed run, and you cannot reproduce a result six months later.

Running CAE Simulations Reliably

Batch execution should be scripted, not manual. A minimal driver loop typically does four things per design point: regenerate geometry from parameters, mesh it, solve it, and export a result file. The following pseudo-code illustrates the control flow and the failure handling that matters most:

for case in design_points:
    geom = build_geometry(case.params)          # parametric CAD
    mesh = generate_mesh(geom, mesh_settings)   # fixed target size
    status = run_solver(mesh, solver_config)
    if status != CONVERGED:
        log_failure(case, status); continue
    export_results(case.id, fields=["stress_max", "mass", "disp_max"])

Two failure modes dominate real campaigns. First, geometry regeneration fails when a parameter combination produces self-intersecting or degenerate features — for example, a fillet radius larger than the adjacent edge. Second, the solver fails to converge when mesh quality degrades near thin features. Both should be logged with the parameter vector, not silently dropped, because a cluster of failures often reveals a region of the design space that the surrogate will extrapolate into poorly.

Handling Mesh Variability

Mesh variability is the most insidious source of label noise in surrogate datasets. When geometry changes, an automatic mesher produces a different node count and element distribution for each design point. If the mesh is too coarse in one case and fine in another, the extracted maximum stress reflects meshing differences rather than design changes. The surrogate then learns a spurious relationship between geometry and mesh density.

The standard remedy is to control mesh density rather than element count. Specify a target element size or a global sizing function tied to a geometric feature (e.g., element_size = 0.8 mm on the fillet, 2.0 mm elsewhere), and verify that key quality metrics — aspect ratio, Jacobian, skewness — stay within bounds for every case. A mesh convergence check on three representative designs (coarse, medium, fine) establishes the element size beyond which the quantity of interest changes by less than a tolerance, say 2%. Use that size for the entire campaign.

For results that must be compared across meshes — field data, contour plots, or nodal values — map them onto a common reference grid or a fixed set of probe points. Scalar outputs such as maximum von Mises stress, total mass, or maximum displacement are naturally mesh-independent once convergence is established, which is why most surrogate workflows prefer scalar quantities of interest over full fields.

Cleaning Simulation Output

Raw solver output is not a dataset. Cleaning proceeds in a fixed order so that each step operates on trustworthy input. First, remove failed or non-converged runs — but retain them in a separate failure log with their parameter vectors. Second, check unit and sign conventions: a displacement reported in millimeters in one solver version and meters in another will destroy a regression model, and a stress sign convention that flips between tension-positive and compression-positive will corrupt any derived quantity. Third, detect outliers. For a scalar quantity of interest, compute the interquartile range and flag points beyond 1.5×IQR, or use a robust z-score based on median absolute deviation. Investigate each flagged point against its mesh quality and convergence history before discarding it — a genuine extreme design is valuable data, while a meshing artifact is noise.

Normalization should be applied after cleaning, not before, so that outlier statistics are computed on physical values. For surrogate training, min-max scaling to [0, 1] or standardization to zero mean and unit variance are both common; standardization is preferable when the quantity of interest spans orders of magnitude, as with stress concentrations. Store the scaling parameters (min/max or mean/std) with the dataset so that predictions can be inverse-transformed consistently at inference time.

A Practical Cleaning Checklist

The output of this stage is a tidy table: one row per successful design point, columns for each normalized parameter, each scalar quantity of interest, and a provenance block. That table — not the raw solver directory — is the artifact the surrogate model consumes, and it should be version-controlled alongside the sampling script and solver configuration so that the entire campaign can be reproduced from a single commit.