Weather Based Nucelar Power Derating Prediction

https://github.com/NateDeMoro/Team_10_HackArizona

Inspiration

When a heatwave pushes river temperatures past a nuclear
plant's cooling-water limits, the plant is forced to throttle back — exactly when the grid needs every megawatt
the most. Industry-wide losses to weather-driven derating
run over $200M per year, yet there is no public forecast of when it is coming. We wanted to give plant and grid
operators a way to see those dips days in advance instead of reacting after they hit.

## What it does

Weather Based Nuclear Power Derating Prediction forecasts
how much power a nuclear plant will actually be able to produce over the next 14 days, anchored on live weather,
river temperature, and streamflow data. Each day in the forecast window comes with a predicted output percentage, an uncertainty band, and a three-tier alert — operational, watch, or alert — surfaced through a web dashboard with a US plant map and a per-plant detail page. A replay slider lets users scrub back through historical dates to see what the model would have predicted on any given day versus what actually happened.

##How we built it

The offline pipeline ingests 20+ years of NRC plant
power-status records, Open-Meteo weather, and USGS water data, then trains 14 XGBoost regressors — one per forecast
horizon — with a dip-weighted point objective and a
per-horizon isotonic calibrator to remove residual bias on the dominant 100% mode. A FastAPI service serves the precomputed forecast and backtest artifacts, and a Next.js dashboard renders the chart, alert badges, and replay slider. Both services deploy to Railway as a single project, with just recipes wiring the entire ingest-train-forecast loop end to end.

## Challenges we ran into

The first model mode-collapsed onto the 100% capacity value because that is the dominant target, so we redesigned the loss with dip-weighted sample weights and added a gated
isotonic calibrator to fix the residual bias the new
objective introduced. Quantile regression for the uncertainty band failed in three different ways — we ended up replacing it with a symmetric residual band derived from validation residuals. We also discovered that most sub-95% capacity events at our anchor plant were not weather-driven at all but operator events, which forced us to add a second plant on a different watershed and document the limitation honestly in the backtest report.

## Accomplishments that we're proud of

We trained on more than two decades of public data, beat
both climatology and persistence baselines on dip-event MAE at every forecast horizon, and shipped the full stack —
pipeline, API, and dashboard — to a live Railway deployment. The architecture is plant-agnostic from the start, so adding a new reactor is a single registry entry plus the existing just recipes. We also resisted the temptation to bury the limitations of the data and the model, calling them out in both the report and the README rather than hiding behind a flattering full-slice metric.

## What we learned

The hardest part of forecasting was not the modeling itself but figuring out which metric actually mattered — full-slice MAE looked great while dip recall was useless, so we had to redefine success around the slice the product actually cares about. We also learned how patchy public infrastructure data really is: USGS water-temperature gauges get decommissioned, sensors disappear over winter, and "active" in the catalog does not mean the data is there. And we learned to be skeptical of every clever calibration trick — most of them solved one problem while quietly breaking another.

## What's next for Weather Based Nuclear Power Derating
Prediction

The most valuable next step is a dollar-value layer that
multiplies predicted MW lost by historical PJM locational marginal prices, converting forecast skill directly into
expected-loss dollars per plant per day. After that,
expanding from two plants to the full set of weather-vulnerable U.S. reactors is mostly a registry-and-data task rather than a modeling one, since the pipeline already supports it. Finally, integrating an LLM-authored operator briefing — already prototyped against Bedrock — would turn each forecast into a plain-English summary that grid operators can act on without reading the chart.

Built With

• calibration
• docker
• fastapi
• matplotlib
• next.js
• numpy
• open-meteo
• pandas
• postgresql
• python
• railway
• react
• typescript
• xgboost