Areas

The concept of areas is introduced in EnergyModelsGeography to create energy systems with transmission between individual regions. As outlined in the philosophy section, each Area can have a different local energy system with different units, CAPEX calculation approaches, and demands.

This page explains the fields of areas more specifically and introduces the different variables.

Area

Introduced types and their fields

EnergyModelsGeography introduces two different areas, RefArea and LimitedExchangeArea. Both types include the following fields:

id:
The field id is only used to provide an identifier for the area. This identifier can be a shortened version of the area name.
name:
The name of the area is used for printing an area to the Julia REPL, and hence, saving of variables. it can be only used as string input for the functions corr_from, corr_to, and corr_from_to.
lon::Real:
The longitudinal position of the area is not directly used in EnergyModelsGeography. It is however possible for the user to provide additional functions which can utilize the longitude for distance calculations.
lat::Real:
The latitudinal position of the area is not directly used in EnergyModelsGeography. It is however possible for the user to provide additional functions which can utilize the latitude for distance calculations.
node::Availability:
The field node correspond to the Availability node of the Area that is utilized for exchanging resources with other areas. !!! danger "Nodal type: It must by a GeoAvailability (or comparable nodes in which the energy balance is not calculated in the create_node function) as otherwise no energy transmission between this area and other areas is possible.
We decided to not limit it directly to GeoAvailability to allow the user to introduce other types of Availability nodes with potentially additional variables and constraints. It is however important to not calculate the energy balance within the Availability node.

LimitedExchangeArea require an additional field:

limit::Dict{<:EMB.Resource, <:TimeProfile}:
The exchange limit is the maximum amount of a resource that can be exported to other areas in each operational period. It is still possible to import from other regions, but the overall net export can not exceed the provided value.

Mathematical description

In the following mathematical equations, we use the name for variables and functions used in the model. Variables are in general represented as

$\texttt{var\_example}[index_1, index_2]$

with square brackets, while functions are represented as

$func\_example(index_1, index_2)$

with paranthesis.

In addition, we simplify the description as:

$n = availability\_node(a)$
corresponds to the availability node $n$ in the area $a$.
$P^{ex} = exchange\_resources(L^{trans}, a)$
correspond to the exchange resources $P^{ex}$ of the area $a$, that is all resources that are either consumed in energy transmission or exchanged with connected areas.
$L^{from}, L^{to} = trans\_sub (L^{trans}, a)$
are all transmission corridors that are either originating (superscript from) or ending (superscript to) in the area $a$.

Variables

The variables of Areas include:

$\texttt{area\_exchange}[a, t, p_{ex}]$

Constraints

The constraints for areas are calculated within the functions constraints_area and create_area. The function constraints_area is the core function as it links the transmission to and from an area with a local energy system while the function create_area allows for providing additional constraints.

`constraints_area`

The overall energy balance is solved within this function. We consider two cases:

The resource is not an exchange resource:
\[\texttt{flow\_out}[n, t, p] = \texttt{flow\_in}[n, t, p] \qquad \forall p \in inputs(n) \setminus P^{ex}\]
The resource is an exchange resource:
\[\texttt{flow\_out}[n, t, p_{ex}] = \texttt{flow\_in}[n, t, p_{ex}] + \texttt{area\_exchange}[a, t, p_{ex}] \qquad \forall p_{ex} \in P^{ex}\]

In addition, we have to add constraints for the variable $\texttt{area\_exchange}[a, t, p_{ex}]$. This is achieved through the compute functions as

\[\begin{aligned} \texttt{area\_exchange}[a, t, p_{ex}] + & \sum_{tm \in L^{from}} compute\_trans\_in(t, p_{ex}, tm) = \\ & \sum_{tm \in L^{to}} compute\_trans\_out(t, p_{ex}, tm) \end{aligned}\]

`create_area`

The RefArea does not introduce additional constraints.

The LimitedExchangeArea introduces additional constraints on the net export from the area. This constraint is given by

\[\texttt{area\_exchange}[a, t, p] \geq - exchange\_limit(a, p, t) \qquad \forall p \in limit\_resources(a)\]

GeoAvailability

The GeoAvailability node is introduced to allow the energy balance of an area being handled on the Area level. It is in itself equivalent to the to GenAvailability node with respect to introduced fields and variables. Availability node provides a detailed description of availability nodes.

Energy exchange

All energy exchange between different areas is routed through a GeoAvailability node. If you do not use a GeoAvailability node (e.g., a GenAvailability node or no availability node at all), you will not have energy transmission between different regions.

Introduced types and their fields

The GeoAvailability node is similar to a GenAvailability. It includes basic functionalities common to most energy system optimization models.

The fields of a GeoAvailability node are given as:

id:
The field id is only used for providing a name to the node.
input::Vector{<:Resource} and output::Vector{<:Resource}:
Both fields describe the input and output Resources as vectors. This approach is different to all other nodes, but simplifies the overall design. It is necessary to specify the same Resources to allow for capacity usage in connected nodes.

Constructor `GeoAvailability`

We require at the time being the specification of the fields input and output due to the way we identify the required flow and link variables. In practice, both fields should include the same Resources. To this end, we provide a simplified constructor in which you only have to specify one vector using the function

GeoAvailability(id, 𝒫::Vector{<:Resource})

Naming

We are aware that GeoAvailability and GenAvailability look similar. We plan to rename one of them with the additional introduction of a constructor. In this case, we introduce breaking changes. We plan to collect as many potential issues as possible before the next breaking changes.