DEV Community: Mohammad Rezwan Khan

What a 5 MWh battery buys a 50 MW load: a reproducible outage example

Mohammad Rezwan Khan — Wed, 23 Sep 2026 08:55:00 +0000

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.

When does a second RC branch earn its place in a battery model?

Mohammad Rezwan Khan — Mon, 10 Aug 2026 20:17:25 +0000

Adding states to a model is easy. Showing that they explain repeatable behavior outside the calibration record is harder—and much more useful.

A one-RC equivalent-circuit battery model represents polarization with one dynamic voltage state. A two-RC model separates that response into fast and slow branches:

dV_fast/dt = -V_fast/(R_fast C_fast) + I/C_fast
dV_slow/dt = -V_slow/(R_slow C_slow) + I/C_slow
V_terminal = OCV(SOC) - I R0 - V_fast - V_slow

That extra branch is not automatically an improvement. It introduces another resistance, capacitance, and state, which can increase parameter correlation and make identification fragile. The second branch earns its place only when the data expose two distinct recovery scales and the fitted behavior survives a waveform that was not used for calibration.

A small held-out test

I maintain an open MATLAB example that fits positive two-RC parameters to a synthetic voltage record, then evaluates the fitted model on a separate pulse profile.

Quantity	Result
Calibration RMSE	0.401 mV
Held-out RMSE	0.440 mV
Estimated fast time constant	2.01 s
Estimated slow time constant	33.88 s

The close errors suggest that the two fitted recovery scales are not limited to the calibration waveform in this synthetic benchmark. They do not establish that the parameters describe a physical commercial cell.

Why the split matters

A low calibration error can hide several failure modes:

the optimizer may have learned one particular current waveform;
two parameter combinations may produce nearly identical calibration voltage;
the OCV-SOC curve may absorb error that belongs to polarization dynamics;
the pulse duration may be too short to identify the slow branch;
sensor noise or preprocessing may dominate millivolt-scale differences.

A held-out pulse does not solve every identification problem, but it asks a better question: does the fitted structure retain useful predictive behavior when the excitation changes?

Reproduce the check

The example is deliberately small and inspectable. From the repository root:

addpath('examples');
check_battery_2rc_fit

The runnable files, assumptions, and expected output are in the MATLAB two-RC model and identification example.

The implementation keeps resistance and capacitance positive, reports the two time constants explicitly, and separates calibration from validation output. A no-plot check makes the numerical behavior reproducible in a terminal or CI job.

What I would require for measured-cell use

Replacing the synthetic record is more than swapping a CSV file. A defensible measured workflow should document:

cell chemistry, capacity, temperature, age, and initial SOC;
current sign convention, sampling, synchronization, and sensor uncertainty;
an independently estimated OCV-SOC relationship;
separate calibration and held-out current profiles;
parameter sensitivity or confidence information;
residuals across SOC and temperature, not only one aggregate RMSE;
a same-data comparison against the simpler one-RC baseline.

The decision rule should be practical: retain the second branch only if its held-out residual improvement matters for the intended estimator, controller, or teaching objective and its parameters remain stable enough to interpret.

The useful question

For people who identify equivalent-circuit models from pulse tests: how do you choose pulse and rest durations that expose a slow branch without making the fit ill-conditioned?

Disclosure: I maintain the linked repository. This article was prepared with AI assistance and reviewed against the repository's documented equations, outputs, and limitations.

Hello DEV: Building Safer, Smarter Battery Systems

Mohammad Rezwan Khan — Mon, 10 Aug 2026 19:29:28 +0000

Hello DEV Community! 👋

I’m Mohammad Rezwan Khan, an Electrical R&D Engineer and PhD focused on battery thermal management systems (BTMS), lithium-ion battery safety and efficiency, and battery energy storage systems (BESS).

Why I joined

Engineering gets better when ideas move between disciplines. Battery challenges sit at the intersection of electrical engineering, thermal science, controls, data, and software. I joined DEV to share practical lessons from that intersection and learn from builders working across the stack.

What I care about

Safer lithium-ion systems
Smarter thermal management
Reliable, efficient energy storage
Clear engineering models and workflows
AI-assisted tools that help engineers reason and build faster

I’m especially interested in how simulation, data analysis, and automation can shorten the path from an engineering question to a trustworthy answer.

What I hope to share

I plan to write about battery-system engineering, BTMS, safety, BESS, modeling, and the tools that make technical R&D more effective. My goal is to keep posts practical, understandable, and useful to both specialists and curious developers.

Let’s connect

If you work on batteries, energy storage, embedded systems, modeling, AI-assisted engineering, or adjacent fields, say hello. I’d love to learn what you’re building.

What is one engineering challenge you’re excited to solve right now?