Source node

Source nodes are technologies that only have an output connection.

Introduced type and its fields

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

The fields of a RefSource 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 capacity 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.
• opex_var::TimeProfile:
  The variable operational expenses are based on the capacity utilization through the variable :cap_use. Hence, it is directly related to the specified output ratios. The variable operating expenses can be provided as OperationalProfile as well.
• opex_fixed::TimeProfile:
  The fixed operating expenses are relative to the installed capacity (through the field cap) and the chosen duration of an investment period as outlined on Utilize TimeStruct.
  It is important to note that you can only use FixedProfile or StrategicProfile for the fixed OPEX, but not RepresentativeProfile or OperationalProfile. In addition, all values have to be non-negative.
• output::Dict{<:Resource,<:Real}:
  The field output includes Resources with their corresponding conversion factors as dictionaries. CO₂ cannot be directly specified, i.e., you cannot specify a ratio. If you would like to use a Source node with CO₂ as output with a given ratio, it is necessary to utilize the package EnergyModelsCO2. If you use CaptureData, it is however necessary to specify CO₂ as output, although the ratio is not important.
  All values have to be non-negative.
• data::Vector{Data}:
  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. When using EmissionsData, only process emissions can be considered, that is the types EmissionsProcess and that is the types EmissionsProcess and CaptureProcessEmissions. Specifying energy related emissions will not have an impact as there is no energy conversion within a Source node.
  Note

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

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 Source nodes include:

• $\texttt{opex\_var}$
• $\texttt{opex\_fixed}$
• $\texttt{cap\_use}$
• $\texttt{cap\_inst}$
• $\texttt{flow\_out}$
• $\texttt{emissions\_node}$ if EmissionsData is added to the field data Note that Source nodes are not compatible with CaptureData except for CaptureProcessEmissions. Hence, you can only provide EmissionsProcess to the node.

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 direction inclusion of the vector of source nodes (or all nodes, if nothing specific is implemented). Instead, it is implicitly assumed that the constraints are valid $\forall n ∈ N^{\text{Source}}$ for all Source 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 Source node. Source 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] \leq \texttt{cap\_inst}[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_out:

  \[\texttt{flow\_out}[n, t, p] = outputs(n, p) \times \texttt{cap\_use}[n, t] \qquad \forall p \in outputs(n) \setminus \{\text{CO}_2\}\]

• constraints_opex_fixed:

  \[\texttt{opex\_fixed}[n, t_{inv}] = opex\_fixed(n, t_{inv}) \times \texttt{cap\_inst}[n, first(t_{inv})]\]

  Why do we use `first()`

  The variable $\texttt{cap\_inst}$ is declared over all operational periods (see the section on Capacity variables for further explanations). Hence, we use the function $first(t_{inv})$ to retrieve the installed capacity in the first operational period of a given investment period $t_{inv}$ in the function constraints_opex_fixed.

• constraints_opex_var:

  \[\texttt{opex\_var}[n, t_{inv}] = \sum_{t \in t_{inv}} opex\_var(n, t) \times \texttt{cap\_use}[n, t] \times scale\_op\_sp(t_{inv}, t)\]

  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_data:
  This function is only called for specified additional data, see above.