Lab 02 — Power & Thermal Budget Calculator

Phase: 01 — Rack-Scale Foundations | Difficulty: ⭐⭐⭐☆☆ | Time: 3–4 hours Language: Python (stdlib only) | Hardware: none

Concept primer: ../WARMUP.md Ch. 4 (power) & Ch. 5 (cooling), ../HITCHHIKERS-GUIDE.md §3–§4.

Run

python3 solution.py     # evaluates three rack scenarios + self-tests

0. The mission

Build the tool that prevents 2 a.m. outages: a calculator that decides whether a rack configuration is safe on power and cooling, with redundancy modeled correctly. This is the math a rack manager applies before every deployment and every "can we add a node?" request — and getting it wrong (budgeting to nameplate, or to the sum of redundant feeds) is one of the most common, most expensive infrastructure mistakes.

Two questions you must be able to answer at the end:

  1. Why is the safe load on two N+1 feeds equal to one derated feed, not two?
  2. Why do you multiply every breaker by 0.8 before you do anything else?

1. The three rules encoded

Rule (WARMUP)In the code
3-phase power: √3·V·I·PF (Ch. 4)three_phase_kw()
80% continuous-load derating (Ch. 4)BREAKER_DERATE, PowerFeed.derated_kw()
N / N+1 / 2N redundancy (Ch. 4)PowerBudget.usable_kw()
Heat removed = flow·cp·ΔT; 1 kW = 3412 BTU/hr (Ch. 5)CoolingLoop.removable_kw_at_dt()
Power capping to fit (Ch. 4)RackConfig.cap_to_fit()

2. What the run shows

Three scenarios, same hardware, different answers — the whole lesson in one screen:

  • Scenario A (fits): 8 nodes at 1.8 kW = 15 kW on N+1 (usable ≈ 16.9 kW). Passes, but note the low power headroom (+1.9 kW) vs huge cooling headroom — power is the binding constraint here, as it usually is in dense AI racks.
  • Scenario B (over budget): denser nodes push it to 19.8 kW > 16.9 kW usable. The tool fails it and proposes a per-node cap (2.04 kW) that would make it fit — trading a little performance for a safe deployment.
  • Scenario C (no redundancy): the same 19.8 kW load "fits" if you drop to N (no spare) — usable jumps to 33.8 kW. This is the dangerous shortcut a tired engineer reaches for; the tool makes the redundancy tradeoff explicit instead of hidden.

The contrast between B and C is the point: redundancy is a choice with a power cost, and your tooling should surface it, not silently assume it away.

3. Extension exercises (do them — this is the lab)

  1. Simulate a feed failure: add PowerBudget.with_failed_feed(name) and re-check the load under the surviving feeds. Confirm that a config sized for N+1 still passes after one feed dies, and that an N-sized config goes critical. This is the redundancy promise, verified.
  2. Real cooling at risk: drop the CDU flow (a failing pump) from 120 to 40 L/min and re-evaluate. Watch a previously-fine rack become cooling-bound. Then raise max_return_temp_c and explain why running hotter buys capacity but shrinks the safety margin to throttle.
  3. Per-component power, not flat per-node: replace node_power_kw with a list of components (accelerators at 350 W, CPU at 350 W, NIC at 25 W) and compute draw from the bill of materials — then wire this lab to Lab 01's model so the calculator consumes the inventory graph directly.
  4. Live headroom monitor: instead of a static node_power_kw, accept measured draw (you'll get this from the Phase 04 PDU/CDU simulator) and emit a Prometheus-style rack_power_headroom_kw gauge (foreshadows Phase 07). Alert when headroom < 10%.

4. Common pitfalls

  1. Budgeting to the sum of N+1 feeds — the #1 real-world outage cause. Usable is one derated feed, because the survivor must carry everything.
  2. Skipping the 0.8 derate — a breaker sized to its nameplate trips under sustained load. Derate first, always.
  3. Confusing rated capacity with ΔT-limited capacity — a CDU rated 130 kW only removes that much if flow and ΔT allow; at low flow or low ΔT it removes far less. removable_kw_at_dt() takes the min of the two for a reason.
  4. Assuming nameplate = draw — measured power is usually 40–70% of nameplate; budgeting to nameplate strands capacity, budgeting to measured needs telemetry and capping as a safety net.

5. What this lab proves about you

You can do — in your head and in code — the power/cooling math that gates every rack deployment, and you understand redundancy as an explicit, costed tradeoff rather than a checkbox. In an interview, "two 30A 415V feeds, N+1, how much load?" is a fast filter; you answer with √3, the 0.8 rule, and "one derated feed ≈ 17 kW, because the survivor carries it all" — and then you mention capping and measured-vs-nameplate as the levers that let you push utilization safely. That's the difference between a coder and someone who can be trusted with a 120 kW rack.