Engineering monograph · Physics & machine learning
A plain-words, comprehensive guide to the physics-AI tools: what they are, how they learn, how to put them inside an agent that catches faults and predicts failures, what each one costs, the hardware you need, and a glossary for every term.
Some AI does not chat. It learns to imitate a physics simulator so closely that it answers in milliseconds what used to take a supercomputer hours. NVIDIA has built a full ladder of these tools, from a fast engine at the bottom to ready-made models at the top.
This guide explains every rung in everyday language, shows how a software agent can lean on them to watch a machine and predict when it will fail, and lays out plainly what is free, what is paid, and the hardware you need. Read it top to bottom, or jump to any section. A glossary at the end defines every piece of jargon the moment you need it.
When people say "AI that understands physics," they usually mean one of two very different things. Keeping them apart is the whole game, because they fail and succeed in opposite ways.
The first kind is a reasoner. A large language model reads your problem in plain English, recognizes that it is, say, a spring-mass-damper or a second-order system, writes down the right equations, and explains the method step by step. It is excellent at framing a problem and choosing an approach, because it has read millions of worked examples. It is poor at being the calculator. Ask it for an exact settling time or a specific eigenvalue and it will hand you a confident, often wrong, number, because underneath it is predicting plausible text, not running arithmetic.N1
The second kind is a surrogate. This is not a language model at all, and it does not use words. It is a network trained to copy the input-to-output behavior of a real physics solver. You feed it the same kind of inputs the slow solver would take, a shape, a set of conditions, a load, and it returns a close answer almost instantly. It does not reason about the problem. It has simply seen so many already-solved cases that it can fill in a new one by interpolation, the way you can guess a person's weight from their height without a formula if you have seen enough people. Everything NVIDIA ships under the "physics-AI" banner is this second kind.
Imagine asking both about a motor: "what temperature will this winding reach after ten minutes at full load?" The reasoner will correctly tell you it is a heat-balance problem, name the equation, and explain that the answer depends on losses and cooling, then guess a number you should not trust. The surrogate, if it was trained on thermal simulations of motors like this one, will return an actual temperature field in milliseconds that is usually close to what the slow solver would have produced. Neither is "smarter." They are different machines for different jobs.
There is also a third, newer idea worth naming: a world model, an AI trained to predict how a whole scene changes over time, used mostly to generate practice data for robots. It sits closer to the surrogate family than the reasoner, and NVIDIA's version is called Cosmos. We will meet it briefly in the products section, but the two-way split above is the one to keep in your head.
The physics-AI offerings are not one product. They are four layers that build on each other, from raw physics math at the bottom to ready-to-use models at the top. Each layer hides the messiness of the one below it.
A kitchen analogy: the engine is the stove and knives that do the actual cooking, the simulation world is the kitchen with its lighting and layout, the framework is the set of recipes and techniques for inventing new dishes, and the model shelf is the freezer of ready-made meals you just heat up. You can cook from scratch or grab a finished dish; most people do some of both.
The useful mental line runs through the middle of the stack. The bottom two rungs compute physics directly: they are engines and simulators that solve the equations, step by step, the honest slow way (just very fast, on a GPU). The top two rungs imitate physics: they are machine-learning models, and the toolkit that trains them, that learned to skip the step-by-step work and jump to the answer. Marketing blurs this line. The engineering does not, and confusing the two is how people end up trusting a guess where they needed a calculation.
A digital twin is a living simulation of a specific real thing, a particular motor, factory, or river, kept in sync with sensor data so you can test changes on the copy before touching the real one. OpenUSD is the shared file format that lets all these tools describe the same 3D scene and pass it around without translation, the way PDF lets any program open the same document. Both show up across the top three rungs.
Two ingredients go in, a fast predictor comes out. The clever part is forcing the network to respect physics, not just memorize examples, so it stays sensible in situations it has not seen exactly.
Step one is gathering examples. You run the slow, trustworthy solver (or collect real sensor readings) for many different inputs, and you save each input together with the answer it produced. This is the training data: thousands of solved cases. Step two is showing those cases to a network over and over until it can predict the answer for an input on its own. Step three, the one that makes this physics-AI rather than plain curve-fitting, is the physics penalty: during training the network is also scored on whether its predictions obey the governing equations, not just whether they match the saved answers. That extra pressure keeps it honest in the gaps between the examples it saw.
Not all surrogates are built the same way. Three designs do most of the work, and they suit different problems. Tap through them below.
Whichever family you use, the trained surrogate carries a quiet risk: it is only as good as the range of examples it saw. If you ask it about something far from its training cases, it will still answer, confidently, and it may be wrong. Good practice is to train an ensemble, several surrogates instead of one, and watch how much they disagree. Wide disagreement is the model's way of admitting it does not know, which gives you an honest uncertainty band instead of false precision. The next section is about exactly this edge.
A surrogate is a brilliant deal right up to the edge of what it was trained on. Past that edge, you go back to the real solver. This single trade-off decides how you use the whole stack.
Why does a surrogate fail outside its training range? Because it never learned physics in the way a textbook teaches it. It learned the shape of the answers across the examples it saw. Inside that range, filling in a new case is interpolation, which networks are very good at. Outside it, the network is extrapolating, guessing beyond the edge of its experience, and there is nothing holding it to reality. The physics penalty helps, but it does not fully rescue a model asked about conditions it has never encountered.
The discipline is simple to state. First, before trusting a surrogate, check that the question sits inside its training range; if it does not, fall back to the real solver. Second, use the surrogate for the wide, cheap search, screening thousands of candidates, then confirm only the handful of survivors with the slow, exact solver. Third, prefer surrogates that respect conservation laws (energy in equals energy out, mass is not created or destroyed), because a model that can quietly break those will mislead you in ways that are hard to spot. The agent that drives all of this sits outside the simulation and calls it as a tool; it never lives inside the thing it is supposed to check.
The names map cleanly onto the stack. Here they are in order, with what each one actually is, who uses it, and where it fits.
This is the foundation tool for building and training your own surrogates. It is open-source and built on PyTorch, the most common framework for machine learning, so it slots into work people already do. It does not hand you finished answers; it hands you the parts: ready-made versions of the three network families, the physics-penalty machinery, and the plumbing to train across many GPUs at once. Its name has changed twice, from SimNet to Modulus to PhysicsNeMo, which is why you will see all three in older articles.N4 Think of it as the bench where surrogates are made. Outside groups already use it in production; one example is a chip-design company speeding up heat simulation of processors.
Announced in November 2025, Apollo is a family of pre-trained physics models you can pick up and use straight away, or fine-tune on your own data so they fit your exact problem. It spans six areas: chips and semiconductors, structural mechanics (how things bend and break), weather and climate, fluid dynamics (air and liquid flow), electromagnetics (antennas, interference), and multiphysics, where several effects interact at once, such as plasma and fusion. Under the hood the models mix the best current designs: neural operators, transformers, and diffusion models. If PhysicsNeMo is the workshop, Apollo is the shelf of ready-made imitators, and several large engineering and chip companies have started building on them.
Earth-2 is a planet-scale weather and climate twin. Its two stars are FourCastNet, a global forecaster built on a Fourier-style neural operator that predicts the whole atmosphere fast, and CorrDiff, a generative model that takes a coarse, blurry forecast and sharpens it into fine local detail, the way an editor turns a rough sketch into a clean drawing. In early 2026 the Earth-2 model family was opened up further and folded in outside models from groups like Europe's ECMWF, Microsoft, and Google. Insurance and energy-risk firms use it to simulate thousands of storm scenarios cheaply, which is too expensive with traditional forecasting alone.
Omniverse is the photorealistic, real-time simulation world where digital twins live, and Isaac Sim is its robotics edition, a virtual lab where robots can be tried and trained safely before touching real hardware. Underneath, the physics is computed by PhysX, and increasingly by Newton, a newer open engine built by NVIDIA together with Google DeepMind and Disney Research and handed to the Linux Foundation in 2025. Newton matters to anyone building a simulation sandbox because it is differentiable: you can ask it not only "what happens?" but "how would the outcome change if I nudged this input?", which lets you optimize a design or tune a controller by following that gradient, instead of trying options blindly.
One more name you may hear: Cosmos, NVIDIA's world model, generates realistic practice footage so robots can learn from far more situations than you could film in real life. It feeds the simulation world rather than replacing the surrogates, so it sits alongside this layer rather than on the shelf above.
Now put the stack to work. In Prognostics and Health Management (PHM), the job is to watch a machine, catch faults early, and predict how long it has left. A surrogate makes two slow loops fast enough for a software agent to run them continuously.
The core move is to treat a trained surrogate as a fast forward model, a tool the agent can call whenever it needs to know "what should be happening right now?" A surrogate that predicts a machine's temperatures or magnetic fields in milliseconds turns diagnosis and life-prediction from overnight jobs into something the agent can run thousands of times before it commits to a single decision. The agent itself is the language model: it decides what to check, calls the surrogate as a tool, reads the result, and explains it. It does not do the physics; it orchestrates it.
Start with a healthy-baseline surrogate, a model trained on the machine when it was working correctly. Run it alongside the real machine, feeding it the same conditions. The residual, the gap between what the sensors measure and what the healthy model predicts, is the anomaly signal. When the machine is healthy the residual is small noise. When something changes, the residual grows and develops a telltale pattern.
Detecting that something is wrong is the easy half. Naming what is wrong is fault isolation, and this is where the cheap surrogate earns its keep. The agent forms a short list of suspects, a worn bearing, a shorted winding turn, a failing power switch, a blocked coolant path, and simulates each one on the surrogate to see which produces a residual pattern that matches reality. The closest match is the likely cause. Because each simulation is nearly free, the agent can test many faults at many severities instead of guessing once. When two suspects fit equally well, that genuine ambiguity becomes a human-in-the-loop checkpoint or a request for one more specific measurement, rather than a coin flip.
Prognosis is forecasting how much useful life remains, often called remaining useful life, or RUL. First the agent tunes the surrogate to match the machine's present, slightly degraded state, a step called data assimilation. Then it rolls that tuned model forward in time under the loads the machine is expected to see, watching the damage grow. Run this once and you get a single guess. Run it across a spread of plausible future workloads, which the speed of the surrogate makes affordable, and you get a distribution: not "it will fail in 40 days," but "it will most likely fail in 35 to 50 days, and here is the chance it goes sooner." That honest confidence band is far more useful for planning maintenance than a lone number.
Everything from Section 04 applies here. Before the agent trusts the surrogate, it checks that the machine's current operating point sits inside the surrogate's training range. Outside it, the agent falls back to the real solver or flags the case for a human. Pairing the surrogate with an ensemble gives the life estimate an honest uncertainty band rather than false precision. These checks are not optional polish; they are what separates a useful health monitor from a confident liar.
The toolkit mapping: build the field surrogates in PhysicsNeMo, warm-start from an Apollo structural or electromagnetics family, serve the surrogate behind an inference endpoint the agent calls, and use Newton or Warp as the differentiable substrate. Plain control questions, the transient and steady state of a given system, still go to a real control solver, because that is exact and cheap. The surrogates earn their place only where the honest alternative is an overnight run.
The pattern across the whole stack is the same: the software and the model weights are mostly free, and you pay only when you use the optimized production-serving layer or redistribute the closed runtime.
A few terms make the pricing readable. Inference means running a trained model to get answers (as opposed to training it in the first place). NIM is NVIDIA's pre-packaged way of running a model for production, a container with the model and a fast engine already wired together behind a standard interface. The Open Model License is the permissive license most of NVIDIA's downloadable model weights ship under, which allows commercial use. And NVIDIA AI Enterprise is the paid support-and-license subscription you need to run NIM in production. With those in hand, the table below reads cleanly.
The one recurring price is the production license, which is charged per GPU. There are two ways to pay it: a yearly license per GPU, or an hourly rate per GPU when you rent cloud GPUs. Which is cheaper depends entirely on how many hours a day you actually run. The estimator below does the arithmetic; slide it to your situation.
All of it runs on NVIDIA GPUs. That dependency, not the licensing, is the real lock-in. Two terms first, then what each tool needs, then a ladder from a laptop to a server.
CUDA is NVIDIA's software layer that lets programs run on its GPUs; "CUDA-capable" simply means an NVIDIA graphics card. VRAM is the memory on that card, and it is usually the limit that bites first: a model or a scene either fits in VRAM or it does not. Bigger jobs need more VRAM, which is the main reason data-center cards cost what they do. It also helps to know that training a model is far heavier than running a finished one, so you can serve a trained surrogate on modest hardware even if training it took a cluster.
For building and training surrogates, PhysicsNeMo needs a CUDA-capable NVIDIA GPU on Linux and scales from a single GPU to multi-node clusters; serious training wants data-center cards. For serving pre-trained models such as Apollo or the Earth-2 models, the packaged inference layer supports data-center GPUs including H100, H200, A100, and L40S, with post-GTC-2026 profiles for the newer Rubin generation, and also runs on RTX workstations and PCs.
For the simulation world, Isaac Sim and Omniverse require an RTX GPU because of the ray-traced rendering, with 8 GB of VRAM as a floor and much more for complex scenes, on Windows or Linux. Newton and Warp need an NVIDIA GPU and run from Python.
The practical takeaway: you can go a long way on a single good workstation. You only need the expensive hardware when you move from building and testing to training at scale and serving many requests at once. Renting that hardware by the hour in the cloud is a common middle path, so you are not forced to buy a server before you know you need one.
Every piece of jargon in this guide, in one sentence each. Tap a term.