The WHY project has made some serious progress since our last newsletter. With the finalisation of the Deliverable D3.1 Technical Documentation of the WHY-toolkit the next step towards the creation of the WHY-Toolkit has been made. In this short article we would like to give you the opportunity to take a sneak peek into the WHY-Architecture and how that translates to the different Use Cases and maybe kindle you interest to take a closer look at Deliverable D3.1 and the WHY-Architecture developed by 4ward Energy Research, Forschungszentrum Jülich and our project coordinator University of Deusto.
The WHY Toolkit will be able to provide information on consumption behaviour of households with a very high level of detail and considering multiple different factors, of which the consideration of decision processes for investments and every day life decisions might just be the most relevant in comparison to other household consumption models. The development of the WHY Toolkit brings together multiple different fields of expertise, each with their own existing models or modelling approaches. Thus, it requires a well-defined architecture and was the starting point for the development of the WHY-architecture.
The figure shows the general structure of the WHY Simulation Architecture which is made up of three main elements:
- Components are either the (simulation/optimisation) models or sets of data that are needed to acquire the results needed for the different Code-Elements as well as the Energy System Models (ESM). The Components are grouped by different categories according to their overall function.
- Code-elements in this particular case refers to a collection of models and modules designated to perform a certain task within the WHY-Architecture. Different Code-Elements are interconnected via Interfaces. These Code-Elements can operate on their own and return the requested output if the required input is provided. Within the WHY-Architecture the Code-Elements interact with one another.
- Interfaces (or API) are the coupling points between the different Code-Elements. Each interface is described by the data it contains and of the format the data provided.
The WHY-Architecture provides the structure to create different detailed household load profiles for the different Use Cases. The general process will be the same for each Use Case, but they will start to differ regarding the number and range of parameters considered, the number of different households created during the uptake process, where the developed households will be multiplied to create the scenario to be considered in the Use Case.
How will it work?
First the general scenario will be described. In case of the Gniebing Use Case the general setting of the village of Gniebing and the effects of a disruption of electricity supply will be considered. In the European Use Case, the European energy strategy totally different parameters will play an important role, such as price and technology developments. The Causal Model will create the general setup of the scenarios and describe the types of households considered and how people would react under the given circumstances or new interventions/policy changes. The data is then provided to the different Load Profile Generators (LPG) which will create the different loadprofiles for all the non-controllable loads. In parallel, the generation profiles of non-controllable generation capacities will also be created.
The next step will consider potential investments in the households such as new generators or heating systems. This will be relevant for all the Use Cases although the decision of what to invest will differ: while the Energy Community Use Case might focus on the investment of a large shared PV generator, the European Energy Strategy Use Case might push the investment in building renovation. Regardless of the type of investment, this is where the Building Sizing algorithms will join the picture. Using either Genetic Algorithms or Mixed Integer Linear programming, the performance of both methods will be evaluated, the parameters (size of the PV, type of renovation approach, etc.) of the investments will be optimised and defined. The feedback of the Building Sizing algorithm will be fed into the Causal Model again, allowing us to see, whether that will cause any further changes in human decision or human behavioural processes.
Once all the building parameters are there and the load profiles for transport, heat and electricity as well as (new) generation capacities are created, the House Infrastructure Simulation will pop into action, simulating the flexible load and generation components for each household. The types and numbers of different households generated this way will differ greatly for each Use Case. The Gniebing and Energy Community Use Cases will have rather heterogenous structures with limited numbers of different households in comparison to the European Energy Strategy or even the Global Energy Scenario Use Cases. The Energy Cooperative Operation and Planning Use Case will be somewhat in between as it considers a larger area than the two “small scale” Use Cases but definitely an as diverse group of households as the two “large scale” Use Cases.
After creating all the different single households, the Uptake Algorithms will be used to multiply and to a certain degree randomise these households to create our total numbers of households needed for the scenarios. For the Gniebing and the Energy Community Use Case this will likely result in less than 1,000 households while that number will definitely be higher in the other Use Cases. Now the simulation will branch off into the different Use Cases, with their specific simulations and models to be used. Each of the Use Cases has an individual goal, as can be read in Deliverable 1.3, and will use a different set of models. But regardless of the Use Case, the outputs generated will then be evaluated and if needed, Interventions of the Causal Models optimised, depending on the type of analysation we are aiming for.
Well that’s it for now, we hope that we have kindled you interest in the WHY project and the WHY-Architecture and cordially invite you to dive deeper into the world of the technical aspects of WHY by reading the related deliverable defining the WHY Model Architecture.
Author: Thomas Nacht, 4ward Energy, Austria