Where OpenUSD Digital Twins Meet Working Physics

An OpenUSD asset says what a coolant distribution unit is. A physics model says how it behaves—this is the bridge between them, walked end-to-end by an AI agent.

Picture a steel cabinet the size of a wardrobe, tucked into a row of AI servers, with two separate water loops threading through it—one tied to the building’s chillers, the other touching the servers themselves—that must never mix. Its entire job is to move more than a megawatt of heat silently, from the server-side loop into the facility loop, across a thin wall of metal. In 3D, it’s just a box with pipes. But that model can’t answer the question the whole thermal budget hinges on. Can it shift 1.2 MW between those loops while holding each at the temperature the equipment demands? Geometry describes what a thing is. It says nothing about how it behaves. This is the story of how we taught that gap to close itself—feeding a cooling unit’s OpenUSD data straight into Modelon Impact’s physics engine, and letting an AI agent do the translation, the modeling, and the validation in a single sitting.

What is OpenUSD?

OpenUSD (Universal Scene Description) started life inside Pixar as the pipeline glue for animated films; a way to let hundreds of artists work on the same colossal 3D scene without stepping on each other. In 2023, it was handed to the Alliance for OpenUSD (AOUSD), with founding members including Pixar, Adobe, Apple, Autodesk, and NVIDIA, and it has since become the de-facto open standard for describing complex 3D worlds.

The easiest way to think about it: OpenUSD is to 3D what HTML is to documents—a common, open format that any tool can read and write. But USD’s real superpower isn’t the geometry. It’s composition. Scenes are assembled from layers, references, and payloads that combine non-destructively, so a rack, a row, a cooling loop, and an entire facility can be built up like transparencies stacked on a light table—each owned by a different team, each swappable, none overwriting the others.

Most importantly for engineers, USD can be extended with custom data. Through custom schemas and attributes, a USD asset can carry far more than shape and material. In the NVIDIA AI-factory assets we worked with, the cooling equipment definitions carried real engineering metadata: nominal capacity, coolant flow rates, supply and return temperatures, approach temperatures, even pump specifications. The 3D model had grown a spec sheet baked into its DNA.

Why is the Whole World Converging on It?

OpenUSD adoption isn’t hype; it solves expensive, chronic problems:

• Interoperability without lock-in. Every CAD, DCC, and simulation tool speaks its own dialect. USD is the neutral interchange that ends the endless, lossy export/import dance.
• A single source of truth. One composed scene, referenced everywhere, instead of a dozen diverging copies drifting out of sync.
• Composability at industrial scale. Layering and referencing let teams collaborate on assets far too large for any one file; the same trait that made it work for feature films makes it work for gigawatt-scale facilities.
• The foundation for digital twins. NVIDIA Omniverse and the broader “AI factory” movement use OpenUSD as the connective tissue for industrial digital twins; factories, warehouses, and now the AI data centers being built at breakneck pace.
• A carrier for more than pixels. Because schemas are extensible, USD is quietly becoming a container for engineering intent; thermal, electrical, and airflow connection points, not just triangles.

That last point is where it gets interesting for anyone in modeling and simulation. If the specification travels inside the 3D asset, then the asset is one translation away from becoming a physics-ready digital twin.

The Missing Half: Geometry Describes, Physics Predicts

Here’s the catch. A USD asset can tell you a CDU (Coolant Distribution Unit) is rated for 1.2 MW at a 35 °C facility-water supply. It cannot tell you the return temperature on each loop under load, whether the specified 10 K approach temperature holds, or how much heat truly crosses the exchanger between the facility and technology loops. Those are emergent, physical behaviors; the domain of a dynamic simulation engine.

Modelon Impact is exactly that engine; and it is where the FMI story happens. Built on the open Modelica language and the Functional Mock-up Interface (FMI), both stewarded by the Modelica Association, Impact is where physics models are authored, compiled directly into FMUs; the portable simulation units at the heart of FMI; and then simulated and coupled natively in the same tool. Creating, parameterizing, and running FMUs isn’t an add-on to Impact, it is what Impact does.

Just as important is what Impact brings pre-built: validated, industry-specific component libraries. Its Data Center Library provides calibrated models of racks, coolant distribution units (CDUs), CRAHs, chillers, and cooling loops; including vendor-calibrated CDU families such as the Vertiv Liebert XDU series. That library is years of thermo-fluid engineering and vendor performance data encoded as ready-to-use, physically validated components—the trustworthy raw material a credible digital twin must be built on. So the opportunity is a clean pairing of two open standards. OpenUSD carries what the equipment is, Modelica/FMI computes how it behaves. The only thing missing was the bridge—and building that bridge by hand is tedious, error-prone spec-transcription work. That’s the job we handed to an agent.

The Integration Workflow: What We Built

We took a real NVIDIA asset; the Generic CDU from the Omniverse AI-factory pipeline samples, a 1,200 kW in-row coolant distribution unit, and drove it all the way to a validated physics model with Claude operating Modelon Impact through its programmatic interface. It’s worth being precise about who does what. Modelon Impact supplies the physics: the validated Data Center Library, the Modelica compiler, and the native FMU and simulation engine. The agent supplies the orchestration: reading the spec, choosing and parameterizing the right model, running it, and checking the answer. Neither half is sufficient alone; an agent without validated models would be guessing physics, and the models without an agent still need slow, error-prone manual setup. The CDU is the perfect subject—a component whose entire purpose is behavior—moving heat between two water loops that never touch. Working through Impact, the agent ran the whole chain:

• Read the USD engineering data. From the asset’s property definitions, it extracted the nominal operating point: 1,200 kW cooling capacity, 35 °C facility-water (FWS) supply, 45 °C technology-coolant (TCS) supply; a 10 K approach; 12.5 kg/s technology flow, dual facility pumps at ~18 kg/s, and a 30% propylene-glycol/water coolant.
• Made a real modeling judgment powered by Modelon’s library. The agent did not invent CDU physics, it chose from Modelon Impact’s catalogue of vendor-calibrated CDU models. Because that library documents each model’s facility-water class, calibration status, and form factor—and Impact’s interface and documentation expose them in a structured, query-able way—the agent could pick the Vertiv Liebert XDU1350 W3 as the closest fully-calibrated match to NVIDIA’s 35 °C spec (W3 is 32 °C, just 3 K off) and configure it in-row. The judgment came from the agent. The validated references and the metadata that made them selectable came from Modelon.
• Authored the model in Modelon Impact’s record → model → experiment structure. A record encoding the USD nominal point, a model wrapping Modelon’s data center CDU with that record, and an experiment imposing both loops’ boundary conditions from the spec; all standard Impact constructs the agent filled in rather than invented.
• Compiled to an FMU, simulated, and validated—all inside Modelon Impact. Impact compiled the parameterized model straight to an FMU and ran it to steady state in the same environment; the agent then checked the results against the datasheet:
  

The unit moved 1.19 MW; 99% of its rated duty; pulling the server-side loop from 69 °C back down to its ~45 °C supply while lifting the facility water from 35 to ~52 °C, with both flows exactly as specified. A datasheet turned into predictive physics: the trustworthy numbers came from Modelon Impact’s validated model and solver, while the agent supplied the transcription, the model selection, the debugging, and the verification.

It even wrote the report and captured the lessons. The agent generated a branded PDF of the validation and wrote the reusable patterns back into a shared engineering knowledge base; so the next asset is faster than the last.

Why This Changes the Modeling & Simulation Workflow

• From days to minutes. The path from “here’s a 3D asset with specs” to “here’s a validated physics model” traditionally means an engineer reading a datasheet and hand-building a model, compressed into a single agent-driven session.
• The digital twin becomes physics aware. A twin you can interrogate (“What’s the return temperature at full load?”) not just one you can look at.
• Fewer transcription errors. Specs flow from the asset into the model programmatically, not by hand.
• Validated physics, on tap. The output isn’t a one-off script—it’s a model built on Modelon Impact’s maintained, vendor-calibrated Data Center Library and run on its FMI-native engine, ready to compose into a larger facility simulation. The credibility comes from the library; the speed comes from the agent.
• Institutional knowledge compounds. Every run leaves behind reusable mappings and gotchas (pitfalls), so expertise accumulates instead of walking out the door.

The deeper shift is a division of labor. Modelon Impact brings the trusted physics; validated models, a Modelica compiler, and a native FMU and simulation engine; and the agent brings the orchestration that used to be slow, manual work. Engineers move up the value chain, from hand-building models to directing the modeling and owning the judgment, on top of an engine whose answers they can trust.

The Bigger Picture: Where This is Heading

This unassuming steel cabinet is a preview of three converging trends:

1. The executable digital twin. 3D + physics + AI is collapsing into twins that are simultaneously visual, predictive, and interactive—the backbone of the “AI factory” vision.
2. Standards pairing up. OpenUSD (geometry/scene) and Modelica/FMI (physics) are becoming complementary open layers, and tools that already live in both, like Modelon Impact with its native FMU authoring and simulation, are where the two standards meet.
3. Agentic engineering. AI agents operating professional tools through structured protocols— reading standards, authoring models, running validations—turn simulation from a specialist bottleneck into an on-demand capability.

And it’s landing at exactly the right moment. AI data centers are being built faster than the grid can feed them—liquid cooling is going from exotic to mandatory—and regulators (EU Energy Efficiency Directive, Germany’s EnEfG) are making energy and water efficiency reportable obligations. A workflow that turns a cooling unit’s 3D asset into a validated thermal model, and ultimately a PUE and efficiency estimate, isn’t a novelty. It’s fast becoming table stakes.

The question is no longer whether your digital twin looks right. It’s whether it can tell you the truth about how it will behave before you build it.

Pratyush Agarwal