
What is a surrogate model?
A surrogate model is a fast approximation of an expensive simulation. How it's built, the main types, how many runs it needs, and when to trust it.


A surrogate model is a fast approximation of an expensive simulation. How it's built, the main types, how many runs it needs, and when to trust it.

A surrogate model is a fast approximation of an expensive simulation. It's built from a limited set of solver runs and learns to predict the outputs engineers need, from a single drag value to a full pressure field, for design inputs it hasn't seen. Teams use it to evaluate far more design candidates than the solver alone allows, then confirm the best ones with the solver.
You'll also see surrogate models called metamodels or emulators (Wikipedia). For a one-paragraph version, see the surrogate model glossary entry.
In engineering simulation, a surrogate stands in for a solver. In machine learning interpretability, a "global surrogate" is a simple model fitted to the predictions of a black-box model, so people can see how that model behaves (Molnar, Interpretable Machine Learning).
Same word, different job. This article is about the first meaning.
Because the simulations engineers trust most are the slowest, and design questions need a lot of them. A well-resolved CFD or FEA case can run for hours. Jones, Schonlau and Welch opened their 1998 paper on expensive optimization with an automotive crash simulation that may take twenty hours (Jones et al., 1998).
Once a surrogate is trained, each evaluation is cheap. That opens up work the solver budget would otherwise rule out (Queipo et al., 2005; Peherstorfer et al., 2018):
Five steps: define what goes in and out, choose which simulations to run, fit the model, test it on runs it never saw, then add runs where it's weak.
Inputs are design variables and operating conditions. They can be a short list of parameters, or the geometry itself as a mesh or point cloud. Outputs are either scalar quantities, such as lift, pressure drop or peak stress, or full fields. This choice decides which model families fit.
This is a design of experiments. A deterministic solver gives the same answer for the same inputs, so repeating a run adds nothing; that's why computer experiments are designed differently from physical ones (Sacks et al., 1989). Space-filling designs, such as Latin hypercube designs, spread the runs across the whole input space (Loeppky et al., 2009).
Each run becomes a training example: inputs on one side, solver outputs on the other. The surrogate learns the mapping between them.
Keep some solver runs out of training and compare the surrogate's predictions with them, output by output. Look at the worst error as well as the average one; Loeppky and colleagues report both for exactly this reason (Loeppky et al., 2009).
A surrogate doesn't have to be trained once. Jones and colleagues framed the trade-off: sample where the surrogate predicts good designs, and sample where its prediction error may be high. Their "expected improvement" criterion balances the two (Jones et al., 1998). Today the same loop is often called active learning.
For a smooth response and a moderate number of inputs, a classic starting point is about ten runs per input variable. Loeppky, Sacks and Welch tested this "n = 10d" rule for Gaussian process models and found it gives reasonable accuracy on tractable problems (Loeppky et al., 2009).
Their second finding is just as useful. When ten runs per input gives poor accuracy, adding runs improves it slowly, so a small first experiment tells you early that the problem may need reformulating.
That rule comes from models with four to twenty inputs and scalar outputs. Neural surrogates that predict full fields across changing geometries have no equivalent rule of thumb: the data they need depends on how much the geometry and the physics vary. A lack of usable data is also one of the main barriers engineers named in our survey of AI adoption in simulation.
Pre-training helps. In research on PDE problems, models pre-trained on broad data and then fine-tuned reached a target accuracy with far fewer downstream examples than models trained from scratch (Subramanian et al., NeurIPS 2023).
Surrogate families differ in what they predict, how much data they need, and whether they estimate their own uncertainty.
Sources for this comparison: NIST/SEMATECH e-Handbook, Jones et al., 1998, Rasmussen and Williams, 2006, ch. 8, Loeppky et al., 2009, Lakshminarayanan et al., 2017.
A polynomial or kriging surrogate maps a fixed list of parameters to a few numbers. If the geometry changes in a way those parameters don't describe, the model has nothing to work with. Neural surrogates learn from the mesh or the field directly, which suits geometry that changes from one design to the next.
Three families appear most often in the published work:
A physics-informed neural network is a related but different tool. It's trained to satisfy the governing equations, and a standard PINN solves one problem instance rather than learning from a set of solver runs.
You can act on a prediction when three things hold: the design sits inside the range the training data covers, the model's error on held-out solver runs is acceptable for the decision at hand, and the prediction's own uncertainty is low. When any of the three fails, that design goes to the solver.
Coverage. A surrogate learns from the runs it was given. Designs unlike them are where its predictions are least reliable, which is why the uncertainty estimate matters most there.
Uncertainty per prediction. Kriging gives a standard error with every prediction (Jones et al., 1998). Neural surrogates need an added method: deep ensembles, for example, train several networks and read their disagreement, and they report higher uncertainty on inputs unlike the training data (Lakshminarayanan et al., 2017). See uncertainty quantification.
The credibility chain. ASME defines verification as checking that a computational model solves its equations correctly, and validation as checking that it represents the real application (ASME VVUQ). A surrogate is checked against the solver, and the solver against experiments. So a surrogate is never more credible than the simulations it learned from. See verification and validation.
Upstream of the solver. The surrogate explores; the solver validates.
A typical loop: train on the solver runs you have, screen thousands of candidates, shortlist the few that look best, confirm them with the solver, and feed those new runs back into training. Multifidelity methods formalize the same idea: cheaper models supply the speed, and the high-fidelity model stays in the loop to keep the answer accurate (Peherstorfer et al., 2018).
NPco builds research-led physics AI for engineering simulation. Its models are pre-trained, transformer-based models that a team fine-tunes on its own simulation data, and they run on-premise or in the team's private cloud, so the data and the model stay within that team's infrastructure. Each prediction carries a confidence index, and an active-learning loop uses uncertainty quantification to suggest which simulations to run next. The solver still validates the final design.
Working on a problem where the solver budget sets the limit? Talk to an engineer.
A reduced order model is one kind of surrogate. It projects the solver's equations onto a small basis built from full simulations. Data-fit surrogates, such as kriging or neural networks, learn only from the solver's inputs and outputs.
Not necessarily. Polynomial response surfaces and kriging are statistical methods that predate deep learning. Neural networks are one family of surrogates, and the one that can predict full fields across changing geometries.
It depends on the problem, the data and the model, so there's no single number. Accuracy is measured against solver runs held out of training, for each output, looking at the worst error as well as the average.
For a Gaussian process with a moderate number of inputs, about ten runs per input is a tested starting point. Neural surrogates on varied geometries need more, depending on how much the geometry and physics vary; pre-training and fine-tuning reduce that need.
No. A surrogate is trained on solver results and checked against them. It lets a team explore many more designs before running the solver, and the solver confirms the designs that matter.