3. CAE model setup for repeatable iterations
In a multi-iteration CAE comparison study, the credibility of the final ranking depends far less on the sophistication of any single simulation than on whether every design variant was evaluated under identical, controlled conditions. A design that appears 4% stiffer may simply have received a finer mesh in a high-gradient region, or a solver tolerance that was relaxed in one run and tightened in another. This chapter addresses the three pillars that make iteration-to-iteration comparison defensible: parametric geometry templating, a meshing strategy that is deterministic and transferable across variants, and solver configuration that is locked, versioned, and auditable.
Geometry templating: one topology, many variants
The objective of geometry templating is to ensure that every design variant shares the same topological structure — the same number of bodies, the same named faces, edges, and vertices, and the same feature tree order — so that boundary conditions, loads, and mesh controls can be applied by name rather than by picking coordinates. When topology changes between variants, every downstream mapping (named selections, contact definitions, mesh sizing on a specific face) must be re-verified, and silent misassignment becomes the dominant source of comparison error.
A practical template is built as a parametric CAD part or a scripted geometry (for example, a Python or journal-file driven model) in which all driving dimensions are exposed as named parameters. Consider a bracket family with parameters t_rib (rib thickness), r_fillet (fillet radius), and h_boss (boss height). The template exposes these three parameters and nothing else; the topology is fixed. Variants are then generated by writing parameter sets into a table and rebuilding:
variant_id, t_rib_mm, r_fillet_mm, h_boss_mm
V01, 3.0, 2.0, 12.0
V02, 4.0, 2.0, 12.0
V03, 4.0, 3.5, 12.0
V04, 4.0, 3.5, 15.0
Two rules keep the template trustworthy. First, parameter ranges must be bounded so that no variant causes a topology change — for instance, a fillet radius that exceeds the adjacent face width will merge faces and destroy named selections. Validate each rebuild by checking that the named-selection count and face-ID list match the template baseline. Second, freeze the CAD kernel version and export format for the entire study; a kernel upgrade mid-study can reorder face IDs even when geometry is visually identical.
Meshing strategy: deterministic and transferable
Mesh independence is a property of a model, not of a single run. The meshing strategy must therefore be defined once, as a reusable recipe, and applied identically to every variant. The recipe should specify element type and order, global target size, local sizing on named faces and edges, growth rate, transition controls, and the meshing algorithm (for example, tetrahedral with inflation layers, or hex-dominant). Where the geometry permits, prefer a mesh that is parameter-driven: local sizes defined as functions of template parameters rather than absolute values, so that a thicker rib automatically receives proportionally sized elements.
A defensible convergence check is performed once on a reference variant, not on every variant. Refine the global size through a sequence — for example, 8 mm, 6 mm, 4.5 mm, 3.5 mm — and track a scalar response such as maximum von Mises stress at a fixed probe location and total strain energy. Accept the coarsest mesh whose response changes by less than a stated threshold (commonly 2–3%) relative to the next finer level. Record the accepted global size and all local controls as the locked recipe. Every subsequent variant uses exactly this recipe; if a variant's geometry forces a local size change, that deviation must be logged and its effect on the response quantified, otherwise the variant is not comparable.
Mesh quality metrics should be checked per variant against fixed acceptance thresholds — for example, minimum Jacobian ratio, maximum skewness, and aspect ratio limits appropriate to the element type. A variant that fails quality thresholds is remeshed with the same recipe and, if it still fails, flagged rather than silently accepted with a degraded mesh.
Solver configuration consistency
Solver settings are the most frequently overlooked source of non-comparability because they are often inherited from a previous project or adjusted interactively. The configuration must be captured as an explicit, version-controlled artifact: a solver input deck, a configuration file, or a documented settings sheet. At minimum, lock the following: material constitutive model and property values (including any temperature dependence), boundary condition and load definitions referenced to named selections, contact formulation and stiffness settings, nonlinear solution controls (substep count, convergence tolerances, line-search options), and output requests (which quantities, at which locations, in which format).
For a linear static study, the critical controls are the equation solver type and the load-step definition; for a nonlinear contact study, the contact stiffness factor and the force residual tolerance dominate. In either case, the rule is the same: the configuration is defined once, stored with a version identifier, and applied unchanged to every variant. If a variant fails to converge under the locked configuration, the correct response is to investigate the variant's geometry or mesh — not to relax the tolerance, because a relaxed tolerance changes the numerical answer and invalidates the comparison.
Verification gates and the audit trail
Each of the three pillars should be guarded by a verification gate that runs automatically or as a checklist before results are accepted. The geometry gate confirms topology integrity and named-selection counts. The mesh gate confirms quality metrics and that the locked sizing recipe was applied. The solver gate confirms convergence, residual levels, and that the configuration version matches the study baseline. A variant that passes all three gates enters the comparison set; a variant that fails any gate is flagged and resolved before ranking.
The audit trail is what makes the ranking defensible months later. For each variant, retain the parameter set, the geometry revision, the mesh statistics (element count, minimum quality metric), the solver configuration version, and the extracted response values. A compact per-variant record might look like this:
| Field | Example (V03) | Purpose |
|---|---|---|
| Parameter set | t_rib=4.0, r_fillet=3.5, h_boss=12.0 | Reproduce geometry |
| Topology check | 12 named selections, matches baseline | Confirm mapping integrity |
| Mesh statistics | 412k elements, min Jacobian 0.71 | Confirm recipe and quality |
| Config version | solver_cfg_v2.1 | Confirm identical physics |
| Response | σ_max = 158 MPa, mass = 1.53 kg | Feed the ranking |
With these three controls in place, the multi-iteration study becomes a controlled experiment rather than a collection of unrelated simulations. The ranking that follows is then a statement about design merit, not about modeling luck — and any reviewer can trace a variant's result back to the exact geometry, mesh, and solver settings that produced it.