Learned Simulators: Early Warnings
Neural networks trained on simulations promise answers far faster than the simulations themselves, until a case strays from what they were trained on. Here a network trained on flow past a cylinder runs beside the solver it learned from, from the same starting frame. Push the case outside the training range and watch which warning light comes on first, and when the two flows part.
How the comparison works, and what to try
Three panels. On top, the solver: a standard fluid simulation of flow along a channel past an obstacle, which sheds a trail of alternating vortices. In the middle, the network trained to imitate it, started from the same frame. Both are drawn as vorticity, how the fluid spins (orange counterclockwise, cyan clockwise). At the bottom, the difference between them, dark while they agree and white where they part. The status line gives the frame, the error between the two flows (the network has failed at 0.5) and whether the case is inside the network’s training range.
The warning lights watch only the network’s own output, never the solver, the way you would have to in practice. Each checks one sign of trouble: a flow that compresses when water can’t, a flow rate that changes along the channel, motion that breaks the equations of a fluid, flow inside the obstacle, energy piling up at the finest scales, five copies of the network disagreeing, an input unlike anything in training, and a combination of all of them. A light comes on when its signal stays above its threshold for three frames; its trace shows how close it is. The decision readout below compares what an engineer would use: how often vortices shed, how hard the obstacle is pushed sideways, and its drag.
The controls. The presets are cases chosen to show one behavior each. Reynolds number sets how fast the flow is (the network trained between 80 and 120); shape, size and position change the obstacle (drag it on the top panel). You can test the network trained with noise on its inputs instead, and turn on a hand back: when the chosen light comes on, the solver takes over for 40 frames and the network then resumes from the solver’s frame. Every change of case lets the solver settle first, which takes a moment.
Things to try. Start with the training range and note the frame where the error passes 0.5, about 90. Then try faster flow and see how much sooner it fails, and which light came on first. Move the obstacle off center: the novelty light is on from the first frame, before anything goes wrong. Then turn on the hand back at the faster flow and watch how often the solver has to take over.
Loading…
Vorticity: orange spins counter-clockwise, cyan clockwise; the obstacle is gray. Difference: white where the velocities differ by one typical fluctuation or more.
Frame 0 · field error 0.00 (failure at 0.5) · inside the training range
Warning lights
Each light watches the network’s own frames (novelty watches its inputs) and comes on when its signal stays above its threshold for 3 frames. The thresholds are the study’s, set so 5% of safe frames alarm. The dashed line is the threshold.
No alarm yet
No alarm yet
No alarm yet
No alarm yet
No alarm yet
Loading the other four networks…
No alarm yet
Loading the other four networks…
The decision readout
| Last 80 frames | Shedding (Strouhal number) | Lift swing | Mean drag |
|---|---|---|---|
| Solver | – | – | – |
| Network | – | – | – |
The decision check starts at frame 60. Drag and lift come from the pressure on the obstacle’s faces in the coarse frames, for both flows.
A case like the training flows: the network tracks the street for about 90 frames, then drifts.
Training range 80–120
Training 12, 14 or 16 cells across
Training within ±5 cells; drag the obstacle to move it along too
The result
We trained five copies of a small network on 512 flows and tested them on 704 new ones: 64 like the training flows, and 32 at each of five growing shifts along four axes (faster flow, new shapes, obstacles off center, larger obstacles). Every warning signal, its threshold and the way they’re combined were fixed on a separate development set before any test flow was looked at, and the test was written down in advance.
The warnings work. Outside the training range, a combination of all the signals ranks frames by whether the network is about to fail with an AUROC of 0.92–0.96 on every axis, and it was on before every failure, typically 19–30 frames ahead (half to most of a shedding cycle). Checking the network’s frames for the divergence a real fluid can’t have is nearly as good and, with the spread between the five networks, the best at telling which runs at the same shift are going wrong. But far out, a simple score of how unusual the inputs are warns as early as any physics check: it knows the case is new from the first frame.
Within the training range, the warnings mostly tell the time. The network drifts off the real flow there too, at a median of frame 87, and a signal that just counts frames ranks those moments almost as well (0.98) as the best checks (0.99). Compared only at the same frame, the best checks still score about 0.89, so they see something the clock doesn’t.
Warning doesn’t make the network worth using. A policy that hands back to the solver when the combination alarms, runs it for 40 frames and resumes, still failed the decision check (frequency, lift swing and drag of the vortex street) in 44–66% of runs, and cost more than running the accurate solver alone: the combination needs all five networks every frame. On this site’s own GPU code the solver is faster still, about 7 times faster than one network step. Training the network with noise on its inputs delays failure about threefold but makes it harder to see coming: almost every signal warns worse.
One network design, one flow, CPU timings for the study. A stronger network or faster hardware for it would change the cost side; the warning results are about this class of emulator.
Loading the results…
Conclusion
A neural network trained to stand in for a flow solver does fail when a case strays from its training, and its own output warns of it. Combining simple checks, such as whether the flow obeys the laws a fluid must, how much several copies of the network disagree, and how unusual the input is, flagged failures outside the training range well and typically 19 to 30 frames ahead, and far out, a plain measure of how unfamiliar the case is warned as early as any of them, from the first frame. Inside the training range the warnings mostly track time: the network drifts as it runs, and the clock alone predicts that nearly as well. But warning was not enough to make the network worth using. Handing back to the solver whenever a warning came on still got the quantities an engineer needs wrong in 44–66% of runs, and cost more than running the accurate solver alone. For this kind of learned simulator, the warnings are a useful safety check, not a way to make it pay; the open question is whether larger networks, or hardware that suits them far better, would change the cost side.
The science
The solver is a lattice Boltzmann method: the fluid as populations of particles moving and colliding on a grid, which recovers the Navier–Stokes equations for slow, weakly compressible flow. Behind a cylinder, above a Reynolds number of about 47, the wake sheds vortices alternately from each side, the von Kármán vortex street, and the obstacle feels a lift that swings at the shedding frequency. The solver passed the standard cylinder benchmark to within 3%.
The network is a U-Net, a convolutional network common in learned simulation, that steps a 2× coarser copy of the flow 25 solver steps at a time. It sees the flow, the obstacle and the Reynolds number, and was trained on circles 12–16 cells across, near the middle of the channel, at Reynolds numbers 80–120. Learned simulators are known to fail outside their training data, and studies keep finding that comparisons against weak baselines overstate them. The open question here is whether the network’s own output carries a usable warning, how early, and whether acting on it pays.
The signals: divergence, mass flux and the momentum residual check the network’s frames against the equations a fluid obeys; wall slip checks that nothing flows inside the obstacle; spectral pile-up looks for energy collecting at the finest scales; ensemble spread measures how much five networks trained the same way disagree; input novelty measures how unlike the training cases the input is. None of them sees the solver.
What’s real
- The solver is a standard lattice Boltzmann method, checked against the Schäfer–Turek cylinder benchmark (drag within 3%, shedding frequency inside the reference range).
- Vortex shedding behind a bluff body, its Strouhal number and the lift that swings with it are textbook fluid dynamics.
- Learned simulators failing outside their training data, and comparisons against weak baselines, are documented across the field.
- The browser runs the same solver and network as the study, checked against the Python research code.
What’s simplified
- A 2D channel 256 × 64 cells at low Reynolds numbers, not a 3D or turbulent flow.
- One small network design; larger or different architectures may fail differently.
- The page's hand back restarts the network from the solver running beside it; the study had to restart a solver from the network's frame, which costs accuracy.
- The study's costs are CPU timings on one laptop; the page's speed is your own GPU's.
Sources
- McGreivy & Hakim, “Weak baselines and reporting biases lead to overoptimism in machine learning for fluid-related partial differential equations,” Nature Machine Intelligence (2024)
- Schäfer, Turek et al., “Benchmark computations of laminar flow around a cylinder” (1996)
- Ohana et al., “The Well: a large-scale collection of diverse physics simulations for machine learning,” NeurIPS (2024)
- Gopakumar et al., “Calibrated physics-informed uncertainty quantification,” ICML (2025)