Cnuas Facility Twin Design¶

1. Why a facility twin¶

Cnuas emulates two ORv3 racks. Everything above the rack, the hall it sits in, the busway that feeds it, the generator that backs the busway and the grid connection behind the generator, has until now existed only as prose.

That is a gap worth closing, because the questions that decide whether an AI datacenter can be built are facility questions. How many megawatts. How much heat. How many generators, and where do they physically stand. A rack emulator cannot answer any of them on its own, and a spreadsheet that answers them has no way to stay consistent with the emulator.

The facility twin closes the gap by generating one artefact that carries both: an OpenUSD stage in which the geometry and the numbers live on the same prims.

2. Scope¶

The generator produces a complete campus at coarse detail and exactly one data hall at full detail.

That split is deliberate. A campus of 1,920 individually modelled racks would be slow to open and no more informative than a campus of sixteen labelled volumes carrying rack counts. Detail is spent where it earns its place, which is the hall containing the two racks Cnuas actually runs.

Every hall contributes to the power model whether or not it is drawn in detail. Detail is geometry, not accounting.

3. The reference campus¶

cnuas_facility.spec.default_campus() describes a 1,000 by 800 metre site.

Quantity	Value
Buildings	3, shaped `I`, `H` and `E`
Data halls	16
Racks	1,920
White space	23,040 m2
IT load	253.2 MW
Facility load at PUE 1.15	291.2 MW
Heat to reject	253.2 MW
Standby generators	99 at 3 MW

3.1 Building shapes¶

The three letter shapes are the ones hyperscale operators actually build, and they encode a distribution strategy rather than an aesthetic.

I is a single hall bar with the plant gallery along one face. It is the simplest thing that works, and it is what a first phase on a new site looks like.
H is two hall bars joined by a central spine. The spine carries the electrical and mechanical plant and feeds both bars.
E is a spine along one edge with three hall wings reaching off it.

In each case the plant sits on the spine and the halls sit on the limbs, so every busway run and every pipe header is short. Copper and chilled water are both expensive per metre, and at 132 kW a rack the currents involved make length a real cost rather than a rounding error.

3.2 The room programme¶

Rooms are named after TIA-942-B, which is the standard that gives datacenter spaces their names. Using the standard names means the scene graph can be read by anyone in the industry rather than only by people who have read this repository.

Room	TIA-942-B name	Role
Data Hall	Equipment Distribution Area (EDA)	The white space. Rack rows in containment
Entrance Room	Entrance Room (ER)	Where carrier conduits terminate
Meet-Me Room	Meet-Me Room (MMR)	Carrier-neutral cross-connect
Main Distribution Area	Main Distribution Area (MDA)	Core routers and the main fibre cross-connect
Horizontal Distribution Area	Horizontal Distribution Area (HDA)	Per-hall aggregation between the MDA and the rows
Fibre Distribution Area	Part of the MDA	Patch frames and splice enclosures

Alongside those, each building carries the plant and support rooms a real one has: medium-voltage switchgear, a transformer vault, paralleling switchgear, a battery room, a pump room, water treatment, a coolant distribution room, a fan wall gallery, a network operations centre, staging and burn-in, a loading dock, a spares store, a security vestibule, offices and amenities.

The battery room deserves a note, because it is nearly empty. On an ORv3 fleet the ride-through battery is in the rack, in the BBU shelf that Cnuas emulates over RS-485. The central battery room holds control and telecoms batteries only. The rack architecture changed the building, and the twin shows it.

3.3 Data hall DH1¶

DH1 in DC1 is emitted rack by rack: 120 rack prims in four rows, hot and cold aisle containment, overhead busway above each hot aisle, and coolant distribution units at the head of each row pair.

Rows are generated in pairs. The two rows of a pair stand back to back across a hot aisle and present their intakes to the cold aisles on either side, which is the arrangement containment is built around.

The first two racks of row A, slots A01 and A02, are the Cnuas racks. They are 24 OU ORv3 racks drawing 6 kW, standing in a row of 132 kW liquid-cooled AI racks, and the size difference is visible in the scene. That is honest: the emulator runs a development rack, not an NVL72.

4. Power model¶

The arithmetic is deliberately plain, and it is kept in power.py with no dependency on geometry so the same numbers are used by the report, the tests and the USD attributes.

Two conventions, both standard practice:

Facility power is IT power multiplied by PUE. Hyperscale best-in-class PUE is 1.06 to 1.15; the industry average is nearer 1.55. The campus uses 1.15.
Essentially all electrical power delivered to IT equipment leaves as heat, so the heat rejection duty is taken as equal to the IT load.

Rack loads roll up to halls, halls to buildings, buildings to a campus and a grid connection. Plant is then sized from the result at N+1, which is why changing a rack count in the spec resizes the generator yards rather than leaving them wrong.

The emulated racks are counted separately rather than smeared into an average, because two 6 kW racks counted as two 132 kW racks would be a 252 kW error in a hall, and the whole value of the twin is that its numbers can be trusted.

4.1 Power density¶

A hall here carries 120 liquid-cooled racks at 132 kW in 1,440 m2, about 11 kW per square metre. That is very high by the standards of an air-cooled hall, and it is why the halls look sparsely populated. An AI hall runs out of power and cooling long before it runs out of floor, so the floor is given over to coolant distribution and to the next phase rather than to more racks.

4.2 The chain from grid to chip¶

The twin models every link:

utility 230 kV
  substation, on the campus
    34.5 kV medium-voltage switchgear room
      paralleling switchgear, against the generator yard
        transformer vault, 34.5 kV to 415 V
          low-voltage switchboard
            overhead busway, above the hot aisle
              ORv3 power shelf, 33 kW, six 5.5 kW PSUs
                48 V busbar
                  BBU shelf, 16.5 kW of ride-through
                    the sled

The last four links of that chain are not a diagram. They are the RS-485 Modbus segment that Cnuas emulates, described in Cnuas OCP Rack Management Design section 3.4.

5. OpenUSD conventions¶

The stage is Z-up in metres, which is what Isaac Sim and the NVIDIA Omniverse DSX blueprint for AI factory digital twins both assume.

5.1 Scene graph¶

/World
  /World/Looks                    materials
  /World/Site                     terrain, ponds, planting, roads
  /World/Yards/<Yard>             generator and cooling compounds, substation
  /World/Buildings/DC1
    /World/Buildings/DC1/Shell    transparent wing volumes
    /World/Buildings/DC1/Rooms    one prim per room, named per TIA-942
    /World/Buildings/DC1/Halls    the detailed hall
  /World/Prototypes               instanced geometry
  /World/Lights                   sun and sky

Building shells are transparent so the room programme inside stays visible. A solid building would be a box, and a box teaches nobody anything.

5.2 Facility metadata on prims¶

There is no ratified OpenUSD schema for power and thermal data on prims. The approach taken here, which is what the OpenUSD documentation recommends until one exists, is a namespaced set of custom attributes.

Attribute	Meaning
`cnuas:kind`	What the prim is in facility terms
`cnuas:tia942`	The standard name of a space
`cnuas:power:ratedKw`	Design draw
`cnuas:power:drawKw`	Instantaneous draw
`cnuas:power:pue`	Power usage effectiveness
`cnuas:thermal:heatKw`	Heat to reject
`cnuas:thermal:cooling`	Cooling method
`cnuas:rack:emulated`	True where Cnuas runs the rack
`cnuas:telemetry:source`	URI of the live data source

Putting the numbers on the prims rather than only in a report means the scene carries its own truth. Select a rack in Isaac Sim and its rating, its cooling method and its telemetry source are in the property panel. It is also what phase two needs, because live values are written onto the same attributes.

5.3 Instancing¶

Trees are scattered with UsdGeomPointInstancer, from a fixed seed so the output is deterministic and a committed .usda diffs cleanly. Plant items and racks are explicit prims referencing shared prototype geometry, because they carry per-item metadata that a point instancer cannot hold.

6. Bridge to the emulator¶

The two racks in DH1 slots A01 and A02 carry a telemetry URI naming a Modbus RTU unit on the emulated ORV3 RS-485 segment:

cnuas:telemetry:source = "modbus-rtu://127.0.0.1:3485/0xc0"

Those addresses are real. They are the PSU unit addresses served by the Renode power-shelf machines, and bmc/renode/tests/orv3_shelf_probe.py already reads PSU_Output_Voltage and PSU_Output_Current from them.

cnuas-facility live closes the loop. It reads those registers, computes the watts, writes them to cnuas:power:drawKw as USD time samples and scales the measurement across the fleet. The campus is no longer a model of a 300 MW datacenter; it is a simulation of one, driven from the bottom by firmware that Cnuas is genuinely running.

6.1 Where the load comes from¶

Power supplies do not choose how much current they deliver. The rack does. So the firmware carries a runtime load register at 0x30000010, re-read on every plant tick, and everything downstream follows from it: output current, the droop on the busbar, conversion efficiency, input power, fan speed and inlet temperature.

Until workloads run on emulated blades, bmc/renode/tests/orv3_load_driver.py stands in for them. It drives a profile into all twelve satellites through the Renode monitor:

Profile	Shape
`idle`	A rack sitting at its floor draw
`diurnal`	A slow sine between floor and design load
`training`	Long plateaus near peak with short checkpoint dips
`burst`	Square waves between idle and peak, the worst case for the grid
`step`	A single step, for A and B comparisons

6.2 Coherent reads¶

A sweep reads each supply's output voltage, output current, output power and input power in one Modbus transaction. Reading them one at a time on a rack whose load is moving samples different instants and yields efficiencies above 100 percent. Real rackmon reads contiguous spans for the same reason.

6.3 Honest extrapolation¶

Two racks are measured. The remaining 1,918 are scaled by the measured utilisation. That is a defensible thing to do and an indefensible thing to hide, so cnuas:live:sampleCount and cnuas:live:utilisation travel with every figure. Utilisation above 100 percent is not an error; it is what the grid connection would have to carry if every rack worked as hard as the measured ones.

6.4 Measured end to end¶

Against Renode, with the diurnal profile running:

  t=   0.0s   2.486kW  2.683kW 47.98V   49.0A eff= 95% inlet=25.0C  util=43.1%  campus= 125.4 MW
  t=  12.6s   8.535kW  9.621kW 47.95V  170.8A eff= 96% inlet=25.0C  util=151.3%  campus= 440.5 MW
  t=  28.4s  16.691kW 16.662kW 47.89V  329.6A eff= 95% inlet=25.0C  util=277.9%  campus= 809.3 MW
  t=  44.2s   9.339kW  8.105kW 47.93V  187.0A eff= 96% inlet=25.0C  util=145.4%  campus= 423.3 MW

The busbar droops as the load rises, efficiency stays inside the modelled curve, and the grid connection swings across most of a gigawatt.

7. Testing¶

The generator is tested without a GPU and without a renderer.

Space planning and power are pure Python with no pxr import, so they are asserted on directly.
test_nothing_on_the_masterplan_overlaps checks that no building, plant yard, pond, planting belt or road runs through any other. The masterplan is hand-placed, so this is the test that keeps it honest.
USD emission is tested by writing a stage to a temporary file and reading it back, so the assertions are about what Isaac Sim would load rather than about what the writer intended.
Generation is asserted to be byte-for-byte deterministic.
The live bridge is covered by an in-process Modbus RTU slave with a settable load, so CI exercises the whole path from the wire to the campus total without Renode. Turning the load down on that fake wire has to make the megawatts fall, or the test fails.

8. Status¶

Capability	State
Campus, buildings, room programme	Working
Detailed data hall with the two emulated racks	Working
Plant yards sized from the load	Working
Power roll-up to a grid connection	Working
OpenUSD emission, Z-up metres, `cnuas:` attributes	Working
Live rack power from the ORV3 shelf	Working
Runtime load input to the PSU model	Working
Workload profiles driving the shelf	Working
Cooling plant that responds to measured heat	Next
Workloads on emulated blades driving the draw	Next
Grid frequency and generator start sequencing	Next