Open source has been a big part of the recent AI conversation. A vast majority of innovations over the past few decades have been powered by open source. Linux, Kubernetes, Postgres, the Hadoop ecosystem including Spark/Flink/Trino, and the various projects from the Apache Foundation define most people’s day-to-day cloud experience, and not to mention, power hundreds of billions of dollars in enterprise software. Much of what powers the modern Silicon Valley can be attributed to the power of open ecosystems. More recently, Hugging Face* has emerged as the community hub and standard toolchain for open machine learning. It is the place the field converges to share, discover, and run models.
How Luminary Builds with NVIDIA PhysicsNeMo
There has been growing interest in Physics AI, and one of the main factors that has been instrumental in that growth is the availability of NVIDIA PhysicsNeMo, an open-source framework for building, training and scaling physics AI models, it gives all companies in the ecosystem the ability to use it within their tech stacks and innovate on top of it. We at Luminary were among the earliest adopters of PhysicsNeMo, and over the past year we’ve used it extensively to build our own innovations on top of this layer. Let’s take a look at PhysicsNeMo and how we at Luminary have used it even as we build out new models such as Luminary-SMART.
PhysicsNeMo is an open-source, PyTorch-based framework for building, training, and deploying Physics AI models. Physics AI models are deep learning models that approximate or accelerate physical simulations. Traditional numerical solvers (CFD, FEM, ElectroMagnetics, Structures) are accurate but expensive, both from a computational perspective and in terms of the time it takes to run the simulation. PhysicsNeMo provides components for training neural networks that learn from simulation or observational data, incorporate governing equations, or combine both approaches. When trained and validated for a specific workload, these models can accelerate parts of simulation and engineering workflows.
How Physics AI Is Being Applied to Engineering Workflows
Northrop Grumman Space Systems is one such example. Designing spacecraft thruster nozzles required CFD runs of up to 12 hours each, which limited engineers to dozens of design variants per month. Luminary generated approximately 2,000 simulations and trained on the PhysicsNeMo DoMINO architecture, delivering a Large Physics Model that predicts nozzle performance in 2 to 5 seconds, about 3,000x faster than simulation, with a median error of 5.2%.
The same approach is now being applied to semiconductor thermal design, one of the most active new application areas for Physics AI. AI accelerators are increasingly thermally constrained, which limits how far the industry can push compute density. A thermal engineer choosing a cold plate architecture has to evaluate a vast design space: chip power maps across operating modes, thermal interface materials, fin topology, manifold slot placement, flow rate, and pressure drop limits. Running a conjugate heat transfer simulation for every combination is impractical, so teams evaluate a subset and over-design to cover the rest. Here, the workflow is to generate thousands of simulations across the parameterized design space, train a large physics model on a PhysicsNeMo architecture such as GeoTransolver, and give engineers predicted temperature, pressure, and flow fields for a new configuration without running a new simulation. Luminary has already applied this approach to cold plate design for EV battery packs with SHIFT-Battery.
What Is Included in PhysicsNeMo
Moving from a design space to a deployed model takes more than an architecture: the simulation data has to be loaded, training has to scale across GPUs, and the model has to respect the underlying physics. PhysicsNeMo provides each of these as a layer of the stack:
- Data pipelines (physicsnemo.datapipes): ETL tuned for scientific data structures: point clouds, meshes, structured grids, rather than the images/text the mainstream tooling assumes.
- Distributed training (physicsnemo.distributed): Built on torch.distributed, with a DistributedManager that scales single-GPU code to multi-node with minimal changes, plus ShardTensor for domain parallelism (sharding a single large physical domain across GPUs).
- Physics/PDE layer (physicsnemo.sym): Symbolic PDE residuals via SymPy with automatic spatial derivatives, so you can add physics-informed loss terms.
- Model architectures (physicsnemo.models): Optimized, ready-to-use implementations of the families that dominate SciML: neural operators (FNO, DeepONet, DoMINO, Transolver), graph nets (MeshGraphNet for mesh/Lagrangian data), diffusion models (CorrDiff, DDPM), transformers, and PINNs. You can use them off the shelf or compose your own from PhysicsNeMo layers plus raw PyTorch.
The diagram above shows the stack’s architecture layers. As we will see in a moment, a CUDA-native accelerated computing stack is a huge accelerator for any company looking to build a physics AI model using PhysicsNeMo as the substrate.
PhysicsNeMo Model Zoo
PhysicsNeMo ships a curated model zoo spanning the main physics-ML families, viz. neural operators (FNO, DeepONet), graph networks (MeshGraphNet), diffusion models (CorrDiff), and weather models (GraphCast).
The two most consequential for engineering-scale CFD are DoMINO and Transolver. DoMINO is NVIDIA’s Decomposable Multi-scale Iterative Neural Operator built for external aerodynamics. It works directly on large surface/volume point clouds, builds a multi-scale latent grid representation of the geometry over the domain, combined with ball-query neighborhood features at several radii for local detail, and predicts full flow fields over complex geometries (e.g., full vehicle bodies) in seconds rather than hours.
Transolver is a transformer-based PDE surrogate that learns physical states via attention over learned ‘slices’, soft groupings of points sharing physical states, making it fast and accurate on arbitrary meshes and geometries; GeoTransolver augments this with DoMINO’s sophisticated geometry representation via cross-attention to better capture complex boundary shapes. Together they represent PhysicsNeMo’s push toward general, geometry-flexible surrogates that scale to real industrial simulation problems.
Luminary builds on these open source models. A model in the zoo ships as an architecture and a training recipe. Getting one to run effectively on a customer’s geometry, at production scale, within an organization’s engineering workflows is what Luminary does: training on our own datasets, validating against solver ground truth, and adapting the architecture to the demands of a specific engineering team. AeroJEPA was added to the model zoo on July 15th, and Luminary is already building an enterprise-ready version of it.
How Luminary Uses PhysicsNeMo
Thanks to PhysicsNeMo, building a new model or pulling together data pipelines doesn’t require starting from scratch.
Luminary uses PhysicsNeMo’s capabilities to train new models.
The Dataset Layer
This is perhaps the most impactful and reusable layer of the PhysicsNeMo stack. Every machine-learning project has an unglamorous first step, viz. getting the data into a shape the model can actually consume. For images or text, libraries like torchvision or Hugging Face solved it years ago. For simulation data, it’s an ongoing issue, because a single “sample” isn’t a JPEG. It’s a whole engineering case: a mesh with hundreds of thousands of triangles, physical fields defined at each cell (pressure, velocity, wall shear stress), a handful of global parameters like Mach number and angle of attack, and metadata about how the case was set up. That bundle is typically split across several files, in several formats (VTK, HDF5, NetCDF, and Luminary’s own LCN), and typically lives in cloud storage rather than on a local disk. In Luminary, this data lives in the Luminary Data Lake.
Multiply that by hundreds of cases, and just loading the training set becomes a real engineering problem. PhysicsNeMo solves this issue in its base class called CAEDataset (Computer-Aided Engineering Dataset). It’s the piece that turns “a folder full of messy simulation files” into “a Python object you can iterate over in a training loop”. Under the hood, CAEDataset handles the things you’d otherwise write from scratch on every project:
- Cloud-native paths, a Luminary addition on top of CAEDataset: a training script written for gs://luminary-datasets/shiftwing/ also works against a local /mnt/data/shiftwing/ mount, without changing a line. That matters because these datasets are often hundreds of gigabytes and don’t typically live on laptops.
- Format-agnostic readers for all the file formats a simulation case spans.
- Normalization scaffolding. Neural networks want inputs roughly centered around zero with unit variance. CAEDataset computes the normalization statistics once over the training set, saves them alongside the model artifact, and reuses them at inference time, so predictions come back in real physical units. This sounds mundane, but forgetting it is the source of a large number of physics-ML bugs.
- Fixed-shape sampling so cases with different mesh sizes can still be batched together. If Case A has 173,000 points and Case B has 208,000, the dataset subsamples both to, say, 16,000 points using uniform or Poisson-gap sampling.
- Distributed-training hooks that work in two modes: the ordinary “split the cases across GPUs” pattern, and the harder “one case is too big for one GPU, split the case itself” pattern (this is where ShardTensor comes in, which we discuss below under Domain Parallelism).
- Per-file caching so you don’t re-download from cloud storage every epoch, which translates into a difference between “training runs in three hours” and “training runs in three days and costs a fortune in egress.”
The elegance of the design is how little code you have to write yourself: nothing except a single method i.e., _load_sample(index), which returns the tensor dictionary your model wants. Everything else is inherited.
For example, when we built Luminary-SMART, we didn’t need to build our own dataset class. SMART reuses GeoTransolver’s TransolverDataPipe (which uses CAEDataset) as is. This works because SMART’s inputs happen to look exactly like GeoTransolver’s inputs: a surface point cloud, per-face physical targets (pressure and wall shear stress), and a small global-parameter vector. We didn’t have any signed distance fields to compute, volume fields to load, or bespoke tensor shapes. As a result, SMART shipped with zero SMART-specific data pipeline code. All the effort went into the model architecture rather than re-plumbing the same read-and-normalize logic for yet another model.
Domain Parallelism
physicsnemo.domain_parallel.ShardTensor and scatter_tensor implement domain parallelism. When a single CFD training sample (for example, a 200k-point surface cloud plus its multi-resolution SDF grids) is too large to fit on one GPU, scatter_tensor slices the sample across ranks at load time, and ShardTensor acts as the transparent handle that lets subsequent model ops read the remote pieces over NCCL as if the tensor still lived on one device. Domain parallelism enables CFD because it lets training samples be arbitrarily large without requiring manual parallelism management.
And since we are training large physics models, we are talking about thousands of training samples and running the training loop thousands of times, and not having to worry about parallelism or GPU optimization allows the model trainer to focus less on the training infrastructure and more on the model architecture and accuracy. As datasets grow, it becomes impossible to train large physics models without domain-parallel capabilities like those you get out of the box with PhysicsNeMo.
DistributedManager
physicsnemo.distributed.DistributedManager is a singleton wrapper around torch.distributed. The distributed training capabilities in DistributedManager let us set up distributed training in an easy, repeatable way. Since our goal with Physics AI models is to build self-improving models where inference results determine data augmentation to improve model accuracy, the underlying framework is an important part of the equation.
Think of DistributedManager as the answer to five questions that the training script needs to know but shouldn’t hard-code:
- Who am I globally? → rank
- Who am I on this box? → local_rank
- How many of us are there? → world_size
- Which GPU do I own? → device
- Has NCCL been initialized? → (implicit; done in the constructor)
Everything SMART’s trainer does with PhysicsNeMo is answering one of those five questions. Consistent answers from DistributedManager set up SMART’s training loop to run consistently with the performance it delivers.
Building on PhysicsNeMo
Over the years, conventional wisdom has converged on the fact that in the long run, open ecosystems win. We have seen that in almost every product class, from operating systems to databases to cloud software systems. More recently, we are starting to see that with frontier models. It is just a matter of time before the open models catch up with the closed-source frontier models for most meaningful tasks.
In each case where open source has emerged as a winner, it starts with a solid product that is made available for open innovation, a community of developers who are vested in the success of the project, a license that is innovation- and adoption-friendly, and a governance framework that ensures that the project is driven by meritocracy and a shared vision, devoid of single-company control. Every winning open source effort has also produced fast innovators who extend the bounds of what is possible with the product and bring enterprise readiness to customers seeking to deploy it across the enterprise.
We believe PhysicsNeMo has similar potential and all the right ingredients to succeed. We also believe that we offer the most enterprise-ready implementation of this stack that supports architectures, supports model-independent Out-of-Distribution Detection and Uncertainty Quantification, as well as the ability to continuously update it to keep it secure and compliant for our highly sensitive customers. PhysicsNeMo provides an open-source framework for building, training, and scaling physics AI models. The work we do is built on that foundation: trained and validated models such as Luminary-SMART and our enterprise version of AeroJEPA, the data lake and training pipelines that keep producing them, and the platform that lets an engineering team run them against their own geometries.
And we intend to keep being part of what could be the winning hand for Physics AI.
*Hugging Face: On Sept. 3, 2026, NVIDIA announced an agreement to acquire Hugging Face, once again highlighting the importance of open ecosystems.
