Across aerospace, teams are being asked to deliver more capable systems on shorter timelines without giving up safety, performance, or confidence in their engineering decisions. In a 2023 McKinsey and NAFEMS survey of 176 simulation users and providers, 73 percent named faster time-to-market as an expected future source of value from simulation, ranking it ahead of product cost reduction and improved performance. This pressure is why engineers across the industry are rethinking how simulation and testing support decisions.
When one part of the workflow is too slow, the instinct is almost always the same: add compute. Ask an aerodynamics team why their aerodynamic database takes weeks to build and the first answer is usually the queue. Each case is a CFD solve, there are thousands of them across the flight envelope, and the machines can only work so fast. The fix follows directly: make the solves faster.
One major aerospace OEM did exactly that. They moved from a conventional CPU-based solver to a GPU-native one and cut runtime per case by nearly an order of magnitude. Throughput went up, cost per case went down. By the logic above, the team should have completed the database far sooner.
It didn’t. The team still waited weeks.
That result is worth sitting with, because it contradicts the instinct every engineering leader has when a workflow is too slow. Faster individual solves did not eliminate the wait, because the wait was never really about how long a single case took. It was about how the entire workflow was structured.
The trap in a discrete workflow
Most simulation still runs in batches. A team defines a fixed set of questions, prepares and runs the cases, validates the results, and hands a static dataset to the engineers waiting on it. When a requirement changes or a new question appears, the decision cannot move until the team prepares, runs, and validates another batch. That is a discrete workflow, and its cost is structural, not computational.
An aerodynamic database is the clearest example. It captures how a vehicle’s forces and moments vary across the flight envelope, giving flight controls, performance, and loads teams a consistent source of aerodynamic coefficients. Building it requires thousands of cases, and the count grows combinatorially: each flight condition has to be evaluated across geometry, angle of attack, sideslip, and control-surface deflections. A vehicle with seven control surfaces sampled at five settings already has roughly 78,000 control configurations before the grid of flight conditions is layered on, and flight-controls derivatives multiply the count again, because each derivative needs additional perturbed solutions. When the configuration changes, the team must rebuild the database from scratch. Thousands of jobs have to be completed before the data is ready, delaying work on the program’s critical path.
Now make every one of those solves ten times faster. The matrix is still fixed in advance. The cases still have to be prepared, launched, monitored, checked, and reduced to quantities of interest. The result is still a static table that goes stale the moment the configuration changes, at which point the whole chain restarts. Faster compute compresses one stage of a multi-stage process and leaves the process intact.
For this OEM, several thousand simulations spanning low-speed through hypersonic conditions, even at roughly an hour per case, still took weeks to prepare, run, validate, and assemble. The machines delivered more throughput. The program still waited for the database.
This is why the faster-compute instinct disappoints. It optimizes the thing you can see, the solve, and leaves untouched the thing that actually sets the tempo: answers arrive in discrete, pre-defined batches, and nothing downstream can move until the batch is done.
What actually changed
The OEM’s engineers and Luminary’s delivery team trained a Large Physics Model on those same several thousand simulations. The training data paired each vehicle configuration and operating condition with solver-produced pressure fields, forces, and moments, so the model learned the mapping from geometry and flight conditions to physical outputs.
Once trained, the model produced the outputs for a new database through inference instead of re-solving every case from first principles. Engineers could query the model directly or export a conventional aerodynamic table for existing flight-dynamics tools, with no change to downstream interfaces. In benchmark testing the model held low-single-digit error against the solver, and the avoided compute of not re-solving the full matrix came to nearly $10,000 per iteration.
The point is not that inference is faster than solving, though it is. The point is that it breaks the batch. Engineers stopped waiting for a pre-defined set of answers and started querying the model as new questions arose. A design change, a new operating condition, or a downstream request no longer triggered another multi-week cycle. You can experience Physics AI inference firsthand in Luminary’s interactive prediction demo.
| Discrete workflow | Continuous workflow |
|---|---|
| Define a fixed case matrix | Query as requirements evolve |
| Prepare and run thousands of jobs | Infer routine cases across the supported envelope |
| Deliver a static table | Query the model or export an updated table |
| Restart when the configuration changes | Adapt with transfer learning and targeted new data |
| Interpolate between sparse samples | Use confidence gating to identify when new simulation is required |
This does not push high-fidelity simulation out of the process. It moves it to the places where it’s most valuable. Solver and test results still anchor training and validation, and routine questions inside the validated envelope get answered by inference instead of a new solve. When a condition falls outside the model’s validated envelope, uncertainty estimates indicate that additional simulation is required. Those new results can then expand both the training data and the envelope in which the model can be trusted. The rigor is still there. What’s gone is the wait.
Physics AI: From one workflow to an organizational capability
The aerodynamic database is the first application of many to come. The OEM is already carrying the same trained pipeline into structural loads, giving the structures team faster access to the aerodynamic data needed to evaluate updated designs. When the design changes, the team can assess its impact without waiting for aerodynamics to prepare and deliver another dataset.
Because the same data, training, validation, deployment, and retraining systems support each application, every use case strengthens a shared foundation. Coefficients feed flight controls and performance; pressure fields feed structures; updated aerodynamic data supports trajectory and mission analysis. As simulation, test, and operational evidence accumulates, the OEM refines that foundation rather than rebuilding the analysis process for every question or team.
That is the shift the faster-compute instinct misses entirely. The gain was never a quicker solve. It was turning a recurring, disposable deliverable into a reusable engineering asset, one that answers new questions as they arise, carries its training investment into new configurations through transfer learning, and grows as simulation and test evidence accumulate. A conventional database is a cost you pay again every time the vehicle changes. A trained Large Physics Model is compute you spend once and draw on continuously.
When verification becomes continuously available, the tempo of engineering itself changes. A question can arise in aerodynamics, produce the pressure data structures needs, and reach a downstream decision without each team waiting for the previous discipline to generate and hand off a dataset. Each discipline keeps its validation standards and trusted tools, but information moves between them faster.
Luminary is the Physics AI platform for building, deploying, and operationalizing Large Physics Models across applications, disciplines, and stages of development, so a capability that starts as one team’s workflow becomes a strength the whole organization can draw on.
See how Physics AI could turn your simulation workflow into a reusable engineering capability. Talk to a Physics AI expert.
