openENTRANCE: Model linkage mappings and definitions

Copyright 2020 openENTRANCE consortium

Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at

 http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.

Model linkage mappings and definitions

This repository aims to share the mapping of some models to be used in openENTRANCE is based on these three principles:

• Define the hierarchical relations among the different concepts used for variable and region domains of the common data format
• Define a set of consistent names, definitions, and meanings for the different concepts

The first rule is to define a single set of pre-defined reserved words to be used in the data-exchange platform. A reserved word can’t be used for two different concepts in the platform. The common data format are thought to be valid both for dynamic data, changing over time (e.g., hourly data), and static data (e.g., yearly data). Besides, we will need to represent both deterministic data (those for which there is certainty over the evolution of the corresponding data) and stochastic data, which depend on uncertain scenarios. Within the common data format, there are six dimensions:

1. Model
2. Scenario
3. Region
4. Variable
5. Unit
6. Subannual

Next, we describe in detail the information to be provided in each dimension. This definition must be exhaustive (cover all the data in the models considered) and avoid duplicities that might lead to inconsistencies. That is, all data should be defined once and just once.

1. Model

This dictionary of model can be linked through this exchange format. Given the intended openness of the exchange format, models inside and outside the openENTRANCE consortium are welcome. A brief description of the model is provided in the next link. Model name and version will be specified as follows:

openTEPES|1.6.12

More details about the dictionary can be found here.

2. Scenario

The analysis/case scenario name describes the type of analysis to be carried out and its context, as used in the openENTRANCE project. For example, analysis/case scenario GreenGrowth or Distributed PV all over Europe or Centralized utility-scale PV in southern Europe can be possible names. Any name is valid here.

This field can be extended to refer to the fact that the analysis/case scenario considered is stochastic/random to account, for example, for the spatial correlation of wind/solar generation, or demand, in different regions/countries. Stochastic/random data are usually time dependent. Thus, stochastic/random scenario names can be used. For example, possible forms can be used:

Distributed PV all over Europe|Scen001

Where the data given belong to the random scenario Scen001 of the analysis/case scenario Distributed PV all over Europe.

More details about the dictionaries can be found here.

3. Region

It refers to the geographical mapping of the variable. For that purpose, a definition of the set of regions is proposed by combining the possible geographical levels, in the order defined next, using pipes (|). Note that the NUTS 2021 Nomenclature is considered. We propose the following levels for the definition of the locations to be considered:

• Continent: Europe
• Region: Continental-Central-East (CCE)
• Country: countries (Germany, France, etc.)
• Area (NUTS 1): large regions inside a country
• Zone (NUTS 2): smaller regions inside a country
• Node (NUTS 3): physical (electrical, gas) nodes or provinces in the corresponding global grid
• District: municipal utility district
• Community: city block
• EndUser: end user
• Circuit: circuit/link of a line (electric or gas)

A greater than sign (>) is used to express the direction of links. For example, node1 > node2 | circuit1 indicates that we refer to circuit1 connecting node1 and node2, from the former to the latter. Bidirectional data must be declared separately for each direction but using only the greater sign. For example, possible values can be:

Germany|DE21H|Node001

Where only the Node001 that belongs to the city of München through the code DE21H (and München is located in the zone of Oberbayern) is defined.

Germany|DE21

Where only the zone of Oberbayern is defined through the code DE21.

Germany|DE2

Where only the area of Bayern is defined through the code De2.

DE21H>AT323|AC01

Defines the electrical circuit AC01 between Munich (NUTS code: DE21H) and Salzburg-und-Umgebung (NUTS code: AT323). For the geographical links (such as electrical circuits), it is important to connect locations at the same level. I.e. NUTS 1 with NUTS 1 or district with district.

More details about the dictionaries can be found here.

4. Variable

It defines the nature/features of the variable whose value is provided. For that purpose, we propose to set up the Variable by specifying values related to the following data types and combining these, in the order provided next, using pipes (|). We propose to consider the following levels of variables:

• Category: Agriculture, Demography, Economy, Emissions, Employment, Energy, EnergyService, GDP, Investment, Land, Trade, Price, ValueAdded
• NonEnergy: Crops, Livestock, Forest, Pasture, BuiltUpArea, OtherLand, Residues
• Energy: FinalEnergy, PrimaryEnergy, SecondaryEnergy
• TypeOfSecondaryEnergy: Electricity, Heat, Transport
• TypeOfFinalEnergy: Commercial, Industry, Other, Residential, TransportationFreight, TransportationPassenger
• Technology: The list of technologies to consider will be easily accessible to modelers, who could develop their data processing tools taking it into account.
• Generator: name of the generator
• Variable: The list of variables to consider will be easily accessible to modelers, who could develop their data processing tools taking it into account. Each variable can be mapped to those models that can use the former as an input or output.

We set here some guidelines to ensure consistency across the variable names to be defined:

• Do not include spaces before and after a (|) sign, but add a space between words
• All words must be capitalized (except for and,w/, w/o)
• Do not use abbreviations (e.g, PHEV) unless strictly necessary add hierarchy levels where it might be useful in the future, e.g, rather than having Plugin-Hybrid Electric Vehicle, use Electric Vehicle|Plugin-Hybrid
• Do not use statistical-operation-abbreviations (min, max, avg) but always spell out the word
• Do not include words like level or quantity in the variable (it should be clear anyway from the context)

Some examples of variables to be considered follow:

PowerCapacity|GasTurbine|CombinedCycle|Arcos3

More details about the dictionaries can be found here. -->

5. Unit

This dictionary refers to the physical, economic, or other type of unit in which the value provided for the variable is to be measured in the openENTRANCE project.

More details about the dictionary can be found here.

6. Subannual

This dictionary refers to the period of time that the value provided for the variable refers to. We propose to set up this column by setting values for the data types year, month, day, or hour, and concatenating them by pipes (|).

Additionally, this section can also use categories for representing periods like: summer day, summer night, winter day, winter night.

Possible values to be included as follow:

01/01/2030 00:00

It defines the hourly value of a certain variable

The possibility of defining a smaller time period, e.g., quarter of an hour, five minutes, is just a question of extending the time domain to minutes.

More details about the dictionaries can be found here.