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.


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.


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}$)


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.


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


is equivalent to these two rows:


The keyword all can be extended to assign specific nodes:

  • all(node1,node2,node3) assigns all listed nodes. Accordingly, in the example above all(2020,2030) would have achieved the same result as using all.
  • all(node1:node2) assigns not only node1 and node2, 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)


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$.


The table above corresponds to the following tree:


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.

Less detailed resolution for debugging

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$.


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.

gasPlantccgtccgtCHPgaselectricity; districtHeat
coalPlantcoalelectricity; districtHeat
fuelCellhydrogenelectricity; 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.


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 nameexplanationdefault
  • different operational modes separated by a semicolon and a space
  • e.g. moreHeat; moreElec for CHP plant in the example
  • types control expansion behaviour of technology, see Göke (2020) for details
  • available options are:
    • stock: no expansion
    • mature: expansion without differentiation by time-step of construction
    • emerging: expansion with differentiation by time-step of construction
  • if expansion is spatially more detailed than dispatch, by default the resolution of dispatch
    is increased to the expansion level
  • using the keyword no prevents this behaviour and enforces the orginal dispatch resolution
  • sets the resolution of expansion time-steps
  • cannot be more detailed than the superordinate dispatch level (usually years)
most detailed resolution
of carriers
  • sets the resolution of expansion regions
  • default corresponds to the smallest value feasible
most detailed resolution
of carriers
  • by default, only leafs (nodes without any descendants) of stored carriers are actively
    stored (see Göke (2020) for details)
  • non-leaf carriers to be stored actively can be added here
  • carriers are separated by a semicolon and a space just like modes

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.


The set of modes includes operational modes defined for technologies. Modes are represented by the symbol $M$.