What does it take to automate engineering analysis?

Automated engineering analysis is a system deciding which study answers the question, running it, and judging the result against a stated requirement. Everything short of that is a solver with a scheduler in front of it.

The distinction matters because the solver was never the hard part. Finite element codes have been accurate for forty years and several good ones are free. What has always needed a person is the judgement wrapped around the solve: whether a static study is even the right question, what the part is actually attached to, how fine the mesh has to be before the number stops moving, and whether the answer that comes back means the design holds.

A tool that gives you a stress plot has done the easy part. The work is deciding whether that plot is evidence.

Solvers are obedient. They answer the question you asked, including when it was the wrong one, and they rarely tell you which happened.

An unconstrained model still solves

Remove the boundary conditions from a static analysis and many solvers do not stop. They return an enormous rigid-body displacement, print that the job finished, and exit successfully. There is no warning text to scan for. The only defence is checking the deck before it runs: three non-collinear nodes held in all three directions remove all six rigid-body modes, and a bounding-box face of a curved body can turn out to be a tangent line two nodes wide.

The peak stress may have no value

At a clamped face or a sharp re-entrant corner the exact solution is singular, so the peak rises without limit as the mesh gets finer. We have measured the same bar go from 52 to 71 MPa over five refinements with no sign of settling, crossing the beam formula on the way past, while the deflection from those same solves converged to a fifth of a percent. One run, two numbers, one of them believable.

Units fail silently

Millimetres with kilograms is out by a thousand in force and a million in stress, and nothing complains. Degrees and radians share a dimension, so a check on dimensionality passes between them and the conversion then scales the value by fifty-seven.

None of these produce an error. They produce a confident wrong answer, which is the worst output an engineering tool can have.

A number becomes evidence when it survives checks that were set up to fail. Four of them do most of the work, and a system can run all four without a person.

Plenty of this is mechanisable. Some of it is not, and a vendor who does not draw the line is selling you a liability.

• Whether the requirements were the right ones. A system can prove a part meets what it was told. It cannot know that the load case someone wrote down is the load case the part will see.
• Whether the assumptions hold for your application. Linear elastic, small displacement, perfectly bonded contact: all reasonable, all wrong somewhere.
• Signing it. Releasing a design carries responsibility that software cannot hold. Nothing should leave as released without a person putting their name on it.

What is left is still most of the hours: setting up, meshing, converging, cross checking, reading, and writing it all down.

If a product claims to automate analysis, these separate the demo from the tool.

• Ask what the mesh study was. If the answer is one mesh, the number has no error bar.
• Ask what it was cross-checked against. A closed-form estimate derived before the solve is a check. Agreement with the system's own previous run is not.
• Ask what happens at a sharp corner. If it reports a peak stress there without qualification, it does not know what a singularity is.
• Ask to see a not-evaluated. A system with no such state has no way to be honest with you.
• Ask whether it is a solver or a surrogate. Both are legitimate. A surrogate trained on solver runs predicts fast and needs validating against the thing it was trained on; a solver is slower and answers directly. You should be told which.
• Ask where it runs. For work under an NDA, whether the geometry leaves the building is a procurement question before it is a technical one.

The solving is not the frontier. Established codes handle structural, thermal, modal, buckling and flow problems accurately, and the good ones are open source. What is new is a system that chooses the study, defends the mesh, reads the result and writes the verdict without being driven step by step.

In LMCAD that chain runs today: geometry meshes and solves end to end, and the results agree with closed-form theory before anything is reported. It is in beta and goes on sale on 1 January 2027. The related pieces are covered separately: what agentic CAD means as a category, and what automated engineering documentation has to produce.