Quantum Solar Optimization

The data

The data behind the numbers

The $455.72 is only as good as the data under it. Sunlight, prices and household use all come from public U.S. government datasets, which you can get 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

National Laboratory of the Rockies, U.S. Department of Energy

What it is
Given a location and a panel setup, PVWatts works out from years of measured weather at that spot how much power those panels make every hour for a year. That is 8,760 numbers.
Why I use it
Because the whole problem is that solar arrives on the sun’s schedule, not the household’s, the shape of the solar day has to come from measured weather rather than from an assumption I typed in.
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, which needs a free key.

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, on a schedule that changes by month and by weekday or weekend.
Why I use it
Timing is only worth money when prices move, which makes the tariff the input that decides whether the battery is worth anything at all. Because the tariff is a real published one, $455.72 is what this plan would actually have paid.
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 afterward, so a full year costs only a handful of calls.

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
A battery is only useful against real demand, and household use sets how expensive the evening is to cover. Averaging that away into a flat 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.

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, saving both 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, where 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.

Getting a key and pulling the data down is the long way, although it is the way that lets you check the numbers against their sources. To just see the answer, the repository ships a year of data already downloaded:

terminal

python -m quantum_solar

One command, no key and no network, once the repository is cloned and installed: four lines, on the project page. With nothing beyond numpy, it prints a real day's plan, the three-way split across the year, the sizing sweep and the payback. Because it runs on a battery that loses nothing, the payback it prints is 25 years rather than the 28 the sizing page reports. Add --round-trip 0.90 --export-ratio 0.25 for the figures with losses and a realistic export credit.

One detail that matters

Why the calendar is pinned to 2018

Because the ResStock summer profiles average every June-through-September weekday exactly as the 2018 calendar defines them, my program has to use 2018 too when it asks whether day 193 is a weekday. 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 on this page assumes power sells back at the price it was bought for, which real Colorado export credits do not, and the $455.72 it produces is for a battery that loses nothing. Both of those are priced on the sizing page. These are the prices as of August 2026.

Credit

Whose data this is

PVWatts and ResStock come from the National Laboratory of the Rockies, a Department of Energy lab in Golden. Until December 2025 the lab was named the National Renewable Energy Laboratory, and the datasets still carry the NREL name. The Utility Rate Database is run by the Department of Energy’s OpenEI project. None of the datasets is mine. My part is picking the datasets, checking them, and lining them up so all three describe the same house on the same day.

The prices are a snapshot of one tariff version, pinned by its database label. On August 20, 2026 Colorado's utility commission approved an Xcel rate increase, about $5 a month on an average residential bill (proceeding 25AL-0494E), with the new rates taking effect at the end of December 2026. Until then the modeled prices match what is billed. After that they will not, although the label says which version every number here was measured against.