Tuesday, October 24, 2017

SolarQuant gets a push forward from University of Auckland

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

No comments: