CO₂ source node

A specific CO₂ source node is required as the default implementation of a RefSource does not allow for the CO₂ instance to be an output, as declared in the function constraints_flow_out. This is due to the implementation using CaptureData in which the CO₂ oulet flow is calculated through the implementation of the capture rate.

Hence, it is necessary to implement a CO₂ source node if one wants to model only a CO₂ source.

Introduced type and its field

The CO2Source is implemented as equivalent to a RefSource. Hence, it utilizes the same functions declared in EnergyModelsBase.

Standard fields

The standard fields 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.

• cap::TimeProfile:
  The installed capacity corresponds to the potential usage 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 a strategic 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. In the case of a CO₂ source, output should always include CO₂. It is also possible to include other resources which are produced with a given correlation with CO₂.
  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 only relevant for additional investment data when EnergyModelsInvestments is used or for additional emission data through EmissionsProcess. The latter would correspond to uncaptured CO₂ that should be included in the analyses.

  Note

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

  Using `EmissionsData`

  CO₂ source nodes are not compatible with CaptureData. This is is also checked in the EnergyModelsBase.check_node function.

  CO₂ source nodes can only us EmissionsProcess.

Additional fields

CO2Source nodes do not add additional fields compared to a RefSource.

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

Standard variables

The CO₂ source node types utilize all standard variables from the RefSource, as described on the page Optimization variables. The variables 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

Additional variables

CO2Source nodes do not add additional variables.

Constraints

The following sections omit the direct inclusion of the vector of CO₂ source nodes. Instead, it is implicitly assumed that the constraints are valid $\forall n ∈ N^{\text{CO}_2\_source}$ for all CO2Source 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 strategic periods).

Standard constraints

CO₂ source nodes utilize in general the standard constraints described on Constraint functions. These standard constraints are:

• 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_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 strategic 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 strategic 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 data of the CO₂ source, see above.

The function constraints_flow_out is extended with a new method for CO₂ source nodes to allow the inclusion of CO₂:

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

Additional constraints

CO2Source nodes do not add additional constraints.