FlexibleOutput

The FlexibleOutput node models a conversion technology that can produce multiple output resources while sharing a single capacity limit. In contrast to a standard NetworkNode, the utilized capacity is defined by the sum of all output flows, scaled by their respective output conversion factors.

This formulation enables flexible allocation of production across several co-products (e.g., multiple heat levels or energy carriers) while ensuring that total production remains consistent with the available capacity.

Introduced type and its fields

The FlexibleOutput is a subtype of the NetworkNode. It reuses all standard NetworkNode functionality except for the output-flow formulation, which is extended to allow flexible output composition.

Standard fields

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

  Conversion factor

  The conversion factor for the input is used as a multiplier for the capacity usage. A value of $2$ implies that you need 2 MW input resource/MW capacity usage.
  The conversion factor for the output is also used as a multiplier for the capacity usage. A value of $2$ implies that you produce 2 MW output resource/MW capacity usage. This implies that a higher value results in more production based on a given capacity. It is hence important to be careful when choosing values to avoid a perpetual motion machine.

• 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 `FlexibleOutput`

  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 a FlexibleOutput 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.

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 FlexibleOutput node uses the standard NetworkNode optimization variables (see Optimization variables):

• $\texttt{opex\_var}$
• $\texttt{opex\_fixed}$
• $\texttt{cap\_use}$
• $\texttt{cap\_inst}$
• $\texttt{flow\_in}$
• $\texttt{flow\_out}$

Constraints

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

FlexibleOutput nodes utilize in general the standard constraints described on Constraint functions for NetworkNodes, except for the output-flow constraint.

The following standard constraints apply:

• 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_capacity:

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

• constraints_flow_in:

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

• 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_ext_data: This function is only called if extension data are specified for the node.

The function constraints_flow_out is extended with a new method for flexible output nodes such that the outputs are flexible within their sum being the capacity usage of the node.

Let $\mathcal{P}^{out}(n)$ denote the set of output resources of node $n$ excluding CO₂, obtained through the function soutputs. The implemented constraint is then given by

\[\sum_{p \in \mathcal{P}^{out}(n)} \frac{\texttt{flow\_out}[n, t, p]}{outputs(n, p)} = \texttt{cap\_use}[n, t]\]

Additional constraints

FlexibleOutput nodes do not introduce additional constraint functions beyond the flexible output-flow formulation described above.