3. Full factorial designs

A full factorial design is the reference standard against which every other design of experiments (DOE) in a CAE parameter study should be judged. It is the only design that, by construction, contains every possible combination of the levels you have chosen for each factor. That completeness is what makes it so valuable for calibration, sensitivity screening, and validation of surrogate models — and it is also what makes it expensive. Understanding the structure precisely, computing the run count before you commit solver time, and executing the baseline correctly are the three skills this chapter develops.

Structure: factors, levels, and the treatment grid

A full factorial design is defined by two quantities: the number of factors k and the number of levels L assigned to each factor. When every factor has the same number of levels, the design is written L^k. A three-factor, two-level design is a 2³ design; a two-factor, three-level design is a 3² design. Mixed-level full factorials (for example, 2 × 3 × 4) are also legitimate and are common in CAE when one parameter is naturally binary — a solver flag, a contact formulation switch — while another is a continuous mesh density with three or four practical settings.

The design is best understood as a grid. Each factor is an axis; each level is a coordinate on that axis; each run is one cell of the grid. In a 2³ design the eight runs are the eight corners of a cube in factor space. This geometric view matters in CAE because the corners are exactly where nonlinearity, contact status changes, and solver divergence are most likely. A full factorial does not merely sample the interior — it deliberately probes the extremes, which is why it is the honest way to map a response surface before you trust a reduced design.

Two structural conventions must be fixed before any run is launched. First, coding: continuous factors are usually coded to −1 and +1 (two levels) or −1, 0, +1 (three levels), with the physical value recovered by x_phys = center + (range/2) · x_coded. Second, run order: the design table lists runs in standard (Yates) order, but execution order should be randomized or at least blocked, so that a drift in solver version, license queue, or machine load does not alias onto a factor. Record both orders in the run log.

Run count and the cost of completeness

The run count is simply the product of the level counts:

N = L1 × L2 × ... × Lk        (full factorial, mixed levels)
N = L^k                        (full factorial, equal levels)

Examples:
  2 factors, 2 levels  ->  2^2 =  4 runs
  3 factors, 2 levels  ->  2^3 =  8 runs
  4 factors, 3 levels  ->  3^4 = 81 runs
  5 factors, 3 levels  ->  3^5 = 243 runs
  6 factors, 4 levels  ->  4^6 = 4096 runs

The growth is multiplicative, and that is the whole story of full factorial economics. Doubling the levels of one factor in a 3-factor study takes you from 8 to 27 runs; adding a fourth three-level factor takes you to 81. In a CAE context each run may be a 20-minute nonlinear implicit solve, so 81 runs is roughly 27 hours of wall-clock time before any re-runs for non-convergence. The practical rule is to use a full factorial when N is small enough that the information gain justifies the cost — typically N ≤ 30–50 for routine parameter studies — and to reserve larger full factorials for calibration campaigns where every interaction must be estimated without confounding.

What you buy for that cost is estimability. A full factorial with L levels and k factors estimates all main effects and all interaction effects up to order k independently. In a 2³ design you get three main effects, three two-factor interactions, and one three-factor interaction, all orthogonal. No reduced design can make that claim without assumptions. This is why the full factorial is the correct baseline: it tells you which interactions actually matter, and that knowledge then justifies a cheaper design for the next campaign.

Baseline execution in a CAE solver

Executing a full factorial in a CAE solver is a loop over the design table, and the quality of the result depends almost entirely on how disciplined that loop is. The workflow below is solver-agnostic; the concrete example uses a structural implicit study with three factors.

Step 1 — Define the factor table. Choose factors that are physically meaningful and independently settable. In the example: mesh size h (levels 4 mm, 6 mm, 8 mm), friction coefficient μ (0.10, 0.20, 0.30), and bolt preload F (18 kN, 24 kN, 30 kN). That is a 3³ design with N = 27 runs.

Step 2 — Build the design matrix. Generate the 27 rows in coded form, then map to physical values. Keep the coded and physical columns side by side in the run log; the coded columns are what the statistical analysis consumes, the physical columns are what the solver consumes.

run  h_coded  mu_coded  F_coded   h_mm   mu    F_kN
 1     -1       -1        -1       4.0   0.10   18
 2      0       -1        -1       6.0   0.10   18
 3     +1       -1        -1       8.0   0.10   18
 4     -1        0        -1       4.0   0.20   18
 ...
27     +1       +1        +1       8.0   0.30   30

Step 3 — Parameterize the model, do not edit it. The single most common source of error in CAE DOE is manual model editing between runs. Instead, drive every factor from a parameter set or input deck variable so that the only thing changing between runs is the design row. In a typical solver this means a parameter block read at startup, with mesh size, friction, and preload all exposed as named parameters. Verify once, by running the center point twice with identical parameters, that the model is deterministic.

Step 4 — Execute with a controlled loop. Run the 27 cases in randomized order, capturing for each run: the design row, solver version, wall-clock time, convergence status, and the response quantities of interest (for example, peak contact pressure, maximum bolt stress, and interface slip). A minimal driver script pattern is:

for row in randomized_design_table:
    write_parameters(row)          # h, mu, F
    status = run_solver(case_dir)  # returns converged / diverged
    extract_responses(case_dir)    # peak pressure, bolt stress, slip
    log(row, status, responses)

Step 5 — Handle non-convergence explicitly. In a 27-run study, expect one or two divergences, usually at the extreme corner (coarse mesh, high friction, high preload). Do not silently drop them: a missing corner biases every effect estimate. First try a solver-side remedy — smaller initial increment, line search, or a restart from the previous converged increment — and record the remedy in the log. If a run still fails, mark it as censored and note it in the analysis; a full factorial with one missing cell is no longer orthogonal, and the analysis must say so.

Step 6 — Verify the baseline before analysis. Check three things: (a) all 27 rows present with a status; (b) the center-point run repeated at the start and end of the campaign agrees within a stated tolerance (for example, 1% on peak pressure) — this detects drift; (c) response ranges are physically plausible, not orders of magnitude off, which usually indicates a parameter mapping error rather than a real effect.

Reading the structure at a glance

The diagram below summarizes the relationship between factor levels, the resulting run grid, and the execution loop that turns the design table into a verified response set. It is the mental model to carry into the analysis chapter: the grid is fixed before execution, the loop must not alter it, and the verification step closes the loop before any effect is estimated.

What the baseline gives you

Once the 27 runs are complete and verified, the design matrix is orthogonal and the response columns can be analyzed directly: main effects are differences of level means, two-factor interactions are differences of differences, and the three-factor interaction is the residual contrast. The full factorial's contribution is that none of these estimates is confounded with another. That property is what makes the baseline trustworthy, and it is the reason a full factorial — even a modest 2³ or 3² — should precede any reduced design in a serious CAE parameter study. The next step is to compute those effects and decide which factors and interactions earn a place in the reduced campaign.