Plan · Preview · Run
- prep.quality.checkquality report and assertions
- prep.quality.gatetrain-ready gate
- splitheld-out cases keep their original split
Prepare simulation data, train and evaluate physics models, and put them to work on your own infrastructure. Starting with CFD.
Every simulation you have run DrivAerML · held-out design 419 · high-fidelity CFD holds a field of physics. Surface pressure coefficient from the CFD solution. Frontier learns it. Front: the CFD reference. Rear: a trained model’s prediction. 2.82% mean error on this design. Change the design. Ask the model. Each new shape gets its pressure field and drag from the trained model, without running CFD again. And shows where it is wrong. Signed prediction error on the geometry. The body turns clear where the model agrees with CFD. Everything the simulation knows. Design 419 in full: surface pressure, skin-friction lines, streamlines and the wake where total pressure falls to zero. Cd 0.206. This is Frontier. From simulation archive to a model you can trust.
Measured in Frontier on DrivAerML
Drag R² on held-out DrivAerML designs, as published (NVIDIA benchmark, arXiv 2507.10747; AB-UPT, arXiv 2502.09692). Test splits differ between studies; GeoTransolver measured in Frontier on NVIDIA’s 48-design split.
The workspace
Why Frontier
Most of the cost of a physics model sits in the simulations behind it, not in the GPUs that train it. Frontier keeps every solver run, boundary condition and field attached, from the first imported case to the evidence behind a prediction.
It is neutral by design. Bring NVIDIA PhysicsNeMo or your own PyTorch models, data from open and commercial solvers, and run on a workstation, your cluster or rented GPUs. Your data and your models stay yours.
Building a large CFD foundation model takes about 200,000 high-fidelity simulations. Generating them costs about $10.3 million, 96% of the budget, while training the model on GPUs costs about $0.4 million, 4%. Frontier keeps every run, with its solver settings, boundary conditions and fields, reusable for the next model.
Estimate for a 3.15B-parameter CFD foundation model trained on 200,000 transient high-fidelity simulations. Source: Ashton, Brandstetter, Mishra, Fluid Intelligence, arXiv 2511.20455 (Table 4).
One workspace
Follow the path from a solver archive to a model you can inspect, evaluate and put to work. Each step leaves a record the next one builds on.
Bring solver outputs into a shared dataset. Inspect geometry and fields, reconcile units, check mesh quality, and hold out entire design families before training.
Every preparation step produces a recorded version you can inspect and replay.
Plan · Preview · Run
Inspect an evaluated model
Choose a held-out car. Compare its pressure field with the CFD reference, then switch to the error. These are saved outputs of NVIDIA GeoTransolver, evaluated through Frontier.
— pressure error · this design
— drag error · this design
20 evaluated designs. Drag either surface to rotate both views.
NVIDIA pretrained GeoTransolver, evaluated in Frontier on all 48 published held-out DrivAerML cases: 2.81% mean relative L1 pressure error and 0.84% mean relative drag error. This viewer loads saved predictions; the display meshes are simplified. Metrics use the original surfaces.
Native pressure is density-normalized. The same fixed pressure scale applies to every design and both comparison panes, saturating outside ±700 m²/s². The full display-data range is to m²/s². Error has its own symmetric scale.
Parameters are morphing offsets from the baseline geometry.
Download evaluation and provenance · Dataset attribution · CC BY-SA 4.0 · NVIDIA model
Evidence, not a dashboard
See prediction, reference and error on the geometry itself, with a shared camera and colour range so differences stay visible.
Hold out whole geometries and trajectories, check for leakage, and see how error grows as designs move away from the training data.
Combine ensembles into uncertainty fields across space and time, so a reviewer sees where a prediction can be relied on.
Dataset revisions, configurations, checkpoints and evaluation reports stay linked, and training is deterministic by default.
Inspect the prediction on the vehicle geometry, alongside the reference field and the measured evaluation. Both panes use the same pressure scale.
Beyond external aerodynamics
Work with pressure on a compressor blade or temperature histories from an operating wind turbine. The data, model and evaluation stay connected as the engineering problem changes.
Compare reference and predicted surface pressure on Rotor37 blade geometries.
Inspect measured turbine channels and evaluate forecasts against a persistence baseline.
Frontier works on fields over geometry, grids and time, whatever solver produced them. Here is what it reads and trains today, stated as precisely as we can.
Built for production campaigns
A single high-fidelity CFD case can reach hundreds of gigabytes. Frontier is engineered for archives of thousands of them, and for the people who have to sign off on what a model was trained on.
Reads from Zarr, HDF5, S3 and HTTP stores are planned against explicit memory budgets and pinned to immutable dataset revisions. A training run reads exactly the data it was approved on.
Data loading is deterministic by default. A resumed run restores its random streams and refuses changed inputs or numerical settings, on one GPU or across nodes.
Publish fields to NVIDIA Omniverse as OpenUSD stages and NanoVDB volumes, tested on grids of 10⁸ nodes, for design reviews and digital-twin scenes.
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.
Your infrastructure. Your engineering data.
Frontier runs where engineering already happens: a workstation, your own servers, an HPC cluster or cloud GPUs. The server, workers and storage are hosted by you.
Data · pipelines · experiments · results
Develop and inspect locally.
Dedicated workers and serverless inference.
Use your cluster and scheduler.
Customer-hosted server, workers and storage · on premises or hybrid
Open where it connects
Formats, connectors, data libraries and developer tools are Apache-2.0 on GitHub. Use them on their own, read the source, or build something that connects to Frontier.
Browse the ecosystemBring mesh and field data out of solver archives.
02 / ExchangeKeep geometry, fields and provenance together.
03 / ReadStream chunked scientific arrays within a memory budget.
04 / ExtendConnect training code through the SDK and PhysicsNeMo bridge.
Questions
Work with us
Frontier is opening to engineering organisations in stages. Join the waitlist with a few quick answers, or start a conversation with the people who built it.
Or
Read the engineering & business briefing →
Image credits