Incorporation of variables for Data types

docs/make.jl

@@ -43,7 +43,7 @@ makedocs(
             "Philosophy"=>"manual/philosophy.md",
             "Optimization variables"=>"manual/optimization-variables.md",
             "Constraint functions"=>"manual/constraint-functions.md",
-            "Data functions"=>"manual/data-functions.md",
+            "ExtensionData functions"=>"manual/data-functions.md",
             "Example"=>"manual/simple-example.md",
             "Investment options"=>"manual/investments.md",
             "Release notes"=>"manual/NEWS.md",
@@ -65,7 +65,7 @@ makedocs(
         "Library" => Any[
             "Public"=>Any[
                 "Resources"=>"library/public/resources.md",
-                "Modeltype and Data"=>"library/public/model_data.md",
+                "Modeltype and ExtensionData"=>"library/public/model_data.md",
                 "Nodes"=>"library/public/nodes.md",
                 "Links"=>"library/public/links.md",
                 "Case"=>"library/public/case_element.md",

docs/src/how-to/create-new-node.md

@@ -47,7 +47,7 @@ This is however only advised if you do not need to access the value of the varia
 2. Emissions can be included in any way.
    It is however beneficial to reutilize the [`EmissionsData`](@ref) type to improve usability with other packages.
    This requries again the inclusion of the field `data` in `NewNodeType`.
-   It is possible to also create new subtypes for `EmissionsData` as well as dispatch on the function [`constraints_data(m, n::Node, 𝒯, 𝒫, modeltype, data::Data)`](@ref man-data_fun).
+   It is possible to also create new subtypes for `EmissionsData` as well as dispatch on the function [`constraints_data(m, n::Node, 𝒯, 𝒫, modeltype, data::ExtensionData)`](@ref man-data_fun).
 3. It is in a first stage not important to include functions for handling all possible `TimeStructure`s, that is, *e.g.*, `RepresentativePeriods`.
    Instead, and error can be provided if an unsupported `TimeStructure` is chosen.
 4. The existing reference nodes and their respective *[constraint functions](@ref man-con)* can serve as idea generators.

docs/src/library/internals/functions.md

@@ -16,6 +16,7 @@ CurrentModule = EnergyModelsBase
 create_element
 create_link
 variables_element
+variables_data(m, _::Type{<:ExtensionData}, 𝒳::Vector{<:AbstractElement}, 𝒯, 𝒫, modeltype::EnergyModel)
 objective(m, 𝒳ᵛᵉᶜ, 𝒫, 𝒯, modeltype::EnergyModel)
 objective_operational
 emissions_operational
@@ -39,9 +40,10 @@ constraints_level_bounds
 variables_capacity
 variables_flow
 variables_opex
-variables_capex(m, 𝒩::Vector{<:Node}, 𝒳ᵛᵉᶜ, 𝒯, modeltype::EnergyModel)
+variables_capex
 variables_emission
 variables_elements
+variables_element_data
 ```
 
 ## [Check functions](@id lib-int-fun-check)
@@ -55,7 +57,7 @@ check_node
 check_link
 check_node_default
 check_node_data(n::Node, data::EmissionsData, 𝒯, modeltype::EnergyModel, check_timeprofiles::Bool)
-check_link_data(n::Link, data::Data, 𝒯, modeltype::EnergyModel, check_timeprofiles::Bool)
+check_link_data(n::Link, data::ExtensionData, 𝒯, modeltype::EnergyModel, check_timeprofiles::Bool)
 check_fixed_opex
 check_time_structure
 check_profile

docs/src/library/internals/reference_EMIExt.md

@@ -32,7 +32,7 @@ check_inv_data
 ### [Methods](@id lib-int-EMIext-met)
 
 ```@docs
-EMB.variables_capex(m, 𝒩::Vector{<:EMB.Node}, 𝒳ᵛᵉᶜ, 𝒯, modeltype::AbstractInvestmentModel)
+EMB.variables_data(m, _::Type{SingleInvData}, 𝒩ᴵⁿᵛ::Vector{<:EMB.Node}, 𝒯, 𝒫, modeltype::AbstractInvestmentModel)
 EMB.objective_invest(m, 𝒩::Vector{<:EMB.Node}, 𝒯ᴵⁿᵛ::TS.AbstractStratPers, modeltype::AbstractInvestmentModel)
 EMB.constraints_capacity_installed(m, n::EMB.Node, 𝒯::TimeStructure, modeltype::AbstractInvestmentModel)
 EMB.check_node_data(n::EMB.Node, data::InvestmentData, 𝒯, modeltype::AbstractInvestmentModel, check_timeprofiles::Bool)

docs/src/library/public/case_element.md

@@ -23,6 +23,12 @@ The connections are incorporated through `Link`s which transport resources betwe
 AbstractElement
 ```
 
+`EnergyModelsBase` allows for the potential of extension data which can be extracted through
+
+```@docs
+element_data
+```
+
 ## [Case type](@id lib-pub-case-case)
 
 The case type is used as input to `EnergyModelsBase` models.

docs/src/library/public/emi_extension.md

@@ -34,7 +34,7 @@ discount_rate
 
 ### [`InvestmentData` types](@id lib-pub-emi_ext-inv_data-types)
 
-`InvestmentData` subtypes are used to provide technologies introduced in `EnergyModelsX` (nodes and transmission modes) a subtype of `Data` that can be used for dispatching.
+`InvestmentData` subtypes are used to provide technologies introduced in `EnergyModelsX` (nodes and transmission modes) a subtype of `ExtensionData` that can be used for dispatching.
 Two different types are directly introduced, `SingleInvData` and `StorageInvData`.
 
 `SingleInvData` is providing a composite type with a single field.

docs/src/library/public/functions.md

@@ -42,7 +42,7 @@ CurrentModule = EMB
 ```
 
 The following functions can be used in newly developed nodes to include constraints.
-See the pages *[Constraint functions](@ref man-con)* and *[Data functions](@ref man-data_fun)* for a detailed explanation on their usage.
+See the pages *[Constraint functions](@ref man-con)* and *[ExtensionData functions](@ref man-data_fun)* for a detailed explanation on their usage.
 
 !!! warning
     The function `constraints_capacity_installed` should not be changed.

docs/src/library/public/model_data.md

@@ -30,16 +30,16 @@ co2_instance
 ## [Additional data](@id lib-pub-mod_data-data)
 
 Emission data are used to provide the individual nodes with potential emissions.
-The approach is also explained on the page *[Data functions](@ref man-data_fun)*.
+The approach is also explained on the page *[ExtensionData functions](@ref man-data_fun)*.
 
-### [`Data` and `Emission` types](@id lib-pub-mod_data-data-types)
+### [`ExtensionData` and `Emission` types](@id lib-pub-mod_data-data-types)
 
-`Data` types are introduced for introducing additional parameters, variables, and constraints to the `Node`s.
-The approach of using the `data` field of `Node`s is explained on the page *[Data functions](@ref man-data_fun)*.
+`ExtensionData` types are introduced for introducing additional parameters, variables, and constraints to the `Node`s.
+The approach of using the `data` field of `Node`s is explained on the page *[ExtensionData functions](@ref man-data_fun)*.
 `EmptyData` is no longer relevant for the modelling, but it is retained for avoiding any problems with existing models.
 
 ```@docs
-Data
+ExtensionData
 EmptyData
 ```
 

docs/src/manual/data-functions.md

@@ -1,7 +1,7 @@
-# [Data functions](@id man-data_fun)
+# [ExtensionData functions](@id man-data_fun)
 
-The package provides the wildcard [`Data`](@ref) type as outlined in the *[Extensions to the model](@ref man-phil-ext)* section of the philosophy page.
-`Data` can be utilized to extend the functionality of the model through dispatching on its type.
+The package provides the wildcard [`ExtensionData`](@ref) type as outlined in the *[Extensions to the model](@ref man-phil-ext)* section of the philosophy page.
+`ExtensionData` can be utilized to extend the functionality of the model through dispatching on its type.
 The following function is included in all reference `create_node` functions, except for `Storage` types
 
 ```julia
@@ -11,10 +11,10 @@ for data ∈ node_data(n)
 end
 ```
 
-There is always a fallback option if a `Data` is specified, but no functions are provided:
+There is always a fallback option if a `ExtensionData` is specified, but no functions are provided:
 
 ```julia
-constraints_data(m, n::Node, 𝒯, 𝒫, modeltype::EnergyModel, data::Data) = nothing
+constraints_data(m, n::Node, 𝒯, 𝒫, modeltype::EnergyModel, data::ExtensionData) = nothing
 ```
 
 Its application is best explained by the implemented functionality for emissions.

docs/src/manual/philosophy.md

@@ -73,12 +73,12 @@ This is done in the package [`EnergyModelsInvestments`](https://energymodelsx.gi
 It can be problematic when one also wants to use investments.
 In addition, care has to be taken with respect to method amibiguity when dispatching on the type `EnergyModel`.
 
-The `Array{Data}` field provides us with flexibility with respect to providing additional data to the existing nodes.
+The `Array{ExtensionData}` field provides us with flexibility with respect to providing additional data to the existing nodes.
 It is implemented in `EnergyModelsBase` for including emissions (both process and energy usage related).
 In that case, it allows for flexibility through either saying whether process (or energy related emissions) are present, or not.
 In addition, it allows for capturing the CO₂ from either the individual CO₂ sources (process and energy usage related), alternatively from both sources, or not at all.
-The individual data types are explained in the Section *[Additional data](@ref lib-pub-mod_data-data)* in the public library as well as on *[Data functions](@ref man-data_fun)*.
-In addition, it is already used in the package [`EnergyModelsInvestments`](https://energymodelsx.github.io/EnergyModelsInvestments.jl/) through the introduction of the `abstract type` `InvestmentData` as subtype of `Data`.
+The individual data types are explained in the Section *[Additional data](@ref lib-pub-mod_data-data)* in the public library as well as on *[ExtensionData functions](@ref man-data_fun)*.
+In addition, it is already used in the package [`EnergyModelsInvestments`](https://energymodelsx.github.io/EnergyModelsInvestments.jl/) through the introduction of the `abstract type` `InvestmentData` as subtype of `ExtensionData`.
 The introduction of `InvestmentData` allows providing additional parameters to individual technologies.
-However, the implementation in `EnergyModelsInvestments` does not utilize the extension through the *[Data functions](@ref man-data_fun)*.
+However, the implementation in `EnergyModelsInvestments` does not utilize the extension through the *[ExtensionData functions](@ref man-data_fun)*.
 Instead, as outlined above, it dispatches on the type `EnergyModel`.

docs/src/nodes/availability.md

@@ -66,7 +66,7 @@ The variables of [`Availability`](@ref) nodes include:
 
 ### [Constraints](@id nodes-availability-math-con)
 
-Availability nodes do not add by default any constraints, except for the constraints introduced in the function `create_node`(@ref).
+Availability nodes do not add by default any constraints, except for the constraints introduced in the function [`create_node`](@ref).
 This constraint is given by:
 
 ```math

docs/src/nodes/networknode.md

@@ -28,7 +28,7 @@ The fields of a [`RefNetworkNode`](@ref) are given as:
   CO₂ cannot be directly specified, *i.e.*, you cannot specify a ratio.
   If you use [`CaptureData`](@ref), it is however necessary to specify CO₂ as output, although the ratio is not important.\
   All values have to be non-negative.
-- **`data::Vector{Data}`**:\
+- **`data::Vector{ExtensionData}`**:\
   An entry for providing additional data to the model.
   In the current version, it is used for both providing `EmissionsData` and additional investment data when [`EnergyModelsInvestments`](https://energymodelsx.github.io/EnergyModelsInvestments.jl/) is used.
   !!! note "Constructor for RefNetworkNode"

docs/src/nodes/sink.md

@@ -23,7 +23,7 @@ The fields of a [`RefSink`](@ref) node are given as:
 - **`input::Dict{<:Resource,<:Real}`**:\
   The field `input` includes [`Resource`](@ref Resource)s with their corresponding conversion factors as dictionaries.\
   All values have to be non-negative.
-- **`data::Vector{Data}`**:\
+- **`data::Vector{ExtensionData}`**:\
   An entry for providing additional data to the model.
   In the current version, it is used for both providing `EmissionsData` and additional investment data when [`EnergyModelsInvestments`](https://energymodelsx.github.io/EnergyModelsInvestments.jl/) is used.
   !!! note "Constructor for `RefSink`"

docs/src/nodes/source.md

@@ -29,7 +29,7 @@ The fields of a [`RefSource`](@ref) node are given as:
   If you would like to use a `Source` node with CO₂ as output with a given ratio, it is necessary to utilize the package [`EnergyModelsCO2`](https://energymodelsx.github.io/EnergyModelsCO2.jl/).
   If you use [`CaptureData`](@ref), it is however necessary to specify CO₂ as output, although the ratio is not important.\
   All values have to be non-negative.
-- **`data::Vector{Data}`**:\
+- **`data::Vector{ExtensionData}`**:\
   An entry for providing additional data to the model.
   In the current version, it is used for both providing `EmissionsData` and additional investment data when [`EnergyModelsInvestments`](https://energymodelsx.github.io/EnergyModelsInvestments.jl/) is used.
   When using `EmissionsData`, only process emissions can be considered, that is the types [`EmissionsProcess`](@ref) and that is the types [`EmissionsProcess`](@ref) and [`CaptureProcessEmissions`](@ref).

docs/src/nodes/storage.md

@@ -81,7 +81,7 @@ The fields of a [`RefStorage`](@ref) are given as:
       In the current implementation, we do not consider `output` conversion factors for the outflow from the [`RefStorage`](@ref) node.
       Similarly, we do not consider the `input` conversion factor of the stored resource.
       Instead, it is assumed that there is no loss of the stored resource in the storage.
-- **`data::Vector{Data}`**:\
+- **`data::Vector{ExtensionData}`**:\
   An entry for providing additional data to the model.
   In the current version, it is used for both providing `EmissionsData` and additional investment data when [`EnergyModelsInvestments`](https://energymodelsx.github.io/EnergyModelsInvestments.jl/) is used.
   !!! note "Constructor for `RefStorage`"

ext/EMIExt/variables_capex.jl

@@ -1,6 +1,7 @@
 """
-    EMB.variables_capex(m, 𝒩::Vector{<:EMB.Node}, 𝒳ᵛᵉᶜ, 𝒯, modeltype::AbstractInvestmentModel)
-    EMB.variables_capex(m, ℒ::Vector{<:Link}, 𝒳ᵛᵉᶜ, 𝒯, modeltype::AbstractInvestmentModel)
+    EMB.variables_data(m, _::Type{SingleInvData}, 𝒩ᴵⁿᵛ::Vector{<:EMB.Node}, 𝒯, 𝒫, modeltype::AbstractInvestmentModel)
+    EMB.variables_data(m, _::Type{StorageInvData}, 𝒩ᴵⁿᵛ::Vector{<:EMB.Node}, 𝒯, 𝒫, modeltype::AbstractInvestmentModel)
+    EMB.variables_data(m, _::Type{SingleInvData}, 𝒩ᴵⁿᵛ::Vector{<:Link}, 𝒯, 𝒫, modeltype::AbstractInvestmentModel)
 
 Declaration of different capital expenditures (CAPEX) variables for the element types
 introduced in `EnergyModelsBase`. CAPEX variables are only introduced for elements that have
@@ -37,37 +38,38 @@ user with two individual methods for both `𝒩::Vector{<:EMB.Node}` and 𝒩::V
     - `**prefix**_remove_b` is an auxiliary variable used in some investment modes for the
       reduction of capacities.
 """
-function EMB.variables_capex(m, 𝒩::Vector{<:EMB.Node}, 𝒳ᵛᵉᶜ, 𝒯, modeltype::AbstractInvestmentModel)
-    𝒩ᴵⁿᵛ = filter(has_investment, filter(!EMB.is_storage, 𝒩))
-    𝒩ˢᵗᵒʳ = filter(EMB.is_storage, 𝒩)
-    𝒩ˡᵉᵛᵉˡ = filter(n -> has_investment(n, :level), 𝒩ˢᵗᵒʳ)
-    𝒩ᶜʰᵃʳᵍᵉ = filter(n -> has_investment(n, :charge), 𝒩ˢᵗᵒʳ)
-    𝒩ᵈⁱˢᶜʰᵃʳᵍᵉ = filter(n -> has_investment(n, :discharge), 𝒩ˢᵗᵒʳ)
+function EMB.variables_data(m, _::Type{SingleInvData}, 𝒩ᴵⁿᵛ::Vector{<:EMB.Node}, 𝒯, 𝒫, modeltype::AbstractInvestmentModel)
     𝒯ᴵⁿᵛ = strategic_periods(𝒯)
 
-    # Add investment variables for reference nodes for each strategic period:
+    # Add investment variables for nodes for each strategic period
     @variable(m, cap_capex[𝒩ᴵⁿᵛ, 𝒯ᴵⁿᵛ] ≥ 0)
     @variable(m, cap_current[𝒩ᴵⁿᵛ, 𝒯ᴵⁿᵛ] ≥ 0)
     @variable(m, cap_add[𝒩ᴵⁿᵛ, 𝒯ᴵⁿᵛ] ≥ 0)
     @variable(m, cap_rem[𝒩ᴵⁿᵛ, 𝒯ᴵⁿᵛ] ≥ 0)
     @variable(m, cap_invest_b[𝒩ᴵⁿᵛ, 𝒯ᴵⁿᵛ] ≥ 0; container = IndexedVarArray)
     @variable(m, cap_remove_b[𝒩ᴵⁿᵛ, 𝒯ᴵⁿᵛ] ≥ 0; container = IndexedVarArray)
+end
+function EMB.variables_data(m, _::Type{StorageInvData}, 𝒩ˢᵗᵒʳ::Vector{<:EMB.Node}, 𝒯, 𝒫, modeltype::EnergyModel)
+    𝒯ᴵⁿᵛ = strategic_periods(𝒯)
 
-    # Add storage specific investment variables for each strategic period:
+    # Add investment variables for storage nodes for each strategic period
+    𝒩ˡᵉᵛᵉˡ = filter(n -> has_investment(n, :level), 𝒩ˢᵗᵒʳ)
     @variable(m, stor_level_capex[𝒩ˡᵉᵛᵉˡ, 𝒯ᴵⁿᵛ] ≥ 0)
     @variable(m, stor_level_current[𝒩ˡᵉᵛᵉˡ, 𝒯ᴵⁿᵛ] ≥ 0)
     @variable(m, stor_level_add[𝒩ˡᵉᵛᵉˡ, 𝒯ᴵⁿᵛ] ≥ 0)
     @variable(m, stor_level_rem[𝒩ˡᵉᵛᵉˡ, 𝒯ᴵⁿᵛ] ≥ 0)
     @variable(m, stor_level_invest_b[𝒩ˡᵉᵛᵉˡ, 𝒯ᴵⁿᵛ] ≥ 0; container = IndexedVarArray)
     @variable(m, stor_level_remove_b[𝒩ˡᵉᵛᵉˡ, 𝒯ᴵⁿᵛ] ≥ 0; container = IndexedVarArray)
 
+    𝒩ᶜʰᵃʳᵍᵉ = filter(n -> has_investment(n, :charge), 𝒩ˢᵗᵒʳ)
     @variable(m, stor_charge_capex[𝒩ᶜʰᵃʳᵍᵉ, 𝒯ᴵⁿᵛ] ≥ 0)
     @variable(m, stor_charge_current[𝒩ᶜʰᵃʳᵍᵉ, 𝒯ᴵⁿᵛ] ≥ 0)
     @variable(m, stor_charge_add[𝒩ᶜʰᵃʳᵍᵉ, 𝒯ᴵⁿᵛ] ≥ 0)
     @variable(m, stor_charge_rem[𝒩ᶜʰᵃʳᵍᵉ, 𝒯ᴵⁿᵛ] ≥ 0)
     @variable(m, stor_charge_invest_b[𝒩ᶜʰᵃʳᵍᵉ, 𝒯ᴵⁿᵛ] ≥ 0; container = IndexedVarArray)
     @variable(m, stor_charge_remove_b[𝒩ᶜʰᵃʳᵍᵉ, 𝒯ᴵⁿᵛ] ≥ 0; container = IndexedVarArray)
 
+    𝒩ᵈⁱˢᶜʰᵃʳᵍᵉ = filter(n -> has_investment(n, :discharge), 𝒩ˢᵗᵒʳ)
     @variable(m, stor_discharge_capex[𝒩ᵈⁱˢᶜʰᵃʳᵍᵉ, 𝒯ᴵⁿᵛ] ≥ 0)
     @variable(m, stor_discharge_current[𝒩ᵈⁱˢᶜʰᵃʳᵍᵉ, 𝒯ᴵⁿᵛ] ≥ 0)
     @variable(m, stor_discharge_add[𝒩ᵈⁱˢᶜʰᵃʳᵍᵉ, 𝒯ᴵⁿᵛ] ≥ 0)
@@ -83,11 +85,10 @@ function EMB.variables_capex(m, 𝒩::Vector{<:EMB.Node}, 𝒳ᵛᵉᶜ, 𝒯, m
         container = IndexedVarArray
     )
 end
-function EMB.variables_capex(m, ℒ::Vector{<:Link}, 𝒳ᵛᵉᶜ, 𝒯, modeltype::AbstractInvestmentModel)
-    ℒᴵⁿᵛ = filter(has_investment, ℒ)
+function EMB.variables_data(m, _::Type{SingleInvData}, ℒᴵⁿᵛ::Vector{<:Link}, 𝒯, 𝒫, modeltype::EnergyModel)
     𝒯ᴵⁿᵛ = strategic_periods(𝒯)
 
-    # Add investment variables for reference nodes for each strategic period:
+    # Add investment variables for links for each strategic period
     @variable(m, link_cap_capex[ℒᴵⁿᵛ, 𝒯ᴵⁿᵛ] ≥ 0)
     @variable(m, link_cap_current[ℒᴵⁿᵛ, 𝒯ᴵⁿᵛ] ≥ 0)
     @variable(m, link_cap_add[ℒᴵⁿᵛ, 𝒯ᴵⁿᵛ] ≥ 0)

src/EnergyModelsBase.jl

@@ -6,7 +6,7 @@ In addition, all required functions for creaeting and running the model are expo
 
 You can find the exported types and functions below or on the pages
 *[Constraint functions](@ref man-con)* and
-*[Data functions](@ref man-data_fun)*.
+*[ExtensionData functions](@ref man-data_fun)*.
 """
 module EnergyModelsBase
 
@@ -41,7 +41,7 @@ export get_time_struct, get_products, get_elements_vec, get_nodes, get_links, ge
 # Export the general classes
 export EnergyModel, OperationalModel
 export Resource, ResourceCarrier, ResourceEmit
-export AbstractElement
+export AbstractElement, element_data
 
 # Export the different node types
 export Source, NetworkNode, Sink, Storage, Availability
@@ -58,7 +58,7 @@ export Cyclic, CyclicRepresentative, CyclicStrategic
 export StorCapOpex, StorCap, StorCapOpexVar, StorCapOpexFixed, StorOpexVar
 
 # Export the data types
-export Data, EmptyData, EmissionsData, CaptureData
+export Data, ExtensionData, EmptyData, EmissionsData, CaptureData
 export CaptureProcessEnergyEmissions, CaptureProcessEmissions, CaptureEnergyEmissions
 export EmissionsProcess, EmissionsEnergy