A 5 MWh battery sounds substantial. At a constant 50 MW electrical load, however, the useful question is: how many seconds can it bridge after the utility disappears?
Here is a reproducible example from Datacenter Twin Lab, an early-alpha power-continuity simulator I maintain with Codex assistance. The example makes the energy accounting visible before adding more complicated failure scenarios.
Start with the result
Assume 5,000 kWh of stored battery energy, a 50,000 kW aggregate IT load, 0.90 discharge efficiency, and 0.95 distribution efficiency. The generator cannot start.
the energy delivered to IT = 5,000 × 0.90 × 0.95 = 4,275 kWh
ride-through = 4,275 / 50,000 × 3,600 = 307.8 seconds
Utility supply fails at 300 seconds elapsed. The battery therefore depletes at 607.8 seconds elapsed, not 307.8 seconds elapsed. Utility restoration at 900 seconds leaves a 292.2-second service gap in this simplified case.
| Quantity | Value | Meaning |
|---|---|---|
| Stored reserve | 5,000 kWh | Energy before conversion losses |
| Energy delivered to IT | 4,275 kWh | Stored reserve multiplied by both efficiencies |
| Ride-through | 307.8 s | Time supported after the outage |
| Depletion timestamp | 607.8 s | Time measured from the simulation start |
| Unserved IT energy | 4,058.33… kWh | 50,000 × 292.2 / 3,600 |
This is an aggregate electrical-load example. It does not predict whether a GPU job finishes or whether a regional grid can support a new datacenter.
Inspect the model, not just the number
Actual screenshot of the preserved 0.3.0a0 interface and its 1 MW / 100 kWh reference fixture. It predates the current browser entry. The 50 MW / 5 MWh example scales demand and reserve by 50, preserving the same ride-through duration. The cover is conceptual project artwork, not a facility photograph or engineering single-line diagram.
A small continuity model needs more than energy divided by power. It needs to track when sources fail, whether the generator becomes available, which electrical paths survive, conversion losses, and the point where stored energy runs out. The useful output is a timeline plus an energy ledger whose inputs can be inspected.
For example, a surviving path rated at 700 kW gross delivers only 665 kW after a 0.95 distribution efficiency. Against a 1,000 kW IT request, that leaves a 335 kW shortfall. Over ten minutes, the corresponding unserved energy is 55.8333… kWh. Power and energy answer different questions.
Reproduce a smaller case
With Git and Python 3.12 or later, this source revision provides a fixed reference:
git clone https://github.com/mohammadrezwankhan/datacenter-twin-lab.git
cd datacenter-twin-lab
git checkout d4b736e4d930043c5edae988a8e8b1f4b7d40a53
python -m datacenter_twin simulate --preset generator_failure
This command runs the 1 MW / 100 kWh reference case. Expected depletion is 607.8 seconds elapsed. It uses the standard-library core from the checkout; the optional local API and dashboard have additional dependencies documented in the repository.
The browser version starts with JavaScript arithmetic. Verify against Python loads the reference engine on demand. Browser/native equality checks test software consistency; they are not proof of physical calibration.
One input distinction that matters
Lesson 3 disables charging in both its 100 and 50 kWh cases. Halving stored energy halves ride-through from 307.8 to 153.9 seconds. The elapsed depletion timestamp moves from 607.8 to 453.9 seconds; that timestamp does not halve because both outages begin at 300 seconds.
The CLI generator-failure preset permits charging before the outage. If its initial reserve is reduced to 50 kWh, pre-outage charging changes the energy available at outage onset. Comparing that run with the charging-disabled lesson without checking inputs would produce a misleading disagreement.
Where this approach helps—and where it stops
The current model covers utility loss and restoration, generator delay or failure, finite storage, electrical path capacity, and shared failure domains. Deterministic JSON results and Markdown/HTML reports make a run inspectable.
These are synthetic teaching fixtures. The project does not model cooling transients, network congestion, workload scheduling, live telemetry, protection coordination, AC transients, or facility-certified uptime. A real equipment-sizing or safety decision needs a different validation process and site evidence.
The source and assumptions are available in the repository. Independent external technical review has not yet been obtained. A useful review starts with one reconstructed calculation and a precise description of any mismatch—not a broad claim that the entire model is validated.

Top comments (1)
Some comments may only be visible to logged-in visitors. Sign in to view all comments.