NVIDIA PhysicsNeMo: a PyTorch framework for physics ML, judged on what the repository actually shows
Open-source deep-learning framework for building, training, and fine-tuning deep learning models using state-of-the-art Physics-ML methods
At a glance
- What is it?
- PhysicsNeMo packages reusable PyTorch components and end-to-end training recipes for scientific machine learning. The examples span aerodynamics, weather, semiconductor packaging, crash dynamics and cardiovascular flow, but the material available here does not settle how much of that runs on a single workstation GPU.
- Who is it for?
- PhysicsNeMo fits teams already working in PyTorch who have a physics dataset and want a starting point rather than a blank repository, particularly where the domain matches one of the shipped examples. It is a poor fit if you only have a CPU-only machine, if your problem has no geometry or mesh component, or if you need a framework that stays stable across minor versions while you run long-lived training jobs.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap PhysicsNeMo is trying to fill, and who still falls outside it
Physics machine learning sits between two communities that rarely share tooling. A CFD or structural mechanics group has solvers, meshes and simulation output, but not a training loop. A machine learning group has the training loop but no intuition for boundary conditions or mesh connectivity. PhysicsNeMo positions itself as the layer that closes that distance: an open-source PyTorch framework for physics ML, scientific machine learning and AI for science and engineering, offering reusable library components plus end-to-end training recipes. The README frames it as a way to build, train and scale physics AI models with PyTorch.
The target reader is someone who already writes Python and already knows PyTorch. Nothing in the repository suggests a no-code or low-code path. If your team cannot read a training script and modify a dataloader, the examples will not help you. The second condition is data. Every example listed in the README is a surrogate modelling or inverse problem task: predict pressure and wall-shear-stress fields, forecast regional weather, predict an advancing epoxy interface, predict crash deformation, invert for subsurface velocity. All of them assume you have simulation output or observations to train against. PhysicsNeMo does not generate that data for you.
What the example catalogue reveals about the intended scope
The README organises demonstrations into domain pairs, and the pairing is more informative than a feature list would be. Aerodynamics appears as a unified external aerodynamics recipe that trains and compares surface and volume models, with an active learning variant using GeoTransolver on a held-out ShiftSUV case. Weather appears as StormCast, described as generative regional weather forecasting. Semiconductor packaging appears as underfill dispensing, a transient epoxy-interface prediction with GeoTransolver. Structural mechanics appears as crash dynamics, transient surrogates on deforming meshes. Geophysics appears as Diffusion FWI, guided generative full-waveform inversion. Healthcare appears as cardiovascular flow, reduced-order prediction with MeshGraphNet. Two further entries cover data-center thermal design and additive manufacturing.
Two architectural families recur across those entries. GeoTransolver shows up in aerodynamics and in underfill dispensing, which suggests a geometry-aware transformer backbone intended to generalise across mesh-based problems. MeshGraphNet shows up in cardiovascular flow, which points to graph neural networks over mesh connectivity. Generative approaches appear separately in StormCast and Diffusion FWI. That split matters when you are choosing a starting point: a diffusion-based recipe and a graph-network recipe have very different inference costs and very different failure behaviour, and the README does not compare them on that axis.
Installation: one command, and a CUDA decision you have to make first
The README gives a single install line for the CUDA 13 path:
pip install "nvidia-physicsnemo[cu13]"
The package name on PyPI is nvidia-physicsnemo, which differs from the project name used everywhere else in the documentation. That mismatch is the first thing to get right in a requirements file or a container build. The README then points to an installation options section for CUDA 12, a basic install, optional features, and source setup. Those options are not reproduced in the material available here, so the exact extra names for CUDA 12 cannot be confirmed from what is given. Treat the cu13 extra as the only verified install variant and read the linked section before pinning anything.
The bracketed extra is doing real work. It implies the base install does not pull in the CUDA-specific dependencies, and that a plain pip install nvidia-physicsnemo gives you a different, presumably CPU-oriented or dependency-light environment. For a team building a container image, that distinction determines image size and whether the build needs network access to NVIDIA package indexes. The repository also carries an install CI workflow, which suggests install paths are exercised automatically, though the material here does not describe what that workflow covers.
Where the documentation is thin enough to be a planning risk
The README is a showcase page, not a reference. It links to a documentation site, a models API page, an examples index, a blog and a discussions forum, but the material available here does not include the contents of any of those. That leaves several questions open that matter before adoption.
First, hardware floor. The topics list includes nvidia-gpu and nvidia-warp, and every example is a physics simulation surrogate, which typically means large meshes and long training runs. Nothing in the supplied material states a minimum GPU, a memory requirement, or whether any example runs end to end on a single device. Second, version stability. Three releases are listed in roughly six months: v2.1.1 in June 2026, v2.2.0 in late August 2026, and v2.2.1 a few days later. A patch release four days after a minor release is ordinary, but the cadence itself tells you the API surface is still moving. If you fork an example and adapt it, budget for re-reading that example after each minor bump. Third, the models page is referenced but not shown, so the catalogue of pretrained checkpoints and their licences cannot be assessed from this material. That last point is the one I would resolve before writing any code.
The GPU dependency is the constraint that decides most adoption questions
PhysicsNeMo is not a general-purpose deep learning framework and does not pretend to be. It is a domain layer that assumes an NVIDIA GPU and, given the nvidia-warp topic, likely assumes Warp for at least some kernels. That is a reasonable design for the stated audience, and it is also the sharpest limitation.
Consider a research group with a single workstation, a modest GPU, and a mesh dataset of a few thousand cases. The framework will install and the examples will import, but the recipes are written for the scale the README photographs imply: full-vehicle crash deformation, regional weather rollouts, patient-specific vessel trees. Adapting a recipe downward is possible in principle, yet the material gives no guidance on which components degrade gracefully and which assume multi-GPU or multi-node execution. A team in that position gets more value from a plain PyTorch training loop plus a graph network library than from a framework whose examples it must first shrink.
The second wrong-tool case is a problem with no geometry. If your inputs are tabular sensor readings or time series without spatial structure, the geometry-aware components that distinguish PhysicsNeMo from generic PyTorch are dead weight. You would be adopting a dependency for its dataloaders alone.
How it compares with building on raw PyTorch plus a graph network library
The realistic alternative is not another physics ML framework. It is assembling the pieces yourself: PyTorch for the training loop, PyTorch Geometric or the Deep Graph Library for mesh and graph convolutions, and your own code for physics-specific losses, boundary condition handling and rollout evaluation. That path costs more upfront engineering and buys control.
The difference in approach is where the abstraction sits. PhysicsNeMo abstracts at the recipe level. You get a working training configuration for external aerodynamics or crash dynamics, and your job is to point it at your data and adjust. The raw-PyTorch path abstracts at nothing: you decide the message-passing scheme, the loss weighting between data and physics terms, the rollout strategy for transient problems, and the checkpoint format. For a team that intends to publish methodological work, that control matters, because a reviewer will ask why a particular graph network was chosen and a recipe default is a weak answer. For a team that needs a surrogate model in production next quarter, the recipe is the better starting point and the control is a distraction.
There is a middle position worth naming. Take a PhysicsNeMo example as a reference implementation, read it, and reimplement the parts you need in plain PyTorch. That gets you the design knowledge without the version-coupling risk, at the cost of not benefiting from upstream fixes.
Licence and maintenance: what Apache-2.0 covers and what it does not
The repository is Apache-2.0, which permits commercial use, modification and redistribution provided you retain the licence and notice files and comply with the patent grant and termination clauses. That is the framework code. The material available here does not state the licence terms for any pretrained checkpoint referenced by the models page, and those terms are frequently different from the code licence. If your plan is to fine-tune a shipped checkpoint rather than train from scratch, resolve that separately. This is not legal advice; read LICENSE.txt and the checkpoint terms yourself.
Maintenance cost has two components. The direct one is upgrade work: with three releases in about six months, expect to re-validate your adapted example after each minor version. The indirect one is dependency drift. A framework that sits on top of PyTorch, CUDA-specific wheels and Warp inherits the upgrade pressure of all three, and the cu13 extra means a CUDA toolkit decision is baked into your environment. Pin the package version and the extra in your lockfile, and treat a CUDA bump as a planned migration rather than a routine update. The install CI workflow exists, which is a signal that install breakage is caught upstream, but the supplied material does not describe its coverage.
Editorial conclusion
PhysicsNeMo fits teams already working in PyTorch who have a physics dataset and want a starting point rather than a blank repository, particularly where the domain matches one of the shipped examples. It is a poor fit if you only have a CPU-only machine, if your problem has no geometry or mesh component, or if you need a framework that stays stable across minor versions while you run long-lived training jobs. Before committing, verify which CUDA extra your driver supports, check whether the example closest to your problem still matches the current API surface, and read the LICENSE.txt terms for the specific model checkpoints you intend to fine-tune.
Community notes