# Data-center cooling — dependency experiments

Version 1.0 · October 2026 · Dan Fisher / danfisher.dev
CC BY 4.0 — https://creativecommons.org/licenses/by/4.0/

Open /examples/cooling-explorer on the website or local preview. Older /lab/cooling-explorer bookmarks redirect here.
All values, thresholds, and timing are fictional teaching choices. This is not an engineering sizing tool, resilience rating, or operating procedure. There is no connection to real equipment.

## 1. Remaining equipment is not necessarily enough capacity
1. Select Lose one cooling train. The experiment resets and is paused.
2. Advance four model minutes. Compare 80 kW generated heat with 60 kW available cooling.
3. Select a 30 kW workload. Advance a few more minutes and watch the room cool.
4. Repeat at 110 kW. Compare the rate of warming.

Discuss: Does having two installed units prove N+1 capacity? What changes when demand changes?

## 2. Compute power can outlast cooling power
1. Select Lose utility power. Advance one model minute.
2. Observe compute running on its UPS while facility cooling has no power.
3. Start facility backup. Advance two model minutes; the backup becomes ready at the end of the second interval.
4. Continue stepping. Restored cooling removes stored heat over time.
5. Compare with a fresh run where you never start backup. The workload eventually latches off under the model's thermal or power policy.

Discuss: What does the UPS actually support? Does a live IT service prove environmental capacity is adequate? Why does restoring power not instantly cool the room?

## 3. Find the common dependency
1. Select Shared pump failure. Both cooling trains are healthy, but available heat removal is zero.
2. Advance four minutes to observe the fictional thermal stop.
3. Restore the shared pump. Notice the workload remains latched off.
4. Continue stepping until temperature is at or below the fictional 27 °C restart criterion.
5. Run recovery check, then Restart workload. Watch the next few samples.

Discuss: How can duplicated equipment share a single failure? Why separate physical recovery, validation, and restart?

## 4. Electrical exhaustion without a thermal stop first
1. Select Lose utility power, then set demand to 30 kW.
2. Advance eight model minutes without starting backup.
3. Inspect the UPS reserve and latched power-stop event.

Discuss: In this model runtime is fixed at eight minutes regardless of load. What additional battery/load information would a real estimate need?

## Suggested observations
- 60 kW of cooling cannot offset an 80 or 110 kW load in this example. At 30 kW the same remaining train has capacity to cool the room back toward its 24 °C target.
- Utility loss does not initially stop compute, because its UPS is separate from the cooling supply. Continuing compute generates heat.
- Restoring equipment changes available capacity; temperature changes during subsequent model intervals.
- Shared pump loss makes both trains unavailable as heat-removal paths even when the equipment itself is healthy.
- Thermal/power stops are latched in the exercise. Recovery must meet sustained-power, cooling-capacity, and temperature checks, followed by deliberate restart.
- Actual facilities have different cooling architectures, redundancy, thermal behavior, transfer sequences, and protection limits. None of this example's thresholds are universal limits.

## Export and explain
Download the generated CSV. Each row gives end-of-step temperature, heat load, capacity, service state, and UPS reserve; heat removed refers to the interval just completed. The initial row represents the baseline rather than an elapsed interval.
Use the observation worksheet at /resources to distinguish a component status, an actual physical response, and an assumption you would need to verify at a real facility.