Building nodes

The AbstractBuildings node types create sinks for all demand resources with penalties for both surplus and deficit. The implementation uses Dict structures for the fields cap, penalty_surplus, and penalty_deficit to facilitate multiple Resources. This approach allows modeling building demands with flexible penalty mechanisms for over- and under-supply.

Introduced types and their fields

AbstractBuildings nodes are subtypes of Sink, and hence, correspond to specialized sink nodes.

The subtype MultipleBuildingTypes is used to enable a specialized constructor that samples the Tecnalia_Building-Stock-Energy-Model module.

The subtype Building can be used to model a simple building demand where the heat demand is calculated from the temperature at a single location and a user-defined temperature-to-demand function. See the constructor for more details.

pip install metocean-api

Standard fields

Standard fields of AbstractBuildings nodes are given as:

• id:
  The field id is only used for providing a name to the node. This is similar to the approach utilized in EnergyModelsBase.

• input::Dict{<:Resource, <:Real}:
  The field input includes Resources with their corresponding conversion factors as dictionaries. All values have to be non-negative.

• data::Vector{<:ExtensionData}:
  An entry for providing additional data to the model. The subtype MultipleBuildingTypes adds automatically EmissionsEnergy to account for the emissions given by energy consumption through an inner constructor, if not specified explicitly. The subtype Building does not automatically add EmissionsEnergy as it is not a requirement that the emissions are associated directly to this node.

  Constructor for `AbstractBuildings` nodes

  The field data is not required as we include a constructor when the value is excluded.

  Using `CaptureData`

  As a Sink node does not have any output, it is not possible to utilize CaptureData. If you still plan to specify it, you will receive an error in the model building.

Additional fields

AbstractBuildings nodes introduce additional fields for demand and penalty specifications:

• cap::Dict{<:Resource,<:TimeProfile}:
  The demand capacity for each of the input resources. All values have to be non-negative.
• penalty_surplus::Dict{<:Resource,<:TimeProfile}:
  The penalties applied for surplus (over-supply) for each of the input resources. These penalties are added to the variable operating expenses. All values have to be non-negative.
• penalty_deficit::Dict{<:Resource,<:TimeProfile}:
  The penalties applied for deficit (under-supply) for each of the input resources. These penalties are added to the variable operating expenses. All values have to be non-negative.

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

Variables

Standard variables

AbstractBuildings nodes utilize standard variables from the Sink node type and includes:

• $\texttt{opex\_var}$
• $\texttt{opex\_fixed}$
• $\texttt{flow\_in}$
• $\texttt{sink\_surplus}$: Declared as the total surplus aggregated across all resources.
• $\texttt{sink\_deficit}$: Declared as the total deficit aggregated across all resources.
• $\texttt{emissions\_node}$ if EmissionsData is added to the field data

Additional variables

AbstractBuildings nodes introduce the following variables:

• $\texttt{buildings\_surplus}[n, t, p]$: Surplus (over-supply) for node $n$ in operational period $t$ for resource $p$.
• $\texttt{buildings\_deficit}[n, t, p]$: Deficit (under-supply) for node $n$ in operational period $t$ for resource $p$.

Constraints

The following sections omit the direct inclusion of the vector of AbstractBuildings nodes. Instead, it is implicitly assumed that the constraints are valid $\forall n ∈ N^{\text{AbstractBuildings}}$ if not stated differently. In addition, all constraints are valid $\forall t \in T$ (that is in all operational periods) or $\forall t_{inv} \in T^{Inv}$ (that is in all strategic periods). Finally, all constraints are valid $\forall p \in inputs(n)$ (that is in all input resources).

Standard constraints

AbstractBuildings nodes utilize the following standard constraint functions:

• constraints_opex_fixed:
  The current implementation fixes the fixed operating expenses of a sink to 0.

  \[\texttt{opex\_fixed}[n, t_{inv}] = 0\]

• constraints_ext_data:
  This function is only called for specified additional data, see above.

The function constraints_capacity is extended with a new method to account for the multiple inputs that must be satisfied within this Sink node:

\[\frac{\texttt{flow\_in}[n, t, p]}{inputs(n, p)} + \texttt{buildings\_deficit}[n, t, p] = capacity(n, t, p) + \texttt{buildings\_surplus}[n, t, p] \qquad \forall p \in inputs(n)\]

\[\texttt{sink\_deficit}[n, t] = \texttt{buildings\_deficit}[n, t, p]\]

\[\texttt{sink\_surplus}[n, t] = \texttt{buildings\_surplus}[n, t, p]\]

The function constraints_flow_in is extended with a new method that does not add any constraint.

The function constraints_capacity_installed is not called within constraints_capacity. Thus, the node does not support investments.

The function constraints_opex_var is extended with a new method to allow for individual penalties for the different demands.

\[\texttt{opex\_var}[n, t_{inv}] = \sum_{t \in t_{inv},\, p \in inputs(n)} \left( \texttt{buildings\_surplus}[n, t, p] \times penalty\_surplus(n, t, p) + \texttt{buildings\_deficit}[n, t, p] \times penalty\_deficit(n, t, p) \right) \times scale\_op\_sp(t_{inv}, t)\]

Additional constraints

AbstractBuildings nodes do not add additional constraints.