Cutting an Engineering Simulation from 39M to 9M Elements

On the engineering-simulation platform I led at Applied Engineering Solutions, one number quietly decided whether a run succeeded or fell over: the element count of the generated mesh. A representative large workflow was producing roughly 39 million elements. Runs were slow, memory-hungry, and unstable. After reworking how the mesh was generated, the same workflow produced about 9 million elements — a ~4x reduction — without losing the fidelity engineers needed.

Here is how I approached it.

Why element count dominates everything

In a finite-element style simulation, almost every cost scales with the number of elements: meshing time, solver memory, the size of result files, post-processing, and how much data the browser has to visualize afterwards. When a mesh balloons, you do not just get a slow run — you get runs that cannot finish at all because they exhaust memory on the worker.

So the highest-leverage optimization is rarely a faster solver. It is generating *fewer, better-placed* elements in the first place.

Where the elements were coming from

The original pipeline meshed uniformly. Regions that were geometrically simple got the same dense treatment as regions with tight curvature and stress concentrations. That uniformity is what produced tens of millions of elements: the mesh was paying full price everywhere, even where it added no accuracy.

The fix was to make density follow the geometry:

• Coarser elements in large, simple, low-gradient regions.
• Finer elements only near curvature, thin features, and boundaries that actually drive the result.
• Sensible minimum and maximum size bounds so the mesh never collapsed into degenerate slivers or exploded in transition zones.

Making it stable, not just smaller

A smaller mesh is only useful if it is also a *valid* one. Two things mattered as much as the raw count:

• Transitions: moving from coarse to fine regions has to be gradual, or you create badly shaped elements that wreck solver convergence.
• Predictability: engineers needed to trust that a given configuration produced a comparable mesh every time, so the parameters driving density were data-driven and administrator-managed rather than hand-tuned per run.

The result

The representative workflow dropped from 39M to 9M elements. Large runs that previously failed became routine, memory pressure on the workers eased, and the whole loop — mesh, solve, post-process, visualize in the browser — got dramatically more practical for real B2B work.

The lesson I keep coming back to: before optimizing how fast you process the work, ask whether you should be doing that much work at all. Most of the win was in *generating less*, intelligently.