Skip to content
DimensionLab
Frontier

The simulations you own,
turned into models you can trust.

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

Sweep the architectures.
Keep the best one.

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.

X-MeshGraphNet0.880NVIDIA benchmark
AB-UPT0.880AB-UPT paper
FIGConvNet0.880NVIDIA benchmark
DoMINO0.880NVIDIA benchmark
GeoTransolver0.880Measured in Frontier

The workspace

Everything behind the result.
In one window.

DrivAerML in Frontier · held-out designs, reference CFD and pretrained model predictions.

DrivAerML in Frontier · held-out designs, reference CFD and pretrained model predictions.

Frontier workspace comparing CFD reference and NVIDIA GeoTransolver pressure predictions on a held-out DrivAerML car

Why Frontier

Your simulation archive
is your most expensive dataset.

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

The whole loop.
In view.

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.

Give your simulations a second life.

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.

Solver archiveOpenFOAM · VTK · CGNS
prepare.recipe.jsonversioned with the project
Versioned datasetahmedml-40 · 40 samples
Quality reportassertions and gates
Preparation recipe
casesrecipedatasetreport

Plan · Preview · Run

  1. prep.quality.checkquality report and assertions
  2. prep.quality.gatetrain-ready gate
  3. splitheld-out cases keep their original split
40 samplestrain 32val 4test 4
Board node · preparation recipe with its inputs and outputs

Inspect an evaluated model

Different designs.
Measured predictions.

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.

CFD referenceGeoTransolver prediction
Loading evaluated cases…
Surface pressure · m²/s²≤ −700 to ≥ 700

— pressure error · this design

— drag error · this design

20 evaluated designs. Drag either surface to rotate both views.

Evaluation, design parameters and sources

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

A loss curve
is only
part of the story.

Look at the field.

See prediction, reference and error on the geometry itself, with a shared camera and colour range so differences stay visible.

Test beyond the training set.

Hold out whole geometries and trajectories, check for leakage, and see how error grows as designs move away from the training data.

Know where the model is unsure.

Combine ensembles into uncertainty fields across space and time, so a reviewer sees where a prediction can be relied on.

Reproduce any result.

Dataset revisions, configurations, checkpoints and evaluation reports stay linked, and training is deterministic by default.

DrivAerML · CFD reference and GeoTransolver prediction in Frontier

DrivAerML · CFD reference and GeoTransolver prediction in Frontier

Full Frontier window comparing CFD and pretrained GeoTransolver pressure on a held-out DrivAerML car

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

Different physics.
The same workspace.

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.

Turbomachinery

Compare reference and predicted surface pressure on Rotor37 blade geometries.

Rotor37 · pressure field comparison

Rotor37 · pressure field comparison

Reference and predicted Rotor37 blade pressure in Frontier

Operational signals

Inspect measured turbine channels and evaluate forecasts against a persistence baseline.

Kelmarsh SCADA · measured generator-bearing temperature

Kelmarsh SCADA · measured generator-bearing temperature

Measured generator-bearing temperature history from the Kelmarsh wind turbine dataset in Frontier

Not tied to one physics.

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.

Verified on public data
External aerodynamics (DrivAerML, AhmedML, WindsorML), airfoils (AirfRANS), turbomachinery (Rotor37), structural response (deforming plate, Mechanical MNIST, PLAID tensile), transient 2-D flows (cylinder wake, shallow water, turbulent radiative layer), crash and battery cases from SHIFT, and operating signals from a wind farm (Kelmarsh SCADA).
Solver and data readers
OpenFOAM, VTK, CGNS, EnSight, Tecplot, Nek5000, PyFR, Fluent, CFX, STAR-CCM+ exports, Abaqus, LS-DYNA, Nastran, COMSOL exports, NetCDF, HDF5, CSV and Parquet, among others. Some commercial readers are still marked experimental until they are validated against a licensed installation.
Model architectures
Point MLPs, Transolver, Fourier neural operators, MeshGraphNets, U-Nets and temporal convolutions in Frontier itself; Transolver, GeoTransolver, FIGConvNet, MeshGraphNet and X-DeepONet through the NVIDIA PhysicsNeMo bridge; your own PyTorch module through the SDK.
Catalogued, verification pending
Electromagnetics, plasma and fusion diagnostics, molecular dynamics, particle and granular methods, and weather and climate reanalyses are listed in the hub with their formats and licences. We mark each one verified only once a real subset has been pulled, converted and checked.

Built for production campaigns

Terabytes in.
Bounded memory per read.

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.

  1. 01

    Data that stays exact

    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.

    Built on ArrayRoute, open source

  2. 02

    Training you can repeat

    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.

    PyTorch · NVIDIA PhysicsNeMo · your own models

  3. 03

    Results at full resolution

    Publish fields to NVIDIA Omniverse as OpenUSD stages and NanoVDB volumes, tested on grids of 10⁸ nodes, for design reviews and digital-twin scenes.

    OpenUSD · NanoVDB · Omniverse Kit

  4. 04

    Models that know their limits

    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.

    HTTP · Triton · FMI 2.0

Your infrastructure. Your engineering data.

At home on
your compute.

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.

Your workspaceFrontier

Data · pipelines · experiments · results

  • 01

    Workstation

    Develop and inspect locally.

  • 02

    Cloud GPUs

    Dedicated workers and serverless inference.

  • 03

    HPC / SLURM

    Use your cluster and scheduler.

Customer-hosted server, workers and storage · on premises or hybrid

Single sign-on
People sign in through your OpenID Connect provider. Workers and CI use scoped API tokens.
Roles and audit
Every route is permissioned by role, and a hash-chained audit log shows any edit to history.
Air-gapped sites
Install and update from an offline bundle, with no connection to the internet.
Explore deployment options

Open where it connects

Built to work
with your world.

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 ecosystem

Questions

Straight answers.
Before the call.

What is DimensionLab Frontier?
Frontier is a physics AI platform. It turns the CFD and CAE simulations an engineering organisation already owns into physics models: it prepares the data with its setup and provenance attached, trains and evaluates surrogate models on held-out designs, and deploys them on the organisation's own infrastructure with the evidence behind every result.
Which simulation formats and solvers can Frontier read?
Open formats such as OpenFOAM, VTK, CGNS, EnSight, Tecplot, NetCDF, HDF5, CSV and Parquet, and exports from commercial tools including Fluent, CFX, STAR-CCM+, Abaqus, LS-DYNA, Nastran and COMSOL. Some commercial readers are marked experimental until they are validated against a licensed installation.
How accurate are the models?
On the public DrivAerML dataset, NVIDIA's pretrained GeoTransolver evaluated in Frontier on all 48 held-out car designs reached a mean relative L1 surface-pressure error of 2.81%, a drag coefficient R² of 0.995 and a mean drag error of 0.84%. Every number is published with the dataset revision, checkpoint hash and evaluation protocol.
Where does Frontier run and where does the data go?
On a workstation, an on-premises HPC cluster, a private or public cloud, or an air-gapped site. Frontier runs inside your infrastructure, so simulation archives and trained models never have to leave it.
How are models deployed?
Models export to ONNX, TorchScript or TensorRT and serve over HTTP or NVIDIA Triton, or package as an FMI 2.0 co-simulation unit. Responses can carry uncertainty and an out-of-envelope flag so a design loop knows when a prediction should not be trusted.
How do I get access?
Frontier is opening to engineering teams in stages. Join the waitlist at dimensionlab.org/waitlist or start a conversation at dimensionlab.org/contact; teams whose simulation programmes are closest to what Frontier supports today go first.

Work with us

Bring your hardest
simulation problem.

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.

Start a conversation

Or

Read the engineering & business briefing →

Image credits