From 47dba635e521c2cdbf312b90202e7a4b413e3237 Mon Sep 17 00:00:00 2001 From: "Documenter.jl" Date: Wed, 16 Oct 2024 14:49:56 +0000 Subject: [PATCH] build based on c96e1b7 --- dev/.documenter-siteinfo.json | 2 +- dev/how-to/contribute/index.html | 2 +- dev/how-to/update-models/index.html | 2 +- dev/index.html | 2 +- dev/library/internals/methods-EMB/index.html | 2 +- .../internals/methods-fields/index.html | 10 ++++----- dev/library/public/index.html | 4 ++-- dev/manual/NEWS/index.html | 2 +- dev/manual/quick-start/index.html | 2 +- dev/manual/simple-example/index.html | 2 +- dev/nodes/hydropower/index.html | 20 +++++++++--------- dev/nodes/nondisres/index.html | 6 +++--- dev/objects.inv | Bin 2229 -> 2239 bytes dev/search_index.js | 2 +- 14 files changed, 29 insertions(+), 29 deletions(-) diff --git a/dev/.documenter-siteinfo.json b/dev/.documenter-siteinfo.json index 3fa6217..0f5e692 100644 --- a/dev/.documenter-siteinfo.json +++ b/dev/.documenter-siteinfo.json @@ -1 +1 @@ -{"documenter":{"julia_version":"1.10.5","generation_timestamp":"2024-09-05T14:57:15","documenter_version":"1.7.0"}} \ No newline at end of file +{"documenter":{"julia_version":"1.11.0","generation_timestamp":"2024-10-16T14:49:51","documenter_version":"1.7.0"}} \ No newline at end of file diff --git a/dev/how-to/contribute/index.html b/dev/how-to/contribute/index.html index 63f68c2..1bf7892 100644 --- a/dev/how-to/contribute/index.html +++ b/dev/how-to/contribute/index.html @@ -1,2 +1,2 @@ -Contribute to EnergyModelsRenewableProducers · EnergyModelsRenewableProducers
GitHub

Contribute to EnergyModelsRenewableProducers

Contributing to EnergyModelsRenewableProducers can be achieved in several different ways.

File a bug report

Another approach to contributing to EnergyModelsRenewableProducers is through filing a bug report as an issue when unexpected behaviour is occuring.

When filing a bug report, please follow the following guidelines:

  1. Be certain that the bug is a bug and originating in EnergyModelsRenewableProducers:
    • If the problem is within the results of the optimization problem, please check first that the nodes are correctly linked with each other. Frequently, missing links (or wrongly defined links) restrict the transport of energy/mass. If you are certain that all links are set correctly, it is most likely a bug in EnergyModelsRenewableProducers and should be reported.
    • If the problem occurs in model construction, it is most likely a bug in either EnergyModelsBase or EnergyModelsRenewableProducers and should be reported in the respective package. The error message of Julia should provide you with the failing function and whether the failing function is located in EnergyModelsBase or EnergyModelsRenewableProducers. It can occur, that the last shown failing function is within JuMP or MathOptInterface. In this case, it is best to trace the error to the last called EnergyModelsBase or EnergyModelsRenewableProducers function.
    • If the problem is only appearing for specific solvers, it is most likely not a bug in EnergyModelsRenewableProducers, but instead a problem of the solver wrapper for MathOptInterface. In this case, please contact the developers of the corresponding solver wrapper.
  2. Label the issue as bug, and
  3. Provide a minimum working example of a case in which the bug occurs.

Feature requests

EnergyModelsRenewableProducers includes several new nodal descriptions for renewable energy producers. However, there can be a demand for additional requirements for the existing nodes or for new descriptions which fall below the umbrella of renewable energy producers. In this case, you can contribute through a feature request.

Feature requests for EnergyModelsRenewableProducers should follow the guidelines developed for EnergyModelsBase.

Note

EnergyModelsRenewableProducers is slightly different than EnergyModelsBase.

Contrary to the other package, we consider that it is beneficial to have all potential features of renewable energy production within EnergyModelsRenewableProducers. Hence, if you have a requirement for a new nodal description, do not hesitate to create an issue.

+Contribute to EnergyModelsRenewableProducers · EnergyModelsRenewableProducers
GitHub

Contribute to EnergyModelsRenewableProducers

Contributing to EnergyModelsRenewableProducers can be achieved in several different ways.

File a bug report

Another approach to contributing to EnergyModelsRenewableProducers is through filing a bug report as an issue when unexpected behaviour is occuring.

When filing a bug report, please follow the following guidelines:

  1. Be certain that the bug is a bug and originating in EnergyModelsRenewableProducers:
    • If the problem is within the results of the optimization problem, please check first that the nodes are correctly linked with each other. Frequently, missing links (or wrongly defined links) restrict the transport of energy/mass. If you are certain that all links are set correctly, it is most likely a bug in EnergyModelsRenewableProducers and should be reported.
    • If the problem occurs in model construction, it is most likely a bug in either EnergyModelsBase or EnergyModelsRenewableProducers and should be reported in the respective package. The error message of Julia should provide you with the failing function and whether the failing function is located in EnergyModelsBase or EnergyModelsRenewableProducers. It can occur, that the last shown failing function is within JuMP or MathOptInterface. In this case, it is best to trace the error to the last called EnergyModelsBase or EnergyModelsRenewableProducers function.
    • If the problem is only appearing for specific solvers, it is most likely not a bug in EnergyModelsRenewableProducers, but instead a problem of the solver wrapper for MathOptInterface. In this case, please contact the developers of the corresponding solver wrapper.
  2. Label the issue as bug, and
  3. Provide a minimum working example of a case in which the bug occurs.

Feature requests

EnergyModelsRenewableProducers includes several new nodal descriptions for renewable energy producers. However, there can be a demand for additional requirements for the existing nodes or for new descriptions which fall below the umbrella of renewable energy producers. In this case, you can contribute through a feature request.

Feature requests for EnergyModelsRenewableProducers should follow the guidelines developed for EnergyModelsBase.

Note

EnergyModelsRenewableProducers is slightly different than EnergyModelsBase.

Contrary to the other package, we consider that it is beneficial to have all potential features of renewable energy production within EnergyModelsRenewableProducers. Hence, if you have a requirement for a new nodal description, do not hesitate to create an issue.

diff --git a/dev/how-to/update-models/index.html b/dev/how-to/update-models/index.html index 4417a71..0e35f99 100644 --- a/dev/how-to/update-models/index.html +++ b/dev/how-to/update-models/index.html @@ -104,4 +104,4 @@ input, output, Data, -) +) diff --git a/dev/index.html b/dev/index.html index 866a26c..1d71fcc 100644 --- a/dev/index.html +++ b/dev/index.html @@ -1,2 +1,2 @@ -Home · EnergyModelsRenewableProducers
GitHub

EnergyModelsRenewableProducers

This Julia package implements three new nodes with corresponding JuMP variables and constraints, extending the package EnergyModelsBase with more detailed representation of renewable energy sources.

These nodes are

  1. a Source node NonDisRES,
  2. a Storage node (HydroStor), and
  3. a Storage node (PumpedHydroStor).

The new introduced node types are also documented in the public library as well as the corresponding nodal page.

Developed nodes

NonDisRES

The first node models a non-dispatchable renewable energy source, like wind power, solar power, or run of river hydropower. These all use intermittent energy sources in the production of energy, so the maximum production capacity varies with the availability of the energy source at the time.

HydroStor and PumpedHydroStor

The other nodes implement a regulated hydropower storage plant, both with (PumpedHydroStor) and without pumps (HydroStor) for filling the reservoir with excess energy. The hydropower storage plant can also be extended as they are declared as subtypes of HydroStorage.

Manual outline

Description of the nodes

How to guides

Library outline

+Home · EnergyModelsRenewableProducers
GitHub

EnergyModelsRenewableProducers

This Julia package implements three new nodes with corresponding JuMP variables and constraints, extending the package EnergyModelsBase with more detailed representation of renewable energy sources.

These nodes are

  1. a Source node NonDisRES,
  2. a Storage node (HydroStor), and
  3. a Storage node (PumpedHydroStor).

The new introduced node types are also documented in the public library as well as the corresponding nodal page.

Developed nodes

NonDisRES

The first node models a non-dispatchable renewable energy source, like wind power, solar power, or run of river hydropower. These all use intermittent energy sources in the production of energy, so the maximum production capacity varies with the availability of the energy source at the time.

HydroStor and PumpedHydroStor

The other nodes implement a regulated hydropower storage plant, both with (PumpedHydroStor) and without pumps (HydroStor) for filling the reservoir with excess energy. The hydropower storage plant can also be extended as they are declared as subtypes of HydroStorage.

Manual outline

Description of the nodes

How to guides

Library outline

diff --git a/dev/library/internals/methods-EMB/index.html b/dev/library/internals/methods-EMB/index.html index bed76af..c075288 100644 --- a/dev/library/internals/methods-EMB/index.html +++ b/dev/library/internals/methods-EMB/index.html @@ -1,2 +1,2 @@ -Methods - EnergyModelsBase · EnergyModelsRenewableProducers
GitHub

Methods - EnergyModelsBase

Index

Extension methods

EnergyModelsBase.variables_node — Function
EMB.variables_node(m, 𝒩ⁿᵈʳ::Vector{NonDisRES}, 𝒯, modeltype::EnergyModel)

Create the optimization variable :curtailment for every NonDisRES node. This method is called from EnergyModelsBase.jl.

source
EMB.variables_node(m, 𝒩::Vector{<:HydroStorage}, 𝒯, modeltype::EnergyModel)

Create the optimization variable :hydro_spill for every HydroStorage node. This variable enables hydro storage nodes to spill water from the reservoir without producing energy. Wihtout this slack variable, parameters with too much inflow would else lead to an infeasible model.

source
EnergyModelsBase.create_node — Function
EMB.create_node(m, n::HydroStorage, 𝒯, 𝒫, modeltype::EnergyModel)

Sets all constraints for the regulated hydro storage node.

source

Constraint methods

EnergyModelsBase.constraints_capacity — Function
constraints_capacity(m, n::NonDisRES, 𝒯::TimeStructure, modeltype::EnergyModel)

Function for creating the constraint on the maximum capacity of a NonDisRES. Also sets the constraint defining curtailment.

source
EnergyModelsBase.constraints_flow_in — Function
constraints_flow_in(m, n::HydroStor, 𝒯::TimeStructure, modeltype::EnergyModel)

When n::HydroStor, the variable :flow_in is fixed to 0 for all potential inputs.

source
constraints_flow_in(m, n::PumpedHydroStor, 𝒯::TimeStructure, modeltype::EnergyModel)

When n::PumpedHydroStor, the variable :flow_in is multiplied with the inputs value to calculate the variable :stor_charge_use.

source
EnergyModelsBase.constraints_level_aux — Function
EMB.constraints_level_aux(m, n::HydroStorage, 𝒯, 𝒫, modeltype)

Function for creating the Δ constraint for the level of a HydroStorage node as well as the specification of the initial level in a strategic period.

The change in storage level in the reservoir at operational periods t is the inflow through :level_inflow plus the input :stor_charge_use minus the production :stor_discharge_use and the spillage of water due to overflow :hydro_spill.

source

Check methods

EnergyModelsBase.check_node — Function
EMB.check_node(n::NonDisRES, 𝒯, modeltype::EMB.EnergyModel, check_timeprofiles::Bool)

This method checks that the NonDisRES node is valid.

Checks

  • The field cap is required to be non-negative (similar to the Source check).
  • The value of the field fixed_opex is required to be non-negative and accessible through a StrategicPeriod as outlined in the function check_fixed_opex(n, 𝒯ᴵⁿᵛ, check_timeprofiles).
  • The values of the dictionary output are required to be non-negative (similar to the Source check).
  • The field profile is required to be in the range $[0, 1]$ for all time steps $t ∈ \mathcal{T}$.
source
EMB.check_node(n::HydroStorage, 𝒯, modeltype::EMB.EnergyModel, check_timeprofiles::Bool)

This method checks that the HydroStorage node is valid.

Checks

  • The TimeProfile of the field capacity in the type in the field charge is required to be non-negative if the chosen composite type has the field capacity.
  • The TimeProfile of the field capacity in the type in the field level is required to be non-negative`.
  • The TimeProfile of the field capacity in the type in the field discharge is required to be non-negative if the chosen composite type has the field capacity.
  • The TimeProfile of the field fixed_opex is required to be non-negative and accessible through a StrategicPeriod as outlined in the function check_fixed_opex(n, 𝒯ᴵⁿᵛ, check_timeprofiles) for the chosen composite type .
  • The field output can only include a single Resource.
  • The value of the field output is required to be smaller or equal to 1.
  • The value of the field input is required to be in the range $[0, 1]$.
  • The value of the field level_init is required to be in the range $[level\_min, 1] \cdot stor\_cap(t)$ for all time steps $t ∈ \mathcal{T}$.
  • The value of the field level_init is required to be in the range $[0, 1]$.
  • The value of the field level_min is required to be in the range $[0, 1]$.
source
+Methods - EnergyModelsBase · EnergyModelsRenewableProducers
GitHub

Methods - EnergyModelsBase

Index

Extension methods

EnergyModelsBase.variables_node — Function
EMB.variables_node(m, 𝒩ⁿᵈʳ::Vector{NonDisRES}, 𝒯, modeltype::EnergyModel)

Create the optimization variable :curtailment for every NonDisRES node. This method is called from EnergyModelsBase.jl.

source
EMB.variables_node(m, 𝒩::Vector{<:HydroStorage}, 𝒯, modeltype::EnergyModel)

Create the optimization variable :hydro_spill for every HydroStorage node. This variable enables hydro storage nodes to spill water from the reservoir without producing energy. Wihtout this slack variable, parameters with too much inflow would else lead to an infeasible model.

source
EnergyModelsBase.create_node — Function
EMB.create_node(m, n::HydroStorage, 𝒯, 𝒫, modeltype::EnergyModel)

Sets all constraints for the regulated hydro storage node.

source

Constraint methods

EnergyModelsBase.constraints_capacity — Function
constraints_capacity(m, n::NonDisRES, 𝒯::TimeStructure, modeltype::EnergyModel)

Function for creating the constraint on the maximum capacity of a NonDisRES. Also sets the constraint defining curtailment.

source
EnergyModelsBase.constraints_flow_in — Function
constraints_flow_in(m, n::HydroStor, 𝒯::TimeStructure, modeltype::EnergyModel)

When n::HydroStor, the variable :flow_in is fixed to 0 for all potential inputs.

source
constraints_flow_in(m, n::PumpedHydroStor, 𝒯::TimeStructure, modeltype::EnergyModel)

When n::PumpedHydroStor, the variable :flow_in is multiplied with the inputs value to calculate the variable :stor_charge_use.

source
EnergyModelsBase.constraints_level_aux — Function
EMB.constraints_level_aux(m, n::HydroStorage, 𝒯, 𝒫, modeltype)

Function for creating the Δ constraint for the level of a HydroStorage node as well as the specification of the initial level in a strategic period.

The change in storage level in the reservoir at operational periods t is the inflow through :level_inflow plus the input :stor_charge_use minus the production :stor_discharge_use and the spillage of water due to overflow :hydro_spill.

source

Check methods

EnergyModelsBase.check_node — Function
EMB.check_node(n::NonDisRES, 𝒯, modeltype::EMB.EnergyModel, check_timeprofiles::Bool)

This method checks that the NonDisRES node is valid.

Checks

  • The field cap is required to be non-negative (similar to the Source check).
  • The value of the field fixed_opex is required to be non-negative and accessible through a StrategicPeriod as outlined in the function check_fixed_opex(n, 𝒯ᴵⁿᵛ, check_timeprofiles).
  • The values of the dictionary output are required to be non-negative (similar to the Source check).
  • The field profile is required to be in the range $[0, 1]$ for all time steps $t ∈ \mathcal{T}$.
source
EMB.check_node(n::HydroStorage, 𝒯, modeltype::EMB.EnergyModel, check_timeprofiles::Bool)

This method checks that the HydroStorage node is valid.

Checks

  • The TimeProfile of the field capacity in the type in the field charge is required to be non-negative if the chosen composite type has the field capacity.
  • The TimeProfile of the field capacity in the type in the field level is required to be non-negative`.
  • The TimeProfile of the field capacity in the type in the field discharge is required to be non-negative if the chosen composite type has the field capacity.
  • The TimeProfile of the field fixed_opex is required to be non-negative and accessible through a StrategicPeriod as outlined in the function check_fixed_opex(n, 𝒯ᴵⁿᵛ, check_timeprofiles) for the chosen composite type .
  • The field output can only include a single Resource.
  • The value of the field output is required to be smaller or equal to 1.
  • The value of the field input is required to be in the range $[0, 1]$.
  • The value of the field level_init is required to be in the range $[level\_min, 1] \cdot stor\_cap(t)$ for all time steps $t ∈ \mathcal{T}$.
  • The value of the field level_init is required to be in the range $[0, 1]$.
  • The value of the field level_min is required to be in the range $[0, 1]$.
source
diff --git a/dev/library/internals/methods-fields/index.html b/dev/library/internals/methods-fields/index.html index db9a720..edcefc3 100644 --- a/dev/library/internals/methods-fields/index.html +++ b/dev/library/internals/methods-fields/index.html @@ -1,7 +1,7 @@ Methods - Accessing fields · EnergyModelsRenewableProducers
GitHub

Methods - Accessing fields

Index

NonDisRES

HydroStorage

PumpedHydroStor

EnergyModelsRenewableProducers.opex_var_pump — Function
opex_var_pump(n::PumpedHydroStor)
-opex_var_pump(n::PumpedHydroStor, t)

Returns the variable OPEX of a node n of type PumpedHydroStor related to pumping either as TimeProfile or at operational period t.

source
+profile(n::NonDisRES, t)

Returns the profile of a node n of type NonDisRES either as TimeProfile or in operational period t.

source

HydroStorage

EnergyModelsRenewableProducers.level_init — Function
level_init(n::HydroStorage)
+level_init(n::HydroStorage, t)

Returns the initial level of a node n of type HydroStorage either as TimeProfile or in operational period t.

source
EnergyModelsRenewableProducers.level_inflow — Function
level_inflow(n::HydroStorage)
+level_inflow(n::HydroStorage, t)

Returns the inflow to a node n of type HydroStorage either as TimeProfile or in operational period t.

source
EnergyModelsRenewableProducers.level_min — Function
level_min(n::HydroStorage)
+level_min(n::HydroStorage, t)

Returns the minimum level of a node n of type HydroStorage either as TimeProfile or in operational period t.

source

PumpedHydroStor

EnergyModelsRenewableProducers.opex_var_pump — Function
opex_var_pump(n::PumpedHydroStor)
+opex_var_pump(n::PumpedHydroStor, t)

Returns the variable OPEX of a node n of type PumpedHydroStor related to pumping either as TimeProfile or in operational period t.

source
diff --git a/dev/library/public/index.html b/dev/library/public/index.html index 2d37871..296604c 100644 --- a/dev/library/public/index.html +++ b/dev/library/public/index.html @@ -1,5 +1,5 @@ -Public · EnergyModelsRenewableProducers
GitHub

Public interface

Module

EnergyModelsRenewableProducers — Module

Main module for EnergyModelsRenewableProducers.jl.

This module implements the following types (Nodes) with constraints:

  • NonDisRes is a subtype of Source and represents a non-dispatchable renewable producer, as wind, solar etc.
  • PumpedHydroStor is a subtype of Storage and represents a regulated pumped hydro storage.
  • HydroStor is a subtype of Storage and represents a regulated hydro storage, that is a standard hydro powerplant without pumps.
source

Node types

Abstract types

Concrete types

EnergyModelsRenewableProducers.NonDisRES — Type
NonDisRES <: EMB.Source

A non-dispatchable renewable energy source. It extends the existing RefSource node through including a profile that corresponds to thr production. The profile can have variations on the strategic level.

Fields

  • id is the name/identifyer of the node.
  • cap::TimeProfile is the installed capacity.
  • profile::TimeProfile is the power production in each operational period as a ratio of the installed capacity at that time.
  • opex_var::TimeProfile is the variable operating expense per energy unit produced.
  • opex_fixed::TimeProfile is the fixed operating expense.
  • output::Dict{Resource, Real} are the generated Resources, normally Power.
  • data::Vector{Data} is the additional data (e.g. for investments). The field data is conditional through usage of a constructor.
source
EnergyModelsRenewableProducers.HydroStor — Type
HydroStor{T} <: HydroStorage{T}

A regulated hydropower storage, modelled as a Storage node. A regulated hydro storage node requires a capacity for the discharge and does not have a required inflow from the model, except for water inflow from outside the model, although it requires a field input.

Fields

  • id is the name/identifyer of the node.
  • level::EMB.UnionCapacity are the level parameters of the HydroStor node. Depending on the chosen type, the charge parameters can include variable OPEX and/or fixed OPEX.
  • discharge::EMB.UnionCapacity are the discharging parameters of the HydroStor node. Depending on the chosen type, the discharge parameters can include variable OPEX, fixed OPEX, and/or a capacity.
  • level_init::TimeProfile is the initial stored energy in the dam.
  • level_inflow::TimeProfile is the inflow of power per operational period.
  • level_min::TimeProfile is the minimum fraction of the reservoir capacity that has to remain in the HydroStorage node.
  • stor_res::ResourceCarrier is the stored Resource.
  • input::Dict{Resource, Real} are the input Resources. In the case of a HydroStor, this field can be left out.
  • output::Dict{Resource, Real} can only contain one entry, the stored resource.
  • data::Vector{Data} additional data (e.g. for investments). The field data is conditional through usage of a constructor.
source
EnergyModelsRenewableProducers.PumpedHydroStor — Type
PumpedHydroStor{T} <: HydroStorage{T}

A pumped hydropower storage, modelled as a Storage node. A pumped hydro storage node allows for storing energy through pumping water into the reservoir. The current implementation is a simplified node in which no lower reservoir is required. Instead, it is assumed that the reservoir has an infinite size.

A pumped hydro storage node requires a capacity for both charge and discharge to account for the potential to store energy in the form of potential energy.

Fields

  • id is the name/identifyer of the node.
  • charge::EMB.UnionCapacity are the charging parameters of the PumpedHydroStor node. Depending on the chosen type, the charge parameters can include variable OPEX, fixed OPEX, and/or a capacity.
  • level::EMB.UnionCapacity are the level parameters of the HydroStor node. Depending on the chosen type, the charge parameters can include variable OPEX and/or fixed OPEX.
  • discharge::EMB.UnionCapacity are the discharging parameters of the HydroStor node. Depending on the chosen type, the discharge parameters can include variable OPEX, fixed OPEX, and/or a capacity.
  • level_init::TimeProfile is the initial stored energy in the dam.
  • level_inflow::TimeProfile is the inflow of power per operational period.
  • level_min::TimeProfile is the minimum fraction of the reservoir capacity that has to remain in the HydroStorage node.
  • stor_res::ResourceCarrier is the stored Resource.
  • input::Dict{Resource, Real} are the input Resources.
  • output::Dict{Resource, Real} can only contain one entry, the stored resource.
  • data::Vector{Data} additional data (e.g. for investments). The field data is conditional through usage of a constructor.
source

Legacy constructors

EnergyModelsRenewableProducers.RegHydroStor — Function
RegHydroStor(
+Public · EnergyModelsRenewableProducers
GitHub
Public interface
Module
EnergyModelsRenewableProducers — Module
Main module for EnergyModelsRenewableProducers.jl.
This module implements the following types (Nodes) with constraints:
  • NonDisRes is a subtype of Source and represents a non-dispatchable renewable producer, as wind, solar etc.
  • PumpedHydroStor is a subtype of Storage and represents a regulated pumped hydro storage.
  • HydroStor is a subtype of Storage and represents a regulated hydro storage, that is a standard hydro powerplant without pumps.
source
Node types
Abstract types
Concrete types
EnergyModelsRenewableProducers.NonDisRES — Type
NonDisRES <: EMB.Source
A non-dispatchable renewable energy source. It extends the existing RefSource node through including a profile that corresponds to thr production. The profile can have variations on the strategic level.
Fields
  • id is the name/identifyer of the node.
  • cap::TimeProfile is the installed capacity.
  • profile::TimeProfile is the power production in each operational period as a ratio of the installed capacity at that time.
  • opex_var::TimeProfile is the variable operating expense per energy unit produced.
  • opex_fixed::TimeProfile is the fixed operating expense.
  • output::Dict{Resource, Real} are the generated Resources, normally Power.
  • data::Vector{Data} is the additional data (e.g. for investments). The field data is conditional through usage of a constructor.
source
EnergyModelsRenewableProducers.HydroStor — Type
HydroStor{T} <: HydroStorage{T}
A regulated hydropower storage, modelled as a Storage node. A regulated hydro storage node requires a capacity for the discharge and does not have a required inflow from the model, except for water inflow from outside the model, although it requires a field input.
Fields
  • id is the name/identifyer of the node.
  • level::EMB.UnionCapacity are the level parameters of the HydroStor node. Depending on the chosen type, the charge parameters can include variable OPEX and/or fixed OPEX.
  • discharge::EMB.UnionCapacity are the discharging parameters of the HydroStor node. Depending on the chosen type, the discharge parameters can include variable OPEX, fixed OPEX, and/or a capacity.
  • level_init::TimeProfile is the initial stored energy in the dam.
  • level_inflow::TimeProfile is the inflow of power per operational period.
  • level_min::TimeProfile is the minimum fraction of the reservoir capacity that has to remain in the HydroStorage node.
  • stor_res::ResourceCarrier is the stored Resource.
  • input::Dict{Resource, Real} are the input Resources. In the case of a HydroStor, this field can be left out.
  • output::Dict{Resource, Real} can only contain one entry, the stored resource.
  • data::Vector{Data} additional data (e.g. for investments). The field data is conditional through usage of a constructor.
source
EnergyModelsRenewableProducers.PumpedHydroStor — Type
PumpedHydroStor{T} <: HydroStorage{T}
A pumped hydropower storage, modelled as a Storage node. A pumped hydro storage node allows for storing energy through pumping water into the reservoir. The current implementation is a simplified node in which no lower reservoir is required. Instead, it is assumed that the reservoir has an infinite size.
A pumped hydro storage node requires a capacity for both charge and discharge to account for the potential to store energy in the form of potential energy.
Fields
  • id is the name/identifyer of the node.
  • charge::EMB.UnionCapacity are the charging parameters of the PumpedHydroStor node. Depending on the chosen type, the charge parameters can include variable OPEX, fixed OPEX, and/or a capacity.
  • level::EMB.UnionCapacity are the level parameters of the HydroStor node. Depending on the chosen type, the charge parameters can include variable OPEX and/or fixed OPEX.
  • discharge::EMB.UnionCapacity are the discharging parameters of the HydroStor node. Depending on the chosen type, the discharge parameters can include variable OPEX, fixed OPEX, and/or a capacity.
  • level_init::TimeProfile is the initial stored energy in the dam.
  • level_inflow::TimeProfile is the inflow of power per operational period.
  • level_min::TimeProfile is the minimum fraction of the reservoir capacity that has to remain in the HydroStorage node.
  • stor_res::ResourceCarrier is the stored Resource.
  • input::Dict{Resource, Real} are the input Resources.
  • output::Dict{Resource, Real} can only contain one entry, the stored resource.
  • data::Vector{Data} additional data (e.g. for investments). The field data is conditional through usage of a constructor.
source
Legacy constructors
EnergyModelsRenewableProducers.RegHydroStor — Function
RegHydroStor(
     id::Any,
     rate_cap::TimeProfile,
     stor_cap::TimeProfile,
@@ -13,4 +13,4 @@
     input,
     output,
     Data,
-)
Original Legacy constructor for a regulated hydropower storage, with or without pumping capabilities. This version is discontinued starting with Version 0.6.0. resulting in an error It is replaced with the two new types HydroStor and PumpedHydroStor to utilize the concept of multiple dispatch instead of logic.
See the documentation for further information regarding how you can translate your existing model to the new model.
Fields
  • id is the name/identifyer of the node.
  • rate_cap::TimeProfile is the installed installed rate capacity.
  • stor_cap::TimeProfile is the installed storage capacity in the dam.
  • has_pump::Bool states wheter the stored resource can flow in.
  • level_init::TimeProfile is the initial stored energy in the dam.
  • level_inflow::TimeProfile is the inflow of power per operational period.
  • level_min::TimeProfile is the minimum fraction of the reservoir capacity that has to remain in the HydroStorage node.
  • opex_var::TimeProfile are the variable operational expenses per GWh produced.
  • opex_fixed::TimeProfile are the fixed operational costs of the storage caacity.
  • stor_res::ResourceCarrier is the stored Resource.
  • input::Dict{Resource, Real} are the stored and used resources. The values in the Dict are ratios describing the energy loss when using the pumps.
  • output::Dict{Resource, Real} can only contain one entry, the stored resource.
  • data::Array{Data} additional data (e.g. for investments). This value is conditional through the application of a constructor.
source

+)

Original Legacy constructor for a regulated hydropower storage, with or without pumping capabilities. This version is discontinued starting with Version 0.6.0. resulting in an error It is replaced with the two new types HydroStor and PumpedHydroStor to utilize the concept of multiple dispatch instead of logic.

See the documentation for further information regarding how you can translate your existing model to the new model.

Fields

  • id is the name/identifyer of the node.
  • rate_cap::TimeProfile is the installed installed rate capacity.
  • stor_cap::TimeProfile is the installed storage capacity in the dam.
  • has_pump::Bool states wheter the stored resource can flow in.
  • level_init::TimeProfile is the initial stored energy in the dam.
  • level_inflow::TimeProfile is the inflow of power per operational period.
  • level_min::TimeProfile is the minimum fraction of the reservoir capacity that has to remain in the HydroStorage node.
  • opex_var::TimeProfile are the variable operational expenses per GWh produced.
  • opex_fixed::TimeProfile are the fixed operational costs of the storage caacity.
  • stor_res::ResourceCarrier is the stored Resource.
  • input::Dict{Resource, Real} are the stored and used resources. The values in the Dict are ratios describing the energy loss when using the pumps.
  • output::Dict{Resource, Real} can only contain one entry, the stored resource.
  • data::Array{Data} additional data (e.g. for investments). This value is conditional through the application of a constructor.
source
diff --git a/dev/manual/NEWS/index.html b/dev/manual/NEWS/index.html index 8d6160e..3326b12 100644 --- a/dev/manual/NEWS/index.html +++ b/dev/manual/NEWS/index.html @@ -1,2 +1,2 @@ -Release notes · EnergyModelsRenewableProducers
GitHub

Release notes

Version 0.6.1 (2024-09-03)

  • Dependency increase for EnergyModelsBase as the changes do not directly affect EnergyModelsCO2.
  • Updated the documentation using the new structure released by EnergyModelsCO2.
  • Included the package DocumenterInterLinks for crossreferences to EnergyModelsBase.
  • Use dev version of EMRP for examples when running as part of tests, similar to PR #33 of EMB.

Version 0.6.0 (2024-05-28)

  • Adjusted to changes introduced in EnergyModelsBase v0.7.
  • Remove legacy constructor for RegHydroStor and provide a warning for it.
  • Added constructors for HydroStor not requiring any longer specifying an input dictionary.

Version 0.5.6 (2024-05-09)

  • Provided a contribution section in the documentation.
  • Fixed a link in the documentation for the examples.

Version 0.5.5 (2024-03-21)

  • Minor changes to the checks to be consistent with EnergyModelsBase v0.6.7.

Version 0.5.4 (2024-03-04)

Examples

  • Fixed a bug when running the examples from a non-cloned version of EnergyModelsRenewableProducers.
  • This was achieved through a separate Project.toml in the examples.

NonDIsRes node

  • Moved the capacity constraints through the profile to the function EMB.constraints_capacity(n::NonDisRES, ...), and hence, removed the function EMB.create_node(n::NonDisRES, ...).

Minor updates

  • Added some checks and tests to the checks.
  • Restructured the test folder.

Version 0.5.3 (2024-01-30)

  • Updated the restrictions on the fields of individual types to be consistent.
  • Added option to not include the field data for the individual introduced Nodes.

Version 0.5.2 (2024-01-19)

  • Updated the documenation to be in line with the updated done in EnergyModelsBsae.
  • Moved RegHydroStor to a new file, legacy_constructors.jl to highlight that a user should use the new types, namely HydroStor and PumpedHydroStor.

Version 0.5.1 (2024-01-17)

  • Update the method constraints_level to match the signature updates for these methods in EnergyModelsBase. This includes renaming constraints_level to constraints_level_sp.
  • Moved the function to EMB.constraints_level_sp to avoid problems.

Version 0.5.0 (2023-12-18)

Adjustment to release in EMB 0.6.0

  • Adjusted the code for the new release.
  • Implementation of support for RepresentativePeriods for HydroStorage nodes.

Version 0.4.2 (2023-09-01)

Create a variable :spill for hydro storage node

  • This variable enables hydro storage nodes to spill water from the reservoir without producing energy.

Version 0.4.1 (2023-08-31)

Split the hydro storage node into to separate nodes

  • Split RegHydroStor into to types PumpedHydroStor and HydroStor. Both are subtypes

of the new abstract type HydroStorage <: EMB.Storage.

  • Fix: variational OPEX for HydroStor now depends on flow_out instead of

flow_in. The new type PumpedHydroStor has a separate parameter for variational OPEX for the pumps, which depends on flow_in.

Version 0.4.0 (2023-06-06)

Switch to TimeStruct

  • Switched the time structure representation to TimeStruct.
  • TimeStruct is implemented with only the basis features that were available in TimeStructures. This implies that neither operational nor strategic uncertainty is included in the model.

Version 0.3.0 (2023-05-30)

  • Adjustment to changes in EnergyModelsBase v0.4.0 related to extra input data.

Version 0.2.2 (2023-05-15)

  • Adjustment to changes in EnergyModelsBase v 0.3.3 related to the calls for the constraint functions.

Version 0.2.1 (2023-02-03)

  • Take the examples out to the folder examples.

Version 0.2.0 (2023-02-03)

Adjustmends to updates in EnergyModelsBase

Adjustment to version 0.3.0, namely:

  • Changed type (Node) calls in tests to be consistent with version 0.3.0.
  • Removal of the type GlobalData and replacement with fields in the type OperationalModel in all tests.
  • Changed type structure to be consistent with EMB version 0.3.0.
  • Substitution of certain constraints in create_node through functions which utilize dispatching on node types.
  • Changed the input to the function variables_node.

Version 0.1.3 (2022-12-12)

Internal release

  • Renamed to follow common prefix naming scheme.
  • Update README.

Version 0.1.2 (2022-12-02)

  • Minor test fixes in preparation of internal release.

Version 0.1.1 (2021-09-07)

Changes in naming

  • Major changes in both variable and parameter naming, check the commit message for an overview.
  • Change of structure in composite type "RegHydroStor".

Version 0.1.0 (2021-08-23)

  • Initial version with inclusion of nodes for:
    • nondispatchable renewable energy sources (NonDisRES) and
    • regulated hydro generation (RegHydroStor, can be used for pumped hydro storage).
+Release notes · EnergyModelsRenewableProducers
GitHub

Release notes

Unversioned

Version 0.6.1 (2024-09-03)

  • Dependency increase for EnergyModelsBase as the changes do not directly affect EnergyModelsCO2.
  • Updated the documentation using the new structure released by EnergyModelsCO2.
  • Included the package DocumenterInterLinks for crossreferences to EnergyModelsBase.
  • Use dev version of EMRP for examples when running as part of tests, similar to PR #33 of EMB.

Version 0.6.0 (2024-05-28)

  • Adjusted to changes introduced in EnergyModelsBase v0.7.
  • Remove legacy constructor for RegHydroStor and provide a warning for it.
  • Added constructors for HydroStor not requiring any longer specifying an input dictionary.

Version 0.5.6 (2024-05-09)

  • Provided a contribution section in the documentation.
  • Fixed a link in the documentation for the examples.

Version 0.5.5 (2024-03-21)

  • Minor changes to the checks to be consistent with EnergyModelsBase v0.6.7.

Version 0.5.4 (2024-03-04)

Examples

  • Fixed a bug when running the examples from a non-cloned version of EnergyModelsRenewableProducers.
  • This was achieved through a separate Project.toml in the examples.

NonDIsRes node

  • Moved the capacity constraints through the profile to the function EMB.constraints_capacity(n::NonDisRES, ...), and hence, removed the function EMB.create_node(n::NonDisRES, ...).

Minor updates

  • Added some checks and tests to the checks.
  • Restructured the test folder.

Version 0.5.3 (2024-01-30)

  • Updated the restrictions on the fields of individual types to be consistent.
  • Added option to not include the field data for the individual introduced Nodes.

Version 0.5.2 (2024-01-19)

  • Updated the documenation to be in line with the updated done in EnergyModelsBsae.
  • Moved RegHydroStor to a new file, legacy_constructors.jl to highlight that a user should use the new types, namely HydroStor and PumpedHydroStor.

Version 0.5.1 (2024-01-17)

  • Update the method constraints_level to match the signature updates for these methods in EnergyModelsBase. This includes renaming constraints_level to constraints_level_sp.
  • Moved the function to EMB.constraints_level_sp to avoid problems.

Version 0.5.0 (2023-12-18)

Adjustment to release in EMB 0.6.0

  • Adjusted the code for the new release.
  • Implementation of support for RepresentativePeriods for HydroStorage nodes.

Version 0.4.2 (2023-09-01)

Create a variable :spill for hydro storage node

  • This variable enables hydro storage nodes to spill water from the reservoir without producing energy.

Version 0.4.1 (2023-08-31)

Split the hydro storage node into to separate nodes

  • Split RegHydroStor into to types PumpedHydroStor and HydroStor. Both are subtypes

of the new abstract type HydroStorage <: EMB.Storage.

  • Fix: variational OPEX for HydroStor now depends on flow_out instead of

flow_in. The new type PumpedHydroStor has a separate parameter for variational OPEX for the pumps, which depends on flow_in.

Version 0.4.0 (2023-06-06)

Switch to TimeStruct

  • Switched the time structure representation to TimeStruct.
  • TimeStruct is implemented with only the basis features that were available in TimeStructures. This implies that neither operational nor strategic uncertainty is included in the model.

Version 0.3.0 (2023-05-30)

  • Adjustment to changes in EnergyModelsBase v0.4.0 related to extra input data.

Version 0.2.2 (2023-05-15)

  • Adjustment to changes in EnergyModelsBase v 0.3.3 related to the calls for the constraint functions.

Version 0.2.1 (2023-02-03)

  • Take the examples out to the folder examples.

Version 0.2.0 (2023-02-03)

Adjustmends to updates in EnergyModelsBase

Adjustment to version 0.3.0, namely:

  • Changed type (Node) calls in tests to be consistent with version 0.3.0.
  • Removal of the type GlobalData and replacement with fields in the type OperationalModel in all tests.
  • Changed type structure to be consistent with EMB version 0.3.0.
  • Substitution of certain constraints in create_node through functions which utilize dispatching on node types.
  • Changed the input to the function variables_node.

Version 0.1.3 (2022-12-12)

Internal release

  • Renamed to follow common prefix naming scheme.
  • Update README.

Version 0.1.2 (2022-12-02)

  • Minor test fixes in preparation of internal release.

Version 0.1.1 (2021-09-07)

Changes in naming

  • Major changes in both variable and parameter naming, check the commit message for an overview.
  • Change of structure in composite type "RegHydroStor".

Version 0.1.0 (2021-08-23)

  • Initial version with inclusion of nodes for:
    • nondispatchable renewable energy sources (NonDisRES) and
    • regulated hydro generation (RegHydroStor, can be used for pumped hydro storage).
diff --git a/dev/manual/quick-start/index.html b/dev/manual/quick-start/index.html index 8bad38f..211e914 100644 --- a/dev/manual/quick-start/index.html +++ b/dev/manual/quick-start/index.html @@ -1,3 +1,3 @@ Quick Start · EnergyModelsRenewableProducers
GitHub
+] add EnergyModelsBase

These packages are required as we do not only use them internally, but also for building a model.

  • Install the package EnergyModelsRenewableProducers

    ] add EnergyModelsRenewableProducers
    • diff --git a/dev/manual/simple-example/index.html b/dev/manual/simple-example/index.html index 7e25aef..9c396e4 100644 --- a/dev/manual/simple-example/index.html +++ b/dev/manual/simple-example/index.html @@ -7,4 +7,4 @@ julia> include(joinpath(exdir, "simple_nondisres.jl")) # Include the code into the Julia REPL to run the first example of the Hydropower node julia> include(joinpath(exdir, "simple_hydro_power.jl"))

    The code was downloaded with git clone

    The examples can then be run from the terminal with

    /path/to/EnergyModelsRenewableProducers.jl/examples $ julia simple_nondisres.jl
-/path/to/EnergyModelsRenewableProducers.jl/examples $ julia simple_hydro_power.jl
    +/path/to/EnergyModelsRenewableProducers.jl/examples $ julia simple_hydro_power.jl diff --git a/dev/nodes/hydropower/index.html b/dev/nodes/hydropower/index.html index 4f5ec48..c218dfd 100644 --- a/dev/nodes/hydropower/index.html +++ b/dev/nodes/hydropower/index.html @@ -1,5 +1,5 @@ -Hydropower · EnergyModelsRenewableProducers
    GitHub

    CO₂ storage node

    The reference storage node, RefStorage is quite flexible with respect to the individual storage behaviours, that is cyclic (both representative and strategic) or accumulating as it is included as parametric type using the individual storage behaviours. In addition, it allows for both charge and level different storage parameters. It is however not possible at the moment to provide a discharge capacity required in hydropower modelling. Furthermore, it is not possible to include an inflow to the storage node, except through artifically creating a source node representing the water flowing into the node.

    Hence, it is necessary to include specific hydropower storage node

    Introduced type and its field

    The HydroStorage abstract type is used to simplify the design of the constraints. It has in its current stage two concrete subtypes, HydroStor and PumpedHydroStor. Both types utilize the same main functionality, although PumpedHydroStor allows for utilizing electricity to store more water. The two nodes are designed to work with the cyclic storage behaviors.

    Input, output, and stored resource

    Although hydro reservoir store water, we have to assume in the current implementation that electricity is stored. The key reason for this is that we do not support in the modelling approach a conversion from the variable $\texttt{flow\_in}$ of a resource to a different stored resource.

    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.
    • charge::EMB.UnionCapacity:
      The charge storage parameters must include a capacity for charging. More information can be found on storage parameters.
      Meaning in boths nodes

      The charge field is only included for PumpedHydroStor nodes while HydroStor do not allow for flow into the node.

    • level::EMB.UnionCapacity:
      The level storage parameters must include a capacity for charging. More information can be found on storage parameters.
    • charge::EMB.UnionCapacity:
      The charge storage parameters must include a capacity for charging. More information can be found on storage parameters.
      Permitted values for storage parameters in `charge`, `level`, and `discharge`

      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. Similarly, you can only use FixedProfile or StrategicProfile for the fixed OPEX, but not RepresentativeProfile or OperationalProfile. The variable operating expenses can be provided as OperationalProfile as well. In addition, all capacity and fixed OPEX values have to be non-negative.

    • stor_res::ResourceEmit:
      The stor_res is the stored Resource. The current implementation of HydroStorage nodes do not consider the conversion of potential energy of the stored water to electricity. Hence, you must specifiy your electricity resource.
    • input::Dict{<:Resource, <:Real} and output::Dict{<:Resource, <:Real}:
      Both fields describe the input and output Resources with their corresponding conversion factors as dictionaries. The values correspond to charge and discharge efficiencies from the HydroStorage nodes.
      All values have to be in the range $[0, 1]$.
    • 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.

    Additional fields

    HydroStorage nodes add additional fields compared to RefStorage nodes. These fields are located below the field discharge, and hence, correspond to the 4ᵗʰ to 6ᵗʰ fields of the node. As a consequence, stor_res is now the 7ᵗʰ field compared to being the 4ᵗʰ in a RefStorage node.

    The individual fields are related to specifics of hydropower. These fields are given as:

    • level_init::TimeProfile:
      The initial level corresponds to the amount of electricity stored in the reservoir at the beginning of each strategic period. It can be provided as OperationalProfile. In practice, it is however sufficient to provide it as StrategicProfile as only a single value is used.
      The initial levels have to be non-negative and less than the maximum storage capacity.
    • level_inflow::TimeProfile:
      The inflow is representing the potential electricity flowing into the reservoir in each operational period. It is depending on rivers flowing into the reservoir or rainfall. It can be provided as OperationalProfile.
    • level_min::TimeProfile:
      The minimum level provides a lower bound on the usage of the storage node in each operational period. This lower bound can be enforced by regulators to maintain a minimum amount of available stored electricity. The current implementation does not allow for a violation of the constraint, although this can be implemented in a latter stage. It can be provided as OperationalProfile.
      The inflow has to be able in combination with the initial level to provide the required minimum level in the first operational period of each strategic period. In addition, all values have to be in the range $[0, 1]$.

    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 hydro power node types utilize all standard variables from RefStorage, as described on the page Optimization variables. The variables include:

    The variables $\texttt{flow\_in}$ and $\texttt{stor\_charge\_use}$ are fixed to a value of 0 in the function constraints_flow_in for HydroStor nodes as these nodes correspond to regulated hydropower plants and not pumped hydropower plants..

    Additional variables

    HydroStorage nodes must allow for spillage of surplus stored water. Hence, a single additional variable is declared through dispatching on the method EnergyModelsBase.variables_node():

    • $\texttt{hydro\_spill}[n, t]$: Spilled electricity in hydropower node $n$ in operational period $t$ with a typical unit of MW.
      The spillage in each operational period is a rate specifying how much electricity is spilled, that is not routed the the grid, but instead directed from the turbines to avoid overfilling the reservoir. It hence allows for an overflow from a reservoir if the inflow to a reservoir exceeds its capacity and the outflow through power generation.

    Constraints

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

    Hydropower storages nodes utilize in general the standard constraints described on Constraint functions for RefStorage nodes.

    stor_charge_xxx

    The constraints for $\texttt{stor\_charge\_use}$ are only implemented for PumpedHydroStor nodes. This also includes the contribution to the variables $\texttt{opex\_fixed}$ and $\texttt{opex\_var}$.

    These standard constraints are:

    • constraints_capacity:

      \[\begin{aligned} +Hydropower · EnergyModelsRenewableProducers

      GitHub

      Hydro storage node

      The reference storage node, RefStorage is quite flexible with respect to the individual storage behaviours, that is cyclic (both representative and strategic) or accumulating as it is included as parametric type using the individual storage behaviours. In addition, it allows for both charge and level different storage parameters. It is however not possible at the moment to provide a discharge capacity required in hydropower modelling. Furthermore, it is not possible to include an inflow to the storage node, except through artifically creating a source node representing the water flowing into the node.

      Hence, it is necessary to include specific hydropower storage node

      Introduced types and their fields

      The HydroStorage abstract type is used to simplify the design of the constraints. It has in its current stage two concrete subtypes, HydroStor and PumpedHydroStor. Both types utilize the same main functionality, although PumpedHydroStor allows for utilizing electricity to store more water. The two nodes are designed to work with the cyclic storage behaviors.

      Input, output, and stored resource

      Although hydro reservoir store water, we have to assume in the current implementation that electricity is stored. The key reason for this is that we do not support in the modelling approach a conversion from the variable $\texttt{flow\_in}$ of a resource to a different stored resource.

      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.
      • charge::EMB.UnionCapacity:
        The charge storage parameters must include a capacity for charging. More information can be found on storage parameters.
        Meaning in boths nodes

        The charge field is only included for PumpedHydroStor nodes while HydroStor do not allow for flow into the node.

      • level::EMB.UnionCapacity:
        The level storage parameters must include a capacity for charging. More information can be found on storage parameters.
      • charge::EMB.UnionCapacity:
        The charge storage parameters must include a capacity for charging. More information can be found on storage parameters.
        Permitted values for storage parameters in `charge`, `level`, and `discharge`

        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. Similarly, you can only use FixedProfile or StrategicProfile for the fixed OPEX, but not RepresentativeProfile or OperationalProfile. The variable operating expenses can be provided as OperationalProfile as well. In addition, all capacity and fixed OPEX values have to be non-negative.

      • stor_res::ResourceEmit:
        The stor_res is the stored Resource. The current implementation of HydroStorage nodes do not consider the conversion of potential energy of the stored water to electricity. Hence, you must specifiy your electricity resource.
      • input::Dict{<:Resource, <:Real} and output::Dict{<:Resource, <:Real}:
        Both fields describe the input and output Resources with their corresponding conversion factors as dictionaries. The values correspond to charge and discharge efficiencies from the HydroStorage nodes.
        All values have to be in the range $[0, 1]$.
      • 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.

      Additional fields

      HydroStorage nodes add additional fields compared to RefStorage nodes. These fields are located below the field discharge, and hence, correspond to the 4ᵗʰ to 6ᵗʰ fields of the node. As a consequence, stor_res is now the 7ᵗʰ field compared to being the 4ᵗʰ in a RefStorage node.

      The individual fields are related to specifics of hydropower. These fields are given as:

      • level_init::TimeProfile:
        The initial level corresponds to the amount of electricity stored in the reservoir at the beginning of each strategic period. It can be provided as OperationalProfile. In practice, it is however sufficient to provide it as StrategicProfile as only a single value is used.
        The initial levels have to be non-negative and less than the maximum storage capacity.
      • level_inflow::TimeProfile:
        The inflow is representing the potential electricity flowing into the reservoir in each operational period. It is depending on rivers flowing into the reservoir or rainfall. It can be provided as OperationalProfile.
      • level_min::TimeProfile:
        The minimum level provides a lower bound on the usage of the storage node in each operational period. This lower bound can be enforced by regulators to maintain a minimum amount of available stored electricity. The current implementation does not allow for a violation of the constraint, although this can be implemented in a latter stage. It can be provided as OperationalProfile.
        The inflow has to be able in combination with the initial level to provide the required minimum level in the first operational period of each strategic period. In addition, all values have to be in the range $[0, 1]$.

      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 hydro power node types utilize all standard variables from RefStorage, as described on the page Optimization variables. The variables include:

      The variables $\texttt{flow\_in}$ and $\texttt{stor\_charge\_use}$ are fixed to a value of 0 in the function constraints_flow_in for HydroStor nodes as these nodes correspond to regulated hydropower plants and not pumped hydropower plants..

      Additional variables

      HydroStorage nodes must allow for spillage of surplus stored water. Hence, a single additional variable is declared through dispatching on the method EnergyModelsBase.variables_node():

      • $\texttt{hydro\_spill}[n, t]$: Spilled electricity in hydropower node $n$ in operational period $t$ with a typical unit of MW.
        The spillage in each operational period is a rate specifying how much electricity is spilled, that is not routed the the grid, but instead directed from the turbines to avoid overfilling the reservoir. It hence allows for an overflow from a reservoir if the inflow to a reservoir exceeds its capacity and the outflow through power generation.

      Constraints

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

      Hydropower storages nodes utilize in general the standard constraints described on Constraint functions for RefStorage nodes.

      stor_charge_xxx

      The constraints for $\texttt{stor\_charge\_use}$ are only implemented for PumpedHydroStor nodes. This also includes the contribution to the variables $\texttt{opex\_fixed}$ and $\texttt{opex\_var}$.

      These standard constraints are:

      • constraints_capacity:

        \[\begin{aligned} \texttt{stor\_level\_inst}[n, t] & \geq \texttt{stor\_level}[n, t] \\ \texttt{stor\_charge\_inst}[n, t] & \geq \texttt{stor\_charge\_use}[n, t] \\ \texttt{stor\_discharge\_inst}[n, t] & \geq \texttt{stor\_discharge\_use}[n, t] \\ @@ -14,15 +14,15 @@ opex\_fixed(discharge(n), t_{inv}) \times \texttt{stor\_discharge\_inst}[n, first(t_{inv})] \end{aligned}\]

        Why do we use `first()`

        The variables $\texttt{stor\_level\_inst}$ are 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 capacities in the first operational period of a given strategic period $t_{inv}$ in the function constraints_opex_fixed.

      • constraints_opex_var:

        \[\begin{aligned} \texttt{opex\_var}&[n, t_{inv}] = \\ \sum_{t \in t_{inv}}& - opex\_var(level(n), t) \times \texttt{stor\_level}[n, t] \times EMB.multiple(t_{inv}, t) + \\ & - opex\_var(charge(n), t) \times \texttt{stor\_charge\_use}[n, t] \times EMB.multiple(t_{inv}, t) + \\ & - opex\_var(discharge(n), t) \times \texttt{stor\_discharge\_use}[n, t] \times EMB.multiple(t_{inv}, t) -\end{aligned}\]

        The function `EMB.multiple`

        The function $EMB.multiple(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₂ storage node, see above.

      Implementation of OPEX

      The fixed and variable OPEX constribubtion for the level and the charge capacities are only included if the corresponding storage parameters have a field opex_fixed and opex_var, respectively. Otherwise, they are omitted.

      The function constraints_flow_in is extended with a new method for hydropower nodes to differentiate whether the node is a pumped hydropower node or not. The standard constraints given by

      \[\begin{aligned} + opex\_var(level(n), t) \times \texttt{stor\_level}[n, t] \times scale\_op\_sp(t_{inv}, t) + \\ & + opex\_var(charge(n), t) \times \texttt{stor\_charge\_use}[n, t] \times scale\_op\_sp(t_{inv}, t) + \\ & + opex\_var(discharge(n), t) \times \texttt{stor\_discharge\_use}[n, t] \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_data:
      This function is only called for specified data of the CO₂ storage node, see above.

    Implementation of OPEX

    The fixed and variable OPEX constribubtion for the level and the charge capacities are only included if the corresponding storage parameters have a field opex_fixed and opex_var, respectively. Otherwise, they are omitted.

    The function constraints_flow_in is extended with a new method for hydropower nodes to differentiate whether the node is a pumped hydropower node or not. The standard constraints given by

    \[\begin{aligned} \texttt{stor\_level\_inst}[n, t] & \geq \texttt{stor\_level}[n, t] \\ \texttt{stor\_charge\_inst}[n, t] & \geq \texttt{stor\_charge\_use}[n, t] \\ \end{aligned}\]

    are extended with a constraint for PumpedHydroStor nodes given by

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

    while the variables $\texttt{flow\_in}$ and $\texttt{stor\_charge\_use}$ are fixed to a value of 0 for HydroStor nodes.

    These constraints allow either to include an efficiency for filling the reservoir (PumpedHydroStor) or avoiding unconstrained variables (HydroStor).

    Additional constraints

    Constraints calculated in create_node

    The outlet flow constraints are given as

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

    As a consequence, similar to the inlet flow constraint, we can specify an efficiency between 0 and 1 to account for loses in the turbine.

    In addition a constraint on the maximum discharge given by

    \[\texttt{stor\_discharge\_use}[n, t] \leq \texttt{stor\_level}[n, t]\]

    is included to constrain the discharge further. This constraint is in practice not active as the storage level is bound at a lower bound provided through the field level_min.

    Level constraints

    The level constraints are in general slightly more complex to understand. The overall structure is outlined on Constraint functions. The level constraints are called through the function constraints_level which then calls additional functions depending on the chosen time structure (whether it includes representative periods and/or operational scenarios) and the chosen storage behaviour.

    The hydro power nodes utilize the majority of the concepts from EnergyModelsBase but require adjustments for both constraining the variable $\texttt{stor\_level\_Δ\_op}$ and specifying how the storage node has to behave in the first operational period of a strategic period. This is achieved through dispatching on the functions constraints_level_aux.

    The constraints introduced in constraints_level_aux can be divided in three groups:

    1. the energy balance,

      \[\begin{aligned} +\texttt{stor\_charge\_use}[n, t] \times outputs(n, p) \qquad \forall p \in outputs(n)\]

      As a consequence, similar to the inlet flow constraint, we can specify an efficiency between 0 and 1 to account for loses in the turbine.

      In addition a constraint on the maximum discharge given by

      \[\texttt{stor\_discharge\_use}[n, t] \leq \texttt{stor\_level}[n, t]\]

      is included to constrain the discharge further. This constraint is in practice not active as the storage level is bound at a lower bound provided through the field level_min.

      Level constraints

      The level constraints are in general slightly more complex to understand. The overall structure is outlined on Constraint functions. The level constraints are called through the function constraints_level which then calls additional functions depending on the chosen time structure (whether it includes representative periods and/or operational scenarios) and the chosen storage behaviour.

      The hydro power nodes utilize the majority of the concepts from EnergyModelsBase but require adjustments for both constraining the variable $\texttt{stor\_level\_Δ\_op}$ and specifying how the storage node has to behave in the first operational period of a strategic period. This is achieved through dispatching on the functions constraints_level_aux.

      The constraints introduced in constraints_level_aux can be divided in three groups:

      1. the energy balance,

        \[\begin{aligned} \texttt{stor\_level\_Δ\_op}&[n, t] = \\ & level\_inflow(n, t) + \texttt{stor\_charge\_use}[n, t] - \\ & \texttt{stor\_discharge\_use}[n, t] - \texttt{hydro\_spill}[n, t] @@ -31,13 +31,13 @@ level\_init(n, first(t_{inv})) + \\ & \texttt{stor\_level\_Δ\_op}[n, first(t_{inv})] \times duration(first(t_{inv})) \end{aligned}\]

      2. the minimum level constraint

        \[\texttt{stor\_level}[n, t] \geq level\_min(n, t) \times \texttt{stor\_level\_inst}[n, t]\]

      corresponding to the change in the storage level in an operational period and strategic period, respectively.

      If the time structure includes representative periods, we also calculate the change of the storage level in each representative period within the function constraints_level_iterate (from EnergyModelsBase):

      \[ \texttt{stor\_level\_Δ\_rp}[n, t_{rp}] = \sum_{t \in t_{rp}} - \texttt{stor\_level\_Δ\_op}[n, t] \times EMB.multiple(t_{rp}, t)\]

      The general level constraint is calculated in the function constraints_level_iterate (from EnergyModelsBase):

      \[\texttt{stor\_level}[n, t] = prev\_level + -\texttt{stor\_level\_Δ\_op}[n, t] \times duration(t)\]

      in which the value $prev\_level$ is depending on the type of the previous operational ($t_{prev}$) and strategic level ($t_{inv,prev}$) (as well as the previous representative period ($t_{rp,prev}$)). It is calculated through the function previous_level.

      In the case of hydropower node, we can distinguish the following cases:

      1. The first operational period in the first representative period in any strategic period (given by $typeof(t_{prev}) = typeof(t_{rp, prev})$ and $typeof(t_{inv,prev}) = NothingPeriod$). In this situation, we can distinguish three cases, the time structure does not include representative periods:

        \[prev\_level = \texttt{stor\_level}[n, last(t_{inv})]\]

        the time structure includes representative periods and the storage behavior is given as CyclicRepresentative:

        \[prev\_level = \texttt{stor\_level}[n, last(t_{rp})]\]

        the time structure includes representative periods and the storage behavior is given as CyclicStrategic:

        \[\begin{aligned} + \texttt{stor\_level\_Δ\_op}[n, t] \times scale\_op\_sp(t_{inv}, t)\]

        The general level constraint is calculated in the function constraints_level_iterate (from EnergyModelsBase):

        \[\texttt{stor\_level}[n, t] = prev\_level + +\texttt{stor\_level\_Δ\_op}[n, t] \times duration(t)\]

        in which the value $prev\_level$ is depending on the type of the previous operational ($t_{prev}$) and strategic level ($t_{inv,prev}$) (as well as the previous representative period ($t_{rp,prev}$)). It is calculated through the function previous_level.

        In the case of hydropower node, we can distinguish the following cases:

        1. The first operational period in the first representative period in any strategic period (given by $typeof(t_{prev}) = typeof(t_{rp, prev})$ and $typeof(t_{inv,prev}) = NothingPeriod$). In this situation, we can distinguish three cases, the time structure does not include representative periods:

          \[prev\_level = \texttt{stor\_level}[n, last(t_{inv})]\]

          the time structure includes representative periods and the storage behavior is given as CyclicRepresentative:

          \[prev\_level = \texttt{stor\_level}[n, last(t_{rp})]\]

          the time structure includes representative periods and the storage behavior is given as CyclicStrategic:

          \[\begin{aligned} prev\_level = & \texttt{stor\_level}[n, first(t_{rp,last})] - \\ & \texttt{stor\_level\_Δ\_op}[n, first(t_{rp,last})] \times duration(first(t_{rp,last})) + \\ & \texttt{stor\_level\_Δ\_rp}[n, t_{rp,last}] \times duration\_strat(t_{rp,last}) -\end{aligned}\]

        2. The first operational period in subsequent representative periods in any strategic period (given by $typeof(t_{prev}) = nothing$) f the the storage behavior is given as CyclicStrategic:

          \[\begin{aligned} +\end{aligned}\]

        3. The first operational period in subsequent representative periods in any strategic period (given by $typeof(t_{prev}) = nothing$) f the the storage behavior is given as CyclicStrategic:

          \[\begin{aligned} prev\_level = & \texttt{stor\_level}[n, first(t_{rp,prev})] - \\ & \texttt{stor\_level\_Δ\_op}[n, first(t_{rp,prev})] \times duration(first(t_{rp,prev})) + \\ & \texttt{stor\_level\_Δ\_rp}[n, t_{rp,prev}] -\end{aligned}\]

          This situation only occurs in cases in which the time structure includes representative periods.

        4. All other operational periods:

          \[ prev\_level = \texttt{stor\_level}[n, t_{prev}]\]

        All cases are implemented in EnergyModelsBase simplifying the design of the system.

    +\end{aligned}\]

    This situation only occurs in cases in which the time structure includes representative periods.

  • All other operational periods:

    \[ prev\_level = \texttt{stor\_level}[n, t_{prev}]\]

    • All cases are implemented in EnergyModelsBase simplifying the design of the system.

    diff --git a/dev/nodes/nondisres/index.html b/dev/nodes/nondisres/index.html index 283ecea..09183d5 100644 --- a/dev/nodes/nondisres/index.html +++ b/dev/nodes/nondisres/index.html @@ -1,5 +1,5 @@ -Non-dispatchable RES · EnergyModelsRenewableProducers
    GitHub

    Non-dispatchable renewable energy source node

    Non-dispatchable renewable energy sources generate electricity from intermittent energy sources. Examples for intermittent energy sources are solar irradiation, the wind, or the flow within rivers. Although these energy sources have a constant nominal capacity, their production depends on intermittent energy sources. Although EnergyModelsX allows for capacities varying on the operational level, it is then not possible to include investments for a technology. Hence, the design of a RefSource is not satisfactory, when considering potential investments in capacities.=.

    Hence, it is necessary to implement a source node representing intermittent renewable energy generation.

    Introduced type and its field

    The NonDisRES 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 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 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 non-dispatchable renewable energy source, output should always include your electricity resource.In practice, you should use a value of 1.
      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.
      Note

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

    Additional fields

    NonDisRES nodes add a single additional field compared to a RefSource:

    • profile::TimeProfile:
      The profile is used as a multiplier to the installed capacity to represent the maximum actual capacity in each operational period.
      The profile should be provided as OperationalProfile or at least as RepresentativeProfile. In addition, all values should be in the range $[0, 1]$.

    This field is at the 3ʳᵈ position below the field cap as shown in NonDisRES.

    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 non-dispatchable renewable energy source node types utilize all standard variables from the RefSource node type, as described on the page Optimization variables. The variables include:

    Additional variables

    NonDisRES nodes should keep track on the curtailment of the electricity, that is the unused capacity in each operational time period. Hence, a single additional variable is declared through dispatching on the method EnergyModelsBase.variables_node():

    • $\texttt{curtailment}[n, t]$: Curtailed capacity of source $n$ in operational period $t$ with a typical unit of MW.
      The curtailed electricity specifies the unused generation capacity of the non-dispatchable energy source. It is currently only used in the calculation, but not with a cost. This can be added by the user, if desired.

    Constraints

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

    Non-dispatchable renewable energy source nodes utilize in general the standard constraints described on Constraint functions. In fact, they use the same create_node function as a RefSource node. These standard constraints are:

    • constraints_capacity_installed:

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

    • constraints_flow_out:

      \[\texttt{flow\_out}[n, t, p] = +Non-dispatchable RES · EnergyModelsRenewableProducers

      GitHub

      Non-dispatchable renewable energy source node

      Non-dispatchable renewable energy sources generate electricity from intermittent energy sources. Examples for intermittent energy sources are solar irradiation, the wind, or the flow within rivers. Although these energy sources have a constant nominal capacity, their production depends on intermittent energy sources. Although EnergyModelsX allows for capacities varying on the operational level, it is then not possible to include investments for a technology. As a consequence, the design of the RefSource is not satisfactory, when considering potential investments in capacities.=.

      Hence, it is necessary to implement a source node representing intermittent renewable energy generation.

      Introduced type and its fields

      The NonDisRES 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 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 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 non-dispatchable renewable energy source, output should always include your electricity resource.In practice, you should use a value of 1.
        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.
        Note

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

      Additional fields

      NonDisRES nodes add a single additional field compared to a RefSource:

      • profile::TimeProfile:
        The profile is used as a multiplier to the installed capacity to represent the maximum actual capacity in each operational period.
        The profile should be provided as OperationalProfile or at least as RepresentativeProfile. In addition, all values should be in the range $[0, 1]$.

      This field is at the 3ʳᵈ position below the field cap as shown in NonDisRES.

      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 non-dispatchable renewable energy source node types utilize all standard variables from the RefSource node type, as described on the page Optimization variables. The variables include:

      Note

      Non-dispatchable renewable energy source nodes are not compatible with CaptureData. Hence, you can only provide EmissionsProcess to the node. It is our aim to include the potential for construction emissions in a latter stage

      Additional variables

      NonDisRES nodes should keep track on the curtailment of the electricity, that is the unused capacity in each operational time period. Hence, a single additional variable is declared through dispatching on the method EnergyModelsBase.variables_node():

      • $\texttt{curtailment}[n, t]$: Curtailed capacity of source $n$ in operational period $t$ with a typical unit of MW.
        The curtailed electricity specifies the unused generation capacity of the non-dispatchable energy source. It is currently only used in the calculation, but not with a cost. This can be added by the user, if desired.

      Constraints

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

      Non-dispatchable renewable energy source nodes utilize in general the standard constraints described on Constraint functions. In fact, they use the same create_node function as a RefSource node. These standard constraints are:

      • 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_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})]\]

      • 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 EMB.multiple(t_{inv}, t)\]

      • constraints_data:
        This function is only called for specified data of the non-dispatchable renewable energy source, see above.

      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.

      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.

      The function constraints_capacity is extended with a new method for non-dispatchable renewable energy source nodes to allow the inclusion of the production profile and the variable $\texttt{curtailment}[n, t]$. It now includes two individual constraints:

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

      and

      \[\texttt{cap\_use}[n, t] + \texttt{curtailment}[n, t] = -profile(n, t) \times \texttt{cap\_inst}[n, t]\]

      This function still calls the subfunction constraints_capacity_installed to limit the variable $\texttt{cap\_inst}[n, t]$ or provide capacity investment options.

      Additional constraints

      NonDisRES nodes do not add additional constraints.

      +\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 variables $\texttt{cap\_inst}$ are 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 capacities 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 non-dispatchable renewable energy source, see above.

    The function constraints_capacity is extended with a new method for non-dispatchable renewable energy source nodes to allow the inclusion of the production profile and the variable $\texttt{curtailment}[n, t]$. It now includes two individual constraints:

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

    and

    \[\texttt{cap\_use}[n, t] + \texttt{curtailment}[n, t] = +profile(n, t) \times \texttt{cap\_inst}[n, t]\]

    This function still calls the subfunction constraints_capacity_installed to limit the variable $\texttt{cap\_inst}[n, t]$ or provide capacity investment options.

    Additional constraints

    NonDisRES nodes do not add additional constraints.

    diff --git a/dev/objects.inv b/dev/objects.inv index 13da27f2b1a624a9c2089cd52fa455c1cf933bc7..39cae3ee4c6098b94125674feb78d1c1c81c14ae 100644 GIT binary patch delta 2115 zcmV-J2)y^T5x)_TlYiN6+c*?`*H>Ji3D9|9Y{^TLK24ftkOEE7iQCRYQ5cLw+iGP| z)zTz?Gv6{_HkYIpidvl}K!Dihy@$&^cO(7KWA~7x-fNG$Kx}|3zGv2+h8YbeKQrI` zL6VflsV>tToxtDX3#`PKLOb#IQNRehr{aGLKwV%0m+C`O0DpYA{AbmoCVrm44GS1e z7=%1UjgWgRnS?y_{3K?Hu4N2O-~$f{evWAB?&vM9?B;Tn1MD8Wm`D7M#Z822Yywy1 zXKTmrNXjQ!D$I9@L7HZ^|iood6>rjZI-eYfNF387nNYj;WA|L_TgGW z-LR0|iA{Zsxqp|rEKaPzzl~}9Fp09;z;|`z`p5)6%KxQ;AEqo0DK2-<(jE5_vhi8q zC2bI0vJ<#g-+{on>#`*A!!4+>o{286-;A3D1@$TPqj-btP-Z2i@$*#?JS2%9&|4O? zk>te@oO_<1`W&Y#)_d)TJSNJLNnKy3ChAH_$R+bdNPqsUC2917G?t*T3~}C}ouwT; zNFO4cl!o|e$NachQx~@IOOzd)VI{<9>=k$yF%vwcIrDNx`Qag6eARh)f3_7Nj)0C8c&`N_rj}r9i z_NlKjG_CNMzPwCPQCV!L9I%=pZUFYE2y+iSi&d-> z@e271fpClzeyP(+G*j3ojx>csY==ypai$PT%6}BOTHO>l3_50u*X(J!BN$@|^}H5l zx48~R;UtYI8Y%&o25u%cN4cjzyw#9PHeML&;RL zPPyFaZMI#^zDI~T%8cTmrVBzBq;8FI%K2?FJtfX;EaM92&(%!EDd#URwdtIE zx*0N&Oh-=Vl+)#E_34~^x&pI@;0N(qq-cWWf#j~xMrNn1Jz(WkgaS}%C$=;aM8^A!}?bABTLr@S-92QC$qk`e{R5R&(}w zSZAN>&OV)+&OQenvy=PHIM?5FxPKjCcxeA0gp7*3t!Z;AXdw)F{~P&pD##&0ke`Vg z`;k~R;TwY0T_;gXLEsx%1}ettXT7ZI@agDcVyV~R(?&6|1Rc}*D(Wmh!LGlxL>AR> zDPdN_<$(3|W41@9dt|w7D4Ww5!`+-ZFgEF&YIF(&g~+IF^)(CfPZXh&Hd`e zEvh9Erbl*W3$0p`Y9=F!YDr<1otb%kFt#%jw-B|qtZ@%fZcT*sgZn*VT}dL5ZRWRm z7LE#kRHGf4e2^r@U4yiXFMM95^mqCCij2~mL<->|f7A?WYyHBju?Dqk{lY8Lpf>23 z)+!48REDDFH3OzXJW2dZSbs!g;g>Dp%Gi&@lM$-`7470Ynbp$vFl$f+z? zl`A8vl!LBT^$)G_QIUT=d9( zYOePxLalxf^Qu>om_0Wm!-w#tEYHha{+JzK?3nw538@SDkJbtsQ+Fo<(kFk< zR%x7>3^#+3R1oy66l9a_3MaXv3Gw({7;x$pz3~=)Jw&|+}~*tTvSesk<=;Q@M@7eU|Z@w48`sD zN=n5hBsGtF-Zwg)a5^Ji=X;3^9f!tGv&nB>8w{TLmwt!?yMM)ML1n*&hlD{Te}s}3 z0KMgH*F6A+Hw-n!tCzS4FpJyIVSbO#+As2|Vn?s&W>pzDn~p65XL=bpo0?_d40KFO zzEH2L_iGbhf5FD}>2KJEO$JTTcvOyyasik;FGzS6yT!{@nSLLeLP~%#k6hlTER+ZJ zILK1JLhP-68h_!rUIvtx+)Ml$8(FnWZlPvI*7A~DVp=8X*u8OUF*ru zRW>?kFsv?~Vdu4N%l3BcmNiPLCDQEv$v0oS9vHvE7Ca=gnEx#>wc-5%Uesk0b(W&; teFFA04CB&>x_u_F}zUD->TZx{|9h_%wFbq7x(}G delta 2105 zcmV-92*&rn5w#JJlYiT8+%^z>*H;V>8)zTsU1=||^Hj%ikpOX;deihF2o|)&-BqF$ z68JEdIwWu8oxq>s7g&j33hl(-M*$=3j*9(}_kv)nAwa>S$Pv9^4E2v)!43~##?B8T5YXPVhCvZ^-rW`Iq z7H{vbB-Awv*?+A#)ccrwnakqD3jCXx#`lvby9s<(N3O3-;Jy66RPe);#UaJ*?peCy zUP3lL3%sNaqDyuHSL$~laPGP+N&IjNYOUu(msc;xeFX*ePw1w2iR@5rC8hK8T@f^r z#1H5V3))EX>4G??zxDvtm5!a$O6}M=gM1m}GU%9APEk_EKr00X zqe)P!JDxttw6sDqeg5UQm~D)sv}U4b$BUPx+VSEQ9_n~LMP+fIa=~h*w*lCrBE{YF zELM3=J8@PWGG&apcGZ~?${&-$HBo} z1e7c@>y*or-elW#%%WCLYLy0Ye)j_rmZ$)zz_GknreEa#LYmveJ{#w+Md`0xt?sWy z?tiZW(>nLQWJ$VbXlk;F`5qzWC^L$Knl1=kkh(R-so=NC^prTWv5YH%KUXsur-Hx0 z)IR6rpPL~Q$#mrBobq$ITK#iQ{<#9Phu{bCT9jvkt%2mO&_-sbtUY1n9fSf8BaS_mzKe>!Ld~S_0(8vMib%>V7&PCNl&UetDHyXL_F^n!oQg3*&18%N zI%Zdw)R}2&eUjNlm|%V6s{!fU(}QhR)dYKVO_=F5!EV%q8R(epd+trP?Ix&lZGR&O zN5tMA|NZz;?{Z$T?=0XEQ)S60yr@#HD?lw*Vmc(T8j(bggnhE=T6&96r7mi9t}cq2 z=*OkHUPCrm=&*=<8&gD3G>aKRe#@}-C)QiVe8RId@I%%(SiTPVdJ#oK;iD!Pkp0t! zx~vxL^D5Y<^RdA`*MogJH-mi+I)7#-_nUdHf8cOC((usv-w7F&d0WfoRM0{=^6n?< z=TwkGf*?N=H})g3Yr;1KySq-JmV&@HvJF&>)os13`ta%KW@4%L;nPMlu>>8{`Xu@+ zKf#H=wM7=)a4BJS!{vhY>3z1xpnG7uZ77?cF_ybIbzpANIn|gH2nvx=$A9V@7$nN@ z3CjgJ&zk4eom+HEB2AB+%obX=B-Knt6y1`-EGIMb>R{|-CT<{VV_D-4qCA>N>j%$! z#Ck1>M7EjV7FoC|;!&-3RPsTR^xreQ$+uS&l-?Rr2p8p}=1*H27oLyxr(GKto}2!( zLC3UKQQ)UC6E$xcuo9vn@qb^!A{vXZY{^!}c_f}pSj}4qQE0fZeu0-Kwc;YP7nlr9 zqJb#x!)?P`DW*qv5ALDEqubh(Eh|T!jUHo`x+BjTW6ZL0q{OU`AM{3S!%c?@;CUgZ zieS~PjA&90x>ePCO}iK&apNOdZI{N#)yxLf1|4&ND#H%#=q-%g`+tz^RGn#FjVie5 zk>k`{A60}}-4OF?RFRlH7bC+)_*i!5WhsBii7$4{{Yvtc1IvWeh5V1!3g=RHClb;J zf6rEFoS6(alaW*q^sE%*jO~gbxups5_-z<)>J_8$7L%bHaI?kk7_*P$2ra+>!Jq1nY3aunVqGihrS~?;;buswuRtAbTGvYwLJ zXtLTBS%sQORvUE8+8A#?O%`d2~bvt%e$0?(oheBEcGkI-kzqB zbnC^vyt!WDzkjj$QoFepYG%GHZ>}Y#Wzy?J>s8j90Gm1F;FsXVCJSA8l`z5zWZ={% zJYsiijG=Xe&CqCcy&)L*Kos+hctm*u=xesEnzwfRD#wx*`&N%tk8W2vzM#XfXLy2> z*N!b`*0D#{D5bVYv%5z>d~N0*zrz+Jvqk?YFm>Sl0Wwk4 using EnergyModelsRenewableProducers\n# Get the path of the examples directory\njulia> exdir = joinpath(pkgdir(EnergyModelsRenewableProducers), \"examples\")\n# Include the code into the Julia REPL to run the first example of the NonDisRes node\njulia> include(joinpath(exdir, \"simple_nondisres.jl\"))\n# Include the code into the Julia REPL to run the first example of the Hydropower node\njulia> include(joinpath(exdir, \"simple_hydro_power.jl\"))","category":"page"},{"location":"manual/simple-example/#The-code-was-downloaded-with-git-clone","page":"Examples","title":"The code was downloaded with git clone","text":"","category":"section"},{"location":"manual/simple-example/","page":"Examples","title":"Examples","text":"The examples can then be run from the terminal with","category":"page"},{"location":"manual/simple-example/","page":"Examples","title":"Examples","text":"/path/to/EnergyModelsRenewableProducers.jl/examples $ julia simple_nondisres.jl\n/path/to/EnergyModelsRenewableProducers.jl/examples $ julia simple_hydro_power.jl","category":"page"},{"location":"manual/quick-start/#quick_start","page":"Quick Start","title":"Quick Start","text":"","category":"section"},{"location":"manual/quick-start/","page":"Quick Start","title":"Quick Start","text":"Install the most recent version of Julia\nInstall the package EnergyModelsBase and the time package TimeStruct, by running:\n] add TimeStruct\n] add EnergyModelsBase\nThese packages are required as we do not only use them internally, but also for building a model.\nInstall the package EnergyModelsRenewableProducers\n] add EnergyModelsRenewableProducers","category":"page"},{"location":"library/internals/methods-EMB/#Methods-EnergyModelsBase","page":"Methods - EnergyModelsBase","title":"Methods - EnergyModelsBase","text":"","category":"section"},{"location":"library/internals/methods-EMB/#Index","page":"Methods - EnergyModelsBase","title":"Index","text":"","category":"section"},{"location":"library/internals/methods-EMB/","page":"Methods - EnergyModelsBase","title":"Methods - EnergyModelsBase","text":"Pages = [\"methods-EMB.md\"]","category":"page"},{"location":"library/internals/methods-EMB/#Extension-methods","page":"Methods - EnergyModelsBase","title":"Extension methods","text":"","category":"section"},{"location":"library/internals/methods-EMB/","page":"Methods - EnergyModelsBase","title":"Methods - EnergyModelsBase","text":"EnergyModelsBase.variables_node\nEnergyModelsBase.create_node","category":"page"},{"location":"library/internals/methods-EMB/#EnergyModelsBase.variables_node","page":"Methods - EnergyModelsBase","title":"EnergyModelsBase.variables_node","text":"EMB.variables_node(m, 𝒩ⁿᵈʳ::Vector{NonDisRES}, 𝒯, modeltype::EnergyModel)\n\nCreate the optimization variable :curtailment for every NonDisRES node. This method is called from EnergyModelsBase.jl.\n\n\n\n\n\nEMB.variables_node(m, 𝒩::Vector{<:HydroStorage}, 𝒯, modeltype::EnergyModel)\n\nCreate the optimization variable :hydro_spill for every HydroStorage node. This variable enables hydro storage nodes to spill water from the reservoir without producing energy. Wihtout this slack variable, parameters with too much inflow would else lead to an infeasible model. \n\n\n\n\n\n","category":"function"},{"location":"library/internals/methods-EMB/#EnergyModelsBase.create_node","page":"Methods - EnergyModelsBase","title":"EnergyModelsBase.create_node","text":"EMB.create_node(m, n::HydroStorage, 𝒯, 𝒫, modeltype::EnergyModel)\n\nSets all constraints for the regulated hydro storage node.\n\n\n\n\n\n","category":"function"},{"location":"library/internals/methods-EMB/#Constraint-methods","page":"Methods - EnergyModelsBase","title":"Constraint methods","text":"","category":"section"},{"location":"library/internals/methods-EMB/","page":"Methods - EnergyModelsBase","title":"Methods - EnergyModelsBase","text":"EnergyModelsBase.constraints_capacity\nEnergyModelsBase.constraints_flow_in\nEnergyModelsBase.constraints_level_aux","category":"page"},{"location":"library/internals/methods-EMB/#EnergyModelsBase.constraints_capacity","page":"Methods - EnergyModelsBase","title":"EnergyModelsBase.constraints_capacity","text":"constraints_capacity(m, n::NonDisRES, 𝒯::TimeStructure, modeltype::EnergyModel)\n\nFunction for creating the constraint on the maximum capacity of a NonDisRES. Also sets the constraint defining curtailment.\n\n\n\n\n\n","category":"function"},{"location":"library/internals/methods-EMB/#EnergyModelsBase.constraints_flow_in","page":"Methods - EnergyModelsBase","title":"EnergyModelsBase.constraints_flow_in","text":"constraints_flow_in(m, n::HydroStor, 𝒯::TimeStructure, modeltype::EnergyModel)\n\nWhen n::HydroStor, the variable :flow_in is fixed to 0 for all potential inputs.\n\n\n\n\n\nconstraints_flow_in(m, n::PumpedHydroStor, 𝒯::TimeStructure, modeltype::EnergyModel)\n\nWhen n::PumpedHydroStor, the variable :flow_in is multiplied with the inputs value to calculate the variable :stor_charge_use.\n\n\n\n\n\n","category":"function"},{"location":"library/internals/methods-EMB/#EnergyModelsBase.constraints_level_aux","page":"Methods - EnergyModelsBase","title":"EnergyModelsBase.constraints_level_aux","text":"EMB.constraints_level_aux(m, n::HydroStorage, 𝒯, 𝒫, modeltype)\n\nFunction for creating the Δ constraint for the level of a HydroStorage node as well as the specification of the initial level in a strategic period.\n\nThe change in storage level in the reservoir at operational periods t is the inflow through :level_inflow plus the input :stor_charge_use minus the production :stor_discharge_use and the spillage of water due to overflow :hydro_spill.\n\n\n\n\n\n","category":"function"},{"location":"library/internals/methods-EMB/#Check-methods","page":"Methods - EnergyModelsBase","title":"Check methods","text":"","category":"section"},{"location":"library/internals/methods-EMB/","page":"Methods - EnergyModelsBase","title":"Methods - EnergyModelsBase","text":"EnergyModelsBase.check_node","category":"page"},{"location":"library/internals/methods-EMB/#EnergyModelsBase.check_node","page":"Methods - EnergyModelsBase","title":"EnergyModelsBase.check_node","text":"EMB.check_node(n::NonDisRES, 𝒯, modeltype::EMB.EnergyModel, check_timeprofiles::Bool)\n\nThis method checks that the NonDisRES node is valid.\n\nChecks\n\nThe field cap is required to be non-negative (similar to the Source check).\nThe value of the field fixed_opex is required to be non-negative and accessible through a StrategicPeriod as outlined in the function check_fixed_opex(n, 𝒯ᴵⁿᵛ, check_timeprofiles).\nThe values of the dictionary output are required to be non-negative (similar to the Source check).\nThe field profile is required to be in the range 0 1 for all time steps t mathcalT.\n\n\n\n\n\nEMB.check_node(n::HydroStorage, 𝒯, modeltype::EMB.EnergyModel, check_timeprofiles::Bool)\n\nThis method checks that the HydroStorage node is valid.\n\nChecks\n\nThe TimeProfile of the field capacity in the type in the field charge is required to be non-negative if the chosen composite type has the field capacity.\nThe TimeProfile of the field capacity in the type in the field level is required to be non-negative`.\nThe TimeProfile of the field capacity in the type in the field discharge is required to be non-negative if the chosen composite type has the field capacity.\nThe TimeProfile of the field fixed_opex is required to be non-negative and accessible through a StrategicPeriod as outlined in the function check_fixed_opex(n, 𝒯ᴵⁿᵛ, check_timeprofiles) for the chosen composite type .\nThe field output can only include a single Resource.\nThe value of the field output is required to be smaller or equal to 1.\nThe value of the field input is required to be in the range 0 1.\nThe value of the field level_init is required to be in the range level_min 1 cdot stor_cap(t) for all time steps t mathcalT.\nThe value of the field level_init is required to be in the range 0 1.\nThe value of the field level_min is required to be in the range 0 1.\n\n\n\n\n\n","category":"function"},{"location":"how-to/update-models/#update-models","page":"Update models","title":"Update your model to the latest versions","text":"","category":"section"},{"location":"how-to/update-models/","page":"Update models","title":"Update models","text":"EnergyModelsRenewableProducers is still in a pre-release version. Hence, there are frequently breaking changes occuring, although we plan to keep backwards compatibility. This document is designed to provide users with information regarding how they have to adjust their models to keep compatibility to the latest changes. We will as well implement information regarding the adjustment of extension packages, although this is more difficult due to the vast majority of potential changes.","category":"page"},{"location":"how-to/update-models/#Adjustments-from-0.4.2","page":"Update models","title":"Adjustments from 0.4.2","text":"","category":"section"},{"location":"how-to/update-models/#Key-changes-for-nodal-descriptions","page":"Update models","title":"Key changes for nodal descriptions","text":"","category":"section"},{"location":"how-to/update-models/","page":"Update models","title":"Update models","text":"Version 0.7 of EnergyModelsBase introduced both storage behaviours resulting in a rework of the individual approach for calculating the level balance as well as the potential to have charge and discharge capacities through storage parameters.","category":"page"},{"location":"how-to/update-models/","page":"Update models","title":"Update models","text":"note: Note\nThe legacy constructors for calls of the composite type of version 0.5 will be included at least until version 0.7.","category":"page"},{"location":"how-to/update-models/#[HydroStor](@ref)","page":"Update models","title":"HydroStor","text":"","category":"section"},{"location":"how-to/update-models/","page":"Update models","title":"Update models","text":"HydroStor was significantly reworked due to the changes in EnergyModelsBase The total rework is provided below.","category":"page"},{"location":"how-to/update-models/","page":"Update models","title":"Update models","text":"# The previous nodal description for a `HydroStor` node was given by:\nHydroStor(\n id,\n rate_cap::TimeProfile,\n stor_cap::TimeProfile,\n\n level_init::TimeProfile,\n level_inflow::TimeProfile,\n level_min::TimeProfile,\n\n opex_var::TimeProfile,\n opex_fixed::TimeProfile,\n stor_res::ResourceCarrier,\n input::Dict{<:Resource, <:Real},\n output::Dict{<:Resource, <:Real},\n data::Vector{Data},\n)\n\n# This translates to the following new version\nHydroStor{CyclicStrategic}(\n id,\n StorCapOpexFixed(stor_cap, opex_fixed),\n StorCapOpexVar(rate_cap, opex_var),\n level_init,\n level_inflow,\n level_min,\n stor_res,\n input,\n output,\n data,\n)","category":"page"},{"location":"how-to/update-models/#[PumpedHydroStor](@ref)","page":"Update models","title":"PumpedHydroStor","text":"","category":"section"},{"location":"how-to/update-models/","page":"Update models","title":"Update models","text":"PumpedHydroStor was significantly reworked due to the changers in EnergyModelsBase The total rework is provided below.","category":"page"},{"location":"how-to/update-models/","page":"Update models","title":"Update models","text":"# The previous nodal description for a `PumpedHydroStor` node was given by:\nPumpedHydroStor(\n id,\n rate_cap::TimeProfile,\n stor_cap::TimeProfile,\n\n level_init::TimeProfile,\n level_inflow::TimeProfile,\n level_min::TimeProfile,\n\n opex_var::TimeProfile,\n opex_var_pump::TimeProfile,\n opex_fixed::TimeProfile,\n stor_res::ResourceCarrier,\n input::Dict{<:Resource, <:Real},\n output::Dict{<:Resource, <:Real},\n data::Vector{Data},\n)\n\n# This translates to the following new version\nPumpedHydroStor{CyclicStrategic}(\n id,\n StorCapOpexVar(rate_cap, opex_var_pump),\n StorCapOpexFixed(stor_cap, opex_fixed),\n StorCapOpexVar(rate_cap, opex_var),\n level_init,\n level_inflow,\n level_min,\n stor_res,\n input,\n output,\n data,\n)","category":"page"},{"location":"how-to/update-models/#Adjustments-from-0.4.0-to-0.6.x","page":"Update models","title":"Adjustments from 0.4.0 to 0.6.x","text":"","category":"section"},{"location":"how-to/update-models/#Key-changes-for-nodal-descriptions-2","page":"Update models","title":"Key changes for nodal descriptions","text":"","category":"section"},{"location":"how-to/update-models/","page":"Update models","title":"Update models","text":"Version 0.4.1 introduced two new types that replaced the original RegHydroStor node with two types called PumpedHydroStor and HydroStor. The changes allowed for the introduction of a variable OPEX for pumping. In the translation below, it is assumed that the variable OPEX for pumping is 0.","category":"page"},{"location":"how-to/update-models/","page":"Update models","title":"Update models","text":"# The previous nodal description was given by:\nRegHydroStor(\n id::Any,\n rate_cap::TimeProfile,\n stor_cap::TimeProfile,\n has_pump::Bool,\n level_init::TimeProfile,\n level_inflow::TimeProfile,\n level_min::TimeProfile,\n opex_var::TimeProfile,\n opex_fixed::TimeProfile,\n stor_res::ResourceCarrier,\n input,\n output,\n Data,\n)\n\n# This translates to the following new version if has_pump == true\nPumpedHydroStor(\n id,\n StorCapOpexVar(rate_cap, FixedProfile(0)),\n StorCapOpexFixed(stor_cap, opex_fixed),\n StorCapOpexVar(rate_cap, opex_var),\n level_init,\n level_inflow,\n level_min,\n stor_res,\n input,\n output,\n Data,\n)\n# and the following version if has_pump == false\nHydroStor(\n id,\n StorCapOpexFixed(stor_cap, opex_fixed),\n StorCapOpexVar(rate_cap, opex_var),\n level_init,\n level_inflow,\n level_min,\n stor_res,\n input,\n output,\n Data,\n)","category":"page"},{"location":"library/internals/methods-fields/#Methods-Accessing-fields","page":"Methods - Accessing fields","title":"Methods - Accessing fields","text":"","category":"section"},{"location":"library/internals/methods-fields/#Index","page":"Methods - Accessing fields","title":"Index","text":"","category":"section"},{"location":"library/internals/methods-fields/","page":"Methods - Accessing fields","title":"Methods - Accessing fields","text":"Pages = [\"methods-fields.md\"]","category":"page"},{"location":"library/internals/methods-fields/#NonDisRES","page":"Methods - Accessing fields","title":"NonDisRES","text":"","category":"section"},{"location":"library/internals/methods-fields/","page":"Methods - Accessing fields","title":"Methods - Accessing fields","text":"EnergyModelsRenewableProducers.profile","category":"page"},{"location":"library/internals/methods-fields/#EnergyModelsRenewableProducers.profile","page":"Methods - Accessing fields","title":"EnergyModelsRenewableProducers.profile","text":"profile(n::NonDisRES)\nprofile(n::NonDisRES, t)\n\nReturns the profile of a node n of type NonDisRES either as TimeProfile or at operational period t.\n\n\n\n\n\n","category":"function"},{"location":"library/internals/methods-fields/#HydroStorage","page":"Methods - Accessing fields","title":"HydroStorage","text":"","category":"section"},{"location":"library/internals/methods-fields/","page":"Methods - Accessing fields","title":"Methods - Accessing fields","text":"EnergyModelsRenewableProducers.level_init\nEnergyModelsRenewableProducers.level_inflow\nEnergyModelsRenewableProducers.level_min","category":"page"},{"location":"library/internals/methods-fields/#EnergyModelsRenewableProducers.level_init","page":"Methods - Accessing fields","title":"EnergyModelsRenewableProducers.level_init","text":"level_init(n::HydroStorage)\nlevel_init(n::HydroStorage, t)\n\nReturns the initial level of a node n of type HydroStorage either as TimeProfile or at operational period t.\n\n\n\n\n\n","category":"function"},{"location":"library/internals/methods-fields/#EnergyModelsRenewableProducers.level_inflow","page":"Methods - Accessing fields","title":"EnergyModelsRenewableProducers.level_inflow","text":"level_inflow(n::HydroStorage)\nlevel_inflow(n::HydroStorage, t)\n\nReturns the inflow to a node n of type HydroStorage either as TimeProfile or at operational period t.\n\n\n\n\n\n","category":"function"},{"location":"library/internals/methods-fields/#EnergyModelsRenewableProducers.level_min","page":"Methods - Accessing fields","title":"EnergyModelsRenewableProducers.level_min","text":"level_min(n::HydroStorage)\nlevel_min(n::HydroStorage, t)\n\nReturns the minimum level of a node n of type HydroStorage either as TimeProfile or at operational period t.\n\n\n\n\n\n","category":"function"},{"location":"library/internals/methods-fields/#PumpedHydroStor","page":"Methods - Accessing fields","title":"PumpedHydroStor","text":"","category":"section"},{"location":"library/internals/methods-fields/","page":"Methods - Accessing fields","title":"Methods - Accessing fields","text":"EnergyModelsRenewableProducers.opex_var_pump","category":"page"},{"location":"library/internals/methods-fields/#EnergyModelsRenewableProducers.opex_var_pump","page":"Methods - Accessing fields","title":"EnergyModelsRenewableProducers.opex_var_pump","text":"opex_var_pump(n::PumpedHydroStor)\nopex_var_pump(n::PumpedHydroStor, t)\n\nReturns the variable OPEX of a node n of type PumpedHydroStor related to pumping either as TimeProfile or at operational period t.\n\n\n\n\n\n","category":"function"},{"location":"manual/NEWS/#Release-notes","page":"Release notes","title":"Release notes","text":"","category":"section"},{"location":"manual/NEWS/#Version-0.6.1-(2024-09-03)","page":"Release notes","title":"Version 0.6.1 (2024-09-03)","text":"","category":"section"},{"location":"manual/NEWS/","page":"Release notes","title":"Release notes","text":"Dependency increase for EnergyModelsBase as the changes do not directly affect EnergyModelsCO2.\nUpdated the documentation using the new structure released by EnergyModelsCO2.\nIncluded the package DocumenterInterLinks for crossreferences to EnergyModelsBase.\nUse dev version of EMRP for examples when running as part of tests, similar to PR #33 of EMB.","category":"page"},{"location":"manual/NEWS/#Version-0.6.0-(2024-05-28)","page":"Release notes","title":"Version 0.6.0 (2024-05-28)","text":"","category":"section"},{"location":"manual/NEWS/","page":"Release notes","title":"Release notes","text":"Adjusted to changes introduced in EnergyModelsBase v0.7.\nRemove legacy constructor for RegHydroStor and provide a warning for it.\nAdded constructors for HydroStor not requiring any longer specifying an input dictionary.","category":"page"},{"location":"manual/NEWS/#Version-0.5.6-(2024-05-09)","page":"Release notes","title":"Version 0.5.6 (2024-05-09)","text":"","category":"section"},{"location":"manual/NEWS/","page":"Release notes","title":"Release notes","text":"Provided a contribution section in the documentation.\nFixed a link in the documentation for the examples.","category":"page"},{"location":"manual/NEWS/#Version-0.5.5-(2024-03-21)","page":"Release notes","title":"Version 0.5.5 (2024-03-21)","text":"","category":"section"},{"location":"manual/NEWS/","page":"Release notes","title":"Release notes","text":"Minor changes to the checks to be consistent with EnergyModelsBase v0.6.7.","category":"page"},{"location":"manual/NEWS/#Version-0.5.4-(2024-03-04)","page":"Release notes","title":"Version 0.5.4 (2024-03-04)","text":"","category":"section"},{"location":"manual/NEWS/#Examples","page":"Release notes","title":"Examples","text":"","category":"section"},{"location":"manual/NEWS/","page":"Release notes","title":"Release notes","text":"Fixed a bug when running the examples from a non-cloned version of EnergyModelsRenewableProducers.\nThis was achieved through a separate Project.toml in the examples.","category":"page"},{"location":"manual/NEWS/#NonDIsRes-node","page":"Release notes","title":"NonDIsRes node","text":"","category":"section"},{"location":"manual/NEWS/","page":"Release notes","title":"Release notes","text":"Moved the capacity constraints through the profile to the function EMB.constraints_capacity(n::NonDisRES, ...), and hence, removed the function EMB.create_node(n::NonDisRES, ...).","category":"page"},{"location":"manual/NEWS/#Minor-updates","page":"Release notes","title":"Minor updates","text":"","category":"section"},{"location":"manual/NEWS/","page":"Release notes","title":"Release notes","text":"Added some checks and tests to the checks.\nRestructured the test folder.","category":"page"},{"location":"manual/NEWS/#Version-0.5.3-(2024-01-30)","page":"Release notes","title":"Version 0.5.3 (2024-01-30)","text":"","category":"section"},{"location":"manual/NEWS/","page":"Release notes","title":"Release notes","text":"Updated the restrictions on the fields of individual types to be consistent.\nAdded option to not include the field data for the individual introduced Nodes.","category":"page"},{"location":"manual/NEWS/#Version-0.5.2-(2024-01-19)","page":"Release notes","title":"Version 0.5.2 (2024-01-19)","text":"","category":"section"},{"location":"manual/NEWS/","page":"Release notes","title":"Release notes","text":"Updated the documenation to be in line with the updated done in EnergyModelsBsae.\nMoved RegHydroStor to a new file, legacy_constructors.jl to highlight that a user should use the new types, namely HydroStor and PumpedHydroStor.","category":"page"},{"location":"manual/NEWS/#Version-0.5.1-(2024-01-17)","page":"Release notes","title":"Version 0.5.1 (2024-01-17)","text":"","category":"section"},{"location":"manual/NEWS/","page":"Release notes","title":"Release notes","text":"Update the method constraints_level to match the signature updates for these methods in EnergyModelsBase. This includes renaming constraints_level to constraints_level_sp.\nMoved the function to EMB.constraints_level_sp to avoid problems.","category":"page"},{"location":"manual/NEWS/#Version-0.5.0-(2023-12-18)","page":"Release notes","title":"Version 0.5.0 (2023-12-18)","text":"","category":"section"},{"location":"manual/NEWS/#Adjustment-to-release-in-EMB-0.6.0","page":"Release notes","title":"Adjustment to release in EMB 0.6.0","text":"","category":"section"},{"location":"manual/NEWS/","page":"Release notes","title":"Release notes","text":"Adjusted the code for the new release.\nImplementation of support for RepresentativePeriods for HydroStorage nodes.","category":"page"},{"location":"manual/NEWS/#Version-0.4.2-(2023-09-01)","page":"Release notes","title":"Version 0.4.2 (2023-09-01)","text":"","category":"section"},{"location":"manual/NEWS/#Create-a-variable-:spill-for-hydro-storage-node","page":"Release notes","title":"Create a variable :spill for hydro storage node","text":"","category":"section"},{"location":"manual/NEWS/","page":"Release notes","title":"Release notes","text":"This variable enables hydro storage nodes to spill water from the reservoir without producing energy.","category":"page"},{"location":"manual/NEWS/#Version-0.4.1-(2023-08-31)","page":"Release notes","title":"Version 0.4.1 (2023-08-31)","text":"","category":"section"},{"location":"manual/NEWS/#Split-the-hydro-storage-node-into-to-separate-nodes","page":"Release notes","title":"Split the hydro storage node into to separate nodes","text":"","category":"section"},{"location":"manual/NEWS/","page":"Release notes","title":"Release notes","text":"Split RegHydroStor into to types PumpedHydroStor and HydroStor. Both are subtypes","category":"page"},{"location":"manual/NEWS/","page":"Release notes","title":"Release notes","text":"of the new abstract type HydroStorage <: EMB.Storage.","category":"page"},{"location":"manual/NEWS/","page":"Release notes","title":"Release notes","text":"Fix: variational OPEX for HydroStor now depends on flow_out instead of","category":"page"},{"location":"manual/NEWS/","page":"Release notes","title":"Release notes","text":"flow_in. The new type PumpedHydroStor has a separate parameter for variational OPEX for the pumps, which depends on flow_in.","category":"page"},{"location":"manual/NEWS/#Version-0.4.0-(2023-06-06)","page":"Release notes","title":"Version 0.4.0 (2023-06-06)","text":"","category":"section"},{"location":"manual/NEWS/#Switch-to-TimeStruct","page":"Release notes","title":"Switch to TimeStruct","text":"","category":"section"},{"location":"manual/NEWS/","page":"Release notes","title":"Release notes","text":"Switched the time structure representation to TimeStruct.\nTimeStruct is implemented with only the basis features that were available in TimeStructures. This implies that neither operational nor strategic uncertainty is included in the model.","category":"page"},{"location":"manual/NEWS/","page":"Release notes","title":"Release notes","text":"Version 0.3.0 (2023-05-30)","category":"page"},{"location":"manual/NEWS/","page":"Release notes","title":"Release notes","text":"Adjustment to changes in EnergyModelsBase v0.4.0 related to extra input data.","category":"page"},{"location":"manual/NEWS/#Version-0.2.2-(2023-05-15)","page":"Release notes","title":"Version 0.2.2 (2023-05-15)","text":"","category":"section"},{"location":"manual/NEWS/","page":"Release notes","title":"Release notes","text":"Adjustment to changes in EnergyModelsBase v 0.3.3 related to the calls for the constraint functions.","category":"page"},{"location":"manual/NEWS/#Version-0.2.1-(2023-02-03)","page":"Release notes","title":"Version 0.2.1 (2023-02-03)","text":"","category":"section"},{"location":"manual/NEWS/","page":"Release notes","title":"Release notes","text":"Take the examples out to the folder examples.","category":"page"},{"location":"manual/NEWS/#Version-0.2.0-(2023-02-03)","page":"Release notes","title":"Version 0.2.0 (2023-02-03)","text":"","category":"section"},{"location":"manual/NEWS/#Adjustmends-to-updates-in-EnergyModelsBase","page":"Release notes","title":"Adjustmends to updates in EnergyModelsBase","text":"","category":"section"},{"location":"manual/NEWS/","page":"Release notes","title":"Release notes","text":"Adjustment to version 0.3.0, namely:","category":"page"},{"location":"manual/NEWS/","page":"Release notes","title":"Release notes","text":"Changed type (Node) calls in tests to be consistent with version 0.3.0.\nRemoval of the type GlobalData and replacement with fields in the type OperationalModel in all tests.\nChanged type structure to be consistent with EMB version 0.3.0.\nSubstitution of certain constraints in create_node through functions which utilize dispatching on node types.\nChanged the input to the function variables_node.","category":"page"},{"location":"manual/NEWS/#Version-0.1.3-(2022-12-12)","page":"Release notes","title":"Version 0.1.3 (2022-12-12)","text":"","category":"section"},{"location":"manual/NEWS/#Internal-release","page":"Release notes","title":"Internal release","text":"","category":"section"},{"location":"manual/NEWS/","page":"Release notes","title":"Release notes","text":"Renamed to follow common prefix naming scheme.\nUpdate README.","category":"page"},{"location":"manual/NEWS/#Version-0.1.2-(2022-12-02)","page":"Release notes","title":"Version 0.1.2 (2022-12-02)","text":"","category":"section"},{"location":"manual/NEWS/","page":"Release notes","title":"Release notes","text":"Minor test fixes in preparation of internal release.","category":"page"},{"location":"manual/NEWS/#Version-0.1.1-(2021-09-07)","page":"Release notes","title":"Version 0.1.1 (2021-09-07)","text":"","category":"section"},{"location":"manual/NEWS/#Changes-in-naming","page":"Release notes","title":"Changes in naming","text":"","category":"section"},{"location":"manual/NEWS/","page":"Release notes","title":"Release notes","text":"Major changes in both variable and parameter naming, check the commit message for an overview.\nChange of structure in composite type \"RegHydroStor\".","category":"page"},{"location":"manual/NEWS/#Version-0.1.0-(2021-08-23)","page":"Release notes","title":"Version 0.1.0 (2021-08-23)","text":"","category":"section"},{"location":"manual/NEWS/","page":"Release notes","title":"Release notes","text":"Initial version with inclusion of nodes for:\nnondispatchable renewable energy sources (NonDisRES) and\nregulated hydro generation (RegHydroStor, can be used for pumped hydro storage).","category":"page"},{"location":"#EnergyModelsRenewableProducers","page":"Home","title":"EnergyModelsRenewableProducers","text":"","category":"section"},{"location":"","page":"Home","title":"Home","text":"This Julia package implements three new nodes with corresponding JuMP variables and constraints, extending the package EnergyModelsBase with more detailed representation of renewable energy sources.","category":"page"},{"location":"","page":"Home","title":"Home","text":"These nodes are","category":"page"},{"location":"","page":"Home","title":"Home","text":"a Source node NonDisRES,\na Storage node (HydroStor), and\na Storage node (PumpedHydroStor).","category":"page"},{"location":"","page":"Home","title":"Home","text":"The new introduced node types are also documented in the public library as well as the corresponding nodal page.","category":"page"},{"location":"#Developed-nodes","page":"Home","title":"Developed nodes","text":"","category":"section"},{"location":"#[NonDisRES](@ref)","page":"Home","title":"NonDisRES","text":"","category":"section"},{"location":"","page":"Home","title":"Home","text":"The first node models a non-dispatchable renewable energy source, like wind power, solar power, or run of river hydropower. These all use intermittent energy sources in the production of energy, so the maximum production capacity varies with the availability of the energy source at the time.","category":"page"},{"location":"#[HydroStor](@ref)-and-[PumpedHydroStor](@ref)","page":"Home","title":"HydroStor and PumpedHydroStor","text":"","category":"section"},{"location":"","page":"Home","title":"Home","text":"The other nodes implement a regulated hydropower storage plant, both with (PumpedHydroStor) and without pumps (HydroStor) for filling the reservoir with excess energy. The hydropower storage plant can also be extended as they are declared as subtypes of HydroStorage.","category":"page"},{"location":"#Manual-outline","page":"Home","title":"Manual outline","text":"","category":"section"},{"location":"","page":"Home","title":"Home","text":"Pages = [\n \"manual/quick-start.md\",\n \"manual/simple-example.md\",\n \"manual/NEWS.md\",\n]\nDepth = 1","category":"page"},{"location":"#Description-of-the-nodes","page":"Home","title":"Description of the nodes","text":"","category":"section"},{"location":"","page":"Home","title":"Home","text":"Pages = [\n \"nodes/nondisres.md\",\n \"nodes/hydropower.md\",\n]\nDepth = 1","category":"page"},{"location":"#How-to-guides","page":"Home","title":"How to guides","text":"","category":"section"},{"location":"","page":"Home","title":"Home","text":"Pages = [\n \"how-to/contribute.md\",\n \"how-to/update-models.md\",\n]\nDepth = 1","category":"page"},{"location":"#Library-outline","page":"Home","title":"Library outline","text":"","category":"section"},{"location":"","page":"Home","title":"Home","text":"Pages = [\n \"library/public.md\",\n \"library/internals/methods-fields.md\",\n \"library/internals/methods-EMB.md\",\n]\nDepth = 1","category":"page"},{"location":"nodes/nondisres/#nodes-nondisres","page":"Non-dispatchable RES","title":"Non-dispatchable renewable energy source node","text":"","category":"section"},{"location":"nodes/nondisres/","page":"Non-dispatchable RES","title":"Non-dispatchable RES","text":"Non-dispatchable renewable energy sources generate electricity from intermittent energy sources. Examples for intermittent energy sources are solar irradiation, the wind, or the flow within rivers. Although these energy sources have a constant nominal capacity, their production depends on intermittent energy sources. Although EnergyModelsX allows for capacities varying on the operational level, it is then not possible to include investments for a technology. Hence, the design of a RefSource is not satisfactory, when considering potential investments in capacities.=.","category":"page"},{"location":"nodes/nondisres/","page":"Non-dispatchable RES","title":"Non-dispatchable RES","text":"Hence, it is necessary to implement a source node representing intermittent renewable energy generation.","category":"page"},{"location":"nodes/nondisres/#nodes-nondisres-fields","page":"Non-dispatchable RES","title":"Introduced type and its field","text":"","category":"section"},{"location":"nodes/nondisres/","page":"Non-dispatchable RES","title":"Non-dispatchable RES","text":"The NonDisRES is implemented as equivalent to a RefSource. Hence, it utilizes the same functions declared in EnergyModelsBase.","category":"page"},{"location":"nodes/nondisres/#nodes-nondisres-fields-stand","page":"Non-dispatchable RES","title":"Standard fields","text":"","category":"section"},{"location":"nodes/nondisres/","page":"Non-dispatchable RES","title":"Non-dispatchable RES","text":"The standard fields are given as:","category":"page"},{"location":"nodes/nondisres/","page":"Non-dispatchable RES","title":"Non-dispatchable RES","text":"id:\nThe field id is only used for providing a name to the node. This is similar to the approach utilized in EnergyModelsBase.\ncap::TimeProfile:\nThe installed capacity corresponds to the nominal capacity of the node.\nIf 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.\nopex_var::TimeProfile:\nThe 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.\nopex_fixed::TimeProfile:\nThe 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.\nIt 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.\noutput::Dict{<:Resource, <:Real}:\nThe field output includes Resources with their corresponding conversion factors as dictionaries. In the case of a non-dispatchable renewable energy source, output should always include your electricity resource.In practice, you should use a value of 1.\nAll values have to be non-negative.\ndata::Vector{Data}:\nAn entry for providing additional data to the model. In the current version, it is only relevant for additional investment data when EnergyModelsInvestments is used.\nnote: Note\nThe field data is not required as we include a constructor when the value is excluded.","category":"page"},{"location":"nodes/nondisres/#nodes-nondisres-fields-new","page":"Non-dispatchable RES","title":"Additional fields","text":"","category":"section"},{"location":"nodes/nondisres/","page":"Non-dispatchable RES","title":"Non-dispatchable RES","text":"NonDisRES nodes add a single additional field compared to a RefSource:","category":"page"},{"location":"nodes/nondisres/","page":"Non-dispatchable RES","title":"Non-dispatchable RES","text":"profile::TimeProfile:\nThe profile is used as a multiplier to the installed capacity to represent the maximum actual capacity in each operational period.\nThe profile should be provided as OperationalProfile or at least as RepresentativeProfile. In addition, all values should be in the range 0 1.","category":"page"},{"location":"nodes/nondisres/","page":"Non-dispatchable RES","title":"Non-dispatchable RES","text":"This field is at the 3ʳᵈ position below the field cap as shown in NonDisRES.","category":"page"},{"location":"nodes/nondisres/#nodes-nondisres-math","page":"Non-dispatchable RES","title":"Mathematical description","text":"","category":"section"},{"location":"nodes/nondisres/","page":"Non-dispatchable RES","title":"Non-dispatchable RES","text":"In the following mathematical equations, we use the name for variables and functions used in the model. Variables are in general represented as","category":"page"},{"location":"nodes/nondisres/","page":"Non-dispatchable RES","title":"Non-dispatchable RES","text":"textttvar_exampleindex_1 index_2","category":"page"},{"location":"nodes/nondisres/","page":"Non-dispatchable RES","title":"Non-dispatchable RES","text":"with square brackets, while functions are represented as","category":"page"},{"location":"nodes/nondisres/","page":"Non-dispatchable RES","title":"Non-dispatchable RES","text":"func_example(index_1 index_2)","category":"page"},{"location":"nodes/nondisres/","page":"Non-dispatchable RES","title":"Non-dispatchable RES","text":"with paranthesis.","category":"page"},{"location":"nodes/nondisres/#nodes-nondisres-math-var","page":"Non-dispatchable RES","title":"Variables","text":"","category":"section"},{"location":"nodes/nondisres/#nodes-nondisres-math-var-stand","page":"Non-dispatchable RES","title":"Standard variables","text":"","category":"section"},{"location":"nodes/nondisres/","page":"Non-dispatchable RES","title":"Non-dispatchable RES","text":"The non-dispatchable renewable energy source node types utilize all standard variables from the RefSource node type, as described on the page Optimization variables. The variables include:","category":"page"},{"location":"nodes/nondisres/","page":"Non-dispatchable RES","title":"Non-dispatchable RES","text":"textttopex_var\ntextttopex_fixed\ntextttcap_use\ntextttcap_inst\ntextttflow_out\ntextttemissions_node if EmissionsData is added to the field data. Note that non-dispatchable renewable energy source nodes are not compatible with CaptureData. Hence, you can only provide EmissionsProcess to the node. It is our aim to include the potential for construction emissions in a latter stage","category":"page"},{"location":"nodes/nondisres/#nodes-nondisres-math-add","page":"Non-dispatchable RES","title":"Additional variables","text":"","category":"section"},{"location":"nodes/nondisres/","page":"Non-dispatchable RES","title":"Non-dispatchable RES","text":"NonDisRES nodes should keep track on the curtailment of the electricity, that is the unused capacity in each operational time period. Hence, a single additional variable is declared through dispatching on the method EnergyModelsBase.variables_node():","category":"page"},{"location":"nodes/nondisres/","page":"Non-dispatchable RES","title":"Non-dispatchable RES","text":"textttcurtailmentn t: Curtailed capacity of source n in operational period t with a typical unit of MW.\nThe curtailed electricity specifies the unused generation capacity of the non-dispatchable energy source. It is currently only used in the calculation, but not with a cost. This can be added by the user, if desired.","category":"page"},{"location":"nodes/nondisres/#nodes-nondisres-math-con","page":"Non-dispatchable RES","title":"Constraints","text":"","category":"section"},{"location":"nodes/nondisres/","page":"Non-dispatchable RES","title":"Non-dispatchable RES","text":"The following sections omit the direction inclusion of the vector of CO₂ source nodes. Instead, it is implicitly assumed that the constraints are valid forall n N^textNonDisRES_source for all NonDisRES 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).","category":"page"},{"location":"nodes/nondisres/#nodes-nondisres-math-con-stand","page":"Non-dispatchable RES","title":"Standard constraints","text":"","category":"section"},{"location":"nodes/nondisres/","page":"Non-dispatchable RES","title":"Non-dispatchable RES","text":"Non-dispatchable renewable energy source nodes utilize in general the standard constraints described on Constraint functions. In fact, they use the same create_node function as a RefSource node. These standard constraints are:","category":"page"},{"location":"nodes/nondisres/","page":"Non-dispatchable RES","title":"Non-dispatchable RES","text":"constraints_capacity_installed:\ntextttcap_instn t = capacity(n t)\nconstraints_flow_out:\ntextttflow_outn t p =\noutputs(n p) times textttcap_usen t\nqquad forall p in outputs(n) setminus textCO_2\nconstraints_opex_fixed:\ntextttopex_fixedn t_inv = opex_fixed(n t_inv) times textttcap_instn first(t_inv)\nconstraints_opex_var:\ntextttopex_varn t_inv = sum_t in t_inv opex_var(n t) times textttcap_usen t times EMBmultiple(t_inv t)\nconstraints_data:\nThis function is only called for specified data of the non-dispatchable renewable energy source, see above.","category":"page"},{"location":"nodes/nondisres/","page":"Non-dispatchable RES","title":"Non-dispatchable RES","text":"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.","category":"page"},{"location":"nodes/nondisres/","page":"Non-dispatchable RES","title":"Non-dispatchable RES","text":"The variable textttcap_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.","category":"page"},{"location":"nodes/nondisres/","page":"Non-dispatchable RES","title":"Non-dispatchable RES","text":"The function constraints_capacity is extended with a new method for non-dispatchable renewable energy source nodes to allow the inclusion of the production profile and the variable textttcurtailmentn t. It now includes two individual constraints:","category":"page"},{"location":"nodes/nondisres/","page":"Non-dispatchable RES","title":"Non-dispatchable RES","text":"textttcap_usen t leq textttcap_instn t","category":"page"},{"location":"nodes/nondisres/","page":"Non-dispatchable RES","title":"Non-dispatchable RES","text":"and","category":"page"},{"location":"nodes/nondisres/","page":"Non-dispatchable RES","title":"Non-dispatchable RES","text":"textttcap_usen t + textttcurtailmentn t =\nprofile(n t) times textttcap_instn t","category":"page"},{"location":"nodes/nondisres/","page":"Non-dispatchable RES","title":"Non-dispatchable RES","text":"This function still calls the subfunction constraints_capacity_installed to limit the variable textttcap_instn t or provide capacity investment options.","category":"page"},{"location":"nodes/nondisres/#nodes-nondisres-math-con-add","page":"Non-dispatchable RES","title":"Additional constraints","text":"","category":"section"},{"location":"nodes/nondisres/","page":"Non-dispatchable RES","title":"Non-dispatchable RES","text":"NonDisRES nodes do not add additional constraints.","category":"page"},{"location":"library/public/#lib-pub","page":"Public","title":"Public interface","text":"","category":"section"},{"location":"library/public/#lib-pub-module","page":"Public","title":"Module","text":"","category":"section"},{"location":"library/public/","page":"Public","title":"Public","text":"EnergyModelsRenewableProducers","category":"page"},{"location":"library/public/#EnergyModelsRenewableProducers","page":"Public","title":"EnergyModelsRenewableProducers","text":"Main module for EnergyModelsRenewableProducers.jl.\n\nThis module implements the following types (Nodes) with constraints:\n\nNonDisRes is a subtype of Source and represents a non-dispatchable renewable producer, as wind, solar etc.\nPumpedHydroStor is a subtype of Storage and represents a regulated pumped hydro storage.\nHydroStor is a subtype of Storage and represents a regulated hydro storage, that is a standard hydro powerplant without pumps.\n\n\n\n\n\n","category":"module"},{"location":"library/public/#lib-pub-node","page":"Public","title":"Node types","text":"","category":"section"},{"location":"library/public/#lib-pub-node-abstract","page":"Public","title":"Abstract types","text":"","category":"section"},{"location":"library/public/","page":"Public","title":"Public","text":"HydroStorage","category":"page"},{"location":"library/public/#EnergyModelsRenewableProducers.HydroStorage","page":"Public","title":"EnergyModelsRenewableProducers.HydroStorage","text":"An abstract type for hydro storage nodes, with or without pumping. \n\n\n\n\n\n","category":"type"},{"location":"library/public/#lib-pub-node-concrete","page":"Public","title":"Concrete types","text":"","category":"section"},{"location":"library/public/","page":"Public","title":"Public","text":"NonDisRES\nHydroStor\nPumpedHydroStor","category":"page"},{"location":"library/public/#EnergyModelsRenewableProducers.NonDisRES","page":"Public","title":"EnergyModelsRenewableProducers.NonDisRES","text":"NonDisRES <: EMB.Source\n\nA non-dispatchable renewable energy source. It extends the existing RefSource node through including a profile that corresponds to thr production. The profile can have variations on the strategic level.\n\nFields\n\nid is the name/identifyer of the node.\ncap::TimeProfile is the installed capacity.\nprofile::TimeProfile is the power production in each operational period as a ratio of the installed capacity at that time.\nopex_var::TimeProfile is the variable operating expense per energy unit produced.\nopex_fixed::TimeProfile is the fixed operating expense.\noutput::Dict{Resource, Real} are the generated Resources, normally Power.\ndata::Vector{Data} is the additional data (e.g. for investments). The field data is conditional through usage of a constructor.\n\n\n\n\n\n","category":"type"},{"location":"library/public/#EnergyModelsRenewableProducers.HydroStor","page":"Public","title":"EnergyModelsRenewableProducers.HydroStor","text":"HydroStor{T} <: HydroStorage{T}\n\nA regulated hydropower storage, modelled as a Storage node. A regulated hydro storage node requires a capacity for the discharge and does not have a required inflow from the model, except for water inflow from outside the model, although it requires a field input.\n\nFields\n\nid is the name/identifyer of the node.\nlevel::EMB.UnionCapacity are the level parameters of the HydroStor node. Depending on the chosen type, the charge parameters can include variable OPEX and/or fixed OPEX.\ndischarge::EMB.UnionCapacity are the discharging parameters of the HydroStor node. Depending on the chosen type, the discharge parameters can include variable OPEX, fixed OPEX, and/or a capacity.\nlevel_init::TimeProfile is the initial stored energy in the dam.\nlevel_inflow::TimeProfile is the inflow of power per operational period.\nlevel_min::TimeProfile is the minimum fraction of the reservoir capacity that has to remain in the HydroStorage node.\nstor_res::ResourceCarrier is the stored Resource.\ninput::Dict{Resource, Real} are the input Resources. In the case of a HydroStor, this field can be left out.\noutput::Dict{Resource, Real} can only contain one entry, the stored resource.\ndata::Vector{Data} additional data (e.g. for investments). The field data is conditional through usage of a constructor.\n\n\n\n\n\n","category":"type"},{"location":"library/public/#EnergyModelsRenewableProducers.PumpedHydroStor","page":"Public","title":"EnergyModelsRenewableProducers.PumpedHydroStor","text":"PumpedHydroStor{T} <: HydroStorage{T}\n\nA pumped hydropower storage, modelled as a Storage node. A pumped hydro storage node allows for storing energy through pumping water into the reservoir. The current implementation is a simplified node in which no lower reservoir is required. Instead, it is assumed that the reservoir has an infinite size.\n\nA pumped hydro storage node requires a capacity for both charge and discharge to account for the potential to store energy in the form of potential energy.\n\nFields\n\nid is the name/identifyer of the node.\ncharge::EMB.UnionCapacity are the charging parameters of the PumpedHydroStor node. Depending on the chosen type, the charge parameters can include variable OPEX, fixed OPEX, and/or a capacity.\nlevel::EMB.UnionCapacity are the level parameters of the HydroStor node. Depending on the chosen type, the charge parameters can include variable OPEX and/or fixed OPEX.\ndischarge::EMB.UnionCapacity are the discharging parameters of the HydroStor node. Depending on the chosen type, the discharge parameters can include variable OPEX, fixed OPEX, and/or a capacity.\nlevel_init::TimeProfile is the initial stored energy in the dam.\nlevel_inflow::TimeProfile is the inflow of power per operational period.\nlevel_min::TimeProfile is the minimum fraction of the reservoir capacity that has to remain in the HydroStorage node.\nstor_res::ResourceCarrier is the stored Resource.\ninput::Dict{Resource, Real} are the input Resources.\noutput::Dict{Resource, Real} can only contain one entry, the stored resource.\ndata::Vector{Data} additional data (e.g. for investments). The field data is conditional through usage of a constructor.\n\n\n\n\n\n","category":"type"},{"location":"library/public/#lib-pub-node-legacy","page":"Public","title":"Legacy constructors","text":"","category":"section"},{"location":"library/public/","page":"Public","title":"Public","text":"RegHydroStor","category":"page"},{"location":"library/public/#EnergyModelsRenewableProducers.RegHydroStor","page":"Public","title":"EnergyModelsRenewableProducers.RegHydroStor","text":"RegHydroStor(\n id::Any,\n rate_cap::TimeProfile,\n stor_cap::TimeProfile,\n has_pump::Bool,\n level_init::TimeProfile,\n level_inflow::TimeProfile,\n level_min::TimeProfile,\n opex_var::TimeProfile,\n opex_fixed::TimeProfile,\n stor_res::ResourceCarrier,\n input,\n output,\n Data,\n)\n\nOriginal Legacy constructor for a regulated hydropower storage, with or without pumping capabilities. This version is discontinued starting with Version 0.6.0. resulting in an error It is replaced with the two new types HydroStor and PumpedHydroStor to utilize the concept of multiple dispatch instead of logic.\n\nSee the documentation for further information regarding how you can translate your existing model to the new model.\n\nFields\n\nid is the name/identifyer of the node.\nrate_cap::TimeProfile is the installed installed rate capacity.\nstor_cap::TimeProfile is the installed storage capacity in the dam.\nhas_pump::Bool states wheter the stored resource can flow in.\nlevel_init::TimeProfile is the initial stored energy in the dam.\nlevel_inflow::TimeProfile is the inflow of power per operational period.\nlevel_min::TimeProfile is the minimum fraction of the reservoir capacity that has to remain in the HydroStorage node.\nopex_var::TimeProfile are the variable operational expenses per GWh produced.\nopex_fixed::TimeProfile are the fixed operational costs of the storage caacity.\nstor_res::ResourceCarrier is the stored Resource.\ninput::Dict{Resource, Real} are the stored and used resources. The values in the Dict are ratios describing the energy loss when using the pumps.\noutput::Dict{Resource, Real} can only contain one entry, the stored resource.\ndata::Array{Data} additional data (e.g. for investments). This value is conditional through the application of a constructor.\n\n\n\n\n\n","category":"function"}] +[{"location":"how-to/contribute/#how_to-con","page":"Contribute to EnergyModelsRenewableProducers","title":"Contribute to EnergyModelsRenewableProducers","text":"","category":"section"},{"location":"how-to/contribute/","page":"Contribute to EnergyModelsRenewableProducers","title":"Contribute to EnergyModelsRenewableProducers","text":"Contributing to EnergyModelsRenewableProducers can be achieved in several different ways.","category":"page"},{"location":"how-to/contribute/#how_to-con-bug_rep","page":"Contribute to EnergyModelsRenewableProducers","title":"File a bug report","text":"","category":"section"},{"location":"how-to/contribute/","page":"Contribute to EnergyModelsRenewableProducers","title":"Contribute to EnergyModelsRenewableProducers","text":"Another approach to contributing to EnergyModelsRenewableProducers is through filing a bug report as an issue when unexpected behaviour is occuring.","category":"page"},{"location":"how-to/contribute/","page":"Contribute to EnergyModelsRenewableProducers","title":"Contribute to EnergyModelsRenewableProducers","text":"When filing a bug report, please follow the following guidelines:","category":"page"},{"location":"how-to/contribute/","page":"Contribute to EnergyModelsRenewableProducers","title":"Contribute to EnergyModelsRenewableProducers","text":"Be certain that the bug is a bug and originating in EnergyModelsRenewableProducers:\nIf the problem is within the results of the optimization problem, please check first that the nodes are correctly linked with each other. Frequently, missing links (or wrongly defined links) restrict the transport of energy/mass. If you are certain that all links are set correctly, it is most likely a bug in EnergyModelsRenewableProducers and should be reported.\nIf the problem occurs in model construction, it is most likely a bug in either EnergyModelsBase or EnergyModelsRenewableProducers and should be reported in the respective package. The error message of Julia should provide you with the failing function and whether the failing function is located in EnergyModelsBase or EnergyModelsRenewableProducers. It can occur, that the last shown failing function is within JuMP or MathOptInterface. In this case, it is best to trace the error to the last called EnergyModelsBase or EnergyModelsRenewableProducers function.\nIf the problem is only appearing for specific solvers, it is most likely not a bug in EnergyModelsRenewableProducers, but instead a problem of the solver wrapper for MathOptInterface. In this case, please contact the developers of the corresponding solver wrapper.\nLabel the issue as bug, and\nProvide a minimum working example of a case in which the bug occurs.","category":"page"},{"location":"how-to/contribute/#how_to-con-feat_req","page":"Contribute to EnergyModelsRenewableProducers","title":"Feature requests","text":"","category":"section"},{"location":"how-to/contribute/","page":"Contribute to EnergyModelsRenewableProducers","title":"Contribute to EnergyModelsRenewableProducers","text":"EnergyModelsRenewableProducers includes several new nodal descriptions for renewable energy producers. However, there can be a demand for additional requirements for the existing nodes or for new descriptions which fall below the umbrella of renewable energy producers. In this case, you can contribute through a feature request.","category":"page"},{"location":"how-to/contribute/","page":"Contribute to EnergyModelsRenewableProducers","title":"Contribute to EnergyModelsRenewableProducers","text":"Feature requests for EnergyModelsRenewableProducers should follow the guidelines developed for EnergyModelsBase.","category":"page"},{"location":"how-to/contribute/","page":"Contribute to EnergyModelsRenewableProducers","title":"Contribute to EnergyModelsRenewableProducers","text":"note: Note\nEnergyModelsRenewableProducers is slightly different than EnergyModelsBase.Contrary to the other package, we consider that it is beneficial to have all potential features of renewable energy production within EnergyModelsRenewableProducers. Hence, if you have a requirement for a new nodal description, do not hesitate to create an issue.","category":"page"},{"location":"nodes/hydropower/#nodes-hydro_power","page":"Hydropower","title":"Hydro storage node","text":"","category":"section"},{"location":"nodes/hydropower/","page":"Hydropower","title":"Hydropower","text":"The reference storage node, RefStorage is quite flexible with respect to the individual storage behaviours, that is cyclic (both representative and strategic) or accumulating as it is included as parametric type using the individual storage behaviours. In addition, it allows for both charge and level different storage parameters. It is however not possible at the moment to provide a discharge capacity required in hydropower modelling. Furthermore, it is not possible to include an inflow to the storage node, except through artifically creating a source node representing the water flowing into the node.","category":"page"},{"location":"nodes/hydropower/","page":"Hydropower","title":"Hydropower","text":"Hence, it is necessary to include specific hydropower storage node","category":"page"},{"location":"nodes/hydropower/#nodes-hydro_power-fields","page":"Hydropower","title":"Introduced types and their fields","text":"","category":"section"},{"location":"nodes/hydropower/","page":"Hydropower","title":"Hydropower","text":"The HydroStorage abstract type is used to simplify the design of the constraints. It has in its current stage two concrete subtypes, HydroStor and PumpedHydroStor. Both types utilize the same main functionality, although PumpedHydroStor allows for utilizing electricity to store more water. The two nodes are designed to work with the cyclic storage behaviors.","category":"page"},{"location":"nodes/hydropower/","page":"Hydropower","title":"Hydropower","text":"warning: Input, output, and stored resource\nAlthough hydro reservoir store water, we have to assume in the current implementation that electricity is stored. The key reason for this is that we do not support in the modelling approach a conversion from the variable textttflow_in of a resource to a different stored resource.","category":"page"},{"location":"nodes/hydropower/#nodes-hydro_power-fields-stand","page":"Hydropower","title":"Standard fields","text":"","category":"section"},{"location":"nodes/hydropower/","page":"Hydropower","title":"Hydropower","text":"The standard fields are given as:","category":"page"},{"location":"nodes/hydropower/","page":"Hydropower","title":"Hydropower","text":"id:\nThe field id is only used for providing a name to the node. This is similar to the approach utilized in EnergyModelsBase.\ncharge::EMB.UnionCapacity:\nThe charge storage parameters must include a capacity for charging. More information can be found on storage parameters.\ninfo: Meaning in boths nodes\nThe charge field is only included for PumpedHydroStor nodes while HydroStor do not allow for flow into the node.\nlevel::EMB.UnionCapacity:\nThe level storage parameters must include a capacity for charging. More information can be found on storage parameters.\ncharge::EMB.UnionCapacity:\nThe charge storage parameters must include a capacity for charging. More information can be found on storage parameters.\nnote: Permitted values for storage parameters in `charge`, `level`, and `discharge`\nIf 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. Similarly, you can only use FixedProfile or StrategicProfile for the fixed OPEX, but not RepresentativeProfile or OperationalProfile. The variable operating expenses can be provided as OperationalProfile as well. In addition, all capacity and fixed OPEX values have to be non-negative.\nstor_res::ResourceEmit:\nThe stor_res is the stored Resource. The current implementation of HydroStorage nodes do not consider the conversion of potential energy of the stored water to electricity. Hence, you must specifiy your electricity resource.\ninput::Dict{<:Resource, <:Real} and output::Dict{<:Resource, <:Real}:\nBoth fields describe the input and output Resources with their corresponding conversion factors as dictionaries. The values correspond to charge and discharge efficiencies from the HydroStorage nodes.\nAll values have to be in the range 0 1.\ndata::Vector{Data}:\nAn entry for providing additional data to the model. In the current version, it is only relevant for additional investment data when EnergyModelsInvestments is used.","category":"page"},{"location":"nodes/hydropower/#nodes-hydro_power-fields-new","page":"Hydropower","title":"Additional fields","text":"","category":"section"},{"location":"nodes/hydropower/","page":"Hydropower","title":"Hydropower","text":"HydroStorage nodes add additional fields compared to RefStorage nodes. These fields are located below the field discharge, and hence, correspond to the 4ᵗʰ to 6ᵗʰ fields of the node. As a consequence, stor_res is now the 7ᵗʰ field compared to being the 4ᵗʰ in a RefStorage node.","category":"page"},{"location":"nodes/hydropower/","page":"Hydropower","title":"Hydropower","text":"The individual fields are related to specifics of hydropower. These fields are given as:","category":"page"},{"location":"nodes/hydropower/","page":"Hydropower","title":"Hydropower","text":"level_init::TimeProfile:\nThe initial level corresponds to the amount of electricity stored in the reservoir at the beginning of each strategic period. It can be provided as OperationalProfile. In practice, it is however sufficient to provide it as StrategicProfile as only a single value is used.\nThe initial levels have to be non-negative and less than the maximum storage capacity.\nlevel_inflow::TimeProfile:\nThe inflow is representing the potential electricity flowing into the reservoir in each operational period. It is depending on rivers flowing into the reservoir or rainfall. It can be provided as OperationalProfile.\nlevel_min::TimeProfile:\nThe minimum level provides a lower bound on the usage of the storage node in each operational period. This lower bound can be enforced by regulators to maintain a minimum amount of available stored electricity. The current implementation does not allow for a violation of the constraint, although this can be implemented in a latter stage. It can be provided as OperationalProfile.\nThe inflow has to be able in combination with the initial level to provide the required minimum level in the first operational period of each strategic period. In addition, all values have to be in the range 0 1.","category":"page"},{"location":"nodes/hydropower/#nodes-hydro_power-math","page":"Hydropower","title":"Mathematical description","text":"","category":"section"},{"location":"nodes/hydropower/","page":"Hydropower","title":"Hydropower","text":"In the following mathematical equations, we use the name for variables and functions used in the model. Variables are in general represented as","category":"page"},{"location":"nodes/hydropower/","page":"Hydropower","title":"Hydropower","text":"textttvar_exampleindex_1 index_2","category":"page"},{"location":"nodes/hydropower/","page":"Hydropower","title":"Hydropower","text":"with square brackets, while functions are represented as","category":"page"},{"location":"nodes/hydropower/","page":"Hydropower","title":"Hydropower","text":"func_example(index_1 index_2)","category":"page"},{"location":"nodes/hydropower/","page":"Hydropower","title":"Hydropower","text":"with paranthesis.","category":"page"},{"location":"nodes/hydropower/#nodes-hydro_power-math-var","page":"Hydropower","title":"Variables","text":"","category":"section"},{"location":"nodes/hydropower/#nodes-hydro_power-math-var-stand","page":"Hydropower","title":"Standard variables","text":"","category":"section"},{"location":"nodes/hydropower/","page":"Hydropower","title":"Hydropower","text":"The hydro power node types utilize all standard variables from RefStorage, as described on the page Optimization variables. The variables include:","category":"page"},{"location":"nodes/hydropower/","page":"Hydropower","title":"Hydropower","text":"textttopex_var\ntextttopex_fixed\ntextttstor_level\ntextttstor_level_inst\ntextttstor_charge_use\ntextttstor_charge_inst\ntextttstor_discharge_use\ntextttstor_discharge_inst\ntextttflow_in\ntextttflow_out\ntextttstor_level_Δ_op\ntextttstor_level_Δ_rp if the TimeStruct includes RepresentativePeriods","category":"page"},{"location":"nodes/hydropower/","page":"Hydropower","title":"Hydropower","text":"The variables textttflow_in and textttstor_charge_use are fixed to a value of 0 in the function constraints_flow_in for HydroStor nodes as these nodes correspond to regulated hydropower plants and not pumped hydropower plants..","category":"page"},{"location":"nodes/hydropower/#nodes-hydro_power-math-add","page":"Hydropower","title":"Additional variables","text":"","category":"section"},{"location":"nodes/hydropower/","page":"Hydropower","title":"Hydropower","text":"HydroStorage nodes must allow for spillage of surplus stored water. Hence, a single additional variable is declared through dispatching on the method EnergyModelsBase.variables_node():","category":"page"},{"location":"nodes/hydropower/","page":"Hydropower","title":"Hydropower","text":"texttthydro_spilln t: Spilled electricity in hydropower node n in operational period t with a typical unit of MW.\nThe spillage in each operational period is a rate specifying how much electricity is spilled, that is not routed the the grid, but instead directed from the turbines to avoid overfilling the reservoir. It hence allows for an overflow from a reservoir if the inflow to a reservoir exceeds its capacity and the outflow through power generation.","category":"page"},{"location":"nodes/hydropower/#nodes-hydro_power-math-con","page":"Hydropower","title":"Constraints","text":"","category":"section"},{"location":"nodes/hydropower/","page":"Hydropower","title":"Hydropower","text":"The following sections omit the direct inclusion of the vector of hydropower storage nodes. Instead, it is implicitly assumed that the constraints are valid forall n N for all HydroStor or PumpedHydroStor 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).","category":"page"},{"location":"nodes/hydropower/#nodes-hydro_power-math-con-stand","page":"Hydropower","title":"Standard constraints","text":"","category":"section"},{"location":"nodes/hydropower/","page":"Hydropower","title":"Hydropower","text":"Hydropower storages nodes utilize in general the standard constraints described on Constraint functions for RefStorage nodes.","category":"page"},{"location":"nodes/hydropower/","page":"Hydropower","title":"Hydropower","text":"warning: stor_charge_xxx\nThe constraints for textttstor_charge_use are only implemented for PumpedHydroStor nodes. This also includes the contribution to the variables textttopex_fixed and textttopex_var.","category":"page"},{"location":"nodes/hydropower/","page":"Hydropower","title":"Hydropower","text":"These standard constraints are:","category":"page"},{"location":"nodes/hydropower/","page":"Hydropower","title":"Hydropower","text":"constraints_capacity:\nbeginaligned\ntextttstor_level_instn t geq textttstor_leveln t \ntextttstor_charge_instn t geq textttstor_charge_usen t \ntextttstor_discharge_instn t geq textttstor_discharge_usen t \nendaligned\nconstraints_capacity_installed:\nbeginaligned\ntextttstor_level_instn t = capacity(level(n) t) \ntextttstor_charge_instn t = capacity(charge(n) t) \ntextttstor_discharge_instn t = capacity(charge(n) t)\nendaligned\ntip: Using investments\nThe 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.\nconstraints_level: The level constraints are in general following the default approach with minor modifications. They are explained in detail below in Level constraints.\nconstraints_opex_fixed:\nbeginaligned\ntextttopex_fixedn t_inv = \n opex_fixed(level(n) t_inv) times textttstor_level_instn first(t_inv) + \n opex_fixed(charge(n) t_inv) times textttstor_charge_instn first(t_inv) + \n opex_fixed(discharge(n) t_inv) times textttstor_discharge_instn first(t_inv)\nendaligned\ntip: Why do we use `first()`\nThe variables textttstor_level_inst are 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 capacities in the first operational period of a given strategic period t_inv in the function constraints_opex_fixed.\nconstraints_opex_var:\nbeginaligned\ntextttopex_varn t_inv = sum_t in t_inv\n opex_var(level(n) t) times textttstor_leveln t times scale_op_sp(t_inv t) + \n opex_var(charge(n) t) times textttstor_charge_usen t times scale_op_sp(t_inv t) + \n opex_var(discharge(n) t) times textttstor_discharge_usen t times scale_op_sp(t_inv t)\nendaligned\ntip: The function `scale_op_sp`\nThe 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.\nconstraints_data:\nThis function is only called for specified data of the CO₂ storage node, see above.","category":"page"},{"location":"nodes/hydropower/","page":"Hydropower","title":"Hydropower","text":"info: Implementation of OPEX\nThe fixed and variable OPEX constribubtion for the level and the charge capacities are only included if the corresponding storage parameters have a field opex_fixed and opex_var, respectively. Otherwise, they are omitted.","category":"page"},{"location":"nodes/hydropower/","page":"Hydropower","title":"Hydropower","text":"The function constraints_flow_in is extended with a new method for hydropower nodes to differentiate whether the node is a pumped hydropower node or not. The standard constraints given by","category":"page"},{"location":"nodes/hydropower/","page":"Hydropower","title":"Hydropower","text":"beginaligned\ntextttstor_level_instn t geq textttstor_leveln t \ntextttstor_charge_instn t geq textttstor_charge_usen t \nendaligned","category":"page"},{"location":"nodes/hydropower/","page":"Hydropower","title":"Hydropower","text":"are extended with a constraint for PumpedHydroStor nodes given by","category":"page"},{"location":"nodes/hydropower/","page":"Hydropower","title":"Hydropower","text":"textttflow_inn t p times inputs(n p) =\ntextttstor_charge_usen t qquad forall p in inputs(n)","category":"page"},{"location":"nodes/hydropower/","page":"Hydropower","title":"Hydropower","text":"while the variables textttflow_in and textttstor_charge_use are fixed to a value of 0 for HydroStor nodes.","category":"page"},{"location":"nodes/hydropower/","page":"Hydropower","title":"Hydropower","text":"These constraints allow either to include an efficiency for filling the reservoir (PumpedHydroStor) or avoiding unconstrained variables (HydroStor).","category":"page"},{"location":"nodes/hydropower/#nodes-hydro_power-math-con-add","page":"Hydropower","title":"Additional constraints","text":"","category":"section"},{"location":"nodes/hydropower/#nodes-hydro_power-math-con-add-node","page":"Hydropower","title":"Constraints calculated in create_node","text":"","category":"section"},{"location":"nodes/hydropower/","page":"Hydropower","title":"Hydropower","text":"The outlet flow constraints are given as","category":"page"},{"location":"nodes/hydropower/","page":"Hydropower","title":"Hydropower","text":"textttflow_outn t p =\ntextttstor_charge_usen t times outputs(n p) qquad forall p in outputs(n)","category":"page"},{"location":"nodes/hydropower/","page":"Hydropower","title":"Hydropower","text":"As a consequence, similar to the inlet flow constraint, we can specify an efficiency between 0 and 1 to account for loses in the turbine.","category":"page"},{"location":"nodes/hydropower/","page":"Hydropower","title":"Hydropower","text":"In addition a constraint on the maximum discharge given by","category":"page"},{"location":"nodes/hydropower/","page":"Hydropower","title":"Hydropower","text":"textttstor_discharge_usen t leq textttstor_leveln t","category":"page"},{"location":"nodes/hydropower/","page":"Hydropower","title":"Hydropower","text":"is included to constrain the discharge further. This constraint is in practice not active as the storage level is bound at a lower bound provided through the field level_min.","category":"page"},{"location":"nodes/hydropower/#nodes-hydro_power-math-con-add-level","page":"Hydropower","title":"Level constraints","text":"","category":"section"},{"location":"nodes/hydropower/","page":"Hydropower","title":"Hydropower","text":"The level constraints are in general slightly more complex to understand. The overall structure is outlined on Constraint functions. The level constraints are called through the function constraints_level which then calls additional functions depending on the chosen time structure (whether it includes representative periods and/or operational scenarios) and the chosen storage behaviour.","category":"page"},{"location":"nodes/hydropower/","page":"Hydropower","title":"Hydropower","text":"The hydro power nodes utilize the majority of the concepts from EnergyModelsBase but require adjustments for both constraining the variable textttstor_level_Δ_op and specifying how the storage node has to behave in the first operational period of a strategic period. This is achieved through dispatching on the functions constraints_level_aux.","category":"page"},{"location":"nodes/hydropower/","page":"Hydropower","title":"Hydropower","text":"The constraints introduced in constraints_level_aux can be divided in three groups:","category":"page"},{"location":"nodes/hydropower/","page":"Hydropower","title":"Hydropower","text":"the energy balance,\nbeginaligned\n textttstor_level_Δ_opn t = \n level_inflow(n t) + textttstor_charge_usen t - \n textttstor_discharge_usen t - texttthydro_spilln t\nendaligned\nthe initial storage level in the first operational period of a strategic period, and\nbeginaligned\n textttstor_level n first(t_inv) = \n level_init(n first(t_inv)) + \n textttstor_level_Δ_opn first(t_inv) times duration(first(t_inv))\nendaligned\nthe minimum level constraint\ntextttstor_leveln t geq level_min(n t) times textttstor_level_instn t","category":"page"},{"location":"nodes/hydropower/","page":"Hydropower","title":"Hydropower","text":"corresponding to the change in the storage level in an operational period and strategic period, respectively.","category":"page"},{"location":"nodes/hydropower/","page":"Hydropower","title":"Hydropower","text":"If the time structure includes representative periods, we also calculate the change of the storage level in each representative period within the function constraints_level_iterate (from EnergyModelsBase):","category":"page"},{"location":"nodes/hydropower/","page":"Hydropower","title":"Hydropower","text":" textttstor_level_Δ_rpn t_rp = sum_t in t_rp\n textttstor_level_Δ_opn t times scale_op_sp(t_inv t)","category":"page"},{"location":"nodes/hydropower/","page":"Hydropower","title":"Hydropower","text":"The general level constraint is calculated in the function constraints_level_iterate (from EnergyModelsBase):","category":"page"},{"location":"nodes/hydropower/","page":"Hydropower","title":"Hydropower","text":"textttstor_leveln t = prev_level +\ntextttstor_level_Δ_opn t times duration(t)","category":"page"},{"location":"nodes/hydropower/","page":"Hydropower","title":"Hydropower","text":"in which the value prev_level is depending on the type of the previous operational (t_prev) and strategic level (t_invprev) (as well as the previous representative period (t_rpprev)). It is calculated through the function previous_level.","category":"page"},{"location":"nodes/hydropower/","page":"Hydropower","title":"Hydropower","text":"In the case of hydropower node, we can distinguish the following cases:","category":"page"},{"location":"nodes/hydropower/","page":"Hydropower","title":"Hydropower","text":"The first operational period in the first representative period in any strategic period (given by typeof(t_prev) = typeof(t_rp prev) and typeof(t_invprev) = NothingPeriod). In this situation, we can distinguish three cases, the time structure does not include representative periods:\nprev_level = textttstor_leveln last(t_inv)\nthe time structure includes representative periods and the storage behavior is given as CyclicRepresentative:\nprev_level = textttstor_leveln last(t_rp)\nthe time structure includes representative periods and the storage behavior is given as CyclicStrategic:\nbeginaligned\n prev_level = textttstor_leveln first(t_rplast) - \n textttstor_level_Δ_opn first(t_rplast) times duration(first(t_rplast)) + \n textttstor_level_Δ_rpn t_rplast times duration_strat(t_rplast)\nendaligned\nThe first operational period in subsequent representative periods in any strategic period (given by typeof(t_prev) = nothing) f the the storage behavior is given as CyclicStrategic:\n\nbeginaligned\n prev_level = textttstor_leveln first(t_rpprev) - \n textttstor_level_Δ_opn first(t_rpprev) times duration(first(t_rpprev)) + \n textttstor_level_Δ_rpn t_rpprev\nendaligned\nThis situation only occurs in cases in which the time structure includes representative periods.\nAll other operational periods:\n\n prev_level = textttstor_leveln t_prev","category":"page"},{"location":"nodes/hydropower/","page":"Hydropower","title":"Hydropower","text":"All cases are implemented in EnergyModelsBase simplifying the design of the system.","category":"page"},{"location":"manual/simple-example/#man-exampl","page":"Examples","title":"Examples","text":"","category":"section"},{"location":"manual/simple-example/","page":"Examples","title":"Examples","text":"For the content of the example, see the examples directory in the project repository.","category":"page"},{"location":"manual/simple-example/#The-package-is-installed-with-]-add","page":"Examples","title":"The package is installed with ] add","text":"","category":"section"},{"location":"manual/simple-example/","page":"Examples","title":"Examples","text":"From the Julia REPL, run","category":"page"},{"location":"manual/simple-example/","page":"Examples","title":"Examples","text":"# Starts the Julia REPL\njulia> using EnergyModelsRenewableProducers\n# Get the path of the examples directory\njulia> exdir = joinpath(pkgdir(EnergyModelsRenewableProducers), \"examples\")\n# Include the code into the Julia REPL to run the first example of the NonDisRes node\njulia> include(joinpath(exdir, \"simple_nondisres.jl\"))\n# Include the code into the Julia REPL to run the first example of the Hydropower node\njulia> include(joinpath(exdir, \"simple_hydro_power.jl\"))","category":"page"},{"location":"manual/simple-example/#The-code-was-downloaded-with-git-clone","page":"Examples","title":"The code was downloaded with git clone","text":"","category":"section"},{"location":"manual/simple-example/","page":"Examples","title":"Examples","text":"The examples can then be run from the terminal with","category":"page"},{"location":"manual/simple-example/","page":"Examples","title":"Examples","text":"/path/to/EnergyModelsRenewableProducers.jl/examples $ julia simple_nondisres.jl\n/path/to/EnergyModelsRenewableProducers.jl/examples $ julia simple_hydro_power.jl","category":"page"},{"location":"manual/quick-start/#quick_start","page":"Quick Start","title":"Quick Start","text":"","category":"section"},{"location":"manual/quick-start/","page":"Quick Start","title":"Quick Start","text":"Install the most recent version of Julia\nInstall the package EnergyModelsBase and the time package TimeStruct, by running:\n] add TimeStruct\n] add EnergyModelsBase\nThese packages are required as we do not only use them internally, but also for building a model.\nInstall the package EnergyModelsRenewableProducers\n] add EnergyModelsRenewableProducers","category":"page"},{"location":"library/internals/methods-EMB/#Methods-EnergyModelsBase","page":"Methods - EnergyModelsBase","title":"Methods - EnergyModelsBase","text":"","category":"section"},{"location":"library/internals/methods-EMB/#Index","page":"Methods - EnergyModelsBase","title":"Index","text":"","category":"section"},{"location":"library/internals/methods-EMB/","page":"Methods - EnergyModelsBase","title":"Methods - EnergyModelsBase","text":"Pages = [\"methods-EMB.md\"]","category":"page"},{"location":"library/internals/methods-EMB/#Extension-methods","page":"Methods - EnergyModelsBase","title":"Extension methods","text":"","category":"section"},{"location":"library/internals/methods-EMB/","page":"Methods - EnergyModelsBase","title":"Methods - EnergyModelsBase","text":"EnergyModelsBase.variables_node\nEnergyModelsBase.create_node","category":"page"},{"location":"library/internals/methods-EMB/#EnergyModelsBase.variables_node","page":"Methods - EnergyModelsBase","title":"EnergyModelsBase.variables_node","text":"EMB.variables_node(m, 𝒩ⁿᵈʳ::Vector{NonDisRES}, 𝒯, modeltype::EnergyModel)\n\nCreate the optimization variable :curtailment for every NonDisRES node. This method is called from EnergyModelsBase.jl.\n\n\n\n\n\nEMB.variables_node(m, 𝒩::Vector{<:HydroStorage}, 𝒯, modeltype::EnergyModel)\n\nCreate the optimization variable :hydro_spill for every HydroStorage node. This variable enables hydro storage nodes to spill water from the reservoir without producing energy. Wihtout this slack variable, parameters with too much inflow would else lead to an infeasible model. \n\n\n\n\n\n","category":"function"},{"location":"library/internals/methods-EMB/#EnergyModelsBase.create_node","page":"Methods - EnergyModelsBase","title":"EnergyModelsBase.create_node","text":"EMB.create_node(m, n::HydroStorage, 𝒯, 𝒫, modeltype::EnergyModel)\n\nSets all constraints for the regulated hydro storage node.\n\n\n\n\n\n","category":"function"},{"location":"library/internals/methods-EMB/#Constraint-methods","page":"Methods - EnergyModelsBase","title":"Constraint methods","text":"","category":"section"},{"location":"library/internals/methods-EMB/","page":"Methods - EnergyModelsBase","title":"Methods - EnergyModelsBase","text":"EnergyModelsBase.constraints_capacity\nEnergyModelsBase.constraints_flow_in\nEnergyModelsBase.constraints_level_aux","category":"page"},{"location":"library/internals/methods-EMB/#EnergyModelsBase.constraints_capacity","page":"Methods - EnergyModelsBase","title":"EnergyModelsBase.constraints_capacity","text":"constraints_capacity(m, n::NonDisRES, 𝒯::TimeStructure, modeltype::EnergyModel)\n\nFunction for creating the constraint on the maximum capacity of a NonDisRES. Also sets the constraint defining curtailment.\n\n\n\n\n\n","category":"function"},{"location":"library/internals/methods-EMB/#EnergyModelsBase.constraints_flow_in","page":"Methods - EnergyModelsBase","title":"EnergyModelsBase.constraints_flow_in","text":"constraints_flow_in(m, n::HydroStor, 𝒯::TimeStructure, modeltype::EnergyModel)\n\nWhen n::HydroStor, the variable :flow_in is fixed to 0 for all potential inputs.\n\n\n\n\n\nconstraints_flow_in(m, n::PumpedHydroStor, 𝒯::TimeStructure, modeltype::EnergyModel)\n\nWhen n::PumpedHydroStor, the variable :flow_in is multiplied with the inputs value to calculate the variable :stor_charge_use.\n\n\n\n\n\n","category":"function"},{"location":"library/internals/methods-EMB/#EnergyModelsBase.constraints_level_aux","page":"Methods - EnergyModelsBase","title":"EnergyModelsBase.constraints_level_aux","text":"EMB.constraints_level_aux(m, n::HydroStorage, 𝒯, 𝒫, modeltype)\n\nFunction for creating the Δ constraint for the level of a HydroStorage node as well as the specification of the initial level in a strategic period.\n\nThe change in storage level in the reservoir at operational periods t is the inflow through :level_inflow plus the input :stor_charge_use minus the production :stor_discharge_use and the spillage of water due to overflow :hydro_spill.\n\n\n\n\n\n","category":"function"},{"location":"library/internals/methods-EMB/#Check-methods","page":"Methods - EnergyModelsBase","title":"Check methods","text":"","category":"section"},{"location":"library/internals/methods-EMB/","page":"Methods - EnergyModelsBase","title":"Methods - EnergyModelsBase","text":"EnergyModelsBase.check_node","category":"page"},{"location":"library/internals/methods-EMB/#EnergyModelsBase.check_node","page":"Methods - EnergyModelsBase","title":"EnergyModelsBase.check_node","text":"EMB.check_node(n::NonDisRES, 𝒯, modeltype::EMB.EnergyModel, check_timeprofiles::Bool)\n\nThis method checks that the NonDisRES node is valid.\n\nChecks\n\nThe field cap is required to be non-negative (similar to the Source check).\nThe value of the field fixed_opex is required to be non-negative and accessible through a StrategicPeriod as outlined in the function check_fixed_opex(n, 𝒯ᴵⁿᵛ, check_timeprofiles).\nThe values of the dictionary output are required to be non-negative (similar to the Source check).\nThe field profile is required to be in the range 0 1 for all time steps t mathcalT.\n\n\n\n\n\nEMB.check_node(n::HydroStorage, 𝒯, modeltype::EMB.EnergyModel, check_timeprofiles::Bool)\n\nThis method checks that the HydroStorage node is valid.\n\nChecks\n\nThe TimeProfile of the field capacity in the type in the field charge is required to be non-negative if the chosen composite type has the field capacity.\nThe TimeProfile of the field capacity in the type in the field level is required to be non-negative`.\nThe TimeProfile of the field capacity in the type in the field discharge is required to be non-negative if the chosen composite type has the field capacity.\nThe TimeProfile of the field fixed_opex is required to be non-negative and accessible through a StrategicPeriod as outlined in the function check_fixed_opex(n, 𝒯ᴵⁿᵛ, check_timeprofiles) for the chosen composite type .\nThe field output can only include a single Resource.\nThe value of the field output is required to be smaller or equal to 1.\nThe value of the field input is required to be in the range 0 1.\nThe value of the field level_init is required to be in the range level_min 1 cdot stor_cap(t) for all time steps t mathcalT.\nThe value of the field level_init is required to be in the range 0 1.\nThe value of the field level_min is required to be in the range 0 1.\n\n\n\n\n\n","category":"function"},{"location":"how-to/update-models/#update-models","page":"Update models","title":"Update your model to the latest versions","text":"","category":"section"},{"location":"how-to/update-models/","page":"Update models","title":"Update models","text":"EnergyModelsRenewableProducers is still in a pre-release version. Hence, there are frequently breaking changes occuring, although we plan to keep backwards compatibility. This document is designed to provide users with information regarding how they have to adjust their models to keep compatibility to the latest changes. We will as well implement information regarding the adjustment of extension packages, although this is more difficult due to the vast majority of potential changes.","category":"page"},{"location":"how-to/update-models/#Adjustments-from-0.4.2","page":"Update models","title":"Adjustments from 0.4.2","text":"","category":"section"},{"location":"how-to/update-models/#Key-changes-for-nodal-descriptions","page":"Update models","title":"Key changes for nodal descriptions","text":"","category":"section"},{"location":"how-to/update-models/","page":"Update models","title":"Update models","text":"Version 0.7 of EnergyModelsBase introduced both storage behaviours resulting in a rework of the individual approach for calculating the level balance as well as the potential to have charge and discharge capacities through storage parameters.","category":"page"},{"location":"how-to/update-models/","page":"Update models","title":"Update models","text":"note: Note\nThe legacy constructors for calls of the composite type of version 0.5 will be included at least until version 0.7.","category":"page"},{"location":"how-to/update-models/#[HydroStor](@ref)","page":"Update models","title":"HydroStor","text":"","category":"section"},{"location":"how-to/update-models/","page":"Update models","title":"Update models","text":"HydroStor was significantly reworked due to the changes in EnergyModelsBase The total rework is provided below.","category":"page"},{"location":"how-to/update-models/","page":"Update models","title":"Update models","text":"# The previous nodal description for a `HydroStor` node was given by:\nHydroStor(\n id,\n rate_cap::TimeProfile,\n stor_cap::TimeProfile,\n\n level_init::TimeProfile,\n level_inflow::TimeProfile,\n level_min::TimeProfile,\n\n opex_var::TimeProfile,\n opex_fixed::TimeProfile,\n stor_res::ResourceCarrier,\n input::Dict{<:Resource, <:Real},\n output::Dict{<:Resource, <:Real},\n data::Vector{Data},\n)\n\n# This translates to the following new version\nHydroStor{CyclicStrategic}(\n id,\n StorCapOpexFixed(stor_cap, opex_fixed),\n StorCapOpexVar(rate_cap, opex_var),\n level_init,\n level_inflow,\n level_min,\n stor_res,\n input,\n output,\n data,\n)","category":"page"},{"location":"how-to/update-models/#[PumpedHydroStor](@ref)","page":"Update models","title":"PumpedHydroStor","text":"","category":"section"},{"location":"how-to/update-models/","page":"Update models","title":"Update models","text":"PumpedHydroStor was significantly reworked due to the changers in EnergyModelsBase The total rework is provided below.","category":"page"},{"location":"how-to/update-models/","page":"Update models","title":"Update models","text":"# The previous nodal description for a `PumpedHydroStor` node was given by:\nPumpedHydroStor(\n id,\n rate_cap::TimeProfile,\n stor_cap::TimeProfile,\n\n level_init::TimeProfile,\n level_inflow::TimeProfile,\n level_min::TimeProfile,\n\n opex_var::TimeProfile,\n opex_var_pump::TimeProfile,\n opex_fixed::TimeProfile,\n stor_res::ResourceCarrier,\n input::Dict{<:Resource, <:Real},\n output::Dict{<:Resource, <:Real},\n data::Vector{Data},\n)\n\n# This translates to the following new version\nPumpedHydroStor{CyclicStrategic}(\n id,\n StorCapOpexVar(rate_cap, opex_var_pump),\n StorCapOpexFixed(stor_cap, opex_fixed),\n StorCapOpexVar(rate_cap, opex_var),\n level_init,\n level_inflow,\n level_min,\n stor_res,\n input,\n output,\n data,\n)","category":"page"},{"location":"how-to/update-models/#Adjustments-from-0.4.0-to-0.6.x","page":"Update models","title":"Adjustments from 0.4.0 to 0.6.x","text":"","category":"section"},{"location":"how-to/update-models/#Key-changes-for-nodal-descriptions-2","page":"Update models","title":"Key changes for nodal descriptions","text":"","category":"section"},{"location":"how-to/update-models/","page":"Update models","title":"Update models","text":"Version 0.4.1 introduced two new types that replaced the original RegHydroStor node with two types called PumpedHydroStor and HydroStor. The changes allowed for the introduction of a variable OPEX for pumping. In the translation below, it is assumed that the variable OPEX for pumping is 0.","category":"page"},{"location":"how-to/update-models/","page":"Update models","title":"Update models","text":"# The previous nodal description was given by:\nRegHydroStor(\n id::Any,\n rate_cap::TimeProfile,\n stor_cap::TimeProfile,\n has_pump::Bool,\n level_init::TimeProfile,\n level_inflow::TimeProfile,\n level_min::TimeProfile,\n opex_var::TimeProfile,\n opex_fixed::TimeProfile,\n stor_res::ResourceCarrier,\n input,\n output,\n Data,\n)\n\n# This translates to the following new version if has_pump == true\nPumpedHydroStor(\n id,\n StorCapOpexVar(rate_cap, FixedProfile(0)),\n StorCapOpexFixed(stor_cap, opex_fixed),\n StorCapOpexVar(rate_cap, opex_var),\n level_init,\n level_inflow,\n level_min,\n stor_res,\n input,\n output,\n Data,\n)\n# and the following version if has_pump == false\nHydroStor(\n id,\n StorCapOpexFixed(stor_cap, opex_fixed),\n StorCapOpexVar(rate_cap, opex_var),\n level_init,\n level_inflow,\n level_min,\n stor_res,\n input,\n output,\n Data,\n)","category":"page"},{"location":"library/internals/methods-fields/#Methods-Accessing-fields","page":"Methods - Accessing fields","title":"Methods - Accessing fields","text":"","category":"section"},{"location":"library/internals/methods-fields/#Index","page":"Methods - Accessing fields","title":"Index","text":"","category":"section"},{"location":"library/internals/methods-fields/","page":"Methods - Accessing fields","title":"Methods - Accessing fields","text":"Pages = [\"methods-fields.md\"]","category":"page"},{"location":"library/internals/methods-fields/#NonDisRES","page":"Methods - Accessing fields","title":"NonDisRES","text":"","category":"section"},{"location":"library/internals/methods-fields/","page":"Methods - Accessing fields","title":"Methods - Accessing fields","text":"EnergyModelsRenewableProducers.profile","category":"page"},{"location":"library/internals/methods-fields/#EnergyModelsRenewableProducers.profile","page":"Methods - Accessing fields","title":"EnergyModelsRenewableProducers.profile","text":"profile(n::NonDisRES)\nprofile(n::NonDisRES, t)\n\nReturns the profile of a node n of type NonDisRES either as TimeProfile or in operational period t.\n\n\n\n\n\n","category":"function"},{"location":"library/internals/methods-fields/#HydroStorage","page":"Methods - Accessing fields","title":"HydroStorage","text":"","category":"section"},{"location":"library/internals/methods-fields/","page":"Methods - Accessing fields","title":"Methods - Accessing fields","text":"EnergyModelsRenewableProducers.level_init\nEnergyModelsRenewableProducers.level_inflow\nEnergyModelsRenewableProducers.level_min","category":"page"},{"location":"library/internals/methods-fields/#EnergyModelsRenewableProducers.level_init","page":"Methods - Accessing fields","title":"EnergyModelsRenewableProducers.level_init","text":"level_init(n::HydroStorage)\nlevel_init(n::HydroStorage, t)\n\nReturns the initial level of a node n of type HydroStorage either as TimeProfile or in operational period t.\n\n\n\n\n\n","category":"function"},{"location":"library/internals/methods-fields/#EnergyModelsRenewableProducers.level_inflow","page":"Methods - Accessing fields","title":"EnergyModelsRenewableProducers.level_inflow","text":"level_inflow(n::HydroStorage)\nlevel_inflow(n::HydroStorage, t)\n\nReturns the inflow to a node n of type HydroStorage either as TimeProfile or in operational period t.\n\n\n\n\n\n","category":"function"},{"location":"library/internals/methods-fields/#EnergyModelsRenewableProducers.level_min","page":"Methods - Accessing fields","title":"EnergyModelsRenewableProducers.level_min","text":"level_min(n::HydroStorage)\nlevel_min(n::HydroStorage, t)\n\nReturns the minimum level of a node n of type HydroStorage either as TimeProfile or in operational period t.\n\n\n\n\n\n","category":"function"},{"location":"library/internals/methods-fields/#PumpedHydroStor","page":"Methods - Accessing fields","title":"PumpedHydroStor","text":"","category":"section"},{"location":"library/internals/methods-fields/","page":"Methods - Accessing fields","title":"Methods - Accessing fields","text":"EnergyModelsRenewableProducers.opex_var_pump","category":"page"},{"location":"library/internals/methods-fields/#EnergyModelsRenewableProducers.opex_var_pump","page":"Methods - Accessing fields","title":"EnergyModelsRenewableProducers.opex_var_pump","text":"opex_var_pump(n::PumpedHydroStor)\nopex_var_pump(n::PumpedHydroStor, t)\n\nReturns the variable OPEX of a node n of type PumpedHydroStor related to pumping either as TimeProfile or in operational period t.\n\n\n\n\n\n","category":"function"},{"location":"manual/NEWS/#Release-notes","page":"Release notes","title":"Release notes","text":"","category":"section"},{"location":"manual/NEWS/#Unversioned","page":"Release notes","title":"Unversioned","text":"","category":"section"},{"location":"manual/NEWS/","page":"Release notes","title":"Release notes","text":"Minor updates on docstrings and descriptions.\nAdjusted to EnergyModelsBase v0.8.1.","category":"page"},{"location":"manual/NEWS/#Version-0.6.1-(2024-09-03)","page":"Release notes","title":"Version 0.6.1 (2024-09-03)","text":"","category":"section"},{"location":"manual/NEWS/","page":"Release notes","title":"Release notes","text":"Dependency increase for EnergyModelsBase as the changes do not directly affect EnergyModelsCO2.\nUpdated the documentation using the new structure released by EnergyModelsCO2.\nIncluded the package DocumenterInterLinks for crossreferences to EnergyModelsBase.\nUse dev version of EMRP for examples when running as part of tests, similar to PR #33 of EMB.","category":"page"},{"location":"manual/NEWS/#Version-0.6.0-(2024-05-28)","page":"Release notes","title":"Version 0.6.0 (2024-05-28)","text":"","category":"section"},{"location":"manual/NEWS/","page":"Release notes","title":"Release notes","text":"Adjusted to changes introduced in EnergyModelsBase v0.7.\nRemove legacy constructor for RegHydroStor and provide a warning for it.\nAdded constructors for HydroStor not requiring any longer specifying an input dictionary.","category":"page"},{"location":"manual/NEWS/#Version-0.5.6-(2024-05-09)","page":"Release notes","title":"Version 0.5.6 (2024-05-09)","text":"","category":"section"},{"location":"manual/NEWS/","page":"Release notes","title":"Release notes","text":"Provided a contribution section in the documentation.\nFixed a link in the documentation for the examples.","category":"page"},{"location":"manual/NEWS/#Version-0.5.5-(2024-03-21)","page":"Release notes","title":"Version 0.5.5 (2024-03-21)","text":"","category":"section"},{"location":"manual/NEWS/","page":"Release notes","title":"Release notes","text":"Minor changes to the checks to be consistent with EnergyModelsBase v0.6.7.","category":"page"},{"location":"manual/NEWS/#Version-0.5.4-(2024-03-04)","page":"Release notes","title":"Version 0.5.4 (2024-03-04)","text":"","category":"section"},{"location":"manual/NEWS/#Examples","page":"Release notes","title":"Examples","text":"","category":"section"},{"location":"manual/NEWS/","page":"Release notes","title":"Release notes","text":"Fixed a bug when running the examples from a non-cloned version of EnergyModelsRenewableProducers.\nThis was achieved through a separate Project.toml in the examples.","category":"page"},{"location":"manual/NEWS/#NonDIsRes-node","page":"Release notes","title":"NonDIsRes node","text":"","category":"section"},{"location":"manual/NEWS/","page":"Release notes","title":"Release notes","text":"Moved the capacity constraints through the profile to the function EMB.constraints_capacity(n::NonDisRES, ...), and hence, removed the function EMB.create_node(n::NonDisRES, ...).","category":"page"},{"location":"manual/NEWS/#Minor-updates","page":"Release notes","title":"Minor updates","text":"","category":"section"},{"location":"manual/NEWS/","page":"Release notes","title":"Release notes","text":"Added some checks and tests to the checks.\nRestructured the test folder.","category":"page"},{"location":"manual/NEWS/#Version-0.5.3-(2024-01-30)","page":"Release notes","title":"Version 0.5.3 (2024-01-30)","text":"","category":"section"},{"location":"manual/NEWS/","page":"Release notes","title":"Release notes","text":"Updated the restrictions on the fields of individual types to be consistent.\nAdded option to not include the field data for the individual introduced Nodes.","category":"page"},{"location":"manual/NEWS/#Version-0.5.2-(2024-01-19)","page":"Release notes","title":"Version 0.5.2 (2024-01-19)","text":"","category":"section"},{"location":"manual/NEWS/","page":"Release notes","title":"Release notes","text":"Updated the documenation to be in line with the updated done in EnergyModelsBsae.\nMoved RegHydroStor to a new file, legacy_constructors.jl to highlight that a user should use the new types, namely HydroStor and PumpedHydroStor.","category":"page"},{"location":"manual/NEWS/#Version-0.5.1-(2024-01-17)","page":"Release notes","title":"Version 0.5.1 (2024-01-17)","text":"","category":"section"},{"location":"manual/NEWS/","page":"Release notes","title":"Release notes","text":"Update the method constraints_level to match the signature updates for these methods in EnergyModelsBase. This includes renaming constraints_level to constraints_level_sp.\nMoved the function to EMB.constraints_level_sp to avoid problems.","category":"page"},{"location":"manual/NEWS/#Version-0.5.0-(2023-12-18)","page":"Release notes","title":"Version 0.5.0 (2023-12-18)","text":"","category":"section"},{"location":"manual/NEWS/#Adjustment-to-release-in-EMB-0.6.0","page":"Release notes","title":"Adjustment to release in EMB 0.6.0","text":"","category":"section"},{"location":"manual/NEWS/","page":"Release notes","title":"Release notes","text":"Adjusted the code for the new release.\nImplementation of support for RepresentativePeriods for HydroStorage nodes.","category":"page"},{"location":"manual/NEWS/#Version-0.4.2-(2023-09-01)","page":"Release notes","title":"Version 0.4.2 (2023-09-01)","text":"","category":"section"},{"location":"manual/NEWS/#Create-a-variable-:spill-for-hydro-storage-node","page":"Release notes","title":"Create a variable :spill for hydro storage node","text":"","category":"section"},{"location":"manual/NEWS/","page":"Release notes","title":"Release notes","text":"This variable enables hydro storage nodes to spill water from the reservoir without producing energy.","category":"page"},{"location":"manual/NEWS/#Version-0.4.1-(2023-08-31)","page":"Release notes","title":"Version 0.4.1 (2023-08-31)","text":"","category":"section"},{"location":"manual/NEWS/#Split-the-hydro-storage-node-into-to-separate-nodes","page":"Release notes","title":"Split the hydro storage node into to separate nodes","text":"","category":"section"},{"location":"manual/NEWS/","page":"Release notes","title":"Release notes","text":"Split RegHydroStor into to types PumpedHydroStor and HydroStor. Both are subtypes","category":"page"},{"location":"manual/NEWS/","page":"Release notes","title":"Release notes","text":"of the new abstract type HydroStorage <: EMB.Storage.","category":"page"},{"location":"manual/NEWS/","page":"Release notes","title":"Release notes","text":"Fix: variational OPEX for HydroStor now depends on flow_out instead of","category":"page"},{"location":"manual/NEWS/","page":"Release notes","title":"Release notes","text":"flow_in. The new type PumpedHydroStor has a separate parameter for variational OPEX for the pumps, which depends on flow_in.","category":"page"},{"location":"manual/NEWS/#Version-0.4.0-(2023-06-06)","page":"Release notes","title":"Version 0.4.0 (2023-06-06)","text":"","category":"section"},{"location":"manual/NEWS/#Switch-to-TimeStruct","page":"Release notes","title":"Switch to TimeStruct","text":"","category":"section"},{"location":"manual/NEWS/","page":"Release notes","title":"Release notes","text":"Switched the time structure representation to TimeStruct.\nTimeStruct is implemented with only the basis features that were available in TimeStructures. This implies that neither operational nor strategic uncertainty is included in the model.","category":"page"},{"location":"manual/NEWS/","page":"Release notes","title":"Release notes","text":"Version 0.3.0 (2023-05-30)","category":"page"},{"location":"manual/NEWS/","page":"Release notes","title":"Release notes","text":"Adjustment to changes in EnergyModelsBase v0.4.0 related to extra input data.","category":"page"},{"location":"manual/NEWS/#Version-0.2.2-(2023-05-15)","page":"Release notes","title":"Version 0.2.2 (2023-05-15)","text":"","category":"section"},{"location":"manual/NEWS/","page":"Release notes","title":"Release notes","text":"Adjustment to changes in EnergyModelsBase v 0.3.3 related to the calls for the constraint functions.","category":"page"},{"location":"manual/NEWS/#Version-0.2.1-(2023-02-03)","page":"Release notes","title":"Version 0.2.1 (2023-02-03)","text":"","category":"section"},{"location":"manual/NEWS/","page":"Release notes","title":"Release notes","text":"Take the examples out to the folder examples.","category":"page"},{"location":"manual/NEWS/#Version-0.2.0-(2023-02-03)","page":"Release notes","title":"Version 0.2.0 (2023-02-03)","text":"","category":"section"},{"location":"manual/NEWS/#Adjustmends-to-updates-in-EnergyModelsBase","page":"Release notes","title":"Adjustmends to updates in EnergyModelsBase","text":"","category":"section"},{"location":"manual/NEWS/","page":"Release notes","title":"Release notes","text":"Adjustment to version 0.3.0, namely:","category":"page"},{"location":"manual/NEWS/","page":"Release notes","title":"Release notes","text":"Changed type (Node) calls in tests to be consistent with version 0.3.0.\nRemoval of the type GlobalData and replacement with fields in the type OperationalModel in all tests.\nChanged type structure to be consistent with EMB version 0.3.0.\nSubstitution of certain constraints in create_node through functions which utilize dispatching on node types.\nChanged the input to the function variables_node.","category":"page"},{"location":"manual/NEWS/#Version-0.1.3-(2022-12-12)","page":"Release notes","title":"Version 0.1.3 (2022-12-12)","text":"","category":"section"},{"location":"manual/NEWS/#Internal-release","page":"Release notes","title":"Internal release","text":"","category":"section"},{"location":"manual/NEWS/","page":"Release notes","title":"Release notes","text":"Renamed to follow common prefix naming scheme.\nUpdate README.","category":"page"},{"location":"manual/NEWS/#Version-0.1.2-(2022-12-02)","page":"Release notes","title":"Version 0.1.2 (2022-12-02)","text":"","category":"section"},{"location":"manual/NEWS/","page":"Release notes","title":"Release notes","text":"Minor test fixes in preparation of internal release.","category":"page"},{"location":"manual/NEWS/#Version-0.1.1-(2021-09-07)","page":"Release notes","title":"Version 0.1.1 (2021-09-07)","text":"","category":"section"},{"location":"manual/NEWS/#Changes-in-naming","page":"Release notes","title":"Changes in naming","text":"","category":"section"},{"location":"manual/NEWS/","page":"Release notes","title":"Release notes","text":"Major changes in both variable and parameter naming, check the commit message for an overview.\nChange of structure in composite type \"RegHydroStor\".","category":"page"},{"location":"manual/NEWS/#Version-0.1.0-(2021-08-23)","page":"Release notes","title":"Version 0.1.0 (2021-08-23)","text":"","category":"section"},{"location":"manual/NEWS/","page":"Release notes","title":"Release notes","text":"Initial version with inclusion of nodes for:\nnondispatchable renewable energy sources (NonDisRES) and\nregulated hydro generation (RegHydroStor, can be used for pumped hydro storage).","category":"page"},{"location":"#EnergyModelsRenewableProducers","page":"Home","title":"EnergyModelsRenewableProducers","text":"","category":"section"},{"location":"","page":"Home","title":"Home","text":"This Julia package implements three new nodes with corresponding JuMP variables and constraints, extending the package EnergyModelsBase with more detailed representation of renewable energy sources.","category":"page"},{"location":"","page":"Home","title":"Home","text":"These nodes are","category":"page"},{"location":"","page":"Home","title":"Home","text":"a Source node NonDisRES,\na Storage node (HydroStor), and\na Storage node (PumpedHydroStor).","category":"page"},{"location":"","page":"Home","title":"Home","text":"The new introduced node types are also documented in the public library as well as the corresponding nodal page.","category":"page"},{"location":"#Developed-nodes","page":"Home","title":"Developed nodes","text":"","category":"section"},{"location":"#[NonDisRES](@ref)","page":"Home","title":"NonDisRES","text":"","category":"section"},{"location":"","page":"Home","title":"Home","text":"The first node models a non-dispatchable renewable energy source, like wind power, solar power, or run of river hydropower. These all use intermittent energy sources in the production of energy, so the maximum production capacity varies with the availability of the energy source at the time.","category":"page"},{"location":"#[HydroStor](@ref)-and-[PumpedHydroStor](@ref)","page":"Home","title":"HydroStor and PumpedHydroStor","text":"","category":"section"},{"location":"","page":"Home","title":"Home","text":"The other nodes implement a regulated hydropower storage plant, both with (PumpedHydroStor) and without pumps (HydroStor) for filling the reservoir with excess energy. The hydropower storage plant can also be extended as they are declared as subtypes of HydroStorage.","category":"page"},{"location":"#Manual-outline","page":"Home","title":"Manual outline","text":"","category":"section"},{"location":"","page":"Home","title":"Home","text":"Pages = [\n \"manual/quick-start.md\",\n \"manual/simple-example.md\",\n \"manual/NEWS.md\",\n]\nDepth = 1","category":"page"},{"location":"#Description-of-the-nodes","page":"Home","title":"Description of the nodes","text":"","category":"section"},{"location":"","page":"Home","title":"Home","text":"Pages = [\n \"nodes/nondisres.md\",\n \"nodes/hydropower.md\",\n]\nDepth = 1","category":"page"},{"location":"#How-to-guides","page":"Home","title":"How to guides","text":"","category":"section"},{"location":"","page":"Home","title":"Home","text":"Pages = [\n \"how-to/contribute.md\",\n \"how-to/update-models.md\",\n]\nDepth = 1","category":"page"},{"location":"#Library-outline","page":"Home","title":"Library outline","text":"","category":"section"},{"location":"","page":"Home","title":"Home","text":"Pages = [\n \"library/public.md\",\n \"library/internals/methods-fields.md\",\n \"library/internals/methods-EMB.md\",\n]\nDepth = 1","category":"page"},{"location":"nodes/nondisres/#nodes-nondisres","page":"Non-dispatchable RES","title":"Non-dispatchable renewable energy source node","text":"","category":"section"},{"location":"nodes/nondisres/","page":"Non-dispatchable RES","title":"Non-dispatchable RES","text":"Non-dispatchable renewable energy sources generate electricity from intermittent energy sources. Examples for intermittent energy sources are solar irradiation, the wind, or the flow within rivers. Although these energy sources have a constant nominal capacity, their production depends on intermittent energy sources. Although EnergyModelsX allows for capacities varying on the operational level, it is then not possible to include investments for a technology. As a consequence, the design of the RefSource is not satisfactory, when considering potential investments in capacities.=.","category":"page"},{"location":"nodes/nondisres/","page":"Non-dispatchable RES","title":"Non-dispatchable RES","text":"Hence, it is necessary to implement a source node representing intermittent renewable energy generation.","category":"page"},{"location":"nodes/nondisres/#nodes-nondisres-fields","page":"Non-dispatchable RES","title":"Introduced type and its fields","text":"","category":"section"},{"location":"nodes/nondisres/","page":"Non-dispatchable RES","title":"Non-dispatchable RES","text":"The NonDisRES is implemented as equivalent to a RefSource. Hence, it utilizes the same functions declared in EnergyModelsBase.","category":"page"},{"location":"nodes/nondisres/#nodes-nondisres-fields-stand","page":"Non-dispatchable RES","title":"Standard fields","text":"","category":"section"},{"location":"nodes/nondisres/","page":"Non-dispatchable RES","title":"Non-dispatchable RES","text":"The standard fields are given as:","category":"page"},{"location":"nodes/nondisres/","page":"Non-dispatchable RES","title":"Non-dispatchable RES","text":"id:\nThe field id is only used for providing a name to the node. This is similar to the approach utilized in EnergyModelsBase.\ncap::TimeProfile:\nThe installed capacity corresponds to the nominal capacity of the node.\nIf 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.\nopex_var::TimeProfile:\nThe 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.\nopex_fixed::TimeProfile:\nThe 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.\nIt 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.\noutput::Dict{<:Resource, <:Real}:\nThe field output includes Resources with their corresponding conversion factors as dictionaries. In the case of a non-dispatchable renewable energy source, output should always include your electricity resource.In practice, you should use a value of 1.\nAll values have to be non-negative.\ndata::Vector{Data}:\nAn entry for providing additional data to the model. In the current version, it is only relevant for additional investment data when EnergyModelsInvestments is used.\nnote: Note\nThe field data is not required as we include a constructor when the value is excluded.","category":"page"},{"location":"nodes/nondisres/#nodes-nondisres-fields-new","page":"Non-dispatchable RES","title":"Additional fields","text":"","category":"section"},{"location":"nodes/nondisres/","page":"Non-dispatchable RES","title":"Non-dispatchable RES","text":"NonDisRES nodes add a single additional field compared to a RefSource:","category":"page"},{"location":"nodes/nondisres/","page":"Non-dispatchable RES","title":"Non-dispatchable RES","text":"profile::TimeProfile:\nThe profile is used as a multiplier to the installed capacity to represent the maximum actual capacity in each operational period.\nThe profile should be provided as OperationalProfile or at least as RepresentativeProfile. In addition, all values should be in the range 0 1.","category":"page"},{"location":"nodes/nondisres/","page":"Non-dispatchable RES","title":"Non-dispatchable RES","text":"This field is at the 3ʳᵈ position below the field cap as shown in NonDisRES.","category":"page"},{"location":"nodes/nondisres/#nodes-nondisres-math","page":"Non-dispatchable RES","title":"Mathematical description","text":"","category":"section"},{"location":"nodes/nondisres/","page":"Non-dispatchable RES","title":"Non-dispatchable RES","text":"In the following mathematical equations, we use the name for variables and functions used in the model. Variables are in general represented as","category":"page"},{"location":"nodes/nondisres/","page":"Non-dispatchable RES","title":"Non-dispatchable RES","text":"textttvar_exampleindex_1 index_2","category":"page"},{"location":"nodes/nondisres/","page":"Non-dispatchable RES","title":"Non-dispatchable RES","text":"with square brackets, while functions are represented as","category":"page"},{"location":"nodes/nondisres/","page":"Non-dispatchable RES","title":"Non-dispatchable RES","text":"func_example(index_1 index_2)","category":"page"},{"location":"nodes/nondisres/","page":"Non-dispatchable RES","title":"Non-dispatchable RES","text":"with paranthesis.","category":"page"},{"location":"nodes/nondisres/#nodes-nondisres-math-var","page":"Non-dispatchable RES","title":"Variables","text":"","category":"section"},{"location":"nodes/nondisres/#nodes-nondisres-math-var-stand","page":"Non-dispatchable RES","title":"Standard variables","text":"","category":"section"},{"location":"nodes/nondisres/","page":"Non-dispatchable RES","title":"Non-dispatchable RES","text":"The non-dispatchable renewable energy source node types utilize all standard variables from the RefSource node type, as described on the page Optimization variables. The variables include:","category":"page"},{"location":"nodes/nondisres/","page":"Non-dispatchable RES","title":"Non-dispatchable RES","text":"textttopex_var\ntextttopex_fixed\ntextttcap_use\ntextttcap_inst\ntextttflow_out\ntextttemissions_node if EmissionsData is added to the field data.","category":"page"},{"location":"nodes/nondisres/","page":"Non-dispatchable RES","title":"Non-dispatchable RES","text":"note: Note\nNon-dispatchable renewable energy source nodes are not compatible with CaptureData. Hence, you can only provide EmissionsProcess to the node. It is our aim to include the potential for construction emissions in a latter stage","category":"page"},{"location":"nodes/nondisres/#nodes-nondisres-math-add","page":"Non-dispatchable RES","title":"Additional variables","text":"","category":"section"},{"location":"nodes/nondisres/","page":"Non-dispatchable RES","title":"Non-dispatchable RES","text":"NonDisRES nodes should keep track on the curtailment of the electricity, that is the unused capacity in each operational time period. Hence, a single additional variable is declared through dispatching on the method EnergyModelsBase.variables_node():","category":"page"},{"location":"nodes/nondisres/","page":"Non-dispatchable RES","title":"Non-dispatchable RES","text":"textttcurtailmentn t: Curtailed capacity of source n in operational period t with a typical unit of MW.\nThe curtailed electricity specifies the unused generation capacity of the non-dispatchable energy source. It is currently only used in the calculation, but not with a cost. This can be added by the user, if desired.","category":"page"},{"location":"nodes/nondisres/#nodes-nondisres-math-con","page":"Non-dispatchable RES","title":"Constraints","text":"","category":"section"},{"location":"nodes/nondisres/","page":"Non-dispatchable RES","title":"Non-dispatchable RES","text":"The following sections omit the direction inclusion of the vector of CO₂ source nodes. Instead, it is implicitly assumed that the constraints are valid forall n N^textNonDisRES_source for all NonDisRES 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).","category":"page"},{"location":"nodes/nondisres/#nodes-nondisres-math-con-stand","page":"Non-dispatchable RES","title":"Standard constraints","text":"","category":"section"},{"location":"nodes/nondisres/","page":"Non-dispatchable RES","title":"Non-dispatchable RES","text":"Non-dispatchable renewable energy source nodes utilize in general the standard constraints described on Constraint functions. In fact, they use the same create_node function as a RefSource node. These standard constraints are:","category":"page"},{"location":"nodes/nondisres/","page":"Non-dispatchable RES","title":"Non-dispatchable RES","text":"constraints_capacity_installed:\ntextttcap_instn t = capacity(n t)\ntip: Using investments\nThe 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.\nconstraints_flow_out:\ntextttflow_outn t p =\noutputs(n p) times textttcap_usen t\nqquad forall p in outputs(n) setminus textCO_2\nconstraints_opex_fixed:\ntextttopex_fixedn t_inv = opex_fixed(n t_inv) times textttcap_instn first(t_inv)\ntip: Why do we use `first()`\nThe variables textttcap_inst are 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 capacities in the first operational period of a given strategic period t_inv in the function constraints_opex_fixed.\nconstraints_opex_var:\ntextttopex_varn t_inv = sum_t in t_inv opex_var(n t) times textttcap_usen t times scale_op_sp(t_inv t)\ntip: The function `scale_op_sp`\nThe 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.\nconstraints_data:\nThis function is only called for specified data of the non-dispatchable renewable energy source, see above.","category":"page"},{"location":"nodes/nondisres/","page":"Non-dispatchable RES","title":"Non-dispatchable RES","text":"The function constraints_capacity is extended with a new method for non-dispatchable renewable energy source nodes to allow the inclusion of the production profile and the variable textttcurtailmentn t. It now includes two individual constraints:","category":"page"},{"location":"nodes/nondisres/","page":"Non-dispatchable RES","title":"Non-dispatchable RES","text":"textttcap_usen t leq textttcap_instn t","category":"page"},{"location":"nodes/nondisres/","page":"Non-dispatchable RES","title":"Non-dispatchable RES","text":"and","category":"page"},{"location":"nodes/nondisres/","page":"Non-dispatchable RES","title":"Non-dispatchable RES","text":"textttcap_usen t + textttcurtailmentn t =\nprofile(n t) times textttcap_instn t","category":"page"},{"location":"nodes/nondisres/","page":"Non-dispatchable RES","title":"Non-dispatchable RES","text":"This function still calls the subfunction constraints_capacity_installed to limit the variable textttcap_instn t or provide capacity investment options.","category":"page"},{"location":"nodes/nondisres/#nodes-nondisres-math-con-add","page":"Non-dispatchable RES","title":"Additional constraints","text":"","category":"section"},{"location":"nodes/nondisres/","page":"Non-dispatchable RES","title":"Non-dispatchable RES","text":"NonDisRES nodes do not add additional constraints.","category":"page"},{"location":"library/public/#lib-pub","page":"Public","title":"Public interface","text":"","category":"section"},{"location":"library/public/#lib-pub-module","page":"Public","title":"Module","text":"","category":"section"},{"location":"library/public/","page":"Public","title":"Public","text":"EnergyModelsRenewableProducers","category":"page"},{"location":"library/public/#EnergyModelsRenewableProducers","page":"Public","title":"EnergyModelsRenewableProducers","text":"Main module for EnergyModelsRenewableProducers.jl.\n\nThis module implements the following types (Nodes) with constraints:\n\nNonDisRes is a subtype of Source and represents a non-dispatchable renewable producer, as wind, solar etc.\nPumpedHydroStor is a subtype of Storage and represents a regulated pumped hydro storage.\nHydroStor is a subtype of Storage and represents a regulated hydro storage, that is a standard hydro powerplant without pumps.\n\n\n\n\n\n","category":"module"},{"location":"library/public/#lib-pub-node","page":"Public","title":"Node types","text":"","category":"section"},{"location":"library/public/#lib-pub-node-abstract","page":"Public","title":"Abstract types","text":"","category":"section"},{"location":"library/public/","page":"Public","title":"Public","text":"HydroStorage","category":"page"},{"location":"library/public/#EnergyModelsRenewableProducers.HydroStorage","page":"Public","title":"EnergyModelsRenewableProducers.HydroStorage","text":"An abstract type for hydro storage nodes, with or without pumping. \n\n\n\n\n\n","category":"type"},{"location":"library/public/#lib-pub-node-concrete","page":"Public","title":"Concrete types","text":"","category":"section"},{"location":"library/public/","page":"Public","title":"Public","text":"NonDisRES\nHydroStor\nPumpedHydroStor","category":"page"},{"location":"library/public/#EnergyModelsRenewableProducers.NonDisRES","page":"Public","title":"EnergyModelsRenewableProducers.NonDisRES","text":"NonDisRES <: EMB.Source\n\nA non-dispatchable renewable energy source. It extends the existing RefSource node through including a profile that corresponds to thr production. The profile can have variations on the strategic level.\n\nFields\n\nid is the name/identifyer of the node.\ncap::TimeProfile is the installed capacity.\nprofile::TimeProfile is the power production in each operational period as a ratio of the installed capacity at that time.\nopex_var::TimeProfile is the variable operating expense per energy unit produced.\nopex_fixed::TimeProfile is the fixed operating expense.\noutput::Dict{Resource, Real} are the generated Resources, normally Power.\ndata::Vector{Data} is the additional data (e.g. for investments). The field data is conditional through usage of a constructor.\n\n\n\n\n\n","category":"type"},{"location":"library/public/#EnergyModelsRenewableProducers.HydroStor","page":"Public","title":"EnergyModelsRenewableProducers.HydroStor","text":"HydroStor{T} <: HydroStorage{T}\n\nA regulated hydropower storage, modelled as a Storage node. A regulated hydro storage node requires a capacity for the discharge and does not have a required inflow from the model, except for water inflow from outside the model, although it requires a field input.\n\nFields\n\nid is the name/identifyer of the node.\nlevel::EMB.UnionCapacity are the level parameters of the HydroStor node. Depending on the chosen type, the charge parameters can include variable OPEX and/or fixed OPEX.\ndischarge::EMB.UnionCapacity are the discharging parameters of the HydroStor node. Depending on the chosen type, the discharge parameters can include variable OPEX, fixed OPEX, and/or a capacity.\nlevel_init::TimeProfile is the initial stored energy in the dam.\nlevel_inflow::TimeProfile is the inflow of power per operational period.\nlevel_min::TimeProfile is the minimum fraction of the reservoir capacity that has to remain in the HydroStorage node.\nstor_res::ResourceCarrier is the stored Resource.\ninput::Dict{Resource, Real} are the input Resources. In the case of a HydroStor, this field can be left out.\noutput::Dict{Resource, Real} can only contain one entry, the stored resource.\ndata::Vector{Data} additional data (e.g. for investments). The field data is conditional through usage of a constructor.\n\n\n\n\n\n","category":"type"},{"location":"library/public/#EnergyModelsRenewableProducers.PumpedHydroStor","page":"Public","title":"EnergyModelsRenewableProducers.PumpedHydroStor","text":"PumpedHydroStor{T} <: HydroStorage{T}\n\nA pumped hydropower storage, modelled as a Storage node. A pumped hydro storage node allows for storing energy through pumping water into the reservoir. The current implementation is a simplified node in which no lower reservoir is required. Instead, it is assumed that the reservoir has an infinite size.\n\nA pumped hydro storage node requires a capacity for both charge and discharge to account for the potential to store energy in the form of potential energy.\n\nFields\n\nid is the name/identifyer of the node.\ncharge::EMB.UnionCapacity are the charging parameters of the PumpedHydroStor node. Depending on the chosen type, the charge parameters can include variable OPEX, fixed OPEX, and/or a capacity.\nlevel::EMB.UnionCapacity are the level parameters of the HydroStor node. Depending on the chosen type, the charge parameters can include variable OPEX and/or fixed OPEX.\ndischarge::EMB.UnionCapacity are the discharging parameters of the HydroStor node. Depending on the chosen type, the discharge parameters can include variable OPEX, fixed OPEX, and/or a capacity.\nlevel_init::TimeProfile is the initial stored energy in the dam.\nlevel_inflow::TimeProfile is the inflow of power per operational period.\nlevel_min::TimeProfile is the minimum fraction of the reservoir capacity that has to remain in the HydroStorage node.\nstor_res::ResourceCarrier is the stored Resource.\ninput::Dict{Resource, Real} are the input Resources.\noutput::Dict{Resource, Real} can only contain one entry, the stored resource.\ndata::Vector{Data} additional data (e.g. for investments). The field data is conditional through usage of a constructor.\n\n\n\n\n\n","category":"type"},{"location":"library/public/#lib-pub-node-legacy","page":"Public","title":"Legacy constructors","text":"","category":"section"},{"location":"library/public/","page":"Public","title":"Public","text":"RegHydroStor","category":"page"},{"location":"library/public/#EnergyModelsRenewableProducers.RegHydroStor","page":"Public","title":"EnergyModelsRenewableProducers.RegHydroStor","text":"RegHydroStor(\n id::Any,\n rate_cap::TimeProfile,\n stor_cap::TimeProfile,\n has_pump::Bool,\n level_init::TimeProfile,\n level_inflow::TimeProfile,\n level_min::TimeProfile,\n opex_var::TimeProfile,\n opex_fixed::TimeProfile,\n stor_res::ResourceCarrier,\n input,\n output,\n Data,\n)\n\nOriginal Legacy constructor for a regulated hydropower storage, with or without pumping capabilities. This version is discontinued starting with Version 0.6.0. resulting in an error It is replaced with the two new types HydroStor and PumpedHydroStor to utilize the concept of multiple dispatch instead of logic.\n\nSee the documentation for further information regarding how you can translate your existing model to the new model.\n\nFields\n\nid is the name/identifyer of the node.\nrate_cap::TimeProfile is the installed installed rate capacity.\nstor_cap::TimeProfile is the installed storage capacity in the dam.\nhas_pump::Bool states wheter the stored resource can flow in.\nlevel_init::TimeProfile is the initial stored energy in the dam.\nlevel_inflow::TimeProfile is the inflow of power per operational period.\nlevel_min::TimeProfile is the minimum fraction of the reservoir capacity that has to remain in the HydroStorage node.\nopex_var::TimeProfile are the variable operational expenses per GWh produced.\nopex_fixed::TimeProfile are the fixed operational costs of the storage caacity.\nstor_res::ResourceCarrier is the stored Resource.\ninput::Dict{Resource, Real} are the stored and used resources. The values in the Dict are ratios describing the energy loss when using the pumps.\noutput::Dict{Resource, Real} can only contain one entry, the stored resource.\ndata::Array{Data} additional data (e.g. for investments). This value is conditional through the application of a constructor.\n\n\n\n\n\n","category":"function"}] }