Engineering · for the technical reader and the ecosystem partner

A model of the hall as one system, solved together every step and kept true to the hall's readings.

Each device in the hall is modelled from its maker's data, and the models are solved together as one system, so what happens in the power distribution shows up in the coolant loop and in the GPUs in the same step, as it does in the hall. This page explains the parts, how each model is built and verified, how they are coupled, how the real limit of a group of racks is computed from them every hour, and how the result reaches the systems a hall already runs.

A reference hall, illustrative numbers: the power and the coolant of one row move through the day at the pace the model sets, and the device in blue is the tightest on the path at that hour.

01 · The parts

Between the utility and a GPU there are two chains of devices, and inside the hall their classes repeat from one hall to the next.

The power distribution runs from the utility transformer through the switchboard and the UPS to the row panels, along the busway to a tap-off and a branch breaker per group of racks, into the rack's power shelves, which convert to the rack's direct-current bus, and on to the GPUs. The coolant loop runs from the facility water through the coolant distribution unit's heat exchanger, its pump and its control valve, through the supply manifold to each rack's cold plates and back through the return manifold. The GPU sits at the end of both chains, drawing from one and heating the other.

Inside the hall, the rack, its power shelves, the coolant distribution unit interface and the leak response follow the published reference designs of the GPU vendor and its equipment partners, and repeat from hall to hall within a platform generation. The models and records for those classes are therefore built once per generation. Everything from the medium-voltage switchgear outward, the utility connection, the redundancy topology, the climate, the water plant and the controls, differs per site and is fitted by engineers with the models as the tool.

02 · The models

Each device is modelled from the standards and the maker's curves, and the models are solved together as one hall, so a change anywhere in the hall shows up everywhere it should.

The value is in the coupling, not in any one model. If a feed is lost and two of the four coolant distribution units lose power, the other two take the whole loop, the flow to each row changes, the racks warm, the GPUs throttle, and the power drawn from the surviving feed drops. That chain crosses the power distribution, the coolant loop, the GPU heat and the power draw in under a minute, and only models that are stepped together can show it. VARCOTT's runtime steps all the models of a hall together on one clock, with typed interfaces between them: what is powered goes from the electrical model to the cooling model, the heat goes from the racks to the loop, the case temperature goes from the loop to the GPUs, and the power actually drawn comes back to the electrical model. The cooling-loop model is exercised on a multi-unit reference hall, with its row headers, collectors and per-rack valves, solved as one hydraulic and thermal system.

A reference hall, illustrative numbers: feed A is lost at t = 0, two units stop, the other two carry the loop, the far groups lose flow, their GPUs throttle, and the draw on feed B falls. The lit part is the device driving each step.

The method is the same for every model: study the published reference for that physics, write the equations as our own typed, pure functions with their regimes and units stated, run the reference beside ours, and import its results as tests with stated tolerances before adding our own cases. Where a maker provides its own model or performance data for a device, we use it. The model that reaches a hall is then calibrated on that hall's readings, and the calibration is part of the record.

Coolant loop

The coolant distribution unit with its plate heat exchanger, pump, control valve, filter, expansion vessel, sensors and both control loops; the supply and return manifolds and branches; the pipes with their transport delay; the racks' cold plates with their flow resistance and the case temperature they produce. Verified test by test against the published reference results of the Lawrence Berkeley National Laboratory's Modelica Buildings library, and as a whole hall against a reference model built from that library's components. It gives the flow, pressure and temperature at every point; the unit's margins in heat, flow and pump head, and the time the water buys after a change, are computed from them.

Power distribution

The transformer, switchboard, UPS, panels, breakers, busway, tap-offs and power shelves as a tree with AC and DC bus types, energised from the breaker states; the loading of every device per phase, with losses and partial-load efficiency, summed from the racks for the devices no meter watches and checked against the meters that exist; the continuous limit of each device from the applicable code rule, its ambient derating and its maker's data; and the time each device would carry an excursion before its protection acts, from the maker's curves, the standards for transformers and the published tables for UPS and shelves.

Facility water

The primary loop, the chiller, the dry cooler or tower and the economiser, with the weather as an input, so the facility water temperature the unit will see at any hour of the year, and at the hottest hour on record, is computed rather than assumed. This is where the seasonal envelope comes from.

GPU heat

The relation between the case temperature the cold plate produces, the power the GPU draws and the point at which the GPU slows itself, calibrated on the hall's own GPU telemetry. It closes the loop between the two chains: warm water raises the case temperature, the GPU draws more and then throttles, and the throttle lowers both the draw and the heat.

03 · The limit

The limit of a group of racks is computed every hour as the tightest device on its two chains, with its margin, its hold time and its contingency cases.

For every group of racks and every hour, with the models solved together at that hour's load, weather and configuration, VARCOTT walks both chains and asks each device how much it can carry now, at this ambient and this water temperature, under its continuous rating; which device has the least margin; and how long that device could carry an excursion if the cap that protects it arrived late. The result is one record per group and hour: the limit, the binding device, the margin, the hold time, and the same for each credible failure, a feed lost, a pump out, a chiller tripped, with the deadline and the order of shedding for each.

Three rules hold throughout. No device is credited with anything its maker or the applicable standard does not support; a device whose loading cannot be checked against a meter is not credited at all, and goes on the list of what to fix instead. The cap that enforces the limit must be able to act within a fraction of the shortest hold time on the path, or the limit is reduced until it can. And the limit is computed for the hottest hour the hall will see while the limit is in force, from the hall's own weather record, as well as for today, so the racks a hall adds are sized to the hour that will test them.

The same record serves four uses: at the peak it says how many racks the hall can carry; at night it says how much work a row may admit and until when; in the alarm list it says what every reading should be, so a reading that disagrees is caught; and in the record it says which connections the readings confirm and which they contradict.

04 · Integration

VARCOTT reads the systems a hall already runs, writes to none of them, and hands its results to the GPU vendor's software in the shapes that software already takes.

It reads the building management system, the power monitoring, the DCIM, the coolant distribution unit controllers, the leak detection and the GPU telemetry, on the owner's own hardware, inside the owner's network. The results leave in three forms, and each form keeps the responsibility where it belongs.

The topology file, one version at a time

NVIDIA's documentation for its Dynamic Power Software describes the facility topology as an import file the site supplies, with one operating limit in watts per device, an overprovisioning percentage, and no field for time, temperature or hold. VARCOTT produces that file from the models, with the limit of each device computed for the hottest hour the limit must survive and signed by the engineer of record, and the site loads it as one file with its version, and loads it again only when the hall changes. The controller enforces that limit at the GPU on its own; it needs nothing from VARCOTT to keep doing so. The controller's operations guide leaves the change control of that limit to the site; the check before and after each change on the Records page is that procedure.

The plan, to the people who place the load

The hourly limit per group of racks goes to the scheduling side as a plan, in the form the scheduler takes, as labels, quotas or reservations, with an until-hour on every row. A plan is advisory. If it is stale it admits nothing the signed limit would not hold, which is what makes the design safe when VARCOTT is quiet.

The event bus

The facility's state and margins, the expected value of every reading, and the status of every connection are published on the event bus the GPU vendor's tools read, in its building-management namespace, keyed to the power meters the building system publishes with their served-by relation, which is what lets the IT side build the power distribution graph. The building system remains the publisher of its own points and their metadata; VARCOTT publishes what it computes.

What would be a separate step

Any integration that pushes a limit or a policy into a running controller is a separate step, validated and authorised by the site before it exists, and it is not part of any of the four applications as offered. The breaker, the bypass valve and the GPU's own power brake remain the protection; VARCOTT computes, records and advises.

05 · The agents

The investigations and the reports are produced by AI agents that reason over the readings, the connection record and the physics models, and an agent's statement is shown as a finding only after a deterministic check has confirmed it.

An event report, a change prediction or the answer to whether an alarm is real takes reasoning over a large body of evidence: which readings matter, in what order things happened, what the physics model of each device says its readings should have been. VARCOTT uses AI agents for that reasoning. An agent works inside a harness and reaches the evidence through tool calls: it reads the record of readings, alarms and operator actions, it reads the record of how the hall's devices are connected, and it runs the physics models of those devices. The harness logs each call, and each statement the agent makes has to name the readings, the time range and the device it rests on.

Each statement is then checked by a deterministic step, with no language model in it, before anyone sees it: the readings it cites are re-read from the record over the time range it names, the expected values it relies on are re-computed by the physics models, and the devices and connections it names are confirmed against the connection record. A statement that passes is shown as a finding. One that fails is shown as unconfirmed, with the reason. The check proves that what the agent said is supported; it cannot prove the agent said everything, so the report also shows which readings and intervals were examined. The tool calls, the evidence, the checks and the coverage are kept with the report, so an engineer or an auditor can follow the same chain the agent followed, and a report produced in days can be put in front of a grid operator, a tenant or an insurer.

06 · Verification

Each model is checked against the references the field uses to check its own simulators, with the reference's tolerance, and the results are these.

The method is the same for every model. We take a published reference for that physics, run its cases through our own code, and import its results as tests with the tolerance its authors use, before adding any case of ours. The references are named because they are the check; nothing here is endorsed by anyone, it is reproduced. For the coolant loop the reference is the Modelica Buildings Library, version 14, from Lawrence Berkeley National Laboratory, an open, peer-reviewed library of liquid-cooled data center components whose authors publish the results of their own example runs; its regression gate is 0.1 % of the value or 0.001 in absolute terms, whichever is larger, about 0.3 K on a temperature and 0.001 on a valve position.

Case	What is compared	Tolerance	Result
Coolant loop · Lawrence Berkeley National Laboratory's Modelica Buildings library, version 14 · 469 tests
The library's own coolant distribution unit example: one unit, one rack, 2 hours, with a step in the rack's heat	All 14 time-varying signals: supply and return temperatures, case temperature, valve position, pump power and pressure, exchanger duty, rack pressure drop, at a 0.1 s step	0.1 % or 0.001, as the library uses	All 14 within tolerance at every point; energy integrals within 0.002 %
A demo hall of 8 racks on one unit, 7 scenarios: baseline, facility water 3 K warmer, a unit trip, a rack isolated, and others	Every rack's inlet and outlet temperature, flows, pump speed, unit pressure drop and return temperature, at a 1 s step	0.1 % or 0.001, with a 2 s time allowance where an input steps	Flows, pump speed, pressure drop and return temperatures within tolerance in all 7; the worst temperature difference is 0.13 K on rack outlets after the unit trip
A multi-unit reference hall with row headers and per-rack valves, built from the library's own components, the same 7 scenarios	Rack-level and unit-level signals through the trips and the warm-water case	As above	No rack-level signal outside tolerance; facility return through a unit trip within 0.16 K; the largest difference, 0.71 K, is on a unit's return during the start-up front of the baseline, where sharp temperature fronts differ between any two good simulators and are reported rather than gated
Power distribution, load flow · the IEEE 13-node distribution test feeder · 291 tests across the power model
The IEEE 13-node test feeder, the case the power-systems community publishes to check load-flow solvers	Input, load and losses per phase; 15 node voltages; 11 segment currents and their losses	0.1 % on power; 0.0003 per unit on voltage; 0.05 % on current	Input power within 0.001 %; voltages within 0.00023 per unit; currents within 0.02 %
Power distribution, short circuit · IEEE 13-node short-circuit test case and IEC 60909-4
The IEEE 13-node short-circuit test case, and the worked meshed example of IEC TR 60909-4	Three-phase and line-to-ground fault currents at 9 buses; initial short-circuit current at 5 buses	0.1 %; 1 A	Within 0.01 %; within 0.1 A
Device limits · IEC 60076-7 worked example and CIGRE TB 880 references
The worked example of IEC 60076-7 for transformer hot spot and ageing; the free reference cases of CIGRE Technical Brochure 880 for the IEC 60287 cable ratings	Hot-spot temperature at 6 checkpoints through an overload cycle; cable current ratings case by case	1.5 K on the hot spot; the brochure's own figures on the ratings	Worst 1.05 K, the same figure an independent transcription of the standard's example reaches; ratings within the brochure's figures

The continuous limits themselves rest on IEEE C57.91 and IEC 60076-7 for transformers, IEEE C57.110 for harmonic derating, IEC 60287 and IEC 60853 for cables, IEC 60947-2 and UL 489 for breakers, UL 1008 for transfer switches, IEC 61439 for assemblies and NEC 310 for conductors, each cited at the rule where it is used.

Verification and validation are two different checks. Verification is what the table shows: our code reproduces a published reference within its tolerance, once, before the model is used anywhere. Validation is per hall: the model is calibrated on that hall's own readings in the first weeks of an engagement, and the calibration report states how close each device's model is to what the hall measures before any limit is credited on it.

What the reference hall demonstrates is the coupled hydraulics and thermal behaviour of a hall through unit trips, rack isolation and warmer facility water: who gets the flow when a unit is lost, how the headers share it, how fast each rack's inlet and case temperature move. What it does not settle is any real hall's own numbers: the pump curve of its units, the flow resistance of each rack against its catalogue value, exchanger fouling and sensor lags. Those are what validation measures. The reference runs are kept as files, with the scripts that produced them.

07 · The founder

David Perez has written power software for mission-critical facilities since 2013, and the record of the white space is where he started.

David Perez is an electrical engineer. In 2013, at Power Analytics, he built Paladin White Space Management in under a year, from the first idea to deployment in the data centers of Fortune 500 and Fortune Global 500 financial institutions. Operators placed breakers into remote power panels on screen; the panel redrew in seconds, and per-phase load rolled up to data center totals on live data from systems such as OSIsoft PI and Eaton Foreseer. He was also the sole developer of DesignView, the suite's real-time dashboard tool. The company was named the most innovative small company of its region that year.

Power Analytics brought him back in 2018 as Chief Software Architect, and he helped build its Power Digital Twin, one of the first live electrical digital twins in data centers. Three buyers acquired the company while he was there, and each put its due-diligence team in front of him. In 2024 The Sun Company recruited him to build its Insight digital twin platform for utility-scale solar; he designed and built it end to end, from the real-time pipeline and its connectors to the historian and the alarm system, whose solar models compare what each site should produce with what it does and alarm on the gap, and after it went live at the company's first sites he was promoted to Vice President with executive ownership of the platform. He works on US Eastern hours from Paraguay, with US engineering teams, since 2013.

VARCOTT is that work one generation of density later: the white-space record of 2013 with the hall's own readings as its witness, the live electrical twin of 2018 joined to a coolant loop that gives minutes instead of hours, and the alarm engine that runs on both.

David Perez on LinkedIn

08 · Next step

Discuss the engineering.

The figure on this page is an illustration of one row of a reference hall, twenty racks on one in-row coolant distribution unit, with the power running as pulses along the distribution, the coolant as slugs in the pipes, and the tightest device on the path lit as the day goes by; its numbers are illustrative. If you want to go through the models, the verification or the integration with your own stack, that conversation is the one we are looking for; bring a hall or a question.

Discuss the engineering