Building an AI factory digital twin requires developers to bring site plans, equipment assets, and engineering requirements into a consistent model that teams can inspect, revise, and prepare for simulation. Connecting these inputs into an editable workflow helps teams explore design alternatives and incorporate engineering feedback as the design evolves.
The NVIDIA Omniverse DSX Blueprint, part of NVIDIA DSX Sim, provides reference digital twin assets, sample scripts, and workflows for developing AI factory digital twins. Built on OpenUSD and NVIDIA Omniverse libraries, the blueprint gives developers a foundation for assembling facility and equipment models with SimReady assets, and connecting them with engineering simulation tools.
Frontier AI models can help developers work with this foundation through agents and connected applications and tools, as explained in Into the Omniverse: How Developers Turn Ideas Into Simulations with Frontier AI Agents. Developers guide agents to bring together design inputs, assemble and revise OpenUSD scenes, and inspect the results. The blueprint supplies reusable assets and workflows, and the agents help developers apply and adapt them to specific design requirements (Figure 1).
This post demonstrates an agent-assisted workflow for turning reference assets, site data, and design requirements into an editable OpenUSD campus model. Developers can use this approach to explore layouts, revise equipment placement, and prepare designs for engineering review and downstream simulation. Developers connect tools and guide changes, while engineers review results to inform the next iteration.
Providing agents with a design foundation for AI factory modeling
Consider a practical question: How should an AI factory hall be configured when the available power is fixed? Changing the compute configuration can impact equipment quantity, placement, electrical distribution, and cooling. Evaluating the alternatives requires those disciplines to work from consistent requirements and design data.
An agent needs context before it can make a useful design proposal. Given only photos or renderings, it can produce a model that looks plausible but may have incorrect dimensions and proportions. Reference assets and project documents help ground the proposal, but the resulting model still requires dimensional checks and engineering review.
A grounded workflow starts with the NVIDIA Omniverse DSX Blueprint and reference design, then incorporates the project’s requirements, drawings, equipment information, and site constraints. Each source has a different role: existing geometry supplies reusable buildings and equipment while architectural references inform appearance; aerial imagery and elevation data provide geographic context; project drawings and equipment information establish dimensions and placement; requirements define the conditions the design must satisfy.
For example, the team used the NVIDIA Santa Clara Headquarters building, Voyager, as design inspiration for an AI factory campus site based on the DSX reference design. The inputs included:
- DSX 3D models: Data hall, central utility buildings, substations, generators, cooling equipment, vehicles, and vegetation.
- Architectural references: Images of Voyager from various aerial and on-the-ground views to inform the roof, facade, solar canopies, and landscaping.
- Site plans (DSX Reference Design): PDFs describing the campus arrangement and a more detailed first phase, including buildings, roads, utility areas, and access areas.
- Requirements documents: An indexed collection of architectural drawings, form-factor studies, Basis of Design documents, room layouts, and other records.
- Geographic data: USGS aerial imagery and elevation data of the selected site used to place the campus in the surrounding terrain.
Together, these sources provide a starting point for an agent-assisted workflow and basis for reviewing its output. They help teams trace design choices to their sources—for example, building placement to a site plan and facade styling to an architectural reference. That traceability supports review; dimensional accuracy still depends on checking the model against the applicable drawings, specifications, and site constraints.
Building an OpenUSD campus site model using an AI agent
To implement this workflow, a frontier AI model runs in an agent harness: software that manages context, instructions, and tool calls. Skills encode repeatable tasks and AI factory domain knowledge. Developers connect modeling and analysis operations through tool interfaces, including the Model Context Protocol (MCP), where supported, and define which changes the agent may propose or apply.
In the campus model example, existing DSX reference designed buildings from the DSX Blueprint and equipment supplied the starting geometry, while the site plans guided placement and first-phase details. The team supplied photographs and the architectural references from the NVIDIA Voyager campus to guide the architectural additions.
For the solar canopy, the frontier AI agent used USD Content Agents to help generate its geometry and materials, then refined the design using the Voyager references. This gave the team an editable architectural element to review alongside the existing buildings and equipment. The canopy remained a conceptual design where an engineering team could check for dimensions, structural properties, and suitability for simulation.
The team then combined the reused assets and new architectural geometry in additive USD layers, keeping changes separate from the source assets. In the Omniverse RTX viewport, the team could inspect the canopy in the context of the campus, review its appearance and placement, and revise the model as design decisions change. USGS aerial data was used for the landscape and elevation plan.
Extending the campus model to evaluate a fixed power budget
The campus model could support a subsequent capacity planning study: How should an AI factory hall be configured within a fixed power budget? The proposed extension would connect the modeled layout with compute, electrical, and cooling requirements to evaluate alternative configurations.
One starting point is an illustrative NVIDIA Vera Rubin NVL72 inference comparison. It contrasts a baseline using MaxP—the highest static GPU-level power setting—with DSX MaxLPS, an AI factory design and operating framework that coordinates facility design, dynamic power allocation, and performance-per-watt optimization. Applying this comparison to a hall would require evaluating the support power, cooling, and networking infrastructure.
Normalized to a 1 MW power basis, assuming a power usage effectiveness (PUE) of 1.1, the illustrative scenario shows a DSX MaxLPS capacity of 400 GPUs and aggregate token throughput of 1.35x the MaxP baseline (Figure 4). These figures are reference assumptions for the proposed study, not results generated by the campus model.
In the proposed workflow, developers would connect the agent to project data and engineering tools so it could help identify equipment and design assumptions requiring review. The reference comparison would inform capacity targets. Engineers would evaluate feasible configurations using complete racks, including their placement, electrical distribution, cooling connections, and network resources.
Using Systems Modeling Language (SysML), teams can represent requirements and link them to system elements. A project team could use these relationships to organize requirements drawn from source documents. If the modeling tool exposes those relationships through an API, MCP, or other supported interface, the agent could query them to flag potentially affected dependencies affected by the proposed change. Drawings and CAD would provide dimensions and placement references, while equipment catalogs would supply the parameters for engineering analysis.
The handoff would be a proposed design revision, accompanied by the requirements, equipment, and follow-up engineering studies. After engineering reviews, the agent could help update the OpenUSD scene to reflect the selected rack configuration and layout. Preparing the scene for a specific simulation would require additional checks and configuration, including geometry, equipment properties, system connections, and boundary conditions.
Assembling the digital twin with OpenUSD and SimReady
After the team reviews a proposed configuration and its affected requirements, the next step is to prepare the design for analysis. This requires more than geometry: engineers need equipment properties and connection data to evaluate power and cooling. OpenUSD brings building geometry, equipment assets, and associated data into a shared scene. USD attributes and custom schemas can preserve links to engineering records and requirements, keeping changes traceable across applications.
The DSX system architecture connects asset preparation, data storage, simulation services, and the digital twin application. For the fixed-power scenario, this provides a framework for bringing the revised layout together with the equipment information needed to evaluate its power and cooling implications.
SimReady Foundation describes the asset data needed for particular simulation uses. While OpenUSD provides the shared scene, SimReady specifications help teams assess whether its assets contain the required data needed for the intended analysis, select the requirements and supported validators appropriate to the equipment and analysis, then check the geometry, properties, and connection data they cover. The agent can help surface missing information and associate it with the affected equipment for the team to review.
Developers can also source equipment assets from the SimReady Central Library on Hugging Face, a free, ungated library of more than 2,000 simulation-ready OpenUSD assets. For AI factory digital twins, teams can discover and reuse OEM-provided racks, power and cooling equipment, reducing asset preparation.
The AI factory pipeline samples provide examples for CAD conversion, optimization, metadata, and validation. Through connected tools, an agent can help invoke these preparation steps and collect their reports.
The resulting handoff is an assembled scene tied to the proposed design revision, with its supporting data, completed checks, and remaining gaps visible. This gives the simulation team the context needed to prepare the study and evaluate how the configuration behaves within the fixed power budget.
Evaluating power and cooling simulations to guide design revisions
With the revised scene assembled and the data gaps identified, prepare the studies needed to evaluate the configuration. In the fixed-power scenario, electrical loading and cooling analysis help determine how the proposed equipment arrangement behaves under the specified operating conditions. The application uses the geometry, equipment properties, and system connections, with additional solver preparation where required.
Where developers have implemented supported solver connections, an agent can submit studies, retrieve results, and associate findings with the affected equipment and requirements. Engineers review the assumptions and results to determine whether the design supports the proposed configurations or needs further revision. Each finding should identify the tested design revision and distinguish calculated results from stored results or AI approximations.
The capacity question now becomes a basis for making design decisions: which equipment configuration to pursue, what supporting infrastructure it requires, and where further analysis is needed. Those decisions feed back into the editable design, enabling the team to refine the proposal and repeat the affected studies.
Selecting compute for agent development, visualization, and simulation
For a workflow like the campus example, select hardware around the task: developing the agent tool connections, editing the scene, or running the engineering studies.
- NVIDIA DGX Spark for personal agent development: Prototype agents, test compatible local AI models, and connect engineering tools. Pair with an RTX system for DSX visualization and simulation.
- NVIDIA RTX PRO Blackwell Workstation Edition GPU for interactive design and simulation: Prepare OpenUSD assets, review digital twins, and run supported engineering simulations.
- NVIDIA DGX Station for larger local AI workloads: Develop and run larger AI models and agents locally. Add an RTX PRO 6000 Blackwell Workstation Edition GPU for visualization and supported simulation applications.
- NVIDIA RTX PRO Server for shared development and simulation: Follow the NVIDIA RTX PRO AI Factory reference architecture, which specifies eight RTX PRO 6000 Blackwell Server Edition GPUs per server and groups four servers into a scalable unit. Size the deployment for inference, visualization, and supported simulation workloads based on scene complexity, solver requirements, and concurrent users.
Connecting applications to the engineering decision
Extending the campus model into an engineering study requires applications that manage requirements, supply equipment data, and calculate physical behavior. Application providers are addressing these scenarios across the workflow:
- Dassault Systèmes addresses the challenge of keeping system requirements and design decisions consistent with CATIA Magic. Its SysML tools let engineers model system elements and interfaces, check model consistency, and evaluate designs against the architecture. Within an agent-assisted workflow, simulation findings can inform proposed updates to the SysML model configuration, subject to engineering review, keeping requirements and the systems model connected throughout design iterations. Dassault Systèmes also supports the Agent2Agent (A2A) protocol for agent-to-agent integration, complementing MCP-based access to tools and data.
- PTC is working to keep digital twin studies connected to the product data they represent through Windchill and NVIDIA Omniverse libraries. Windchill manages version-controlled Creo and other CAD data; the announced integration is intended to bring that data into a shared 3D environment for engineering review and simulation. This addresses the handoff from the managed equipment design to the AI factory digital twin.
- Cadence Reality Digital Twin Platform answers the fixed-power question: how many GPUs can run, and can they be cooled? It couples equipment and power models with computational fluid dynamics to simulate MaxP, MaxQ, and DSX MaxLPS. Stakeholders see the impact on power, cooling, and token throughput before a single rack is installed and continues through the life of the AI factory. Built on NVIDIA Omniverse libraries, SimReady assets, and OpenUSD, the Cadence Reality Digital Twin allows collaborative and agentic optimization of AI factory performance.
- Siemens supports detailed evaluation of fluid flow and heat transfer with Simcenter STAR-CCM+, where engineers calculate how a proposed design behaves under specified conditions. For AI factory infrastructure, Siemens has also developed DSX-aligned reference architectures that combine power distribution, automation, and simulation-ready assets. These address the need to represent supporting infrastructure alongside compute equipment in the factory design.
Get started with the NVIDIA Omniverse DSX Blueprint
Choose one engineering question, connect the required data and tools, assemble the digital twin with OpenUSD, and use SimReady requirements to prepare assets for the intended analysis. Review the result before expanding.
Ready to get started?
- Build with the NVIDIA Omniverse DSX Blueprint
- Assemble your digital twin with OpenUSD
- Prepare and validate your assets with DSX asset guidance and SimReady Foundation
- Prepare content for your workflow with AI factory pipeline samples
- Explore related simulation examples in Putting Astra to Work in Simulation With NVIDIA Omniverse Libraries
Stay up to date by subscribing to NVIDIA news and following NVIDIA Omniverse on Discord and YouTube.