Transmission modes

Transmission modes are introduced to model different approaches for transmission for resources. These transmission modes are located within a transmission corridor. In general, transmission modes are designed to only transport a single Resource

    Introduced types and their fields

    EnergyModelsGeography provides multiple TransmissionModes that can be introduced in models. The hierarchy of the individual transmission modes is given by:

    TransmissionMode
    ├─ PipeMode
    │  ├─ PipeLinepackSimple
    │  └─ PipeSimple
    ├─ RefDynamic
    └─ RefStatic

    The individual modes use in general the same constraint functions and have the same fields with minor variations. Hence, all nodes with be presented below.

    The fields of the types are given as:

    • id:
      The field id is only used for providing a name to the transmission mode.
    • Transported resource fields:
      • RefStatic and RefDynamic
        • resource::EMB.Resource :
          The field resource corresponds to the transported Resource. The same resource is entering and leaving a transmission mode. Hence, pressure drop cannot be considered.
      • PipeMode; PipeSimple and PipeLinepackSimple
        • inlet::EMB.Resource and outlet::EMB.Resource:
          The implemented PipeModes allow for a differentiation between the Resource entering a transmission mode and the one leaving. This allows the incorporation of a pressure drop, albeit not through pressure drop equations but through a fixed pressure drop.
        • consuming::EMB.Resource and consumption_rate::TimeProfile: PipeModes introduce furthermore a consuming Resource. The consuming resource is required to transport the inlet resource. The proportionality is given by the value provided in the field consumption_rate.
        New `PipeMode` types

        Introducing new PipeMode types requires you to provide the same fields. Alternatively, you have to provide new methods to the functions, EMB.inputs, EMB.outputs, and consumption_rate.

    • trans_cap::TimeProfile:
      The installed capacity corresponds to the nominal capacity of the transmission mode. It is the outlet capacity and not the inlet capacity, that is after the calculation of the loss in the transmission mode.
      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.
    • trans_loss::TimeProfile:
      The transmission loss is calculated as a ratio of the transported resource. It is an absolute ratio, i.e., it is not dependent on the distance of the transmission corridor.
    • opex_var::TimeProfile:
      The variable operational expenses are based on the capacity utilization through the variable :trans_out. 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 trans_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.
    • data::Vector{Data}:
      An entry for providing additional data to the model. In the current version, it is only used for providing additional investment data when EnergyModelsInvestments is used.
      Note

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

    PipeLinepackSimple transmission modes also introduce an additional field:

    • energy_share:Float64:
      The energy share is a value corresponding to the amount of a resource that can be stored within a PipeLinepackSimple transmission mode. It is a relative ratio corresponding to the maximum amount of a Resource that can be stored within a pipeline. If you have, e.g., a hydrogen pipeline of 13 GW and have the potential to store in this pipeline 13 GWh through linepacking, then you have to provide a value of 1 GWh/GW.

    The types RefStatic and RefDynamic have furthermore the following field:

    • directions::Int:
      The direction value decides whether only unidirectional (1) or bidirectional (2) transport is allowed for the transmission mode.

    Theoretically, both PipeSimple and PipeLinepackSimple include the field directions. However, it is automatically set to 1 through the application of an inner constructor.

    Order of the fields

    The order of the individual fields can be best found in the library, RefStatic, RefDynamic, PipeSimple, and PipeLinepackSimple.

    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 all transmission modes are described on optimization variables and include:

    • $\texttt{trans\_opex\_var}$
    • $\texttt{trans\_opex\_fixed}$
    • $\texttt{trans\_cap}$
    • $\texttt{trans\_in}$
    • $\texttt{trans\_out}$
    • $\texttt{trans\_loss}$
    • $\texttt{emissions\_trans}$ if the transmission mode uses dispatch on the function has_emissions.

    PipeLinepackSimple transmission modes include furthermore:

    • $\texttt{linepack\_stor\_level}$

    Bidirectional transmission modes include furthermore:

    • $\texttt{trans\_neg}$
    • $\texttt{trans\_pos}$

    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 transmission modes. Instead, it is implicitly assumed that the constraints are valid $\forall tm ∈ M$ for all TransmissionMode 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).

    The following standard constraints are implemented for a TransmissionMode node.

    • constraints_capacity:

      Unidirectional transport constrains the outlet flow to the provided capacity while simultaneously introduce lower bounds of 0 on both $\texttt{trans\_out}$ and $\texttt{trans\_in}$:

      \[\texttt{trans\_out}[tm, t] \leq \texttt{trans\_cap}[tm, t]\]

      Bidirectional transport constrains bothe the inlet and outlet flow to the provided capacity:

      \[\begin{aligned} \texttt{trans\_in}[tm, t] & \geq -\texttt{trans\_cap}[tm, t] \\ \texttt{trans\_out}[tm, t] & \leq \texttt{trans\_cap}[tm, t] \end{aligned}\]

      PipeLinepackSimple transmission modes employ the same constraints as unidirectional transport, but require further constraints for the loss calculation and the storage balance:

      \[\begin{aligned} \texttt{trans\_in}[tm, t] & \leq \texttt{trans\_cap}[tm, t] + \texttt{trans\_loss}[tm, t] \\ \texttt{trans\_out}[tm, t] & \leq \texttt{trans\_cap}[tm, t] \\ \texttt{linepack\_stor\_level}[tm, t] & \leq \texttt{trans\_cap}[tm, t] \times energy\_share(tm) \\ \end{aligned}\]

    • constraints_capacity_installed:

      \[\texttt{trans\_cap}[tm, t] = capacity(tm, 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_trans_loss:

      Unidirectional transport calculates the loss as a fraction of the inlet:

      \[\texttt{trans\_loss}[tm, t] = loss(tm, t) \times \texttt{trans\_in}[tm, t]\]

      Bidirectional transport calculates the loss as a fraction of the positive and negative contributions:

      \[\texttt{trans\_loss}[tm, t] = loss(tm, t) \times \left(\texttt{trans\_pos}[tm, t] + \texttt{trans\_neg}[tm, t]\right)\]

      which are in turn calculated as:

      \[\texttt{trans\_pos}[tm, t] - \texttt{trans\_neg}[tm, t] = 0.5 \times \left(\texttt{trans\_in}[tm, t] + \texttt{trans\_out}[tm, t]\right)\]

      Loss calculations

      It looks to me that the loss calculations are not equivalent. We have to change that.

    • constraints_trans_balance:

      The overall transport balance is then given as:

      \[\texttt{trans\_out}[tm, t] = \texttt{trans\_in}[tm, t] - \texttt{trans\_loss}[tm, t]\]

      PipeLinepackSimple uses a different approach which will be revisited as it does not support a time structure including operational scenarios or representative periods. Hence, it will not be included in the documentation. If you are interested in the mathematical formulation, feel free to look at the function constraints_trans_balance.

    • constraints_opex_fixed:

      \[\texttt{trans\_opex\_fixed}[tm, t_{inv}] = opex\_fixed(tm, t_{inv}) \times \texttt{trans\_cap}[tm, first(t_{inv})]\]

      Why do we use `first()`

      The variable $\texttt{trans\_cap}$ is declared over all operational periods (see the variable section 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:

      Unidirectional transport calculates the variable operating expenses as a fraction of the outlet flow:

      \[\begin{aligned} \texttt{trans\_opex\_var}[tm, t_{inv}] = \sum_{t \in t_{inv}} & opex\_var(tm, t) \times \\ & \texttt{trans\_out}[tm, t] \times \\ & scale\_op\_sp(t_{inv}, t) \end{aligned}\]

      while bidirectional transport utilize again the variables $\texttt{trans\_pos}[tm, t]$ and $\texttt{trans\_neg}[tm, t]$ as introduced above:

      \[\begin{aligned} \texttt{trans\_opex\_var}[tm, t_{inv}] = \sum_{t \in t_{inv}} & opex\_var(tm, t) \times \\ & \left(\texttt{trans\_pos}[tm, t] + \texttt{trans\_neg}[tm, t]\right) \times \\ & scale\_op\_sp(t_{inv}, t) \end{aligned}\]

      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_emissions:

      Unidirectional transport calculates the emissions of the resourecs $p_{em} \in emit\_resources(tm)$ as a fraction of the outlet flow:

      \[\texttt{emissions\_trans}[tm, t, p_{em}] = emission(tm, p_{em}, t) \times \texttt{trans\_out}[tm, t]\]

      while bidirectional transport utilize again the variables $\texttt{trans\_pos}[tm, t]$ and $\texttt{trans\_neg}[tm, t]$ as introduced above:

      \[\texttt{emissions\_trans}[tm, t, p_{em}] = emission(tm, p_{em}, t) \times \left(\texttt{trans\_pos}[tm, t] + \texttt{trans\_neg}[tm, t]\right)\]