Week 16: Final steps

Since this week was the final development week, there was no new topic to be teached the classes served mostly as place to clarify doubts and get feedback on the final solution. As per usual in the last week, the focus was shifted to the User Interface (UI), optimization and the conclusion of the paper.

The UI was built using the one created in Challenge 1 as a scaffold, taking advantage of its dataset management capabilities (importing, visualizing, editing and downloading) . This post will only showcase the two most relevant functions of the UI for this challenge, but a later blog post will go deeper within the UI capabilities.

The Forecast tab allows the user to pick the date range that is to be Forecasted. The request is sent to the backend and then the results are displayed on a chart, allowing the user to pick which houses are to be included in it.

Once the forecasting has been done, the planning tab is unlocked. The user picks the execution settings and then the request is made to the backend. The results can be seen on a per-period basis as well as on a fully interactive chart, that displays the forecasted and the planning recommended value for each parameter. The chart can show from none to all of the following: Consumption, Production, Flexibility, Storage, Energy Balance, Financial Balance, Purchase Market Prices and Sale Market Prices.

When connecting the planning service to the UI, the team noticed it was unviably slow. When all the houses were considered, the Particle Swarm Optimization (PSO) algorithm was taking 20 minutes for a day-long planning and escalated exponentially to over 4 hours when executed for 3-days-long planning. Even though the execution times themselves were not unviable, the solutions were far from mediocre. In order to have better solutions, PSO would have to have its number of particles, iterations and/or trials pumped up, which would result in even longer waiting times, that could easily scale exponentially.

Previously, the Flexibility used by each participant was being calculated separately by the PSO, which meant the execution time scaled exponential with the number of households selected. This solution was not scalable and did not offer many upsides versus calculating the total Flexibility used and then distributing it evenly among the households. As such, the team changed the approach - the process starts by getting the total consumption, production and flexibility of the community for each period. The PSO then generates the values for the new consumption, per period, that range between the community's Consumption Minimum (see Equation 1) and the Consumption Forecast.

Equation 1 - Consumption Minimum

On the other hand, the PSO was also calculating the Battery Load (Equation 2) for each period i, as seen in Equation 2.

Equation 2 - Battery Load

This approach did not restrict the amount the battery can charge/discharge and required heavy penalizations when the Battery Load change between periods was higher than the its Charge or Discharge Rate. This meant that there would be a lot of computing power wasted, because the charge/discharge rate limits would often be violated.

In order to fix this, the team decided to have the PSO compute the Battery Load Change instead. This allowed for a more controlled range of solutions, which always ensured the Battery Load Change did not surpass its limits (Equation 3) . However, this solution still requires heavy penalizations in order to ensure the Battery Minimum Mandatory Load and Capacity were respected. Nevertheless, this new penalization is less likely to be triggered, preventing a lot of wasted computed power.

Equation 3 - Battery Load Change

With this optimizations, the team managed to get a solution which execution time is merely dependent on the amount of periods used, meaning its usage is not limited by the size of the community. Finally, the execution time of a day-long planning for the whole community dropped from 20 minutes to 2 minutes and for 3-day-long planning, it dropped from over 4 hours to merely 5 minutes. This time improvements are also came with much better solutions, that are extremely responsive to changes in the execution's parameters.

With the presentations closing in the team will focus on preparing for them, but expect a mid-week update detailing the final solution's full capabilities.