2. Change classification
Model requalification begins with a single, disciplined question: what exactly changed? The answer determines whether the existing qualification evidence remains valid, must be extended, or must be rebuilt. In practice, most requalification failures are not caused by the change itself but by misclassifying it — treating a design change as a solver upgrade, or vice versa. This section establishes a working taxonomy, explains why the two categories affect model validity differently, and provides a decision procedure you can apply to real change records.
Two Categories, Two Different Validity Arguments
A design change alters the modeled system or the intent of the model: geometry, materials, boundary conditions, operating envelope, control logic, parameter values, or the modeling assumptions themselves. The solver still solves the same class of equations, but it now solves a different problem. A solver change alters the numerical machinery used to solve an unchanged problem: solver version, discretization scheme, convergence tolerances, time-step control, linear solver, mesh adaptation strategy, or hardware/compiler stack that affects floating-point behavior.
The distinction matters because the two categories invalidate different parts of the qualification evidence chain. Qualification evidence typically consists of (1) a verified model definition, (2) a validated correlation against reference data, and (3) a documented verification of the numerical solution. A design change attacks (1) and usually (2): the model definition no longer describes the qualified configuration, and the validation correlation may no longer apply. A solver change attacks (3) and, indirectly, (2): the model definition is untouched, but the numerical error budget may shift, so previously demonstrated agreement with reference data can no longer be assumed.
Impact on Model Validity and Qualification Status
Model validity is a claim about fitness for purpose: the model, as configured and solved, represents the real system within a stated accuracy for a stated envelope. Qualification status is the administrative record that this claim has been demonstrated. The two can diverge. A solver change may leave the model physically valid while the qualification record becomes stale because the numerical evidence was produced on a different solver build. Conversely, a small design change — a 2 mm fillet radius increase, say — may leave the numerical evidence intact but invalidate the geometric fidelity argument.
The table below summarizes how each change type typically maps onto qualification status. Treat the entries as a default assessment that must be confirmed by impact analysis, not as an automatic verdict.
| Change type | Typical examples | Model definition | Validation evidence | Numerical verification | Default qualification status |
|---|---|---|---|---|---|
| Design — parametric | Material property update, minor dimension change within tolerance, boundary value adjustment | Changed | Re-check required | Reusable if mesh and numerics unchanged | Conditional; targeted re-validation |
| Design — configurational | New geometry feature, added component, changed operating envelope, revised control law | Changed | Invalid | Reusable only after mesh convergence re-check | Suspended; full requalification |
| Solver — version upgrade | Major/minor release, changed default schemes or tolerances | Unchanged | At risk | Invalid | Conditional; regression and verification re-run |
| Solver — numerical settings | Tolerance tightening, scheme switch, time-step change, linear solver change | Unchanged | At risk | Invalid | Conditional; sensitivity study required |
| Solver — environment | Compiler, MPI library, hardware, OS update | Unchanged | Low risk | Re-verify on representative cases | Conditional; reproducibility check |
Applying the Classification: A Worked Procedure
Consider a thermal-fluid model qualified against test data at three operating points. The change record states: "Upgraded solver from release 2023.1 to 2024.2; default gradient limiter changed; also updated coolant conductivity from 0.58 to 0.61 W/(m·K) based on supplier data." This is a compound change and must be decomposed.
- Split the record. Item A: solver version and default limiter. Item B: material property update. Each gets its own impact assessment and its own requalification decision.
- Assess Item B as a design change. The input deck changes. Determine whether the conductivity update lies within the validated parameter range. If the original validation covered 0.55–0.62 W/(m·K), the existing correlation remains applicable and only a delta check is needed. If it falls outside, re-validation at the affected operating points is required.
- Assess Item A as a solver change. Re-run the verification suite — mesh convergence, conservation checks, and at least one benchmark with an analytical or published solution — on the new release. Compare key outputs against the qualified baseline. A practical acceptance band for this example might be ±1.5 % on peak temperature and ±2 % on pressure drop; anything beyond triggers investigation before the qualification record is updated.
- Re-run the validation cases with the new solver but the old material property, isolating the numerical effect. Only then combine both changes and confirm the combined result is explained by the two individual effects.
- Update the qualification record with the new solver build identifier, the revised property value and its source, and the regression evidence. Record the classification rationale explicitly — this is what an auditor will ask for first.
Reading the Impact Map
The figure below maps the two change categories onto the evidence chain and the resulting qualification state. Use it as a triage aid when a change record first arrives: locate the change type, follow the affected evidence links, and read off the default status before committing to a requalification plan.
Common Misclassifications and Their Symptoms
Three failure patterns recur in practice. First, solver upgrades logged as "no change" because the input deck was untouched. The symptom appears months later when a reviewer cannot reproduce a qualified result on the archived build. Second, material or tolerance updates logged as solver changes because they were made in the same maintenance window as a version upgrade. The symptom is a requalification that re-runs numerical benchmarks but never re-checks the validation correlation, leaving a physical discrepancy undetected. Third, environment changes ignored entirely — a compiler or MPI update that shifts results at the last digit. These rarely invalidate a model, but they break bit-for-bit reproducibility, which many qualification schemes require; the fix is a reproducibility check on one representative case, not a full requalification.
A useful defensive practice is to require every change record to state, in one sentence, which evidence link it touches and why. If the author cannot name the link, the classification is not yet complete. This single field forces the decomposition described above and makes the requalification decision auditable without reconstructing the reasoning later.
With the taxonomy and impact map in place, the next step is to translate a classification into a concrete requalification scope: which verification cases, which validation points, and which acceptance criteria must be re-executed. That scoping decision is where the classification pays off, because it determines exactly how much of the original qualification evidence can be carried forward and how much must be regenerated.