The optimizer did its job. Then engineering reality hit.

Qi Qi, Machine Learning Engineer at Secondmind, discusses a recent technical paper "Beyond Optimization: Using Machine Learning to Support Constraint Design", and explains why the real test of an optimization workflow is what happens in the design review after the requirements move.

Date:

Date:

Every engineer who has run an optimization campaign will likely know the feeling. Weeks of simulation, a healthy Pareto front, a design chosen and carried into the review. And then a requirement moves, and the design you brought is now the answer to a question nobody is asking. Requirements move on every real programme; the only question is what your tooling has to say when they do.

That is the situation we built a benchmark around for NAFEMS UK Conference 2026. We deliberately scripted the requirement changes (one initial design stage, then three revisions of the kind fatigue and thermal reviews produce) and ran two toolchains through the same sequence: a conventional multi-objective optimization, and Secondmind for Design Space Exploration.

The conventional toolchain

The first stage proceeds exactly as expected. The optimizer runs a 5,000-simulation campaign, produces a healthy Pareto front, and the team selects a strong design. Then the fatigue review lands: the stress cap is coming down from 250 MPa to 150 MPa.

Under the new cap, the Pareto front is essentially wiped out. The engineer reruns the whole campaign against the tighter limit, another 5,000 simulations, and the best design it can find scrapes 179.9 Nm of torque against a hard minimum of 180 Nm. Technically a result; nobody wants to sign it off.

So the engineer does the sensible thing and goes to negotiate: is the 150 MPa really fixed? The stress engineer's answer is perfectly reasonable: "Probably not… What do you need it to be?"

And there the toolchain goes quiet. Ten thousand simulation runs, and none of them can say what stress cap would open up a workable design space. The optimizer did exactly what it was asked to do for the requirements as originally posed. It has no way to answer the question the project now depends on. In our benchmark, the baseline engineer gets there in the end: re-posing the problem, spending another full campaign, settling on a compromise at 200 MPa. But the compromise comes by trial and error, one expensive campaign at a time, and the engineer is left without evidence at exactly the moment the project needs it.

Wasted compute is a failure in itself (cutting simulation spend is much of what Secondmind exists to do), but there is a second failure here, and it is the one this benchmark was built to expose: conventional tools treat requirements as fixed inputs to a one-shot process. In reality, working out the right requirements is part of the engineering job: they emerge, get challenged, and get negotiated across disciplines. And in a genuinely new design space, you often can't know what is sensible to ask for until you look. It's like house-hunting in a city you don't know: you discover the right requirements by viewing what's actually on offer. A tool that only answers "find the best design for these constraints" is answering a question the engineer only briefly has.

The Secondmind approach

Now replay the same meeting with the Secondmind toolchain. Before any requirement changed, this workflow spent its budget differently: a few hundred simulation runs, directed by Secondmind Active Learning at mapping the feasible region rather than chasing a single optimum. Even so, it matched the baseline's torque on the initial stage for a fraction of the compute cost. The output isn't just a design; it's a reusable probabilistic model of how the design space behaves.

The fatigue review lands, the cap drops to 150 MPa — and the model's first answer is bad news, delivered fast: slide the stress threshold down and the feasible region collapses. No new simulations; seconds, not weeks. Bad news with a shape, though, is something you can negotiate with. Slide the threshold back up to 200 and pockets of feasibility reappear. This time the engineer walks into the conversation with the stress team carrying an answer: 150 leaves us nothing; 200 gives us room — can the fatigue case live with that? The stress engineer still has to be persuaded; requirements are still traded, not conjured. What's changed is that both sides are looking at evidence.


Figure 2. 2D feasibility slices through the surrogate at iteration 38, centred on Design A, at stress <= 250 MPa (left), 200 MPa (centre) and 150 MPa (right); blue indicates a high predicted probability of satisfying all constraints. The feasible pocket is large at 250 MPa, narrow at 200 MPa, and collapses at 150 MPa.

Feasibility slices through the surrogate model at three stress thresholds: 250 MPa (left), 200 MPa (center), and 150 MPa (right). Blue indicates a high predicted probability of satisfying all constraints. The feasible pocket is large at 250 MPa, narrows at 200 MPa, and collapses at 150 MPa — giving the engineering team the evidence needed to negotiate a workable compromise rather than simply restarting.

Once the compromise is agreed, the engineer chooses how much confidence to buy: take a verified design straight from the existing surrogate model at essentially no extra cost, or spend a couple of dozen targeted simulations refining the model first. Both routes beat the design the baseline reached after its extra campaigns. And when the thermal review later tightens the iron-loss cap — invalidating the baseline's compromise entirely and forcing yet another restart — the same choice is simply on the table again. The model built in stage one is still paying out, three requirement changes later.

What actually changed

Across the full sequence the ledger reads roughly 700 simulator calls against the baseline's 20,000, for comparable final torque — about thirty times cheaper. But the ratio is only half the story. The baseline optimizer performed exactly to specification; the difference is what the engineer could say in the room. One workflow ends at "we'll have to run it again"; the other lets the engineer answer "what do you need it to be?" with numbers. That is what we mean by supporting constraint design: treating the negotiation of requirements as a first-class part of the workflow, not an inconvenience between optimizations.


The same approach, live in Secondmind for Design Space Exploration. Engineers can drag the parameter sliders on the right and watch the feasibility map update in real time — turning what would have been a new simulation campaign into an instant design space interrogation.

In Secondmind for Design Space Exploration this is the everyday workflow, not a benchmark: engineers adjust constraint thresholds live and watch the feasible space respond, no new simulations required. The full technical paper goes deeper: the stage-by-stage simulator budgets and torque figures, how Active Learning selects simulations, and the complete four-stage comparison against the conventional baseline.

Access the full technical paper here.

Learn more

Want to see how Secondmind can help you with your most complex engineering challenges?

Share