Introducing Frontier
Frontier turns the simulations your team has already run into physics models you can train, evaluate and deploy on your own infrastructure. Today we are opening the waitlist.
Every engineering organisation that relies on simulation is sitting on an archive: years of CFD and CAE runs, each one paid for in compute, licences and engineering time. Most of those results are used once, for the decision they were run for, and then stored. Frontier is our answer to a simple question: what if every one of those simulations made the next design faster?
Frontier is a workspace to prepare simulation data, train and evaluate physics models, and deploy them where your engineers work. It runs on your infrastructure: a workstation, your own servers, an HPC cluster or cloud GPUs. Today we are opening the waitlist.
Why now
The research community has started to put numbers on what physics AI at scale really costs. In Fluid Intelligence (arXiv 2511.20455), Ashton, Brandstetter and Mishra estimate that for a 3-billion-parameter CFD foundation model trained on 200,000 high-fidelity simulations, generating the data would cost around $10.3M of compute, against roughly $0.4M to train the model. The simulations are the expensive part.
They also make a point every simulation engineer will recognise: simulations are not interchangeable. Two datasets of the same car, run with different physics models, meshes and numerics, produce answers that a single model cannot simply be trained on together. A model is only as good as the record of how its data was made.
Those two observations shaped Frontier more than anything else.
What Frontier does
Prepare. Connectors read solver outputs, including OpenFOAM, VTK, CGNS and EnSight exports, into versioned datasets. Geometry, fields, boundary conditions and solver settings stay attached to every sample. Preparation steps are recorded as recipes you can inspect, replay and reuse for the next campaign. Reads are planned against explicit memory budgets and pinned to immutable dataset revisions, so a training run reads exactly the data it was approved on.
Train. Bring NVIDIA PhysicsNeMo models or your own PyTorch code. Training is deterministic by default: a resumed run restores its random streams and refuses changed inputs or numerical settings. Physics-aware metrics stream alongside losses, and every checkpoint keeps its lineage back to the data.
Evaluate. Compare predictions with the reference on the geometry itself, with a shared colour scale. Hold out whole designs, check for leakage, quantify uncertainty with ensembles, and keep the evidence in reports that stay linked to the dataset, configuration and checkpoint.
Deploy. Export to ONNX, TorchScript or TensorRT, serve over HTTP or NVIDIA Triton, or package an FMI 2.0 unit for system simulation. Responses can carry uncertainty and an out-of-envelope flag, so a design loop knows when a prediction should not be trusted.
A measured example
On DrivAerML, the public dataset of high-fidelity simulations of car designs, we evaluated NVIDIA's pretrained GeoTransolver in Frontier on all 48 held-out designs of its published split:
- surface pressure, mean relative L1 error
- 2.81%
- drag R² across 48 designs
- 0.995
- mean relative drag error
- 0.84%
Every number comes with its dataset revision, model checkpoint hash and evaluation protocol. You can inspect the predictions in 3D on the Frontier page, and read the full write-up in our case study.
Open where it connects
The parts of Frontier that other tools need to read, run or build against are open source under Apache-2.0: the dataset format, the solver connectors, the Python SDK, the PhysicsNeMo bridge and ArrayRoute, our library for bounded scientific array reads. You can use them without Frontier, and a dataset you prepare is never locked to us. Browse them in the open ecosystem.
Who it is for
Frontier is built for organisations that run their own simulation programmes: automotive, aerospace, energy, industrial equipment and the teams that serve them. It is designed for the people who own the problem together: the simulation engineer, the machine learning engineer and the person responsible for the infrastructure.
We are opening Frontier in stages, starting with teams whose work is closest to what it supports today. If that sounds like you, join the waitlist and tell us about your simulations, or start a conversation with the people who built it.