Sets and Mappings
In AnyMOD sets like regions, time-steps, carriers, and technologies are organized as Nodes
within hierarchical Trees
. They are defined by a mandatory input files named set_region.csv
, set_timestep.csv
, set_carrier.csv
, and set_technology.csv
, respectively. Relations between different sets (e.g. between carriers and technologies) are represented by mapping nodes within these trees to each other. This graph-based modelling approach is explained in detail in Göke (2020).
Next, these key sets and how their tree structure and mappings are obtained from input files are introduced based on the demo problem. Also, additional sets not organized as hierarchical trees are briefly listed as well.
Regions
The set_region.csv
file defines all modelling regions. The file consists out of consecutive columns named region_1
, region_2
etc. with each column relating to a level in the resulting tree. A region on a specific level is defined by writing its name into the respective column. To connect regions from different levels, they both need to be written into the same column. Names of regions are not required to be unique, not even on the same level.
The set file for regions from the demo problem is provided below.
region_1 | region_2 |
East | EastNorth |
East | EastSouth |
West | WestNorth |
West | WestSouth |
Consequently, this file defines six regions on two different levels. East
and West
are on level 1 and their descendants EastNorth
and EastSouth
as well as WestNorth
and WestSouth
are on level 2. Since names of regions are not required to be unique, alternatively each of the four descendant regions could have also been named North
or South
. By using the plotTree
function the corresponding hierarchical tree can be visualized and exported to the output directory:
Application context
Throughout the model regions are used in different contexts and depending on the context different symbols are used:
- $R_{exp}$: Region of capacity expansion, used in all investment related model elements
- $R_{disp}$: Region of dispatch, used in all dispatch related model elements
- $R_a$, $R_b$: Regions of exchange, element is not differentiated by direction of exchange (e.g. exchange capacities from $R_a$ to $R_b$ also apply from $R_b$ to $R_a$)
- $R_{from}$, $R_{to}$: Regions of exchange, element is differentiated by direction of exchange (e.g. the exchange loses from $R_{from}$ to $R_{to}$ do not apply from $R_{to}$ to $R_{from}$)
Time-steps
The set_timestep.csv
file defines all modelling time-steps, for both capacity expansion (usually years) and dispatch (for example hours). The file is structured analogously to the file for regions. Just as regions, names of time-steps are not required to be unique.
The first lines of the corresponding file in the demo problem are provided below.
timestep_1 | timestep_2 | timestep_3 | timestep_4 |
2020 | |||
2030 | |||
all | d001 | hh0001 | h0001 |
all | d001 | hh0001 | h0002 |
⋮ |
This file makes use of the all
keyword to reduce the number of rows required in the input file. This keyword serves as a placeholder for all nodes defined on the respective level. Consequently, in this case the following row
timestep_1 | timestep_2 | timestep_3 | timestep_4 |
all | d001 | hh0001 | h0001 |
is equivalent to these two rows:
timestep_1 | timestep_2 | timestep_3 | timestep_4 |
2020 | d001 | hh0001 | h0001 |
2030 | d001 | hh0001 | h0001 |
The keyword all
can be extended to assign specific nodes:
all(node1,node2,node3)
assigns all listed nodes. Accordingly, in the example aboveall(2020,2030)
would have achieved the same result as usingall
.all(node1:node2)
assigns not onlynode1
andnode2
, but also all nodes in between according to alphabetical order.
In the example above, the use of all
results in each year having descendant nodes that represent days (level 2), 4-hour steps (level 3) and hours (level 4). Since names of time-steps are not required to be unique, these different nodes for each year can share the same names. A reduced version of the corresponding tree is plotted below:
Application context
The following symbols are used to refer to time-steps depending on the context:
- $Ts_{exp}$: Time-steps of capacity expansion
- $Ts_{dis}$: Time-steps of dispatch
- $Ts_{sup}$: Superordinate dispatch time-steps (usually years)
Carriers
The hierarchical tree of energy carriers is defined analogously to regions and time-steps. The respective .csv
table from the demo problem is given below. Unlike regions and timestep, carrier names are required to be unique. Carriers are always represented by the symbol $C$.
carrier_1 | carrier_2 | timestep_dispatch | timestep_expansion | region_dispatch | region_expansion |
electricity | 4 | 1 | 1 | 2 | |
heat | districtHeat | 3 | 1 | 2 | 2 |
gas | naturalGas | 2 | 1 | 2 | 2 |
gas | synthGas | 2 | 1 | 1 | 1 |
coal | 1 | 1 | 1 | 1 | |
hydrogen | 1 | 1 | 1 | 1 |
The table above corresponds to the following tree:
Mapping
Carrier resolution
In addition to defining carriers, the set_carrier.csv
file also maps them to regions and time-steps to specify the resolution there are modeled at. This is done separately for dispatch and expansion in the columns timestep_dispatch
,timestep_expansion
,region_dispatch
, and region_expansion
. The numbers in these columns correspond to levels of the respective trees. In the example displayed below, 4
in the timestep_dispatch
column for electricity
means, dispatch for electricity is modeled for each time-step on level 4. Going back to the definition of time-steps above, this corresponds to an hourly resolution.
Creating and especially solving a model is much faster if the temporal resolution of dispatch is decreased. Therefore, it is advisable to first test new models at a less detailed temporal resolution. In the example this would be achieved by replacing the 4
for electricity with 2
to switch to a daily resolution. This will help you to spot and fix mistakes or unintended effects more efficiently.
AnyMOD checks the specified resolutions and will throw an error, if any logical inconsistencies are detected. Resolutions provided in a specific row only apply to the last carrier in that row. However, carrier on higher levels without a specified resolution, like gas
in the example, automatically inherit a resolution from their descendants.
Optional mappings
For reasons elaborated in Göke (2020), be default energy balances in AnyMOD are not formulated as equality constraints meaning supply can exceed demand. To overwrite this behaviour, an optional column named carrier_equality
using the keywords yes
and no
can be added to the file, where yes
will enforce an equality constraint. Carriers are represented by the symbol $Te$.
Technologies
The hierarchical tree of technologies is defined analogously to regions and time-steps. The respective .csv
table from the demo problem is given below. Unlike regions and timesteps, technology names are required to be unique.
technology_1 | technology_2 | technology_3 | carrier_conversion_in | carrier_conversion_out | carrier_stored_in | carrier_stored_out |
wind | electricity | |||||
solar | openspace | electricity | ||||
solar | rooftop | photovoltaic | electricity | electricity | ||
solar | rooftop | solarThermal | heat | heat | ||
gasPlant | ccgt | ccgtNoCHP | gas | electricity | ||
gasPlant | ccgt | ccgtCHP | gas | electricity; districtHeat | ||
gasPlant | ocgt | gas | electricity | |||
coalPlant | coal | electricity; districtHeat | ||||
heatpump | electricity | heat | ||||
gasStorage | gas | gas | ||||
gasBoiler | gas | heat | ||||
hydro | electricity | electricity | ||||
electrolysis | electricity | hydrogen | ||||
methanation | hydrogen | synthGas | ||||
fuelCell | hydrogen | electricity; districtHeat |
Within a model only nodes without any descendants are actual technologies. The remaining nodes have the sole purpose of organizing them. This facilitates the read-in of parameter data and formulation of certain constraints (e.g. the available rooftop area limiting the summed capacity of photovoltaic
and solarThermal
). The resulting hierarchical tree from the table above is displayed below.
Mappings
Converted and stored carriers
The .csv
table above does not only define the hierarchical tree of technologies, but also maps carriers to these technologies. This assignment differentiates between in- and output carriers and between conversion and storage.
In AnyMOD conversion generally refers to one or multiple carrier being used or generated as displayed in the diagram below. In the diagram expressions in italic refer to model variables and expressions in boxes to parameters.
The technology ccgtCHP
from the example is a pure conversion technology converting gas
to electricity
and districtHeat
, because conversion_input
and conversion_output
are assigned accordingly. It is not necessary for a conversion technology to have both, an in- and and output carrier. For instance, in the example renewables like wind
only have an output.
Storage is analogously described by the diagram below. In the example, hydro
is a pure storage technology, because electricity
is assigned to both storage_input
and storage_output
. Storage is not limited to a single carrier and a technology can store an arbitrary number of different carriers.
Assigning carriers as a storage output (or input) means they can be discharged to (or charged from) the general energy balance. Technologies that can only discharge but not charge a carrier from the energy balance are conceivable as well. However, this only makes sense, if the carrier can be generated internally to charge the storage in the first place. The interplay of conversion and storage in such a case is illustrated by the following diagram:
Such a technology is created by assigning the same carrier to conversion_output
and storage_output
, but not to storage_output
. In the example, this is the case for the technology photovoltaic
. It is intended to represent a residental photovoltaic panel combined with a home battery that cannot be charged from the gird, but from the panel.
Also the opposite case can be modeled: A carrier charged from outside, but only discharged within the technology. This only makes sense if the carrier is being used within the technology's conversion process. The corresponding diagram is given below and could represent a gas power plant with an onside gas storage.
Optional mappings
The following table lists all optional columns that can be specified within in set_technology.csv
file to overwrite a default behaviour.
An important option to point out is technology_type
. Three different technology types exist: stock
, mature
and emerging
. Stock technologies cannot be expended and are limited to pre-existing capacities. Emerging technologies differ from mature technologies in the sense that their capacities are differentiated by time-step of construction $Ts_{exp}$. This allows to account for technological improvement over time, but increases the required numbers of variables and constraints.
column name | explanation | default |
mode |
|
none |
technology_type |
|
mature |
region_disaggregate |
|
yes |
timestep_expansion |
|
most detailed resolution of carriers |
region_expansion |
|
most detailed resolution of carriers |
carrier_stored_active |
|
none |
Other Sets
Other sets in AnyMOD are not organized in hierarchical trees and might even be empty in a specific model. These are listed here.
Modes
The set of modes includes operational modes defined for technologies. Modes are represented by the symbol $M$.