loading
loading
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: developin
document fetched 2026-10-24 11:20 · canonical https://developer.nvidia.com/blog/developing-an-ai-factory-digital-twin-with-an-agent-assisted-workflow