4. Simulation dataset design

A simulation dataset is only as useful as the design space it covers. Before any solver runs, the engineer must decide which configurations to simulate, how many, and where in the parameter space they should sit. This chapter treats that decision as a formal engineering activity: defining the design space, choosing a sampling strategy (Latin hypercube, Sobol, or factorial), and assembling the resulting points into a case matrix that drives batch execution.

4.1 From Physical Problem to Design Space

A design space is the Cartesian product of the independent variables you allow to vary, each bounded by a lower and upper limit and possibly constrained by feasibility rules. For a vehicle aerodynamics study, a design space might be:

• Velocity v ∈ [15, 40] m/s
• Yaw angle β ∈ [−5°, +5°]
• Ride height h ∈ [80, 160] mm
• Rear wing angle α ∈ [0°, 15°]

Each variable carries a type (continuous, discrete, or categorical), a unit, and a reference convention. State the sign convention explicitly — for example, "positive yaw means the vehicle nose points left of the freestream" — and keep it consistent across the case matrix, the solver setup, and any post-processing scripts. Ambiguity here is one of the most common sources of corrupted datasets.

Constraints reduce the nominal box to a feasible region. A ride height of 80 mm combined with a 15° wing angle may violate a ground-clearance rule; such combinations must be excluded or repaired before sampling. Record constraints as explicit predicates so they can be enforced programmatically.

4.2 Sampling Strategies

Three families dominate CAE dataset generation. The right choice depends on dimensionality, the smoothness of the response, and whether you need variance decomposition.

Full factorial sampling places a point at every combination of discrete levels. With 4 variables at 5 levels each, that is 5⁴ = 625 cases — tractable for a fast CFD run but prohibitive for a 12-hour transient thermal solve. Factorial designs are ideal when you need clean main-effect and interaction estimates and the level count is small.

Latin hypercube sampling divides each axis into N equal-probability bins and places exactly one sample per bin per axis, then randomly pairs the coordinates. This guarantees stratification along every 1-D projection. A common improvement is maximin or correlation-optimized LHS, which iteratively swaps points to maximize the minimum pairwise distance and minimize spurious correlations. In Python, scipy.stats.qmc.LatinHypercube provides this directly:

from scipy.stats.qmc import LatinHypercube
import numpy as np

sampler = LatinHypercube(d=4, seed=42)
unit = sampler.random(n=64)          # 64 points in [0,1)^4

# Scale to physical bounds
lower = np.array([15.0, -5.0, 80.0, 0.0])
upper = np.array([40.0,  5.0, 160.0, 15.0])
cases = lower + unit * (upper - lower)

Sobol sequences are deterministic low-discrepancy sequences that fill space more uniformly than random LHS, especially as dimension grows. They are the preferred choice when the dataset will feed a variance-based sensitivity analysis (Sobol indices) or a Gaussian-process surrogate. Use scipy.stats.qmc.Sobol with scramble=True for randomized quasi-Monte Carlo behavior:

from scipy.stats.qmc import Sobol

sobol = Sobol(d=4, scramble=True, seed=7)
unit = sobol.random(n=128)           # 128 points, power of two

4.3 Constructing the Case Matrix

The case matrix is the tabular artifact that binds each sample to a runnable simulation. A well-formed matrix has one row per case and columns for: a stable case_id, the sampled parameter values in physical units, derived quantities (e.g., Reynolds number), the mesh or geometry variant, solver settings, and a status field. Below is a minimal example for the aerodynamics study, showing the first four of 64 LHS cases:

Derived columns such as Reynolds number are computed once and stored, so downstream scripts never recompute them inconsistently. The status field tracks the lifecycle: pending → running → converged / diverged / failed. This makes the matrix both a design record and a progress ledger.

4.4 Feasibility Filtering and Repair

After sampling, apply constraint predicates. A case that violates ground clearance can be repaired by projecting it onto the feasible boundary, or simply dropped. Dropping is cleaner statistically but reduces sample count; projection preserves count but biases the distribution. Document which policy you chose. For the example above, a constraint h ≥ 90 mm when α ≥ 10° would flag aero_0002 (h = 94, α = 12.3) as feasible but aero_0003 (h = 148, α = 2.1) as trivially feasible — only cases near the boundary need scrutiny.

4.5 Visualizing the Design

Before launching hundreds of solver jobs, plot the sample distribution. The figure below shows a two-dimensional projection of a 64-point LHS design over velocity and yaw angle, with the feasible region shaded and infeasible samples marked. This kind of projection plot is the fastest way to catch clustering, gaps, or constraint violations.

In this projection, the blue points are stratified across both axes — no two share a velocity bin or a yaw bin, which is the defining property of LHS. The single red circle marks a sample that violated the ground-clearance constraint and was excluded from the run queue. If the plot showed heavy clustering in one corner, you would re-sample with a different seed or switch to Sobol before spending compute.

4.6 Practical Checklist

• Define every variable with bounds, units, type, and sign convention.
• Encode constraints as executable predicates, not prose.
• Choose the sampler based on dimension and downstream use: factorial for ≤3 discrete variables, LHS for surrogate training, Sobol for sensitivity analysis.
• Generate the case matrix with stable IDs, physical-unit values, derived columns, and a status field.
• Filter or repair infeasible cases and document the policy.
• Plot 2-D projections and inspect coverage before launching solvers.
• Preserve the original sampled values; never mutate them silently on failure.

A disciplined design-space and sampling workflow turns a pile of solver runs into a dataset with known statistical properties — one that supports surrogate modeling, sensitivity analysis, and credible uncertainty quantification downstream.