Headroom

Inspiration

Clean energy is waiting on the grid. At the end of 2024, 956 GW of solar was waiting in U.S. interconnection queues, and the median project now takes more than four years from request to operation (Berkeley Lab, Queued Up 2025). Smaller projects that connect to local distribution grids face the same question: can this part of the grid take it? That answer usually comes from power-flow studies, one request at a time. I wanted a tool that answers it for every location at once, shows why, and is honest about how sure it is.

What it does

Headroom runs on a full-size 20 kV distribution grid (pandapower's MV Oberrhein network: 177 buses, 181 lines, two 110/20 kV substations).

• Try a project: pick any bus and add solar. A full AC power flow runs in a few tens of milliseconds, and the one-line diagram shows the result live: moving dots follow the real direction of power, lines change colour with loading, and a gauge in every bus shows how close it is to the voltage limit. Add 3 MW at the farthest bus on a typical day and you watch the power reverse back toward the substation. Switch to the worst case and the end of the feeder turns red as the voltage passes 1.04 pu.
• Capacity map: for any project size, every bus lights up firm (fits even in the worst case), flexible (fits in 95% of conditions, so it could connect now with an agreement to curtail in the rare conditions where it doesn't) or can't. At 5 MW: 117 of 177 buses are firm and 152 are flexible, so 35 more locations open up with no new wires.
• Proof: the model's test results against the real solver, and a live race: 17,700 capacity searches done in seconds, against an estimated hour and a half with the power flow alone.

How I built it

1. Physics engine (pandapower): add a project, run the AC power flow, and check voltage (at most 1.04 pu) and line and transformer loading (at most 100%).
2. Capacity search: bisection from 0 to 20 MW in 0.1 MW steps, about 10 power flows per bus. Firm capacity is the result in the worst case: load at 10% of peak and the other generators at 80%.
3. Training data: 60,000 solved scenarios (bus, project size, load level, generation level), plus extra samples near each bus's pass/fail boundary and at the edges of the condition ranges.
4. ML model (scikit-learn HistGradientBoosting): predicts the three numbers the check uses (highest voltage, busiest line, busiest transformer) from 19 features, including physics hints such as the voltage-rise estimate

$$\frac{\Delta V}{V} \approx \frac{P R}{V^2}$$

where R is the grid's resistance seen from the bus.

1. Flexible capacity: the model runs the same search for every bus under 1,000 sampled grid conditions and keeps the largest size that passes in at least 95% of them:

$$C_{95}(b) = \max P \text{ such that } \Pr(\text{pass}) \ge 0.95$$

Then the real solver rechecks every bus on 50 new conditions and lowers any capacity that fails more than 5% of them. It lowered 96 of 177 buses, by at most 0.7 MW. The model is never trusted on its own.

1. Interface: Streamlit plus a custom HTML, SVG and JavaScript component that draws the whole grid as a live one-line diagram. It runs fully offline.

The numbers

• Pass or fail agrees with the real power flow 98.0% of the time on 12,000 scenarios the model never saw. A simple baseline gets 59.3%.
• It says "pass" when the solver says "fail" only 1.0% of the time, and still agrees 96.6% of the time close to a limit.
• Its capacity is off by 0.18 MW on average against the solver's own search.

Challenges I ran into

• One number hides most of the story. The grid as shipped is the worst case, so a single capacity per bus understates what fits most of the time. Splitting it into firm and flexible turned a pass/fail map into a decision tool.
• Errors near the limit matter most. A wrong "pass" is the dangerous mistake, so I added physics features and boundary-focused training data, measured accuracy near the limits separately, and kept the solver recheck as a safety net.
• Drawing 177 buses so a person can read them. I laid the radial grid out as a compact one-line diagram, with every line's animation driven by the solved power flow.
• I'm new to Python, so every step was also a lesson in running, testing and committing code.

Accomplishments that I'm proud of

• A complete pipeline built during the hackathon: physics engine, 60,000 solved scenarios, a model, two capacity maps and a live interface.
• Showing reverse power flow and voltage rise as they happen, not just reporting a number.
• The flexible map: 35 more buses can take a 5 MW project.

What I learned

Most of this grid is limited by voltage, not by wires. In the worst case, 112 of 177 buses hit the 1.04 pu limit first, 57 hit a line limit and 6 hit the substation transformer. Capacity falls along each feeder: the farthest bus takes only 1.9 MW firm, but 3.0 MW in 96% of sampled conditions. I also learned that a fast model is only useful with a check that catches its mistakes.

What's next for Headroom

• Smart inverters: at the farthest bus, letting the inverter absorb reactive power raises its worst-case capacity from 1.9 MW to 4.0 MW at power factor 0.95, and to 9.3 MW at 0.9.
• Real feeder data from a utility (with its written permission), and hourly conditions instead of samples.
• Estimating how many hours a flexible project would be curtailed each year.
• Talking to utilities and solar developers about a pilot.

How I used AI

I built Headroom solo with Claude (ANTHROP\C). I chose the problem, made the project decisions (the grid, the limits, the conditions, firm versus flexible), directed the build step by step and checked the results as I went. I wrote the first step of the capacity search myself. Claude Code wrote most of the code from my prompts, and Claude helped me plan the project and design the interface.

Built With

• claude
• javascript
• networkx
• numpy
• pandapower
• python
• streamlit