Six days of computing time spent on the wrong geometry

A study run to completion on a model that did not represent the part.

Six days of computing time were spent on the wrong geometry when a simulation ran, fully converged, on a model that no longer matched the part it was meant to represent, and nothing in the solver's output was ever going to flag that mismatch because the arithmetic had no way of knowing what the real part looked like.

A mesh is a snapshot of a moving design

A simulation model is built from a snapshot of a design, imported once, cleaned up, meshed, and set running. Real designs keep moving after that snapshot is taken: a fillet gets enlarged to help manufacturing, a wall thickness changes to hit a weight target, a feature is added or removed entirely in response to some other constraint elsewhere in the project. None of those later changes reach a simulation that has already been meshed and is sitting in a compute queue, because the mesh is built from the geometry as it existed at the moment it was imported. On a project with several people touching related parts at once, that import moment can be well behind the current state of the design before the mesh has even finished generating, let alone before a multi-day solve has run to completion.

The result is a study that solves the equations correctly, converges cleanly, and describes, with genuine precision, a part that stopped being the actual design at some point during the run. Every hour of computing time after that point was spent refining the answer to a question the project had already moved past, and the refinement itself, more iterations, tighter residuals, gives no indication whatsoever that the underlying geometry has drifted away from what is actually going to be built.

A mesh that is too coarse or a boundary condition that is a rough guess at least leaves its error inside the version of the geometry the solver has. A geometry mismatch is invisible in a much stricter sense, since the model in front of the solver, considered on its own, has nothing wrong with it. The problem exists entirely in the relationship between that model and a design that has since moved on somewhere else, a relationship the solver has no way of checking because it was never given the later version to compare against.

The risk compounds sharply on any project where several disciplines are iterating on related geometry at once, since a mechanical designer, an electronics packager, and a thermal analyst can each be working from a snapshot taken at a slightly different moment, and a simulation built from one of those snapshots has no way of knowing the others have already moved on without it.

Driving flawlessly with a map of the wrong city

Driving a long journey using a detailed, carefully followed map of the wrong city produces confident, competent navigation the entire way. Every turn is taken correctly according to the map in hand, every junction anticipated, every road recognised exactly where the map says it should be, and the driving itself is flawless from start to finish. Every mile of it is still on the wrong side of town, because the map, however well read, described somewhere other than the place the driver needed to reach.

A simulation running against outdated geometry is that drive. The solving is correct. The meshing is careful. The convergence is clean. The entire process, examined on its own terms, looks exactly like good engineering, because it is good engineering, applied faithfully to a map that had already stopped matching the territory somewhere upstream of the first iteration. A driver following a wrong map has no reason, from inside the car, to suspect anything is amiss while each turn lines up with the page, and an engineer watching a converging residual plot has no equivalent signal telling them the geometry underneath it has already been superseded.

A map that is only slightly out of date is, if anything, more dangerous than one describing an entirely different city, since a single new road or a closed junction produces an error small enough to go unnoticed for many turns in a row, exactly as a geometry mismatch confined to one recently revised feature can leave the great majority of a simulation's result correct while quietly poisoning the one region that actually changed.

Checking the revision before a long run

A part still under active development can be revised more than once in the time one detailed simulation takes to mesh, solve and post-process, so a study that takes the better part of a week is racing against a design that may not sit still for a day of it. Nothing in a typical simulation workflow compares the geometry in the solver against the latest released version of the part, which leaves that comparison to a person.

The fix is treating geometry as something to be re-checked against its source right before a long run starts, and again before the results are used to make a decision, since having been correct at the moment of import says nothing about the week since. A version stamp or a revision check taking thirty seconds before a six-day run begins is cheap insurance against discovering, only after the run finishes, that the part being studied and the part being built quietly parted ways somewhere in the middle of the week.

My key error with this

I went straight to the detailed geometry, because the detailed geometry was what I actually wanted an answer about and the simplified version felt like a detour that would tell me something I already knew. Six days of solver time later I had a converged drag figure that was wrong, and it was wrong for a reason that any crude version of the model would have exposed within the hour, since the geometry I had meshed did not represent the part I thought I was studying. Running a stripped-back case first would have cost an afternoon and would have told me the answer was in the wrong range before I committed a week to computing it precisely. What replaced the belief is that a low-fidelity model is not a worse version of the real study, it is the instrument that checks whether the real study is pointed at the right thing, and that the more expensive the run, the less defensible it is to skip the cheap one that validates its setup.