GitHub

Sink node

Sink nodes are technologies that only have an input connection. In the context of EnergyModelsBase, they correspond to a demand.

Introduced type and its fields

The RefSink node is implemented as a reference node that can be used for a Sink. It includes basic functionalities common to most energy system optimization models.

The fields of a RefSink node are given as:

  • id:
    The field id is only used for providing a name to the node.
  • cap::TimeProfile:
    The installed capacity corresponds to the nominal demand of the node.
    If the node should contain investments through the application of EnergyModelsInvestments, it is important to note that you can only use FixedProfile or StrategicProfile for the capacity, but not RepresentativeProfile or OperationalProfile. In addition, all values have to be non-negative.
  • penalty::Dict{Symbol,<:TimeProfile}:
    The penalty dictionary is used for providing penalties for soft constraints to allow for both over and under delivering the demand.
    It must include the fields :surplus and :deficit. In addition, it is crucial that the sum of both values is larger than 0 to avoid an unconstrained model.
  • 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. In the current version, it is used for both providing EmissionsData and additional investment data when EnergyModelsInvestments is used.
    Constructor for `RefSink`

    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.

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.

Variables

The variables of Sink nodes include:

Constraints

A qualitative overview of the individual constraints can be found on Constraint functions. This section focuses instead on the mathematical description of the individual constraints. It omits the direct inclusion of the vector of sink nodes (or all nodes, if nothing specific is implemented). Instead, it is implicitly assumed that the constraints are valid $\forall n ∈ N^{\text{Sink}}$ for all Sink types 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 investment periods).

The following standard constraints are implemented for a Sink node. Sink nodes utilize the declared method for all nodes 𝒩. The constraint functions are called within the function create_node. Hence, if you do not have to call additional functions, but only plan to include a method for one of the existing functions, you do not have to specify a new create_node method.

  • constraints_capacity:

    \[\texttt{cap\_use}[n, t] + \texttt{sink\_deficit}[n, t] = \texttt{cap\_inst}[n, t] + \texttt{sink\_surplus}[n, t]\]

  • constraints_capacity_installed:

    \[\texttt{cap\_inst}[n, t] = capacity(n, t)\]

    Using investments

    The function constraints_capacity_installed is also used in EnergyModelsInvestments to incorporate the potential for investment. Nodes with investments are then no longer constrained by the parameter capacity.

  • constraints_flow_in:

    \[\texttt{flow\_in}[n, t, p] = inputs(n, p) \times \texttt{cap\_use}[n, t] \qquad \forall p \in inputs(n)\]

    Multiple inputs

    The constrained above allows for the utilization of multiple inputs with varying ratios. it is however necessary to deliver the fixed ratio of all inputs.

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

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

  • constraints_opex_var:

    \[\begin{aligned} \texttt{opex\_var}[n, t_{inv}] = & scale\_op\_sp(t_{inv}, t) \times \\ \sum_{t \in t_{inv}} & ( surplus\_penalty(n, t) \times \texttt{sink\_surplus}[n, t] + \\ & deficit\_penalty(n, t) \times \texttt{sink\_deficit}[n, t]) \\ & \end{aligned}\]

    The function `scale_op_sp`

    The function $scale\_op\_sp(t_{inv}, t)$ calculates the scaling factor between operational and investment periods. It also takes into account potential operational scenarios and their probability as well as representative periods.

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