Heat Pump Energy Flexibility by Hessam Golmohamadi- AAU- Department of Computer Science
Once upon a time, our team worked on a project that aimed to make residential heating systems more energy-efficient and flexible. We recognized that building heating systems were energy-intensive consumers and that optimizing their operation could help facilitate renewable power integration and provide flexibility for power and heat networks. Heat pumps, in particular, showed promise in achieving these goals.
However, optimizing the operation of heat pumps requires precise estimation of the dynamic thermal characteristics of the building, such as thermal resistance and capacity, which are specified by differential equations mathematically. Inaccurate estimation can significantly affect the operation of heat controllers and reduce their efficiency.
To tackle this challenge, we addressed two grey-box models - the Continuous-Time Stochastic Model (CTSM) and Bayesian Optimization (BO) - in R and Python software, respectively. These models estimated the dynamic thermal characteristics of residential buildings, and we compared their performance. We found that BO exhibited an average of 31% higher accuracy in the estimation of dynamic thermal characteristics than the CTSM.
We then used UPPAAL-STRATEGO software to unlock the heat-to-power flexibility of heat pumps. The heat flexibility was generated using the probabilistic FlexOffer concept, considering uncertain weather variables. Our approach generated 39.03 kWh and 36.93 kWh energy flexibility for the residential building using the BO and the CTSM, respectively, with a gap of only 5.38%.
Our greatest success in this project was finding a more accurate and efficient way to estimate dynamic thermal characteristics, which is essential for optimizing the operation of heating systems in buildings. We are excited about the potential impact our work can have on energy-efficient and flexible building heating systems.
As for funny or ridiculous moments, we learned the hard way that a single logical error in the CTSM-R code can cause a massive error in the results. We spent hours trying to figure out why our results were not matching our expectations, only to realize that we had accidentally confused two thermal dynamic variables in the R code. We laughed about it afterward, but it was a valuable lesson in the importance of double-checking our work.We have already presented our work at Proceedings of the Energy Informatics 2022. Also, we published extended results in the Journal of Building Engineering, Elsevier. We believe that our approach can make a significant contribution to achieving more sustainable and energy-efficient buildings. Due to the high share of building energy consumption in climate change, building decarbonization with heat pumps will be a workable solution in near future.
Public Parking Lots of EVs by Hessam Golmohamadi- AAU- Department of Computer Science
As a part of FEVER, our team conducted a research project that aimed to integrate the flexibility potentials of aggregated electric batteries into power systems. We recognized that large-scale parking lots of Electric Vehicles (EVs) can be considered a virtual storage plant to counterbalance the renewable power variation on the supply side.
As a team working on asset management for public parking lots of EVs, we were surprised by the extent to which EVscan provide energy flexibility for power systems with high renewable power penetration. Initially, we expected EVsto be a passive load on the grid, but we soon realized that they could be leveraged as a flexible and dynamic resource that can help to counterbalance the renewable power intermittencyand facilitate renewable power integration.
Of course, this realization also brought with it a set of challenges and hurdles that we needed to overcome. One of the biggest challenges was training the control system and energy management software that could optimize charging patterns in real-time and ensure that the impact on the grid was minimized. We needed to train our algorithms with real traffic data from large-scale parking lots which were inaccessible. Due to a lack of data, we synthesized the traffic data using probabilistic methods.
Despite these challenges, we have made significant progress in our algorithm, and our greatest success so far has been the successful designation of a stochastic model to integrate the energy flexibility of EVs into power grids. This project involved stochastic programming and flexible energy management that allowed us to optimize the charging/dischargingoperation of EVs with different dwell times, balance the grid, and integrate the EVs’ flexibility into the power system. The results were highly promising in theory, and we can scaleup the project to real-world public parking lots.
Of course, no project is without its funny moments and ridiculous mishaps. One incident that stands out in our mindshappened in software coding when all the charging stations were left on all day long due to a logical error in the program. Consequently, the designated controller drained the entire grid and charged all the EVs to full electric capacity regardless of power grid imbalance and EV needs! We quickly debugged the software and learned a valuable lesson about the importance of program debugging.As for happenings, we are excited to publish our work in the Journal of Energy Storage, Elsevier. We believe that asset management for public parking lots of EVs has the potential to play a significant role in the transition toward a cleaner and more sustainable energy system, and we are eager to share our experiences and insights with others in the field. We expect to hear more in near future about the green mobility sector and its critical role in energy systems decarbonization.
Energy Flexibility - FlexOffers by Fabio Lilliu - AAU- Department of Computer Science
There are many ways to describe energy flexibility: usually, it is done by accurate mathematical representations. However, we wanted to come up with something different: a representation easy to visualize and understand, that would work for any kind of flexible device. Of course some accuracy had to be sacrificed for that; in exchange, however, this flexibility representation is much more scalable in terms of time horizons and number of devices, compared to more accurate representations.
We called this approach FlexOffer, as it represents an offer of flexibility from the prosumer. An interesting comparison that has been made about FlexOffers is to see them as Lego bricks: the length of the brick represents the time for which flexibility is modelled, the height represents the amount of available flexibility. Also, FlexOffers are easy to aggregate: that is, many small FlexOffers could be combined into a few big FlexOffers, which would represent their combined flexibility. With the previous analogy, it would be a bit like "stacking” the Lego bricks one with another.
This model has been evolving over time, in order to represent flexibility for different devices and under many scenarios. In FEVER, two main contributions have been made: 1) extend it in order to represent flexibility for batteries, and 2) expand it so that uncertainty would be considered. The figure shows how the model looks like for batteries: each polygon represents one time unit. For each polygon, the x axis is the amount of energy used up to that time, while the y axis is the amount of energy that can be used at that time: positive values mean "energy that can be given to the battery”, negative values "energy that can be taken from the battery”. For example, the last polygon is a rectangle with two cut angles: those two angles represent the cases when someone tries to take energy from an empty battery or to charge a full battery, which is not possible.
The model for uncertainty is more complex: it considers uncertainty for time (when the device is started), and amount of energy (how much can be consumed). Depending on the margin of uncertainty that is deemed acceptable, different FlexOffers are generated. For example, in the second figure, the pink FlexOffer is generated if we want to be sure about available flexibility, while the blue one is generated if we want flexibility with probability at least 80% of being available.Lastly, a funny thing that happened during this work has been the choice of acronyms: FlexOffers are usually written as FOs, and so their expansions, like Dependency FlexOffers are written as DFOs. It made us smile when we noticed that the same pattern made us write Uncertain FlexOffers as UFOs.