Quantum Solar Optimization

The data

The data behind the numbers

The $455.72 is only as good as the data under it. The sunlight, the prices and the household use all come from public U.S. government datasets. None of it is made up, and you can get all three yourself.

What I use

Three datasets

One for each of the three things a day is made of: what the panels make, what power costs, and what the house uses.

Sunlight

NREL PVWatts, version 8

U.S. National Renewable Energy Laboratory

What it is
Give PVWatts a location and a panel setup. Using years of measured weather at that spot, it works out how much power those panels make every hour for a year. That is 8,760 numbers.
Why I use it
The whole problem is that solar arrives on the sun’s schedule, not the household’s. If I made up the sunlight, I could make up a shape that happens to make my optimizer look good. Measured weather takes that choice away from me.
Exactly what I asked for
Latitude 39.74, longitude −105.18 (Golden, Colorado). 5 kW system, tilt 20°, azimuth 180° (facing south), standard module type, 14% system losses, hourly timeframe.
How it gets in
Fetched live from the API. It needs a free key.
developer.nlr.gov

Prices

Xcel Energy Residential Energy Time-of-Use tariff

OpenEI Utility Rate Database, U.S. Department of Energy

What it is
A public catalog of what U.S. utilities actually charge. This entry is the time-of-use plan Xcel Energy, Colorado’s biggest utility, sells to homes. Prices change through the day, and the schedule changes by month and by weekday or weekend.
Why I use it
Timing is only worth money when prices move, so this is the input that decides whether the battery is worth anything. Using a real published tariff means $455.72 is what this plan would have paid, not what a made-up one would.
Exactly what I asked for
The summer season (June–September) carries the higher on-peak rate. Weekends are billed at one flat price, which is why all $455.72 comes from weekdays.
How it gets in
Fetched live from the API, one request per month and day type, and remembered afterwards, so a full year costs only a handful of calls.
Rate 69bd927af5cd25efec0e9aad

Household use

NREL ResStock End-Use Load Profiles, 2024 release

U.S. Department of Energy

What it is
A model of how American homes actually use electricity, built from real building data. I use the Colorado single-family-detached set, which adds up 15-minute readings across about 1.49 million homes for a year.
Why I use it
The battery is only useful against real demand. Household use decides how expensive the evening is to cover. A flat or made-up load would quietly change the answer.
Exactly what I asked for
Four buckets: summer and winter, each weekday and weekend. Roughly 28 kWh a day in summer, 31 in winter, with the expected overnight low and evening peak.
How it gets in
Kept in the repository as four 24-hour CSVs, so the project runs with no download. The script that rebuilds them from the original 45 MB file is in there too.
OEDI submission 4520

Do it yourself

How to get the same data

All three are free and public. Nothing here is behind a login I have and you do not.

01

Get a free NREL key

PVWatts and the rate database are both served from developer.nlr.gov. Signing up is free and takes a minute. Set the key as an environment variable, or put it in a .env file at the root of the repository.

02

Fetch

The program asks PVWatts once for a full year, and the rate database for the tariff. Both are saved to disk, so the year downloads once instead of 365 times. The ResStock profiles are already in the repository.

03

Check

Every response is checked before it is used: no sun at night, sensible midday peaks, 24 prices at believable levels. The tests run against saved copies, so they never need the network or my key.

04

Align

All three land on the same 24 hourly slots. Energy is added up within each hour and the price for that hour is attached, so a day becomes three lined-up lists plus the battery’s settings.

terminal

export NREL_API_KEY=your_key_here

python -c "from quantum_solar import annual_savings; print(annual_savings(39.74, -105.18))"

That prints the same $455.72 the rest of this project is built on. If it does not, one of us has a bug and I would like to know which.

One detail that matters

Why the calendar is pinned to 2018

The ResStock profiles average the 22 July weekdays exactly as the 2018 calendar defines them. So when my program asks whether day 193 is a weekday, it has to use 2018 too. Any other year would put weekday household patterns on days the source data treated as weekends.

2018 is also not a leap year, so 365 days line up exactly with the 8,760 hours PVWatts returns and there is no February 29 to handle. Both reasons are written into the code, so nobody makes the year adjustable later and breaks the alignment.

What this data does not cover

Holidays are billed as ordinary weekdays, because the rate database carries no holiday schedule and ResStock folds holidays into its weekday averages. The tariff assumes power sells back at the price it was bought for, which real Colorado export credits do not. Battery round-trip losses are not modeled. These are the prices as of August 2026.

Credit

Whose data this is

PVWatts and ResStock are published by the U.S. National Renewable Energy Laboratory. The Utility Rate Database is run by the Department of Energy’s OpenEI project. None of the datasets is mine. My part is picking them, checking them, and lining them up so they describe the same house on the same day.

Back to the projectThe technical details

Keep reading

The rest of this project

Quantum Solar OptimizationBack to the project pageSolar and storage primerHow panels and batteries actually work, from zeroHow it worksThe technical answers, including every number on the project pageThe quantum implementationFrom a day of decisions to a circuit, with the codeRun it yourself, freeA guide to sending your own circuit to a real quantum computerWhat I got wrongThe four retractions and the two bugs behind them