Physics-ML Monograph Series

NVIDIA PhysicsNeMo: a field guide for vehicle engineering

What the framework is, how its four repositories fit together, and a curated tour of the GitHub examples closest to real automotive work: external aerodynamics, crash dynamics, thermal surrogates, and deployment workflows.

By Majid Mazouchi Drafted with Claude July 2026 Sources: github.com/NVIDIA
Abstract. PhysicsNeMo (formerly Modulus) is NVIDIA's open-source framework for building, training, and fine-tuning physics-ML models: neural operators, graph neural networks, physics-attention transformers, diffusion models, and PINNs, backed by optimized data pipelines and multi-GPU training infrastructure. For a vehicle engineer, the most valuable part of the project is not the library itself but its example catalog: production-grade training recipes on open automotive datasets (DrivAerML, AhmedML, DrivAerNet) plus deployment workflows that couple trained surrogates back into CFD and CAE toolchains. This guide maps that catalog, filtered through a vehicle lens.
Section 01

What PhysicsNeMo actually is

PhysicsNeMo is best understood as three things stacked together: a model zoo of physics-ML architectures, a training substrate tuned for scientific data structures, and a recipe catalog of end-to-end worked examples.

The project began life as NVIDIA Modulus and was rebranded to PhysicsNeMo in early 2025. It is Apache 2.0 licensed, pure PyTorch underneath, and installable either as a pip package or through NVIDIA's NGC container images. The framework is modular by design, and its core components break down as follows:

The training recipes themselves are deliberately not bundled into the pip wheel. You clone the repository and work from examples/, each recipe carrying its own requirements.txt and Hydra configuration. That decision matters in practice: the examples are meant to be forked and pointed at your own data, not imported as a black box.

Section 02

The four-repository ecosystem

PhysicsNeMo is not one repo. It is a small constellation, and each member owns a distinct stage of the surrogate lifecycle: data curation, training, physics constraints, and engineering deployment.

NVIDIA/physicsnemo

The core framework: model architectures, datapipes, distributed utilities, and the full examples/ training-recipe catalog spanning CFD, structural mechanics, weather, and healthcare.

github.com/NVIDIA/physicsnemo

NVIDIA/physicsnemo-sym

Symbolic PDE framework for physics-informed training: geometry primitives, SymPy equation definitions, and residual-loss machinery behind the PINN and PINO recipes.

github.com/NVIDIA/physicsnemo-sym

NVIDIA/physicsnemo-cfd

The deployment side: recipes for calling pretrained models served as NVIDIA Inference Microservices (the DoMINO Automotive Aero NIM), a benchmarking suite of engineering metrics, and hybrid CFD-initialization workflows.

github.com/NVIDIA/physicsnemo-cfd

NVIDIA/physicsnemo-curator

Accelerated ETL toolkit that turns raw solver output (VTU, VTP, STL, LS-DYNA d3plot) into training-ready Zarr or VTP datasets, with reference pipelines for external aerodynamics and crash.

github.com/NVIDIA/physicsnemo-curator

A useful mental model: Curator feeds, PhysicsNeMo trains, Sym constrains, CFD deploys. The vehicle examples in Section 04 are drawn from all four.

Section 03

The model families, in one table

Every recipe in the catalog is a pairing of an architecture with a data regime. Knowing the families makes the example gallery legible.

Table 1 · Architecture families used in the vehicle-relevant recipes
FamilyRepresentativesData shapeWhere it shines in vehicle work
Graph neural networks MeshGraphNet, X-MeshGraphNet, AeroGraphNet Unstructured meshes as graphs Surface pressure and wall shear on car bodies; transient crash deformation on FE meshes; anything where mesh topology carries the physics
Point-cloud multi-scale DoMINO Point clouds, local multi-scale sampling Large-scale external aerodynamics; the architecture behind NVIDIA's Automotive Aero NIM
Physics-attention transformers Transolver, GeoTransolver Meshes and point sets via learned physical slices External aero and crash with strong out-of-the-box speed; supports FP8 training through Transformer Engine
Convolutional mesh solvers FIGConvUNet Large 3D meshes, arbitrary in/out geometry Efficient drag prediction over full-vehicle meshes with millions of cells
Neural operators FNO, PINO, ModAFNO Regular grids and spectral fields Field-to-field maps such as parametrized flow or thermal fields; the natural bridge to thermal neural network work
PINNs (via Sym) physicsnemo.sym recipes Collocation points, no or little data Data-poor regimes: enforcing Navier-Stokes or heat-equation residuals when simulation budgets are thin
Diffusion models physicsnemo diffusion module, CorrDiff Fields with distributions of answers Ensembles, inverse problems, and physics-constrained generation; useful where a single deterministic answer undersells uncertainty
Section 04

The vehicle example gallery

Fifteen recipes and workflows from the official repositories, each one runnable today, filtered and annotated for automotive relevance. Use the chips to slice by domain.

Showing 15 of 15 examples
Section 05

The open automotive datasets

Three open datasets underwrite nearly every aero recipe above. Knowing their scope tells you what a pretrained model has and has not seen.

Table 2 · Open datasets behind the automotive recipes
DatasetContentsLicenseUsed by
DrivAerML 500 parametrically morphed variants of the DrivAer notchback generic vehicle, spanning 16 geometric parameters, with high-fidelity scale-resolving CFD validated against wind-tunnel data CC-BY-SA DoMINO, Transolver, XAeroNet, NIM workflows
DrivAerNet Large parametric family of realistic DrivAer-derived car geometries with CFD surface and force data Open (research) AeroGraphNet, FIGConvUNet
AhmedML Parametric Ahmed-body bluff geometries; the canonical simplified car shape for validating aero surrogates cheaply Open AeroGraphNet, Curator ETL, UMAP analysis recipe
Practical note

The Curator repository ships scripts to download DrivAerML from multiple mirrors. Budget real disk: the full volume-field dataset runs to terabytes, which is precisely why the surface-only recipes (XAeroNet-S, DoMINO surface mode) exist as first milestones.

Section 06

Getting started

Two supported installation routes, one important flag, and the shape of a minimal recipe run.

Install

# Route 1: pip. Include cu12 or cu13 to get CUDA-matched PyTorch
# and GPU-accelerated RAPIDS packages.
pip install "nvidia-physicsnemo[cu12]"

# Physics-informed training (PINNs, PINO) needs the sym extra:
pip install "nvidia-physicsnemo[sym]"

# Graph-based recipes (MeshGraphNet, crash) need the gnns extra:
pip install "nvidia-physicsnemo[gnns]"

# Route 2: the NGC container, which bundles the full stack:
docker pull nvcr.io/nvidia/physicsnemo/physicsnemo:25.08

Clone the recipes

# Training recipes are NOT in the wheel. Work from the repo:
git clone https://github.com/NVIDIA/physicsnemo.git
cd physicsnemo/examples/cfd/external_aerodynamics/aero_graph_net
pip install -r requirements.txt

# Each recipe is Hydra-configured; a run looks like:
python train.py data.data_dir=/data/ahmed_body training.epochs=300

Curate your own solver output

# Example: LS-DYNA crash archives → training-ready Zarr
export PYTHONPATH=$PYTHONPATH:examples
physicsnemo-curator-etl \
  --config-dir=examples/structural_mechanics/crash/config \
  --config-name=crash_etl \
  serialization_format=zarr \
  etl.source.input_dir=/data/crash_sims/
A sensible first week

Day 1-2: run the DoMINO NIM inference notebooks on a DrivAerML sample and inspect the diagnostics. Day 3-4: train AeroGraphNet on the Ahmed-body set to internalize the Hydra recipe structure. Day 5: point the Curator ETL at one folder of your own solver output and see what breaks. That sequence front-loads the two hard lessons, deployment plumbing and data schemas, before any training bill arrives.

Section 07

From surrogate to vehicle health management

The catalog is framed around design-time CAE, but the same trained surrogates are quietly ideal building blocks for prognostics and health management.

Three bridges are worth naming explicitly. First, residual generation: a fast physics surrogate evaluated against telemetry provides a model-based expectation, and the innovation between prediction and measurement is the raw material of fault detection. A thermal or electro-thermal surrogate trained in the PhysicsNeMo style can serve as the nominal model in exactly the residual-analysis sense used in classical model-based diagnosis, but at fleet scale and with geometry awareness.

Second, what-if throughput: prognostics ultimately asks how a degraded component behaves under future load. Surrogates that answer in milliseconds make it feasible to roll out thousands of stress scenarios per vehicle per day, something no solver-in-the-loop architecture can afford. The crash recipe's design-sweep framing translates directly into degradation-sweep framing.

Third, uncertainty as a first-class signal: the MoE ensemble and the diffusion module both expose predictive spread. In a health-management context, spread is not a nuisance to be averaged away; it is the confidence weighting a downstream decision layer needs before flagging a fleet action.

None of the official examples say "PHM" on the label. But an engineer who can run the DoMINO recipe, the crash pipeline, and the Curator ETL has assembled, almost incidentally, every ingredient of a physics-grounded digital twin for a vehicle subsystem. The remaining work is the part frameworks cannot ship: choosing what to monitor, and deciding what a residual is allowed to mean.

Section 08

Choosing your architecture: a decision guide

The single most common false start is picking a model by fashion rather than by data regime. Start from what you have, not from what is newest.

Table 3 · From data regime to architecture
Your situationReach forRecipe to forkReasoning
Hundreds of steady CFD runs over varying geometry, full-vehicle scale DoMINO or Transolver external_aerodynamics/domino Point-sampling avoids mesh downsampling; both scale to production geometry and have pretrained checkpoints to adapt
Small dataset (tens of runs), mesh topology carries the physics MeshGraphNet aero_graph_net or vortex_shedding_mgn Graph inductive bias is strong regularization; the sample-efficient workhorse of the catalog
Meshes too large for one GPU (tens of millions of cells) XAeroNet / X-MeshGraphNet, FIGConvUNet xaeronet, figconvnet Built-in graph partitioning and factorized grids exist precisely to break the memory ceiling
Fields on regular grids (thermal maps, parametrized flow) FNO / PINO darcy_fno as template Spectral operators excel at grid-to-grid field maps and train fast; natural fit for battery or inverter thermal fields
Little or no data, but the governing PDE is known PINN via physicsnemo.sym ldc_pinns Physics residual replaces missing data; accept slower, fussier training as the price
Transient rollout (crash deformation, wake dynamics) GeoTransolver / MGN with rollout schemes structural_mechanics/crash The crash recipe already implements one-step, autoregressive, and time-bundled rollout for you to compare
You need uncertainty, not just a point estimate MoE ensemble or diffusion module MoE aero recipe; physicsnemo diffusion Ensemble spread and posterior sampling are the two supported routes to calibrated doubt
Rule of thumb

Data-rich and geometry-varying: learn from data, add physics only as a soft constraint. Data-poor and physics-known: go physics-informed. In between, the physics-informed fine-tuning recipes in physicsnemo.sym let a data-driven model inherit PDE residual pressure late in training, often the best of both.

Section 09

Anatomy of a recipe

Every training recipe in the catalog follows the same skeleton. Internalize it once and every other example becomes familiar territory.

# Typical recipe layout (aero_graph_net shown; others rhyme)
aero_graph_net/
├── conf/                  # Hydra configuration tree
│   ├── config.yaml        # top-level defaults
│   ├── data/              # dataset variants (ahmed, drivaernet)
│   ├── model/             # architecture hyperparameters
│   └── experiment/        # named, reproducible run bundles
├── src/ or *.py           # datapipe, model wiring, loss
├── train.py               # entry point, Hydra-decorated
├── inference.py           # checkpoint → predictions on new geometry
└── requirements.txt       # recipe-specific extras

Five framework idioms recur across every recipe and are worth learning by name:

Section 10

A 30-day project playbook

Four weeks from zero to a defensible pilot, with an explicit exit criterion per week so the project can fail fast instead of drifting.

W1Foundations

Environment, inference, and one toy training run

Stand up the NGC container or pip environment. Run the DoMINO NIM notebooks on a DrivAerML sample and study the no-ground-truth diagnostics. Train AeroGraphNet on the Ahmed-body set end to end, deliberately small, to internalize the Hydra structure, checkpointing, and logging.

a trained toy checkpoint plus a NIM inference plot you can explain line by line

W2Data

Audit your data and build the ETL

Inventory your solver archives: formats, schemas, field names, units, mesh sizes, and how many independent designs you truly have. Extend a Curator pipeline to your schema and produce a first Zarr dataset with global statistics. Decide the target quantities and the engineering metrics that will define success before any training starts.

a versioned, training-ready dataset and a written metric definition signed off by the domain owner

W3Modeling

First real surrogate, benchmarked honestly

Pick the architecture from Table 3, fork the matching recipe, and train on your data. Evaluate with the physicsnemo-cfd benchmarking workflow: pointwise error, integrated quantities, spectra, and residuals, not just a validation loss curve. If a pretrained DoMINO checkpoint fits your domain, run the predictor-corrector fine-tuning in parallel as a baseline race.

a benchmark report comparing at least two approaches on the Week-2 metrics

W4Decision

Validation report and deployment sketch

Stress-test generalization on held-out designs, quantify where the surrogate is and is not trustworthy, and write the honest one-pager: accuracy achieved, compute spent, speedup delivered, failure modes observed. Sketch the deployment path, a NIM-style container, a Python evaluation API, or a hybrid warm-start into your existing solver, and present the go / no-go.

a go / no-go decision backed by numbers, not enthusiasm

Section 11

Pitfalls the recipes will not warn you about

Seven failure modes seen repeatedly in first surrogate projects, each cheap to avoid if named in advance.

1 · Train/test leakage inside parametric families

DrivAerML's 500 cases are morphs of one base car; your in-house sweeps are likely the same. A random split puts near-twins on both sides and inflates accuracy. Split by design parameter region or by base geometry, and report both interpolation and extrapolation error separately.

2 · Field error is not force error

A model with excellent L2 pressure error can still miss drag by many counts, because integrated forces are dominated by small regions of separation and stagnation. Always evaluate integrated quantities and spectral content alongside pointwise metrics; the benchmarking workflow exists for exactly this reason.

3 · Mismatched normalization statistics

The global-stats file computed at ETL time is part of the model contract. Reusing a checkpoint with regenerated or different statistics produces confidently wrong fields with no error message. Version the stats file with the checkpoint, always.

4 · Aggressive mesh downsampling

Decimating a production mesh to fit GPU memory destroys near-wall gradients, the very physics that sets drag and heat flux. Prefer architectures designed around the problem: DoMINO's point sampling, XAeroNet's graph partitioning, FIGConv's factorized grids. Downsampling should be a measured decision, not a workaround.

5 · PINN training pathologies in data-rich regimes

Physics-informed losses bring stiff optimization, loss-balancing sensitivity, and spectral bias. When you have data, use it; reserve pure PINNs for genuinely data-poor problems, and prefer the physics-informed fine-tuning recipes when you want residual pressure on a data-driven model.

6 · Unpinned, fast-moving examples

The examples directory evolves quickly and some recipes are flagged as under active development. Pin to a tagged release for anything you intend to reproduce, and record the container tag in your experiment metadata.

7 · Underestimating storage before compute

Volume-field datasets at DrivAerML fidelity run to terabytes, and ETL is I/O-bound long before training is GPU-bound. Start with surface-only targets, budget disk and object storage first, and consider the newer PhysicsNeMo-Mesh format for markedly faster mesh loading than VTU.

Section 12

Learning resources

The shortest paths into the ecosystem, ordered roughly by how a newcomer should encounter them.

Table 4 · Where to learn what
ResourceWhat it is forLink
Official documentationAPI reference, tutorials, and the browsable examples catalog with per-recipe pagesdocs.nvidia.com/physicsnemo
Examples catalogThe full recipe index across CFD, structural, weather, and healthcare domainsexamples_catalog.html
Project blogRelease notes and deep-dives (diffusion module, PhysicsNeMo-Mesh, crash surrogates); the best way to track what is newnvidia.github.io/physicsnemo/blog
PhysicsNeMo ForumCommunity Q&A from new to moderate-level users and the maintainersNVIDIA developer forums
NGC container registryThe batteries-included Docker images (physicsnemo:25.08 and later)catalog.ngc.nvidia.com
NIM catalogPretrained hosted models including the DoMINO Automotive Aero NIMbuild.nvidia.com
CAE ML datasets hubDrivAerML, AhmedML, and WindsorML dataset access and documentationcaemldatasets.org
NVIDIA DLI courseGuided introduction to physics-informed ML with the framework, useful for team onboardingnvidia.com/training
Section 13

References

Framework and workflows
  1. NVIDIA PhysicsNeMo: open-source deep-learning framework for Physics-ML. github.com/NVIDIA/physicsnemo
  2. NVIDIA PhysicsNeMo documentation and examples catalog. docs.nvidia.com/physicsnemo
  3. NVIDIA PhysicsNeMo-CFD: library for using trained models in engineering and CFD workflows. github.com/NVIDIA/physicsnemo-cfd
  4. NVIDIA PhysicsNeMo-Curator: accelerated ETL toolkit for AI-ready scientific datasets. github.com/NVIDIA/physicsnemo-curator
  5. NVIDIA PhysicsNeMo-Sym: symbolic PDE framework for physics-informed training. github.com/NVIDIA/physicsnemo-sym
  6. Tangsali, K., Ranade, R., Nabian, M. A., Kamenev, A., Sharpe, P., Ashton, N., Cherukuri, R., Choudhry, S. "A Benchmarking Framework for AI Models in Automotive Aerodynamics." 2025. arXiv:2507.10747
  7. Sharpe, P., Ranade, R., Tangsali, K., Nabian, M. A., Cherukuri, R., Choudhry, S. "Accelerating Transient CFD through Machine Learning-Based Flow Initialization." 2025. Referenced in the physicsnemo-cfd hybrid initialization workflow. Workflow README
Architectures
  1. Ranade, R., et al. "DoMINO: A Decomposable Multi-scale Iterative Neural Operator for Modeling Large Scale Engineering Simulations." 2025. arXiv:2501.13350
  2. Choy, C., Kamenev, A., Kossaifi, J., Rietmann, M., Kautz, J., Azizzadenesheli, K. "Factorized Implicit Global Convolution for Automotive Computational Fluid Dynamics Prediction." 2025. arXiv:2502.04317
  3. Wu, H., Luo, H., Wang, H., Wang, J., Long, M. "Transolver: A Fast Transformer Solver for PDEs on General Geometries." ICML 2024. arXiv:2402.02366
  4. Pfaff, T., Fortunato, M., Sanchez-Gonzalez, A., Battaglia, P. "Learning Mesh-Based Simulation with Graph Networks." ICLR 2021. arXiv:2010.03409
  5. Li, Z., Kovachki, N., Azizzadenesheli, K., Liu, B., Bhattacharya, K., Stuart, A., Anandkumar, A. "Fourier Neural Operator for Parametric Partial Differential Equations." ICLR 2021. arXiv:2010.08895
  6. Raissi, M., Perdikaris, P., Karniadakis, G. E. "Physics-Informed Neural Networks: A Deep Learning Framework for Solving Forward and Inverse Problems Involving Nonlinear Partial Differential Equations." Journal of Computational Physics, 378, 2019.
Datasets and geometries
  1. Ashton, N., et al. "DrivAerML: High-Fidelity Computational Fluid Dynamics Dataset for Road-Car External Aerodynamics." 2024. arXiv:2408.11969
  2. Elrefaie, M., Dai, A., Ahmed, F. "DrivAerNet: A Parametric Car Dataset for Data-Driven Aerodynamic Design and Graph-Based Drag Prediction." ASME IDETC 2024. arXiv:2403.08055
  3. Heft, A. I., Indinger, T., Adams, N. A. "Introduction of a New Realistic Generic Car Model for Aerodynamic Investigations." SAE Technical Paper 2012-01-0168, 2012. (The DrivAer geometry.)
  4. Ahmed, S. R., Ramm, G., Faltin, G. "Some Salient Features of the Time-Averaged Ground Vehicle Wake." SAE Technical Paper 840300, 1984. (The Ahmed body.)
Vehicle applications
  1. "Automotive Crash Dynamics Modeling Accelerated with Machine Learning." NVIDIA, 2025. Validated on full-vehicle Body-in-White data using PhysicsNeMo. arXiv:2510.15201
  2. NVIDIA PhysicsNeMo blog: 25.08 release notes (DoMINO fine-tuning, MoE, design sensitivities) and the structural mechanics deep-dive. nvidia.github.io/physicsnemo/blog
  3. NVIDIA DoMINO Automotive Aero NIM documentation. docs.nvidia.com/nim
On citation hygiene

arXiv identifiers above were verified against the sources in July 2026. Author lists for the NVIDIA workflow papers are abbreviated; consult the arXiv pages for complete attributions before citing formally.