GitHub

Nodes

Nodes are used in EnergyModelsBase to convert Resources. They are coupled to the rest of the system through the Flow variables. Nodes are the key types for extending EnergyModelsBase through dispatch. You can find an introduction of the different node types on the page Creating a new node

Index

Abstract Node types

The following abstract node types are implemented in the EnergyModelsBase. These abstract types are relevant for dispatching in individual functions.

Reference node types

The following composite types are implemented in the EnergyModelsBase. They can be used for describing a simple energy system without any non-linear or binary based expressions. Hence, there are, e.g., no operation point specific efficiencies implemented.

EnergyModelsBase.RefSource — Type
RefSource <: Source

A reference Source node. The reference Source node allows for a time varying capacity which is normalized to a conversion value of 1 in the field input. Note, that if you include investments, you can only use as TimeProfile a FixedProfile or StrategicProfile.

Fields

  • id is the name/identifier of the node.
  • cap::TimeProfile is the installed capacity.
  • opex_var::TimeProfile is the variable operating expense per per capacity usage through the variable :cap_use.
  • opex_fixed::TimeProfile is the fixed operating expense per installed capacity through the variable :cap_inst.
  • output::Dict{<:Resource,<:Real} are the generated Resources with conversion value Real.
  • data::Vector{<:Data} is the additional data (e.g., for investments). The field data is conditional through usage of a constructor.
source
EnergyModelsBase.RefNetworkNode — Type
RefNetworkNode <: NetworkNode

A reference NetworkNode node. The RefNetworkNode utilizes a linear, time independent conversion rate of the input Resources to the output Resources, subject to the available capacity. The capacity is hereby normalized to a conversion value of 1 in the fields input and output.

Fields

  • id is the name/identifier of the node.
  • cap::TimeProfile is the installed capacity.
  • opex_var::TimeProfile is the variable operating expense per per capacity usage through the variable :cap_use.
  • opex_fixed::TimeProfile is the fixed operating expense per installed capacity through the variable :cap_inst.
  • input::Dict{<:Resource,<:Real} are the input Resources with conversion value Real.
  • output::Dict{<:Resource,<:Real} are the generated Resources with conversion value Real.
  • data::Vector{Data} is the additional data (e.g., for investments). The field data is conditional through usage of a constructor.
source
EnergyModelsBase.RefSink — Type
RefSink <: Sink

A reference Sink node. This node corresponds to a demand given by the field cap. The penalties introduced in the field penalty affect the variable OPEX for both a surplus and deficit.

Fields

  • id is the name/identifier of the node.
  • cap::TimeProfile is the demand.
  • penalty::Dict{Symbol,<:TimeProfile} are penalties for surplus or deficits. The dictionary requires the fields :surplus and :deficit.
  • input::Dict{<:Resource,<:Real} are the input Resources with conversion value Real.
  • data::Vector{<:Data} is the additional data (e.g., for investments). The field data is conditional through usage of a constructor.
source
EnergyModelsBase.RefStorage — Type
RefStorage{T} <: Storage{T}

A reference Storage node.

This node is designed to store either a ResourceCarrier or a ResourceEmit. It is designed as a parametric type through the type parameter T to differentiate between different cyclic behaviours. Note that the parameter T is only used for dispatching, but does not carry any other information. Hence, it is simple to fast switch between different StorageBehaviors.

The current implemented cyclic behaviours are CyclicRepresentative, CyclicStrategic, and AccumulatingEmissions.

Fields

  • id is the name/identifier of the node.
  • charge::AbstractStorageParameters are the charging parameters of the Storage node. Depending on the chosen type, the charge parameters can include variable OPEX, fixed OPEX, and/or a capacity.
  • level::AbstractStorageParameters are the level parameters of the Storage node. Depending on the chosen type, the charge parameters can include variable OPEX and/or fixed OPEX.
  • stor_res::Resource is the stored Resource.
  • input::Dict{<:Resource,<:Real} are the input Resources with conversion value Real.
  • output::Dict{<:Resource,<:Real} are the generated Resources with conversion value Real. Only relevant for linking and the stored Resource as the output value is not utilized in the calculations.
  • data::Vector{<:Data} is the additional data (e.g., for investments). The field data is conditional through usage of a constructor.
source
EnergyModelsBase.GenAvailability — Type
GenAvailability <: Availability

A reference Availability node. The reference Availability node solves the energy balance for all connected flows.

Fields

  • id is the name/identifier of the node.
  • inputs::Vector{<:Resource} are the input Resources.
  • output::Vector{<:Resource} are the output Resources.

A constructor is provided so that only a single array can be provided with the fields:

  • id is the name/identifier of the node.
  • 𝒫::Vector{<:Resource} are the [Resource`](@ref)s.
source

Storage behaviours

EnergyModelsBase provides several different storage behaviours for calculating the level balance of a Storage node. In general, the concrete storage behaviours are ready to use and should account for all eventualities.

EnergyModelsBase.Accumulating — Type
Accumulating <: StorageBehavior

Accumulating as supertype for an accumulating storage level.

Accumulating storage behaviour implies that the change in the overall storage level in a strategic period can be both positive or negative.

Examples for potential usage of Accumulating are CO₂ storages in which the CO₂ is permanently stored or multi year hydropower magazines.

source
EnergyModelsBase.AccumulatingEmissions — Type
AccumulatingEmissions <: Accumulating

StorageBehavior which accumulates all inflow witin a strategic period. AccumulatingEmissions allows as well to serve as a ResourceEmit emission point to represent a soft constraint on storing the captured emissions.

source
EnergyModelsBase.Cyclic — Type
Cyclic <: StorageBehavior

Cyclic as supertype for a cyclic storage level.

Cyclic storage behaviour implies that the change in the overall storage level in a strategic period behaves cyclic.

source
EnergyModelsBase.CyclicRepresentative — Type
CyclicRepresentative <: Cyclic

StorageBehavior in which cyclic behaviour is achieved within the lowest time structure excluding operational times.

In the case of TwoLevel{SimpleTimes}, this approach is similar to CyclicStrategic. In the case of TwoLevel{RepresentativePeriods{SimpleTimes}}, this approach differs from CyclicStrategic as the cyclic constraint is enforeced within each representative period.

source
EnergyModelsBase.CyclicStrategic — Type
CyclicStrategic <: Cyclic

StorageBehavior in which the the cyclic behaviour is achieved within a strategic period. This implies that the initial level in individual representative periods can be different when using RepresentativePeriods.

source
Note

We have not yet supported upper and lower bound constraints in the case of using OperationalScenarios. While the calculation of the overall level balance and the operational costs is consistent, it can happen that the upper and lower bound of the storage level is violated.

This impacts specifically CyclicStrategic.

Storage parameters

Storage parameters are used for describing different parameters for the individual capacities of a Storage node. In practice, Storage nodes can have three different capacities:

  1. charge, that is a capacity for charging the Storage node,
  2. level, that is the amount of energy/mass that can be stored, and
  3. discharge, that is a capacity for discharging the Storage node.

In general, each of the individual capacities can have an assigned capacity, variable OPEX, and fixed OPEX. Furthermore, it is possible to only have a variable OPEX. To this end, multiple composite types are defined.

EnergyModelsBase.StorCapOpex — Type
StorCapOpex <: AbstractStorageParameters

A storage parameter type for including a capacity as well as variable and fixed operational expenditures.

Fields

  • capacity::TimeProfile is the installed capacity.
  • opex_var::TimeProfile is the variable operating expense per capacity usage through the variable :cap_use.
  • opex_fixed::TimeProfile is the fixed operating expense per installed capacity through the variable :cap_inst.
source
EnergyModelsBase.StorCap — Type
StorCap <: AbstractStorageParameters

A storage parameter type for including only a capacity. This implies that neither the usage of the Storage, nor the installed capacity have a direct impact on the objective function.

Fields

  • capacity::TimeProfile is the installed capacity.
source
EnergyModelsBase.StorCapOpexVar — Type
StorCap <: AbstractStorageParameters

A storage parameter type for including a capacity and variable operational expenditures. This implies that the installed capacity has no direct impact on the objective function.

Fields

  • capacity::TimeProfile is the installed capacity.
  • opex_var::TimeProfile is the variable operating expense per capacity usage through the variable :cap_use.
source
EnergyModelsBase.StorCapOpexFixed — Type
StorCapOpexFixed <: AbstractStorageParameters

A storage parameter type for including a capacity and fixed operational expenditures. This implies that the installed capacity has no direct impact on the objective function.

Fields

  • capacity::TimeProfile is the installed capacity.
  • opex_fixed::TimeProfile is the fixed operating expense per installed capacity through the variable :cap_inst.
source
EnergyModelsBase.StorOpexVar — Type
StorCap <: AbstractStorageParameters

A storage parameter type for including variable operational expenditures. This implies that the charge or discharge rate do not have a capacity and the Storage level can be used within a single TimePeriod.

This type can only be used for the fields charge and discharge.

Fields

  • opex_var::TimeProfile is the variable operating expense per capacity usage through the variable :cap_use.
source

When dispatching on the individual type, it is also possible to use the following unions:

Functions for accessing fields of Node types

The following functions are declared for accessing fields from a Node type.

Warning

If you want to introduce new Node types, it is important that these functions are either functional for your new types or you have to declare corresponding functions. The first approach can be achieved through using the same name for the respective fields.

The functions storage_resource is only required for Storage nodes, when you plan to use the implemented constraint function constraints_flow_in. The functions surplus_penalty and deficit_penalty are only required for Sink nodes if you plan to use the implemented constraint function constraints_opex_var.

EnergyModelsBase.capacity — Function
capacity(n::Node)
capacity(n::Node, t)

Returns the capacity of a node n as TimeProfile or in operational period t.

Storage nodes

The capacity is not directly defined for Storage nodes. Instead, it is necessary to call the function on the respective field, see capacity(stor_par::AbstractStorageParameters).

source
capacity(stor_par::AbstractStorageParameters)
capacity(stor_par::AbstractStorageParameters, t)

Returns the capacity of storage parameter stor_par as TimeProfile or in operational period t.

Accessing storage parameters

The individual storage parameters of a Storage node can be accessed through the functions charge(n), level(n), and discharge(n).

source
EnergyModelsBase.opex_var — Function
opex_var(n::Node)
opex_var(n::Node, t)

Returns the variable OPEX of a node n as TimeProfile or in operational period t.

Storage nodes

The variable OPEX is not directly defined for Storage nodes. Instead, it is necessary to call the function on the respective field, see opex_var(stor_par::AbstractStorageParameters).

source
opex_var(stor_par::UnionOpexVar)
opex_var(stor_par::UnionOpexVar, t)

Returns the variable OPEX of storage parameter stor_par as TimeProfile or in operational period t.

Accessing storage parameters

The individual storage parameters of a Storage node can be accessed through the functions charge(n), level(n), and discharge(n).

source
EnergyModelsBase.opex_fixed — Function
opex_fixed(n::Node)
opex_fixed(n::Node, t_inv)

Returns the fixed OPEX of a node node n as TimeProfile or in strategic period t_inv.

Storage nodes

The fixed OPEX is not directly defined for Storage nodes. Instead, it is necessary to call the function on the respective field, see opex_fixed(stor_par::AbstractStorageParameters).

source
opex_fixed(stor_par::UnionOpexFixed)
opex_fixed(stor_par::UnionOpexFixed, t_inv)

Returns the fixed OPEX of storage parameter stor_par as TimeProfile or in strategic period t_inv.

Accessing storage parameters

The individual storage parameters of a Storage node can be accessed through the functions charge(n), level(n), and discharge(n).

source
EnergyModelsBase.inputs — Method
inputs(n::Node)
inputs(n::Node, p::Resource)

Returns the input resources of a node n, specified via the field input.

If the resource p is specified, it returns the value (1 in the case of Availability, nothing in the case of a Source)

source
EnergyModelsBase.outputs — Method
outputs(n::Node)
outputs(n::Node, p::Resource)

Returns the output resources of a node n, specified via the field output.

If the resource p is specified, it returns the value (1 in the case of Availability, nothing in the case of a Sink)

source
EnergyModelsBase.charge — Function
charge(n::Storage)

Returns the parameter type of the charge field of the node. If the node has no field charge, it returns nothing.

source
EnergyModelsBase.discharge — Function
discharge(n::Storage)

Returns the parameter type of the discharge field of the node. If the node has no field discharge, it returns nothing.

source

Functions for identifying Nodes

The following functions are declared for filtering on Node types.

Warning

If you want to introduce new Node types, it is important that the functions has_input, has_output, and has_emissions are either functional for your new types or you have to declare corresponding functions. The first approach can be achieved through using the same name for the respective fields.

The functions nodes_input, nodes_output, and nodes_emissions are not used in the model as they are replaced by the build in filter function as, e.g., filter(has_input, 𝒩). In practice, they provide a pre-defined approach for filtering nodes and do not require additional modifications. They can be used in potential extensions.

EnergyModelsBase.has_charge — Function
has_charge(n::Storage)

Returns logic whether the node has a charge field allowing for restrictions and/or costs on the (installed) charging rate.

source
EnergyModelsBase.has_discharge — Function
has_discharge(n::Storage)

Returns logic whether the node has a discharge field allowing for restrictions and/or costs on the (installed) discharging rate.

source
EnergyModelsBase.is_unidirectional — Method
is_unidirectional(n::Node)

Returns logic whether the node n can be used bidirectional or only unidirectional.

Bidirectional flow in nodes

In the current stage, EnergyModelsBase does not include any nodes which can be used bidirectional, that is with flow reversal.

If you plan to use bidirectional flow, you have to declare your own nodes and links that support this. You can then dispatch on this function for the incorporation.

source