Project
In progressQuantum Solar Optimization
My program finds the cheapest way to run a home solar battery - it saves a real Colorado home $1.93 on a typical summer weekday. I then ran the same problem on a real quantum computer to measure how it does against an answer I already knew.
Start here
The whole idea, in four steps
A home with solar panels and a battery
The panels make power when the sun is out. The battery can store that power, or store cheap power from the grid, and save it for later.
Electricity prices change all day
Power is cheapest overnight and most expensive in the evening, when everyone comes home and turns everything on.
So timing is worth money
Fill the battery when power is cheap or the sun is shining. Run the house off the battery during the expensive evening hours. Same electricity, smaller bill.
My program finds the best plan
It picks the cheapest schedule for the whole day. Then I rebuilt the same problem in a form a quantum computer can attempt, to see how close it gets.
Try it yourself
Steer the plan
This runs the same optimizer live in your browser. Change the battery or the prices and watch the cheapest schedule redraw instantly.
This day's bill
$2.56 saved
Without a battery: $3.19
With this plan: $0.63
The day: price, solar, and home use
The cheapest plan the program finds
Raise the evening peak and the savings climb. Even at a flat $0.14 the battery still pays off, by banking free midday solar for the evening.
This is an interactive model of the same problem, on a day shaped like the real Golden, CO summer weekday the project studied. The live number is this model's own answer; on the fully real data, the optimization saved about $1.93. Either way the mechanism is the point: the same kind of program found the cheapest schedule out of ten billion in about a tenth of a millisecond, and that answer is what the quantum experiment later gets graded against.
Why it matters
Buying electricity on sale
If you have ever waited for something to go on sale before buying it, you already understand this project. A battery lets a home buy electricity when it is on sale (overnight, or free from its own panels) and spend it when the price roughly triples in the evening. Picking the right hours can save a home hundreds of dollars a year.
And it is not just one home. More houses add solar panels and batteries every year, and each one faces this same puzzle every single day. Better plans mean lower bills, and they also take pressure off the power grid at its busiest hours, which is when blackouts happen and when the dirtiest backup power plants get switched on.
Want more background?
I wrote a short primer on how solar panels and home batteries actually work.
Read the primerThe result
One day on a real home's bill
All three inputs are now real. Here is what the program did with them, for a home in Golden, Colorado, on a typical summer weekday.
What the day costs the house
No solar, no battery
The house buys every bit of power from the grid.
$6.11
Add solar panels
The sun covers the daytime, but mornings and evenings still cost.
$1.43
Add my program's battery plan
Charge in the cheap hours, spend in the expensive ones.
-$0.50
The caveats
This is one summer weekday. A few things it does not yet capture:
- On weekends this utility charges one flat price all day, so timing is worth exactly $0 there. That is the whole idea in one fact: timing is only worth money when prices move.
- Winter prices are lower, so a full year would not save at this daily rate.
- The model still assumes power sells back at the same price it buys, and ignores the small losses inside the battery.
Turning one good day into a real full-year number is the next step. The notebook that computes all of this is public in the repo.
The catch
Why not just try every plan?
Every hour, the battery can do one of three things: charge, do nothing, or power the house. That sounds simple, but the choices are connected. If you drain the battery at noon, it is empty at 7 PM when you need it most. So you cannot decide each hour on its own; you have to plan the whole day at once.
3
choices every hour: charge, wait, or use
24
hours in a day, all connected
10¹⁰+
possible plans for one single day
Ten billion plans is more than you could check by hand in a lifetime. Problems like this, where you have to pick the best combination out of an enormous pile, are called optimization problems, and they show up everywhere: airline schedules, delivery routes, stock portfolios. This battery is my small, checkable version of one.
The classical method
How the program finds the best plan
The slow, sure way is to check every plan and keep the cheapest. My program can do that, and it is useful for testing, but it only works for short days; the pile of plans grows too fast.
The fast way rests on one observation: to make the best choice at 8 PM, you do not need the whole story of the day so far. The only thing that matters is how full the battery is right now. So instead of tracking billions of complete plans, the program walks through the day hour by hour and remembers just one fact for each possible battery level: the cheapest way to arrive there. At the last hour it reads off the cheapest ending and traces the path back. Computer scientists call this dynamic programming. Both methods are exact: they do not guess, they find the single cheapest plan.
And the fast method really is fast: a full day, solved perfectly, in about a tenth of a millisecond. For one home, this ordinary program wins outright. Which raises a fair question: why involve a quantum computer at all?
The quantum part
Where the quantum computer comes in
What it is for
Not to save money: the classical method above already solved the full day, all ten billion plans of it, in a tenth of a millisecond. The quantum computer is the thing under test, and it was tested on tiny scale models of the day with a few hundred possible plans at most. Because the true answer to each scale model is known, every quantum result can be graded exactly, showing how much of the quantum method survives on a real machine.
How it works
A quantum computer stores information using the physics of very small things, like single atoms or tiny superconducting circuits (IBM's machines, which I used, are the latter). Its bits, called qubits, can hold every combination of a set of yes/no choices at once, but there is a catch: when you measure, you get back just one of them. So the algorithm I use (called QAOA) has one real job: arrange the interference among all those held-at-once possibilities so that, at measurement time, the cheap schedules come out far more often than chance.
Why the measurement matters
A much bigger version of this problem exists. Thousands of homes with batteries share the same wires and chase the same cheap hours, so their choices affect each other, and coordinating all of them at once is where exact classical methods hit their own wall. Quantum optimization is seriously being explored there, though it is an open question: classical methods refined over decades are very good, and no one has yet shown a quantum computer winning on a practical problem. My one-house problem is a scale model of it, small enough that the exact answer is known.
What the simulator showed
On a simulator (a regular computer imitating a perfect quantum one), the smallest test problems went well: the best answer out of 4,096 draws was the exact cheapest plan every time, and in the best runs a single draw was about twice as likely to be the cheapest plan as a random guess.
The advantage was not consistent: other runs did worse than guessing (the chart shows both), and past a few slots it becomes too small for 4,096 draws to detect. The biggest test problem, 6 slots, took about 20 to 40 minutes to simulate, against a tenth of a millisecond classically.
How to read the chart
The chart compares the quantum machine to random guessing, not to the classical program; that contest is settled and could only ever say quantum lost. The live question is whether the quantum part does anything at all. Each measurement returns one schedule, like a draw from a hat, and a working circuit makes cheap schedules come out more often than their fair share. So the chart plots how much more often good plans appear than chance would produce: above the dashed line beats chance, on the line is nothing luck alone would not do.
Ceiling
The classical program's perfect answer
The experiment
Where does the quantum machine land?
Floor
Random guessing
What the real machine showed
I sent the four smallest circuits to ibm_fez, a real 156-qubit IBM quantum computer, for 7 seconds of machine time. Two findings came back:
- Noise got steadily worse as the circuits got bigger, exactly as expected. One way to measure this is the gap between the real machine's results and the perfect answer, on a scale where 0 is a perfect match and 1 is completely different. That gap grew from 0.12 on the smallest circuit to 0.46 on the largest, rising in step with the number of noisy two-qubit operations, which went from 37 to 290.
- Only the smallest, simplest circuit still beat random guessing. The other three were drowned out by the hardware's noise.
I had also predicted that simpler circuits would always survive noise better than deeper ones. That did not cleanly hold: at these sizes the signal sat near the measurement floor, and the ordering mostly reflected how well each circuit had been tuned rather than its depth. A prediction that does not pan out is still a result, and writing it down beforehand is what stops me from quietly dropping it.
Want to try this yourself? IBM's quantum computers are free to use, and I wrote a guide to running your own circuits on one, from signing up to reading the results. How a normal laptop can imitate a quantum computer at all is explained on the technical page.
Real data
Where the numbers come from
The planner needs three inputs for a day. As of July 9, all three are real.
Sunlight: real
From PVWatts, a public tool run by the U.S. National Renewable Energy Laboratory. Give it a location and a panel setup, and it estimates from years of measured weather how much power those panels produce, hour by hour. My program asks it about a site in Golden, Colorado.
Source: NREL PVWatts API (v8)
Prices: real
From the Utility Rate Database, a public catalog of U.S. electricity rates run by the Department of Energy's OpenEI project. My program reads the time-of-use plan that Xcel Energy, Colorado's biggest utility, offers its residential customers.
Household use: real
From ResStock, a U.S. Department of Energy model of how American homes actually use power, built from real building data. My program uses its typical summer-weekday pattern for a single-family Colorado home, about 30 kWh a day.
How the data was used
- Fetch. The program asks PVWatts for a full year of hourly generation at latitude 39.74, longitude -105.18 (Golden, Colorado) for a 5 kW rooftop system facing south, and asks the Utility Rate Database for the RE-TOU tariff. The ResStock household profile was prepared once: Colorado's single-family-detached data, averaged over the 22 July weekdays of its reference year into one 24-hour pattern, then saved into the repo so no download is needed to run the project.
- Check. Every response goes through sanity checks (no solar generation at night, believable daytime peaks, sensible price levels) and is cached on disk, and the tests run against saved copies so they never depend on the network.
- Align. One day is picked (day 172 of the year, near June 21) and everything is put on the same 24 hourly slots: energy amounts are summed within each hour, prices are averaged.
- Solve. Those three series, plus a 10 kWh battery that can move 2 kWh per hour and starts half full, become the problem that every solver on this page runs on.
Data credits: 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; the tariff belongs to Xcel Energy. This is an independent student project, not affiliated with or endorsed by any of them. The exact fetch-and-check code is in the repo's data module, and the derivation of the household profile is documented there file by file.
What I give the program
One day, as lists of hourly numbers: the three inputs above, plus the battery's size and how fast it can safely charge or discharge.
What it gives back
An instruction for every hour: charge, wait, or run the house off the battery. Along with it, the battery's level across the day and the day's total electricity cost under that plan. The chart below is exactly this output, drawn.
Under the hood
The plan behind the bill
Charge when power is cheap, use it when power is expensive.
The program's raw answer is just a list of numbers: for each hour, charge, wait, or use. To make that readable, a short script I wrote draws the day as a picture. The top panel shows the three inputs (the price of electricity, the home's use, and its solar generation); the bottom panel shows what the program decided to do about them: green bars where it charges, red bars where it runs the house off the battery, and a black line tracking how full the battery is. You can check the logic with your own eyes: the green sits under the cheap and sunny hours, the red under the expensive evening ones.
Verification
How I know the answers are right
It is easy to write a program that produces a plan. It is harder to prove the plan is actually the cheapest one. So I solve every day with two independent exact methods - a slow one that checks every possible plan one by one, and a fast clever one - and they must agree perfectly, every time. The quantum method is then measured against that verified answer; how close it gets is the experiment. These checks re-run automatically every time I change the code, so a mistake would be caught right away.
Check it yourself
Every line of code, every test, and the full history of the project are public, so anyone can read it, run it, and check my claims.
quantum-solar on GitHubProgress notes
Where things stand
July 11, 2026
It ran on a real quantum computer
I sent the four smallest circuits to ibm_fez, one of IBM's 156-qubit quantum processors, using 7 seconds of quantum-computer time. The findings are in the quantum section above; the raw counts are in the repo at docs/results/hardware_counts.json. A separate walkthrough page explains how anyone can sign up and run their own circuits on IBM's free quantum computers.
July 9, 2026
Predictions, written down before the run
Before spending any real quantum machine time, I wrote down exactly what I expect to happen and how I will judge the results, and committed it to the repo, so I cannot move the goalposts afterward. My main prediction: on a real, noisy machine the simpler quantum circuit should do at least as well as the deeper one, because every extra operation adds noise. I also rehearsed the full analysis on stand-in data, so when the real results arrive the only new thing will be the numbers.
July 9, 2026
A real home, a real number
The last estimated input is now real: household use comes from ResStock, a U.S. Department of Energy model of how American homes actually use electricity. With all three inputs real, I ran the first complete end-to-end day for a home in Golden, Colorado. Without solar or a battery the house would pay $6.11 for the day; with solar, $1.43; with solar plus my program running the battery, it ends the day 50 cents ahead. The battery plan itself is worth $1.93 that day. The big caveat: weekends there have one flat price, so timing is worth nothing two days a week, and a full-year number needs winter days too. That is the next step.
July 9, 2026
Staged for a real quantum computer
The program is now ready to run on IBM’s real hardware. I tuned the quantum circuit’s settings on the simulator and saved them, and wrote the submission step so that it first shows exactly what it would send and how many seconds of machine time it would use, and only spends IBM’s free monthly minutes when I explicitly say yes.
July 8, 2026
Measured how close the quantum method gets
I ran the first head-to-head study of the quantum method against the exact answer, on test problems ranging from a day split into 2 decision slots up to 6 (6 to 22 qubits). On the 2-slot problems it finds the exact cheapest plan every time. As the number of slots grows its success rate falls fast, and on the 5- and 6-slot problems it no longer lands on the exact best plan at all; any advantage over random guessing there is too small to measure with 4,096 samples. The classical method answers every one of these in under a millisecond; simulating the quantum method on the biggest problems took about 20 to 40 minutes. The full numbers and charts are in the GitHub repo.
July 8, 2026
Now using real electricity prices
The second input is real now too: the program reads the actual time-of-use rates that Xcel Energy, Colorado’s biggest utility, charges its residential customers, straight from the Department of Energy’s public Utility Rate Database. That leaves one piece still estimated, the household’s hour-by-hour electricity use. Once that is real, I can run a real day end to end and report a real dollar saving for a real home.
July 7, 2026
Now using real solar data
The program can now pull real sunlight data for an actual location (a site in Golden, Colorado) from the U.S. National Renewable Energy Laboratory’s PVWatts tool and feed it straight into the planner, with checks that the numbers make physical sense: no generation at night, sensible peaks at midday.
July 5, 2026
The program works on example data
Given a day of electricity prices, sunlight, and household use, the program finds the battery plan that costs the least, and I confirmed the answer is correct by checking it three independent ways. On the example day it charges overnight and at midday, when power is cheap or the sun is out, then uses the battery during the expensive evening hours (see the chart above). This first milestone used example numbers for all three inputs; the notes above track which of them are now real.
Verify
Check my work
Every number on this page traces back to something you can inspect or re-run.
The hardware run
IBM assigned the run a job ID when the circuits executed on ibm_fez, and my code saved it with the results:
d994b5cqp3as739tkvp0
4,096 shots, 7.0 seconds of quantum-processor time. A job ID is only viewable from the account that ran it, so the checkable part is the raw measurement counts, committed with the job ID inside, and the code that produced them.
Re-run it yourself
The demo notebook rebuilds the classical result end to end and shows the three methods agreeing (brute force, dynamic programming, QAOA):
terminal
git clone https://github.com/austinamissah/quantum-solar.git
cd quantum-solar
python -m venv .venv && source .venv/bin/activate
pip install -r requirements.txt && pip install -e . --no-deps
jupyter lab notebooks/demo.ipynb # or: pytest -m "not slow"The hardware script is spend-safe by design: it prints exactly what it would send and how many seconds it would use, and touches the real machine only with an explicit --yes-spend-qpu flag.
Status
What is next
As of July 11, 2026, the project has two results. The classical one: on fully real data for a home in Golden, Colorado, the optimal battery plan is worth $1.93 on a typical summer weekday. The quantum one: a measurement of where the hardware stands today; on a real IBM machine, only the smallest circuit beat random guessing before noise took over. The main step left is growing one good day into a full-year estimate across seasons and weekends.