If you can't read the message click here.

 
Newsletter #2 May 20, 2020
Updates of project development from the project coordinator, Dr. Juha Kiviluoma

Spine project has had highly productive months thanks to the amazingly talented project team. Spine Toolbox is now at version 0.4. In addition to a multitude of changes that should make the Toolbox more usable, there were also couple of big changes under the hood. First, Spine Engine has been separated from the Spine Toolbox. This means that tool execution now happens separately from the Toolbox, which ensures that the Toolbox can remain responsive even if there is heavy modelling happening in the background. The separation also paves the way for cloud execution and parallelization. Second, the data structure received a new layer of generalization, which allows the Toolbox to treat different kinds of data in suitable manner. Previously we had ‘objects’ and ‘relationship’. Now these are two ‘entity’ types among others. This allows entity type specific functionality in Spine Toolbox. Furthermore, it allows extending the toolbox functionality without breaking its existing functionality. New entity types that are either implemented or forthcoming include alternatives, scenarios and groups. Third, projects can now exist anywhere in the digisphere - previously they were contained within Spine Toolbox ‘projects’ folder, but this can be restricting for situations where the same project is accessed from multiple devices. Fourth, data types have been expanded. For example, we now have a data type for maps that allows creating nested data structures and arrays.

Spine Model has also been under heavy modifications. At the end of last year, we consolidated a model version where we were able to run the first set of case studies (the so-called A-case studies). Since then we have been implementing a long list of big structural changes including a very flexible temporal structure, rolling solves, removing the ‘direction’ dimension and ‘commodity’ dimension when they are not needed, moving storages to nodes, and implementing transfer delays. Next we will be working on the stochastic structure, investment mode, piecewise linear constraints, and implementing features and methods as a way to control what the model actually does. We have also contemplated about renaming Spine Model.


Results from the first case studies

Case studies are a key aspect of Spine, as they allow us to build confidence in our application and explore alternative modelling approaches. Five of the thirteen case studies planned for the project are now completed. These ‘A’ case studies had the primary purpose of replicating existing studies and hence allowed us to ensure that the Spine Model is working correctly. Below is a summary of key outcomes.

Case study A1: Irish dispatch study with power flows

This case study helped to develop the functionality of the components in the Spine software suite. The components (Spine Toolbox, Spine Data Store, spineInterface.jl) were used to recreate the Epiphron modelling tool in the Spine framework. Thus, it highlighted the potential of Spine as a model development suite. It was also used to test a power flow formulation that could be implemented in Spine Model.

Case study A2: Belgian gas grid study with pressure driven gas transfer

Spine Model provides a dedicated interface to introduce new constraints and formulations, allowing the user to integrate their own specific constraints as needed. This case study explored that functionality by introducing a gas transfer equation, based on the Weymouth Equation that is applied to simulate a hybrid power and gas network system.

Case study A3: District heating study of Stockholm

This study highlighted the capability of the Spine Model to represent energy conversion units of different nature, e.g., CHP units, heat boilers, gas turbines, and even units that can alternate between multiple operating modes. In addition, it used the rolling structure of Spine Model to run a one-year simulation with a rolling time horizon.

Case study A4: Cost optimization study with building heat physics

This study was the first to utilize the full modelling cycle of Spine. Data was imported from original sources into the Spine format, and then sent to the Spine Model to compute the results. Spine Toolbox orchestrated the entire workflow, and was also used to run an alternative version of the same model that invokes the Backbone modelling framework as an external tool.

Case study A5: Hydro power study with river systems

Here we modelled the Skellefte river in the Swedish hydro power system. The study combined a fairly detailed hydro model, including storage in the reservoirs, local inflows, and delays between stations, with a fairly coarse electricity model, where the entire system demand was concentrated on a single node.  

In all the above case studies, we have validated the results obtained by Spine against reference models and tools. As Spine Model develops further, these case studies will not necessarily work any longer with the latest Spine Model version. However, we will try to update some of these case studies close to the end of the project. More information can be found in D6.1: Summary of the Case Studies (preliminary version will soon be published in http://www.spine-model.org/publications.htm).


Presenting Spine

Spine project has been actively presented in different events during the past year. Here is a list of events and presentations held:


Workshop in the EMP-E conference 2019: Modelling the implementation of A Clean Planet For All Strategy

In October 2019, Spine project organised a workshop / parallel session as part of the Energy Modelling Platform for Europe (EMP-E) conference held in Brussels on October 8th-9th, 2019 (http://www.energymodellingplatform.eu/home-emp-e-2019.html#). The parallel section was called “Tools and data structures that allow sharing code and data”, and it was chaired by Prof. Erik Delarue from the KU Leuven / Energyville.

The session explored plans to improve the sharing of code and data in open source energy system models, and aimed to have a discussion on the ways forward.

There were four presentations in the session. Their contents are briefly summarised below:

Dr. Juha Kiviluoma (VTT Technical Research Centre of Finland): “Software design choices related to data sharing and data acquisition”

This first presentation by Juha Kiviluoma (VTT) discussed the design choices regarding how to share data between collaborators based on the experience in the Spine project. Spine Toolbox uses an entity-attribute-value data structure that allows representation of any kind of modelling data, including structure of the data, using the same format. This enables the possibility to exchange data between different tools and models efficiently - as soon as those tools can communicate with the Toolbox data structure. In the following discussion, the need for shared energy system semantics was brought up. Spine Toolbox could use such a semantic and there is an ongoing effort called ‘OpenEnergySemantic’ (part of Open Energy Modelling initiative) that pursues a shared semantic.

Dr. Kris Poncelet (KU Leuven): “How Spine Toolbox handles data to serve models and other tools” Spine Toolbox gives you different views to see and edit data

The presentation by Kris Poncelet (KU Leuven) demonstrated the use of Spine Toolbox, and the way it allows display and manipulation of different kinds of data. The Spine database can currently be accessed through a Python API or through a Julia API - the Julia API includes very helpful automation for model development. The audience posed the question of whether the data structure allows composition (re-using data across data objects). This is not presently possible, but it could be added through the relatively flexible data structure design - a new entity type for composition could enable this.

Dr. Matthew Gidden (IIASA-International Institute for Applied Systems Analysis): "Open-source tools in the Integrated Assessment Modeling community and scenario assessment by the IPCC"

Matthew Gidden from IIASA presented how they have enabled comparison of results from many different models using a simple but generic data structure. This will be further developed in the EU project OpenEntrance. The Python based package has great visualization features that are interesting also from Spine Toolbox perspective.

Dr. Stefan Pfenninger (ETH Zürich): “An overview of the Open Power System Data (OPSD) project”

In the last presentation Stefan Pfenninger (ETH Zürich) gave an overview of the Open Power System Data project. Their objective, since 2015, has been to build an efficient, high quality and legally accessible data repository. The system uses Frictionless DataPackage (which can be relatively easily imported to Spine Toolbox). The data includes not just power plants, but also time series and weather data. Since it is an open source project, others can, and have, contribute by making adjacent data packages. Active discussion followed the presentations. It was noted that the differences between open source licenses are a big problem for cross-using different datasets. These data silos should be avoided. Open Knowledge International proposes to e.g. cc-4.0 as a good choice. The legal use of ENTSO-E data was also discussed. Even though the legal standing is difficult, we can still see that data has been made available for it to be used.

It was asked how data can be imported into Spine Toolbox and used by different modelling languages. We were happy to explain that there are a couple of ways to import data (e.g. from tabular data and from GDX files). It is then possible to export data for Julia, Python and GAMS models. Furthermore, it was asked whether there will be a data collection initiative for other energy sectors (Open Power System Data is mainly about power system data after all). There is apparently some work by industrial ecologists, but other sources were not brought up. Moreover, uncertainty, future projections etc. are not included in the Open Power System Data, but IIASA presently hosts some data for future (integrated assessment). It was also highlighted that metadata should include legal metadata (licences, etc.) as well.


Spotlight: Fabiano Pallonetto, UCD Dublin

Could you tell us a little of yourself - how did you become an energy system modeller?

Well, I am not an energy modeller but more a computer scientist with a PhD in Energy Engineering. Everything started in Sweden in 2006 when I went to visit a hydroelectric power plant. During that period abroad, I realised I wanted to contribute to reducing the global carbon footprint and promote a more sustainable society. Since then, I have been working in academia and several start-ups as a multidisciplinary researcher in the field of sustainable mobility, energy engineering and computer science.

How long have you been involved in the Spine project and what is your role in it?

I have been involved in Spine since June 2018 when UCD Energy Institute hired me as Senior Researcher, and I joined the Spine core team. Since then, I contributed to the overall software design of Spine, the data flow and the integration among different components. It has been a short but intense journey, and it has been a pleasure to work with such a talented team.   

What has been the most important progress step / output in Spine model / toolbox so far?

I think the fundamental progress so far has been the design and implementation of a scalable software architecture that is flexible and at the same time powerful for the solution of multivector energy optimisation problems. The integration of different programming language and software into a single software suite can push the boundaries of the monolithic software environment. The language-agnostic workflow formulation allows the development of a completely different paradigm in the world of energy system integration  

What do you consider as the main end products of the Spine project, and how do you see the future development of Spine?

The Spine software suite is composed of Spine Toolbox, Spine Data Structure, Spine Engine, and Spine Model served with example case studies, associated plugins as well as connectors for different tools and programming languages. I believe such a broad, open-source software suite together with a vibrant community of users are the main end products of the Spine project. I see a bright future for Spine, a toolbox for testing and integrating different models and external plugins and a cloud-based scalable engine for professional and resource-intensive workflows. One step at the time.



www.spine-model.org