ActivationCostNode

ActivationCostNode is a specialized NetworkNode that introduces unit commitment logic with additional fuel or resource costs incurred upon startup. It models technologies that consume extra input when switching on, such as combustion turbines or thermal boilers.

Introduced type and its fields

The ActivationCostNode extends the standard NetworkNode by incorporating binary unit commitment variables and explicit activation costs in the form of additional input resource usage during startup.

Standard fields

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

• input::Dict{<:Resource,<:Real} and output::Dict{<:Resource,<:Real}:
  Both fields describe the input and output Resources with their corresponding conversion factors as dictionaries.
  CO₂ cannot be directly specified, i.e., you cannot specify a ratio. 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 providing EmissionsData.

  Constructor for `ActivationCostNode`

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

  Using `CaptureData`

  If you plan to use CaptureData for an ActivationCostNode node, it is crucial that you specify your CO₂ resource in the output dictionary. The chosen value is however not important as the CO₂ flow is automatically calculated based on the process utilization and the provided process emission value. The reason for this necessity is that flow variables are declared through the keys of the output dictionary. Hence, not specifying CO₂ as output resource results in not creating the corresponding flow variable and subsequent problems in the design.

  We plan to remove this necessity in the future. As it would most likely correspond to breaking changes, we have to be careful to avoid requiring major changes in other packages.

Additional fields

ActivationCostNode nodes add two additional fields compared to a NetworkNode:

• activation_time::Real:
  Duration of activation effect (currently used to inform activation logic in customized formulations). This field is currently not utilized.
• activation_consumption::Dict{<:Resource,<:Real}:
  Required consumption of the input resources when the node switches on. Note that the value is the absolute required value and the resource must be included in the input dictionary.

Mathematical description

ActivationCostNode introduces startup-aware constraints and binary control variables, alongside the standard flow and cost formulations of NetworkNodes.

Variables

In addition to common variables:

• $\texttt{opex\_var}$
• $\texttt{opex\_fixed}$
• $\texttt{cap\_use}$
• $\texttt{cap\_inst}$
• $\texttt{flow\_in}$
• $\texttt{flow\_out}$
• $\texttt{emissions\_node}$ if EmissionsData is added to the field data

the following binary variables are defined for unit commitment logic:

• $\texttt{on\_off}[n, t] \in \{0,1\}$:
  Binary status indicator for whether the unit is active in time period $t$.
• $\texttt{onswitch}[n, t] \in \{0,1\}$:
  Indicates that the unit is being turned on in time period $t$.
• $\texttt{offswitch}[n, t] \in \{0,1\}$:
  Indicates that the unit is being turned off in time period $t$.

Constraints

The following sections omit the direct inclusion of the vector of ActivationCostNode nodes. Instead, it is implicitly assumed that the constraints are valid $\forall n ∈ N$ for all ActivationCostNode 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).

Standard constraints

ActivationCostNodes utilize in general the standard constraints that are implemented for a NetworkNode node as described in the documentation of EnergyModelsBase. These standard constraints are:

• 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 data of the nodes, see above.

The functions constraints_capacity is extended with a new method to calculate the on-off switching. The consistency across time is provided by the following constraint

\[\texttt{on\_off}[n, t] = \texttt{on\_off}[n, t_{prev}] - \texttt{offswitch}[n, t] + \texttt{onswitch}[n, t]\]

For the first time step in each investment period, the last value of the previous period is used instead of $t_{prev}$.

\[\texttt{offswitch}[n, t] + \texttt{onswitch}[n, t] \leq 0\]

The operational usage of the node is limited by the variable $\texttt{on\_off}[n, t]$

\[\texttt{cap\_use}[n, t] = \texttt{on\_off}[n, t] \times capacity(n, t)\]

and the installed capacity through the variable $\texttt{cap\_inst}[n, t]$

\[\texttt{cap\_use}[n, t] \leq \texttt{cap\_inst}[n, t]\]

As we want to avoid bilinearities and have not implemented the linear reformulation, we furthermore constrain the function installed capacity to the provided capacity in this function.

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

The function constraints_flow_in is extended with a new method to account for the additional consumption:

\[\texttt{flow\_in}[n, t, p] = inputs(n, p) \times \texttt{cap\_use}[n, t] + activation\_consumption(n, p) \times \texttt{onswitch}[n, t]\]

This models additional startup consumption, e.g., diesel or gas during ignition or ramp-up.