Building a Custom AI/HPC Data Center Simulation¶

This guide starts with no assumed knowledge of NVIDIA Isaac Sim or OpenUSD. It takes a facility specification from a planning worksheet to a validated Cnuas power model, a complete OpenUSD campus, an interactive Isaac Sim scene, and optional live power animation from the emulated ORv3 racks.

At the end, you will have:

a site with dimensions, roads, green screening and retention ponds;
one or more I, H, or E data-center buildings;
data halls, rack rows, hot/cold aisles and the TIA-942 room programme;
custom AI, storage, network, or Cnuas ORv3 rack populations;
IT load, PUE, grid connection, heat-rejection duty and N+1 plant counts;
generator, cooling, substation and support yards;
an OpenUSD .usda, .usdc, or .usd stage;
an Isaac Sim viewport with facility metadata on every relevant object; and
optional USD time samples driven by the Cnuas ORv3 PSU/BBU simulation.

1. Understand the three layers¶

You do not build the facility inside Isaac Sim from an empty viewport.

Layer	Role	Requires an NVIDIA GPU
Cnuas facility planner	Reads the campus specification, validates geometry, calculates power/cooling, and writes OpenUSD	No
OpenUSD	Portable scene description containing geometry, hierarchy, materials, engineering metadata, and time samples	No
NVIDIA Isaac Sim	Interactive RTX viewport and Python environment used to inspect, extend, render, and replay the stage	Yes

OpenUSD is the hand-off format. Cnuas remains the source of truth for layout and engineering values; Isaac Sim displays and extends the result. You can generate and validate a campus on a headless server without installing Isaac Sim.

Isaac Sim is a general simulation application built on NVIDIA Omniverse Kit. It is commonly introduced through robotics, but Cnuas uses its OpenUSD stage, viewport, scripting, timeline, and rendering capabilities for the facility twin. No robot setup is required.

2. Decide what you are designing¶

Complete this worksheet before editing a configuration.

Decision	Examples	Where it appears
Site boundary	1,000 m by 800 m	`site_w`, `site_d`
Design target	300 MW campus, 1 GW campus, or a fixed rack count	Derived by `power`
Building topology	`I` for a linear phase, `H` or `E` for more hall wings	`shape`
Building placement	Southwest origin of every building	`origin_x`, `origin_y`
Hall programme	halls per wing, hall width/depth	`halls_per_wing`, `hall`
Rack population	rows, racks per row, equipment type	`rows`, `racks_per_row`, `rack_type`
Cooling	air, rear-door heat exchanger, direct-to-chip, immersion	rack `cooling`
Efficiency	design PUE, normally scenario-specific	`pue`
Electrical plant	utility substation and N+1 generators	`yards`
Mechanical plant	coolant distribution and heat rejection	rack type plus cooling yards
Resilience	N+1 plant; ORv3 rack BBUs provide ride-through	automatic yard counts
Network rooms	ER, MMR, MDA, HDA and fibre distribution	emitted automatically
Detailed geometry	which hall emits every rack, aisle, busway and CDU	`detailed_hall`
Cnuas integration	number of live emulated ORv3 racks	`cnuas_racks`
Landscape	ponds and planted screening areas	`lakes`, `groves`
Roads	fire loop and north/south service spine	road fields on the campus

Facility vocabulary¶

Data hall / server hall / white space: the Equipment Distribution Area containing rack rows.
ER: Entrance Room, where carrier conduits enter.
MMR: Meet-Me Room, the carrier-neutral cross-connect.
MDA: Main Distribution Area, containing core network and fibre distribution.
HDA: Horizontal Distribution Area, the per-hall network aggregation room.
CDU: Coolant Distribution Unit separating facility water from the technology cooling loop.
PUE: facility power divided by IT power.
IT load: electrical load consumed by racks.
Facility load / grid connection: IT load multiplied by PUE.
Heat rejection: approximately equal to IT load; almost all rack power becomes heat.
N+1: enough units for the calculated duty plus one spare unit.

3. Install the Cnuas facility planner¶

From the Cnuas repository root:

python3 -m venv .venv
source .venv/bin/activate
python -m pip install --upgrade pip
python -m pip install -e './facility[test]'

cnuas-facility --help
pytest -q facility/tests

Python 3.10 or later is required. The usd-core dependency supplies the OpenUSD Python API used to write stages. Generation does not require Isaac Sim, an RTX GPU, a VM, or the Cnuas emulated rack.

4. Create an editable campus specification¶

Start from the complete reference campus rather than writing JSON from memory:

mkdir -p out
cnuas-facility template --out out/my-campus.json

The file is strict JSON. Unknown fields, invalid names, unsupported rack types, bad dimensions, off-site objects, overlapping buildings/plant/roads, and rack grids that do not fit are rejected instead of ignored.

A smaller complete example is included at facility/examples/custom-campus.json. Copy it if you want to begin with one building:

cp facility/examples/custom-campus.json out/my-campus.json

4.1 Site and roads¶

{
  "name": "ExampleAIWest",
  "label": "Example AI West Campus",
  "site_w": 700.0,
  "site_d": 500.0,
  "pue": 1.20,
  "road_width_m": 9.0,
  "loop_road_inset_m": 40.0,
  "service_spine_x_m": 300.0
}

Coordinates are metres in a local site coordinate system. (0, 0) is the southwest corner. The service spine should sit between data-center buildings and their external plant. Keep the fire-loop inset large enough for landscape screening outside it and buildings/yards inside it.

4.2 Custom rack equipment¶

The built-in rack names are:

Name	Rating	Cooling
`CnuasORv3_24OU`	6 kW	Air
`GB200_NVL72`	132 kW	Direct-to-chip
`StorageRack`	12 kW	Air
`NetworkRack`	15 kW	Air

Add project-specific equipment under rack_types:

"rack_types": [
  {
    "name": "CustomAI80kW",
    "label": "Custom 80 kW direct-to-chip AI rack",
    "width_m": 0.6,
    "depth_m": 1.2,
    "height_m": 2.2,
    "power_kw": 80.0,
    "cooling": "dtc",
    "note": "Replace this example with the selected platform."
  }
]

Cooling must be air, rdhx, dtc, or immersion. A rack type name must be unique and is then referenced by each hall.

4.3 Buildings, halls, and racks¶

"buildings": [
  {
    "name": "DC1",
    "label": "DC1, first-phase AI building",
    "shape": "I",
    "origin_x": 70.0,
    "origin_y": 100.0,
    "halls_per_wing": 2,
    "hall": {
      "name": "DH",
      "rows": 3,
      "racks_per_row": 8,
      "rack_type": "CustomAI80kW",
      "width_m": 40.0,
      "depth_m": 28.0,
      "detailed": false,
      "cnuas_racks": 0
    },
    "wing_depth_m": 38.0,
    "spine_width_m": 32.0,
    "wing_gap_m": 45.0,
    "detailed_hall": "DH1",
    "cnuas_racks": 2
  }
]

An I building has one hall wing, an H has two, and an E has three. Therefore:

building halls = shape wing count x halls_per_wing
racks per hall = rows x racks_per_row

Only a hall named by detailed_hall is emitted rack by rack. Every other hall is a lightweight volume but remains fully included in power and rack counts. This keeps a multi-thousand-rack stage responsive.

cnuas_racks replaces the leading slots in the detailed hall with the ORv3 racks that Cnuas emulates. It does not add extra racks or inflate the hall.

4.4 Power, cooling, and grid plant¶

Power is derived from the rack population:

IT load       = sum(rack count x rack rating)
facility load = IT load x PUE
heat rejected = IT load

Generator and heat-rejection yards can follow a building automatically:

{
  "name": "GeneratorYardDC1",
  "label": "DC1 N+1 standby generation",
  "kind": "generators",
  "x": 350.0,
  "y": 100.0,
  "w": 200.0,
  "d": 60.0,
  "count": "auto",
  "item": "Generator",
  "rows": 2,
  "building": "DC1"
}

For automatic counts, set building to the owning building and use kind: "generators" or kind: "cooling". Cnuas calculates:

3 MW generators as ceil(facility load / 3 MW) + 1;
3.5 MW heat-rejection units as ceil(IT heat / 3.5 MW) + 1; and
2 MW in-hall CDUs from direct-to-chip rack load.

The model sizes capacity and places symbolic plant. It is not a utility interconnection study, short-circuit analysis, hydraulic model, or CFD result. An electrical/mechanical engineer must turn the planning values into a construction design.

4.5 Landscape and water¶

lakes are elliptical retention ponds described by center and radii. groves are rectangular planted areas. Both must remain inside the site and clear of buildings, yards, and roads. They are not decorative afterthoughts: they reserve stormwater, screening, and potential thermal-infrastructure space during master planning.

5. Validate before rendering¶

Run validation immediately after every layout change:

cnuas-facility validate --config out/my-campus.json

A successful result summarizes buildings, halls, racks, and facility load. Failures identify the field, object, boundary violation, or overlap. Do not move on to Isaac Sim to diagnose planning errors; the planner gives a more precise answer than a viewport.

Then review the engineering outputs:

cnuas-facility rooms --config out/my-campus.json
cnuas-facility power --config out/my-campus.json --depth 2

Review in this order:

Room programme: ER, MMR, MDA, HDA, electrical, mechanical, staging, loading, security, NOC, office, and amenities.
Rack and hall counts.
IT MW and rack density.
PUE and facility/grid MW.
Heat rejection.
N+1 generator and cooling-unit counts.
Yard areas and separation on the site.

Sizing toward a target¶

For a first estimate:

approximate rack count =
    target facility kW / (rack rating kW x PUE)

A 300 MW target with 132 kW racks and PUE 1.15 starts near 1,976 racks. Choose a practical hall/row arrangement around that estimate, run power, and iterate. A 1 GW campus should normally be represented as multiple phases or buildings rather than one enormous hall.

6. Generate the OpenUSD campus¶

Once validation and power review pass:

cnuas-facility build \
  --config out/my-campus.json \
  --out out/my-campus.usda

Use:

.usda while developing: text, reviewable, and diffable;
.usdc for faster loading of a stable large scene; or
.usd when the downstream workflow chooses the encoding.

The stage uses metres, Z-up, /World as its default prim, deterministic geometry, lights, materials, and namespaced cnuas: engineering attributes.

Inspect it without Isaac Sim:

usdcat out/my-campus.usda | head -80

Blender and other USD-capable applications can also open the stage, but they may not display all custom engineering attributes as conveniently as Omniverse Kit.

7. Install and prepare NVIDIA Isaac Sim¶

Isaac Sim is optional for generation but required for the interactive workflow. NVIDIA supports workstation, container, cloud, livestream, and Python installation paths. Follow the current official installation guide and system requirements; requirements change faster than Cnuas releases.

Important current constraints:

use a supported Windows or Linux release and NVIDIA driver;
use an NVIDIA RTX-capable GPU with RT cores;
data-center GPUs without RT cores, including A100 and H100, are not supported as Isaac Sim display devices;
budget VRAM for the size of the stage and any sensors added later;
the Isaac Sim container is Linux-only; and
online assets require outbound HTTPS unless you configure a local asset root.

Before loading Cnuas, start Isaac Sim and complete NVIDIA's Stage Setup tutorial. You only need the stage/navigation portions; the robot exercises are not a Cnuas prerequisite.

8. Open the campus in Isaac Sim¶

GUI method¶

Start Isaac Sim.
Select File → Open.
Choose the absolute path to out/my-campus.usda.
Wait for materials and prims to finish loading.
In the Stage panel, expand /World, then Buildings, a building, Halls, the detailed hall, and Racks.
Select /World to inspect campus rack count and total power.
Select a rack to inspect its rating, cooling method, live state, and telemetry source.

Do not rescale or rotate the root to “make it look right.” The stage is already Z-up in metres. A scale change makes facility dimensions and physics units incorrect.

Reproducible script method¶

Run the supplied loader with Isaac Sim's Python, not the Cnuas virtual environment:

cd /path/to/isaac-sim
./python.sh /path/to/cnuas/facility/scripts/open_in_isaac.py \
  --stage /absolute/path/to/cnuas/out/my-campus.usda

For a render host:

./python.sh /path/to/cnuas/facility/scripts/open_in_isaac.py \
  --stage /absolute/path/to/cnuas/out/my-campus.usda \
  --screenshot /tmp/my-campus.png

The script supports Isaac Sim 5.x and 4.x launch modules, verifies the /World metadata after opening, and can run headless.

9. Work safely in Isaac Sim¶

Treat the generated Cnuas stage as a build artifact. Regenerating it overwrites manual edits made directly in that layer.

For cameras, signage, detailed vendor assets, people, vehicles, sensors, or presentation lighting:

Keep my-campus.usda as the generated base layer.
Create a separate USD layer or stage that sublayers/references it.
Author visual and simulation overrides in the new layer.
Regenerate only the Cnuas base after changing engineering inputs.

This separation keeps power/layout reproducible while allowing an Isaac Sim artist or simulation engineer to enrich the scene.

10. Connect live Cnuas rack power¶

The static stage uses design ratings. Live mode samples the emulated ORv3 power shelf over Modbus RTU, writes time samples to the detailed Cnuas racks, and scales the modeled fleet using the measured utilization.

Build and start the shelf from the repository root:

make -C bmc/firmware/orv3 firmware
renode --disable-xwt --port 1234 \
  bmc/renode/scripts/cnuas-orv3-power-shelf.resc

In another terminal, apply a workload profile:

python3 bmc/renode/tests/orv3_load_driver.py \
  --profile diurnal \
  --duration 60

Sample into a new stage:

cnuas-facility live \
  --config out/my-campus.json \
  --stage out/my-campus.usda \
  --out out/my-campus-live.usda \
  --duration 60 \
  --interval 1 \
  --fps 24

Open my-campus-live.usda in Isaac Sim and scrub the timeline. The cnuas:live:sampleCount attribute records how many emulated racks were measured; the remaining fleet is an explicit extrapolation, not falsely presented as thousands of measurements.

11. Iterate as an engineering workflow¶

Use this loop:

requirements
  -> edit JSON
  -> validate geometry
  -> review rooms
  -> review power/cooling/grid
  -> generate USD
  -> inspect in Isaac Sim
  -> run live telemetry
  -> revise requirements

Keep the JSON, power report, generated USD, and rendered evidence together for each scenario. Give scenarios names such as phase-1-300mw, phase-2-600mw, air-cooled-baseline, or dtc-high-density rather than silently replacing one design with another.

12. Troubleshooting¶

Symptom	Cause	Action
`unknown field`	Typo or unsupported schema key	Use `template` as the schema reference
`unknown rack type`	Hall references a rack not built in or declared	Add it under `rack_types`
Racks do not fit	Too many rows/racks for hall dimensions	Increase hall dimensions or reduce the grid
Object lies outside site	Coordinates plus dimensions exceed site bounds	Move it or enlarge the site
Object overlaps another	Building, yard, road, pond, or grove collision	Change coordinates; do not bypass validation
Facility MW is unexpectedly high	Rack rating/count or PUE is high	Inspect `power --depth 2` building by building
Isaac Sim cannot import	Unsupported install/GPU/driver or wrong path	Verify the official requirements and use an absolute stage path
Campus appears tiny or huge	Root scale or stage units were changed	Restore one metre per stage unit and Z-up
Live command cannot reach shelf	Renode shelf is not running or endpoint differs	Start the ORv3 shelf and check port 3485
Timeline has no samples	Static stage opened instead of live output	Open the file passed to `--out`

13. Model boundaries¶

Cnuas currently models space planning, room programme, rack population, electrical/thermal roll-up, symbolic plant sizing, OpenUSD geometry, and live rack-power time samples.

It does not currently provide:

computational fluid dynamics or rack inlet temperature prediction;
hydraulic pipe sizing;
utility load-flow, fault-current, arc-flash, or protection coordination;
generator transient/fuel autonomy studies;
structural, seismic, fire, acoustic, or environmental approval;
measured cooling-plant response to live heat; or
a claim that the generated plan is construction-ready.

Use the twin to compare scenarios, connect emulated IT load to facility scale, and communicate a coherent design. Use discipline-specific engineering tools and qualified reviewers before making physical design decisions.

14. Completion checklist¶

[ ] Site dimensions and setbacks are defined.
[ ] Building topology and phase origins are defined.
[ ] Hall dimensions can physically contain every rack row.
[ ] ER/MMR/MDA/HDA and support-room programme has been reviewed.
[ ] Rack ratings and cooling methods match the intended equipment.
[ ] IT load, PUE, grid MW, heat rejection, and density are plausible.
[ ] Generator and cooling yards have capacity and physical area.
[ ] Roads, plant, ponds, groves, and buildings validate without overlap.
[ ] The intended hall is detailed and contains the Cnuas ORv3 racks.
[ ] The JSON passes cnuas-facility validate.
[ ] The power and rooms reports have been saved.
[ ] The OpenUSD stage opens in Isaac Sim at Z-up, one metre per unit.
[ ] Isaac-specific edits live in a separate layer.
[ ] Live telemetry, if used, records its sample count and output stage.