Incremental re-analysis for small geometry changes in FEA

Users say it plainly: 'Having to run a full analysis to get results on small changes; would be nice to have an iterative function that could adjust analysis results with small changes to the model.' This is a daily frustration for design engineers who are running simulation in a design loop — tweaking a fillet radius, changing a bracket thickness, adding a rib — and then waiting for a full overnight solve to see whether the change helped.

The reason this hasn't been built into the major solvers is partly technical — true incremental FEA for arbitrary geometry changes is hard — but mostly structural. The CAE vendors sell solver throughput, often priced by core-hours or token consumption. Faster results from fewer full runs directly reduces the revenue their pricing model is built on. They have a quiet disincentive to solve this. The user experiencing the frustration (the design engineer or analyst) rarely controls the software budget, and the budget holder doesn't feel the daily friction of waiting for reruns.

What can be built today without solving the full incremental FEA problem: a change-scoping layer that sits between the CAD change and the solver submission. When a geometry change comes in, it identifies which elements are affected, what fraction of the model's stiffness matrix changes, and whether the change is local enough that a submodel run — on just the affected region with boundary conditions derived from the full-model result — would give a defensible answer. It then runs the submodel automatically and flags the result with a confidence estimate based on the size and location of the change relative to the stress gradient in the original full run.

This recurs every design iteration. In an active development program, a team might make five to fifteen geometry changes per week, each currently requiring a full rerun. Cutting even half of those full reruns to submodel runs saves real compute cost and, more importantly, real calendar time. The business case is straightforward for any team running simulation-driven design rather than simulation as a final check.

What to build

Build a script-driven workflow layer for Ansys Mechanical that compares two versions of a model's geometry, identifies the localized change region, automatically constructs and submits a submodel job with cut boundary conditions derived from the prior full-model result, and returns the submodel result alongside a confidence flag based on proximity of the change to high-stress or high-gradient regions in the original solution.

Where to start

Start with a single narrow use case: bracket and mounting feature modifications on existing assemblies, where the geometry change is typically local by definition and the full-model result for the surrounding structure is already trusted — this limits the scope of submodel boundary condition errors and makes the confidence flag easier to calibrate.

The hard part

The submodel approach only gives trustworthy results when the geometry change is genuinely local and away from stress concentrations — building a reliable automated confidence scoring system that correctly flags when a submodel result is not valid is as hard as the core feature itself, and getting it wrong erodes trust fast.

How it makes money

Usage-based pricing tied to submodel jobs run per month, with a free tier for up to 10 submodel jobs to drive adoption, then $300–800/month for teams running higher volumes — framed as compute cost savings to make the ROI conversation easy.