One of the exciting developments at Greenstage Power has been some collaboration with University of Auckland on our experimental machine learning module called SolarQuant. This is the stand alone app server that takes consumption or generation data and aims to learn how that energy flow happened, based on the context of when it happened and what the environmental conditions were at the time. We had a visitor to New Zealand from MIT Engineering named Paige Studer, and she was instrumental at giving SolarQuant a push forward. We interviewed Paige below on the project:
Tell us a
little about what you worked on at UofA
During my time at
the University of Auckland, I had the privilege to work on
SolarQuant, which is a program that is working to accurately predict
a building’s energy consumption given a set of inputs such as time,
weather, temperature, etc. When I arrived at the UofA, the current
state was that SolarQuant could take inputs and a building’s energy
consumption to find weights for each of the inputs. Then given only
the inputs and found weights, it would map how closely the calculated
energy consumption matched the actually energy consumption. The next
step was to see if we could get similar results by taking predicted
inputs, getting a calculated energy consumption, and compare it with
the actual inputs with actual consumption.
One of the main
factors in being able to do this was formatting the predicted weather
so that it looked the same as the actual weather, with the exception
of a type id showing that it was predicted and not actual. The
predicted weather was taken from Norwegian weather, in the form of an
XML file. The program would go through the file and find entries
that had all of the information that we needed and added them to an
initial array. This array with the predicted weather data had
problems, such as not being sorted, having repeating information,
etc. This initial array needed to be cleaned up and adjusted to make
it look like real data. A second array was constructed so that the
time of each prediction was in chronological order and separated by
thirty minutes, without any repeating or missing times. Once this
was completed, the program would go through that array, create
weather datum objects and place those objects into a database to be
used in the future.
Because the
future weather in the database looked the same as actual weather in
the database, we could use it on the SolarQuant platform. From here
the program takes the future weather data, downloads it, and instead
of training it on energy consumption, it skips straight to the
questioning stage since it is the future there is no energy
consumption to train off of. After this, John was going to add his
code and we would hopefully see predicted energy consumption and
eventually compare this with actual energy consumption for the same
time period.
Do you think
it will work?
Yes, of course I
think it will work! Theoretically it will, so if it doesn’t right
away it would be due to some bugs in the code that can be fixed. I’m
very excited to see where it goes in the future once it is working,
because there are some pretty cool applications. One in particular
that I find to be interesting is if we can accurately predict the
weather and a building’s energy consumption, given a solar/battery
system, you could potentially become smarter at when to charge and
discharge your battery.
As a developer
what are the challenges SolarQuant is going to have – what should
we get ready for?
I think that
SolarQuant will only be getting better and faster, and that it will
be important to stay flexible and be able to adjust with the program.
For instance, one thing that John and I had talked about was
possibly using a different weather source for predicted weather and
how to handle it. Do you make one function that can handle all
different weather sources, make a function for each weather source,
etc? Being open to change in the code and sources in the future will
make a difference in how well SolarQuant will continue to progress.
I think one idea that John reiterated that was helpful is we want to
walk before we run, meaning let’s make small additions/changes and
make sure that works before progressing. We don’t want to write
all this code and have it not work without us knowing why.
Did you like
NZ? We heard you went bungy jumping!?
New Zealand was
absolutely awesome! I loved meeting new people, learning about the
Maori culture, and especially loved the adventure atmosphere of New
Zealand. On the weekends I was able to go on lots of side trips, my
favorite being Queenstown where I did the Kawarau Bridge bungy jump,
Waitomo black water rafting, and sand boarding while I was visiting
the Bay of Islands.
What are the
next plans, where to?
I will begin working at a solar energy company in Southern California
that specializes in getting schools solar energy, often in the form
of carports. I will be an Assistant Project Engineer there, and I
hope to learn more about solar energy projects, continue to grow my
skillsets, and make a positive impact on the community.
 |
| SolarQuant comparing predicted consumption (blue) with actual (orange) consumption after training on 1 year of data |
Some of the results from Paige's work coming in are shown above in a
screenshot of the SolarQuant interface. The trained network predicted a
time series in light blue here, and the actual power consumption is
shown in orange. Thanks once again to Dr. Nirmal Nair at University of Auckland ECE who made this possible! And developers can checkout SolarQuant as it progresses here: git@github.com:SolarNetwork/solarquant.git
