A liquid-cooled hall reports full when the nameplates of its racks add up to the limits set at design. Its devices, the feeders, the switchboard, the UPS, the panels, the coolant distribution units, carry less than that at almost every hour. VARCOTT computes the real continuous limit of each device every hour, from its own state and the hall's readings, names the device that stops each group of racks from taking more, and tells you how many racks the hall can carry, with the redundancy intact, at the hottest hour the limit must survive. The first step is a headroom study on one operating hall.
Each megawatt is approved by the utility, metered, and paid for whether it is used or not, and the next one takes years. A rack went from 5 to 10 kilowatts to 135 kilowatts within a few years, so the margins that were harmless at the old density now cost whole rows.
The usual way to fill a hall is to add up the nameplate peak of every rack and stop when the sum reaches the rating of the feeder, the switchboard, the UPS, the panel or the coolant distribution unit. Racks never all peak at the same second, so a hall whose nameplates add to 20 MW draws about 16 to 18 MW at its busiest moment. Each device also received its own margin at design, and those margins stack along the chain. The operators who have built systems to recover it report recovering 8 % of a production hall's provisioned power in one published case, and a GPU vendor's test placed more than a third more GPUs on the same power budget; the range we plan with is 8 to 20 %. The operators who publish on this call the practice of installing more racks than the sum of nameplates, with a cap ready for the rare moments the real draw approaches a limit, oversubscription; the word matters less than the mechanism, which is a cap at the GPU that keeps the real draw under the rating of every device.
Today the facility limits reach the GPU vendor's power controller as fixed numbers the site types in, one operating limit per device and an overprovisioning percentage, with no time dimension and no cooling margin. In the words of one operator's own analysis, the hall reports full because the spreadsheet says so, not because the physics does. The design-time study is right for the day it was signed.
A rack is served by a chain of devices from the utility to its power shelves, and by a second chain from the facility water to its cold plates. Capacity is not one number for the hall. It is a number per path, set by whichever device on that path is closest to its own limit at this hour.
The load moves it. A job lands on one row, and that row's panel becomes the tightest device while the transformer still has room. The weather moves it. At 36 °C ambient the transformer derates and becomes the tightest device in the early afternoon; at 27 °C facility water the coolant distribution unit loses capacity and becomes the tightest device later in the day. The configuration moves it. A feed in maintenance, a pump out of service or a chiller lost changes the chain that serves a row, and with it the device that limits the row.
VARCOTT computes the loading of every device on both chains every hour, including the panels and branches that no meter watches, from the rack draws and the wiring, and checks those computed loadings against the meters that do exist. For each group of racks it names the tightest device, the margin to its continuous limit, and the time that device could carry an excursion if the cap were late. The limit is seasonal, so the study reports the envelope at the hottest hour the hall will see while the limit is in force, taken from the hall's own weather record, as well as today's, and the racks you add are sized to that hour rather than to the day of the study. A site that wants the headroom of the cooler months back can run two signed limits a year, one for summer and one for the rest, each changed under its own change control.
The same limit, used at night instead of at the peak, tells the scheduler how much batch work a row may admit. That use has its own page, the hours, because it is bought by different people.
The hoursYou give us the one-lines, the protection settings, the loop drawings, the equipment list and an export from the historian. The first number comes from history: what the hall paid for last month and could not use, device by device.
The study delivers two things. The first is the headroom credited today: the continuous limit of every device per group of racks and per hour, with the time it can hold, electrical and cooling in one picture, the tightest device on each path named, and the envelope at the hottest hour the limit must survive. The second is the list of what unlocks the rest: which sensors to calibrate, which records to reconcile, which devices to meter, each line with the megawatts it would release. Where a reading cannot be trusted or a device is not metered, no headroom is credited, and that line goes on the list instead.
The study decides three things: the limit of each device under the signed bounds, the device that binds each row at each hour, and the number of racks the hall can add at that hottest hour, with the redundancy intact. It does not decide on its own where the hall's devices sit relative to their makers' curves: the pump curves of the coolant distribution units, the thermal response of the transformers and the flow behaviour of the racks at warm water are taken from the makers' data and then calibrated on the hall's readings during the study, and the calibration report says how close each device's model is to what the hall measures. The reaction time of the power controller is measured on the hall, not assumed. Where a device cannot be calibrated because the readings do not exist, it is credited at its conservative limit and goes on the unlock list.
After the study, the signed limits go to the GPU vendor's power controller as the topology file it imports, computed rather than typed, and the hourly envelope is kept live for the plan. The gain is measured on your racks: rack groups that run to the new limits against groups that do not, over enough nights for the difference to be a measurement. The engineer of record signs the bounds the limits sit inside, once, and the record of what was computed from which readings is kept.
Four things are true before that happens.
The limit never asked any device to run above its continuous rating, and the redundancy was intact when the limit was set; in an N+1 or 2N hall the surviving path after a failure holds its load until the cap and the shed order bring it back under its limit, inside the time that device can carry. The chiller trip was already inside the envelope: every credible failure has its own limit, its own deadline and its own order of what to shed, computed before it happens.
The scheduler places jobs; it does not enforce limits. The cap is enforced at the GPU by its power limit, which the power controller you already run sets, and the workload cannot exceed it whatever the scheduler does. The GPU slows within seconds, no job has to checkpoint, and nothing trips. Every limit keeps a margin for the fastest ramp the row can make in the time the controller needs to react, and a limit the controller cannot enforce in time is reduced until it can. The breaker and the bypass valve remain the last line, and the plan is built so that line is never reached.
The electrical cut is instant and the water is not. VARCOTT computes the thermal time constants of your loop, how long the water buys after a cut, and sets the cooling limit so that time is never needed. The cap the controller enforces is the signed limit of each device, loaded as one file with its version and reissued only when the hall changes; VARCOTT's hourly numbers go to the people who place the load as a plan. If VARCOTT's feed goes quiet, the controller keeps enforcing the signed limit on its own, and a stale plan admits nothing the cap would not hold.
Your engineer of record signs the bounds, not the hours: the continuous rating of each device and its basis, the standard or the maker's curve, and the redundancy criterion. Every hourly limit sits inside those signed bounds. Nothing VARCOTT computes goes to a breaker or a valve; it goes to the controller as a file and to people as a plan.
We model the devices in your hall from their makers' data and solve the models together as one hall, so the limit of a row comes from the coupled system and not from any device on its own. The cooling-loop model covers the coolant distribution unit, its heat exchanger, pump, valve and controls, the manifolds, the pipes and the racks' cold plates, and is verified test by test against the Lawrence Berkeley National Laboratory's Modelica Buildings library. The power-distribution model is built the same way: each device's limit from the standards and the maker's curves, verified against the IEEE 13-node test feeder and the IEC 60909 short-circuit cases before it is used. 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 typed in by hand, and no field for time, temperature or hold. The study produces that file with the limits computed.
VARCOTT is founded by David Perez, an electrical engineer who has written power software for mission-critical facilities since 2013: the white-space power management of Fortune 500 data centers, and one of the first live electrical digital twins in data centers.
The headroom study on one operating hall is scoped in one call. It starts from last month's historian export and your one-lines, and its first number is what you paid for and could not use.