# NVIDIA PhysicsNeMo: a PyTorch framework for physics ML, from install to first surrogate

> PhysicsNeMo packages reusable PyTorch components and end-to-end recipes for scientific machine learning, with CUDA 13 wheels on PyPI and domain examples from aerodynamics to weather. The catch is the dependency floor and the GPU assumption.

**NVIDIA/physicsnemo** — Open-source deep-learning framework for building, training, and fine-tuning deep learning models using state-of-the-art Physics-ML methods

- Repository: https://github.com/NVIDIA/physicsnemo
- Website: https://developer.nvidia.com/physicsnemo
- Stars: 3,298 · Forks: 799
- Language: Python
- License: Apache-2.0
- Published: 2026-09-10 · Updated: 2026-09-10 · Language: en
- Canonical page: https://hysenlabs.com/projects/nvidia-physicsnemo

## What PhysicsNeMo is for, and who it is not for

PhysicsNeMo is an open-source PyTorch framework for physics machine learning, scientific machine learning, and AI for science and engineering. The README describes it as providing reusable library components and end-to-end training recipes. That phrasing matters: this is not a solver, and it is not a simulation engine. It is the layer between raw PyTorch and a trained surrogate model for a physical system.

The audience is narrower than "anyone doing science with deep learning". The examples directory is organised by domain: external aerodynamics, weather, semiconductor underfill dispensing, structural crash, geophysics, healthcare, data-center thermal design, additive manufacturing, molecular dynamics, nuclear engineering, reservoir simulation, TCAD, kinetic Monte Carlo. Each of those is a field where someone already has simulation data and wants a model that predicts a field faster than the simulator produces it. If that is your situation, the repository layout is the pitch. If you are looking for a general-purpose ML library, the physics-specific components will be overhead rather than help.

One structural signal is worth reading carefully. A v2.0-MIGRATION-GUIDE.md sits at the top level of the repository, and the project also publishes a physicsnemo sym package and a physicsnemo curator package. People search for comparisons between them, which suggests the naming has caused confusion. If you are evaluating PhysicsNeMo today, confirm which of those packages your use case belongs to before you write code against any of them.

## The mechanism: components plus recipes, not a monolithic trainer

The architecture visible in the repository is a library of model and utility modules under physicsnemo/, with examples/ layered on top as complete training recipes. The pyproject.toml dependency list tells you what the framework leans on. torch>=2.10.0 and torchvision>=0.25.0a0 are the base. warp-lang>=1.14.0 brings in NVIDIA Warp, which is the GPU kernel layer the topics list also names. hydra-core>=1.3.2 and omegaconf>=2.3.0 handle configuration, which is how the example recipes are parameterised. tensordict[zarr]>=0.14.0 and h5py>=3.15.1 and cftime>=1.6.5 cover tensor containers and the scientific file formats that climate and HDF5 data arrive in. einops>=0.8.1 and jaxtyping>=0.3.3 handle tensor reshaping and shape annotation. onnx>=1.14.0 is there for export.

That dependency set is the real description of the data flow. Simulation output lands in HDF5, Zarr, or NetCDF-style files; a dataset component reads it into tensors; a model from physicsnemo/ consumes those tensors; Hydra configs select the model and training parameters; Warp supplies GPU-accelerated operations where a plain PyTorch op would be too slow or too memory-hungry. Nothing in the README suggests a single prescribed training loop you must adopt. The examples are the reference implementation of that pipeline per domain, which is why the aerodynamics and weather recipes are presented as the headline material rather than any single model class.

The trade-off is that you inherit the configuration conventions. Hydra means your experiment is a YAML tree plus a command line, and the examples are written that way. Teams that prefer plain argparse and a Python entry point will spend time adapting rather than using.

## Installing PhysicsNeMo and running something real

The README gives one install line for the CUDA 13 build. It is a PyPI package named nvidia-physicsnemo, not physicsnemo:

```bash
pip install "nvidia-physicsnemo[cu13]"
```

For CUDA 12, a basic install, optional features, or a source setup, the README points to its installation options section rather than repeating commands, so check that section before assuming the cu13 extra is right for your driver. The Python requirement in pyproject.toml is >=3.11,<3.15, which rules out 3.10 and earlier.

For a source checkout, the Makefile shows what the project itself runs. The install target upgrades pip and installs the package in editable mode, then installs tfrecord separately with a comment that it is placed there until the container is updated:

```bash
make install
```

There is a separate editable-install target that adds the dev extra and passes --config-settings editable_mode=strict, which is what contributors use. If you only want to consume the library, the PyPI line is the shorter path.

Once installed, the realistic first use is not a blank script. The repository ships a minimal example directory alongside the domain ones, and the examples README is the index. The practical sequence is to pick the example closest to your physics, read its configuration, and run it against the sample data it expects before pointing it at your own. The README does not document a single canonical "hello world" command, so treat the example you choose as the entry point and expect to read its config tree. Container builds are also supported: the Dockerfile builds in stages (dependencies, builder, deploy, docs, with a ci branch) on top of a base image defaulting to nvcr.io/nvidia/pytorch:26.06-py3, and the Makefile exposes a container-deploy target that tags the image physicsnemo:deploy. That is the route to take if you would rather not manage the CUDA and PyTorch versions yourself.

## Where PhysicsNeMo gets in your way

The dependency floor is steep and it moves. torch>=2.10.0 with torchvision>=0.25.0a0, where the torchvision pin is an alpha, is not a combination most production environments already have. If your team is on an older PyTorch because another model in the same service depends on it, PhysicsNeMo will not slot in without an upgrade you may not control.

The GPU assumption is structural, not incidental. Warp is a core dependency, the topics list names nvidia-gpu, and the install extra is a CUDA version selector. The README does not present a CPU-first path. If you are prototyping on a laptop without an NVIDIA GPU, or your deployment target is CPU inference, the framework's acceleration story does not apply to you and you would be carrying dependencies for nothing.

Version churn is the third constraint. The v2.0 migration guide at the repository root exists because the project changed things in a way users had to be walked through. That is normal for a framework at this stage, but it means code written against one release is not guaranteed to survive the next. Pin your version and read the changelog before upgrading.

Finally, the documentation gap around the first run is real. The README gives an install command and a gallery of domain examples, but no single end-to-end walkthrough that takes a new user from install to a trained checkpoint. The examples are the documentation, and they assume you already know the physics and the file formats involved. That is a reasonable assumption for the intended audience and a wall for anyone else.

## PhysicsNeMo compared with a general PyTorch stack

The honest alternative is not another physics-ML framework. It is plain PyTorch plus your own model code. The difference in approach is where the reusable work lives. With plain PyTorch you write the mesh handling, the field-normalisation logic, the dataset readers for HDF5 or Zarr, the distributed training wiring, and the export path yourself, and you own every one of those decisions. With PhysicsNeMo, the project has already made those decisions and shipped them as components, and you inherit both the convenience and the constraints.

That trade favours PhysicsNeMo when your problem resembles one of the shipped domains closely enough that an example configuration is a starting point rather than a rewrite. Aerodynamics, weather, structural crash, and the other listed domains have reference recipes with data loaders and model definitions already wired together. Rebuilding that from scratch is weeks of work that produces nothing novel.

The trade favours plain PyTorch when your physics is unusual, your data layout does not match any example, or you need to understand and control every operation for verification purposes. A framework that hides mesh handling behind a component is a liability if your correctness argument depends on inspecting that handling. There is also a middle path worth considering: use PhysicsNeMo's data and utility components selectively while keeping your own training loop, since the repository is organised as a library rather than a monolith. The pyproject.toml dependencies are the cost of that choice, and they are not small.

## Maintenance, licence, and what upgrading costs

The repository is not archived, and its last push was on 2026-09-10, one week before this writing. Releases v2.2.0 and v2.2.1 landed on 2026-08-27 and 2026-08-31, after v2.1.1 on 2026-06-08. That cadence, combined with a CHANGELOG.md at the root and a v2.0-MIGRATION-GUIDE.md, indicates a project that is being changed and that expects users to track those changes.

The upgrade cost follows from that. A minor version bump is not guaranteed to be a drop-in. Budget for reading the changelog and re-running your example configuration after each upgrade, and pin the version in your own environment so an unattended pip install cannot move you. The container path reduces this cost somewhat because the Dockerfile pins a base image, but the base image tag itself is a version you will eventually have to move.

On licensing: the project is Apache-2.0, stated both in the repository metadata and in pyproject.toml as license = "Apache-2.0", and the source files carry SPDX headers naming NVIDIA Corporation & Affiliates. Apache-2.0 is a permissive licence with an explicit patent grant and a requirement to preserve notices and state changes. That is generally the permissive end of the spectrum, but the framework depends on a large third-party tree, and your obligations for those dependencies are governed by their licences, not this one. The repository does not document a licence audit of its dependency set, so run your own if that matters to your organisation. This is not legal advice.

## Conclusion

Adopt PhysicsNeMo if your team already trains PyTorch models on NVIDIA GPUs and your problem matches one of the domain recipes, because the value is in the components and example configurations more than in the training loop. Do not adopt it if you are CPU-only, if you need a stable API surface across releases, or if your workflow is a conventional CFD or FEA solver you have no intention of replacing with a learned surrogate. Before committing, verify three things: that a CUDA build matching your driver exists at the version you need, that the example closest to your physics actually runs on your data layout, and that the v2.0-MIGRATION-GUIDE.md changes do not touch the modules you plan to build on.

## FAQ

### What is PhysicsNeMo?

It is an open-source PyTorch framework from NVIDIA for physics machine learning, scientific machine learning, and AI for science and engineering. The README describes it as providing reusable library components and end-to-end training recipes.

### Is PhysicsNeMo free?

Yes. It is published on PyPI as nvidia-physicsnemo and licensed under Apache-2.0, which is stated in the repository metadata and in pyproject.toml. Your obligations for the large third-party dependency tree are set by those packages' own licences.

### How do I install NVIDIA PhysicsNeMo?

The README gives pip install "nvidia-physicsnemo[cu13]" for the CUDA 13 build, and points to its installation options section for CUDA 12, a basic install, optional features, or a source setup. The package requires Python >=3.11,<3.15.

### How do I use PhysicsNeMo?

The README does not give a single canonical first-run command. The practical route is the examples directory, which is organised by domain and indexed by examples/README.md, where each recipe pairs a configuration with a model and data pipeline. Start from the example closest to your physics.

### What is the difference between PhysicsNeMo and PhysicsNeMo Sym?

The repository publishes physicsnemo sym as a separate package, and people search for the comparison, but the README provided here does not document what distinguishes them. Check the documentation site for the scope of each before choosing.

## Sources

- [License: Apache-2.0](https://github.com/NVIDIA/physicsnemo/blob/main/LICENSE)
- [NVIDIA/physicsnemo on GitHub](https://github.com/NVIDIA/physicsnemo)
- [Project website](https://developer.nvidia.com/physicsnemo)
- [README](https://github.com/NVIDIA/physicsnemo/blob/main/README.md)
- [Releases](https://github.com/NVIDIA/physicsnemo/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/nvidia-physicsnemo