All Articles
Wireframe mesh of a twisted compressor blade on a dark grid

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.

Léonie Meister
Léonie Meister
Chief of Staff, NPco

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.

Two meanings of "surrogate model"

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.

Why engineers use surrogate models

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):

  • Design space exploration: scan many geometries and operating points to see which regions perform well.
  • Sensitivity analysis: find out which inputs actually move the result.
  • Surrogate-based optimization: search for better designs and send only the promising ones to the solver.
  • Uncertainty quantification: push scatter in the inputs through thousands of evaluations, which would be out of reach on the solver.

How a surrogate model is built

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.

1. Define the inputs and outputs

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.

2. Choose which simulations to run

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).

3. Run the solver and fit the model

Each run becomes a training example: inputs on one side, solver outputs on the other. The surrogate learns the mapping between them.

4. Test it on runs it never saw

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).

5. Add runs where the model is weak or the design looks promising

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.

How many simulations does a surrogate model need?

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).

Types of surrogate models

Surrogate families differ in what they predict, how much data they need, and whether they estimate their own uncertainty.

  • Polynomial response surface. Predicts: A few scalar outputs. Uncertainty estimate: Fit diagnostics, such as a lack-of-fit check. Good fit when: Few inputs and a smooth response.
  • Kriging (Gaussian process). Predicts: Scalar outputs. Uncertainty estimate: Built in: each prediction comes with a standard error. Good fit when: Tens to hundreds of runs; exact computation scales with the cube of the number of runs.
  • Reduced order model. Predicts: Full fields. Uncertainty estimate: Depends on the method. Good fit when: Many evaluations of one parametric model, with access to the solver's equations.
  • Neural network (GNN, neural operator, transformer). Predicts: Full fields on meshes or grids, across varied geometries. Uncertainty estimate: Not built in; added with methods such as deep ensembles. Good fit when: Larger, varied datasets; geometry changes between designs.
  • High-fidelity solver (the reference). Predicts: Whatever it's set up to compute. Uncertainty estimate: Through V&V and UQ of the solver itself. Good fit when: Confirming the shortlist.

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.

Neural surrogates: learning full fields

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:

  • Graph neural networks. MeshGraphNets treats the simulation mesh as a graph and passes messages between neighboring nodes. Its authors report results in aerodynamics, structural mechanics and cloth, running one to two orders of magnitude faster than the simulation it was trained on (Pfaff et al., ICLR 2021).
  • Neural operators. The Fourier neural operator learns the map from a PDE's parameters to its solution for a whole family of problems, and can be evaluated at a finer resolution than it was trained on (Li et al., 2020).
  • Transformers. Transolver groups mesh points with similar physical states and computes attention between the groups, which keeps the cost linear in the number of points. It was tested on car and airfoil designs (Wu et al., ICML 2024). We cover this family in transformers in numerical simulation.

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.

When can you trust a surrogate model's prediction?

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.

Where a surrogate fits in the engineering workflow

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).

How NPco works with surrogate models

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.

FAQ

Is a surrogate model the same as a reduced order model?

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.

Is a surrogate model a form of AI?

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.

How accurate is a surrogate model?

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.

How many simulations do you need to train a surrogate model?

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.

Can a surrogate model replace CFD or FEA?

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.

Sources

  1. Wikipedia, "Surrogate model," https://en.wikipedia.org/wiki/Surrogate_model
  2. C. Molnar, Interpretable Machine Learning, chapter "Surrogate Models" (global surrogate), https://christophm.github.io/interpretable-ml-book/global.html
  3. D. R. Jones, M. Schonlau, W. J. Welch, "Efficient Global Optimization of Expensive Black-Box Functions," Journal of Global Optimization 13, 455–492, 1998, https://www.stat.ubc.ca/~will/docs/JonSchWel1998_global_optimization.pdf
  4. N. V. Queipo, R. T. Haftka, W. Shyy, T. Goel, R. Vaidyanathan, P. K. Tucker, "Surrogate-based analysis and optimization," Progress in Aerospace Sciences 41(1), 1–28, 2005, NASA record: https://ntrs.nasa.gov/citations/20050186653
  5. B. Peherstorfer, K. Willcox, M. Gunzburger, "Survey of multifidelity methods in uncertainty propagation, inference, and optimization," SIAM Review, 2018, https://arxiv.org/abs/1806.10761
  6. J. Sacks, W. J. Welch, T. J. Mitchell, H. P. Wynn, "Design and Analysis of Computer Experiments," Statistical Science 4(4), 1989, https://projecteuclid.org/journals/statistical-science/volume-4/issue-4/Design-and-Analysis-of-Computer-Experiments/10.1214/ss/1177012413.full
  7. J. L. Loeppky, J. Sacks, W. J. Welch, "Choosing the Sample Size of a Computer Experiment: A Practical Guide," Technometrics 51(4), 366–376, 2009, https://www.asc.ohio-state.edu/statistics/comp_exp/jour.club/LoeppkySacksWelch_TNX2009.pdf
  8. S. Subramanian et al., "Towards Foundation Models for Scientific Machine Learning: Characterizing Scaling and Transfer Behavior," NeurIPS 2023, https://arxiv.org/abs/2306.00258
  9. NIST/SEMATECH e-Handbook of Statistical Methods, "Response surface designs," https://www.itl.nist.gov/div898/handbook/pri/section3/pri336.htm
  10. C. E. Rasmussen, C. K. I. Williams, Gaussian Processes for Machine Learning, MIT Press, 2006, chapter 8, https://gaussianprocess.org/gpml/chapters/RW8.pdf
  11. B. Lakshminarayanan, A. Pritzel, C. Blundell, "Simple and Scalable Predictive Uncertainty Estimation using Deep Ensembles," NIPS 2017, https://arxiv.org/abs/1612.01474
  12. T. Pfaff, M. Fortunato, A. Sanchez-Gonzalez, P. W. Battaglia, "Learning Mesh-Based Simulation with Graph Networks," ICLR 2021, https://arxiv.org/abs/2010.03409
  13. Z. Li et al., "Fourier Neural Operator for Parametric Partial Differential Equations," 2020, https://arxiv.org/abs/2010.08895
  14. H. Wu, H. Luo, H. Wang, J. Wang, M. Long, "Transolver: A Fast Transformer Solver for PDEs on General Geometries," ICML 2024, PMLR 235, https://proceedings.mlr.press/v235/wu24r.html
  15. ASME, "Verification, Validation and Uncertainty Quantification (VVUQ)," https://www.asme.org/codes-standards/publications-information/verification-validation-uncertainty

Share this article