diff --git a/dev/.documenter-siteinfo.json b/dev/.documenter-siteinfo.json index 8abd943014..2302339041 100644 --- a/dev/.documenter-siteinfo.json +++ b/dev/.documenter-siteinfo.json @@ -1 +1 @@ -{"documenter":{"julia_version":"1.9.3","generation_timestamp":"2023-10-24T13:31:06","documenter_version":"1.1.2"}} \ No newline at end of file +{"documenter":{"julia_version":"1.9.3","generation_timestamp":"2023-10-24T14:31:39","documenter_version":"1.1.2"}} \ No newline at end of file diff --git a/dev/advanced_concepts/Lossless_DC_power_flow/index.html b/dev/advanced_concepts/Lossless_DC_power_flow/index.html index 82367d67da..2348768d32 100644 --- a/dev/advanced_concepts/Lossless_DC_power_flow/index.html +++ b/dev/advanced_concepts/Lossless_DC_power_flow/index.html @@ -1,2 +1,2 @@ -Lossless nodal DC power flows · SpineOpt.jl
GitHub

Lossless nodal DC power flows

Currently, there are two different methods to represent lossless DC power flows. In the following the implementation of the nodal model is presented, based of node voltage angles.

Key concepts

In the following, it is described how to set up a connection in order to represent a nodal lossless DC power flow network. Therefore, key object - and relationship classes as well as parameters are introduced.

  1. connection: A connection represents the electricity line being modelled. A physical property of a connection is its connection_reactance, which is defined on the connection object. Furthermore, if the reactance is given in a p.u. different from the standard unit used (e.g. p.u. = 100MVA), the parameter connection_reactance_base can be used to perform this conversion.
  2. node: In a lossless DC power flow model, nodes correspond to buses. To use voltage angles for the representation of a lossless DC model, the has_voltage_angle needs to be true for these nodes (which will trigger the generation of the node_voltage_angle variable). Limits on the voltage angle can be enforced through the max_voltage_angle and min_voltage_angle parameters. The reference node of the system should have a voltage angle equal to zero, assigned through the parameter fix_node_voltage_angle.
  3. connection__to_node and connection__from_node : These relationships need to be introduced between the connection and each node, in order to allow power flows (i.e. connection_flow). Furthermore, a capacity limit on the connection line can be introduced on these relationships through the parameter connection_capacity.
  4. connection__node__node: To ensure energy conservation across the power line, a fixed ratio between incoming and outgoing flows should be given. The fix_ratio_out_in_connection_flow parameter enforces a fixed ratio between outgoing flows (i.e. to_node) and incoming flows (i.e. from_node). This parameter should be defined for both flow direction.

The mathematical formulation of the lossless DC power flow model using voltage angles is fully described here.

+Lossless nodal DC power flows · SpineOpt.jl
GitHub

Lossless nodal DC power flows

Currently, there are two different methods to represent lossless DC power flows. In the following the implementation of the nodal model is presented, based of node voltage angles.

Key concepts

In the following, it is described how to set up a connection in order to represent a nodal lossless DC power flow network. Therefore, key object - and relationship classes as well as parameters are introduced.

  1. connection: A connection represents the electricity line being modelled. A physical property of a connection is its connection_reactance, which is defined on the connection object. Furthermore, if the reactance is given in a p.u. different from the standard unit used (e.g. p.u. = 100MVA), the parameter connection_reactance_base can be used to perform this conversion.
  2. node: In a lossless DC power flow model, nodes correspond to buses. To use voltage angles for the representation of a lossless DC model, the has_voltage_angle needs to be true for these nodes (which will trigger the generation of the node_voltage_angle variable). Limits on the voltage angle can be enforced through the max_voltage_angle and min_voltage_angle parameters. The reference node of the system should have a voltage angle equal to zero, assigned through the parameter fix_node_voltage_angle.
  3. connection__to_node and connection__from_node : These relationships need to be introduced between the connection and each node, in order to allow power flows (i.e. connection_flow). Furthermore, a capacity limit on the connection line can be introduced on these relationships through the parameter connection_capacity.
  4. connection__node__node: To ensure energy conservation across the power line, a fixed ratio between incoming and outgoing flows should be given. The fix_ratio_out_in_connection_flow parameter enforces a fixed ratio between outgoing flows (i.e. to_node) and incoming flows (i.e. from_node). This parameter should be defined for both flow direction.

The mathematical formulation of the lossless DC power flow model using voltage angles is fully described here.

diff --git a/dev/advanced_concepts/cumulated_flow_restrictions/index.html b/dev/advanced_concepts/cumulated_flow_restrictions/index.html index 00c932141f..93682567d4 100644 --- a/dev/advanced_concepts/cumulated_flow_restrictions/index.html +++ b/dev/advanced_concepts/cumulated_flow_restrictions/index.html @@ -1,2 +1,2 @@ -Imposing renewable energy targets · SpineOpt.jl
GitHub

Imposing renewable energy targets

This advanced concept illustrates how renewable targets can be realized in SpineOpt.

Imposing lower limits on renewable production

Imposing a lower bound on the cumulated flow of a unit group by an absolute value

In the current landscape of energy systems modeling, especially in investment models, it is a common idea to implement a lower limit on the amount of electricity that is generated by renewable sources. SpineOpt allows the user to implement such restrictions by means of the min_total_cumulated_unit_flow_to_node parameter. Which will trigger the creation of the constraint_total_cumulated_unit_flow.

To impose a limit on overall renewable generation over the entire optimization horizon, the following objects, relationships, and parameters are relevant:

  1. unit: In this case, a unit represents a process (e.g. electricity generation from wind), where one

or multiple unit_flows are associated with renewable generation

  1. node: Besides from nodes required to denote e.g. a fuel node or a supply node, at least one node should be introduced representing electricity demand. (Note: To distinguish e.g. between regions there can also be more than one electricity node)
  2. unit__to_node: To associate electricity flows with a unit, the relationship between the unit and the electricity node needs to be imposed, to trigger the generation of a electricity-unit_flow variable.
  3. min_total_cumulated_unit_flow_to_node: This parameter triggers a lower bound on all cumulated flows from a unit (or a group of units), e.g. the group of all renewable generators, to a node (or node group).

Let's take a look at a simple example to see how this works. Suppose that we have a system with only one node, which represents the demand for electricity, and two units: a wind farm, and a conventional gas unit. To connect the wind farm to the electricity node, the unit__to_node relationship has to be defined.

One can then simply define the min_total_cumulated_unit_flow_to_node parameter for the 'windfarm__toelectricity_node' relationship to impose a lower bound on the total generation origination from the wind farm.

Note that the value of this parameter is expected to be given as an absolute value, thus care has to be taken to make sure that the units match with the ones used for the unit_flow variable.

The main source of flexibility in the use of this constraint lies in the possibility to define the parameter for relationships that link 'nodegroups' and/or 'unitgroups'. For example, by grouping multiple units that are considered renewable sources (e.g. PV, and wind), targets can be implemented across multiple renewable sources. Similarly, by defining multiple electricity nodes, generation targets can be spatially disagreggated.

Limiting the cumulated flow of a unit group by a share of the demand

For convenience, we want to be able to define the min_total_cumulated_unit_flow_to_node, when used to set a renewable target, as a share of the demand. At the moment an absolute lower bound needs to be provided by the user, but we want to automate this preprocessing in SpineOpt. (to be implemented)

Imposing an upper limit on carbon emissions

Imposing an upper limit on carbon emissions over the entire optimization horizon

To impose a limit on overall carbon emissions over the entire optimization horizon, the following objects, relationships and parameters are relevant:

  1. unit: In this case, a unit represents a process (e.g. conversion of Gas to Electricity), where one

or multiple unit_flows are associated with carbon emissions

  1. node: Besides from nodes required to denote e.g. a fuel node or a supply node, at least one node should be introduced representing carbon emissions. (Note: To distinguish e.g. between regions there can also be more than one carbon node)
  2. unit__to_node: To associate carbon flows with a unit, the relationship between the unit and the carbon node needs to be imposed, to trigger the generation of a carbon-unit_flow variable.
  3. unit__node__node and **fix_ratio_out_out **: Ratio between e.g. output and output unit flows; e.g. how carbon intensive an electricity flow of a unit is. The parameter is defined on a unit__node__node relationship, for example (gasplant, Carbon, Electricity). (Note: For a full list of possible ratios, see also unit__node__node and associated parameters)
  4. max_total_cumulated_unit_flow_to_node (and unit__to_node): This parameter triggers a limit on all flows from a unit (or a group of units), e.g. the group of all conventional generators, to a node (or node groups), e.g. considering the atmosphere as a fictive CO2 node, over the entire modelling horizon (e.g. a carbon budget). For example this could be defined on a relationship between a gasplant and a Carbon node, but can also be defined a unit group of all conventional generators and a carbon node. See also: constraint_total_cumulated_unit_flow

Imposing an upper bound on the cumulated flows of a unit group for a specific period of time (advanced method)

If the desired functionality is not to cap emissions over the entire modelling horizon, but rather for specific periods of time (e.g., to impose decreasing carbon caps over time), an alternative method can be used, which will be described in the following.

To illustrate this functionality, we will assume that there is a ficticious cap of 100 for a period of time 2025-2030, and a cap of 50 for the period of time 2030-2035. In this simple example, we will assume that one carbon-emitting unit carbon_unit is present with two outgoing commodity flows, e.g. here electricity and carbon.

Three nodes are required to represent this system: an electricity node, a carbon_cap_1 node (with has_state=true and node_state_cap=100), and a carbon_cap_2 node (with has_state=true and node_state_cap=50).

Further we introduce the unit__node__node relationships between carbon_unit__carbon_cap1__electricity and carbon_unit__carbon_cap2__electricity. On these relationships, we will define the ratio between emissions and electricity production. In this fictious example, we will assume 0.5 units of emissions per unit of electricity.

The fix_ratio_out_out parameter will now be defined as a time varying parameter in the following way (simplified representation of TimeSeries parameter):

fix_ratio_out_out(carbon_unit__carbon_cap1__electricity) = [2025: 0.5; 2030: 0] fix_ratio_out_out(carbon_unit__carbon_cap2__electricity) = [2025: 0; 2030: 0.5]

This way the first emission-cap node carbon_cap1 can only be "filled" during the 2025-2030, while carbon_cap2 can only be "filled" during the second period 2030-2035.

Note that it would also be possible to have, e.g., one node with time-varying node_state_cap. However, in this case, "unused" carbon emissions in the first period of time would be availble for the second period of time.

Imposing a carbon tax

To include carbon pricing in a model, the following objects, relationships and parameters are relevant:

  1. unit: In this case, a unit represents a process (e.g. conversion of Gas to Electricity), where one

or multiple unit_flows are associated with carbon emissions

  1. node and tax_in_unit_flow: Besides from nodes required to denote e.g. a fuel node or a supply node, at least one node should be introduced representing carbon emissions. To associate a carbon-tax with all incoming unit_flows, the tax_in_unit_flow parameter can be defined on this node (Note: To distinguish e.g. between regions there can also be more than one carbon node)
  2. unit__to_node: To associate carbon flows with a unit, the relationship between the unit and the carbon node needs to be imposed, to trigger the generation of a carbon-unit_flow variable.
  3. unit__node__node and **fix_ratio_out_out **: Ratio between e.g. output and output unit flows; e.g. how carbon intensive an electricity flow of a unit is. The parameter is defined on a unit__node__node relationship, for example (Gasplant, Carbon, Electricity). (Note: For a full list of possible ratios, see also unit__node__node and associated parameters)
+Imposing renewable energy targets · SpineOpt.jl
GitHub

Imposing renewable energy targets

This advanced concept illustrates how renewable targets can be realized in SpineOpt.

Imposing lower limits on renewable production

Imposing a lower bound on the cumulated flow of a unit group by an absolute value

In the current landscape of energy systems modeling, especially in investment models, it is a common idea to implement a lower limit on the amount of electricity that is generated by renewable sources. SpineOpt allows the user to implement such restrictions by means of the min_total_cumulated_unit_flow_to_node parameter. Which will trigger the creation of the constraint_total_cumulated_unit_flow.

To impose a limit on overall renewable generation over the entire optimization horizon, the following objects, relationships, and parameters are relevant:

  1. unit: In this case, a unit represents a process (e.g. electricity generation from wind), where one

or multiple unit_flows are associated with renewable generation

  1. node: Besides from nodes required to denote e.g. a fuel node or a supply node, at least one node should be introduced representing electricity demand. (Note: To distinguish e.g. between regions there can also be more than one electricity node)
  2. unit__to_node: To associate electricity flows with a unit, the relationship between the unit and the electricity node needs to be imposed, to trigger the generation of a electricity-unit_flow variable.
  3. min_total_cumulated_unit_flow_to_node: This parameter triggers a lower bound on all cumulated flows from a unit (or a group of units), e.g. the group of all renewable generators, to a node (or node group).

Let's take a look at a simple example to see how this works. Suppose that we have a system with only one node, which represents the demand for electricity, and two units: a wind farm, and a conventional gas unit. To connect the wind farm to the electricity node, the unit__to_node relationship has to be defined.

One can then simply define the min_total_cumulated_unit_flow_to_node parameter for the 'windfarm__toelectricity_node' relationship to impose a lower bound on the total generation origination from the wind farm.

Note that the value of this parameter is expected to be given as an absolute value, thus care has to be taken to make sure that the units match with the ones used for the unit_flow variable.

The main source of flexibility in the use of this constraint lies in the possibility to define the parameter for relationships that link 'nodegroups' and/or 'unitgroups'. For example, by grouping multiple units that are considered renewable sources (e.g. PV, and wind), targets can be implemented across multiple renewable sources. Similarly, by defining multiple electricity nodes, generation targets can be spatially disagreggated.

Limiting the cumulated flow of a unit group by a share of the demand

For convenience, we want to be able to define the min_total_cumulated_unit_flow_to_node, when used to set a renewable target, as a share of the demand. At the moment an absolute lower bound needs to be provided by the user, but we want to automate this preprocessing in SpineOpt. (to be implemented)

Imposing an upper limit on carbon emissions

Imposing an upper limit on carbon emissions over the entire optimization horizon

To impose a limit on overall carbon emissions over the entire optimization horizon, the following objects, relationships and parameters are relevant:

  1. unit: In this case, a unit represents a process (e.g. conversion of Gas to Electricity), where one

or multiple unit_flows are associated with carbon emissions

  1. node: Besides from nodes required to denote e.g. a fuel node or a supply node, at least one node should be introduced representing carbon emissions. (Note: To distinguish e.g. between regions there can also be more than one carbon node)
  2. unit__to_node: To associate carbon flows with a unit, the relationship between the unit and the carbon node needs to be imposed, to trigger the generation of a carbon-unit_flow variable.
  3. unit__node__node and **fix_ratio_out_out **: Ratio between e.g. output and output unit flows; e.g. how carbon intensive an electricity flow of a unit is. The parameter is defined on a unit__node__node relationship, for example (gasplant, Carbon, Electricity). (Note: For a full list of possible ratios, see also unit__node__node and associated parameters)
  4. max_total_cumulated_unit_flow_to_node (and unit__to_node): This parameter triggers a limit on all flows from a unit (or a group of units), e.g. the group of all conventional generators, to a node (or node groups), e.g. considering the atmosphere as a fictive CO2 node, over the entire modelling horizon (e.g. a carbon budget). For example this could be defined on a relationship between a gasplant and a Carbon node, but can also be defined a unit group of all conventional generators and a carbon node. See also: constraint_total_cumulated_unit_flow

Imposing an upper bound on the cumulated flows of a unit group for a specific period of time (advanced method)

If the desired functionality is not to cap emissions over the entire modelling horizon, but rather for specific periods of time (e.g., to impose decreasing carbon caps over time), an alternative method can be used, which will be described in the following.

To illustrate this functionality, we will assume that there is a ficticious cap of 100 for a period of time 2025-2030, and a cap of 50 for the period of time 2030-2035. In this simple example, we will assume that one carbon-emitting unit carbon_unit is present with two outgoing commodity flows, e.g. here electricity and carbon.

Three nodes are required to represent this system: an electricity node, a carbon_cap_1 node (with has_state=true and node_state_cap=100), and a carbon_cap_2 node (with has_state=true and node_state_cap=50).

Further we introduce the unit__node__node relationships between carbon_unit__carbon_cap1__electricity and carbon_unit__carbon_cap2__electricity. On these relationships, we will define the ratio between emissions and electricity production. In this fictious example, we will assume 0.5 units of emissions per unit of electricity.

The fix_ratio_out_out parameter will now be defined as a time varying parameter in the following way (simplified representation of TimeSeries parameter):

fix_ratio_out_out(carbon_unit__carbon_cap1__electricity) = [2025: 0.5; 2030: 0] fix_ratio_out_out(carbon_unit__carbon_cap2__electricity) = [2025: 0; 2030: 0.5]

This way the first emission-cap node carbon_cap1 can only be "filled" during the 2025-2030, while carbon_cap2 can only be "filled" during the second period 2030-2035.

Note that it would also be possible to have, e.g., one node with time-varying node_state_cap. However, in this case, "unused" carbon emissions in the first period of time would be availble for the second period of time.

Imposing a carbon tax

To include carbon pricing in a model, the following objects, relationships and parameters are relevant:

  1. unit: In this case, a unit represents a process (e.g. conversion of Gas to Electricity), where one

or multiple unit_flows are associated with carbon emissions

  1. node and tax_in_unit_flow: Besides from nodes required to denote e.g. a fuel node or a supply node, at least one node should be introduced representing carbon emissions. To associate a carbon-tax with all incoming unit_flows, the tax_in_unit_flow parameter can be defined on this node (Note: To distinguish e.g. between regions there can also be more than one carbon node)
  2. unit__to_node: To associate carbon flows with a unit, the relationship between the unit and the carbon node needs to be imposed, to trigger the generation of a carbon-unit_flow variable.
  3. unit__node__node and **fix_ratio_out_out **: Ratio between e.g. output and output unit flows; e.g. how carbon intensive an electricity flow of a unit is. The parameter is defined on a unit__node__node relationship, for example (Gasplant, Carbon, Electricity). (Note: For a full list of possible ratios, see also unit__node__node and associated parameters)
diff --git a/dev/advanced_concepts/decomposition/index.html b/dev/advanced_concepts/decomposition/index.html index e1a86af68a..3107cf6993 100644 --- a/dev/advanced_concepts/decomposition/index.html +++ b/dev/advanced_concepts/decomposition/index.html @@ -1,2 +1,2 @@ -Decomposition · SpineOpt.jl
GitHub

Decomposition

Decomposition approaches take advantage of certain problem structures to separate them into multiple related problems which are each more easily solved. Decomposition also allows us to do the inverse, which is to combine independent problems into a single problem, where each can be solved separately but with communication between them (e.g. investments and operations problems)

Decomposition thus allows us to do a number of things

  • Solve larger problems which are otherwise intractable
  • Include more detail in problems which otherwise need to be simplified
  • Combine related problems (e.g. investments/operations) in a more scientific way (rather than ad-hoc).
  • Employ parallel computing methods to solve multiple problems simultaneously.

High-level Decomposition Algorithm

The high-level algorithm is described below. For a more detailed description please see Benders decomposition

  • Model initialisation (preprocessdatastructure, generate temporal structures etc.)
  • For each benders_iteration
    • Solve master problem
    • Process master-problem solution:
      • set units_invested_bi(unit=u) equal to the investment variables solution from the master problem
    • Solve operations problem loop
    • Process operations sub-problem
      • set units_on_mv(unit=u) equal to the marginal value of the units_on bound constraint
    • Test for convergence
    • Update master problem
    • Rewind operations problem
    • Next benders iteration

Duals and reduced costs calculation for decomposition

The marginal values above are computed as the reduced costs of relevant optimisation variables. However, the dual solution to a MIP problem is not well defined. The standard approach to obtaining marginal values from a MIP model is to relax the integer variables, fix them to their last solution value and re-solve the problem as an LP. This is the standard approach in energy system modelling to obtain energy prices. However, although this is the standard approach, it does need to be used with caution. The main hazard associated with inferring duals in this way is that the impact on costs of an investment may be overstated. However, since these duals are used in Benders decomposition to obtain a lower bound on costs (i.e. the maximum potential value from an investment), this is ok and can be "corrected" in the next iteration. And finally, the benders gap will tell us how close our decomposed problem is to the optimal global solution.

Reporting dual values and reduced costs

To report the dual of a constraint, one can add an output item with the corresponding constraint name (e.g. constraint_nodal_balance) and add that to a report. This will cause the corresponding constraint's relaxed problem marginal value will be reported in the output DB. When adding a constraint name as an output we need to preface the actual constraint name with constraint_ to avoid ambiguity with variable names (e.g. units_available). So to report the marginal value of units_available we add an output object called constraint_units_available.

To report the reduced cost for a variable which is the marginal value of the associated active bound or fix constraints on that variable, one can add an output object with the variable name prepended by bound_. So, to report the unitson reducedcost value, one would create an output item called bound_units_on. If added to a report, this will cause the reduced cost of units_on in the final fixed LP to be written to the output db.

Using Decomposition

Assuming one has set up a conventional investments problem as described in Investment Optimization the following additional steps are required to utilise the decomposition framework:

  • Set the model_type parameter for your model to spineopt_benders.
  • Specify max_gap parameter for your model - This determines the master problem convergence criterion for the relative benders gap. A value of 0.05 will represent a relative benders gap of 5%.
  • Specify the max_iterations parameter for your model - This determines the master problem convergence criterion for the number of iterations. A value of 10 could be appropriate but this is highly dependent on the size and nature of the problem.

Once the above is set, all investment decisions in the model are automatically decomposed and optimised in a Benders master problem. This behaviour may change in the future to allow some investment decisions to be optimised in the operations problem and some optimised in the master problem as desired.

+Decomposition · SpineOpt.jl
GitHub

Decomposition

Decomposition approaches take advantage of certain problem structures to separate them into multiple related problems which are each more easily solved. Decomposition also allows us to do the inverse, which is to combine independent problems into a single problem, where each can be solved separately but with communication between them (e.g. investments and operations problems)

Decomposition thus allows us to do a number of things

  • Solve larger problems which are otherwise intractable
  • Include more detail in problems which otherwise need to be simplified
  • Combine related problems (e.g. investments/operations) in a more scientific way (rather than ad-hoc).
  • Employ parallel computing methods to solve multiple problems simultaneously.

High-level Decomposition Algorithm

The high-level algorithm is described below. For a more detailed description please see Benders decomposition

  • Model initialisation (preprocessdatastructure, generate temporal structures etc.)
  • For each benders_iteration
    • Solve master problem
    • Process master-problem solution:
      • set units_invested_bi(unit=u) equal to the investment variables solution from the master problem
    • Solve operations problem loop
    • Process operations sub-problem
      • set units_on_mv(unit=u) equal to the marginal value of the units_on bound constraint
    • Test for convergence
    • Update master problem
    • Rewind operations problem
    • Next benders iteration

Duals and reduced costs calculation for decomposition

The marginal values above are computed as the reduced costs of relevant optimisation variables. However, the dual solution to a MIP problem is not well defined. The standard approach to obtaining marginal values from a MIP model is to relax the integer variables, fix them to their last solution value and re-solve the problem as an LP. This is the standard approach in energy system modelling to obtain energy prices. However, although this is the standard approach, it does need to be used with caution. The main hazard associated with inferring duals in this way is that the impact on costs of an investment may be overstated. However, since these duals are used in Benders decomposition to obtain a lower bound on costs (i.e. the maximum potential value from an investment), this is ok and can be "corrected" in the next iteration. And finally, the benders gap will tell us how close our decomposed problem is to the optimal global solution.

Reporting dual values and reduced costs

To report the dual of a constraint, one can add an output item with the corresponding constraint name (e.g. constraint_nodal_balance) and add that to a report. This will cause the corresponding constraint's relaxed problem marginal value will be reported in the output DB. When adding a constraint name as an output we need to preface the actual constraint name with constraint_ to avoid ambiguity with variable names (e.g. units_available). So to report the marginal value of units_available we add an output object called constraint_units_available.

To report the reduced cost for a variable which is the marginal value of the associated active bound or fix constraints on that variable, one can add an output object with the variable name prepended by bound_. So, to report the unitson reducedcost value, one would create an output item called bound_units_on. If added to a report, this will cause the reduced cost of units_on in the final fixed LP to be written to the output db.

Using Decomposition

Assuming one has set up a conventional investments problem as described in Investment Optimization the following additional steps are required to utilise the decomposition framework:

  • Set the model_type parameter for your model to spineopt_benders.
  • Specify max_gap parameter for your model - This determines the master problem convergence criterion for the relative benders gap. A value of 0.05 will represent a relative benders gap of 5%.
  • Specify the max_iterations parameter for your model - This determines the master problem convergence criterion for the number of iterations. A value of 10 could be appropriate but this is highly dependent on the size and nature of the problem.

Once the above is set, all investment decisions in the model are automatically decomposed and optimised in a Benders master problem. This behaviour may change in the future to allow some investment decisions to be optimised in the operations problem and some optimised in the master problem as desired.

diff --git a/dev/advanced_concepts/investment_optimization/index.html b/dev/advanced_concepts/investment_optimization/index.html index 9d8ecbc43b..5d8b640972 100644 --- a/dev/advanced_concepts/investment_optimization/index.html +++ b/dev/advanced_concepts/investment_optimization/index.html @@ -1,2 +1,2 @@ -Investment Optimization · SpineOpt.jl
GitHub

Investment Optimization

SpineOpt offers numerous ways to optimise investment decisions energy system models and in particular, offers a number of methologogies for capturing increased detail in investment models while containing the impact on run time. The basic principles of investments will be discussed first and this will be followed by more advanced approaches.

Key concepts for investments

Investment Decisions These are the investment decisions that SpineOpt currently supports. At a high level, this means that the activity of the entities in question is controlled by an investment decision variable. The current implementation supports investments in :

  • unit
  • connection
  • Storage - Note: while the above investment decisions correspond to an object class (i.e.) an investment in a unit or a connection, Storages are not an object class in themselves and are rather a property of a node. As such, a storage investment controls whether a particular node has a state variable or not.

Investment Variable Types In all cases the capacity of the unit or connection or the maximum node state of a node is multiplied by the investment variable which may either be continuous, binary or integer. This is determined, for units, by setting the unit_investment_variable_type parameter accordingly. Similary, for connections and node storages the connection_investment_variable_type and storage_investment_variable_type are specified.

Identiying Investment Candidate Units, Connections and Storages The parameter candidate_units represents the number of units of this type that may be invested in. candidate_units determines the upper bound of the investment variable and setting this to a value greater than 0 identifies the unit as an investment candidate unit in the optimisation. If the unit_investment_variable_type is set to :variable_type_integer, the investment variable can be interpreted as the number of discrete units that may be invested in. However, if unit_investment_variable_type is :variable_type_continuous and the unit_capacity is set to unity, the investment decision variable can then be interpreted as the capacity of the unit rather than the number of units with candidate_units being the maximum capacity that can be invested in. Finally, we can invest in discrete blocks of capacity by setting unit_capacity to the size of the investment capacity blocks and have unit_investment_variable_type set to :variable_type_integer with candidate_units representing the maximum number of capacity blocks that may be invested in. The key points here are:

Investment Costs Investment costs are specified by setting the appropriate *_investment\_cost parameter. The investment cost for units are specified by setting the unit_investment_cost parameter. This is currently interpreted as the full cost over the investment period for the unit. See the section below on investment temporal structure for setting the investment period. If the investment period is 1 year, then the corresponding unit_investment_cost is the annualised investment cost. For connections and storages, the investment cost parameters are connection_investment_cost and storage_investment_cost, respectively.

Temporal and Stochastic Structure of Investment Decisions SpineOpt's flexible stochastic and temporal structure extend to investments where individual investment decisions can have their own temporal and stochastic structure independent of other investment decisions and other model variables. A global temporal resolution for all investment decisions can be defined by specifying the relationship model__default_investment_temporal_block. If a specific temporal resolution is required for specific investment decisions, then one can specify the following relationships:

Specifying any of the above relationships will override the corresponding model__default_investment_temporal_block.

Similarly, a global stochastic structure can be defined for all investment decisions by specifying the relationship model__default_investment_stochastic_structure. If a specific stochastic structure is required for specific investment decisions, then one can specifying the following relationships:

Specifying any of the above relationships will override the corresponding model__default_investment_stochastic_structure.

Creating an Investment Candidate Unit Example

If we have model that is not currently set up for investments and we wish to create an investment candidate unit, we can take the following steps.

Model Reference

Variables for investments

Variable NameIndicesDescription
units_invested_availableunit, s, tThe number of invested in units that are available at a given (s, t)
units_investedunit, s, tThe point-in-time investment decision corresponding to the number of units invested in at (s,t)
units_mothballedunit, s, t"Instantaneous" decision variable to mothball a unit
connections_invested_availableconnection, s, tThe number of invested-in connectionss that are available at a given (s, t)
connections_investedconnection, s, tThe point-in-time investment decision corresponding to the number of connectionss invested in at (s,t)
connections_decommissionedconnection, s, t"Instantaneous" decision variable to decommission a connection
storages_invested_availablenode, s, tThe number of invested-in storages that are available at a given (s, t)
storages_investednode, s, tThe point-in-time investment decision corresponding to the number of storages invested in at (s,t)
storages_decommissionednode, s, t"instantaneous" decision variable to decommission a storage

Relationships for investments

Relationship NameRelated Object Class ListDescription
model__default_investment_temporal_blockmodel, temporal_blockDefault temporal resolution for investment decisions effective if unit__investmenttemporalblock is not specified
model__default_investment_stochastic_structuremodel, stochastic_structureDefault stochastic structure for investment decisions effective if unit__investmentstochasticstructure is not specified
unit__investment_temporal_blockunit, temporal_blockSet temporal resolution of investment decisions - overrides model__defaultinvestmenttemporal_block
unit__investment_stochastic_structureunit, stochastic_structureSet stochastic structure for investment decisions - overrides model__defaultinvestmentstochastic_structure

Parameters for investments

Parameter NameObject Class ListDescription
candidate_unitsunitThe number of additional units of this type that can be invested in
unit_investment_costunitThe total overnight investment cost per candidate unit over the model horizon
unit_investment_lifetimeunitThe investment lifetime of the unit - once invested-in, a unit must exist for at least this amount of time
unit_investment_variable_typeunitWhether the units_invested_available variable is continuous, integer or binary
fix_units_investedunitFix the value of units_invested
fix_units_invested_availableunitFix the value of connections_invested_available
candidate_connectionsconnectionThe number of additional connections of this type that can be invested in
connection_investment_costconnectionThe total overnight investment cost per candidate connection over the model horizon
connection_investment_lifetimeconnectionThe investment lifetime of the connection - once invested-in, a connection must exist for at least this amount of time
connection_investment_variable_typeconnectionWhether the connections_invested_available variable is continuous, integer or binary
fix_connections_investedconnectionFix the value of connections_invested
fix_connections_invested_availableconnectionFix the value of connection_invested_available
candidate_storagesnodeThe number of additional storages of this type that can be invested in at node
storage_investment_costnodeThe total overnight investment cost per candidate storage over the model horizon
storage_investment_lifetimenodeThe investment lifetime of the storage - once invested-in, a storage must exist for at least this amount of time
storage_investment_variable_typenodeWhether the storages_invested_available variable is continuous, integer or binary
fix_storages_investednodeFix the value of storages_invested
fix_storages_invested_availablenodeFix the value of storages_invested_available
FilenameRelative PathDescription
constraintunitsinvested_available.jl\constraintsconstrains units_invested_available to be less than candidate_units
constraintunitsinvested_transition.jl\constraintsdefines the relationship between units_invested_available, units_invested and units_mothballed. Analagous to units_on, units_started and units_shutdown
constraintunitlifetime.jl\constraintsonce a unit is invested-in, it must remain in existence for at least unit_investment_lifetime - analagous to min_up_time.
constraintunitsavailable.jl\constraintsEnforces units_available is the sum of number_of_units and units_invested_available
constraintconnectionsinvested_available.jl\constraintsconstrains connections_invested_available to be less than candidate_connections
constraintconnectionsinvested_transition.jl\constraintsdefines the relationship between connections_invested_available, connections_invested and connections_decommissioned. Analagous to units_on, units_started and units_shutdown
constraintconnectionlifetime.jl\constraintsonce a connection is invested-in, it must remain in existence for at least connection_investment_lifetime - analagous to min_up_time.
constraintstoragesinvested_available.jl\constraintsconstrains storages_invested_available to be less than candidate_storages
constraintstoragesinvested_transition.jl\constraintsdefines the relationship between storages_invested_available, storages_invested and storages_decommissioned. Analagous to units_on, units_started and units_shutdown
constraintstoragelifetime.jl\constraintsonce a storage is invested-in, it must remain in existence for at least storage_investment_lifetime - analagous to min_up_time.
+Investment Optimization · SpineOpt.jl
GitHub

Investment Optimization

SpineOpt offers numerous ways to optimise investment decisions energy system models and in particular, offers a number of methologogies for capturing increased detail in investment models while containing the impact on run time. The basic principles of investments will be discussed first and this will be followed by more advanced approaches.

Key concepts for investments

Investment Decisions These are the investment decisions that SpineOpt currently supports. At a high level, this means that the activity of the entities in question is controlled by an investment decision variable. The current implementation supports investments in :

  • unit
  • connection
  • Storage - Note: while the above investment decisions correspond to an object class (i.e.) an investment in a unit or a connection, Storages are not an object class in themselves and are rather a property of a node. As such, a storage investment controls whether a particular node has a state variable or not.

Investment Variable Types In all cases the capacity of the unit or connection or the maximum node state of a node is multiplied by the investment variable which may either be continuous, binary or integer. This is determined, for units, by setting the unit_investment_variable_type parameter accordingly. Similary, for connections and node storages the connection_investment_variable_type and storage_investment_variable_type are specified.

Identiying Investment Candidate Units, Connections and Storages The parameter candidate_units represents the number of units of this type that may be invested in. candidate_units determines the upper bound of the investment variable and setting this to a value greater than 0 identifies the unit as an investment candidate unit in the optimisation. If the unit_investment_variable_type is set to :variable_type_integer, the investment variable can be interpreted as the number of discrete units that may be invested in. However, if unit_investment_variable_type is :variable_type_continuous and the unit_capacity is set to unity, the investment decision variable can then be interpreted as the capacity of the unit rather than the number of units with candidate_units being the maximum capacity that can be invested in. Finally, we can invest in discrete blocks of capacity by setting unit_capacity to the size of the investment capacity blocks and have unit_investment_variable_type set to :variable_type_integer with candidate_units representing the maximum number of capacity blocks that may be invested in. The key points here are:

Investment Costs Investment costs are specified by setting the appropriate *_investment\_cost parameter. The investment cost for units are specified by setting the unit_investment_cost parameter. This is currently interpreted as the full cost over the investment period for the unit. See the section below on investment temporal structure for setting the investment period. If the investment period is 1 year, then the corresponding unit_investment_cost is the annualised investment cost. For connections and storages, the investment cost parameters are connection_investment_cost and storage_investment_cost, respectively.

Temporal and Stochastic Structure of Investment Decisions SpineOpt's flexible stochastic and temporal structure extend to investments where individual investment decisions can have their own temporal and stochastic structure independent of other investment decisions and other model variables. A global temporal resolution for all investment decisions can be defined by specifying the relationship model__default_investment_temporal_block. If a specific temporal resolution is required for specific investment decisions, then one can specify the following relationships:

Specifying any of the above relationships will override the corresponding model__default_investment_temporal_block.

Similarly, a global stochastic structure can be defined for all investment decisions by specifying the relationship model__default_investment_stochastic_structure. If a specific stochastic structure is required for specific investment decisions, then one can specifying the following relationships:

Specifying any of the above relationships will override the corresponding model__default_investment_stochastic_structure.

Creating an Investment Candidate Unit Example

If we have model that is not currently set up for investments and we wish to create an investment candidate unit, we can take the following steps.

Model Reference

Variables for investments

Variable NameIndicesDescription
units_invested_availableunit, s, tThe number of invested in units that are available at a given (s, t)
units_investedunit, s, tThe point-in-time investment decision corresponding to the number of units invested in at (s,t)
units_mothballedunit, s, t"Instantaneous" decision variable to mothball a unit
connections_invested_availableconnection, s, tThe number of invested-in connectionss that are available at a given (s, t)
connections_investedconnection, s, tThe point-in-time investment decision corresponding to the number of connectionss invested in at (s,t)
connections_decommissionedconnection, s, t"Instantaneous" decision variable to decommission a connection
storages_invested_availablenode, s, tThe number of invested-in storages that are available at a given (s, t)
storages_investednode, s, tThe point-in-time investment decision corresponding to the number of storages invested in at (s,t)
storages_decommissionednode, s, t"instantaneous" decision variable to decommission a storage

Relationships for investments

Relationship NameRelated Object Class ListDescription
model__default_investment_temporal_blockmodel, temporal_blockDefault temporal resolution for investment decisions effective if unit__investmenttemporalblock is not specified
model__default_investment_stochastic_structuremodel, stochastic_structureDefault stochastic structure for investment decisions effective if unit__investmentstochasticstructure is not specified
unit__investment_temporal_blockunit, temporal_blockSet temporal resolution of investment decisions - overrides model__defaultinvestmenttemporal_block
unit__investment_stochastic_structureunit, stochastic_structureSet stochastic structure for investment decisions - overrides model__defaultinvestmentstochastic_structure

Parameters for investments

Parameter NameObject Class ListDescription
candidate_unitsunitThe number of additional units of this type that can be invested in
unit_investment_costunitThe total overnight investment cost per candidate unit over the model horizon
unit_investment_lifetimeunitThe investment lifetime of the unit - once invested-in, a unit must exist for at least this amount of time
unit_investment_variable_typeunitWhether the units_invested_available variable is continuous, integer or binary
fix_units_investedunitFix the value of units_invested
fix_units_invested_availableunitFix the value of connections_invested_available
candidate_connectionsconnectionThe number of additional connections of this type that can be invested in
connection_investment_costconnectionThe total overnight investment cost per candidate connection over the model horizon
connection_investment_lifetimeconnectionThe investment lifetime of the connection - once invested-in, a connection must exist for at least this amount of time
connection_investment_variable_typeconnectionWhether the connections_invested_available variable is continuous, integer or binary
fix_connections_investedconnectionFix the value of connections_invested
fix_connections_invested_availableconnectionFix the value of connection_invested_available
candidate_storagesnodeThe number of additional storages of this type that can be invested in at node
storage_investment_costnodeThe total overnight investment cost per candidate storage over the model horizon
storage_investment_lifetimenodeThe investment lifetime of the storage - once invested-in, a storage must exist for at least this amount of time
storage_investment_variable_typenodeWhether the storages_invested_available variable is continuous, integer or binary
fix_storages_investednodeFix the value of storages_invested
fix_storages_invested_availablenodeFix the value of storages_invested_available
FilenameRelative PathDescription
constraintunitsinvested_available.jl\constraintsconstrains units_invested_available to be less than candidate_units
constraintunitsinvested_transition.jl\constraintsdefines the relationship between units_invested_available, units_invested and units_mothballed. Analagous to units_on, units_started and units_shutdown
constraintunitlifetime.jl\constraintsonce a unit is invested-in, it must remain in existence for at least unit_investment_lifetime - analagous to min_up_time.
constraintunitsavailable.jl\constraintsEnforces units_available is the sum of number_of_units and units_invested_available
constraintconnectionsinvested_available.jl\constraintsconstrains connections_invested_available to be less than candidate_connections
constraintconnectionsinvested_transition.jl\constraintsdefines the relationship between connections_invested_available, connections_invested and connections_decommissioned. Analagous to units_on, units_started and units_shutdown
constraintconnectionlifetime.jl\constraintsonce a connection is invested-in, it must remain in existence for at least connection_investment_lifetime - analagous to min_up_time.
constraintstoragesinvested_available.jl\constraintsconstrains storages_invested_available to be less than candidate_storages
constraintstoragesinvested_transition.jl\constraintsdefines the relationship between storages_invested_available, storages_invested and storages_decommissioned. Analagous to units_on, units_started and units_shutdown
constraintstoragelifetime.jl\constraintsonce a storage is invested-in, it must remain in existence for at least storage_investment_lifetime - analagous to min_up_time.
diff --git a/dev/advanced_concepts/mga/index.html b/dev/advanced_concepts/mga/index.html index cdf3a0cbae..4ddd131025 100644 --- a/dev/advanced_concepts/mga/index.html +++ b/dev/advanced_concepts/mga/index.html @@ -1,2 +1,2 @@ -Modelling to generate alternatives · SpineOpt.jl
GitHub

Modelling to generate alternatives

Through modelling to generate alternatives (short MGA), near-optimal solutions can be explored under certain conditions. Currently, SpineOpt supports two methods for MGA are available.

Modelling to generate alternative: Maximally different portfolios

The idea is that an orginal problem is solved, and subsequently solved again under the condition that the realization of variables should be maximally different from the previous iteration(s), while keeping the objective function within a certain threshold (defined by max_mga_slack).

In SpineOpt, we choose units_invested_available, connections_invested_available, and storages_invested_available as variables that can be considered for the maximum-difference-problem. The implementation is based on Modelling to generate alternatives: A technique to explore uncertainty in energy-environment-economy models.

How to set up an MGA problem

  • model: In order to explore an MGA model, you will need one model of type spineopt_mga. You should also define the number of iterations (max_mga_iterations, and the maximum allowed deviation from the original objective function (max_mga_slack).
  • at least one investment candidate of type unit, connection, or node. For more details on how to set up an investment problem please see: Investment Optimization.
  • To include the investment decisions in the MGA difference maximization, the parameter units_invested_mga, connections_invested_mga, or storages_invested_mga need to be set to true, respectively.
  • The original MGA formulation is non-convex (maximization problem of an absolute function), but has been linearized through big M method. For this purpose, one should always make sure that units_invested_big_m_mga, connections_invested_big_m_mga, or storages_invested_big_m_mga, respectively, is sufficently large to always be larger the the maximum possible difference per MGA iteration. (Typically the number of candidates could suffice.)
  • As outputs are used to intermediately store solutions from different MGA runs, it is important that units_invested, connections_invested, or storages_invested, respectively, are defined as output objects in your database.

Modelling to generate alternative: Trade-offs between technology investments

The idea of this approach is to explore near-optimal solutions that maximize/minimize investment in a certain technology (or multiple technologies simultanesously).

How to set up an MGA problem

  • model: In order to explore an MGA model, you will need one model of type spineopt_mga. The maximum allowed deviation from the original objective function should be defined via max_mga_slack. Note that for this method, we don't define an explicit number of iteration via the max_mga_iterations parameter (see also below)
  • at least one investment candidate of type unit, connection, or node. For more details on how to set up an investment problem please see: Investment Optimization.
  • To include the investment decisions in the MGA min/maximization, the parameter units_invested_mga, connections_invested_mga, or storages_invested_mga need to be set to true, respectively.
  • To explore near-optimal solutions using this methodology, the units_invested_mga_weight, connections_invested_mga_weight, and storages_invested_mga_weight parameters are used to define near-optimal solutions. For this purpose, these parameters are defined as Arrays, defining the weight of the technology per iterations. Note that the length of these Arrays should be the same for all technologies, as this will correspond to the number of MGA iterations, i.e., the number of near-optimal solutions. To analyze the trade-off between two technology types, we can, e.g., define units_invested_mga_weight for unit group 1 as [-1,-0.5,0], whereas the use the weights [0,-0.5,-1] for the other technology storage group 1 in question. Note that a negative sign will correspond to a minimization of investments in the corresponding technology type, while positive signs correspond to a maximization of the respective technology. In the given example, we would hence first minimize the investments in unit group 1, then minimize the two technologies simultaneuously, and finally only minimize investments in storage group 2.
  • As outputs are used to intermediately store solutions from different MGA runs, it is important that units_invested, connections_invested, or storages_invested, respectively, are defined as output objects in your database.
+Modelling to generate alternatives · SpineOpt.jl
GitHub

Modelling to generate alternatives

Through modelling to generate alternatives (short MGA), near-optimal solutions can be explored under certain conditions. Currently, SpineOpt supports two methods for MGA are available.

Modelling to generate alternative: Maximally different portfolios

The idea is that an orginal problem is solved, and subsequently solved again under the condition that the realization of variables should be maximally different from the previous iteration(s), while keeping the objective function within a certain threshold (defined by max_mga_slack).

In SpineOpt, we choose units_invested_available, connections_invested_available, and storages_invested_available as variables that can be considered for the maximum-difference-problem. The implementation is based on Modelling to generate alternatives: A technique to explore uncertainty in energy-environment-economy models.

How to set up an MGA problem

  • model: In order to explore an MGA model, you will need one model of type spineopt_mga. You should also define the number of iterations (max_mga_iterations, and the maximum allowed deviation from the original objective function (max_mga_slack).
  • at least one investment candidate of type unit, connection, or node. For more details on how to set up an investment problem please see: Investment Optimization.
  • To include the investment decisions in the MGA difference maximization, the parameter units_invested_mga, connections_invested_mga, or storages_invested_mga need to be set to true, respectively.
  • The original MGA formulation is non-convex (maximization problem of an absolute function), but has been linearized through big M method. For this purpose, one should always make sure that units_invested_big_m_mga, connections_invested_big_m_mga, or storages_invested_big_m_mga, respectively, is sufficently large to always be larger the the maximum possible difference per MGA iteration. (Typically the number of candidates could suffice.)
  • As outputs are used to intermediately store solutions from different MGA runs, it is important that units_invested, connections_invested, or storages_invested, respectively, are defined as output objects in your database.

Modelling to generate alternative: Trade-offs between technology investments

The idea of this approach is to explore near-optimal solutions that maximize/minimize investment in a certain technology (or multiple technologies simultanesously).

How to set up an MGA problem

  • model: In order to explore an MGA model, you will need one model of type spineopt_mga. The maximum allowed deviation from the original objective function should be defined via max_mga_slack. Note that for this method, we don't define an explicit number of iteration via the max_mga_iterations parameter (see also below)
  • at least one investment candidate of type unit, connection, or node. For more details on how to set up an investment problem please see: Investment Optimization.
  • To include the investment decisions in the MGA min/maximization, the parameter units_invested_mga, connections_invested_mga, or storages_invested_mga need to be set to true, respectively.
  • To explore near-optimal solutions using this methodology, the units_invested_mga_weight, connections_invested_mga_weight, and storages_invested_mga_weight parameters are used to define near-optimal solutions. For this purpose, these parameters are defined as Arrays, defining the weight of the technology per iterations. Note that the length of these Arrays should be the same for all technologies, as this will correspond to the number of MGA iterations, i.e., the number of near-optimal solutions. To analyze the trade-off between two technology types, we can, e.g., define units_invested_mga_weight for unit group 1 as [-1,-0.5,0], whereas the use the weights [0,-0.5,-1] for the other technology storage group 1 in question. Note that a negative sign will correspond to a minimization of investments in the corresponding technology type, while positive signs correspond to a maximization of the respective technology. In the given example, we would hence first minimize the investments in unit group 1, then minimize the two technologies simultaneuously, and finally only minimize investments in storage group 2.
  • As outputs are used to intermediately store solutions from different MGA runs, it is important that units_invested, connections_invested, or storages_invested, respectively, are defined as output objects in your database.
diff --git a/dev/advanced_concepts/powerflow/index.html b/dev/advanced_concepts/powerflow/index.html index 591466f16c..1428574db5 100644 --- a/dev/advanced_concepts/powerflow/index.html +++ b/dev/advanced_concepts/powerflow/index.html @@ -1,2 +1,2 @@ -PTDF-Based Powerflow · SpineOpt.jl
GitHub

Power transfer distribution factors (PTDF) based DC power flow

There are two main methodologies for directly including DC powerflow in unit commitment/energy system models. One method is to directly include the bus voltage angles as variables in the model. This method is described in Nodal lossless DC Powerflow.

Here we discuss the method of using power transfer distribution factors (PTDF) for DC power flow and line outage distribution factors (lodf) for security constrained unit commitment.

Key concepts

  1. ptdf: The power transfer distribution factors are a property of the network reactances and their derivation may be found here. ptdf(n, c) represents the fraction of an injection at node n that will flow on connection c. The flow on connection c is then the sum over all nodes of ptdf(n, c)*net_injection(c). The advantage of this method is that it introduces no additional variables into the problem and instead, introduces only one constraint for each connection whose flow we are interested in monitoring.
  2. lodf: Line outage distribution factors are a function of the network ptdfs and their derivation is also found here. lodf(c_contingency, c_monitored) represents the fraction of the pre-contingency flow on connection c_contingency that will flow on c_monitored if c_contingency is disconnected. Therefore, the post contingency flow on connection c_monitored is the pre_contingency flow plus lodf(c_contingency, c_monitored)\*pre_contingency_flow(c_contingency)). Therefore, consideration of N contingencies on M monitored lines introduces N x M constraints into the model. Usually one wishes to contain this number and methods are given below to achieve this.
  3. Defining your network To identify the network for which ptdfs, lodfs and connection_flows will be calculated according to the ptdf method, one does the following:
    • Create node objects for each bus in the model.
    • Create connection objects representing each line of the network: For each connection specify the connection_reactance parameter and the connection_type parameter. Setting connection_type=connection_type_lossless_bidirectional simplifies the amount of data that needs to be specified for an eletrical network. See connection_type for more details
    • Set the connection__to_node and connection__from_node relationships to define the topology of each connection along with the connection_capacity parameter on one or both of these relationships.
    • Set the connection_emergency_capacity parameter to define the post contingency rating if lodf-based N-1 security constraints are to be included
    • Create a commodity object and node__commodity relationships for all the nodes that comprise the electrical network for which PTDFs are to be calculated.
    • Specify the commodity_physics parameter for the commodity to :commodity_physics_ptdf if ptdf-based DC load flow is desired with no N-1 security constraints or to :commodity_physics_lodf if it is desired to include lodf-based N-1 security constraints
    • To identify the reference bus(node) specify the node_opf_type parameter for the appropriate node with the value node_opf_type_reference.
  4. Controlling problem size
    • The lines to be monitored are specified by setting the connection_monitored property for each connection for which a flow constraint is to be generated
    • The contingencies to be considered are specified by setting the connection_contingency property for the appropriate connections. For N contingencies and M monitored lines, N x M constraints will be generated.
    • If the lodf(c_contingency, c_monitored) is very small, it means the outage of c_contingency has a small impact on the flow on c_monitoredand there is little point in including this constraint in the model. This can be achieved by setting the commodity_lodf_tolerance commodity parameter. Contingency / Monotired line combinations with lodfs below this value will be ignored, reducing the size of the model.
    • If ptdf(n, c) is very small, it means an injection at n has a small impact on the flow on c and there is little point in considering it. This can be achieved by setting the commodity_ptdf_threshold commodity parameter. Node / Monotired line combinations with ptdfs below this value will be ignored, reducing the number of coefficients in the model.
    • To more easily identify which connections are worth being monitored or which contingencies are worth being considered, you can add the contingency_is_binding output to any of your reports (via a report__output relationship). This will run the model without the security constraints, and instead write a parameter called contingency_is_binding to the output database for each pair of contingency and monitored connection. The value of the parameter will be a (possibly stochastic) time-series where a value of one will indicate that the corresponding security constraint is binding, and zero otherwise.
+PTDF-Based Powerflow · SpineOpt.jl
GitHub

Power transfer distribution factors (PTDF) based DC power flow

There are two main methodologies for directly including DC powerflow in unit commitment/energy system models. One method is to directly include the bus voltage angles as variables in the model. This method is described in Nodal lossless DC Powerflow.

Here we discuss the method of using power transfer distribution factors (PTDF) for DC power flow and line outage distribution factors (lodf) for security constrained unit commitment.

Key concepts

  1. ptdf: The power transfer distribution factors are a property of the network reactances and their derivation may be found here. ptdf(n, c) represents the fraction of an injection at node n that will flow on connection c. The flow on connection c is then the sum over all nodes of ptdf(n, c)*net_injection(c). The advantage of this method is that it introduces no additional variables into the problem and instead, introduces only one constraint for each connection whose flow we are interested in monitoring.
  2. lodf: Line outage distribution factors are a function of the network ptdfs and their derivation is also found here. lodf(c_contingency, c_monitored) represents the fraction of the pre-contingency flow on connection c_contingency that will flow on c_monitored if c_contingency is disconnected. Therefore, the post contingency flow on connection c_monitored is the pre_contingency flow plus lodf(c_contingency, c_monitored)\*pre_contingency_flow(c_contingency)). Therefore, consideration of N contingencies on M monitored lines introduces N x M constraints into the model. Usually one wishes to contain this number and methods are given below to achieve this.
  3. Defining your network To identify the network for which ptdfs, lodfs and connection_flows will be calculated according to the ptdf method, one does the following:
    • Create node objects for each bus in the model.
    • Create connection objects representing each line of the network: For each connection specify the connection_reactance parameter and the connection_type parameter. Setting connection_type=connection_type_lossless_bidirectional simplifies the amount of data that needs to be specified for an eletrical network. See connection_type for more details
    • Set the connection__to_node and connection__from_node relationships to define the topology of each connection along with the connection_capacity parameter on one or both of these relationships.
    • Set the connection_emergency_capacity parameter to define the post contingency rating if lodf-based N-1 security constraints are to be included
    • Create a commodity object and node__commodity relationships for all the nodes that comprise the electrical network for which PTDFs are to be calculated.
    • Specify the commodity_physics parameter for the commodity to :commodity_physics_ptdf if ptdf-based DC load flow is desired with no N-1 security constraints or to :commodity_physics_lodf if it is desired to include lodf-based N-1 security constraints
    • To identify the reference bus(node) specify the node_opf_type parameter for the appropriate node with the value node_opf_type_reference.
  4. Controlling problem size
    • The lines to be monitored are specified by setting the connection_monitored property for each connection for which a flow constraint is to be generated
    • The contingencies to be considered are specified by setting the connection_contingency property for the appropriate connections. For N contingencies and M monitored lines, N x M constraints will be generated.
    • If the lodf(c_contingency, c_monitored) is very small, it means the outage of c_contingency has a small impact on the flow on c_monitoredand there is little point in including this constraint in the model. This can be achieved by setting the commodity_lodf_tolerance commodity parameter. Contingency / Monotired line combinations with lodfs below this value will be ignored, reducing the size of the model.
    • If ptdf(n, c) is very small, it means an injection at n has a small impact on the flow on c and there is little point in considering it. This can be achieved by setting the commodity_ptdf_threshold commodity parameter. Node / Monotired line combinations with ptdfs below this value will be ignored, reducing the number of coefficients in the model.
    • To more easily identify which connections are worth being monitored or which contingencies are worth being considered, you can add the contingency_is_binding output to any of your reports (via a report__output relationship). This will run the model without the security constraints, and instead write a parameter called contingency_is_binding to the output database for each pair of contingency and monitored connection. The value of the parameter will be a (possibly stochastic) time-series where a value of one will indicate that the corresponding security constraint is binding, and zero otherwise.
diff --git a/dev/advanced_concepts/pressure_driven_gas_transfer/index.html b/dev/advanced_concepts/pressure_driven_gas_transfer/index.html index 820d0bb009..52ff6fb724 100644 --- a/dev/advanced_concepts/pressure_driven_gas_transfer/index.html +++ b/dev/advanced_concepts/pressure_driven_gas_transfer/index.html @@ -1,2 +1,2 @@ -Pressure driven gas transfer · SpineOpt.jl
GitHub

Pressure driven gas transfer

The generic formulation of SpineOpt is based on a trade based model. However, network physics can be different depending on the traded commodity. This chapter specifically addresses the use of pressure driven gas transfer models and enabling linepack flexibility in SpineOpt. To this date, investments in pressure driven pipelines are not yet supported within SpineOpt. The use of multiple feed-in nodes, e.g. to represent multiple commodity flows through a pipeline is not yet supported.

For the representation of pressure driven gas transfer, we use the MILP formulation, as described in Schwele - Coordination of Power and Natural Gas Systems: Convexification Approaches for Linepack Modeling. Here, the non-linearities associated with the Weymouth equation are convexified through an outer approximation of the Weymouth equation through fixed pressure points.

Key concept

Here, we briefly describe the key objects and relationships required to model pressure driven gas transfers in SpineOpt.

  1. connection: A connection represents the gas pipeline being modelled. Usually the direction of flow is not known a priory. To ensure that the flow through the gas pipeline is unidirectional, the parameter has_binary_gas_flow needs to be set to true.
  2. node: Nodes with different characteristics are used for the representation of pressure driven gas transfer.
    • For each connection, there will be two nodes representing the start and end point of the pipeline. Associated with these nodes are the following parameters: the has_pressure parameter, which needs to be set to true, in order to create the variable node_pressure; the max_node_pressure and min_node_pressure to constrain the pressure variable.
    • To leverage linepack flexibility, a third node is introduced representing the linepack storage of the pipeline. To trigger the storage linepack and hence, node_state variables, the has_state parameter needs to be set to true.
  3. connection__to_node and connection__from_node To enable flows through the pipeline and into the linepack storage, each node has to have both these relationships in common with the connection pipeline. These relationships will trigger the generation of connection_flow variables in all possible directions.
  4. connection__node__node This relationship is key to the pressure driven gas transfer, holding the information about the pipeline characteristics and bringing the elements into interaction.
    • The parameter connection_linepack_constant holds the linepack constant and triggers the generation of the line pack storage constraint. Note that the first node should be the linepack storage node, while the second node should be a node_group of both, the start and the end node of the pipeline.
    • The linearization of the Weymouth equation through outer approximation relies on the use of fixed pressure points. For this purpose, the two parameters fixed_pressure_constant_1 and fixed_pressure_constant_0 hold the fixed pressure constants and trigger the generation of the constraint_fix_node_pressure_point. The constraint introduces the relationship between pressure and gas flows. Note, that the pressure constants should be entered in a way, that the first node represents the origin node, the second node the destination node. Each connection should have a connection__node__node to each combination of its start and end nodes (and associated parameters). (See Schwele - Coordination of Power and Natural Gas Systems: Convexification Approaches for Linepack Modeling)
    • By default, pipelines are considered to be passive. However, a compression station between two pipeline pressure nodes can be represented by defining a compression_factor. The relationship should be defined in such a manner, that the first node represents the sending node, the second node represents the receiving node, which pressure is equal or smaller to the pressure at the sending node times the compression factor.
    • Lastly, to ensure the balance between incoming/outgoing flows and flows into the linepack, the ratio between the flows need to be fixed. The average incoming flows of the node group (of the pressure start and end nodes) have to equal the flows into the linepack storage, and vice versa. Therefore, the fix_ratio_out_in_connection_flow needs to be set to a value (typically 1) for the (pressure group, linepack storage) node pair, and for the (linepack storage, pressure group) node pair.

A gas pipeline and its connected nodes are illustrated below. A complete mathematical formulation can be found here.

Illustration of gas pipeline

+Pressure driven gas transfer · SpineOpt.jl
GitHub

Pressure driven gas transfer

The generic formulation of SpineOpt is based on a trade based model. However, network physics can be different depending on the traded commodity. This chapter specifically addresses the use of pressure driven gas transfer models and enabling linepack flexibility in SpineOpt. To this date, investments in pressure driven pipelines are not yet supported within SpineOpt. The use of multiple feed-in nodes, e.g. to represent multiple commodity flows through a pipeline is not yet supported.

For the representation of pressure driven gas transfer, we use the MILP formulation, as described in Schwele - Coordination of Power and Natural Gas Systems: Convexification Approaches for Linepack Modeling. Here, the non-linearities associated with the Weymouth equation are convexified through an outer approximation of the Weymouth equation through fixed pressure points.

Key concept

Here, we briefly describe the key objects and relationships required to model pressure driven gas transfers in SpineOpt.

  1. connection: A connection represents the gas pipeline being modelled. Usually the direction of flow is not known a priory. To ensure that the flow through the gas pipeline is unidirectional, the parameter has_binary_gas_flow needs to be set to true.
  2. node: Nodes with different characteristics are used for the representation of pressure driven gas transfer.
    • For each connection, there will be two nodes representing the start and end point of the pipeline. Associated with these nodes are the following parameters: the has_pressure parameter, which needs to be set to true, in order to create the variable node_pressure; the max_node_pressure and min_node_pressure to constrain the pressure variable.
    • To leverage linepack flexibility, a third node is introduced representing the linepack storage of the pipeline. To trigger the storage linepack and hence, node_state variables, the has_state parameter needs to be set to true.
  3. connection__to_node and connection__from_node To enable flows through the pipeline and into the linepack storage, each node has to have both these relationships in common with the connection pipeline. These relationships will trigger the generation of connection_flow variables in all possible directions.
  4. connection__node__node This relationship is key to the pressure driven gas transfer, holding the information about the pipeline characteristics and bringing the elements into interaction.
    • The parameter connection_linepack_constant holds the linepack constant and triggers the generation of the line pack storage constraint. Note that the first node should be the linepack storage node, while the second node should be a node_group of both, the start and the end node of the pipeline.
    • The linearization of the Weymouth equation through outer approximation relies on the use of fixed pressure points. For this purpose, the two parameters fixed_pressure_constant_1 and fixed_pressure_constant_0 hold the fixed pressure constants and trigger the generation of the constraint_fix_node_pressure_point. The constraint introduces the relationship between pressure and gas flows. Note, that the pressure constants should be entered in a way, that the first node represents the origin node, the second node the destination node. Each connection should have a connection__node__node to each combination of its start and end nodes (and associated parameters). (See Schwele - Coordination of Power and Natural Gas Systems: Convexification Approaches for Linepack Modeling)
    • By default, pipelines are considered to be passive. However, a compression station between two pipeline pressure nodes can be represented by defining a compression_factor. The relationship should be defined in such a manner, that the first node represents the sending node, the second node represents the receiving node, which pressure is equal or smaller to the pressure at the sending node times the compression factor.
    • Lastly, to ensure the balance between incoming/outgoing flows and flows into the linepack, the ratio between the flows need to be fixed. The average incoming flows of the node group (of the pressure start and end nodes) have to equal the flows into the linepack storage, and vice versa. Therefore, the fix_ratio_out_in_connection_flow needs to be set to a value (typically 1) for the (pressure group, linepack storage) node pair, and for the (linepack storage, pressure group) node pair.

A gas pipeline and its connected nodes are illustrated below. A complete mathematical formulation can be found here.

Illustration of gas pipeline

diff --git a/dev/advanced_concepts/ramping_and_reserves/index.html b/dev/advanced_concepts/ramping_and_reserves/index.html index 439b68ec7d..b88b570027 100644 --- a/dev/advanced_concepts/ramping_and_reserves/index.html +++ b/dev/advanced_concepts/ramping_and_reserves/index.html @@ -1,2 +1,2 @@ -Ramping and Reserves · SpineOpt.jl
GitHub

Ramping and Reserves

To enable the representation of units with a high level of technical detail, the ramping ability of units can be constrained in SpineOpt. This means that the user has the freedom to impose restrictions on the change in output of units between consecutive timesteps, for online (spinning) units, units starting up and units shutting down. In this section, the concept of ramps in SpineOpt will be introduced. Furthermore, the use of reserves will be explained.

Relevant objects, relationships and parameters

Everything that is related to ramping is defined in parameters of either the unit__to_node, unit__from_node, or unit__to_node_group relationship. Generally speaking, the ramping constraints will impose restrictions on the change in the unit_flow variable between two consecutive timesteps.

All parameters that limit the ramping abilities of a unit are expressed as a fraction of the unit capacity. This means that a value of 1 indicates the full capacity of a unit.

The discussion here will be kept conceptual, for the mathematical formulation the reader is referred to the Ramping and reserve constraints

Constraining spinning ramps

Constraining shutdown ramps

Constraining startup ramps

General principle and example use cases

The general principle of the Spine modelling ramping constraints is that all of these parameters can be defined separately for each unit. This allows the user to incorporate different units (which can either represent a single unit or a technology type) with different flexibility characteristics.

It should be noted that it is perfectly possible to omit all of the constraining parameters mentioned above. However, once either of the ramping parameters is defined, it is necessary to also assign values to the other parameters. E.g. if a user only wants to restrict the spinning ramp up capability of a unit, one also has to assign values to the max_startup_ramp, min_Shutdown_Ramp etc.

Illustrative examples

Step 1: Simple case of unrestricted unit

When none of the ramping parameters mentioned above are defined, the unit is considered to have full ramping flexibility. This means that in any given timestep, its output can be any value between 0 and its capacity, regardless of what the output of the unit was in the previous timestep, and regardless of the on- or offline status or the unit in the previous timestep. Provided that this does not conflict with the Unit commitment restrictions that are defined for this unit. Parameter values for a unit__node relationship are illustratively given below.

  • max_shutdown_ramp : 1
  • min_shutdown_ramp : 0
  • max_start_up_ramp : 1
  • min_start_up_ramp : 0
  • ramp_up_limit : 1
  • ramp_down_limit : 1
  • unit_capacity : 200

Step 2: Spinning ramp restriction

A unit which is only restricted in spinning ramping can be created by changing the ramp_up/down_limit parameters:

  • ramp_up_limit : 0.2
  • ramp_down_limit : 0.4

This parameter choice implies that the unit's output between two consecutive timesteps can change with no more than $0.2 * 200$ and no less than $0.4 * 200$. For example, when the unit is running at an output of $100$ in some timestep $t$, its output for the next timestep must be somewhere in the interval $[20,140]$. Unless it shuts down completely.

Step 3: Shutdown restrictions

By changing the parameter max_shutdown_ramp in the previous example, an additional restriction is imposed on the maximum output of the unit from which it can go offline.

  • max_shutdown_ramp : 0.5
  • min_shutdown_ramp : 0.3

When this unit goes offline in a given timestep $t+1$, the output of the unit must be below $0.5*200 = 100$ in the timestep $t$ before that. Similarly, the parameter min_shutdown_ramp can be used to impose a minimum output value in the timestep before a shutdown. For example, a value of $0.3$ in this example would mean that the unit can not be running below an output of $60$ in timestep $t$.

Step 4: Startup restrictions

The startup restrictions are very similar to the shutdown restrictions, but of course apply to units that are starting up. Consider for example the same unit as in the example above, but now with a max_start_up_ramp equal to $0.4$ and min_start_up_ramp equal to $0.2$:

  • max_start_up_ramp : 0.4
  • min_start_up_ramp : 0.2

When the unit is offline in timestep $t$ and comes online in timestep $t+1$, its output in timestep $t+1$ will be restricted to the interval $[40,80]$.

Reserve concept

To include a requirement of reserve provision in a model, SpineOpt offers the possibility of creating reserve nodes. Of course reserve provision is different from regular operation, because the reserved capacity does not actually get activated. In this section, we will take a look at the things that are particular for a reserve node.

Defining a reserve node

To define a reserve node, the following parameters have to be defined for the relevant node:

  • is_reserve_node : this boolean parameter indicates that this node is a reserve node.
  • upward_reserve : this boolean parameter indicates that the demand for reserve provision of this node concerns upward reserves.
  • downward_reserve : this boolean parameter indicates that the demand for reserve provision of this node concerns downward reserves.
  • reserve_procurement_cost: (optional) this parameter indicates the procurement cost of a unit for a certain reserve product and can be define on a unit__to_node or unit__from_node relationship.

Defining a node group

SpineOpt allows the user to constrain ramping abilities of units that are linked to multiple nodes by defining node groups. This is especially relevant for reserve provision because a unit that provides reserves is linked to a regular, as well as a reserve node. It is then possible to constrain the unit's ramping for the combination of regular operation and reserve provision.

Since reserve provision in fact literally reserves part of the capacity of a unit, the demand of the reserve node will be subtracted from the part that is available for regular operation. The section below will discuss how this works in SpineOpt by means of an example.

Since the demand of the nodes is defined on the individual node level (and the node group has no demand), the balance type of the group node should be set to balance_type_none.

Ramping constraints on a node group with one reserve node

Reserves step 1: simple case of unrestricted unit

Let's assume that we have one unit and two nodes in a model, one for reserves and one for regular demand. The unit is then linked by the unit__to_node relationships to each node individually, and on top of that, it is linked to a node group containing both nodes.

The ramping of the unit can now be constrained by defining the same parameters as before, but now for the node group. As before, the simplest case is a unit that is only restricted by its capacity:

  • max_shutdown_ramp : 1
  • min_shutdown_ramp : 0
  • max_start_up_ramp : 1
  • min_start_up_ramp : 0
  • ramp_up_limit : 1
  • ramp_down_limit : 1
  • unit_capacity : 200

The capacity restriction now implies that the sum of the reserve demand and regular demand cannot exceed the capacity of the unit. For example: when the reserve node has a demand of 10 in timestep t, the unit_flow variable to the regular node must be smaller than or equal to 190.

Reserves step 2: Spinning ramp restriction

The unit can be restricted only in spinning ramping, as in the previous example, by defining the ramp_up/down_limit parameters in the unit__to_node relationship for the node group:

  • ramp_up_limit : 0.2
  • ramp_down_limit : 0.4

This parameter choice implies that the unit's flow to the regular demand node between two consecutive timesteps can change with no more than $0.2 * 200 - upward\_reserve\_demand$ and no less than $0.4 * 200 - downward\_reserve\_demand$. For example, when the unit is running at an output of $100$ in some timestep $t$, and there is an upward reserve demand of 10 its output for the next timestep must be somewhere in the interval $[20,130]$.

It can be seen in this example that the demand for reserves is subtracted from both the generation capacity, and the ramping capacity of the unit that is available for regular operation. This stems from the fact that in providing reserve capacity, the unit is expected to be able to provide the demanded reserve within one timestep.

Reserves Step 3: Non-spinning reserves

Units can also be allowed to provide non-spinning reserves, through shutdowns and startups. This can be done by using the following parameters in the unit__to_node relationship for the reserve node :

  • max_res_startup_ramp

  • min_res_startup_ramp

  • max_res_shutdown_ramp

  • min_res_shutdown_ramp

  • unit_capacity

These parameters are constraining reserve provision in exactly the same way as their equivalents for regular operation. Note that it is now necessary to define a capacity of the unit with respect to the reserve node. The ramping parameters will then be interpreted as fractions of this specific capacity. The unit's overall capacity can be different than its capacity for reserve provision.

A unit which can provide both spinning and non-spinning reserves can be defined as follows:

Parameters to be defined for unit to node group relationship

  • max_shutdown_ramp : 1
  • min_shutdown_ramp : 0
  • max_start_up_ramp : 1
  • min_start_up_ramp : 0
  • ramp_up_limit : 0.2
  • ramp_down_limit : 0.4
  • unit_capacity : 200

Parameters to be defined for unit to reserve node relationship

  • max_res_startup_ramp: 0.5
  • min_res_startup_ramp: 0.1
  • unit_capacity: 150

The spinning reserve and ramping restrictions now remain the same as above, but on top of that the unit is able to provide non-spinning upward reserves when it is offline. In this particular example, the contribution of the offline unit to upward reserves can be anything in the interval [15,75].

Using node_groups for both combined and individual restrictions

It can be seen from the example above that when a node group is defined, ramping restrictions can be imposed both on the group level (thus for the unit as a whole) as well as for the individual nodes. If, for example a ramp-up-limit is defined for the node group, the sum of upward ramping of the two nodes will be restricted by this parameter, but it is still possible to limit the individual flows to the nodes as well. We will now discuss an example of this for the ramp_up_limit, but this also holds for other parameters.

Let's continue with the example above, where an online unit is capable of ramping up by 20% of its capacity and down by 40%. We might want to impose tighter restrictions for upward reserve provision than the ramping in overall operation (e.g. because the reserved capacity has to be available in a shorter time than the duration_unit). One can then simply define an additional parameter for the unit to reserve node relationship as follows.

  • ramp_up_limit : 0.15

Which now restricts the spinning upward ramping provision of the unit to 15% of its capacity, as defined for the reserve node. In this case, the change in the unit's flow to the regular demand node between two consecutive timesteps is still limited to the interval $[0.2 * 200 - upward\_reserve\_demand, 0.4 * 200 - downward\_reserve\_demand]$. But the upward reserves that it can provide has an upper bound of `$150 * 0.15$.

+Ramping and Reserves · SpineOpt.jl
GitHub

Ramping and Reserves

To enable the representation of units with a high level of technical detail, the ramping ability of units can be constrained in SpineOpt. This means that the user has the freedom to impose restrictions on the change in output of units between consecutive timesteps, for online (spinning) units, units starting up and units shutting down. In this section, the concept of ramps in SpineOpt will be introduced. Furthermore, the use of reserves will be explained.

Relevant objects, relationships and parameters

Everything that is related to ramping is defined in parameters of either the unit__to_node, unit__from_node, or unit__to_node_group relationship. Generally speaking, the ramping constraints will impose restrictions on the change in the unit_flow variable between two consecutive timesteps.

All parameters that limit the ramping abilities of a unit are expressed as a fraction of the unit capacity. This means that a value of 1 indicates the full capacity of a unit.

The discussion here will be kept conceptual, for the mathematical formulation the reader is referred to the Ramping and reserve constraints

Constraining spinning ramps

Constraining shutdown ramps

Constraining startup ramps

General principle and example use cases

The general principle of the Spine modelling ramping constraints is that all of these parameters can be defined separately for each unit. This allows the user to incorporate different units (which can either represent a single unit or a technology type) with different flexibility characteristics.

It should be noted that it is perfectly possible to omit all of the constraining parameters mentioned above. However, once either of the ramping parameters is defined, it is necessary to also assign values to the other parameters. E.g. if a user only wants to restrict the spinning ramp up capability of a unit, one also has to assign values to the max_startup_ramp, min_Shutdown_Ramp etc.

Illustrative examples

Step 1: Simple case of unrestricted unit

When none of the ramping parameters mentioned above are defined, the unit is considered to have full ramping flexibility. This means that in any given timestep, its output can be any value between 0 and its capacity, regardless of what the output of the unit was in the previous timestep, and regardless of the on- or offline status or the unit in the previous timestep. Provided that this does not conflict with the Unit commitment restrictions that are defined for this unit. Parameter values for a unit__node relationship are illustratively given below.

  • max_shutdown_ramp : 1
  • min_shutdown_ramp : 0
  • max_start_up_ramp : 1
  • min_start_up_ramp : 0
  • ramp_up_limit : 1
  • ramp_down_limit : 1
  • unit_capacity : 200

Step 2: Spinning ramp restriction

A unit which is only restricted in spinning ramping can be created by changing the ramp_up/down_limit parameters:

  • ramp_up_limit : 0.2
  • ramp_down_limit : 0.4

This parameter choice implies that the unit's output between two consecutive timesteps can change with no more than $0.2 * 200$ and no less than $0.4 * 200$. For example, when the unit is running at an output of $100$ in some timestep $t$, its output for the next timestep must be somewhere in the interval $[20,140]$. Unless it shuts down completely.

Step 3: Shutdown restrictions

By changing the parameter max_shutdown_ramp in the previous example, an additional restriction is imposed on the maximum output of the unit from which it can go offline.

  • max_shutdown_ramp : 0.5
  • min_shutdown_ramp : 0.3

When this unit goes offline in a given timestep $t+1$, the output of the unit must be below $0.5*200 = 100$ in the timestep $t$ before that. Similarly, the parameter min_shutdown_ramp can be used to impose a minimum output value in the timestep before a shutdown. For example, a value of $0.3$ in this example would mean that the unit can not be running below an output of $60$ in timestep $t$.

Step 4: Startup restrictions

The startup restrictions are very similar to the shutdown restrictions, but of course apply to units that are starting up. Consider for example the same unit as in the example above, but now with a max_start_up_ramp equal to $0.4$ and min_start_up_ramp equal to $0.2$:

  • max_start_up_ramp : 0.4
  • min_start_up_ramp : 0.2

When the unit is offline in timestep $t$ and comes online in timestep $t+1$, its output in timestep $t+1$ will be restricted to the interval $[40,80]$.

Reserve concept

To include a requirement of reserve provision in a model, SpineOpt offers the possibility of creating reserve nodes. Of course reserve provision is different from regular operation, because the reserved capacity does not actually get activated. In this section, we will take a look at the things that are particular for a reserve node.

Defining a reserve node

To define a reserve node, the following parameters have to be defined for the relevant node:

  • is_reserve_node : this boolean parameter indicates that this node is a reserve node.
  • upward_reserve : this boolean parameter indicates that the demand for reserve provision of this node concerns upward reserves.
  • downward_reserve : this boolean parameter indicates that the demand for reserve provision of this node concerns downward reserves.
  • reserve_procurement_cost: (optional) this parameter indicates the procurement cost of a unit for a certain reserve product and can be define on a unit__to_node or unit__from_node relationship.

Defining a node group

SpineOpt allows the user to constrain ramping abilities of units that are linked to multiple nodes by defining node groups. This is especially relevant for reserve provision because a unit that provides reserves is linked to a regular, as well as a reserve node. It is then possible to constrain the unit's ramping for the combination of regular operation and reserve provision.

Since reserve provision in fact literally reserves part of the capacity of a unit, the demand of the reserve node will be subtracted from the part that is available for regular operation. The section below will discuss how this works in SpineOpt by means of an example.

Since the demand of the nodes is defined on the individual node level (and the node group has no demand), the balance type of the group node should be set to balance_type_none.

Ramping constraints on a node group with one reserve node

Reserves step 1: simple case of unrestricted unit

Let's assume that we have one unit and two nodes in a model, one for reserves and one for regular demand. The unit is then linked by the unit__to_node relationships to each node individually, and on top of that, it is linked to a node group containing both nodes.

The ramping of the unit can now be constrained by defining the same parameters as before, but now for the node group. As before, the simplest case is a unit that is only restricted by its capacity:

  • max_shutdown_ramp : 1
  • min_shutdown_ramp : 0
  • max_start_up_ramp : 1
  • min_start_up_ramp : 0
  • ramp_up_limit : 1
  • ramp_down_limit : 1
  • unit_capacity : 200

The capacity restriction now implies that the sum of the reserve demand and regular demand cannot exceed the capacity of the unit. For example: when the reserve node has a demand of 10 in timestep t, the unit_flow variable to the regular node must be smaller than or equal to 190.

Reserves step 2: Spinning ramp restriction

The unit can be restricted only in spinning ramping, as in the previous example, by defining the ramp_up/down_limit parameters in the unit__to_node relationship for the node group:

  • ramp_up_limit : 0.2
  • ramp_down_limit : 0.4

This parameter choice implies that the unit's flow to the regular demand node between two consecutive timesteps can change with no more than $0.2 * 200 - upward\_reserve\_demand$ and no less than $0.4 * 200 - downward\_reserve\_demand$. For example, when the unit is running at an output of $100$ in some timestep $t$, and there is an upward reserve demand of 10 its output for the next timestep must be somewhere in the interval $[20,130]$.

It can be seen in this example that the demand for reserves is subtracted from both the generation capacity, and the ramping capacity of the unit that is available for regular operation. This stems from the fact that in providing reserve capacity, the unit is expected to be able to provide the demanded reserve within one timestep.

Reserves Step 3: Non-spinning reserves

Units can also be allowed to provide non-spinning reserves, through shutdowns and startups. This can be done by using the following parameters in the unit__to_node relationship for the reserve node :

  • max_res_startup_ramp

  • min_res_startup_ramp

  • max_res_shutdown_ramp

  • min_res_shutdown_ramp

  • unit_capacity

These parameters are constraining reserve provision in exactly the same way as their equivalents for regular operation. Note that it is now necessary to define a capacity of the unit with respect to the reserve node. The ramping parameters will then be interpreted as fractions of this specific capacity. The unit's overall capacity can be different than its capacity for reserve provision.

A unit which can provide both spinning and non-spinning reserves can be defined as follows:

Parameters to be defined for unit to node group relationship

  • max_shutdown_ramp : 1
  • min_shutdown_ramp : 0
  • max_start_up_ramp : 1
  • min_start_up_ramp : 0
  • ramp_up_limit : 0.2
  • ramp_down_limit : 0.4
  • unit_capacity : 200

Parameters to be defined for unit to reserve node relationship

  • max_res_startup_ramp: 0.5
  • min_res_startup_ramp: 0.1
  • unit_capacity: 150

The spinning reserve and ramping restrictions now remain the same as above, but on top of that the unit is able to provide non-spinning upward reserves when it is offline. In this particular example, the contribution of the offline unit to upward reserves can be anything in the interval [15,75].

Using node_groups for both combined and individual restrictions

It can be seen from the example above that when a node group is defined, ramping restrictions can be imposed both on the group level (thus for the unit as a whole) as well as for the individual nodes. If, for example a ramp-up-limit is defined for the node group, the sum of upward ramping of the two nodes will be restricted by this parameter, but it is still possible to limit the individual flows to the nodes as well. We will now discuss an example of this for the ramp_up_limit, but this also holds for other parameters.

Let's continue with the example above, where an online unit is capable of ramping up by 20% of its capacity and down by 40%. We might want to impose tighter restrictions for upward reserve provision than the ramping in overall operation (e.g. because the reserved capacity has to be available in a shorter time than the duration_unit). One can then simply define an additional parameter for the unit to reserve node relationship as follows.

  • ramp_up_limit : 0.15

Which now restricts the spinning upward ramping provision of the unit to 15% of its capacity, as defined for the reserve node. In this case, the change in the unit's flow to the regular demand node between two consecutive timesteps is still limited to the interval $[0.2 * 200 - upward\_reserve\_demand, 0.4 * 200 - downward\_reserve\_demand]$. But the upward reserves that it can provide has an upper bound of `$150 * 0.15$.

diff --git a/dev/advanced_concepts/representative_days_w_seasonal_storage/index.html b/dev/advanced_concepts/representative_days_w_seasonal_storage/index.html index 08153ad243..6daf4ca7e9 100644 --- a/dev/advanced_concepts/representative_days_w_seasonal_storage/index.html +++ b/dev/advanced_concepts/representative_days_w_seasonal_storage/index.html @@ -1,2 +1,2 @@ -Representative days with seasonal storages · SpineOpt.jl
GitHub

Representative days with seasonal storages

In order to reduce the problem size, representative periods are often used in optimization models. However, this often limits the ability to properly account for seasonal storages.

In SpineOpt, we provide functionality to use representative days with seasonal storages.

General idea

The general idea is to mimick the seasonal effects throughout a non-representative period, e.g. a year of optimization, by introducing a specific sequence of the representative periods.

Usage of representative days and seasonal storages for investment problems

Assuming you already have an investment model with a certain temporal structure that works, you can turn it into a representative periods model with the following steps.

  1. Identify the nodes and units whose flows and statuses you want to model using representative periods, as well as their associated temporal_blocks.
  2. Select the representative periods. For example if you are modelling a year, you can select a few weeks (one in summer, one in winder, and one in mid season).
  3. For each representative period, create a temporal_block specifying block_start, block_end and resolution.
  4. Associate these temporal_blocks to the nodes and units identified in step 1, via node__temporal_block and units_on__temporal_block relationships.
  5. Finally, for each original temporal_block associated to these nodes and units (those identified in step 1), specify the value of the representative_periods_mapping parameter. This should be a map where each entry associates a date-time to the name of one of the representative period temporal_blocks created in step 3. More specifically, an entry with t as the key and b as the value means that time slices from the original block starting at t, are 'represented' by time slices from the b block. In other words, time slices between t and t plus the duration of b are represented by b.

In SpineOpt, this will be interpreted in the following way:

  • All operational variables, with the exception of the node_state variable, will be created only for the representative periods. For the non-representative periods, SpineOpt will use the variable of the corresponding representative period according to the value of the representative_periods_mapping parameter.
  • The node_state variable and the investment variables will be created for all periods, representative and non-representative.

The SpinePeriods.jl package provides an alternative, perhaps simpler way to setup a representative periods model based on the automatic selection and ordering of periods.

+Representative days with seasonal storages · SpineOpt.jl
GitHub

Representative days with seasonal storages

In order to reduce the problem size, representative periods are often used in optimization models. However, this often limits the ability to properly account for seasonal storages.

In SpineOpt, we provide functionality to use representative days with seasonal storages.

General idea

The general idea is to mimick the seasonal effects throughout a non-representative period, e.g. a year of optimization, by introducing a specific sequence of the representative periods.

Usage of representative days and seasonal storages for investment problems

Assuming you already have an investment model with a certain temporal structure that works, you can turn it into a representative periods model with the following steps.

  1. Identify the nodes and units whose flows and statuses you want to model using representative periods, as well as their associated temporal_blocks.
  2. Select the representative periods. For example if you are modelling a year, you can select a few weeks (one in summer, one in winder, and one in mid season).
  3. For each representative period, create a temporal_block specifying block_start, block_end and resolution.
  4. Associate these temporal_blocks to the nodes and units identified in step 1, via node__temporal_block and units_on__temporal_block relationships.
  5. Finally, for each original temporal_block associated to these nodes and units (those identified in step 1), specify the value of the representative_periods_mapping parameter. This should be a map where each entry associates a date-time to the name of one of the representative period temporal_blocks created in step 3. More specifically, an entry with t as the key and b as the value means that time slices from the original block starting at t, are 'represented' by time slices from the b block. In other words, time slices between t and t plus the duration of b are represented by b.

In SpineOpt, this will be interpreted in the following way:

  • All operational variables, with the exception of the node_state variable, will be created only for the representative periods. For the non-representative periods, SpineOpt will use the variable of the corresponding representative period according to the value of the representative_periods_mapping parameter.
  • The node_state variable and the investment variables will be created for all periods, representative and non-representative.

The SpinePeriods.jl package provides an alternative, perhaps simpler way to setup a representative periods model based on the automatic selection and ordering of periods.

diff --git a/dev/advanced_concepts/stochastic_framework/index.html b/dev/advanced_concepts/stochastic_framework/index.html index 15623ca4f0..788814e67e 100644 --- a/dev/advanced_concepts/stochastic_framework/index.html +++ b/dev/advanced_concepts/stochastic_framework/index.html @@ -6,4 +6,4 @@ # If not a root `stochastic_scenario` -weight(scenario) = sum([weight(parent) * weight_relative_to_parents(scenario)] for parent in parents)

Finally, with all the pieces in place, we'll need to connect the defined stochastic_structure objects to the desired objects in the Systemic object classes using the Structural relationship classes like node__stochastic_structure etc. Here, we essentially tell which parts of the modelled system use which stochastic_structure. Since creating each of these relationships individually can be a bit of a pain, there are a few Meta relationship classes like the model__default_stochastic_structure, that can be used to set model-wide defaults that are used if specific relationships are missing.

Example of deterministic stochastics

Here, we'll demonstrate step-by-step how to create the simplest possible stochastic frame: the fully deterministic one. See the Deterministic Stochastic Structure archetype for how the final data structure looks like, as well as how to connect this stochastic_structure to the rest of your model.

  1. Create a stochastic_scenario called e.g. realization and a stochastic_structure called e.g. deterministic.
  2. We can skip the parent_stochastic_scenario__child_stochastic_scenario relationship, since there isn't a stochastic DAG in this example, and the default behaviour of each stochastic_scenario being independent works for our purposes (only one stochastic_scenario anyhow).
  3. Create the stochastic_structure__stochastic_scenario relationship for (deterministic, realization), and set its weight_relative_to_parents parameter to 1. We don't need to define the stochastic_scenario_end parameter, as we want the realization to go on indefinitely.
  4. Relate the deterministic stochastic_structure to all the desired system objects using the appropriate Structural relationship classes, or use the model-level default Meta relationship classes.

Example of branching stochastics

Here, we'll demonstrate step-by-step how to create a simple branching stochastic tree, where one scenario branches into three at a specific point in time. See the Branching Stochastic Tree archetype for how the final data structure looks like, as well as how to connect this stochastic_structure to the rest of your model.

  1. Create four stochastic_scenario objects called e.g. realization, forecast1, forecast2, and forecast3, and a stochastic_structure called e.g. branching.
  2. Define the stochastic DAG by creating the parent_stochastic_scenario__child_stochastic_scenario relationships for (realization, forecast1), (realization, forecast2), and (realization, forecast3).
  3. Create the stochastic_structure__stochastic_scenario relationship for (branching, realization), (branching, forecast1), (branching, forecast2), and (branching, forecast3).
  4. Set the weight_relative_to_parents parameter to 1 and the stochastic_scenario_end parameter e.g. to 6h for the stochastic_structure__stochastic_scenario relationship (branching, realization). Now, the realization stochastic_scenario will end after 6 hours of time steps, and its children (forecast1, forecast2, and forecast3) will become active.
  5. Set the weight_relative_to_parents Parameters for the (branching, forecast1), (branching, forecast2), and (branching, forecast3) stochastic_structure__stochastic_scenario relationships to whatever you desire, e.g. 0.33 for equal probabilities across all forecasts.
  6. Relate the branching stochastic_structure to all the desired system objects using the appropriate Structural relationship classes, or use the model-level default Meta relationship classes.

Example of converging stochastics

Here, we'll demonstrate step-by-step how to create a simple stochastic DAG, where both branching and converging occurs. This example relies on the previous Example of branching stochastics, but adds another stochastic_scenario at the end, which is a child of the forecast1, forecast2, and forecast3 scenarios. See the Converging Stochastic Tree archetype for how the final data structure looks like, as well as how to connect this stochastic_structure to the rest of your model.

  1. Follow the steps 1-5 in the previous Example of branching stochastics, except call the stochastic_structure something different, e.g. converging.
  2. Create a new stochastic_scenario called e.g. converged_forecast.
  3. Alter the stochastic DAG by creating the parent_stochastic_scenario__child_stochastic_scenario relationships for (forecast1, converged_forecast), (forecast2, converged_forecast), and (forecast3, converged_forecast). Now all three forecasts will converge into a single converged_forecast.
  4. Add the stochastic_structure__stochastic_scenario relationship for (converging, converged_forecast), and set its weight_relative_to_parents parameter to 1. Now, all the probability mass in forecast1, forecast2, and forecast3 will be summed up back to the converged_forecast.
  5. Set the stochastic_scenario_end Parameters of the stochastic_structure__stochastic_scenario relationships (converging, forecast1), (converging, forecast2), and (converging, forecast3) to e.g. 1D, so that all three scenarios end at the same time and the converged_forecast becomes active.
  6. Relate the converging stochastic_structure to all the desired system objects using the appropriate Structural relationship classes, or use the model-level default Meta relationship classes.

Working with stochastic updating data

Now that we've discussed how to set up stochastics for SpineOpt, let's focus on stochastic data. The most complex form of input data SpineOpt can currently handle is both stochastic and updating, meaning that the values the parameter takes can depend on both the stochastic_scenario, and the analysis time (first time step) of each solve. However, just stochastic or just updating cases are supported as well, using the same input data format.

In SpineOpt, stochastic data uses the Map data type from SpineInterface.jl. Essentially, Maps are general indexed data containers, which SpineOpt tries to interpret as stochastic data. Every time SpineOpt calls a parameter, it passes the stochastic_scenario and analysis time as keyword arguments to the parameter, but depending on the parameter type, it doesn't necessarily do anything with that information. For Map type parameters, those keyword arguments are used for navigating the indices of the Map to try and find the corresponding value. If the Map doesn't include the stochastic_scenario index it's looking for, it assumes there's no stochastic information in the Map and carries on to search for analysis time indices. This logic is useful for defining both stochastic and updating data, as well as either case by itself, as shown in the following examples.

Example of stochastic data

By stochastic data, we mean parameter values that depend only on the stochastic_scenario. In such a case, the input data must be formatted as a Map with the following structure

stochastic_scenariovalue
scenario1value1
scenario2value2

where stochastic_scenario indices are simply Strings corresponding to the names of the stochastic_scenario objects. The values can be whatever data types SpineInterface.jl supports, like Constants, DateTimes, Durations, or TimeSeries. In the above example, the parameter will take value1 in scenario1, and value2 in scenario2. Note that since there's no analysis time index in this example, the values are used regardless of the analysis time.

Example of updating data

By updating data, we mean parameter values that depend only on the analysis time. In such a case, the input data must be formatted as a Map with the following structure

analysis timevalue
2000-01-01T00:00:00value1
2000-01-01T12:00:00value2

where the analysis time indices are DateTime values. The values can be whatever data types SpineInterface.jl supports, like Constants, DateTimes, Durations, or TimeSeries. In the above example, the parameter will take value1 if the first time step of the current simulation is between 2000-01-01T00:00:00 and 2000-01-01T12:00:00, and value2 if the first time step of the simulation is after 2000-01-01T12:00:00. Note that since there's no stochastic_scenario index in this example, the values are used regardless of the stochastic_scenario.

Example of stochastic updating data

By stochastic updating data, we mean parameter values that depend on both the stochastic_scenario and the analysis time. In such a case, the input data must be formatted as a Map with the following structure

stochastic_scenarioanalysis timevalue
scenario12000-01-01T00:00:00value1
scenario12000-01-01T12:00:00value2
scenario22000-01-01T00:00:00value3
scenario22000-01-01T12:00:00value4

where the stochastic_scenario indices are simply Strings corresponding to the names of the stochastic_scenario objects, and the analysis time indices are DateTime values. The values can be whatever data types SpineInterface.jl supports, like Constants, DateTimes, Durations, or TimeSeries. In the above example, the parameter will take value1 if the first time step of the current simulation is between 2000-01-01T00:00:00 and 2000-01-01T12:00:00 and the parameter is called in scenario1, and value3 in scenario2. If the first time step of the current simulation is after 2000-01-01T12:00:00, the parameter will take value2 in scenario1, and value4 in scenario2.

Constraint generation with stochastic path indexing

Every time a constraint might refer to variables either on different time steps or on different stochastic scenarios (meaning different nodes or units), the constraint needs to use stochastic path indexing in order to be correctly generated for arbitrary stochastic DAGs. In practise, this means following the procedure outlined below:

  1. Identify all unique full stochastic paths, meaning all the possible ways of traversing the DAG. This is done along with generating the stochastic structure, so no real impact on constraint generation.
  2. Find all the stochastic scenarios that are active on all the stochastic structures and time slices included in the constraint.
  3. Find all the unique stochastic paths by intersecting the set of active scenarios with the full stochastic paths.
  4. Generate constraints over each unique stochastic path found in step 3.

Steps 2 and 3 are the crucial ones, and are currently handled by separate constraint_<constraint_name>_indices functions. Essentially, these functions go through all the variables on all the time steps included in the constraint, collect the set of active stochastic_scenarios on each time step, and then determine the unique active stochastic paths on each time step. The functions pre-form the index set over which the constraint is then generated in the add_constraint_<constraint_name> functions.

+weight(scenario) = sum([weight(parent) * weight_relative_to_parents(scenario)] for parent in parents)

Finally, with all the pieces in place, we'll need to connect the defined stochastic_structure objects to the desired objects in the Systemic object classes using the Structural relationship classes like node__stochastic_structure etc. Here, we essentially tell which parts of the modelled system use which stochastic_structure. Since creating each of these relationships individually can be a bit of a pain, there are a few Meta relationship classes like the model__default_stochastic_structure, that can be used to set model-wide defaults that are used if specific relationships are missing.

Example of deterministic stochastics

Here, we'll demonstrate step-by-step how to create the simplest possible stochastic frame: the fully deterministic one. See the Deterministic Stochastic Structure archetype for how the final data structure looks like, as well as how to connect this stochastic_structure to the rest of your model.

  1. Create a stochastic_scenario called e.g. realization and a stochastic_structure called e.g. deterministic.
  2. We can skip the parent_stochastic_scenario__child_stochastic_scenario relationship, since there isn't a stochastic DAG in this example, and the default behaviour of each stochastic_scenario being independent works for our purposes (only one stochastic_scenario anyhow).
  3. Create the stochastic_structure__stochastic_scenario relationship for (deterministic, realization), and set its weight_relative_to_parents parameter to 1. We don't need to define the stochastic_scenario_end parameter, as we want the realization to go on indefinitely.
  4. Relate the deterministic stochastic_structure to all the desired system objects using the appropriate Structural relationship classes, or use the model-level default Meta relationship classes.

Example of branching stochastics

Here, we'll demonstrate step-by-step how to create a simple branching stochastic tree, where one scenario branches into three at a specific point in time. See the Branching Stochastic Tree archetype for how the final data structure looks like, as well as how to connect this stochastic_structure to the rest of your model.

  1. Create four stochastic_scenario objects called e.g. realization, forecast1, forecast2, and forecast3, and a stochastic_structure called e.g. branching.
  2. Define the stochastic DAG by creating the parent_stochastic_scenario__child_stochastic_scenario relationships for (realization, forecast1), (realization, forecast2), and (realization, forecast3).
  3. Create the stochastic_structure__stochastic_scenario relationship for (branching, realization), (branching, forecast1), (branching, forecast2), and (branching, forecast3).
  4. Set the weight_relative_to_parents parameter to 1 and the stochastic_scenario_end parameter e.g. to 6h for the stochastic_structure__stochastic_scenario relationship (branching, realization). Now, the realization stochastic_scenario will end after 6 hours of time steps, and its children (forecast1, forecast2, and forecast3) will become active.
  5. Set the weight_relative_to_parents Parameters for the (branching, forecast1), (branching, forecast2), and (branching, forecast3) stochastic_structure__stochastic_scenario relationships to whatever you desire, e.g. 0.33 for equal probabilities across all forecasts.
  6. Relate the branching stochastic_structure to all the desired system objects using the appropriate Structural relationship classes, or use the model-level default Meta relationship classes.

Example of converging stochastics

Here, we'll demonstrate step-by-step how to create a simple stochastic DAG, where both branching and converging occurs. This example relies on the previous Example of branching stochastics, but adds another stochastic_scenario at the end, which is a child of the forecast1, forecast2, and forecast3 scenarios. See the Converging Stochastic Tree archetype for how the final data structure looks like, as well as how to connect this stochastic_structure to the rest of your model.

  1. Follow the steps 1-5 in the previous Example of branching stochastics, except call the stochastic_structure something different, e.g. converging.
  2. Create a new stochastic_scenario called e.g. converged_forecast.
  3. Alter the stochastic DAG by creating the parent_stochastic_scenario__child_stochastic_scenario relationships for (forecast1, converged_forecast), (forecast2, converged_forecast), and (forecast3, converged_forecast). Now all three forecasts will converge into a single converged_forecast.
  4. Add the stochastic_structure__stochastic_scenario relationship for (converging, converged_forecast), and set its weight_relative_to_parents parameter to 1. Now, all the probability mass in forecast1, forecast2, and forecast3 will be summed up back to the converged_forecast.
  5. Set the stochastic_scenario_end Parameters of the stochastic_structure__stochastic_scenario relationships (converging, forecast1), (converging, forecast2), and (converging, forecast3) to e.g. 1D, so that all three scenarios end at the same time and the converged_forecast becomes active.
  6. Relate the converging stochastic_structure to all the desired system objects using the appropriate Structural relationship classes, or use the model-level default Meta relationship classes.

Working with stochastic updating data

Now that we've discussed how to set up stochastics for SpineOpt, let's focus on stochastic data. The most complex form of input data SpineOpt can currently handle is both stochastic and updating, meaning that the values the parameter takes can depend on both the stochastic_scenario, and the analysis time (first time step) of each solve. However, just stochastic or just updating cases are supported as well, using the same input data format.

In SpineOpt, stochastic data uses the Map data type from SpineInterface.jl. Essentially, Maps are general indexed data containers, which SpineOpt tries to interpret as stochastic data. Every time SpineOpt calls a parameter, it passes the stochastic_scenario and analysis time as keyword arguments to the parameter, but depending on the parameter type, it doesn't necessarily do anything with that information. For Map type parameters, those keyword arguments are used for navigating the indices of the Map to try and find the corresponding value. If the Map doesn't include the stochastic_scenario index it's looking for, it assumes there's no stochastic information in the Map and carries on to search for analysis time indices. This logic is useful for defining both stochastic and updating data, as well as either case by itself, as shown in the following examples.

Example of stochastic data

By stochastic data, we mean parameter values that depend only on the stochastic_scenario. In such a case, the input data must be formatted as a Map with the following structure

stochastic_scenariovalue
scenario1value1
scenario2value2

where stochastic_scenario indices are simply Strings corresponding to the names of the stochastic_scenario objects. The values can be whatever data types SpineInterface.jl supports, like Constants, DateTimes, Durations, or TimeSeries. In the above example, the parameter will take value1 in scenario1, and value2 in scenario2. Note that since there's no analysis time index in this example, the values are used regardless of the analysis time.

Example of updating data

By updating data, we mean parameter values that depend only on the analysis time. In such a case, the input data must be formatted as a Map with the following structure

analysis timevalue
2000-01-01T00:00:00value1
2000-01-01T12:00:00value2

where the analysis time indices are DateTime values. The values can be whatever data types SpineInterface.jl supports, like Constants, DateTimes, Durations, or TimeSeries. In the above example, the parameter will take value1 if the first time step of the current simulation is between 2000-01-01T00:00:00 and 2000-01-01T12:00:00, and value2 if the first time step of the simulation is after 2000-01-01T12:00:00. Note that since there's no stochastic_scenario index in this example, the values are used regardless of the stochastic_scenario.

Example of stochastic updating data

By stochastic updating data, we mean parameter values that depend on both the stochastic_scenario and the analysis time. In such a case, the input data must be formatted as a Map with the following structure

stochastic_scenarioanalysis timevalue
scenario12000-01-01T00:00:00value1
scenario12000-01-01T12:00:00value2
scenario22000-01-01T00:00:00value3
scenario22000-01-01T12:00:00value4

where the stochastic_scenario indices are simply Strings corresponding to the names of the stochastic_scenario objects, and the analysis time indices are DateTime values. The values can be whatever data types SpineInterface.jl supports, like Constants, DateTimes, Durations, or TimeSeries. In the above example, the parameter will take value1 if the first time step of the current simulation is between 2000-01-01T00:00:00 and 2000-01-01T12:00:00 and the parameter is called in scenario1, and value3 in scenario2. If the first time step of the current simulation is after 2000-01-01T12:00:00, the parameter will take value2 in scenario1, and value4 in scenario2.

Constraint generation with stochastic path indexing

Every time a constraint might refer to variables either on different time steps or on different stochastic scenarios (meaning different nodes or units), the constraint needs to use stochastic path indexing in order to be correctly generated for arbitrary stochastic DAGs. In practise, this means following the procedure outlined below:

  1. Identify all unique full stochastic paths, meaning all the possible ways of traversing the DAG. This is done along with generating the stochastic structure, so no real impact on constraint generation.
  2. Find all the stochastic scenarios that are active on all the stochastic structures and time slices included in the constraint.
  3. Find all the unique stochastic paths by intersecting the set of active scenarios with the full stochastic paths.
  4. Generate constraints over each unique stochastic path found in step 3.

Steps 2 and 3 are the crucial ones, and are currently handled by separate constraint_<constraint_name>_indices functions. Essentially, these functions go through all the variables on all the time steps included in the constraint, collect the set of active stochastic_scenarios on each time step, and then determine the unique active stochastic paths on each time step. The functions pre-form the index set over which the constraint is then generated in the add_constraint_<constraint_name> functions.

diff --git a/dev/advanced_concepts/temporal_framework/index.html b/dev/advanced_concepts/temporal_framework/index.html index ce7a5e8b0b..8f33f9c015 100644 --- a/dev/advanced_concepts/temporal_framework/index.html +++ b/dev/advanced_concepts/temporal_framework/index.html @@ -1,2 +1,2 @@ -Temporal Framework · SpineOpt.jl
GitHub

Temporal Framework

Spine Model aims to provide a high degree of flexibility in the temporal dimension across different components of the created model. This means that the user has some freedom to choose how the temporal aspects of different components of the model are defined. This freedom increases the variety of problems that can be tackled in Spine: from very coarse, long term models, to very detailed models with a more limited horizon, or a mix of both. The choice of the user on how this flexibility is used will lead to the temporal structure of the model.

The main components of flexibility consist of the following parts:

  • The horizon that is modeled: end and start time
  • Temporal resolution
  • Possibility of a rolling optimization window
  • Support for commonly used methods such as representative days

Part of the temporal flexibility in Spine is due to the fact that these options mentioned above can be implemented differently across different components of the model, which can be very useful when different markets are coupled in a single model. The resolution and horizon of the gas market can for example be taken differently than that of the electricity market. This documentation aims to give the reader insight in how these aspects are defined, and which objects are used for this.

We start by introducing the relevant objects with their parameters, and the relevant relationship classes for the temporal structure. Afterwards, we will discuss how this setting creates flexibility and will present some of the practical approaches to create a variety of temporal structures.

Objects, relationships, and their parameters

In this section, the objects and relationships will be discussed that form the temporal structure together.

Objects relevant for the temporal framework

For the objects, the relevant parameters will also be introduced, along with the type of values that are allowed, following the format below:

  • 'parameter_name' : "Allowed value type"

model object

Each model object holds general information about the model at hand. Here we only discuss the time related parameters:

These two parameters define the model horizon. A Datetime value is to be taken for both parameters, in which case they directly mark respectively the beginning and end of the modeled time horizon.

This parameters gives the unit of duration that is used in the model calculations. The default value for this parameter is 'minute'. E.g. if the duration_unit is set to hour, a Duration of one minute gets converted into 1/60 hours for the calculations.

This parameter defines how much the optimization window rolls forward in a rolling horizon optimization and should be expressed as a duration. In the practical approaches presented below, the rolling window optimization will be explained in more detail.

temporal_block object

A temporal block defines the properties of the optimization that is to be solved in the current window. Most importantly, it holds the necessary information about the resolution and horizon of the optimization.

  • resolution (optional): "duration value" or "array of duration values"

This parameter specifies the resolution of the temporal block, or in other words: the length of the timesteps used in the optimization run.

  • block_start (optional): "duration value" or "Date time value"

Indicates the start of this temporal block.

  • block_end(optional): "duration value" or "Date time value"

Indicates the end of this temporal block.

Relationships relevant for the temporal framework

model__temporal_block relationship

In this relationship, a model instance is linked to a temporal block. If this relationship doesn't exist - the temporal block is disregarded from this optimization model.

model__default_temporal_block relationship

Defines the default temporal block used for model objects, which will be replaced when a specific relationship is defined for a model in model__temporal_block.

node__temporal_block relationship

This relationship will link a node to a temporal block.

units_on__temporal_block relationship

This relationship links the units_on variable of a unit to a temporal block and will therefore govern the time-resolution of the unit's online/offline status.

unit__investment_temporal_block relationship

This relationship sets the temporal dimensions for investment decisions of a certain unit. The separation between this relationship and the units_on__temporal_block, allows the user for example to give a much finer resolution to a unit's on- or offline status than to it's investment decisions.

model__default_investment_temporal_block relationship

Defines the default temporal block used for investment decisions, which will be replaced when a specific relationship is defined for a unit in unit__investment_temporal_block.

General principle of the temporal framework

The general principle of the Spine modeling temporal structure is that different temporal blocks can be defined and linked to different objects in a model. This leads to great flexibility in the temporal structure of the model as a whole. To illustrate this, we will discuss some of the possibilities that arise in this framework.

One single temporal_block

Single solve with single block

The simplest case is a single solve of the entire time horizon (so roll_forward not defined) with a fixed resolution. In this case, only one temporal block has to be defined with a fixed resolution. Each node has to be linked to this temporal_block.

Alternatively, a variable resolution can be defined by choosing an array of durations for the resolution parameter. The sum of the durations in the array then have to match the length of the temporal block. The example below illustrates an optimization that spans one day for which the resolution is hourly in the beginning and then gradually decreases to a 6h resolution at the end.

  • temporal_block_1
    • block_start: 0h (Alternative DateTime: e.g. 2030-01-01T00:00:00)
    • block_end: 1D (Alternative DateTime: e.g. 2030-01-02T00:00:00)
    • resolution: [1h 1h 1h 1h 2h 2h 2h 4h 4h 6h]

Note that, as mentioned above, the block_start and block_end parameters can also be entered as absolute values, i.e. DateTime values.

Rolling window optimization with single block

A model with a single temporal_block can also be optimized in a rolling horizon framework. In this case, the roll_forward parameter has to be defined in the model object. The roll_forward parameter will then determine how much the optimization moves forward with every step, while the size of the temporal block will determine how large a time frame is optimized in each step. To see this more clearly, let's take a look at an example.

Suppose we want to model a horizon of one week, with a rolling window size of one day. The roll_forward parameter will then be a duration value of 1d. If we take the temporal_block parameters block_start and block_end to be the duration values 0h and 1d respectively, the model will optimize each day of the week separately. However, we could also take the block_end parameter to be 2d. Now the model will start by optimizing day 1 and day 2 together, after which it keeps only the values obtained for the first day, and moves forward to optimize the second and third day together.

Again, a variable resolution can be implemented for the rolling window optimization. The sum of the durations must in this case match the size of the optimized window.

Advanced usage: multiple temporal_block objects

Single solve with multiple blocks

Disconnected time periods

Multiple temporal blocks can be used to optimize disconnected periods. Let's take a look at an example in which two temporal blocks are defined.

  • temporal_block_1
    • block_start: 0h
    • block_end: 4h
  • temporal_block_2
    • block_start: 12h
    • block_end: 16h

This example will lead to an optimization of the first four hours of the model horizon, and also of hour 12 to 16. By defining exactly the same relationships for the two temporal blocks, an optimization of disconnected periods is achieved for exactly the same model components. This leads to the possibility of implementing the widely used representative days method. If desired, it is possible to choose a different temporal resolution for the different temporal_blocks.

It is worth noting that dynamic variables like node_state and units_on merit special attention when using disconnected time periods. By default, when trying to access variables Variables outside the defined temporal_blocks, SpineOpt.jl assumes such variables exist but allows them to take any values within specified bounds. If fixed initial conditions for the disconnected periods are desired, one needs to use parameters such as fix_node_state or fix_units_on.

Different regions/commodities in different resolutions

Multiple temporal blocks can also be used to model different regions or different commodities with a different resolution. This is especially useful when there is a certain region or commodity of interest, while other elements are connected to this but require less detail. For this kind of usage, the relationships that are defined for the temporal blocks will be different, as shown in the example below.

  • temporal_blocks
    • temporal_block_1
      • resolution: 1h
    • temporal_block_2
      • resolution: 2h
  • nodes
    • node_1
    • node_2
  • node_temporal_block relationships
    • node_1_temporal_block_1
    • node_2_temporal_block_2

Similarly, the on- and offline status of a unit can be modeled with a lower resolution than the actual output of that unit, by defining the units_on_temporal_block relationship with a different temporal block than the one used for the node_temporal_block relationship (of the node to which the unit is connected).

Rolling horizon with multiple blocks

Rolling horizon with different window sizes

Similar to what has been discussed above in Different regions/commodities in different resolutions, different commodities or regions can be modeled with a different resolution in the rolling horizon setting. The way to do it is completely analogous. Furthermore, when using the rolling horizon framework, a different window size can be chosen for the different modeled components, by simply using a different block_end parameter. However, using different block_ends e.g. for interconnected regions should be treated with care, as the variables for each region will only be generated for their respective temporal_block, which in most cases will lead to inconsistent linking constraints.

Putting it all together: rolling horizon with variable resolution that differs for different model components

Below is an example of an advanced use case in which a rolling horizon optimization is used, and different model components are optimized with a different resolution. By choosing the relevant parameters in the following way:

  • model
    • roll_forward: 4h
  • temporal_blocks
    • temporal_block_A
      • resolution: [1h 1h 2h 2h 2h 3h 3h]
      • block_end: 14h
    • temporal_block_B
      • resolution: [2h 2h 4h 6h]
      • block_end: 14h
  • nodes
    • node_1
    • node_2
  • node_temporal_block relationships
    • node_1_temporal_block_A
    • node_2_temporal_block_B

The two model components that are considered have a different resolution, and their own resolution is also varying within the optimization window. Note that in this case the two optimization windows have the same size, but this is not strictly necessary. The image below visualizes the first two window optimizations of this model.

temporal structure

+Temporal Framework · SpineOpt.jl
GitHub

Temporal Framework

Spine Model aims to provide a high degree of flexibility in the temporal dimension across different components of the created model. This means that the user has some freedom to choose how the temporal aspects of different components of the model are defined. This freedom increases the variety of problems that can be tackled in Spine: from very coarse, long term models, to very detailed models with a more limited horizon, or a mix of both. The choice of the user on how this flexibility is used will lead to the temporal structure of the model.

The main components of flexibility consist of the following parts:

  • The horizon that is modeled: end and start time
  • Temporal resolution
  • Possibility of a rolling optimization window
  • Support for commonly used methods such as representative days

Part of the temporal flexibility in Spine is due to the fact that these options mentioned above can be implemented differently across different components of the model, which can be very useful when different markets are coupled in a single model. The resolution and horizon of the gas market can for example be taken differently than that of the electricity market. This documentation aims to give the reader insight in how these aspects are defined, and which objects are used for this.

We start by introducing the relevant objects with their parameters, and the relevant relationship classes for the temporal structure. Afterwards, we will discuss how this setting creates flexibility and will present some of the practical approaches to create a variety of temporal structures.

Objects, relationships, and their parameters

In this section, the objects and relationships will be discussed that form the temporal structure together.

Objects relevant for the temporal framework

For the objects, the relevant parameters will also be introduced, along with the type of values that are allowed, following the format below:

  • 'parameter_name' : "Allowed value type"

model object

Each model object holds general information about the model at hand. Here we only discuss the time related parameters:

These two parameters define the model horizon. A Datetime value is to be taken for both parameters, in which case they directly mark respectively the beginning and end of the modeled time horizon.

This parameters gives the unit of duration that is used in the model calculations. The default value for this parameter is 'minute'. E.g. if the duration_unit is set to hour, a Duration of one minute gets converted into 1/60 hours for the calculations.

This parameter defines how much the optimization window rolls forward in a rolling horizon optimization and should be expressed as a duration. In the practical approaches presented below, the rolling window optimization will be explained in more detail.

temporal_block object

A temporal block defines the properties of the optimization that is to be solved in the current window. Most importantly, it holds the necessary information about the resolution and horizon of the optimization.

  • resolution (optional): "duration value" or "array of duration values"

This parameter specifies the resolution of the temporal block, or in other words: the length of the timesteps used in the optimization run.

  • block_start (optional): "duration value" or "Date time value"

Indicates the start of this temporal block.

  • block_end(optional): "duration value" or "Date time value"

Indicates the end of this temporal block.

Relationships relevant for the temporal framework

model__temporal_block relationship

In this relationship, a model instance is linked to a temporal block. If this relationship doesn't exist - the temporal block is disregarded from this optimization model.

model__default_temporal_block relationship

Defines the default temporal block used for model objects, which will be replaced when a specific relationship is defined for a model in model__temporal_block.

node__temporal_block relationship

This relationship will link a node to a temporal block.

units_on__temporal_block relationship

This relationship links the units_on variable of a unit to a temporal block and will therefore govern the time-resolution of the unit's online/offline status.

unit__investment_temporal_block relationship

This relationship sets the temporal dimensions for investment decisions of a certain unit. The separation between this relationship and the units_on__temporal_block, allows the user for example to give a much finer resolution to a unit's on- or offline status than to it's investment decisions.

model__default_investment_temporal_block relationship

Defines the default temporal block used for investment decisions, which will be replaced when a specific relationship is defined for a unit in unit__investment_temporal_block.

General principle of the temporal framework

The general principle of the Spine modeling temporal structure is that different temporal blocks can be defined and linked to different objects in a model. This leads to great flexibility in the temporal structure of the model as a whole. To illustrate this, we will discuss some of the possibilities that arise in this framework.

One single temporal_block

Single solve with single block

The simplest case is a single solve of the entire time horizon (so roll_forward not defined) with a fixed resolution. In this case, only one temporal block has to be defined with a fixed resolution. Each node has to be linked to this temporal_block.

Alternatively, a variable resolution can be defined by choosing an array of durations for the resolution parameter. The sum of the durations in the array then have to match the length of the temporal block. The example below illustrates an optimization that spans one day for which the resolution is hourly in the beginning and then gradually decreases to a 6h resolution at the end.

  • temporal_block_1
    • block_start: 0h (Alternative DateTime: e.g. 2030-01-01T00:00:00)
    • block_end: 1D (Alternative DateTime: e.g. 2030-01-02T00:00:00)
    • resolution: [1h 1h 1h 1h 2h 2h 2h 4h 4h 6h]

Note that, as mentioned above, the block_start and block_end parameters can also be entered as absolute values, i.e. DateTime values.

Rolling window optimization with single block

A model with a single temporal_block can also be optimized in a rolling horizon framework. In this case, the roll_forward parameter has to be defined in the model object. The roll_forward parameter will then determine how much the optimization moves forward with every step, while the size of the temporal block will determine how large a time frame is optimized in each step. To see this more clearly, let's take a look at an example.

Suppose we want to model a horizon of one week, with a rolling window size of one day. The roll_forward parameter will then be a duration value of 1d. If we take the temporal_block parameters block_start and block_end to be the duration values 0h and 1d respectively, the model will optimize each day of the week separately. However, we could also take the block_end parameter to be 2d. Now the model will start by optimizing day 1 and day 2 together, after which it keeps only the values obtained for the first day, and moves forward to optimize the second and third day together.

Again, a variable resolution can be implemented for the rolling window optimization. The sum of the durations must in this case match the size of the optimized window.

Advanced usage: multiple temporal_block objects

Single solve with multiple blocks

Disconnected time periods

Multiple temporal blocks can be used to optimize disconnected periods. Let's take a look at an example in which two temporal blocks are defined.

  • temporal_block_1
    • block_start: 0h
    • block_end: 4h
  • temporal_block_2
    • block_start: 12h
    • block_end: 16h

This example will lead to an optimization of the first four hours of the model horizon, and also of hour 12 to 16. By defining exactly the same relationships for the two temporal blocks, an optimization of disconnected periods is achieved for exactly the same model components. This leads to the possibility of implementing the widely used representative days method. If desired, it is possible to choose a different temporal resolution for the different temporal_blocks.

It is worth noting that dynamic variables like node_state and units_on merit special attention when using disconnected time periods. By default, when trying to access variables Variables outside the defined temporal_blocks, SpineOpt.jl assumes such variables exist but allows them to take any values within specified bounds. If fixed initial conditions for the disconnected periods are desired, one needs to use parameters such as fix_node_state or fix_units_on.

Different regions/commodities in different resolutions

Multiple temporal blocks can also be used to model different regions or different commodities with a different resolution. This is especially useful when there is a certain region or commodity of interest, while other elements are connected to this but require less detail. For this kind of usage, the relationships that are defined for the temporal blocks will be different, as shown in the example below.

  • temporal_blocks
    • temporal_block_1
      • resolution: 1h
    • temporal_block_2
      • resolution: 2h
  • nodes
    • node_1
    • node_2
  • node_temporal_block relationships
    • node_1_temporal_block_1
    • node_2_temporal_block_2

Similarly, the on- and offline status of a unit can be modeled with a lower resolution than the actual output of that unit, by defining the units_on_temporal_block relationship with a different temporal block than the one used for the node_temporal_block relationship (of the node to which the unit is connected).

Rolling horizon with multiple blocks

Rolling horizon with different window sizes

Similar to what has been discussed above in Different regions/commodities in different resolutions, different commodities or regions can be modeled with a different resolution in the rolling horizon setting. The way to do it is completely analogous. Furthermore, when using the rolling horizon framework, a different window size can be chosen for the different modeled components, by simply using a different block_end parameter. However, using different block_ends e.g. for interconnected regions should be treated with care, as the variables for each region will only be generated for their respective temporal_block, which in most cases will lead to inconsistent linking constraints.

Putting it all together: rolling horizon with variable resolution that differs for different model components

Below is an example of an advanced use case in which a rolling horizon optimization is used, and different model components are optimized with a different resolution. By choosing the relevant parameters in the following way:

  • model
    • roll_forward: 4h
  • temporal_blocks
    • temporal_block_A
      • resolution: [1h 1h 2h 2h 2h 3h 3h]
      • block_end: 14h
    • temporal_block_B
      • resolution: [2h 2h 4h 6h]
      • block_end: 14h
  • nodes
    • node_1
    • node_2
  • node_temporal_block relationships
    • node_1_temporal_block_A
    • node_2_temporal_block_B

The two model components that are considered have a different resolution, and their own resolution is also varying within the optimization window. Note that in this case the two optimization windows have the same size, but this is not strictly necessary. The image below visualizes the first two window optimizations of this model.

temporal structure

diff --git a/dev/advanced_concepts/unit_commitment/index.html b/dev/advanced_concepts/unit_commitment/index.html index ca92d6fd22..53e687baef 100644 --- a/dev/advanced_concepts/unit_commitment/index.html +++ b/dev/advanced_concepts/unit_commitment/index.html @@ -1,2 +1,2 @@ -Unit Commitment · SpineOpt.jl
GitHub

Unit commitment

To incorporate technical detail about (clustered) unit-commitment statuses of units, the online, started and shutdown status of units can be tracked and constrained in SpineOpt. In the following, relevant relationships and parameters are introduced and the general working principle is described.

Key concepts for unit commitment

Here, we briefly describe the key concepts involved in the representation of (clustered) unit commitment models:

  • units_on is an optimization variable that holds information about the on- or offline status of a unit. Unit commitment restrictions will govern how this variable can change through time.

  • units_on__temporal_block is a relationship linking the units_on variable of this unit to a specific temporal_block object. The temporal block holds information on the temporal scope and resolution for which the variable should be optimized.

  • online_variable_type is a method parameter and can take the values unit_online_variable_type_binary, unit_online_variable_type_integer, unit_online_variable_type_linear. If the binary value is chosen, the units status is modelled as a binary (classic UC). For clustered unit commitment units, the integer type is applicable. Note that if the parameter is not defined, the default will be linear. If the units status is not crucial, this can reduce the computational burden.

  • number_of_units defines how many units of a certain unit type are available. Typically this parameter takes a binary (UC) or integer (clustered UC) value. To avoid confusion the following distinction will be made in this document: unit will be used to identify a Spine unit object, which can have multiple members. Together with the unit_availability_factor, this will determine the maximum number of members that can be online at any given time. (Thus restricting the units_on variable). The default value for this parameter is $1$. It is possible to allow the model to increase the number_of_units itself, through Investment Optimization

  • unit_availability_factor: (number value or time series). Is the fraction of the time that this unit is considered to be available, by acting as a multiplier on the capacity. A time series can be used to indicate the intermittent character of renewable generation technologies.

  • min_up_time: (duration value). Sets the minimum time that a unit has to stay online after a startup. Inclusion of this parameter will trigger the creation of the constraint on Minimum up time (basic version)

  • min_down_time: (duration value). Sets the minimum time that a unit has to stay offline after a shutdown. Inclusion of this parameter will trigger the creation of the constraint on Minimum down time (basic version)

  • minimum_operating_point: (number value) limits the minimum value of the unit_flow variable for a unit which is currently online. Inclusion of this parameter will trigger the creation of the Constraint on minimum operating point

  • start_up_cost: "number value". Cost associated with starting up a unit.

  • shut_down_cost: "number value". Cost associated with shutting down a unit.

Illustrative unit commitment examples

Step 1: defining the number of members of a unit type

A spine unit can represent multiple members. This can be incorporated in a model by setting the number_of_units parameter to a specific value. For example, if we define a single unit in a model as follows:

  • unit_1
    • number_of_units: 2

And we link the unit to a certain node_1 with a unit__to_node relationship.

  • unit_1_to__node_1

The single spine unit defined here, now represents two members. This means that a single unit_flow variable will be created for this unit, but the restrictions as imposed by the Ramping and Reserves framework will be adapted to reflect the fact that there are two members present, thus doubling the total capacity.

Step 2: choosing the online_variable_type

Next, we have to decide the online_variable_type for this unit, which will restrict the kind of values that the units_on variable can take. This basically comes down to deciding if we are working in a classical UC framework (unit_online_variable_type_binary), a clustered UC framework (unit_online_variable_type_integer), or a relaxed clustered UC framework (unit_online_variable_type_linear), in which a non-integer number of units can be online.

The classical UC framework can only be applied when the number_of_units equals 1.

Step 3: imposing a minimum operating point

The output of an online unit to a specific node can be restricted to be above a certain minimum by choosing a value for the minimum_operating_point parameter. This parameter is defined for the unit__to_node relationship, and is given as a fraction of the unit_capacity. If we continue with the example above, and define the following objects, relationships, and parameters:

  • unit_1
    • number_of_units: 2
    • unit_online_variable_type: "unit_online_variable_type_integer"
  • unit_1_to__node_1
    • minimum_operating_point: 0.2
    • unit_capacity: 200

It can be seen that in this case the unit_flow form unit_1 to node_1 must for any timestep $t$ be larger than $units\_on(t) * 0.2 * 200$

Step 4: imposing a minimum up or down time

Spine units can also be restricted in their commitment status with minimum up- or down times by choosing a value for the min_up_time or min_down_time respectively. These parameters are defined for the unit object, and should be duration values. We can continue the example and add a minimum up time for the unit:

  • unit_1
    • number_of_units: 2
    • unit_online_variable_type: "unit_online_variable_type_integer"
    • min_up_time: 2h
  • unit_1_to__node_1
    • minimum_operating_point: 0.2
    • unit_capacity: 200

Whereas the units_on variable was restricted (before inclusion of the min_up_time parameter) to be smaller than or equal to the number_of_units for any timestep $t$, it now has to be smaller than or equal to the number_of_units decremented with the units_started_up summed over the timesteps that include t - min_up_time. This implies that a unit which has started up, has to stay online for at least the min_up_time

To consider a simple example let's assume that we have a model with a resolution of 1h. Suppose that before t, there is no member of the unit online and in timestep t -> t + 1h, one member starts up. Another member starts up in timestep t + 1h \-> t + 2h. The first startup, along with the minimum up time of 2 hours implies that the units_on variable of this unit has now changed to $1$ in timestep t -> t + 1h and can not go back to $0$ in timestep t-> t + 1h -> t + 2h. The second startup further restricts the number of units that are allowed to be online, it can be seen that the following restrictions apply when both startups are combined with the minimum up time of 2h:

  • t-> t + 1h : $units\_on = 1$
  • t + 1h -> t + 2h: $units\_on = 2$
  • t + 2h-> t + 3h: $units\_on \in {1,2}$
  • t + 3h-> t + 4h: $units\_on \in {0,1,2}$

The minimum down time restrictions operate in very much the same way, they simply impose that units that have been shut down, have to stay offline for the chosen period of time.

Step 5: allocationg a cost to startups or shutdowns

Costs can be allocated to startups or shutdowns by choosing a value for the start_up_cost or shut_down_cost respectively.

Step 6: defining unit availabilities

By defining a unit_availability_factor, the fact that typical members are not available all the time can be reflected in the model.

Typically, units are not available $100$% of the time, due to scheduled maintenance, unforeseen outages, or other things. This can be incorporated in the model by setting the unit_availability_factor to a fractional value. For each timestep in the model, an upper bound is then imposed on the units_on variable, equal to number_of_units $*$ unit_availability_factor. This parameter can not be used when the online_variable_type is binary. It should also be noted that when the online_variable_type is of integer type, the aforementioned product must be integer as well, since it will determine the value of the units_available parameter which is restricted to integer values. The default value for this parameter is $1$.

The unit_availability_factor can also be taken as a timeseries. By allowing a different availability factor for each timestep in the model, it can perfectly be used to represent intermittent technologies of which the output cannot be fully controlled.

+Unit Commitment · SpineOpt.jl
GitHub

Unit commitment

To incorporate technical detail about (clustered) unit-commitment statuses of units, the online, started and shutdown status of units can be tracked and constrained in SpineOpt. In the following, relevant relationships and parameters are introduced and the general working principle is described.

Key concepts for unit commitment

Here, we briefly describe the key concepts involved in the representation of (clustered) unit commitment models:

  • units_on is an optimization variable that holds information about the on- or offline status of a unit. Unit commitment restrictions will govern how this variable can change through time.

  • units_on__temporal_block is a relationship linking the units_on variable of this unit to a specific temporal_block object. The temporal block holds information on the temporal scope and resolution for which the variable should be optimized.

  • online_variable_type is a method parameter and can take the values unit_online_variable_type_binary, unit_online_variable_type_integer, unit_online_variable_type_linear. If the binary value is chosen, the units status is modelled as a binary (classic UC). For clustered unit commitment units, the integer type is applicable. Note that if the parameter is not defined, the default will be linear. If the units status is not crucial, this can reduce the computational burden.

  • number_of_units defines how many units of a certain unit type are available. Typically this parameter takes a binary (UC) or integer (clustered UC) value. To avoid confusion the following distinction will be made in this document: unit will be used to identify a Spine unit object, which can have multiple members. Together with the unit_availability_factor, this will determine the maximum number of members that can be online at any given time. (Thus restricting the units_on variable). The default value for this parameter is $1$. It is possible to allow the model to increase the number_of_units itself, through Investment Optimization

  • unit_availability_factor: (number value or time series). Is the fraction of the time that this unit is considered to be available, by acting as a multiplier on the capacity. A time series can be used to indicate the intermittent character of renewable generation technologies.

  • min_up_time: (duration value). Sets the minimum time that a unit has to stay online after a startup. Inclusion of this parameter will trigger the creation of the constraint on Minimum up time (basic version)

  • min_down_time: (duration value). Sets the minimum time that a unit has to stay offline after a shutdown. Inclusion of this parameter will trigger the creation of the constraint on Minimum down time (basic version)

  • minimum_operating_point: (number value) limits the minimum value of the unit_flow variable for a unit which is currently online. Inclusion of this parameter will trigger the creation of the Constraint on minimum operating point

  • start_up_cost: "number value". Cost associated with starting up a unit.

  • shut_down_cost: "number value". Cost associated with shutting down a unit.

Illustrative unit commitment examples

Step 1: defining the number of members of a unit type

A spine unit can represent multiple members. This can be incorporated in a model by setting the number_of_units parameter to a specific value. For example, if we define a single unit in a model as follows:

  • unit_1
    • number_of_units: 2

And we link the unit to a certain node_1 with a unit__to_node relationship.

  • unit_1_to__node_1

The single spine unit defined here, now represents two members. This means that a single unit_flow variable will be created for this unit, but the restrictions as imposed by the Ramping and Reserves framework will be adapted to reflect the fact that there are two members present, thus doubling the total capacity.

Step 2: choosing the online_variable_type

Next, we have to decide the online_variable_type for this unit, which will restrict the kind of values that the units_on variable can take. This basically comes down to deciding if we are working in a classical UC framework (unit_online_variable_type_binary), a clustered UC framework (unit_online_variable_type_integer), or a relaxed clustered UC framework (unit_online_variable_type_linear), in which a non-integer number of units can be online.

The classical UC framework can only be applied when the number_of_units equals 1.

Step 3: imposing a minimum operating point

The output of an online unit to a specific node can be restricted to be above a certain minimum by choosing a value for the minimum_operating_point parameter. This parameter is defined for the unit__to_node relationship, and is given as a fraction of the unit_capacity. If we continue with the example above, and define the following objects, relationships, and parameters:

  • unit_1
    • number_of_units: 2
    • unit_online_variable_type: "unit_online_variable_type_integer"
  • unit_1_to__node_1
    • minimum_operating_point: 0.2
    • unit_capacity: 200

It can be seen that in this case the unit_flow form unit_1 to node_1 must for any timestep $t$ be larger than $units\_on(t) * 0.2 * 200$

Step 4: imposing a minimum up or down time

Spine units can also be restricted in their commitment status with minimum up- or down times by choosing a value for the min_up_time or min_down_time respectively. These parameters are defined for the unit object, and should be duration values. We can continue the example and add a minimum up time for the unit:

  • unit_1
    • number_of_units: 2
    • unit_online_variable_type: "unit_online_variable_type_integer"
    • min_up_time: 2h
  • unit_1_to__node_1
    • minimum_operating_point: 0.2
    • unit_capacity: 200

Whereas the units_on variable was restricted (before inclusion of the min_up_time parameter) to be smaller than or equal to the number_of_units for any timestep $t$, it now has to be smaller than or equal to the number_of_units decremented with the units_started_up summed over the timesteps that include t - min_up_time. This implies that a unit which has started up, has to stay online for at least the min_up_time

To consider a simple example let's assume that we have a model with a resolution of 1h. Suppose that before t, there is no member of the unit online and in timestep t -> t + 1h, one member starts up. Another member starts up in timestep t + 1h \-> t + 2h. The first startup, along with the minimum up time of 2 hours implies that the units_on variable of this unit has now changed to $1$ in timestep t -> t + 1h and can not go back to $0$ in timestep t-> t + 1h -> t + 2h. The second startup further restricts the number of units that are allowed to be online, it can be seen that the following restrictions apply when both startups are combined with the minimum up time of 2h:

  • t-> t + 1h : $units\_on = 1$
  • t + 1h -> t + 2h: $units\_on = 2$
  • t + 2h-> t + 3h: $units\_on \in {1,2}$
  • t + 3h-> t + 4h: $units\_on \in {0,1,2}$

The minimum down time restrictions operate in very much the same way, they simply impose that units that have been shut down, have to stay offline for the chosen period of time.

Step 5: allocationg a cost to startups or shutdowns

Costs can be allocated to startups or shutdowns by choosing a value for the start_up_cost or shut_down_cost respectively.

Step 6: defining unit availabilities

By defining a unit_availability_factor, the fact that typical members are not available all the time can be reflected in the model.

Typically, units are not available $100$% of the time, due to scheduled maintenance, unforeseen outages, or other things. This can be incorporated in the model by setting the unit_availability_factor to a fractional value. For each timestep in the model, an upper bound is then imposed on the units_on variable, equal to number_of_units $*$ unit_availability_factor. This parameter can not be used when the online_variable_type is binary. It should also be noted that when the online_variable_type is of integer type, the aforementioned product must be integer as well, since it will determine the value of the units_available parameter which is restricted to integer values. The default value for this parameter is $1$.

The unit_availability_factor can also be taken as a timeseries. By allowing a different availability factor for each timestep in the model, it can perfectly be used to represent intermittent technologies of which the output cannot be fully controlled.

diff --git a/dev/advanced_concepts/user_constraints/index.html b/dev/advanced_concepts/user_constraints/index.html index a96debd590..ff925ef035 100644 --- a/dev/advanced_concepts/user_constraints/index.html +++ b/dev/advanced_concepts/user_constraints/index.html @@ -1,2 +1,2 @@ -User Constraints · SpineOpt.jl
GitHub

User Constraints

User constraints allow the user to define arbitrary linear constraints involving most of the problem variables. This section describes this function and how to use it.

Key User Constraint Concepts

  1. The basic principle: The basic steps involved in forming a user constraint are:
  • Creating a user constraint object: One creates a new user_constraint object which will be used as a unique handle for the specific constraint and on which constraint-level parameters will be defined.
  • Specify which variables are involved in the constraint: this generally involves creating a relationship involving the user_constraint object. For example, specifying the relationship unit__from_node__user_constraint specifies that the corresponding unit_flow variable is involved in the constraint. The table below contains a complete list of variables and the corresponding relationships to set.
  • Specify the variable coefficients: this will generally involve specifying a parameter named *_coefficient on the relationship defined above to specify the coefficient on that particular variable in the constraint. For example, to define the coefficient on the unit_flow variable, one specifies the unit_flow_coefficient parameter on the approrpriate unit__from_node__user_constraint relationship. The table below contains a complete list of variables and the corresponding coefficient parameters to set.
  • Specify the right-hand-side constant term: The constraint should be formed in conventional form with all constant terms moved to the right-hand side. The right-hand-side constant term is specified by setting the right_hand_side user_constraint parameter.
    • Specify the constraint sense: this is done by setting the constraint_sense user_constraint parameter. The allowed values are ==, >= and <=.
    • Coefficients can be defined on some parameters themselves. For example, one may specify a coefficient on a node's demand parameter. This is done by specifying the relationship node__user_constraint and specifying the demand_coefficient parameter on that relationship
  1. Piecewise unit_flow coefficients: As described in operating_points, specifying this parameter decomposes the unit_flow variable into a number of sub operating segment variables named unit_flow_op in the model and with an additional index, i for the operating segment. The intention of this functionality is to allow unit_flow coefficients to be defined individually per segment to define a piecewise linear function. To accomplish this, the steps are as described above with the exception that one must define operating_points on the appropriate unit__from_node or unit__to_node as an array type with the dimension corresponding to the number of operating points and then set the unit_flow_coefficient for the appropriate unit__from_node__user_constraint relationship, also as an array type with the same number of elements. Note that if operating points is defined as an array type with more than one elements, unit_flow_coefficient may be defined as either an array or non-array type. However, if operating_points is of non-array type, corresponding unit_flow_coefficients must also be of non-array types.
  2. Variables, relationships and coefficient guide for user constraints The table below provides guidance regarding what relationships and coefficients to set for various problem variables and parameters.
Problem variable / Parameter NameRelationshipParameter
unit_flow (direction=from_node)unit__from_node__user_constraintunit_flow_coefficient (non-array type)
unit_flow (direction=to_node)unit__to_node__user_constraintunit_flow_coefficient (non-array type)
unit_flow_op (direction=from_node)unit__from_node__user_constraintunit_flow_coefficient (array type)
unit_flow_op (direction=to_node)unit__to_node__user_constraintunit_flow_coefficient (array type)
connection_flow (direction=from_node)connection__from_node__user_constraintconnection_flow_coefficient
connection_flow (direction=to_node)connection__to_node__user_constraintconnection_flow_coefficient
node_statenode__user_constraintnode_state_coefficient
storages_investednode__user_constraintstorages_invested_coefficient
storages_invested_availablenode__user_constraintstorages_invested_available_coefficient
demandnode__user_constraintdemand_coefficient
units_onunit__user_constraintunits_on_coefficient
units_started_upunit__user_constraintunits_started_up_coefficient
units_investedunit__user_constraintunits_invested_coefficient
units_invested_availableunit__user_constraintunits_invested_available_coefficient
connections_investedconnection__user_constraintconnections_invested_coefficient
connections_invested_availableconnection__user_constraintconnections_invested_available_coefficient
+User Constraints · SpineOpt.jl
GitHub

User Constraints

User constraints allow the user to define arbitrary linear constraints involving most of the problem variables. This section describes this function and how to use it.

Key User Constraint Concepts

  1. The basic principle: The basic steps involved in forming a user constraint are:
  • Creating a user constraint object: One creates a new user_constraint object which will be used as a unique handle for the specific constraint and on which constraint-level parameters will be defined.
  • Specify which variables are involved in the constraint: this generally involves creating a relationship involving the user_constraint object. For example, specifying the relationship unit__from_node__user_constraint specifies that the corresponding unit_flow variable is involved in the constraint. The table below contains a complete list of variables and the corresponding relationships to set.
  • Specify the variable coefficients: this will generally involve specifying a parameter named *_coefficient on the relationship defined above to specify the coefficient on that particular variable in the constraint. For example, to define the coefficient on the unit_flow variable, one specifies the unit_flow_coefficient parameter on the approrpriate unit__from_node__user_constraint relationship. The table below contains a complete list of variables and the corresponding coefficient parameters to set.
  • Specify the right-hand-side constant term: The constraint should be formed in conventional form with all constant terms moved to the right-hand side. The right-hand-side constant term is specified by setting the right_hand_side user_constraint parameter.
    • Specify the constraint sense: this is done by setting the constraint_sense user_constraint parameter. The allowed values are ==, >= and <=.
    • Coefficients can be defined on some parameters themselves. For example, one may specify a coefficient on a node's demand parameter. This is done by specifying the relationship node__user_constraint and specifying the demand_coefficient parameter on that relationship
  1. Piecewise unit_flow coefficients: As described in operating_points, specifying this parameter decomposes the unit_flow variable into a number of sub operating segment variables named unit_flow_op in the model and with an additional index, i for the operating segment. The intention of this functionality is to allow unit_flow coefficients to be defined individually per segment to define a piecewise linear function. To accomplish this, the steps are as described above with the exception that one must define operating_points on the appropriate unit__from_node or unit__to_node as an array type with the dimension corresponding to the number of operating points and then set the unit_flow_coefficient for the appropriate unit__from_node__user_constraint relationship, also as an array type with the same number of elements. Note that if operating points is defined as an array type with more than one elements, unit_flow_coefficient may be defined as either an array or non-array type. However, if operating_points is of non-array type, corresponding unit_flow_coefficients must also be of non-array types.
  2. Variables, relationships and coefficient guide for user constraints The table below provides guidance regarding what relationships and coefficients to set for various problem variables and parameters.
Problem variable / Parameter NameRelationshipParameter
unit_flow (direction=from_node)unit__from_node__user_constraintunit_flow_coefficient (non-array type)
unit_flow (direction=to_node)unit__to_node__user_constraintunit_flow_coefficient (non-array type)
unit_flow_op (direction=from_node)unit__from_node__user_constraintunit_flow_coefficient (array type)
unit_flow_op (direction=to_node)unit__to_node__user_constraintunit_flow_coefficient (array type)
connection_flow (direction=from_node)connection__from_node__user_constraintconnection_flow_coefficient
connection_flow (direction=to_node)connection__to_node__user_constraintconnection_flow_coefficient
node_statenode__user_constraintnode_state_coefficient
storages_investednode__user_constraintstorages_invested_coefficient
storages_invested_availablenode__user_constraintstorages_invested_available_coefficient
demandnode__user_constraintdemand_coefficient
units_onunit__user_constraintunits_on_coefficient
units_started_upunit__user_constraintunits_started_up_coefficient
units_investedunit__user_constraintunits_invested_coefficient
units_invested_availableunit__user_constraintunits_invested_available_coefficient
connections_investedconnection__user_constraintconnections_invested_coefficient
connections_invested_availableconnection__user_constraintconnections_invested_available_coefficient
diff --git a/dev/concept_reference/Object Classes/index.html b/dev/concept_reference/Object Classes/index.html index d7a16ac5c9..1eadf35a8e 100644 --- a/dev/concept_reference/Object Classes/index.html +++ b/dev/concept_reference/Object Classes/index.html @@ -1,2 +1,2 @@ -Object Classes · SpineOpt.jl
GitHub

Object Classes

commodity

A good or product that can be consumed, produced, traded. E.g., electricity, oil, gas, water...

Related Parameters: commodity_lodf_tolerance, commodity_physics, commodity_ptdf_threshold, is_active, mp_min_res_gen_to_demand_ratio_slack_penalty and mp_min_res_gen_to_demand_ratio

Related Relationship Classes: node__commodity and unit__commodity

Commodities correspond to the type of energy traded. When associated with a node through the node__commodity relationship, a specific form of energy, i.e. commodity, can be associated with a specific location. Furthermore, by linking commodities with units, it is possible to track the flows of a certain commodity and impose limitations on the use of a certain commodity (See also max_cum_in_unit_flow_bound). For the representation of specific commodity physics, related to e.g. the representation of the electric network, designated parameters can be defined to enforce commodity specific behaviour. (See also commodity_physics)

connection

A transfer of commodities between nodes. E.g. electricity line, gas pipeline...

Related Parameters: benders_starting_connections_invested, candidate_connections, connection_availability_factor, connection_contingency, connection_investment_cost, connection_investment_lifetime, connection_investment_variable_type, connection_monitored, connection_reactance_base, connection_reactance, connection_resistance, connection_type, connections_invested_big_m_mga, connections_invested_mga_weight, connections_invested_mga, fix_connections_invested_available, fix_connections_invested, forced_availability_factor, graph_view_position, has_binary_gas_flow, initial_connections_invested_available, initial_connections_invested and is_active

Related Relationship Classes: connection__from_node__investment_group, connection__from_node__user_constraint, connection__from_node, connection__investment_group, connection__investment_stochastic_structure, connection__investment_temporal_block, connection__node__node, connection__to_node__investment_group, connection__to_node__user_constraint, connection__to_node and connection__user_constraint

A connection represents a transfer of one commodity over space. For example, an electricity transmission line, a gas pipe, a river branch, can be modelled using a connection.

A connection always takes commodities from one or more nodes, and releases them to one or more (possibly the same) nodes. The former are specificed through the connection__from_node relationship, and the latter through connection__to_node. Every connection inherits the temporal and stochastic structures from the associated nodes. The model will generate connection_flow variables for every combination of connection, node, direction (from node or to node), time slice, and stochastic scenario, according to the above relationships.

The operation of the connection is specified through a number of parameter values. For example, the capacity of the connection, as the maximum amount of energy that can enter or leave it, is given by connection_capacity. The conversion ratio of input to output can be specified using any of fix_ratio_out_in_connection_flow, max_ratio_out_in_connection_flow, and min_ratio_out_in_connection_flow parameters in the connection__node__node relationship. The delay on a connection, as the time it takes for the energy to go from one end to the other, is given by connection_flow_delay.

investment_group

A group of investments that need to be done together.

Related Parameters: equal_investments, maximum_capacity_invested_available, maximum_entities_invested_available, minimum_capacity_invested_available and minimum_entities_invested_available

Related Relationship Classes: connection__from_node__investment_group, connection__investment_group, connection__to_node__investment_group, node__investment_group, unit__from_node__investment_group, unit__investment_group and unit__to_node__investment_group

The investment_group class represents a group of investments that need to be done together. For example, a storage investment on a node might only make sense if done together with a unit or a connection investment.

To use this functionality, you must first create an investment_group and then specify any number of unit__investment_group, node__investment_group, and/or connection__investment_group relationships between your investment_group and the unit, node, and/or connection investments that you want to be done together. This will ensure that the investment variables of all the entities in the investment_group have the same value.

model

An instance of SpineOpt, that specifies general parameters such as the temporal horizon.

Related Parameters: big_m, db_lp_solver_options, db_lp_solver, db_mip_solver_options, db_mip_solver, duration_unit, is_active, max_gap, max_iterations, max_mga_iterations, max_mga_slack, min_iterations, model_end, model_start, model_type, roll_forward, window_duration, window_weight, write_lodf_file, write_mps_file and write_ptdf_file

Related Relationship Classes: model__default_investment_stochastic_structure, model__default_investment_temporal_block, model__default_stochastic_structure, model__default_temporal_block, model__report, model__stochastic_structure and model__temporal_block

The model object holds general information about the optimization problem at hand. Firstly, the modelling horizon is specified on the model object, i.e. the scope of the optimization model, and if applicable the duration of the rolling window (see also model_start, model_end and roll_forward). Secondly, the model works as an overarching assembler - only through linking temporal_blocks and stochastic_structures to a model object via relationships, they become part of the optimization problem, and respectively linked nodes, connections and units. If desired the user can also specify defaults for temporals and stochastic via the designated default relationships (see e.g., model__default_temporal_block). In this case, the default temporal is populated for missing node__temporal_block relationships. Lastly, the model object contains information about the algorithm used for solving the problem (see model_type).

node

A universal aggregator of commodify flows over units and connections, with storage capabilities.

Related Parameters: balance_type, benders_starting_storages_invested, candidate_storages, demand, downward_reserve, fix_node_pressure, fix_node_state, fix_node_voltage_angle, fix_storages_invested_available, fix_storages_invested, frac_state_loss, fractional_demand, graph_view_position, has_pressure, has_state, has_voltage_angle, initial_node_pressure, initial_node_state, initial_node_voltage_angle, initial_storages_invested_available, initial_storages_invested, is_active, is_non_spinning, is_reserve_node, max_node_pressure, max_voltage_angle, min_node_pressure, min_voltage_angle, minimum_reserve_activation_time, nodal_balance_sense, node_opf_type, node_slack_penalty, node_state_cap, node_state_min, state_coeff, storage_investment_cost, storage_investment_lifetime, storage_investment_variable_type, storages_invested_big_m_mga, storages_invested_mga_weight, storages_invested_mga, tax_in_unit_flow, tax_net_unit_flow, tax_out_unit_flow and upward_reserve

Related Relationship Classes: connection__from_node__investment_group, connection__from_node__user_constraint, connection__from_node, connection__node__node, connection__to_node__investment_group, connection__to_node__user_constraint, connection__to_node, node__commodity, node__investment_group, node__investment_stochastic_structure, node__investment_temporal_block, node__node, node__stochastic_structure, node__temporal_block, node__user_constraint, unit__from_node__investment_group, unit__from_node__user_constraint, unit__from_node, unit__node__node, unit__to_node__investment_group, unit__to_node__user_constraint and unit__to_node

The node is perhaps the most important object class out of the Systemic object classes, as it is what connects the rest together via the Systemic relationship classes. Essentially, nodes act as points in the modelled commodity network where commodity balance is enforced via the node balance and node injection constraints, tying together the inputs and outputs from units and connections, as well as any external demand. Furthermore, nodes play a crucial role for defining the temporal and stochastic structures of the model via the node__temporal_block and node__stochastic_structure relationships. For more details about the Temporal Framework and the Stochastic Framework, please refer to the dedicated sections.

Since nodes act as the points where commodity balance is enforced, this also makes them a natural fit for implementing storage. The has_state parameter controls whether a node has a node_state variable, which essentially represents the commodity content of the node. The state_coeff parameter tells how the node_state variable relates to all the commodity flows. Storage losses are handled via the frac_state_loss parameter, and potential diffusion of commodity content to other nodes via the diff_coeff parameter for the node__node relationship.

output

A variable name from SpineOpt that can be included in a report.

Related Parameters: is_active and output_resolution

Related Relationship Classes: report__output

An output is essentially a handle for a SpineOpt variable and Objective function to be included in a report and written into an output database. Typically, e.g. the unit_flow variables are desired as output from most models, so creating an output object called unit_flow allows one to designate it as something to be written in the desired report. Note that unless appropriate model__report and report__output relationships are defined, SpineOpt doesn't write any output!

report

A results report from a particular SpineOpt run, including the value of specific variables.

Related Parameters: is_active and output_db_url

Related Relationship Classes: model__report and report__output

A report is essentially a group of outputs from a model, that gets written into the output database as a result of running SpineOpt. Note that unless appropriate model__report and report__output relationships are defined, SpineOpt doesn't write any output!

settings

Internal SpineOpt settings. We kindly advise not to mess with this one.

Related Parameters: version

TODO

stochastic_scenario

A scenario for stochastic optimisation in SpineOpt.

Related Parameters: is_active

Related Relationship Classes: parent_stochastic_scenario__child_stochastic_scenario and stochastic_structure__stochastic_scenario

Essentially, a stochastic_scenario is a label for an alternative period of time, describing one possibility of what might come to pass. They are the basic building blocks of the scenario-based Stochastic Framework in SpineOpt.jl, but aren't really meaningful on their own. Only when combined into a stochastic_structure using the stochastic_structure__stochastic_scenario and parent_stochastic_scenario__child_stochastic_scenario relationships, along with Parameters like the weight_relative_to_parents and stochastic_scenario_end, they become meaningful.

stochastic_structure

A group of stochastic scenarios that represent a structure.

Related Parameters: is_active

Related Relationship Classes: connection__investment_stochastic_structure, model__default_investment_stochastic_structure, model__default_stochastic_structure, model__stochastic_structure, node__investment_stochastic_structure, node__stochastic_structure, stochastic_structure__stochastic_scenario, unit__investment_stochastic_structure and units_on__stochastic_structure

The stochastic_structure is the key component of the scenario-based Stochastic Framework in SpineOpt.jl, and essentially represents a group of stochastic_scenarios with set Parameters. The stochastic_structure__stochastic_scenario relationship defines which stochastic_scenarios are included in which stochastic_structures, and the weight_relative_to_parents and stochastic_scenario_end Parameters define the exact shape and impact of the stochastic_structure, along with the parent_stochastic_scenario__child_stochastic_scenario relationship.

The main reason as to why stochastic_structures are so important is, that they act as handles connecting the Stochastic Framework to the modelled system. This is handled using the Structural relationship classes e.g. node__stochastic_structure, which define the stochastic_structure applied to each object describing the modelled system. Connecting each system object to the appropriate stochastic_structure individually can be a bit bothersome at times, so there are also a number of convenience Meta relationship classes like the model__default_stochastic_structure, which allow setting model-wide defaults to be used whenever specific definitions are missing.

temporal_block

A length of time with a particular resolution.

Related Parameters: block_end, block_start, is_active, representative_periods_mapping, resolution and weight

Related Relationship Classes: connection__investment_temporal_block, model__default_investment_temporal_block, model__default_temporal_block, model__temporal_block, node__investment_temporal_block, node__temporal_block, unit__investment_temporal_block and units_on__temporal_block

A temporal block defines the temporal properties of the optimization that is to be solved in the current window. It is the key building block of the Temporal Framework. Most importantly, it holds the necessary information about the resolution and horizon of the optimization. A single model can have multiple temporal blocks, which is one of the main sources of temporal flexibility in Spine: by linking different parts of the model to different temporal blocks, a single model can contain aspects that are solved with different temporal resolutions or time horizons.

unit

A conversion of one/many comodities between nodes.

Related Parameters: benders_starting_units_invested, candidate_units, curtailment_cost, fix_units_invested_available, fix_units_invested, fix_units_on, fom_cost, forced_availability_factor, graph_view_position, initial_units_invested_available, initial_units_invested, initial_units_on, is_active, is_renewable, min_down_time, min_up_time, number_of_units, online_variable_type, shut_down_cost, start_up_cost, unit_availability_factor, unit_investment_cost, unit_investment_lifetime, unit_investment_variable_type, units_invested_big_m_mga, units_invested_mga_weight, units_invested_mga, units_on_cost, units_on_non_anticipativity_margin and units_on_non_anticipativity_time

Related Relationship Classes: unit__commodity, unit__from_node__investment_group, unit__from_node__user_constraint, unit__from_node, unit__investment_group, unit__investment_stochastic_structure, unit__investment_temporal_block, unit__node__node, unit__to_node__investment_group, unit__to_node__user_constraint, unit__to_node, unit__user_constraint, units_on__stochastic_structure and units_on__temporal_block

A unit represents an energy conversion process, where energy of one commodity can be converted into energy of another commodity. For example, a gas turbine, a power plant, or even a load, can be modelled using a unit.

A unit always takes energy from one or more nodes, and releases energy to one or more (possibly the same) nodes. The former are specificed through the unit__from_node relationship, and the latter through unit__to_node. Every unit has a temporal and stochastic structures given by the units_on__temporal_block and [units_on__stochastic_structure] relationships. The model will generate unit_flow variables for every combination of unit, node, direction (from node or to node), time slice, and stochastic scenario, according to the above relationships.

The operation of the unit is specified through a number of parameter values. For example, the capacity of the unit, as the maximum amount of energy that can enter or leave it, is given by unit_capacity. The conversion ratio of input to output can be specified using any of fix_ratio_out_in_unit_flow, max_ratio_out_in_unit_flow, and min_ratio_out_in_unit_flow. The variable operating cost is given by vom_cost.

user_constraint

A generic data-driven custom constraint.

Related Parameters: constraint_sense, is_active and right_hand_side

Related Relationship Classes: connection__from_node__user_constraint, connection__to_node__user_constraint, connection__user_constraint, node__user_constraint, unit__from_node__user_constraint, unit__to_node__user_constraint and unit__user_constraint

The user_constraint is a generic data-driven custom constraint, which allows for defining constraints involving multiple units, nodes, or connections. The constraint_sense parameter changes the sense of the user_constraint, while the right_hand_side parameter allows for defining the constant terms of the constraint.

Coefficients for the different variables appearing in the user_constraint are defined using relationships, like e.g. unit__from_node__user_constraint and connection__to_node__user_constraint for unit_flow and connection_flow variables, or unit__user_constraint and node__user_constraint for units_on, units_started_up, and node_state variables.

For more information, see the dedicated article on User Constraints

+Object Classes · SpineOpt.jl
GitHub

Object Classes

commodity

A good or product that can be consumed, produced, traded. E.g., electricity, oil, gas, water...

Related Parameters: commodity_lodf_tolerance, commodity_physics, commodity_ptdf_threshold, is_active, mp_min_res_gen_to_demand_ratio_slack_penalty and mp_min_res_gen_to_demand_ratio

Related Relationship Classes: node__commodity and unit__commodity

Commodities correspond to the type of energy traded. When associated with a node through the node__commodity relationship, a specific form of energy, i.e. commodity, can be associated with a specific location. Furthermore, by linking commodities with units, it is possible to track the flows of a certain commodity and impose limitations on the use of a certain commodity (See also max_cum_in_unit_flow_bound). For the representation of specific commodity physics, related to e.g. the representation of the electric network, designated parameters can be defined to enforce commodity specific behaviour. (See also commodity_physics)

connection

A transfer of commodities between nodes. E.g. electricity line, gas pipeline...

Related Parameters: benders_starting_connections_invested, candidate_connections, connection_availability_factor, connection_contingency, connection_investment_cost, connection_investment_lifetime, connection_investment_variable_type, connection_monitored, connection_reactance_base, connection_reactance, connection_resistance, connection_type, connections_invested_big_m_mga, connections_invested_mga_weight, connections_invested_mga, fix_connections_invested_available, fix_connections_invested, forced_availability_factor, graph_view_position, has_binary_gas_flow, initial_connections_invested_available, initial_connections_invested and is_active

Related Relationship Classes: connection__from_node__investment_group, connection__from_node__user_constraint, connection__from_node, connection__investment_group, connection__investment_stochastic_structure, connection__investment_temporal_block, connection__node__node, connection__to_node__investment_group, connection__to_node__user_constraint, connection__to_node and connection__user_constraint

A connection represents a transfer of one commodity over space. For example, an electricity transmission line, a gas pipe, a river branch, can be modelled using a connection.

A connection always takes commodities from one or more nodes, and releases them to one or more (possibly the same) nodes. The former are specificed through the connection__from_node relationship, and the latter through connection__to_node. Every connection inherits the temporal and stochastic structures from the associated nodes. The model will generate connection_flow variables for every combination of connection, node, direction (from node or to node), time slice, and stochastic scenario, according to the above relationships.

The operation of the connection is specified through a number of parameter values. For example, the capacity of the connection, as the maximum amount of energy that can enter or leave it, is given by connection_capacity. The conversion ratio of input to output can be specified using any of fix_ratio_out_in_connection_flow, max_ratio_out_in_connection_flow, and min_ratio_out_in_connection_flow parameters in the connection__node__node relationship. The delay on a connection, as the time it takes for the energy to go from one end to the other, is given by connection_flow_delay.

investment_group

A group of investments that need to be done together.

Related Parameters: equal_investments, maximum_capacity_invested_available, maximum_entities_invested_available, minimum_capacity_invested_available and minimum_entities_invested_available

Related Relationship Classes: connection__from_node__investment_group, connection__investment_group, connection__to_node__investment_group, node__investment_group, unit__from_node__investment_group, unit__investment_group and unit__to_node__investment_group

The investment_group class represents a group of investments that need to be done together. For example, a storage investment on a node might only make sense if done together with a unit or a connection investment.

To use this functionality, you must first create an investment_group and then specify any number of unit__investment_group, node__investment_group, and/or connection__investment_group relationships between your investment_group and the unit, node, and/or connection investments that you want to be done together. This will ensure that the investment variables of all the entities in the investment_group have the same value.

model

An instance of SpineOpt, that specifies general parameters such as the temporal horizon.

Related Parameters: big_m, db_lp_solver_options, db_lp_solver, db_mip_solver_options, db_mip_solver, duration_unit, is_active, max_gap, max_iterations, max_mga_iterations, max_mga_slack, min_iterations, model_end, model_start, model_type, roll_forward, window_duration, window_weight, write_lodf_file, write_mps_file and write_ptdf_file

Related Relationship Classes: model__default_investment_stochastic_structure, model__default_investment_temporal_block, model__default_stochastic_structure, model__default_temporal_block, model__report, model__stochastic_structure and model__temporal_block

The model object holds general information about the optimization problem at hand. Firstly, the modelling horizon is specified on the model object, i.e. the scope of the optimization model, and if applicable the duration of the rolling window (see also model_start, model_end and roll_forward). Secondly, the model works as an overarching assembler - only through linking temporal_blocks and stochastic_structures to a model object via relationships, they become part of the optimization problem, and respectively linked nodes, connections and units. If desired the user can also specify defaults for temporals and stochastic via the designated default relationships (see e.g., model__default_temporal_block). In this case, the default temporal is populated for missing node__temporal_block relationships. Lastly, the model object contains information about the algorithm used for solving the problem (see model_type).

node

A universal aggregator of commodify flows over units and connections, with storage capabilities.

Related Parameters: balance_type, benders_starting_storages_invested, candidate_storages, demand, downward_reserve, fix_node_pressure, fix_node_state, fix_node_voltage_angle, fix_storages_invested_available, fix_storages_invested, frac_state_loss, fractional_demand, graph_view_position, has_pressure, has_state, has_voltage_angle, initial_node_pressure, initial_node_state, initial_node_voltage_angle, initial_storages_invested_available, initial_storages_invested, is_active, is_non_spinning, is_reserve_node, max_node_pressure, max_voltage_angle, min_node_pressure, min_voltage_angle, minimum_reserve_activation_time, nodal_balance_sense, node_opf_type, node_slack_penalty, node_state_cap, node_state_min, state_coeff, storage_investment_cost, storage_investment_lifetime, storage_investment_variable_type, storages_invested_big_m_mga, storages_invested_mga_weight, storages_invested_mga, tax_in_unit_flow, tax_net_unit_flow, tax_out_unit_flow and upward_reserve

Related Relationship Classes: connection__from_node__investment_group, connection__from_node__user_constraint, connection__from_node, connection__node__node, connection__to_node__investment_group, connection__to_node__user_constraint, connection__to_node, node__commodity, node__investment_group, node__investment_stochastic_structure, node__investment_temporal_block, node__node, node__stochastic_structure, node__temporal_block, node__user_constraint, unit__from_node__investment_group, unit__from_node__user_constraint, unit__from_node, unit__node__node, unit__to_node__investment_group, unit__to_node__user_constraint and unit__to_node

The node is perhaps the most important object class out of the Systemic object classes, as it is what connects the rest together via the Systemic relationship classes. Essentially, nodes act as points in the modelled commodity network where commodity balance is enforced via the node balance and node injection constraints, tying together the inputs and outputs from units and connections, as well as any external demand. Furthermore, nodes play a crucial role for defining the temporal and stochastic structures of the model via the node__temporal_block and node__stochastic_structure relationships. For more details about the Temporal Framework and the Stochastic Framework, please refer to the dedicated sections.

Since nodes act as the points where commodity balance is enforced, this also makes them a natural fit for implementing storage. The has_state parameter controls whether a node has a node_state variable, which essentially represents the commodity content of the node. The state_coeff parameter tells how the node_state variable relates to all the commodity flows. Storage losses are handled via the frac_state_loss parameter, and potential diffusion of commodity content to other nodes via the diff_coeff parameter for the node__node relationship.

output

A variable name from SpineOpt that can be included in a report.

Related Parameters: is_active and output_resolution

Related Relationship Classes: report__output

An output is essentially a handle for a SpineOpt variable and Objective function to be included in a report and written into an output database. Typically, e.g. the unit_flow variables are desired as output from most models, so creating an output object called unit_flow allows one to designate it as something to be written in the desired report. Note that unless appropriate model__report and report__output relationships are defined, SpineOpt doesn't write any output!

report

A results report from a particular SpineOpt run, including the value of specific variables.

Related Parameters: is_active and output_db_url

Related Relationship Classes: model__report and report__output

A report is essentially a group of outputs from a model, that gets written into the output database as a result of running SpineOpt. Note that unless appropriate model__report and report__output relationships are defined, SpineOpt doesn't write any output!

settings

Internal SpineOpt settings. We kindly advise not to mess with this one.

Related Parameters: version

TODO

stochastic_scenario

A scenario for stochastic optimisation in SpineOpt.

Related Parameters: is_active

Related Relationship Classes: parent_stochastic_scenario__child_stochastic_scenario and stochastic_structure__stochastic_scenario

Essentially, a stochastic_scenario is a label for an alternative period of time, describing one possibility of what might come to pass. They are the basic building blocks of the scenario-based Stochastic Framework in SpineOpt.jl, but aren't really meaningful on their own. Only when combined into a stochastic_structure using the stochastic_structure__stochastic_scenario and parent_stochastic_scenario__child_stochastic_scenario relationships, along with Parameters like the weight_relative_to_parents and stochastic_scenario_end, they become meaningful.

stochastic_structure

A group of stochastic scenarios that represent a structure.

Related Parameters: is_active

Related Relationship Classes: connection__investment_stochastic_structure, model__default_investment_stochastic_structure, model__default_stochastic_structure, model__stochastic_structure, node__investment_stochastic_structure, node__stochastic_structure, stochastic_structure__stochastic_scenario, unit__investment_stochastic_structure and units_on__stochastic_structure

The stochastic_structure is the key component of the scenario-based Stochastic Framework in SpineOpt.jl, and essentially represents a group of stochastic_scenarios with set Parameters. The stochastic_structure__stochastic_scenario relationship defines which stochastic_scenarios are included in which stochastic_structures, and the weight_relative_to_parents and stochastic_scenario_end Parameters define the exact shape and impact of the stochastic_structure, along with the parent_stochastic_scenario__child_stochastic_scenario relationship.

The main reason as to why stochastic_structures are so important is, that they act as handles connecting the Stochastic Framework to the modelled system. This is handled using the Structural relationship classes e.g. node__stochastic_structure, which define the stochastic_structure applied to each object describing the modelled system. Connecting each system object to the appropriate stochastic_structure individually can be a bit bothersome at times, so there are also a number of convenience Meta relationship classes like the model__default_stochastic_structure, which allow setting model-wide defaults to be used whenever specific definitions are missing.

temporal_block

A length of time with a particular resolution.

Related Parameters: block_end, block_start, is_active, representative_periods_mapping, resolution and weight

Related Relationship Classes: connection__investment_temporal_block, model__default_investment_temporal_block, model__default_temporal_block, model__temporal_block, node__investment_temporal_block, node__temporal_block, unit__investment_temporal_block and units_on__temporal_block

A temporal block defines the temporal properties of the optimization that is to be solved in the current window. It is the key building block of the Temporal Framework. Most importantly, it holds the necessary information about the resolution and horizon of the optimization. A single model can have multiple temporal blocks, which is one of the main sources of temporal flexibility in Spine: by linking different parts of the model to different temporal blocks, a single model can contain aspects that are solved with different temporal resolutions or time horizons.

unit

A conversion of one/many comodities between nodes.

Related Parameters: benders_starting_units_invested, candidate_units, curtailment_cost, fix_units_invested_available, fix_units_invested, fix_units_on, fom_cost, forced_availability_factor, graph_view_position, initial_units_invested_available, initial_units_invested, initial_units_on, is_active, is_renewable, min_down_time, min_up_time, number_of_units, online_variable_type, shut_down_cost, start_up_cost, unit_availability_factor, unit_investment_cost, unit_investment_lifetime, unit_investment_variable_type, units_invested_big_m_mga, units_invested_mga_weight, units_invested_mga, units_on_cost, units_on_non_anticipativity_margin and units_on_non_anticipativity_time

Related Relationship Classes: unit__commodity, unit__from_node__investment_group, unit__from_node__user_constraint, unit__from_node, unit__investment_group, unit__investment_stochastic_structure, unit__investment_temporal_block, unit__node__node, unit__to_node__investment_group, unit__to_node__user_constraint, unit__to_node, unit__user_constraint, units_on__stochastic_structure and units_on__temporal_block

A unit represents an energy conversion process, where energy of one commodity can be converted into energy of another commodity. For example, a gas turbine, a power plant, or even a load, can be modelled using a unit.

A unit always takes energy from one or more nodes, and releases energy to one or more (possibly the same) nodes. The former are specificed through the unit__from_node relationship, and the latter through unit__to_node. Every unit has a temporal and stochastic structures given by the units_on__temporal_block and [units_on__stochastic_structure] relationships. The model will generate unit_flow variables for every combination of unit, node, direction (from node or to node), time slice, and stochastic scenario, according to the above relationships.

The operation of the unit is specified through a number of parameter values. For example, the capacity of the unit, as the maximum amount of energy that can enter or leave it, is given by unit_capacity. The conversion ratio of input to output can be specified using any of fix_ratio_out_in_unit_flow, max_ratio_out_in_unit_flow, and min_ratio_out_in_unit_flow. The variable operating cost is given by vom_cost.

user_constraint

A generic data-driven custom constraint.

Related Parameters: constraint_sense, is_active and right_hand_side

Related Relationship Classes: connection__from_node__user_constraint, connection__to_node__user_constraint, connection__user_constraint, node__user_constraint, unit__from_node__user_constraint, unit__to_node__user_constraint and unit__user_constraint

The user_constraint is a generic data-driven custom constraint, which allows for defining constraints involving multiple units, nodes, or connections. The constraint_sense parameter changes the sense of the user_constraint, while the right_hand_side parameter allows for defining the constant terms of the constraint.

Coefficients for the different variables appearing in the user_constraint are defined using relationships, like e.g. unit__from_node__user_constraint and connection__to_node__user_constraint for unit_flow and connection_flow variables, or unit__user_constraint and node__user_constraint for units_on, units_started_up, and node_state variables.

For more information, see the dedicated article on User Constraints

diff --git a/dev/concept_reference/Parameter Value Lists/index.html b/dev/concept_reference/Parameter Value Lists/index.html index e0e80737ac..a12d0c62a2 100644 --- a/dev/concept_reference/Parameter Value Lists/index.html +++ b/dev/concept_reference/Parameter Value Lists/index.html @@ -1,2 +1,2 @@ -Parameter Value Lists · SpineOpt.jl
GitHub

Parameter Value Lists

balance_type_list

Possible values: balance_type_group, balance_type_node and balance_type_none

The balance_type_list parameter value list contains the possible values for the balance_type parameter.

boolean_value_list

Possible values: false and true

A list of boolean values (True or False).

commodity_physics_list

Possible values: commodity_physics_lodf, commodity_physics_none and commodity_physics_ptdf

commodity_physics_list holds the possible values for the commodity parameter commodity_physics parameter. See commodity_physics for more details

connection_investment_variable_type_list

Possible values: connection_investment_variable_type_continuous and connection_investment_variable_type_integer

The connection_investment_variable_type_list holds the possible values for the type of a connection's investment variable which may be chosen between integer or continuous.

connection_type_list

Possible values: connection_type_lossless_bidirectional and connection_type_normal

connection_type_list holds the possible values for the connection_type parameter. See connection_type for more details

constraint_sense_list

Possible values: <=, == and >=

The constraint_sense_list parameter value list contains the possible values for the constraint_sense parameter.

db_lp_solver_list

Possible values: CDCS.jl, CDDLib.jl, COSMO.jl, CPLEX.jl, CSDP.jl, Clp.jl, ECOS.jl, GLPK.jl, Gurobi.jl, HiGHS.jl, Hypatia.jl, Ipopt.jl, KNITRO.jl, MadNLP.jl, MosekTools.jl, NLopt.jl, OSQP.jl, ProxSDP.jl, SCIP.jl, SCS.jl, SDPA.jl, SDPNAL.jl, SDPT3.jl, SeDuMi.jl and Xpress.jl

List of supported LP solvers which may be specified for the db_lp_solver_options parameter. The value must correspond exactly to the name of the Julia solver package (e.g. Clp.jl) and is case sensitive.

db_mip_solver_list

Possible values: CPLEX.jl, Cbc.jl, GLPK.jl, Gurobi.jl, HiGHS.jl, Juniper.jl, KNITRO.jl, MosekTools.jl, SCIP.jl and Xpress.jl

List of supported MIP solvers which may be specified for the db_mip_solver_options parameter. The value must correspond exactly to the name of the Julia solver package (e.g. Cbc.jl) and is case sensitive.

duration_unit_list

Possible values: hour and minute

The duration_unit_list parameter value list contains the possible values for the duration_unit parameter.

model_type_list

Possible values: spineopt_benders, spineopt_mga, spineopt_other and spineopt_standard

model_type_list holds the possible values for the model parameter model_type parameter. See model_type for more details

node_opf_type_list

Possible values: node_opf_type_normal and node_opf_type_reference

Houses the different possible values for the node_opf_type parameter. To identify the reference node, set node_opf_type = :node_opf_type_reference, while node_opf_type = node_opf_type_normal is the default value for non-reference nodes.

See also powerflow.

unit_investment_variable_type_list

Possible values: unit_investment_variable_type_continuous and unit_investment_variable_type_integer

unit_investment_variable_type_list holds the possible values for the type of a unit's investment variable which may be chosen from integer, binary or continuous.

unit_online_variable_type_list

Possible values: unit_online_variable_type_binary, unit_online_variable_type_integer, unit_online_variable_type_linear and unit_online_variable_type_none

unit_online_variable_type_list holds the possible values for the type of a unit's commitment status variable which may be chosen from binary, integer, or linear.

variable_type_list

Possible values: variable_type_binary, variable_type_continuous and variable_type_integer

The variable_type_list parameter value list contains the possible values for the connection_investment_variable_type and storage_investment_variable_type parameters.

write_mps_file_list

Possible values: write_mps_always, write_mps_never and write_mps_on_no_solve

This parameter value list is deprecated and will be removed in a future version.

Houses the different values for the write_mps_file parameter. Possible values include write_mps_always, write\_mps\_on\_no\_solve, and write\_mps\_never.

+Parameter Value Lists · SpineOpt.jl
GitHub

Parameter Value Lists

balance_type_list

Possible values: balance_type_group, balance_type_node and balance_type_none

The balance_type_list parameter value list contains the possible values for the balance_type parameter.

boolean_value_list

Possible values: false and true

A list of boolean values (True or False).

commodity_physics_list

Possible values: commodity_physics_lodf, commodity_physics_none and commodity_physics_ptdf

commodity_physics_list holds the possible values for the commodity parameter commodity_physics parameter. See commodity_physics for more details

connection_investment_variable_type_list

Possible values: connection_investment_variable_type_continuous and connection_investment_variable_type_integer

The connection_investment_variable_type_list holds the possible values for the type of a connection's investment variable which may be chosen between integer or continuous.

connection_type_list

Possible values: connection_type_lossless_bidirectional and connection_type_normal

connection_type_list holds the possible values for the connection_type parameter. See connection_type for more details

constraint_sense_list

Possible values: <=, == and >=

The constraint_sense_list parameter value list contains the possible values for the constraint_sense parameter.

db_lp_solver_list

Possible values: CDCS.jl, CDDLib.jl, COSMO.jl, CPLEX.jl, CSDP.jl, Clp.jl, ECOS.jl, GLPK.jl, Gurobi.jl, HiGHS.jl, Hypatia.jl, Ipopt.jl, KNITRO.jl, MadNLP.jl, MosekTools.jl, NLopt.jl, OSQP.jl, ProxSDP.jl, SCIP.jl, SCS.jl, SDPA.jl, SDPNAL.jl, SDPT3.jl, SeDuMi.jl and Xpress.jl

List of supported LP solvers which may be specified for the db_lp_solver_options parameter. The value must correspond exactly to the name of the Julia solver package (e.g. Clp.jl) and is case sensitive.

db_mip_solver_list

Possible values: CPLEX.jl, Cbc.jl, GLPK.jl, Gurobi.jl, HiGHS.jl, Juniper.jl, KNITRO.jl, MosekTools.jl, SCIP.jl and Xpress.jl

List of supported MIP solvers which may be specified for the db_mip_solver_options parameter. The value must correspond exactly to the name of the Julia solver package (e.g. Cbc.jl) and is case sensitive.

duration_unit_list

Possible values: hour and minute

The duration_unit_list parameter value list contains the possible values for the duration_unit parameter.

model_type_list

Possible values: spineopt_benders, spineopt_mga, spineopt_other and spineopt_standard

model_type_list holds the possible values for the model parameter model_type parameter. See model_type for more details

node_opf_type_list

Possible values: node_opf_type_normal and node_opf_type_reference

Houses the different possible values for the node_opf_type parameter. To identify the reference node, set node_opf_type = :node_opf_type_reference, while node_opf_type = node_opf_type_normal is the default value for non-reference nodes.

See also powerflow.

unit_investment_variable_type_list

Possible values: unit_investment_variable_type_continuous and unit_investment_variable_type_integer

unit_investment_variable_type_list holds the possible values for the type of a unit's investment variable which may be chosen from integer, binary or continuous.

unit_online_variable_type_list

Possible values: unit_online_variable_type_binary, unit_online_variable_type_integer, unit_online_variable_type_linear and unit_online_variable_type_none

unit_online_variable_type_list holds the possible values for the type of a unit's commitment status variable which may be chosen from binary, integer, or linear.

variable_type_list

Possible values: variable_type_binary, variable_type_continuous and variable_type_integer

The variable_type_list parameter value list contains the possible values for the connection_investment_variable_type and storage_investment_variable_type parameters.

write_mps_file_list

Possible values: write_mps_always, write_mps_never and write_mps_on_no_solve

This parameter value list is deprecated and will be removed in a future version.

Houses the different values for the write_mps_file parameter. Possible values include write_mps_always, write\_mps\_on\_no\_solve, and write\_mps\_never.

diff --git a/dev/concept_reference/Parameters/index.html b/dev/concept_reference/Parameters/index.html index d8a0322e06..5b1c34d575 100644 --- a/dev/concept_reference/Parameters/index.html +++ b/dev/concept_reference/Parameters/index.html @@ -5,4 +5,4 @@ # If not a root `stochastic_scenario` -weight(scenario) = sum([weight(parent) * weight_relative_to_parents(scenario)] for parent in parents)

The above calculation is performed starting from the roots, generation by generation, until the leaves of the stochastic DAG. Thus, the final weight of each stochastic_scenario is dependent on the weight_relative_to_parents Parameters of all its ancestors.

window_duration

The duration of the window in case it differs from roll_forward

Related Object Classes: model

TODO

window_weight

The weight of the window in the rolling subproblem

Default value: 1

Related Object Classes: model

The window_weight parameter, defined for a model object, is used in the Benders decomposition algorithm with representative periods. In this setup, the subproblem rolls over a series of possibly disconnected windows, corresponding to the representative periods. Each of these windows can have a different weight, for example, equal to the fraction of the full model horizon that it represents. Chosing a good weigth can help the solution be more accurate.

To use weighted rolling representative periods Benders, do the following.

Note that it the problem rolls n times, then you have n + 1 windows.

write_lodf_file

A boolean flag for whether the LODF values should be written to a results file.

Default value: false

Uses Parameter Value Lists: boolean_value_list

Related Object Classes: model

If this parameter value is set to true, a diagnostics file containing all the network line outage distributions factors in CSV format will be written to the current directory.

write_mps_file

A selector for writing an .mps file of the model.

Uses Parameter Value Lists: write_mps_file_list

Related Object Classes: model

This parameter is deprecated and will be removed in a future version.

This parameter controls when to write a diagnostic model file in MPS format. If set to write_mps_always, the model will always be written in MPS format to the current directory. If set to write\_mps\_on\_no\_solve, the MPS file will be written when the model solve terminates with a status of false. If set to write\_mps\_never, no file will be written

write_ptdf_file

A boolean flag for whether the LODF values should be written to a results file.

Default value: false

Uses Parameter Value Lists: boolean_value_list

Related Object Classes: model

If this parameter value is set to true, a diagnostics file containing all the network power transfer distributions factors in CSV format will be written to the current directory.

+weight(scenario) = sum([weight(parent) * weight_relative_to_parents(scenario)] for parent in parents)

The above calculation is performed starting from the roots, generation by generation, until the leaves of the stochastic DAG. Thus, the final weight of each stochastic_scenario is dependent on the weight_relative_to_parents Parameters of all its ancestors.

window_duration

The duration of the window in case it differs from roll_forward

Related Object Classes: model

TODO

window_weight

The weight of the window in the rolling subproblem

Default value: 1

Related Object Classes: model

The window_weight parameter, defined for a model object, is used in the Benders decomposition algorithm with representative periods. In this setup, the subproblem rolls over a series of possibly disconnected windows, corresponding to the representative periods. Each of these windows can have a different weight, for example, equal to the fraction of the full model horizon that it represents. Chosing a good weigth can help the solution be more accurate.

To use weighted rolling representative periods Benders, do the following.

Note that it the problem rolls n times, then you have n + 1 windows.

write_lodf_file

A boolean flag for whether the LODF values should be written to a results file.

Default value: false

Uses Parameter Value Lists: boolean_value_list

Related Object Classes: model

If this parameter value is set to true, a diagnostics file containing all the network line outage distributions factors in CSV format will be written to the current directory.

write_mps_file

A selector for writing an .mps file of the model.

Uses Parameter Value Lists: write_mps_file_list

Related Object Classes: model

This parameter is deprecated and will be removed in a future version.

This parameter controls when to write a diagnostic model file in MPS format. If set to write_mps_always, the model will always be written in MPS format to the current directory. If set to write\_mps\_on\_no\_solve, the MPS file will be written when the model solve terminates with a status of false. If set to write\_mps\_never, no file will be written

write_ptdf_file

A boolean flag for whether the LODF values should be written to a results file.

Default value: false

Uses Parameter Value Lists: boolean_value_list

Related Object Classes: model

If this parameter value is set to true, a diagnostics file containing all the network power transfer distributions factors in CSV format will be written to the current directory.

diff --git a/dev/concept_reference/Relationship Classes/index.html b/dev/concept_reference/Relationship Classes/index.html index c370756bd4..1520e28060 100644 --- a/dev/concept_reference/Relationship Classes/index.html +++ b/dev/concept_reference/Relationship Classes/index.html @@ -1,2 +1,2 @@ -Relationship Classes · SpineOpt.jl
GitHub

Relationship Classes

connection__from_node

Defines the nodes the connection can take input from, and holds most connection_flow variable specific parameters.

Related Object Classes: connection and node

Related Parameters: connection_capacity, connection_conv_cap_to_flow, connection_emergency_capacity, connection_flow_cost, connection_flow_non_anticipativity_margin, connection_flow_non_anticipativity_time, connection_intact_flow_non_anticipativity_margin, connection_intact_flow_non_anticipativity_time, fix_binary_gas_connection_flow, fix_connection_flow, fix_connection_intact_flow, graph_view_position, initial_binary_gas_connection_flow, initial_connection_flow and initial_connection_intact_flow

connection__from_node is a two-dimensional relationship between a connection and a node and implies a connection_flow to the connection from the node. Specifying such a relationship will give rise to a connection_flow_variable with indices connection=connection, node=node, direction=:from_node. Relationships defined on this relationship will generally apply to this specific flow variable. For example, connection_capacity will apply only to this specific flow variable, unless the connection parameter connection_type is specified.

connection__from_node__investment_group

Indicates which connection capacities are included in the capacity invested available of an investment group

Related Object Classes: connection, investment_group and node

TODO

connection__from_node__user_constraint

when specified this relationship allows the relevant flow connection flow variable to be included in the specified user constraint

Related Object Classes: connection, node and user_constraint

Related Parameters: connection_flow_coefficient

TODO

connection__investment_group

Indicates that a connection belongs in an investment_group.

Related Object Classes: connection and investment_group

TODO

connection__investment_stochastic_structure

Defines the stochastic structure of the connections investments variable

Related Object Classes: connection and stochastic_structure

The connection__investment_stochastic_structure relationship defines the stochastic_structure of connection-related investment decisions. Essentially, it sets the stochastic_structure used by the connections_invested_available variable of the connection.

The connection__investment_stochastic_structure relationship uses the model__default_investment_stochastic_structure relationship if not defined.

connection__investment_temporal_block

Defines the temporal resolution of the connections investments variable

Related Object Classes: connection and temporal_block

connection__investment_temporal_block is a two-dimensional relationship between a connection and a temporal_block. This relationship defines the temporal resolution and scope of a connection's investment decision. Note that in a decomposed investments problem with two model objects, one for the master problem model and another for the operations problem model, the link to the specific model is made indirectly through the model__temporal_block relationship. If a model__default_investment_temporal_block is specified and no connection__investment_temporal_block relationship is specified, the model__default_investment_temporal_block relationship will be used. Conversely if connection__investment_temporal_block is specified along with model__temporal_block, this will override model__default_investment_temporal_block for the specified connection.

See also Investment Optimization

connection__node__node

Holds parameters spanning multiple connection_flow variables to and from multiple nodes.

Related Object Classes: connection and node

Related Parameters: compression_factor, connection_flow_delay, connection_linepack_constant, fix_ratio_out_in_connection_flow, fixed_pressure_constant_0, fixed_pressure_constant_1, max_ratio_out_in_connection_flow and min_ratio_out_in_connection_flow

connection__node__node is a three-dimensional relationship between a connection, a node (node 1) and another node (node 2). connection__node__node infers a conversion and a direction with respect to that conversion. Node 1 is assumed to be the input node and node 2 is assumed to be the output node. For example, the fix_ratio_out_in_connection_flow parameter defined on connection__node__node relates the output connection_flow to node 2 to the intput connection_flow from node 1

connection__to_node

Defines the nodes the connection can output to, and holds most connection_flow variable specific parameters.

Related Object Classes: connection and node

Related Parameters: connection_capacity, connection_conv_cap_to_flow, connection_emergency_capacity, connection_flow_cost, connection_flow_non_anticipativity_margin, connection_flow_non_anticipativity_time, connection_intact_flow_non_anticipativity_margin, connection_intact_flow_non_anticipativity_time, fix_binary_gas_connection_flow, fix_connection_flow, fix_connection_intact_flow, graph_view_position, initial_binary_gas_connection_flow, initial_connection_flow and initial_connection_intact_flow

connection__to_node is a two-dimensional relationship between a connection and a node and implies a connection_flow from the connection to the node. Specifying such a relationship will give rise to a connection_flow_variable with indices connection=connection, node=node, direction=:to_node. Relationships defined on this relationship will generally apply to this specific flow variable. For example, connection_capacity will apply only to this specific flow variable, unless the connection parameter connection_type is specified.

connection__to_node__investment_group

Indicates which connection capacities are included in the capacity invested available of an investment group

Related Object Classes: connection, investment_group and node

TODO

connection__to_node__user_constraint

when specified this relationship allows the relevant flow connection flow variable to be included in the specified user constraint

Related Object Classes: connection, node and user_constraint

Related Parameters: connection_flow_coefficient

TODO

connection__user_constraint

Relationship required to involve a connections investment variables in a user_constraint

Related Object Classes: connection and user_constraint

Related Parameters: connections_invested_available_coefficient and connections_invested_coefficient

TODO

model__default_investment_stochastic_structure

Defines the default stochastic structure used for investment variables, which will be replaced by more specific definitions

Related Object Classes: model and stochastic_structure

The model__default_investment_stochastic_structure relationship can be used to set model-wide default unit__investment_stochastic_structure, connection__investment_stochastic_structure, and node__investment_stochastic_structure relationships. Its main purpose is to allow users to avoid defining each relationship individually, and instead allow them to focus on defining only the exceptions. As such, any specific unit__investment_stochastic_structure, connection__investment_stochastic_structure, and node__investment_stochastic_structure relationships take priority over the model__default_investment_stochastic_structure relationship.

model__default_investment_temporal_block

Defines the default temporal block used for investment variables, which will be replaced by more specific definitions

Related Object Classes: model and temporal_block

model__default_investment_temporal_block is a two-dimensional relationship between a model and a temporal_block. This relationship defines the default temporal resolution and scope for all investment decisions in the model (units, connections and storages). Specifying model__default_investment_temporal_block for a model avoids the need to specify individual node__investment_temporal_block, unit__investment_temporal_block and connection__investment_temporal_block relationships. Conversely, if any of these individual relationships are defined (e.g. connection__investment_temporal_block) along with model__temporal_block, these will override model__default_investment_temporal_block.

See also Investment Optimization

model__default_stochastic_structure

Defines the default stochastic structure used for model variables, which will be replaced by more specific definitions

Related Object Classes: model and stochastic_structure

The model__default_stochastic_structure relationship can be used to set a model-wide default for the node__stochastic_structure and units_on__stochastic_structure relationships. Its main purpose is to allow users to avoid defining each relationship individually, and instead allow them to focus on defining only the exceptions. As such, any specific node__stochastic_structure or units_on__stochastic_structure relationships take priority over the model__default_stochastic_structure relationship.

model__default_temporal_block

Defines the default temporal block used for model variables, which will be replaced by more specific definitions

Related Object Classes: model and temporal_block

The model__default_temporal_block relationship can be used to set a model-wide default for the node__temporal_block and units_on__temporal_block relationships. Its main purpose is to allow users to avoid defining each relationship individually, and instead allow them to focus on defining only the exceptions. As such, any specific node__temporal_block or units_on__temporal_block relationships take priority over the model__default_temporal_block relationship.

model__report

Determines which reports are written for each model and in turn, which outputs are written for each model

Related Object Classes: model and report

The model__report relationship tells which reports are written by which model, where the contents of the reports are defined separately using the report__output relationship. Without appropriately defined model__report and report__output and relationships, SpineOpt doesn't write any output, so be sure to include at least one report connected to all the output variables of interest in the model!

model__stochastic_structure

Defines which stochastic_structures are included in which models.

Related Object Classes: model and stochastic_structure

The [model__stochastic_structure] relationship defines which stochastic_structures are active in which models. Essentially, this relationship allows for e.g. attributing multiple node__stochastic_structure relationships for a single node, and switching between them in different models. Any stochastic_structure in the model__default_stochastic_structure relationship is automatically assumed to be active in the connected model, so there's no need to include it in [model__stochastic_structure] separately.

model__temporal_block

Defines which temporal_blocks are included in which models.

Related Object Classes: model and temporal_block

The model__temporal_block relationship is used to determine which temporal_blocks are included in a specific model. Note that defining this relationship does not yet imply that any element of the model will be governed by the specified temporal_block, for this to happen additional relationships have to be defined such as the model__default_temporal_block relationship.

node__commodity

Define a commodity for a node. Only a single commodity is permitted per node

Related Object Classes: commodity and node

node__commodity is a two-dimensional relationship between a node and a commodity and specifies the commodity that flows to or from the node. Generally, since flows are not dimensioned by commodity, this has no meaning in terms of the variables and constraint equations. However, there are two specific uses for this relationship:

  1. To specify that specific network physics should apply to the network formed by the member nodes for that commodity. See powerflow
  2. Only connection flows that are between nodes of the same or no commodity are included in the node_balance constraint.

node__investment_group

Indicates that a node belongs in a investment_group.

Related Object Classes: investment_group and node

TODO

node__investment_stochastic_structure

defines the stochastic structure for node related investments, currently only storages

Related Object Classes: node and stochastic_structure

The node__investment_stochastic_structure relationship defines the stochastic_structure of node-related investment decisions. Essentially, it sets the stochastic_structure used by the storages_invested_available variable of the node.

The node__investment_stochastic_structure relationship uses the model__default_investment_stochastic_structure relationship if not defined.

node__investment_temporal_block

defines the temporal resolution for node related investments, currently only storages

Related Object Classes: node and temporal_block

node__investment_temporal_block is a two-dimensional relationship between a node and a temporal_block. This relationship defines the temporal resolution and scope of a node's investment decisions (currently only storage invesments). Note that in a decomposed investments problem with two model objects, one for the master problem model and another for the operations problem model, the link to the specific model is made indirectly through the model__temporal_block relationship. If a model__default_investment_temporal_block is specified and no node__investment_temporal_block relationship is specified, the model__default_investment_temporal_block relationship will be used. Conversely if node__investment_temporal_block is specified along with model__temporal_block, this will override model__default_investment_temporal_block for the specified node.

See also Investment Optimization

node__node

Holds parameters for direct interactions between two nodes, e.g. node_state diffusion coefficients.

Related Object Classes: node

Related Parameters: diff_coeff

The node__node relationship is used for defining direct interactions between two nodes, like diffusion of commodity content. Note that the node__node relationship is assumed to be one-directional, meaning that

node__node(node1=n1, node2=n2) != node__node(node1=n2, node2=n1).

Thus, when one wants to define symmetric relationships between two nodes, one needs to define both directions as separate relationships.

node__stochastic_structure

Defines which specific stochastic_structure is used by the node and all flow variables associated with it. Only one stochastic_structure is permitted per node.

Related Object Classes: node and stochastic_structure

Related Parameters: is_active

The node__stochastic_structure relationship defines which stochastic_structure the node uses. Essentially, it sets the stochastic_structure of all the flow variables connected to the node, as well as the potential node_state variable. Note that only one stochastic_structure can be defined per node per model, as interpreted based on the node__stochastic_structure and model__stochastic_structure relationships. Investment variables use dedicated relationships, as detailed in the Investment Optimization section.

The node__stochastic_structure relationship uses the model__default_stochastic_structure relationship if not specified.

node__temporal_block

Defines the temporal_blocks used by the node and all the flow variables associated with it.

Related Object Classes: node and temporal_block

Related Parameters: cyclic_condition and is_active

This relationship links a node to a temporal_block and as such it will determine which temporal block governs the temporal horizon and resolution of the variables associated with this node. Specifically, the resolution of the temporal block will directly imply the duration of the time slices for which both the regular and ramping flow variables and their associated constraints are created.

For a more detailed description of how the temporal structure in SpineOpt can be created, see Temporal Framework.

node__user_constraint

specifying this relationship allows a node's demand or node_state to be included in the specified user constraint

Related Object Classes: node and user_constraint

Related Parameters: demand_coefficient, node_state_coefficient, storages_invested_available_coefficient and storages_invested_coefficient

TODO

parent_stochastic_scenario__child_stochastic_scenario

Defines the master stochastic direct acyclic graph, meaning how the stochastic_scenarios are related to each other.

Related Object Classes: stochastic_scenario

The parent_stochastic_scenario__child_stochastic_scenario relationship defines how the individual stochastic_scenarios are related to each other, forming what is referred to as the stochastic direct acyclic graph (DAG) in the Stochastic Framework section. It acts as a sort of basis for the stochastic_structures, but doesn't contain any Parameters necessary for describing how it relates to the Temporal Framework or the Objective function.

The parent_stochastic_scenario__child_stochastic_scenario relationship and the stochastic DAG it forms are crucial for Constraint generation with stochastic path indexing. Every finite stochastic DAG has a limited number of unique ways of traversing it, called full stochastic paths, which are used when determining how many different constraints need to be generated over time periods where stochastic_structures branch or converge, or when generating constraints involving different stochastic_structures. See the Stochastic Framework section for more information.

report__output

Output object related to a report object are returned to the output database (if they appear in the model as variables)

Related Object Classes: output and report

Related Parameters: overwrite_results_on_rolling

The report__output relationship tells which output variables to include in which report when writing SpineOpt output. Note that the reports also need to be connected to a model using the model__report relationship. Without appropriately defined model__report and report__output and relationships, SpineOpt doesn't write any output, so be sure to include at least one report connected to all the output variables of interest in the model!

stochastic_structure__stochastic_scenario

Defines which stochastic_scenarios are included in which stochastic_structure, and holds the parameters required for realizing the structure in combination with the temporal_blocks.

Related Object Classes: stochastic_scenario and stochastic_structure

Related Parameters: stochastic_scenario_end and weight_relative_to_parents

The stochastic_structure__stochastic_scenario relationship defines which stochastic_scenarios are included in which stochastic_structure, as well as holds the stochastic_scenario_end and weight_relative_to_parents Parameters defining how the stochastic_structure interacts with the Temporal Framework and the Objective function. Along with parent_stochastic_scenario__child_stochastic_scenario, this relationship is used to define the exact properties of each stochastic_structure, which are then applied to the objects describing the modelled system according to the Structural relationship classes, like the node__stochastic_structure relationship.

unit__commodity

Holds parameters for commodities used by the unit.

Related Object Classes: commodity and unit

Related Parameters: max_cum_in_unit_flow_bound

To impose a limit on the cumulative amount of commodity flows, the max_cum_in_unit_flow_bound can be imposed on a unit__commodity relationship. This can be very helpful, e.g. if a certain amount of emissions should not be surpased throughout the optimization.

Note that, next to the unit__commodity relationship, also the nodes connected to the units need to be associated with their corresponding commodities, see node__commodity.

unit__from_node

Defines the nodes the unit can take input from, and holds most unit_flow variable specific parameters.

Related Object Classes: node and unit

Related Parameters: fix_nonspin_ramp_up_unit_flow, fix_nonspin_units_started_up, fix_ramp_up_unit_flow, fix_start_up_unit_flow, fix_unit_flow_op, fix_unit_flow, fuel_cost, graph_view_position, initial_nonspin_ramp_up_unit_flow, initial_nonspin_units_started_up, initial_ramp_up_unit_flow, initial_start_up_unit_flow, initial_unit_flow_op, initial_unit_flow, is_active, max_res_shutdown_ramp, max_res_startup_ramp, max_shutdown_ramp, max_startup_ramp, max_total_cumulated_unit_flow_from_node, min_res_shutdown_ramp, min_res_startup_ramp, min_shutdown_ramp, min_startup_ramp, min_total_cumulated_unit_flow_from_node, min_unit_flow, minimum_operating_point, operating_points, ordered_unit_flow_op, ramp_down_cost, ramp_down_limit, ramp_up_cost, ramp_up_limit, reserve_procurement_cost, unit_capacity, unit_conv_cap_to_flow, unit_flow_non_anticipativity_margin, unit_flow_non_anticipativity_time and vom_cost

The unit__to_node and unit__from_node unit relationships are core elements of SpineOpt. For each unit__to_node or unit__from_node, a unit_flow variable is automatically added to the model, i.e. a commodity flow of a unit to or from a specific node, respectively.

Various parameters can be defined on the unit__from_node relationship, in order to constrain the associated unit flows. In most cases a unit_capacity will be defined for an upper bound on the commodity flows. Apart from that, ramping abilities of a unit can be defined. For further details on ramps see Ramping and Reserves.

To associate costs with a certain commodity flows, cost terms, such as fuel_costs and vom_costs, can be included for the unit__from_node relationship.

It is important to note, that the parameters associated with the unit__from_node can be defined either for a specific node, or for a group of nodes. Grouping nodes for the described parameters will result in an aggregation of the unit flows for the triggered constraint, e.g. the definition of the unit_capacity on a group of nodes will result in an upper bound on the sum of all individual unit_flows.

unit__from_node__investment_group

Indicates which unit capacities are included in the capacity invested available of an investment group

Related Object Classes: investment_group, node and unit

TODO

unit__from_node__user_constraint

Defines which input unit_flows are included in the user_constraint, and holds their parameters.

Related Object Classes: node, unit and user_constraint

Related Parameters: graph_view_position and unit_flow_coefficient

TODO

unit__investment_group

Indicates that a unit belongs in an investment_group.

Related Object Classes: investment_group and unit

TODO

unit__investment_stochastic_structure

Sets the stochastic structure for investment decisions - overrides model__default_investment_stochastic_structure.

Related Object Classes: stochastic_structure and unit

The unit__investment_stochastic_structure relationship defines the stochastic_structure of unit-related investment decisions. Essentially, it sets the stochastic_structure used by the units_invested_available variable of the unit.

The unit__investment_stochastic_structure relationship uses the model__default_investment_stochastic_structure relationship if not defined.

unit__investment_temporal_block

Sets the temporal resolution of investment decisions - overrides model__default_investment_temporal_block

Related Object Classes: temporal_block and unit

unit__investment_temporal_block is a two-dimensional relationship between a unit and a temporal_block. This relationship defines the temporal resolution and scope of a unit's investment decision. Note that in a decomposed investments problem with two model objects, one for the master problem model and another for the operations problem model, the link to the specific model is made indirectly through the model__temporal_block relationship. If a model__default_investment_temporal_block is specified and no unit__investment_temporal_block relationship is specified, the model__default_investment_temporal_block relationship will be used. Conversely if unit__investment_temporal_block is specified along with model__temporal_block, this will override model__default_investment_temporal_block for the specified unit.

See also Investment Optimization

unit__node__node

Holds parameters spanning multiple unit_flow variables to and from multiple nodes.

Related Object Classes: node and unit

Related Parameters: fix_ratio_in_in_unit_flow, fix_ratio_in_out_unit_flow, fix_ratio_out_in_unit_flow, fix_ratio_out_out_unit_flow, fix_units_on_coefficient_in_in, fix_units_on_coefficient_in_out, fix_units_on_coefficient_out_in, fix_units_on_coefficient_out_out, max_ratio_in_in_unit_flow, max_ratio_in_out_unit_flow, max_ratio_out_in_unit_flow, max_ratio_out_out_unit_flow, max_units_on_coefficient_in_in, max_units_on_coefficient_in_out, max_units_on_coefficient_out_in, max_units_on_coefficient_out_out, min_ratio_in_in_unit_flow, min_ratio_in_out_unit_flow, min_ratio_out_in_unit_flow, min_ratio_out_out_unit_flow, min_units_on_coefficient_in_in, min_units_on_coefficient_in_out, min_units_on_coefficient_out_in, min_units_on_coefficient_out_out, unit_idle_heat_rate, unit_incremental_heat_rate and unit_start_flow

While the relationships unit__to_node and unit__to_node take care of the automatic generation of the unit_flow variables, the unit__node__node relationships hold the information how the different commodity flows of a unit interact. Only through this relationship and the associated parameters, the topology of a unit, i.e. which intakes lead to which products etc., becomes unambiguous.

In almost all cases, at least one of the ..._ratio_... parameters will be defined, e.g. to set a fixed ratio between outgoing and incoming commodity flows of unit (see also e.g. fix_ratio_out_in_unit_flow). Note that the parameters can also be defined on a relationship between groups of objects, e.g. to force a fixed ratio between a group of nodes. In the triggered constraints, this will lead to an aggregation of the individual unit flows.

unit__to_node

Defines the nodes the unit can output to, and holds most unit_flow variable specific parameters.

Related Object Classes: node and unit

Related Parameters: fix_nonspin_ramp_down_unit_flow, fix_nonspin_ramp_up_unit_flow, fix_nonspin_units_shut_down, fix_nonspin_units_started_up, fix_ramp_down_unit_flow, fix_ramp_up_unit_flow, fix_shut_down_unit_flow, fix_start_up_unit_flow, fix_unit_flow_op, fix_unit_flow, fuel_cost, graph_view_position, initial_nonspin_ramp_down_unit_flow, initial_nonspin_ramp_up_unit_flow, initial_nonspin_units_shut_down, initial_nonspin_units_started_up, initial_ramp_down_unit_flow, initial_ramp_up_unit_flow, initial_shut_down_unit_flow, initial_start_up_unit_flow, initial_unit_flow_op, initial_unit_flow, is_active, max_res_shutdown_ramp, max_res_startup_ramp, max_shutdown_ramp, max_startup_ramp, max_total_cumulated_unit_flow_to_node, min_res_shutdown_ramp, min_res_startup_ramp, min_shutdown_ramp, min_startup_ramp, min_total_cumulated_unit_flow_to_node, min_unit_flow, minimum_operating_point, operating_points, ordered_unit_flow_op, ramp_down_cost, ramp_down_limit, ramp_up_cost, ramp_up_limit, reserve_procurement_cost, unit_capacity, unit_conv_cap_to_flow, unit_flow_non_anticipativity_margin, unit_flow_non_anticipativity_time and vom_cost

The unit__to_node and unit__from_node unit relationships are core elements of SpineOpt. For each unit__to_node or unit__from_node, a unit_flow variable is automatically added to the model, i.e. a commodity flow of a unit to or from a specific node, respectively.

Various parameters can be defined on the unit__to_node relationship, in order to constrain the associated unit flows. In most cases a unit_capacity will be defined for an upper bound on the commodity flows. Apart from that, ramping abilities of a unit can be defined. For further details on ramps see Ramping and Reserves.

To associate costs with a certain commodity flow, cost terms, such as fuel_costs and vom_costs, can be included for the unit__to_node relationship.

It is important to note, that the parameters associated with the unit__to_node can be defined either for a specific node, or for a group of nodes. Grouping nodes for the described parameters will result in an aggregation of the unit flows for the triggered constraint, e.g. the definition of the unit_capacity on a group of nodes will result in an upper bound on the sum of all individual unit_flows.

unit__to_node__investment_group

Indicates which unit capacities are included in the capacity invested available of an investment group

Related Object Classes: investment_group, node and unit

TODO

unit__to_node__user_constraint

Defines which output unit_flows are included in the user_constraint, and holds their parameters.

Related Object Classes: node, unit and user_constraint

Related Parameters: graph_view_position and unit_flow_coefficient

TODO

unit__user_constraint

Defines which units_on variables are included in the user_constraint, and holds their parameters.

Related Object Classes: unit and user_constraint

Related Parameters: units_invested_available_coefficient, units_invested_coefficient, units_on_coefficient and units_started_up_coefficient

TODO

units_on__stochastic_structure

Defines which specific stochastic_structure is used for the units_on variable of the unit. Only one stochastic_structure is permitted per unit.

Related Object Classes: stochastic_structure and unit

Related Parameters: is_active

The units_on__stochastic_structure relationship defines the stochastic_structure used by the units_on variable. Essentially, this relationship permits defining a different stochastic_structure for the online decisions regarding the units_on variable, than what is used for the production unit_flow variables. A common use-case is e.g. using only one units_on variable across multiple stochastic_scenarios for the unit_flow variables. Note that only one units_on__stochastic_structure relationship can be defined per unit per model, as interpreted by the units_on__stochastic_structure and model__stochastic_structure relationships.

The units_on__stochastic_structure relationship uses the model__default_stochastic_structure relationship if not specified.

units_on__temporal_block

Defines which specific temporal_blocks are used by the units_on variable of the unit.

Related Object Classes: temporal_block and unit

Related Parameters: is_active

units_on__temporal_block is a relationship linking the units_on variable of a unit to a specific temporal_block object. As such, this relationship will determine which temporal block governs the on- and offline status of the unit. The temporal block holds information on the temporal scope and resolution for which the variable should be optimized.

+Relationship Classes · SpineOpt.jl
GitHub

Relationship Classes

connection__from_node

Defines the nodes the connection can take input from, and holds most connection_flow variable specific parameters.

Related Object Classes: connection and node

Related Parameters: connection_capacity, connection_conv_cap_to_flow, connection_emergency_capacity, connection_flow_cost, connection_flow_non_anticipativity_margin, connection_flow_non_anticipativity_time, connection_intact_flow_non_anticipativity_margin, connection_intact_flow_non_anticipativity_time, fix_binary_gas_connection_flow, fix_connection_flow, fix_connection_intact_flow, graph_view_position, initial_binary_gas_connection_flow, initial_connection_flow and initial_connection_intact_flow

connection__from_node is a two-dimensional relationship between a connection and a node and implies a connection_flow to the connection from the node. Specifying such a relationship will give rise to a connection_flow_variable with indices connection=connection, node=node, direction=:from_node. Relationships defined on this relationship will generally apply to this specific flow variable. For example, connection_capacity will apply only to this specific flow variable, unless the connection parameter connection_type is specified.

connection__from_node__investment_group

Indicates which connection capacities are included in the capacity invested available of an investment group

Related Object Classes: connection, investment_group and node

TODO

connection__from_node__user_constraint

when specified this relationship allows the relevant flow connection flow variable to be included in the specified user constraint

Related Object Classes: connection, node and user_constraint

Related Parameters: connection_flow_coefficient

TODO

connection__investment_group

Indicates that a connection belongs in an investment_group.

Related Object Classes: connection and investment_group

TODO

connection__investment_stochastic_structure

Defines the stochastic structure of the connections investments variable

Related Object Classes: connection and stochastic_structure

The connection__investment_stochastic_structure relationship defines the stochastic_structure of connection-related investment decisions. Essentially, it sets the stochastic_structure used by the connections_invested_available variable of the connection.

The connection__investment_stochastic_structure relationship uses the model__default_investment_stochastic_structure relationship if not defined.

connection__investment_temporal_block

Defines the temporal resolution of the connections investments variable

Related Object Classes: connection and temporal_block

connection__investment_temporal_block is a two-dimensional relationship between a connection and a temporal_block. This relationship defines the temporal resolution and scope of a connection's investment decision. Note that in a decomposed investments problem with two model objects, one for the master problem model and another for the operations problem model, the link to the specific model is made indirectly through the model__temporal_block relationship. If a model__default_investment_temporal_block is specified and no connection__investment_temporal_block relationship is specified, the model__default_investment_temporal_block relationship will be used. Conversely if connection__investment_temporal_block is specified along with model__temporal_block, this will override model__default_investment_temporal_block for the specified connection.

See also Investment Optimization

connection__node__node

Holds parameters spanning multiple connection_flow variables to and from multiple nodes.

Related Object Classes: connection and node

Related Parameters: compression_factor, connection_flow_delay, connection_linepack_constant, fix_ratio_out_in_connection_flow, fixed_pressure_constant_0, fixed_pressure_constant_1, max_ratio_out_in_connection_flow and min_ratio_out_in_connection_flow

connection__node__node is a three-dimensional relationship between a connection, a node (node 1) and another node (node 2). connection__node__node infers a conversion and a direction with respect to that conversion. Node 1 is assumed to be the input node and node 2 is assumed to be the output node. For example, the fix_ratio_out_in_connection_flow parameter defined on connection__node__node relates the output connection_flow to node 2 to the intput connection_flow from node 1

connection__to_node

Defines the nodes the connection can output to, and holds most connection_flow variable specific parameters.

Related Object Classes: connection and node

Related Parameters: connection_capacity, connection_conv_cap_to_flow, connection_emergency_capacity, connection_flow_cost, connection_flow_non_anticipativity_margin, connection_flow_non_anticipativity_time, connection_intact_flow_non_anticipativity_margin, connection_intact_flow_non_anticipativity_time, fix_binary_gas_connection_flow, fix_connection_flow, fix_connection_intact_flow, graph_view_position, initial_binary_gas_connection_flow, initial_connection_flow and initial_connection_intact_flow

connection__to_node is a two-dimensional relationship between a connection and a node and implies a connection_flow from the connection to the node. Specifying such a relationship will give rise to a connection_flow_variable with indices connection=connection, node=node, direction=:to_node. Relationships defined on this relationship will generally apply to this specific flow variable. For example, connection_capacity will apply only to this specific flow variable, unless the connection parameter connection_type is specified.

connection__to_node__investment_group

Indicates which connection capacities are included in the capacity invested available of an investment group

Related Object Classes: connection, investment_group and node

TODO

connection__to_node__user_constraint

when specified this relationship allows the relevant flow connection flow variable to be included in the specified user constraint

Related Object Classes: connection, node and user_constraint

Related Parameters: connection_flow_coefficient

TODO

connection__user_constraint

Relationship required to involve a connections investment variables in a user_constraint

Related Object Classes: connection and user_constraint

Related Parameters: connections_invested_available_coefficient and connections_invested_coefficient

TODO

model__default_investment_stochastic_structure

Defines the default stochastic structure used for investment variables, which will be replaced by more specific definitions

Related Object Classes: model and stochastic_structure

The model__default_investment_stochastic_structure relationship can be used to set model-wide default unit__investment_stochastic_structure, connection__investment_stochastic_structure, and node__investment_stochastic_structure relationships. Its main purpose is to allow users to avoid defining each relationship individually, and instead allow them to focus on defining only the exceptions. As such, any specific unit__investment_stochastic_structure, connection__investment_stochastic_structure, and node__investment_stochastic_structure relationships take priority over the model__default_investment_stochastic_structure relationship.

model__default_investment_temporal_block

Defines the default temporal block used for investment variables, which will be replaced by more specific definitions

Related Object Classes: model and temporal_block

model__default_investment_temporal_block is a two-dimensional relationship between a model and a temporal_block. This relationship defines the default temporal resolution and scope for all investment decisions in the model (units, connections and storages). Specifying model__default_investment_temporal_block for a model avoids the need to specify individual node__investment_temporal_block, unit__investment_temporal_block and connection__investment_temporal_block relationships. Conversely, if any of these individual relationships are defined (e.g. connection__investment_temporal_block) along with model__temporal_block, these will override model__default_investment_temporal_block.

See also Investment Optimization

model__default_stochastic_structure

Defines the default stochastic structure used for model variables, which will be replaced by more specific definitions

Related Object Classes: model and stochastic_structure

The model__default_stochastic_structure relationship can be used to set a model-wide default for the node__stochastic_structure and units_on__stochastic_structure relationships. Its main purpose is to allow users to avoid defining each relationship individually, and instead allow them to focus on defining only the exceptions. As such, any specific node__stochastic_structure or units_on__stochastic_structure relationships take priority over the model__default_stochastic_structure relationship.

model__default_temporal_block

Defines the default temporal block used for model variables, which will be replaced by more specific definitions

Related Object Classes: model and temporal_block

The model__default_temporal_block relationship can be used to set a model-wide default for the node__temporal_block and units_on__temporal_block relationships. Its main purpose is to allow users to avoid defining each relationship individually, and instead allow them to focus on defining only the exceptions. As such, any specific node__temporal_block or units_on__temporal_block relationships take priority over the model__default_temporal_block relationship.

model__report

Determines which reports are written for each model and in turn, which outputs are written for each model

Related Object Classes: model and report

The model__report relationship tells which reports are written by which model, where the contents of the reports are defined separately using the report__output relationship. Without appropriately defined model__report and report__output and relationships, SpineOpt doesn't write any output, so be sure to include at least one report connected to all the output variables of interest in the model!

model__stochastic_structure

Defines which stochastic_structures are included in which models.

Related Object Classes: model and stochastic_structure

The [model__stochastic_structure] relationship defines which stochastic_structures are active in which models. Essentially, this relationship allows for e.g. attributing multiple node__stochastic_structure relationships for a single node, and switching between them in different models. Any stochastic_structure in the model__default_stochastic_structure relationship is automatically assumed to be active in the connected model, so there's no need to include it in [model__stochastic_structure] separately.

model__temporal_block

Defines which temporal_blocks are included in which models.

Related Object Classes: model and temporal_block

The model__temporal_block relationship is used to determine which temporal_blocks are included in a specific model. Note that defining this relationship does not yet imply that any element of the model will be governed by the specified temporal_block, for this to happen additional relationships have to be defined such as the model__default_temporal_block relationship.

node__commodity

Define a commodity for a node. Only a single commodity is permitted per node

Related Object Classes: commodity and node

node__commodity is a two-dimensional relationship between a node and a commodity and specifies the commodity that flows to or from the node. Generally, since flows are not dimensioned by commodity, this has no meaning in terms of the variables and constraint equations. However, there are two specific uses for this relationship:

  1. To specify that specific network physics should apply to the network formed by the member nodes for that commodity. See powerflow
  2. Only connection flows that are between nodes of the same or no commodity are included in the node_balance constraint.

node__investment_group

Indicates that a node belongs in a investment_group.

Related Object Classes: investment_group and node

TODO

node__investment_stochastic_structure

defines the stochastic structure for node related investments, currently only storages

Related Object Classes: node and stochastic_structure

The node__investment_stochastic_structure relationship defines the stochastic_structure of node-related investment decisions. Essentially, it sets the stochastic_structure used by the storages_invested_available variable of the node.

The node__investment_stochastic_structure relationship uses the model__default_investment_stochastic_structure relationship if not defined.

node__investment_temporal_block

defines the temporal resolution for node related investments, currently only storages

Related Object Classes: node and temporal_block

node__investment_temporal_block is a two-dimensional relationship between a node and a temporal_block. This relationship defines the temporal resolution and scope of a node's investment decisions (currently only storage invesments). Note that in a decomposed investments problem with two model objects, one for the master problem model and another for the operations problem model, the link to the specific model is made indirectly through the model__temporal_block relationship. If a model__default_investment_temporal_block is specified and no node__investment_temporal_block relationship is specified, the model__default_investment_temporal_block relationship will be used. Conversely if node__investment_temporal_block is specified along with model__temporal_block, this will override model__default_investment_temporal_block for the specified node.

See also Investment Optimization

node__node

Holds parameters for direct interactions between two nodes, e.g. node_state diffusion coefficients.

Related Object Classes: node

Related Parameters: diff_coeff

The node__node relationship is used for defining direct interactions between two nodes, like diffusion of commodity content. Note that the node__node relationship is assumed to be one-directional, meaning that

node__node(node1=n1, node2=n2) != node__node(node1=n2, node2=n1).

Thus, when one wants to define symmetric relationships between two nodes, one needs to define both directions as separate relationships.

node__stochastic_structure

Defines which specific stochastic_structure is used by the node and all flow variables associated with it. Only one stochastic_structure is permitted per node.

Related Object Classes: node and stochastic_structure

Related Parameters: is_active

The node__stochastic_structure relationship defines which stochastic_structure the node uses. Essentially, it sets the stochastic_structure of all the flow variables connected to the node, as well as the potential node_state variable. Note that only one stochastic_structure can be defined per node per model, as interpreted based on the node__stochastic_structure and model__stochastic_structure relationships. Investment variables use dedicated relationships, as detailed in the Investment Optimization section.

The node__stochastic_structure relationship uses the model__default_stochastic_structure relationship if not specified.

node__temporal_block

Defines the temporal_blocks used by the node and all the flow variables associated with it.

Related Object Classes: node and temporal_block

Related Parameters: cyclic_condition and is_active

This relationship links a node to a temporal_block and as such it will determine which temporal block governs the temporal horizon and resolution of the variables associated with this node. Specifically, the resolution of the temporal block will directly imply the duration of the time slices for which both the regular and ramping flow variables and their associated constraints are created.

For a more detailed description of how the temporal structure in SpineOpt can be created, see Temporal Framework.

node__user_constraint

specifying this relationship allows a node's demand or node_state to be included in the specified user constraint

Related Object Classes: node and user_constraint

Related Parameters: demand_coefficient, node_state_coefficient, storages_invested_available_coefficient and storages_invested_coefficient

TODO

parent_stochastic_scenario__child_stochastic_scenario

Defines the master stochastic direct acyclic graph, meaning how the stochastic_scenarios are related to each other.

Related Object Classes: stochastic_scenario

The parent_stochastic_scenario__child_stochastic_scenario relationship defines how the individual stochastic_scenarios are related to each other, forming what is referred to as the stochastic direct acyclic graph (DAG) in the Stochastic Framework section. It acts as a sort of basis for the stochastic_structures, but doesn't contain any Parameters necessary for describing how it relates to the Temporal Framework or the Objective function.

The parent_stochastic_scenario__child_stochastic_scenario relationship and the stochastic DAG it forms are crucial for Constraint generation with stochastic path indexing. Every finite stochastic DAG has a limited number of unique ways of traversing it, called full stochastic paths, which are used when determining how many different constraints need to be generated over time periods where stochastic_structures branch or converge, or when generating constraints involving different stochastic_structures. See the Stochastic Framework section for more information.

report__output

Output object related to a report object are returned to the output database (if they appear in the model as variables)

Related Object Classes: output and report

Related Parameters: overwrite_results_on_rolling

The report__output relationship tells which output variables to include in which report when writing SpineOpt output. Note that the reports also need to be connected to a model using the model__report relationship. Without appropriately defined model__report and report__output and relationships, SpineOpt doesn't write any output, so be sure to include at least one report connected to all the output variables of interest in the model!

stochastic_structure__stochastic_scenario

Defines which stochastic_scenarios are included in which stochastic_structure, and holds the parameters required for realizing the structure in combination with the temporal_blocks.

Related Object Classes: stochastic_scenario and stochastic_structure

Related Parameters: stochastic_scenario_end and weight_relative_to_parents

The stochastic_structure__stochastic_scenario relationship defines which stochastic_scenarios are included in which stochastic_structure, as well as holds the stochastic_scenario_end and weight_relative_to_parents Parameters defining how the stochastic_structure interacts with the Temporal Framework and the Objective function. Along with parent_stochastic_scenario__child_stochastic_scenario, this relationship is used to define the exact properties of each stochastic_structure, which are then applied to the objects describing the modelled system according to the Structural relationship classes, like the node__stochastic_structure relationship.

unit__commodity

Holds parameters for commodities used by the unit.

Related Object Classes: commodity and unit

Related Parameters: max_cum_in_unit_flow_bound

To impose a limit on the cumulative amount of commodity flows, the max_cum_in_unit_flow_bound can be imposed on a unit__commodity relationship. This can be very helpful, e.g. if a certain amount of emissions should not be surpased throughout the optimization.

Note that, next to the unit__commodity relationship, also the nodes connected to the units need to be associated with their corresponding commodities, see node__commodity.

unit__from_node

Defines the nodes the unit can take input from, and holds most unit_flow variable specific parameters.

Related Object Classes: node and unit

Related Parameters: fix_nonspin_ramp_up_unit_flow, fix_nonspin_units_started_up, fix_ramp_up_unit_flow, fix_start_up_unit_flow, fix_unit_flow_op, fix_unit_flow, fuel_cost, graph_view_position, initial_nonspin_ramp_up_unit_flow, initial_nonspin_units_started_up, initial_ramp_up_unit_flow, initial_start_up_unit_flow, initial_unit_flow_op, initial_unit_flow, is_active, max_res_shutdown_ramp, max_res_startup_ramp, max_shutdown_ramp, max_startup_ramp, max_total_cumulated_unit_flow_from_node, min_res_shutdown_ramp, min_res_startup_ramp, min_shutdown_ramp, min_startup_ramp, min_total_cumulated_unit_flow_from_node, min_unit_flow, minimum_operating_point, operating_points, ordered_unit_flow_op, ramp_down_cost, ramp_down_limit, ramp_up_cost, ramp_up_limit, reserve_procurement_cost, unit_capacity, unit_conv_cap_to_flow, unit_flow_non_anticipativity_margin, unit_flow_non_anticipativity_time and vom_cost

The unit__to_node and unit__from_node unit relationships are core elements of SpineOpt. For each unit__to_node or unit__from_node, a unit_flow variable is automatically added to the model, i.e. a commodity flow of a unit to or from a specific node, respectively.

Various parameters can be defined on the unit__from_node relationship, in order to constrain the associated unit flows. In most cases a unit_capacity will be defined for an upper bound on the commodity flows. Apart from that, ramping abilities of a unit can be defined. For further details on ramps see Ramping and Reserves.

To associate costs with a certain commodity flows, cost terms, such as fuel_costs and vom_costs, can be included for the unit__from_node relationship.

It is important to note, that the parameters associated with the unit__from_node can be defined either for a specific node, or for a group of nodes. Grouping nodes for the described parameters will result in an aggregation of the unit flows for the triggered constraint, e.g. the definition of the unit_capacity on a group of nodes will result in an upper bound on the sum of all individual unit_flows.

unit__from_node__investment_group

Indicates which unit capacities are included in the capacity invested available of an investment group

Related Object Classes: investment_group, node and unit

TODO

unit__from_node__user_constraint

Defines which input unit_flows are included in the user_constraint, and holds their parameters.

Related Object Classes: node, unit and user_constraint

Related Parameters: graph_view_position and unit_flow_coefficient

TODO

unit__investment_group

Indicates that a unit belongs in an investment_group.

Related Object Classes: investment_group and unit

TODO

unit__investment_stochastic_structure

Sets the stochastic structure for investment decisions - overrides model__default_investment_stochastic_structure.

Related Object Classes: stochastic_structure and unit

The unit__investment_stochastic_structure relationship defines the stochastic_structure of unit-related investment decisions. Essentially, it sets the stochastic_structure used by the units_invested_available variable of the unit.

The unit__investment_stochastic_structure relationship uses the model__default_investment_stochastic_structure relationship if not defined.

unit__investment_temporal_block

Sets the temporal resolution of investment decisions - overrides model__default_investment_temporal_block

Related Object Classes: temporal_block and unit

unit__investment_temporal_block is a two-dimensional relationship between a unit and a temporal_block. This relationship defines the temporal resolution and scope of a unit's investment decision. Note that in a decomposed investments problem with two model objects, one for the master problem model and another for the operations problem model, the link to the specific model is made indirectly through the model__temporal_block relationship. If a model__default_investment_temporal_block is specified and no unit__investment_temporal_block relationship is specified, the model__default_investment_temporal_block relationship will be used. Conversely if unit__investment_temporal_block is specified along with model__temporal_block, this will override model__default_investment_temporal_block for the specified unit.

See also Investment Optimization

unit__node__node

Holds parameters spanning multiple unit_flow variables to and from multiple nodes.

Related Object Classes: node and unit

Related Parameters: fix_ratio_in_in_unit_flow, fix_ratio_in_out_unit_flow, fix_ratio_out_in_unit_flow, fix_ratio_out_out_unit_flow, fix_units_on_coefficient_in_in, fix_units_on_coefficient_in_out, fix_units_on_coefficient_out_in, fix_units_on_coefficient_out_out, max_ratio_in_in_unit_flow, max_ratio_in_out_unit_flow, max_ratio_out_in_unit_flow, max_ratio_out_out_unit_flow, max_units_on_coefficient_in_in, max_units_on_coefficient_in_out, max_units_on_coefficient_out_in, max_units_on_coefficient_out_out, min_ratio_in_in_unit_flow, min_ratio_in_out_unit_flow, min_ratio_out_in_unit_flow, min_ratio_out_out_unit_flow, min_units_on_coefficient_in_in, min_units_on_coefficient_in_out, min_units_on_coefficient_out_in, min_units_on_coefficient_out_out, unit_idle_heat_rate, unit_incremental_heat_rate and unit_start_flow

While the relationships unit__to_node and unit__to_node take care of the automatic generation of the unit_flow variables, the unit__node__node relationships hold the information how the different commodity flows of a unit interact. Only through this relationship and the associated parameters, the topology of a unit, i.e. which intakes lead to which products etc., becomes unambiguous.

In almost all cases, at least one of the ..._ratio_... parameters will be defined, e.g. to set a fixed ratio between outgoing and incoming commodity flows of unit (see also e.g. fix_ratio_out_in_unit_flow). Note that the parameters can also be defined on a relationship between groups of objects, e.g. to force a fixed ratio between a group of nodes. In the triggered constraints, this will lead to an aggregation of the individual unit flows.

unit__to_node

Defines the nodes the unit can output to, and holds most unit_flow variable specific parameters.

Related Object Classes: node and unit

Related Parameters: fix_nonspin_ramp_down_unit_flow, fix_nonspin_ramp_up_unit_flow, fix_nonspin_units_shut_down, fix_nonspin_units_started_up, fix_ramp_down_unit_flow, fix_ramp_up_unit_flow, fix_shut_down_unit_flow, fix_start_up_unit_flow, fix_unit_flow_op, fix_unit_flow, fuel_cost, graph_view_position, initial_nonspin_ramp_down_unit_flow, initial_nonspin_ramp_up_unit_flow, initial_nonspin_units_shut_down, initial_nonspin_units_started_up, initial_ramp_down_unit_flow, initial_ramp_up_unit_flow, initial_shut_down_unit_flow, initial_start_up_unit_flow, initial_unit_flow_op, initial_unit_flow, is_active, max_res_shutdown_ramp, max_res_startup_ramp, max_shutdown_ramp, max_startup_ramp, max_total_cumulated_unit_flow_to_node, min_res_shutdown_ramp, min_res_startup_ramp, min_shutdown_ramp, min_startup_ramp, min_total_cumulated_unit_flow_to_node, min_unit_flow, minimum_operating_point, operating_points, ordered_unit_flow_op, ramp_down_cost, ramp_down_limit, ramp_up_cost, ramp_up_limit, reserve_procurement_cost, unit_capacity, unit_conv_cap_to_flow, unit_flow_non_anticipativity_margin, unit_flow_non_anticipativity_time and vom_cost

The unit__to_node and unit__from_node unit relationships are core elements of SpineOpt. For each unit__to_node or unit__from_node, a unit_flow variable is automatically added to the model, i.e. a commodity flow of a unit to or from a specific node, respectively.

Various parameters can be defined on the unit__to_node relationship, in order to constrain the associated unit flows. In most cases a unit_capacity will be defined for an upper bound on the commodity flows. Apart from that, ramping abilities of a unit can be defined. For further details on ramps see Ramping and Reserves.

To associate costs with a certain commodity flow, cost terms, such as fuel_costs and vom_costs, can be included for the unit__to_node relationship.

It is important to note, that the parameters associated with the unit__to_node can be defined either for a specific node, or for a group of nodes. Grouping nodes for the described parameters will result in an aggregation of the unit flows for the triggered constraint, e.g. the definition of the unit_capacity on a group of nodes will result in an upper bound on the sum of all individual unit_flows.

unit__to_node__investment_group

Indicates which unit capacities are included in the capacity invested available of an investment group

Related Object Classes: investment_group, node and unit

TODO

unit__to_node__user_constraint

Defines which output unit_flows are included in the user_constraint, and holds their parameters.

Related Object Classes: node, unit and user_constraint

Related Parameters: graph_view_position and unit_flow_coefficient

TODO

unit__user_constraint

Defines which units_on variables are included in the user_constraint, and holds their parameters.

Related Object Classes: unit and user_constraint

Related Parameters: units_invested_available_coefficient, units_invested_coefficient, units_on_coefficient and units_started_up_coefficient

TODO

units_on__stochastic_structure

Defines which specific stochastic_structure is used for the units_on variable of the unit. Only one stochastic_structure is permitted per unit.

Related Object Classes: stochastic_structure and unit

Related Parameters: is_active

The units_on__stochastic_structure relationship defines the stochastic_structure used by the units_on variable. Essentially, this relationship permits defining a different stochastic_structure for the online decisions regarding the units_on variable, than what is used for the production unit_flow variables. A common use-case is e.g. using only one units_on variable across multiple stochastic_scenarios for the unit_flow variables. Note that only one units_on__stochastic_structure relationship can be defined per unit per model, as interpreted by the units_on__stochastic_structure and model__stochastic_structure relationships.

The units_on__stochastic_structure relationship uses the model__default_stochastic_structure relationship if not specified.

units_on__temporal_block

Defines which specific temporal_blocks are used by the units_on variable of the unit.

Related Object Classes: temporal_block and unit

Related Parameters: is_active

units_on__temporal_block is a relationship linking the units_on variable of a unit to a specific temporal_block object. As such, this relationship will determine which temporal block governs the on- and offline status of the unit. The temporal block holds information on the temporal scope and resolution for which the variable should be optimized.

diff --git a/dev/concept_reference/_example/index.html b/dev/concept_reference/_example/index.html index c6a1e1812a..e2c9a5dca0 100644 --- a/dev/concept_reference/_example/index.html +++ b/dev/concept_reference/_example/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

AN EXAMPLE DESCRIPTION FOR HOW THE AUTOGENERATION OF CONCEPT REFERENCE BASED ON SPINEOPT TEMPLATE WORKS

References to other sections, e.g. node are handled like this. Don't use the grave accents around the reference name, as it breaks the reference! Grave accents in Documenter.jl refer to docstrings in the code instead of sections in the documentation.

+- · SpineOpt.jl
GitHub

AN EXAMPLE DESCRIPTION FOR HOW THE AUTOGENERATION OF CONCEPT REFERENCE BASED ON SPINEOPT TEMPLATE WORKS

References to other sections, e.g. node are handled like this. Don't use the grave accents around the reference name, as it breaks the reference! Grave accents in Documenter.jl refer to docstrings in the code instead of sections in the documentation.

diff --git a/dev/concept_reference/balance_type/index.html b/dev/concept_reference/balance_type/index.html index 759800db8b..96287f04c6 100644 --- a/dev/concept_reference/balance_type/index.html +++ b/dev/concept_reference/balance_type/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

The balance_type parameter determines whether or not a node needs to be balanced, in the classical sense that the sum of flows entering the node is equal to the sum of flows leaving it.

The values balance_type_node (the default) and balance_type_group mean that the node is always balanced. The only exception is if the node belongs in a group that has itself balance_type equal to balance_type_group. The value balance_type_none means that the node doesn't need to be balanced.

+- · SpineOpt.jl
GitHub

The balance_type parameter determines whether or not a node needs to be balanced, in the classical sense that the sum of flows entering the node is equal to the sum of flows leaving it.

The values balance_type_node (the default) and balance_type_group mean that the node is always balanced. The only exception is if the node belongs in a group that has itself balance_type equal to balance_type_group. The value balance_type_none means that the node doesn't need to be balanced.

diff --git a/dev/concept_reference/balance_type_list/index.html b/dev/concept_reference/balance_type_list/index.html index 0ffa6149c9..58b60b4ffe 100644 --- a/dev/concept_reference/balance_type_list/index.html +++ b/dev/concept_reference/balance_type_list/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub
+- · SpineOpt.jl
GitHub
diff --git a/dev/concept_reference/big_m/index.html b/dev/concept_reference/big_m/index.html index 5d4435d821..d13d720d91 100644 --- a/dev/concept_reference/big_m/index.html +++ b/dev/concept_reference/big_m/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

The big_m parameter is a property of the model object. The bigM method is commonly used for the purpose of recasting non-linear constraints into a mixed-integer reformulation. In SpineOpt, the bigM formulation is used to describe the sign of gas flow through a connection (if a pressure driven gas transfer model is used). The big_m parameter in combination with the binary variable binary_gas_connection_flow is used in the constraints on the gas flow capacity and the fixed node pressure points and ensures that the average flow through a pipeline is only in one direction and is constraint by the fixed pressure points from the outer approximation of the Weymouth equation. See Schwele - Coordination of Power and Natural Gas Systems: Convexification Approaches for Linepack Modeling for reference.

+- · SpineOpt.jl
GitHub

The big_m parameter is a property of the model object. The bigM method is commonly used for the purpose of recasting non-linear constraints into a mixed-integer reformulation. In SpineOpt, the bigM formulation is used to describe the sign of gas flow through a connection (if a pressure driven gas transfer model is used). The big_m parameter in combination with the binary variable binary_gas_connection_flow is used in the constraints on the gas flow capacity and the fixed node pressure points and ensures that the average flow through a pipeline is only in one direction and is constraint by the fixed pressure points from the outer approximation of the Weymouth equation. See Schwele - Coordination of Power and Natural Gas Systems: Convexification Approaches for Linepack Modeling for reference.

diff --git a/dev/concept_reference/block_end/index.html b/dev/concept_reference/block_end/index.html index 4d5f1d6d1c..f2d15749bf 100644 --- a/dev/concept_reference/block_end/index.html +++ b/dev/concept_reference/block_end/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

Indicates the end of this temporal block. The default value is equal to a duration of 0. It is useful to distinguish here between two cases: a single solve, or a rolling window optimization.

single solve When a Date time value is chosen, this is directly the end of the optimization for this temporal block. In a single solve optimization, a combination of block_start and block_end can easily be used to run optimizations that cover only part of the model horizon. Multiple temporal_block objects can then be used to create optimizations for disconnected time periods, which is commonly used in the method of representative days. The default value coincides with the model_end.

rolling window optimization To create a temporal block that is rolling along with the optimization window, a rolling temporal block, a duration value should be chosen. The block_end parameter will in this case determine the size of the optimization window, with respect to the start of each optimization window. If multiple temporal blocks with different block_end parameters exist, the maximum value will determine the size of the optimization window. Note, this is different from the roll_forward parameter, which determines how much the window moves for after each optimization. For more info, see One single temporal_block. The default value is equal to the roll_forward parameter.

+- · SpineOpt.jl
GitHub

Indicates the end of this temporal block. The default value is equal to a duration of 0. It is useful to distinguish here between two cases: a single solve, or a rolling window optimization.

single solve When a Date time value is chosen, this is directly the end of the optimization for this temporal block. In a single solve optimization, a combination of block_start and block_end can easily be used to run optimizations that cover only part of the model horizon. Multiple temporal_block objects can then be used to create optimizations for disconnected time periods, which is commonly used in the method of representative days. The default value coincides with the model_end.

rolling window optimization To create a temporal block that is rolling along with the optimization window, a rolling temporal block, a duration value should be chosen. The block_end parameter will in this case determine the size of the optimization window, with respect to the start of each optimization window. If multiple temporal blocks with different block_end parameters exist, the maximum value will determine the size of the optimization window. Note, this is different from the roll_forward parameter, which determines how much the window moves for after each optimization. For more info, see One single temporal_block. The default value is equal to the roll_forward parameter.

diff --git a/dev/concept_reference/block_start/index.html b/dev/concept_reference/block_start/index.html index d3aab75171..08e737cb2f 100644 --- a/dev/concept_reference/block_start/index.html +++ b/dev/concept_reference/block_start/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

Indicates the start of this temporal block. The main use of this parameter is to create an offset from the model start. The default value is equal to a duration of 0. It is useful to distinguish here between two cases: a single solve, or a rolling window optimization.

single solve When a Date time value is chosen, this is directly the start of the optimization for this temporal block. When a duration is chosen, it is added to the model_start to obtain the start of this temporal_block. In the case of a duration, the chosen value directly marks the offset of the optimization with respect to the model_start. The default value for this parameter is the model_start.

rolling window optimization To create a temporal block that is rolling along with the optimization window, a rolling temporal block, a duration value should be chosen. The temporal block_start will again mark the offset of the optimization start but now with respect to the start of each optimization window.

+- · SpineOpt.jl
GitHub

Indicates the start of this temporal block. The main use of this parameter is to create an offset from the model start. The default value is equal to a duration of 0. It is useful to distinguish here between two cases: a single solve, or a rolling window optimization.

single solve When a Date time value is chosen, this is directly the start of the optimization for this temporal block. When a duration is chosen, it is added to the model_start to obtain the start of this temporal_block. In the case of a duration, the chosen value directly marks the offset of the optimization with respect to the model_start. The default value for this parameter is the model_start.

rolling window optimization To create a temporal block that is rolling along with the optimization window, a rolling temporal block, a duration value should be chosen. The temporal block_start will again mark the offset of the optimization start but now with respect to the start of each optimization window.

diff --git a/dev/concept_reference/boolean_value_list/index.html b/dev/concept_reference/boolean_value_list/index.html index 6f7fad5ca9..46193aff0d 100644 --- a/dev/concept_reference/boolean_value_list/index.html +++ b/dev/concept_reference/boolean_value_list/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

A list of boolean values (True or False).

+- · SpineOpt.jl
GitHub

A list of boolean values (True or False).

diff --git a/dev/concept_reference/candidate_connections/index.html b/dev/concept_reference/candidate_connections/index.html index 6cafd8c10d..6545c3a69c 100644 --- a/dev/concept_reference/candidate_connections/index.html +++ b/dev/concept_reference/candidate_connections/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub
+- · SpineOpt.jl
GitHub
diff --git a/dev/concept_reference/candidate_storages/index.html b/dev/concept_reference/candidate_storages/index.html index 3209e31d87..60de8fa2a1 100644 --- a/dev/concept_reference/candidate_storages/index.html +++ b/dev/concept_reference/candidate_storages/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

Within an investments problem candidate_storages determines the upper bound on the storages investment decision variable in constraint storages_invested_available. In constraint node_state_cap the maximum node state will be the product of the storages investment variable and node_state_cap. Thus, the interpretation of candidate_storages depends on storage_investment_variable_type which determines the investment decision variable type. If storage_investment_variable_type is integer or binary, then candidate_storages represents the maximum number of discrete storages of size node_state_cap that may be invested in at the corresponding node. If storage_investment_variable_type is continuous, candidate_storages is more analagous to a maximum storage capacity with node_state_cap being analagous to a scaling parameter.

Note that candidate_storages is the main investment switch and setting a value other than none/nothing triggers the creation of the investment variable for storages at the corresponding node. Note that a value of zero will still trigger the variable creation but its value will be fixed to zero. This can be useful if an inspection of the related dual variables will yield the value of this resource.

See also Investment Optimization and storage_investment_variable_type

+- · SpineOpt.jl
GitHub

Within an investments problem candidate_storages determines the upper bound on the storages investment decision variable in constraint storages_invested_available. In constraint node_state_cap the maximum node state will be the product of the storages investment variable and node_state_cap. Thus, the interpretation of candidate_storages depends on storage_investment_variable_type which determines the investment decision variable type. If storage_investment_variable_type is integer or binary, then candidate_storages represents the maximum number of discrete storages of size node_state_cap that may be invested in at the corresponding node. If storage_investment_variable_type is continuous, candidate_storages is more analagous to a maximum storage capacity with node_state_cap being analagous to a scaling parameter.

Note that candidate_storages is the main investment switch and setting a value other than none/nothing triggers the creation of the investment variable for storages at the corresponding node. Note that a value of zero will still trigger the variable creation but its value will be fixed to zero. This can be useful if an inspection of the related dual variables will yield the value of this resource.

See also Investment Optimization and storage_investment_variable_type

diff --git a/dev/concept_reference/candidate_units/index.html b/dev/concept_reference/candidate_units/index.html index ae8c3921a6..e5a062049c 100644 --- a/dev/concept_reference/candidate_units/index.html +++ b/dev/concept_reference/candidate_units/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

Within an investments problem candidate_units determines the upper bound on the unit investment decision variable in constraint units_invested_available. In constraint unit_flow_capacity the maximum unit_flow will be the product of the units_invested_available and the corresponding unit_capacity. Thus, the interpretation of candidate_units depends on unit_investment_variable_type which determines the unit investment decision variable type. If unit_investment_variable_type is integer or binary, then candidate_units represents the maximum number of discrete units that may be invested in. If unit_investment_variable_type is continuous, candidate_units is more analagous to a maximum storage capacity.

Note that candidate_units is the main investment switch and setting a value other than none/nothing triggers the creation of the investment variable for the unit. Note that a value of zero will still trigger the variable creation but its value will be fixed to zero. This can be useful if an inspection of the related dual variables will yield the value of this resource.

See also Investment Optimization and unit_investment_variable_type

+- · SpineOpt.jl
GitHub

Within an investments problem candidate_units determines the upper bound on the unit investment decision variable in constraint units_invested_available. In constraint unit_flow_capacity the maximum unit_flow will be the product of the units_invested_available and the corresponding unit_capacity. Thus, the interpretation of candidate_units depends on unit_investment_variable_type which determines the unit investment decision variable type. If unit_investment_variable_type is integer or binary, then candidate_units represents the maximum number of discrete units that may be invested in. If unit_investment_variable_type is continuous, candidate_units is more analagous to a maximum storage capacity.

Note that candidate_units is the main investment switch and setting a value other than none/nothing triggers the creation of the investment variable for the unit. Note that a value of zero will still trigger the variable creation but its value will be fixed to zero. This can be useful if an inspection of the related dual variables will yield the value of this resource.

See also Investment Optimization and unit_investment_variable_type

diff --git a/dev/concept_reference/commodity/index.html b/dev/concept_reference/commodity/index.html index 09ea5ee972..d89aec3c24 100644 --- a/dev/concept_reference/commodity/index.html +++ b/dev/concept_reference/commodity/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

Commodities correspond to the type of energy traded. When associated with a node through the node__commodity relationship, a specific form of energy, i.e. commodity, can be associated with a specific location. Furthermore, by linking commodities with units, it is possible to track the flows of a certain commodity and impose limitations on the use of a certain commodity (See also max_cum_in_unit_flow_bound). For the representation of specific commodity physics, related to e.g. the representation of the electric network, designated parameters can be defined to enforce commodity specific behaviour. (See also commodity_physics)

+- · SpineOpt.jl
GitHub

Commodities correspond to the type of energy traded. When associated with a node through the node__commodity relationship, a specific form of energy, i.e. commodity, can be associated with a specific location. Furthermore, by linking commodities with units, it is possible to track the flows of a certain commodity and impose limitations on the use of a certain commodity (See also max_cum_in_unit_flow_bound). For the representation of specific commodity physics, related to e.g. the representation of the electric network, designated parameters can be defined to enforce commodity specific behaviour. (See also commodity_physics)

diff --git a/dev/concept_reference/commodity_lodf_tolerance/index.html b/dev/concept_reference/commodity_lodf_tolerance/index.html index 774649ec10..6c364d2f11 100644 --- a/dev/concept_reference/commodity_lodf_tolerance/index.html +++ b/dev/concept_reference/commodity_lodf_tolerance/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

Given two connections, the line outage distribution factor (LODF) is the fraction of the pre-contingency flow on the first one, that will flow on the second after the contingency. commodity_lodf_tolerance is the minimum absolute value of the LODF that is considered meaningful. Any value below this tolerance (in absolute value) will be treated as zero.

The LODFs are used to model contingencies on some connections and their impact on some other connections. To model contingencies on a connection, set connection_contingency to true; to study the impact of such contingencies on another connection, set connection_monitored to true.

In addition, define a commodity with commodity_physics set to commodity_physics_lodf, and associate that commodity (via node__commodity) to both connections' nodes (given by connection__to_node and connection__from_node).

+- · SpineOpt.jl
GitHub

Given two connections, the line outage distribution factor (LODF) is the fraction of the pre-contingency flow on the first one, that will flow on the second after the contingency. commodity_lodf_tolerance is the minimum absolute value of the LODF that is considered meaningful. Any value below this tolerance (in absolute value) will be treated as zero.

The LODFs are used to model contingencies on some connections and their impact on some other connections. To model contingencies on a connection, set connection_contingency to true; to study the impact of such contingencies on another connection, set connection_monitored to true.

In addition, define a commodity with commodity_physics set to commodity_physics_lodf, and associate that commodity (via node__commodity) to both connections' nodes (given by connection__to_node and connection__from_node).

diff --git a/dev/concept_reference/commodity_physics/index.html b/dev/concept_reference/commodity_physics/index.html index b5300fd1b6..5db55abbc7 100644 --- a/dev/concept_reference/commodity_physics/index.html +++ b/dev/concept_reference/commodity_physics/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

This parameter determines the specific formulation used to carry out dc load flow within a model. To enable power transfer distribution factor (ptdf) based load flow for a network of nodes and connections, all nodes must be related to a commodity with commodity_physics set to commodity_physics_ptdf. To enable security constraint unit comment based on ptdfs and line outage distribution factors (lodf) all nodes must be related to a commodity with commodity_physics set to commodity_physics_lodf.

See also powerflow

+- · SpineOpt.jl
GitHub

This parameter determines the specific formulation used to carry out dc load flow within a model. To enable power transfer distribution factor (ptdf) based load flow for a network of nodes and connections, all nodes must be related to a commodity with commodity_physics set to commodity_physics_ptdf. To enable security constraint unit comment based on ptdfs and line outage distribution factors (lodf) all nodes must be related to a commodity with commodity_physics set to commodity_physics_lodf.

See also powerflow

diff --git a/dev/concept_reference/commodity_physics_list/index.html b/dev/concept_reference/commodity_physics_list/index.html index 1609e201ec..0916bdd246 100644 --- a/dev/concept_reference/commodity_physics_list/index.html +++ b/dev/concept_reference/commodity_physics_list/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub
+- · SpineOpt.jl
GitHub
diff --git a/dev/concept_reference/commodity_ptdf_threshold/index.html b/dev/concept_reference/commodity_ptdf_threshold/index.html index 0cb7235626..33a2fc98df 100644 --- a/dev/concept_reference/commodity_ptdf_threshold/index.html +++ b/dev/concept_reference/commodity_ptdf_threshold/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

Given a connection and a node, the power transfer distribution factor (PTDF) is the fraction of the flow injected into the node that will flow on the connection. commodity_ptdf_threshold is the minimum absolute value of the PTDF that is considered meaningful. Any value below this threshold (in absolute value) will be treated as zero.

The PTDFs are used to model DC power flow on certain connections. To model DC power flow on a connection, set connection_monitored to true.

In addition, define a commodity with commodity_physics set to either commodity_physics_ptdf, or commodity_physics_lodf. and associate that commodity (via node__commodity) to both connections' nodes (given by connection__to_node and connection__from_node).

+- · SpineOpt.jl
GitHub

Given a connection and a node, the power transfer distribution factor (PTDF) is the fraction of the flow injected into the node that will flow on the connection. commodity_ptdf_threshold is the minimum absolute value of the PTDF that is considered meaningful. Any value below this threshold (in absolute value) will be treated as zero.

The PTDFs are used to model DC power flow on certain connections. To model DC power flow on a connection, set connection_monitored to true.

In addition, define a commodity with commodity_physics set to either commodity_physics_ptdf, or commodity_physics_lodf. and associate that commodity (via node__commodity) to both connections' nodes (given by connection__to_node and connection__from_node).

diff --git a/dev/concept_reference/compression_factor/index.html b/dev/concept_reference/compression_factor/index.html index 76880428b4..7ea05ce9b7 100644 --- a/dev/concept_reference/compression_factor/index.html +++ b/dev/concept_reference/compression_factor/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

This parameter is specific to the use of pressure driven gas transfer. To represent a compression between two nodes in the gas network, the compression_factor can be defined. This factor ensures that the pressure of a node is equal to (or lower than) the pressure at the sending node times the compression_factor. The relationship connection__node__node that hosts this parameter should be defined in a way that the first node represents the origin node and the second node represents the compressed node.

+- · SpineOpt.jl
GitHub

This parameter is specific to the use of pressure driven gas transfer. To represent a compression between two nodes in the gas network, the compression_factor can be defined. This factor ensures that the pressure of a node is equal to (or lower than) the pressure at the sending node times the compression_factor. The relationship connection__node__node that hosts this parameter should be defined in a way that the first node represents the origin node and the second node represents the compressed node.

diff --git a/dev/concept_reference/connection/index.html b/dev/concept_reference/connection/index.html index 5de65439e3..d5f7509560 100644 --- a/dev/concept_reference/connection/index.html +++ b/dev/concept_reference/connection/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

A connection represents a transfer of one commodity over space. For example, an electricity transmission line, a gas pipe, a river branch, can be modelled using a connection.

A connection always takes commodities from one or more nodes, and releases them to one or more (possibly the same) nodes. The former are specificed through the connection__from_node relationship, and the latter through connection__to_node. Every connection inherits the temporal and stochastic structures from the associated nodes. The model will generate connection_flow variables for every combination of connection, node, direction (from node or to node), time slice, and stochastic scenario, according to the above relationships.

The operation of the connection is specified through a number of parameter values. For example, the capacity of the connection, as the maximum amount of energy that can enter or leave it, is given by connection_capacity. The conversion ratio of input to output can be specified using any of fix_ratio_out_in_connection_flow, max_ratio_out_in_connection_flow, and min_ratio_out_in_connection_flow parameters in the connection__node__node relationship. The delay on a connection, as the time it takes for the energy to go from one end to the other, is given by connection_flow_delay.

+- · SpineOpt.jl
GitHub

A connection represents a transfer of one commodity over space. For example, an electricity transmission line, a gas pipe, a river branch, can be modelled using a connection.

A connection always takes commodities from one or more nodes, and releases them to one or more (possibly the same) nodes. The former are specificed through the connection__from_node relationship, and the latter through connection__to_node. Every connection inherits the temporal and stochastic structures from the associated nodes. The model will generate connection_flow variables for every combination of connection, node, direction (from node or to node), time slice, and stochastic scenario, according to the above relationships.

The operation of the connection is specified through a number of parameter values. For example, the capacity of the connection, as the maximum amount of energy that can enter or leave it, is given by connection_capacity. The conversion ratio of input to output can be specified using any of fix_ratio_out_in_connection_flow, max_ratio_out_in_connection_flow, and min_ratio_out_in_connection_flow parameters in the connection__node__node relationship. The delay on a connection, as the time it takes for the energy to go from one end to the other, is given by connection_flow_delay.

diff --git a/dev/concept_reference/connection__from_node/index.html b/dev/concept_reference/connection__from_node/index.html index d57d7c839c..10f7e68194 100644 --- a/dev/concept_reference/connection__from_node/index.html +++ b/dev/concept_reference/connection__from_node/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

connection__from_node is a two-dimensional relationship between a connection and a node and implies a connection_flow to the connection from the node. Specifying such a relationship will give rise to a connection_flow_variable with indices connection=connection, node=node, direction=:from_node. Relationships defined on this relationship will generally apply to this specific flow variable. For example, connection_capacity will apply only to this specific flow variable, unless the connection parameter connection_type is specified.

+- · SpineOpt.jl
GitHub

connection__from_node is a two-dimensional relationship between a connection and a node and implies a connection_flow to the connection from the node. Specifying such a relationship will give rise to a connection_flow_variable with indices connection=connection, node=node, direction=:from_node. Relationships defined on this relationship will generally apply to this specific flow variable. For example, connection_capacity will apply only to this specific flow variable, unless the connection parameter connection_type is specified.

diff --git a/dev/concept_reference/connection__from_node__unit_constraint/index.html b/dev/concept_reference/connection__from_node__unit_constraint/index.html index dff5dfa295..1a304c5c74 100644 --- a/dev/concept_reference/connection__from_node__unit_constraint/index.html +++ b/dev/concept_reference/connection__from_node__unit_constraint/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

connection__from_node__user_constraint is a three-dimensional relationship between a connection, a node and a user_constraint. The relationship specifies that the connection_flow variable to the specified connection from the specified node is involved in the specified user_constraint. Parameters on this relationship generally apply to this specific connection_flow variable. For example the parameter connection_flow_coefficient defined on connection__from_node__user_constraint represents the coefficient on the specific connection_flow variable in the specified user_constraint

+- · SpineOpt.jl
GitHub

connection__from_node__user_constraint is a three-dimensional relationship between a connection, a node and a user_constraint. The relationship specifies that the connection_flow variable to the specified connection from the specified node is involved in the specified user_constraint. Parameters on this relationship generally apply to this specific connection_flow variable. For example the parameter connection_flow_coefficient defined on connection__from_node__user_constraint represents the coefficient on the specific connection_flow variable in the specified user_constraint

diff --git a/dev/concept_reference/connection__investment_stochastic_structure/index.html b/dev/concept_reference/connection__investment_stochastic_structure/index.html index e4191ed234..0b0153274d 100644 --- a/dev/concept_reference/connection__investment_stochastic_structure/index.html +++ b/dev/concept_reference/connection__investment_stochastic_structure/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub
+- · SpineOpt.jl
GitHub
diff --git a/dev/concept_reference/connection__investment_temporal_block/index.html b/dev/concept_reference/connection__investment_temporal_block/index.html index eea888c7f7..8f498003a9 100644 --- a/dev/concept_reference/connection__investment_temporal_block/index.html +++ b/dev/concept_reference/connection__investment_temporal_block/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

connection__investment_temporal_block is a two-dimensional relationship between a connection and a temporal_block. This relationship defines the temporal resolution and scope of a connection's investment decision. Note that in a decomposed investments problem with two model objects, one for the master problem model and another for the operations problem model, the link to the specific model is made indirectly through the model__temporal_block relationship. If a model__default_investment_temporal_block is specified and no connection__investment_temporal_block relationship is specified, the model__default_investment_temporal_block relationship will be used. Conversely if connection__investment_temporal_block is specified along with model__temporal_block, this will override model__default_investment_temporal_block for the specified connection.

See also Investment Optimization

+- · SpineOpt.jl
GitHub

connection__investment_temporal_block is a two-dimensional relationship between a connection and a temporal_block. This relationship defines the temporal resolution and scope of a connection's investment decision. Note that in a decomposed investments problem with two model objects, one for the master problem model and another for the operations problem model, the link to the specific model is made indirectly through the model__temporal_block relationship. If a model__default_investment_temporal_block is specified and no connection__investment_temporal_block relationship is specified, the model__default_investment_temporal_block relationship will be used. Conversely if connection__investment_temporal_block is specified along with model__temporal_block, this will override model__default_investment_temporal_block for the specified connection.

See also Investment Optimization

diff --git a/dev/concept_reference/connection__node__node/index.html b/dev/concept_reference/connection__node__node/index.html index eb4866503f..d7ca186941 100644 --- a/dev/concept_reference/connection__node__node/index.html +++ b/dev/concept_reference/connection__node__node/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

connection__node__node is a three-dimensional relationship between a connection, a node (node 1) and another node (node 2). connection__node__node infers a conversion and a direction with respect to that conversion. Node 1 is assumed to be the input node and node 2 is assumed to be the output node. For example, the fix_ratio_out_in_connection_flow parameter defined on connection__node__node relates the output connection_flow to node 2 to the intput connection_flow from node 1

+- · SpineOpt.jl
GitHub

connection__node__node is a three-dimensional relationship between a connection, a node (node 1) and another node (node 2). connection__node__node infers a conversion and a direction with respect to that conversion. Node 1 is assumed to be the input node and node 2 is assumed to be the output node. For example, the fix_ratio_out_in_connection_flow parameter defined on connection__node__node relates the output connection_flow to node 2 to the intput connection_flow from node 1

diff --git a/dev/concept_reference/connection__to_node/index.html b/dev/concept_reference/connection__to_node/index.html index eca2b5594c..a091f7e0f8 100644 --- a/dev/concept_reference/connection__to_node/index.html +++ b/dev/concept_reference/connection__to_node/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

connection__to_node is a two-dimensional relationship between a connection and a node and implies a connection_flow from the connection to the node. Specifying such a relationship will give rise to a connection_flow_variable with indices connection=connection, node=node, direction=:to_node. Relationships defined on this relationship will generally apply to this specific flow variable. For example, connection_capacity will apply only to this specific flow variable, unless the connection parameter connection_type is specified.

+- · SpineOpt.jl
GitHub

connection__to_node is a two-dimensional relationship between a connection and a node and implies a connection_flow from the connection to the node. Specifying such a relationship will give rise to a connection_flow_variable with indices connection=connection, node=node, direction=:to_node. Relationships defined on this relationship will generally apply to this specific flow variable. For example, connection_capacity will apply only to this specific flow variable, unless the connection parameter connection_type is specified.

diff --git a/dev/concept_reference/connection__to_node__unit_constraint/index.html b/dev/concept_reference/connection__to_node__unit_constraint/index.html index 0a4a2d9b48..dc0473b5a0 100644 --- a/dev/concept_reference/connection__to_node__unit_constraint/index.html +++ b/dev/concept_reference/connection__to_node__unit_constraint/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

connection__to_node__user_constraint is a three-dimensional relationship between a connection, a node and a user_constraint. The relationship specifies that the connection_flow variable from the specified connection to the specified node is involved in the specified user_constraint. Parameters on this relationship generally apply to this specific connection_flow variable. For example the parameter connection_flow_coefficient defined on connection__to_node__user_constraint represents the coefficient on the specific connection_flow variable in the specified user_constraint

+- · SpineOpt.jl
GitHub

connection__to_node__user_constraint is a three-dimensional relationship between a connection, a node and a user_constraint. The relationship specifies that the connection_flow variable from the specified connection to the specified node is involved in the specified user_constraint. Parameters on this relationship generally apply to this specific connection_flow variable. For example the parameter connection_flow_coefficient defined on connection__to_node__user_constraint represents the coefficient on the specific connection_flow variable in the specified user_constraint

diff --git a/dev/concept_reference/connection_availability_factor/index.html b/dev/concept_reference/connection_availability_factor/index.html index 8b4c161430..d6591c1937 100644 --- a/dev/concept_reference/connection_availability_factor/index.html +++ b/dev/concept_reference/connection_availability_factor/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

To indicate that a connection is only available to a certain extent or at certain times of the optimization, the connection_availability_factor can be used. A typical use case could be an availability timeseries for connection with expected outage times. By default the availability factor is set to 1. The availability is, among others, used in the constraint_connection_flow_capacity.

+- · SpineOpt.jl
GitHub

To indicate that a connection is only available to a certain extent or at certain times of the optimization, the connection_availability_factor can be used. A typical use case could be an availability timeseries for connection with expected outage times. By default the availability factor is set to 1. The availability is, among others, used in the constraint_connection_flow_capacity.

diff --git a/dev/concept_reference/connection_capacity/index.html b/dev/concept_reference/connection_capacity/index.html index eefbf83f32..5a86ba8fde 100644 --- a/dev/concept_reference/connection_capacity/index.html +++ b/dev/concept_reference/connection_capacity/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

Defines the upper bound on the corresponding connection_flow variable. If the connection is a candidate connection, the effective connection_flow upper bound is the product of the investment variable, connections_invested_available and connection_capacity. If ptdf based dc load flow is enabled, connection_capacity represents the normal rating of a connection (line) while connection_emergency_capacity represents the maximum post contingency flow.

+- · SpineOpt.jl
GitHub

Defines the upper bound on the corresponding connection_flow variable. If the connection is a candidate connection, the effective connection_flow upper bound is the product of the investment variable, connections_invested_available and connection_capacity. If ptdf based dc load flow is enabled, connection_capacity represents the normal rating of a connection (line) while connection_emergency_capacity represents the maximum post contingency flow.

diff --git a/dev/concept_reference/connection_contingency/index.html b/dev/concept_reference/connection_contingency/index.html index f28e899d58..91340cf794 100644 --- a/dev/concept_reference/connection_contingency/index.html +++ b/dev/concept_reference/connection_contingency/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

Specifies that the connection in question is to be included as a contingency when security constrained unit commitment is enabled. When using security constrained unit commitment by setting commodity_physics to commodity_physics_lodf, an N-1 security constraint is created for each monitored line (connection_monitored = true) for each specified contingency (connection_contingency = true).

See also powerflow

+- · SpineOpt.jl
GitHub

Specifies that the connection in question is to be included as a contingency when security constrained unit commitment is enabled. When using security constrained unit commitment by setting commodity_physics to commodity_physics_lodf, an N-1 security constraint is created for each monitored line (connection_monitored = true) for each specified contingency (connection_contingency = true).

See also powerflow

diff --git a/dev/concept_reference/connection_conv_cap_to_flow/index.html b/dev/concept_reference/connection_conv_cap_to_flow/index.html index 62b9f05288..af01f5aa3d 100644 --- a/dev/concept_reference/connection_conv_cap_to_flow/index.html +++ b/dev/concept_reference/connection_conv_cap_to_flow/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub
+- · SpineOpt.jl
GitHub
diff --git a/dev/concept_reference/connection_emergency_capacity/index.html b/dev/concept_reference/connection_emergency_capacity/index.html index 101f748da9..1e50356d5a 100644 --- a/dev/concept_reference/connection_emergency_capacity/index.html +++ b/dev/concept_reference/connection_emergency_capacity/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub
+- · SpineOpt.jl
GitHub
diff --git a/dev/concept_reference/connection_flow_coefficient/index.html b/dev/concept_reference/connection_flow_coefficient/index.html index 73c52567e7..5d922015d5 100644 --- a/dev/concept_reference/connection_flow_coefficient/index.html +++ b/dev/concept_reference/connection_flow_coefficient/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub
+- · SpineOpt.jl
GitHub
diff --git a/dev/concept_reference/connection_flow_cost/index.html b/dev/concept_reference/connection_flow_cost/index.html index 9fffb14585..c8bc1ef8a1 100644 --- a/dev/concept_reference/connection_flow_cost/index.html +++ b/dev/concept_reference/connection_flow_cost/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

By defining the connection_flow_cost parameter for a specific connection, a cost term will be added to the objective function that values all connection_flow variables associated with that connection during the current optimization window.

+- · SpineOpt.jl
GitHub

By defining the connection_flow_cost parameter for a specific connection, a cost term will be added to the objective function that values all connection_flow variables associated with that connection during the current optimization window.

diff --git a/dev/concept_reference/connection_flow_delay/index.html b/dev/concept_reference/connection_flow_delay/index.html index 43ec7cb752..04140c57a4 100644 --- a/dev/concept_reference/connection_flow_delay/index.html +++ b/dev/concept_reference/connection_flow_delay/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub
+- · SpineOpt.jl
GitHub
diff --git a/dev/concept_reference/connection_investment_cost/index.html b/dev/concept_reference/connection_investment_cost/index.html index 2765c01e78..f25c42ca07 100644 --- a/dev/concept_reference/connection_investment_cost/index.html +++ b/dev/concept_reference/connection_investment_cost/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

By defining the connection_investment_cost parameter for a specific connection, a cost term will be added to the objective function whenever a connection investment is made during the current optimization window.

+- · SpineOpt.jl
GitHub

By defining the connection_investment_cost parameter for a specific connection, a cost term will be added to the objective function whenever a connection investment is made during the current optimization window.

diff --git a/dev/concept_reference/connection_investment_lifetime/index.html b/dev/concept_reference/connection_investment_lifetime/index.html index 309745871f..acf7f425dd 100644 --- a/dev/concept_reference/connection_investment_lifetime/index.html +++ b/dev/concept_reference/connection_investment_lifetime/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

connection_investment_lifetime is the minimum amount of time that a connection has to stay in operation once it's invested-in. Only after that time, the connection can be decomissioned. Note that connection_investment_lifetime is a dynamic parameter that will impact the amount of solution history that must remain available to the optimisation in each step - this may impact performance.

+- · SpineOpt.jl
GitHub

connection_investment_lifetime is the minimum amount of time that a connection has to stay in operation once it's invested-in. Only after that time, the connection can be decomissioned. Note that connection_investment_lifetime is a dynamic parameter that will impact the amount of solution history that must remain available to the optimisation in each step - this may impact performance.

diff --git a/dev/concept_reference/connection_investment_variable_type/index.html b/dev/concept_reference/connection_investment_variable_type/index.html index 3278e78ee0..ffb7ba157a 100644 --- a/dev/concept_reference/connection_investment_variable_type/index.html +++ b/dev/concept_reference/connection_investment_variable_type/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

The connection_investment_variable_type parameter represents the type of the connections_invested_available decision variable.

The default value, variable_type_integer, means that only integer factors of the connection_capacity can be invested in. The value variable_type_continuous means that any fractional factor can also be invested in. The value variable_type_binary means that only a factor of 1 or zero are possible.

+- · SpineOpt.jl
GitHub

The connection_investment_variable_type parameter represents the type of the connections_invested_available decision variable.

The default value, variable_type_integer, means that only integer factors of the connection_capacity can be invested in. The value variable_type_continuous means that any fractional factor can also be invested in. The value variable_type_binary means that only a factor of 1 or zero are possible.

diff --git a/dev/concept_reference/connection_investment_variable_type_list/index.html b/dev/concept_reference/connection_investment_variable_type_list/index.html index 17816b8588..5d2087e7c8 100644 --- a/dev/concept_reference/connection_investment_variable_type_list/index.html +++ b/dev/concept_reference/connection_investment_variable_type_list/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub
+- · SpineOpt.jl
GitHub
diff --git a/dev/concept_reference/connection_linepack_constant/index.html b/dev/concept_reference/connection_linepack_constant/index.html index fdc6db2a31..bd3ca237b8 100644 --- a/dev/concept_reference/connection_linepack_constant/index.html +++ b/dev/concept_reference/connection_linepack_constant/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

The linepack constant is a physical property of a connection representing a pipeline and holds information on how the linepack flexibility relates to pressures of the adjacent nodes. If, and only if, this parameter is defined, the linepack flexibility of a pipeline can be modelled. The existence of the parameter triggers the generation of the constraint on line pack storage. The connection_linepack_constant should always be defined on the tuple (connection pipeline, linepack storage node, node group (containing both pressure nodes, i.e. start and end of the pipeline)). See also.

+- · SpineOpt.jl
GitHub

The linepack constant is a physical property of a connection representing a pipeline and holds information on how the linepack flexibility relates to pressures of the adjacent nodes. If, and only if, this parameter is defined, the linepack flexibility of a pipeline can be modelled. The existence of the parameter triggers the generation of the constraint on line pack storage. The connection_linepack_constant should always be defined on the tuple (connection pipeline, linepack storage node, node group (containing both pressure nodes, i.e. start and end of the pipeline)). See also.

diff --git a/dev/concept_reference/connection_monitored/index.html b/dev/concept_reference/connection_monitored/index.html index 045c990e1c..2b870f0a9e 100644 --- a/dev/concept_reference/connection_monitored/index.html +++ b/dev/concept_reference/connection_monitored/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub
+- · SpineOpt.jl
GitHub
diff --git a/dev/concept_reference/connection_reactance/index.html b/dev/concept_reference/connection_reactance/index.html index 633b9c28e5..c51620f3ed 100644 --- a/dev/concept_reference/connection_reactance/index.html +++ b/dev/concept_reference/connection_reactance/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

The per unit reactance of a transmission line. Used in ptdf based dc load flow where the relative reactances of lines determine the ptdfs of the network and in lossless dc powerflow where the flow on a line is given by flow = 1/x(theta_to-theta_from) where x is the reatance of the line, thetato is the voltage angle of the remote node and thetafrom is the voltage angle of the sending node.

+- · SpineOpt.jl
GitHub

The per unit reactance of a transmission line. Used in ptdf based dc load flow where the relative reactances of lines determine the ptdfs of the network and in lossless dc powerflow where the flow on a line is given by flow = 1/x(theta_to-theta_from) where x is the reatance of the line, thetato is the voltage angle of the remote node and thetafrom is the voltage angle of the sending node.

diff --git a/dev/concept_reference/connection_reactance_base/index.html b/dev/concept_reference/connection_reactance_base/index.html index 3cbb643e29..56c480b0c8 100644 --- a/dev/concept_reference/connection_reactance_base/index.html +++ b/dev/concept_reference/connection_reactance_base/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub
+- · SpineOpt.jl
GitHub
diff --git a/dev/concept_reference/connection_resistance/index.html b/dev/concept_reference/connection_resistance/index.html index 87151dd229..2d639a68ad 100644 --- a/dev/concept_reference/connection_resistance/index.html +++ b/dev/concept_reference/connection_resistance/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

The per unit resistance of a transmission line. Currently unimplemented!

+- · SpineOpt.jl
GitHub

The per unit resistance of a transmission line. Currently unimplemented!

diff --git a/dev/concept_reference/connection_type/index.html b/dev/concept_reference/connection_type/index.html index ea66eb4b42..3e4c08b314 100644 --- a/dev/concept_reference/connection_type/index.html +++ b/dev/concept_reference/connection_type/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

Used to control specific pre-processing actions on connections. Currently, the primary purpose of connection_type is to simplify the data that is required to define a simple bi-directional, lossless line. If connection_type=:connection_type_lossless_bidirectional, it is only necessary to specify the following minimum data:

If connection_type=:connection_type_lossless_bidirectional the following pre-processing actions are taken:

+- · SpineOpt.jl
GitHub

Used to control specific pre-processing actions on connections. Currently, the primary purpose of connection_type is to simplify the data that is required to define a simple bi-directional, lossless line. If connection_type=:connection_type_lossless_bidirectional, it is only necessary to specify the following minimum data:

If connection_type=:connection_type_lossless_bidirectional the following pre-processing actions are taken:

diff --git a/dev/concept_reference/connection_type_list/index.html b/dev/concept_reference/connection_type_list/index.html index 3d7d82f66d..ea33f5b7a1 100644 --- a/dev/concept_reference/connection_type_list/index.html +++ b/dev/concept_reference/connection_type_list/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub
+- · SpineOpt.jl
GitHub
diff --git a/dev/concept_reference/connections_invested_avaiable_coefficient/index.html b/dev/concept_reference/connections_invested_avaiable_coefficient/index.html index ab6410a422..0fedaa84a3 100644 --- a/dev/concept_reference/connections_invested_avaiable_coefficient/index.html +++ b/dev/concept_reference/connections_invested_avaiable_coefficient/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub
+- · SpineOpt.jl
GitHub
diff --git a/dev/concept_reference/connections_invested_big_m_mga/index.html b/dev/concept_reference/connections_invested_big_m_mga/index.html index 241888dff9..3252aeeca5 100644 --- a/dev/concept_reference/connections_invested_big_m_mga/index.html +++ b/dev/concept_reference/connections_invested_big_m_mga/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

The connections_invested_big_m_mga parameter is used in combination with the MGA algorithm (see mga-advanced). It defines an upper bound on the maximum difference between any MGA iteration. The big M should be chosen always sufficiently large. (Typically, a value equivalent to candidate_connections could suffice.)

+- · SpineOpt.jl
GitHub

The connections_invested_big_m_mga parameter is used in combination with the MGA algorithm (see mga-advanced). It defines an upper bound on the maximum difference between any MGA iteration. The big M should be chosen always sufficiently large. (Typically, a value equivalent to candidate_connections could suffice.)

diff --git a/dev/concept_reference/connections_invested_coefficient/index.html b/dev/concept_reference/connections_invested_coefficient/index.html index a8eb28f6d7..4f795954aa 100644 --- a/dev/concept_reference/connections_invested_coefficient/index.html +++ b/dev/concept_reference/connections_invested_coefficient/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub
+- · SpineOpt.jl
GitHub
diff --git a/dev/concept_reference/connections_invested_mga/index.html b/dev/concept_reference/connections_invested_mga/index.html index 173d9836fd..6a9b3e8680 100644 --- a/dev/concept_reference/connections_invested_mga/index.html +++ b/dev/concept_reference/connections_invested_mga/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub
+- · SpineOpt.jl
GitHub
diff --git a/dev/concept_reference/constraint_sense/index.html b/dev/concept_reference/constraint_sense/index.html index 4a3c2e712a..51cf544ed0 100644 --- a/dev/concept_reference/constraint_sense/index.html +++ b/dev/concept_reference/constraint_sense/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub
+- · SpineOpt.jl
GitHub
diff --git a/dev/concept_reference/constraint_sense_list/index.html b/dev/concept_reference/constraint_sense_list/index.html index a454aed260..90577def38 100644 --- a/dev/concept_reference/constraint_sense_list/index.html +++ b/dev/concept_reference/constraint_sense_list/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub
+- · SpineOpt.jl
GitHub
diff --git a/dev/concept_reference/curtailment_cost/index.html b/dev/concept_reference/curtailment_cost/index.html index f4fa7f92be..20adf3b40e 100644 --- a/dev/concept_reference/curtailment_cost/index.html +++ b/dev/concept_reference/curtailment_cost/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

By defining the curtailment_cost parameter for a specific unit, a cost term will be added to the objective function whenever this unit's available capacity exceeds its activity (i.e., the unit_flow variable) over the course of the operational dispatch during the current optimization window.

+- · SpineOpt.jl
GitHub

By defining the curtailment_cost parameter for a specific unit, a cost term will be added to the objective function whenever this unit's available capacity exceeds its activity (i.e., the unit_flow variable) over the course of the operational dispatch during the current optimization window.

diff --git a/dev/concept_reference/cyclic_condition/index.html b/dev/concept_reference/cyclic_condition/index.html index 6beb0f7e57..54ff914aa2 100644 --- a/dev/concept_reference/cyclic_condition/index.html +++ b/dev/concept_reference/cyclic_condition/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub
+- · SpineOpt.jl
GitHub
diff --git a/dev/concept_reference/db_lp_solver/index.html b/dev/concept_reference/db_lp_solver/index.html index 78ea1866a6..8e6680583c 100644 --- a/dev/concept_reference/db_lp_solver/index.html +++ b/dev/concept_reference/db_lp_solver/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

Specifies the Julia solver package to be used to solve Linear Programming Problems (LPs) for the specific model. The value must correspond exactly (case sensitive) to the name of the Julia solver package (e.g. Clp.jl). Installation and configuration of solvers is the responsibility of the user. A full list of solvers supported by JuMP can be found here. Note that the specified problem must support LP problems. Solver options are specified using the db_lp_solver_options parameter for the model. Note also that if run_spineopt() is called with the lp_solver keyword argument specified, this will override this parameter.

+- · SpineOpt.jl
GitHub

Specifies the Julia solver package to be used to solve Linear Programming Problems (LPs) for the specific model. The value must correspond exactly (case sensitive) to the name of the Julia solver package (e.g. Clp.jl). Installation and configuration of solvers is the responsibility of the user. A full list of solvers supported by JuMP can be found here. Note that the specified problem must support LP problems. Solver options are specified using the db_lp_solver_options parameter for the model. Note also that if run_spineopt() is called with the lp_solver keyword argument specified, this will override this parameter.

diff --git a/dev/concept_reference/db_lp_solver_list/index.html b/dev/concept_reference/db_lp_solver_list/index.html index 09d2022243..a07c694fd8 100644 --- a/dev/concept_reference/db_lp_solver_list/index.html +++ b/dev/concept_reference/db_lp_solver_list/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

List of supported LP solvers which may be specified for the db_lp_solver_options parameter. The value must correspond exactly to the name of the Julia solver package (e.g. Clp.jl) and is case sensitive.

+- · SpineOpt.jl
GitHub

List of supported LP solvers which may be specified for the db_lp_solver_options parameter. The value must correspond exactly to the name of the Julia solver package (e.g. Clp.jl) and is case sensitive.

diff --git a/dev/concept_reference/db_lp_solver_options/index.html b/dev/concept_reference/db_lp_solver_options/index.html index 834c0875d4..836e8d9c58 100644 --- a/dev/concept_reference/db_lp_solver_options/index.html +++ b/dev/concept_reference/db_lp_solver_options/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

LP solver options are specified for a model using the db_lp_solver_options parameter. This parameter value must take the form of a nested map where the outer key corresponds to the solver package name (case sensitive). E.g. Clp.jl. The inner map consists of option name and value pairs. See the below example. By default, the SpineOpt template contains some common parameters for some common solvers. For a list of supported solver options, one should consult the documentation for the solver and//or the julia solver wrapper package. example db_lp_solver_options map parameter

+- · SpineOpt.jl
GitHub

LP solver options are specified for a model using the db_lp_solver_options parameter. This parameter value must take the form of a nested map where the outer key corresponds to the solver package name (case sensitive). E.g. Clp.jl. The inner map consists of option name and value pairs. See the below example. By default, the SpineOpt template contains some common parameters for some common solvers. For a list of supported solver options, one should consult the documentation for the solver and//or the julia solver wrapper package. example db_lp_solver_options map parameter

diff --git a/dev/concept_reference/db_mip_solver/index.html b/dev/concept_reference/db_mip_solver/index.html index b7babe61e7..1ccd5185e4 100644 --- a/dev/concept_reference/db_mip_solver/index.html +++ b/dev/concept_reference/db_mip_solver/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

Specifies the Julia solver package to be used to solve Mixed Integer Programming Problems (MIPs) for the specific model. The value must correspond exactly (case sensitive) to the name of the Julia solver package (e.g. Cbc.jl). Installation and configuration of solvers is the responsibility of the user. A full list of solvers supported by JuMP can be found here. Note that the specified problem must support MIP problems. Solver options are specified using the db_mip_solver_options parameter for the model. Note also that if run_spineopt() is called with the mip_solver keyword argument specified, this will override this parameter.

+- · SpineOpt.jl
GitHub

Specifies the Julia solver package to be used to solve Mixed Integer Programming Problems (MIPs) for the specific model. The value must correspond exactly (case sensitive) to the name of the Julia solver package (e.g. Cbc.jl). Installation and configuration of solvers is the responsibility of the user. A full list of solvers supported by JuMP can be found here. Note that the specified problem must support MIP problems. Solver options are specified using the db_mip_solver_options parameter for the model. Note also that if run_spineopt() is called with the mip_solver keyword argument specified, this will override this parameter.

diff --git a/dev/concept_reference/db_mip_solver_list/index.html b/dev/concept_reference/db_mip_solver_list/index.html index fe85c62686..98453c399e 100644 --- a/dev/concept_reference/db_mip_solver_list/index.html +++ b/dev/concept_reference/db_mip_solver_list/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

List of supported MIP solvers which may be specified for the db_mip_solver_options parameter. The value must correspond exactly to the name of the Julia solver package (e.g. Cbc.jl) and is case sensitive.

+- · SpineOpt.jl
GitHub

List of supported MIP solvers which may be specified for the db_mip_solver_options parameter. The value must correspond exactly to the name of the Julia solver package (e.g. Cbc.jl) and is case sensitive.

diff --git a/dev/concept_reference/db_mip_solver_options/index.html b/dev/concept_reference/db_mip_solver_options/index.html index c5c39e18e8..bb46ad5575 100644 --- a/dev/concept_reference/db_mip_solver_options/index.html +++ b/dev/concept_reference/db_mip_solver_options/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

MIP solver options are specified for a model using the db_mip_solver_options parameter. This parameter value must take the form of a nested map where the outer key corresponds to the solver package name (case sensitive). E.g. Cbc.jl. The inner map consists of option name and value pairs. See the below example. By default, the SpineOpt template contains some common parameters for some common solvers. For a list of supported solver options, one should consult the documentation for the solver and//or the julia solver wrapper package. example db_mip_solver_options map parameter

+- · SpineOpt.jl
GitHub

MIP solver options are specified for a model using the db_mip_solver_options parameter. This parameter value must take the form of a nested map where the outer key corresponds to the solver package name (case sensitive). E.g. Cbc.jl. The inner map consists of option name and value pairs. See the below example. By default, the SpineOpt template contains some common parameters for some common solvers. For a list of supported solver options, one should consult the documentation for the solver and//or the julia solver wrapper package. example db_mip_solver_options map parameter

diff --git a/dev/concept_reference/demand/index.html b/dev/concept_reference/demand/index.html index 9b44c723de..c19ea2e9b4 100644 --- a/dev/concept_reference/demand/index.html +++ b/dev/concept_reference/demand/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

The demand parameter represents a "demand" or a "load" of a commodity on a node. It appears in the node injection constraint, with positive values interpreted as "demand" or "load" for the modelled system, while negative values provide the system with "influx" or "gain". When the node is part of a group, the fractional_demand parameter can be used to split demand into fractions, when desired. See also: Introduction to groups of objects

The demand parameter can also be included in custom user_constraints using the demand_coefficient parameter for the node__user_constraint relationship.

+- · SpineOpt.jl
GitHub

The demand parameter represents a "demand" or a "load" of a commodity on a node. It appears in the node injection constraint, with positive values interpreted as "demand" or "load" for the modelled system, while negative values provide the system with "influx" or "gain". When the node is part of a group, the fractional_demand parameter can be used to split demand into fractions, when desired. See also: Introduction to groups of objects

The demand parameter can also be included in custom user_constraints using the demand_coefficient parameter for the node__user_constraint relationship.

diff --git a/dev/concept_reference/demand_coefficient/index.html b/dev/concept_reference/demand_coefficient/index.html index 67c4b81c44..b3b8ed311d 100644 --- a/dev/concept_reference/demand_coefficient/index.html +++ b/dev/concept_reference/demand_coefficient/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub
+- · SpineOpt.jl
GitHub
diff --git a/dev/concept_reference/diff_coeff/index.html b/dev/concept_reference/diff_coeff/index.html index 5132dcb00c..acd198a37d 100644 --- a/dev/concept_reference/diff_coeff/index.html +++ b/dev/concept_reference/diff_coeff/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

The diff_coeff parameter represents diffusion of a commodity between the two nodes in the node__node relationship. It appears as a coefficient on the node_state variable in the node injection constraint, essentially representing diffusion power per unit of state. Note that the diff_coeff is interpreted as one-directional, meaning that if one defines

diff_coeff(node1=n1, node2=n2),

there will only be diffusion from n1 to n2, but not vice versa. Symmetric diffusion is likely used in most cases, requiring defining the diff_coeff both ways

diff_coeff(node1=n1, node2=n2) == diff_coeff(node1=n2, node2=n1).
+- · SpineOpt.jl
GitHub

The diff_coeff parameter represents diffusion of a commodity between the two nodes in the node__node relationship. It appears as a coefficient on the node_state variable in the node injection constraint, essentially representing diffusion power per unit of state. Note that the diff_coeff is interpreted as one-directional, meaning that if one defines

diff_coeff(node1=n1, node2=n2),

there will only be diffusion from n1 to n2, but not vice versa. Symmetric diffusion is likely used in most cases, requiring defining the diff_coeff both ways

diff_coeff(node1=n1, node2=n2) == diff_coeff(node1=n2, node2=n1).
diff --git a/dev/concept_reference/downward_reserve/index.html b/dev/concept_reference/downward_reserve/index.html index 0682587c43..ffdf7f9d56 100644 --- a/dev/concept_reference/downward_reserve/index.html +++ b/dev/concept_reference/downward_reserve/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

If a node has a true is_reserve_node parameter, it will be treated as a reserve node in the model. To define whether the node corresponds to an upward or downward reserve commodity, the upward_reserve or the downward_reserve parameter needs to be set to true, respectively.

+- · SpineOpt.jl
GitHub

If a node has a true is_reserve_node parameter, it will be treated as a reserve node in the model. To define whether the node corresponds to an upward or downward reserve commodity, the upward_reserve or the downward_reserve parameter needs to be set to true, respectively.

diff --git a/dev/concept_reference/duration_unit/index.html b/dev/concept_reference/duration_unit/index.html index 0779c4eca0..0282395472 100644 --- a/dev/concept_reference/duration_unit/index.html +++ b/dev/concept_reference/duration_unit/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

The duration_unit parameter specifies the base unit of time in a model. Two values are currently supported, hour and the default minute. E.g. if the duration_unit is set to hour, a Duration of one minute gets converted into 1/60 hours for the calculations.

+- · SpineOpt.jl
GitHub

The duration_unit parameter specifies the base unit of time in a model. Two values are currently supported, hour and the default minute. E.g. if the duration_unit is set to hour, a Duration of one minute gets converted into 1/60 hours for the calculations.

diff --git a/dev/concept_reference/duration_unit_list/index.html b/dev/concept_reference/duration_unit_list/index.html index 6df9032693..a70efca6c5 100644 --- a/dev/concept_reference/duration_unit_list/index.html +++ b/dev/concept_reference/duration_unit_list/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub
+- · SpineOpt.jl
GitHub
diff --git a/dev/concept_reference/fix_binary_gas_connection_flow/index.html b/dev/concept_reference/fix_binary_gas_connection_flow/index.html index 0dc2e55b90..c9ea2d70ad 100644 --- a/dev/concept_reference/fix_binary_gas_connection_flow/index.html +++ b/dev/concept_reference/fix_binary_gas_connection_flow/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub
+- · SpineOpt.jl
GitHub
diff --git a/dev/concept_reference/fix_connection_flow/index.html b/dev/concept_reference/fix_connection_flow/index.html index 8541054769..9fd10e4bb0 100644 --- a/dev/concept_reference/fix_connection_flow/index.html +++ b/dev/concept_reference/fix_connection_flow/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub
+- · SpineOpt.jl
GitHub
diff --git a/dev/concept_reference/fix_connection_intact_flow/index.html b/dev/concept_reference/fix_connection_intact_flow/index.html index 15a4248e29..17332f440f 100644 --- a/dev/concept_reference/fix_connection_intact_flow/index.html +++ b/dev/concept_reference/fix_connection_intact_flow/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub
+- · SpineOpt.jl
GitHub
diff --git a/dev/concept_reference/fix_connections_invested/index.html b/dev/concept_reference/fix_connections_invested/index.html index 6504c41cb5..1a9d1f9fd1 100644 --- a/dev/concept_reference/fix_connections_invested/index.html +++ b/dev/concept_reference/fix_connections_invested/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub
+- · SpineOpt.jl
GitHub
diff --git a/dev/concept_reference/fix_connections_invested_available/index.html b/dev/concept_reference/fix_connections_invested_available/index.html index 359a05d215..570e4edbf4 100644 --- a/dev/concept_reference/fix_connections_invested_available/index.html +++ b/dev/concept_reference/fix_connections_invested_available/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub
+- · SpineOpt.jl
GitHub
diff --git a/dev/concept_reference/fix_node_pressure/index.html b/dev/concept_reference/fix_node_pressure/index.html index 1c638ea7db..8577e1339f 100644 --- a/dev/concept_reference/fix_node_pressure/index.html +++ b/dev/concept_reference/fix_node_pressure/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

In a pressure driven gas model, gas network nodes are associated with the node_pressure variable. In order to fix the pressure at a certain node or to give intial conditions the fix_node_pressure parameter can be used.

+- · SpineOpt.jl
GitHub

In a pressure driven gas model, gas network nodes are associated with the node_pressure variable. In order to fix the pressure at a certain node or to give intial conditions the fix_node_pressure parameter can be used.

diff --git a/dev/concept_reference/fix_node_state/index.html b/dev/concept_reference/fix_node_state/index.html index 5fc73e2993..4369d1c6fd 100644 --- a/dev/concept_reference/fix_node_state/index.html +++ b/dev/concept_reference/fix_node_state/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

The fix_node_state parameter simply fixes the value of the node_state variable to the provided value, if one is found. Common uses for the parameter include e.g. providing initial values for node_state variables, by fixing the value on the first modelled time step (or the value before the first modelled time step) using a TimeSeries type parameter value with an appropriate timestamp. Due to the way SpineOpt handles TimeSeries data, the node_state variables are only fixed for time steps with defined fix_node_state parameter values.

+- · SpineOpt.jl
GitHub

The fix_node_state parameter simply fixes the value of the node_state variable to the provided value, if one is found. Common uses for the parameter include e.g. providing initial values for node_state variables, by fixing the value on the first modelled time step (or the value before the first modelled time step) using a TimeSeries type parameter value with an appropriate timestamp. Due to the way SpineOpt handles TimeSeries data, the node_state variables are only fixed for time steps with defined fix_node_state parameter values.

diff --git a/dev/concept_reference/fix_node_voltage_angle/index.html b/dev/concept_reference/fix_node_voltage_angle/index.html index 600babc62f..52cd485448 100644 --- a/dev/concept_reference/fix_node_voltage_angle/index.html +++ b/dev/concept_reference/fix_node_voltage_angle/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

For a lossless nodal DC power flow network, each node is associated with a node_voltage_angle variable. In order to fix the voltage angle at a certain node or to give initial conditions the fix_node_voltage_angle parameter can be used.

+- · SpineOpt.jl
GitHub

For a lossless nodal DC power flow network, each node is associated with a node_voltage_angle variable. In order to fix the voltage angle at a certain node or to give initial conditions the fix_node_voltage_angle parameter can be used.

diff --git a/dev/concept_reference/fix_nonspin_ramp_down_unit_flow/index.html b/dev/concept_reference/fix_nonspin_ramp_down_unit_flow/index.html index 324ddd9476..807b907488 100644 --- a/dev/concept_reference/fix_nonspin_ramp_down_unit_flow/index.html +++ b/dev/concept_reference/fix_nonspin_ramp_down_unit_flow/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

The fix_nonspin_ramp_down_unit_flow parameter simply fixes the value of the nonspin_ramp_down_unit_flow variable to the provided value. As such, it determines directly how much non-spinning downward reserve commodity flows the relevant unit is providing to the node to which it is linked by the unit__to_node relationship.

When a single value is selected, this value is kept constant throughout the model. It is also possible to provide a timeseries of values, which can be used for example to impose initial conditions by providing a value only for the first timestep included in the model.

+- · SpineOpt.jl
GitHub

The fix_nonspin_ramp_down_unit_flow parameter simply fixes the value of the nonspin_ramp_down_unit_flow variable to the provided value. As such, it determines directly how much non-spinning downward reserve commodity flows the relevant unit is providing to the node to which it is linked by the unit__to_node relationship.

When a single value is selected, this value is kept constant throughout the model. It is also possible to provide a timeseries of values, which can be used for example to impose initial conditions by providing a value only for the first timestep included in the model.

diff --git a/dev/concept_reference/fix_nonspin_ramp_up_unit_flow/index.html b/dev/concept_reference/fix_nonspin_ramp_up_unit_flow/index.html index 64e1326e91..7b71c3b475 100644 --- a/dev/concept_reference/fix_nonspin_ramp_up_unit_flow/index.html +++ b/dev/concept_reference/fix_nonspin_ramp_up_unit_flow/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

The fix_nonspin_ramp_up_unit_flow parameter simply fixes the value of the nonspin_ramp_up_unit_flow variable to the provided value. As such, it determines directly how much non-spinning upward reserve commodity flows the relevant unit is providing to the node to which it is linked by the unit__to_node relationship.

When a single value is selected, this value is kept constant throughout the model. It is also possible to provide a timeseries of values, which can be used for example to impose initial conditions by providing a value only for the first timestep included in the model.

+- · SpineOpt.jl
GitHub

The fix_nonspin_ramp_up_unit_flow parameter simply fixes the value of the nonspin_ramp_up_unit_flow variable to the provided value. As such, it determines directly how much non-spinning upward reserve commodity flows the relevant unit is providing to the node to which it is linked by the unit__to_node relationship.

When a single value is selected, this value is kept constant throughout the model. It is also possible to provide a timeseries of values, which can be used for example to impose initial conditions by providing a value only for the first timestep included in the model.

diff --git a/dev/concept_reference/fix_nonspin_units_shut_down/index.html b/dev/concept_reference/fix_nonspin_units_shut_down/index.html index 5c989107a1..a942be0f30 100644 --- a/dev/concept_reference/fix_nonspin_units_shut_down/index.html +++ b/dev/concept_reference/fix_nonspin_units_shut_down/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

The fix_nonspin_units_shut_down parameter simply fixes the value of the nonspin_units_shut_down variable to the provided value. As such, it determines directly how many member units are involved in providing downward reserve commodity flows to the node to which it is linked by the unit__to_node relationship.

When a single value is selected, this value is kept constant throughout the model. It is also possible to provide a timeseries of values, which can be used for example to impose initial conditions by providing a value only for the first timestep included in the model.

+- · SpineOpt.jl
GitHub

The fix_nonspin_units_shut_down parameter simply fixes the value of the nonspin_units_shut_down variable to the provided value. As such, it determines directly how many member units are involved in providing downward reserve commodity flows to the node to which it is linked by the unit__to_node relationship.

When a single value is selected, this value is kept constant throughout the model. It is also possible to provide a timeseries of values, which can be used for example to impose initial conditions by providing a value only for the first timestep included in the model.

diff --git a/dev/concept_reference/fix_nonspin_units_started_up/index.html b/dev/concept_reference/fix_nonspin_units_started_up/index.html index 756224a3db..99535630cf 100644 --- a/dev/concept_reference/fix_nonspin_units_started_up/index.html +++ b/dev/concept_reference/fix_nonspin_units_started_up/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

The fix_nonspin_units_started_up parameter simply fixes the value of the nonspin_units_started_up variable to the provided value. As such, it determines directly how many member units are involved in providing upward reserve commodity flows to the node to which it is linked by the unit__to_node relationship.

When a single value is selected, this value is kept constant throughout the model. It is also possible to provide a timeseries of values, which can be used for example to impose initial conditions by providing a value only for the first timestep included in the model.

+- · SpineOpt.jl
GitHub

The fix_nonspin_units_started_up parameter simply fixes the value of the nonspin_units_started_up variable to the provided value. As such, it determines directly how many member units are involved in providing upward reserve commodity flows to the node to which it is linked by the unit__to_node relationship.

When a single value is selected, this value is kept constant throughout the model. It is also possible to provide a timeseries of values, which can be used for example to impose initial conditions by providing a value only for the first timestep included in the model.

diff --git a/dev/concept_reference/fix_ramp_down_unit_flow/index.html b/dev/concept_reference/fix_ramp_down_unit_flow/index.html index caeda81373..bc8cd6e4c1 100644 --- a/dev/concept_reference/fix_ramp_down_unit_flow/index.html +++ b/dev/concept_reference/fix_ramp_down_unit_flow/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

The fix_ramp_down_unit_flow parameter simply fixes the value of the ramp_down_unit_flow variable to the provided value. It is possible to provide an incomplete timeseries of values, which can be used for example to impose initial conditions by providing a value only for the first timestep included in the model.

+- · SpineOpt.jl
GitHub

The fix_ramp_down_unit_flow parameter simply fixes the value of the ramp_down_unit_flow variable to the provided value. It is possible to provide an incomplete timeseries of values, which can be used for example to impose initial conditions by providing a value only for the first timestep included in the model.

diff --git a/dev/concept_reference/fix_ramp_up_unit_flow/index.html b/dev/concept_reference/fix_ramp_up_unit_flow/index.html index 27aa0b94be..76a66003c4 100644 --- a/dev/concept_reference/fix_ramp_up_unit_flow/index.html +++ b/dev/concept_reference/fix_ramp_up_unit_flow/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

The fix_ramp_up_unit_flow parameter simply fixes the value of the ramp_up_unit_flow variable to the provided value. It is possible to provide an incomplete timeseries of values, which can be used for example to impose initial conditions by providing a value only for the first timestep included in the model.

+- · SpineOpt.jl
GitHub

The fix_ramp_up_unit_flow parameter simply fixes the value of the ramp_up_unit_flow variable to the provided value. It is possible to provide an incomplete timeseries of values, which can be used for example to impose initial conditions by providing a value only for the first timestep included in the model.

diff --git a/dev/concept_reference/fix_ratio_in_in_unit_flow/index.html b/dev/concept_reference/fix_ratio_in_in_unit_flow/index.html index 812bf46b90..1d547f6e6a 100644 --- a/dev/concept_reference/fix_ratio_in_in_unit_flow/index.html +++ b/dev/concept_reference/fix_ratio_in_in_unit_flow/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

The definition of the fix_ratio_in_in_unit_flow parameter triggers the generation of the constraint_fix_ratio_in_in_unit_flow and fixes the ratio between incoming flows of a unit. The parameter is defined on the relationship class unit__node__node, where both nodes (or group of nodes) in this relationship represent from_nodes, i.e. the incoming flows to the unit. The ratio parameter is interpreted such that it constrains the ratio of in1 over in2, where in1 is the unit_flow variable from the first node in the unit__node__node relationship in a left-to-right order. This parameter can be useful, for instance if a unit requires a specific commodity mix as a fuel supply.

To enforce e.g. for a unit u a fixed share of 0.8 of its incoming flow from the node supply_fuel_1 compared to its incoming flow from the node group supply_fuel_2 (consisting of the two nodes supply_fuel_2_component_a and supply_fuel_2_component_b) the fix_ratio_in_in_unit_flow parameter would be set to 0.8 for the relationship u__supply_fuel_1__supply_fuel_2.

+- · SpineOpt.jl
GitHub

The definition of the fix_ratio_in_in_unit_flow parameter triggers the generation of the constraint_fix_ratio_in_in_unit_flow and fixes the ratio between incoming flows of a unit. The parameter is defined on the relationship class unit__node__node, where both nodes (or group of nodes) in this relationship represent from_nodes, i.e. the incoming flows to the unit. The ratio parameter is interpreted such that it constrains the ratio of in1 over in2, where in1 is the unit_flow variable from the first node in the unit__node__node relationship in a left-to-right order. This parameter can be useful, for instance if a unit requires a specific commodity mix as a fuel supply.

To enforce e.g. for a unit u a fixed share of 0.8 of its incoming flow from the node supply_fuel_1 compared to its incoming flow from the node group supply_fuel_2 (consisting of the two nodes supply_fuel_2_component_a and supply_fuel_2_component_b) the fix_ratio_in_in_unit_flow parameter would be set to 0.8 for the relationship u__supply_fuel_1__supply_fuel_2.

diff --git a/dev/concept_reference/fix_ratio_in_out_unit_flow/index.html b/dev/concept_reference/fix_ratio_in_out_unit_flow/index.html index 8155aa1374..202a17b1c1 100644 --- a/dev/concept_reference/fix_ratio_in_out_unit_flow/index.html +++ b/dev/concept_reference/fix_ratio_in_out_unit_flow/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

The definition of the fix_ratio_in_out_unit_flow parameter triggers the generation of the constraint_fix_ratio_in_out_unit_flow and fixes the ratio between incoming and outgoing flows of a unit. The parameter is defined on the relationship class unit__node__node, where the first node (or group of nodes) in this relationship represents the from_node,i i.e. the incoming flows to the unit, and the second node (or group of nodes), represents the to_node i.e. the outgoing flow from the unit. The ratio parameter is interpreted such that it constrains the ratio of in over out, where in is the unit_flow variable from the first node in the unit__node__node relationship in a left-to-right order.

To enforce e.g. a fixed ratio of 1.4 for a unit u between its incoming gas flow from the node ng and its outgoing flows to the node group el_heat (consisting of the two nodes el and heat), the fix_ratio_in_out_unit_flow parameter would be set to 1.4 for the relationship u__ng__el_heat.

+- · SpineOpt.jl
GitHub

The definition of the fix_ratio_in_out_unit_flow parameter triggers the generation of the constraint_fix_ratio_in_out_unit_flow and fixes the ratio between incoming and outgoing flows of a unit. The parameter is defined on the relationship class unit__node__node, where the first node (or group of nodes) in this relationship represents the from_node,i i.e. the incoming flows to the unit, and the second node (or group of nodes), represents the to_node i.e. the outgoing flow from the unit. The ratio parameter is interpreted such that it constrains the ratio of in over out, where in is the unit_flow variable from the first node in the unit__node__node relationship in a left-to-right order.

To enforce e.g. a fixed ratio of 1.4 for a unit u between its incoming gas flow from the node ng and its outgoing flows to the node group el_heat (consisting of the two nodes el and heat), the fix_ratio_in_out_unit_flow parameter would be set to 1.4 for the relationship u__ng__el_heat.

diff --git a/dev/concept_reference/fix_ratio_out_in_connection_flow/index.html b/dev/concept_reference/fix_ratio_out_in_connection_flow/index.html index 865cc96fef..e493242651 100644 --- a/dev/concept_reference/fix_ratio_out_in_connection_flow/index.html +++ b/dev/concept_reference/fix_ratio_out_in_connection_flow/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

The definition of the fix_ratio_out_in_connection_flow parameter triggers the generation of the constraint_fix_ratio_out_in_connection_flow and fixes the ratio between outgoing and incoming flows of a connection. The parameter is defined on the relationship class connection__node__node, where the first node (or group of nodes) in this relationship represents the to_node, i.e. the outgoing flow from the connection, and the second node (or group of nodes), represents the from_node, i.e. the incoming flows to the connection. In most cases the fix_ratio_out_in_connection_flow parameter is set to equal or lower than 1, linking the flows entering to the flows leaving the connection. The ratio parameter is interpreted such that it constrains the ratio of out over in, where out is the connection_flow variable from the first node in the connection__node__node relationship in a left-to-right order. The parameter can be used to e.g. account for losses over a connection in a certain direction.

To enforce e.g. a fixed ratio of 0.8 for a connection conn between its outgoing electricity flow to node el1 and its incoming flows from the node node el2, the fix_ratio_out_in_connection_flow parameter would be set to 0.8 for the relationship u__el1__el2.

+- · SpineOpt.jl
GitHub

The definition of the fix_ratio_out_in_connection_flow parameter triggers the generation of the constraint_fix_ratio_out_in_connection_flow and fixes the ratio between outgoing and incoming flows of a connection. The parameter is defined on the relationship class connection__node__node, where the first node (or group of nodes) in this relationship represents the to_node, i.e. the outgoing flow from the connection, and the second node (or group of nodes), represents the from_node, i.e. the incoming flows to the connection. In most cases the fix_ratio_out_in_connection_flow parameter is set to equal or lower than 1, linking the flows entering to the flows leaving the connection. The ratio parameter is interpreted such that it constrains the ratio of out over in, where out is the connection_flow variable from the first node in the connection__node__node relationship in a left-to-right order. The parameter can be used to e.g. account for losses over a connection in a certain direction.

To enforce e.g. a fixed ratio of 0.8 for a connection conn between its outgoing electricity flow to node el1 and its incoming flows from the node node el2, the fix_ratio_out_in_connection_flow parameter would be set to 0.8 for the relationship u__el1__el2.

diff --git a/dev/concept_reference/fix_ratio_out_in_unit_flow/index.html b/dev/concept_reference/fix_ratio_out_in_unit_flow/index.html index 7c782f6b5b..4249c653b6 100644 --- a/dev/concept_reference/fix_ratio_out_in_unit_flow/index.html +++ b/dev/concept_reference/fix_ratio_out_in_unit_flow/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

The definition of the fix_ratio_out_in_unit_flow parameter triggers the generation of the constraint_fix_ratio_out_in_unit_flow and fixes the ratio between out and incoming flows of a unit. The parameter is defined on the relationship class unit__node__node, where the first node (or group of nodes) in this relationship represents the to_node, i.e. the outgoing flow from the unit, and the second node (or group of nodes), represents the from_node, i.e. the incoming flows to the unit. The ratio parameter is interpreted such that it constrains the ratio of out over in, where out is the unit_flow variable from the first node in the unit__node__node relationship in a left-to-right order.

To enforce e.g. a fixed ratio of 0.8 for a unit u between its outgoing flows to the node group el_heat (consisting of the two nodes el and heat) and its incoming gas flow from ngthe fix_ratio_out_in_unit_flow parameter would be set to 0.8 for the relationship u__el_heat__ng.

+- · SpineOpt.jl
GitHub

The definition of the fix_ratio_out_in_unit_flow parameter triggers the generation of the constraint_fix_ratio_out_in_unit_flow and fixes the ratio between out and incoming flows of a unit. The parameter is defined on the relationship class unit__node__node, where the first node (or group of nodes) in this relationship represents the to_node, i.e. the outgoing flow from the unit, and the second node (or group of nodes), represents the from_node, i.e. the incoming flows to the unit. The ratio parameter is interpreted such that it constrains the ratio of out over in, where out is the unit_flow variable from the first node in the unit__node__node relationship in a left-to-right order.

To enforce e.g. a fixed ratio of 0.8 for a unit u between its outgoing flows to the node group el_heat (consisting of the two nodes el and heat) and its incoming gas flow from ngthe fix_ratio_out_in_unit_flow parameter would be set to 0.8 for the relationship u__el_heat__ng.

diff --git a/dev/concept_reference/fix_ratio_out_out_unit_flow/index.html b/dev/concept_reference/fix_ratio_out_out_unit_flow/index.html index 320715dac0..deca272ade 100644 --- a/dev/concept_reference/fix_ratio_out_out_unit_flow/index.html +++ b/dev/concept_reference/fix_ratio_out_out_unit_flow/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

The definition of the fix_ratio_out_out_unit_flow parameter triggers the generation of the constraint_fix_ratio_out_out_unit_flow and fixes the ratio between outgoing flows of a unit. The parameter is defined on the relationship class unit__node__node, where the nodes (or group of nodes) in this relationship represent the to_node's', i.e. outgoing flow from the unit. The ratio parameter is interpreted such that it constrains the ratio of out1 over out2, where out1 is the unit_flow variable from the first node in the unit__node__node relationship in a left-to-right reading order.

To enforce a fixed ratio between two products of a unit u, e.g. fixing the share of produced electricity flowing to node el to 0.4 of the production of heat flowing to node heat, the fix_ratio_out_out_unit_flow parameter would be set to 0.4 for the relationship u__el__heat.

+- · SpineOpt.jl
GitHub

The definition of the fix_ratio_out_out_unit_flow parameter triggers the generation of the constraint_fix_ratio_out_out_unit_flow and fixes the ratio between outgoing flows of a unit. The parameter is defined on the relationship class unit__node__node, where the nodes (or group of nodes) in this relationship represent the to_node's', i.e. outgoing flow from the unit. The ratio parameter is interpreted such that it constrains the ratio of out1 over out2, where out1 is the unit_flow variable from the first node in the unit__node__node relationship in a left-to-right reading order.

To enforce a fixed ratio between two products of a unit u, e.g. fixing the share of produced electricity flowing to node el to 0.4 of the production of heat flowing to node heat, the fix_ratio_out_out_unit_flow parameter would be set to 0.4 for the relationship u__el__heat.

diff --git a/dev/concept_reference/fix_shut_down_unit_flow/index.html b/dev/concept_reference/fix_shut_down_unit_flow/index.html index 4d7ba8c2a4..cbf55071fe 100644 --- a/dev/concept_reference/fix_shut_down_unit_flow/index.html +++ b/dev/concept_reference/fix_shut_down_unit_flow/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

The fix_shut_down_unit_flow parameter fixes the value of the shut_down_unit_flow to the provided value, if the parameter is defined.

Common uses for the parameter include e.g. providing initial values for the shut_down_unit_flow, by fixing the value on the first modelled time step (or the value before the first modelled time step) using a TimeSeries type parameter value with an appropriate timestamp. Due to the way SpineOpt handles TimeSeries data, the shut_down_unit_flow variable is only fixed for time steps with defined fix_shut_down_unit_flow parameter values.

Other uses can include e.g. a constant or time-varying exogenous commodity flow from or to a unit.

Note that the mentioned shut_down_unit_flow variable is only included if the parameter max_startup_ramp exist for the correspond unit__to_node or unit__from_node relationship. The usage of ramps is described in Ramping and Reserves.

+- · SpineOpt.jl
GitHub

The fix_shut_down_unit_flow parameter fixes the value of the shut_down_unit_flow to the provided value, if the parameter is defined.

Common uses for the parameter include e.g. providing initial values for the shut_down_unit_flow, by fixing the value on the first modelled time step (or the value before the first modelled time step) using a TimeSeries type parameter value with an appropriate timestamp. Due to the way SpineOpt handles TimeSeries data, the shut_down_unit_flow variable is only fixed for time steps with defined fix_shut_down_unit_flow parameter values.

Other uses can include e.g. a constant or time-varying exogenous commodity flow from or to a unit.

Note that the mentioned shut_down_unit_flow variable is only included if the parameter max_startup_ramp exist for the correspond unit__to_node or unit__from_node relationship. The usage of ramps is described in Ramping and Reserves.

diff --git a/dev/concept_reference/fix_start_up_unit_flow/index.html b/dev/concept_reference/fix_start_up_unit_flow/index.html index 402b3f436f..3376d6598f 100644 --- a/dev/concept_reference/fix_start_up_unit_flow/index.html +++ b/dev/concept_reference/fix_start_up_unit_flow/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

The fix_start_up_unit_flow parameter fixes the value of the start_up_unit_flow to the provided value, if the parameter is defined.

Common uses for the parameter include e.g. providing initial values for the start_up_unit_flow, by fixing the value on the first modelled time step (or the value before the first modelled time step) using a TimeSeries type parameter value with an appropriate timestamp. Due to the way SpineOpt handles TimeSeries data, the start_up_unit_flow variable is only fixed for time steps with defined fix_start_up_unit_flow parameter values.

Other uses can include e.g. a constant or time-varying exogenous commodity flow from or to a unit.

Note that the mentioned start_up_unit_flow variable is only included if the parameter max_startup_ramp exist for the correspond unit__to_node or unit__from_node relationship. The usage of ramps is described in Ramping and Reserves.

+- · SpineOpt.jl
GitHub

The fix_start_up_unit_flow parameter fixes the value of the start_up_unit_flow to the provided value, if the parameter is defined.

Common uses for the parameter include e.g. providing initial values for the start_up_unit_flow, by fixing the value on the first modelled time step (or the value before the first modelled time step) using a TimeSeries type parameter value with an appropriate timestamp. Due to the way SpineOpt handles TimeSeries data, the start_up_unit_flow variable is only fixed for time steps with defined fix_start_up_unit_flow parameter values.

Other uses can include e.g. a constant or time-varying exogenous commodity flow from or to a unit.

Note that the mentioned start_up_unit_flow variable is only included if the parameter max_startup_ramp exist for the correspond unit__to_node or unit__from_node relationship. The usage of ramps is described in Ramping and Reserves.

diff --git a/dev/concept_reference/fix_storages_invested/index.html b/dev/concept_reference/fix_storages_invested/index.html index 9e58a7b832..907df2a51e 100644 --- a/dev/concept_reference/fix_storages_invested/index.html +++ b/dev/concept_reference/fix_storages_invested/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub
+- · SpineOpt.jl
GitHub
diff --git a/dev/concept_reference/fix_storages_invested_available/index.html b/dev/concept_reference/fix_storages_invested_available/index.html index 378ececb43..d85f171479 100644 --- a/dev/concept_reference/fix_storages_invested_available/index.html +++ b/dev/concept_reference/fix_storages_invested_available/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

Used primarily to fix the value of the storages_invested_available variable which represents the storages investment decision variable and how many candidate storages are available at the corresponding node, time step and stochastic scenario. Used also in the decomposition framework to communicate the value of the master problem solution variables to the operational sub-problem.

See also candidate_storages and Investment Optimization

+- · SpineOpt.jl
GitHub

Used primarily to fix the value of the storages_invested_available variable which represents the storages investment decision variable and how many candidate storages are available at the corresponding node, time step and stochastic scenario. Used also in the decomposition framework to communicate the value of the master problem solution variables to the operational sub-problem.

See also candidate_storages and Investment Optimization

diff --git a/dev/concept_reference/fix_unit_flow/index.html b/dev/concept_reference/fix_unit_flow/index.html index d834389a57..733081b83f 100644 --- a/dev/concept_reference/fix_unit_flow/index.html +++ b/dev/concept_reference/fix_unit_flow/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

The fix_unit_flow parameter fixes the value of the unit_flow variable to the provided value, if the parameter is defined.

Common uses for the parameter include e.g. providing initial values for the unit_flow variable, by fixing the value on the first modelled time step (or the value before the first modelled time step) using a TimeSeries type parameter value with an appropriate timestamp. Due to the way SpineOpt handles TimeSeries data, the unit_flow variable is only fixed for time steps with defined fix_unit_flow parameter values.

Other uses can include e.g. a constant or time-varying exogenous commodity flow from or to a unit.

+- · SpineOpt.jl
GitHub

The fix_unit_flow parameter fixes the value of the unit_flow variable to the provided value, if the parameter is defined.

Common uses for the parameter include e.g. providing initial values for the unit_flow variable, by fixing the value on the first modelled time step (or the value before the first modelled time step) using a TimeSeries type parameter value with an appropriate timestamp. Due to the way SpineOpt handles TimeSeries data, the unit_flow variable is only fixed for time steps with defined fix_unit_flow parameter values.

Other uses can include e.g. a constant or time-varying exogenous commodity flow from or to a unit.

diff --git a/dev/concept_reference/fix_unit_flow_op/index.html b/dev/concept_reference/fix_unit_flow_op/index.html index 6e9381023c..e7267da4da 100644 --- a/dev/concept_reference/fix_unit_flow_op/index.html +++ b/dev/concept_reference/fix_unit_flow_op/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

If operating_points is defined on a certain unit__to_node or unit__from_node flow, the corresponding unit_flow flow variable is decomposed into a number of sub-variables, unit_flow_op one for each operating point, with an additional index, i to reference the specific operating point. fix_unit_flow_op can thus be used to fix the value of one or more of the variables as desired.

+- · SpineOpt.jl
GitHub

If operating_points is defined on a certain unit__to_node or unit__from_node flow, the corresponding unit_flow flow variable is decomposed into a number of sub-variables, unit_flow_op one for each operating point, with an additional index, i to reference the specific operating point. fix_unit_flow_op can thus be used to fix the value of one or more of the variables as desired.

diff --git a/dev/concept_reference/fix_units_invested/index.html b/dev/concept_reference/fix_units_invested/index.html index 31840df2bb..aef6db2690 100644 --- a/dev/concept_reference/fix_units_invested/index.html +++ b/dev/concept_reference/fix_units_invested/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub
+- · SpineOpt.jl
GitHub
diff --git a/dev/concept_reference/fix_units_invested_available/index.html b/dev/concept_reference/fix_units_invested_available/index.html index 10e00e98fb..01afc2af34 100644 --- a/dev/concept_reference/fix_units_invested_available/index.html +++ b/dev/concept_reference/fix_units_invested_available/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

Used primarily to fix the value of the units_invested_available variable which represents the unit investment decision variable and how many candidate units are invested-in and available at the corresponding node, time step and stochastic scenario. Used also in the decomposition framework to communicate the value of the master problem solution variables to the operational sub-problem.

See also Investment Optimization, candidate_units and unit_investment_variable_type

+- · SpineOpt.jl
GitHub

Used primarily to fix the value of the units_invested_available variable which represents the unit investment decision variable and how many candidate units are invested-in and available at the corresponding node, time step and stochastic scenario. Used also in the decomposition framework to communicate the value of the master problem solution variables to the operational sub-problem.

See also Investment Optimization, candidate_units and unit_investment_variable_type

diff --git a/dev/concept_reference/fix_units_on/index.html b/dev/concept_reference/fix_units_on/index.html index 4b87744b11..b6222cc988 100644 --- a/dev/concept_reference/fix_units_on/index.html +++ b/dev/concept_reference/fix_units_on/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

The fix_units_on parameter simply fixes the value of the units_on variable to the provided value. As such, it determines directly how many members of the specific unit will be online throughout the model when a single value is selected. It is also possible to provide a timeseries of values, which can be used for example to impose initial conditions by providing a value only for the first timestep included in the model.

+- · SpineOpt.jl
GitHub

The fix_units_on parameter simply fixes the value of the units_on variable to the provided value. As such, it determines directly how many members of the specific unit will be online throughout the model when a single value is selected. It is also possible to provide a timeseries of values, which can be used for example to impose initial conditions by providing a value only for the first timestep included in the model.

diff --git a/dev/concept_reference/fix_units_on_coefficient_in_in/index.html b/dev/concept_reference/fix_units_on_coefficient_in_in/index.html index 1f5d18ff7d..a5d0a34b93 100644 --- a/dev/concept_reference/fix_units_on_coefficient_in_in/index.html +++ b/dev/concept_reference/fix_units_on_coefficient_in_in/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

The fix_units_on_coefficient_in_in parameter is an optional coefficient in the unit input-input ratio constraint controlled by the fix_ratio_in_in_unit_flow parameter. Essentially, it acts as a coefficient for the units_on variable in the constraint, allowing for fixing the conversion ratio depending on the amount of online capacity.

Note that there are different parameters depending on the directions of the unit_flow variables being constrained: fix_units_on_coefficient_in_out, fix_units_on_coefficient_out_in, and fix_units_on_coefficient_out_out, all of which apply to their respective constraints. Similarly, there are different parameters for setting minimum or maximum conversion rates, e.g. min_units_on_coefficient_in_in and max_units_on_coefficient_in_in.

+- · SpineOpt.jl
GitHub

The fix_units_on_coefficient_in_in parameter is an optional coefficient in the unit input-input ratio constraint controlled by the fix_ratio_in_in_unit_flow parameter. Essentially, it acts as a coefficient for the units_on variable in the constraint, allowing for fixing the conversion ratio depending on the amount of online capacity.

Note that there are different parameters depending on the directions of the unit_flow variables being constrained: fix_units_on_coefficient_in_out, fix_units_on_coefficient_out_in, and fix_units_on_coefficient_out_out, all of which apply to their respective constraints. Similarly, there are different parameters for setting minimum or maximum conversion rates, e.g. min_units_on_coefficient_in_in and max_units_on_coefficient_in_in.

diff --git a/dev/concept_reference/fix_units_on_coefficient_in_out/index.html b/dev/concept_reference/fix_units_on_coefficient_in_out/index.html index 91de54596c..95693a6b45 100644 --- a/dev/concept_reference/fix_units_on_coefficient_in_out/index.html +++ b/dev/concept_reference/fix_units_on_coefficient_in_out/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

The fix_units_on_coefficient_in_out parameter is an optional coefficient in the unit input-output ratio constraint controlled by the fix_ratio_in_out_unit_flow parameter. Essentially, it acts as a coefficient for the units_on variable in the constraint, allowing for fixing the conversion ratio depending on the amount of online capacity.

Note that there are different parameters depending on the directions of the unit_flow variables being constrained: fix_units_on_coefficient_in_in, fix_units_on_coefficient_out_in, and fix_units_on_coefficient_out_out, all of which apply to their respective constraints. Similarly, there are different parameters for setting minimum or maximum conversion rates, e.g. min_units_on_coefficient_in_out and max_units_on_coefficient_in_out.

+- · SpineOpt.jl
GitHub

The fix_units_on_coefficient_in_out parameter is an optional coefficient in the unit input-output ratio constraint controlled by the fix_ratio_in_out_unit_flow parameter. Essentially, it acts as a coefficient for the units_on variable in the constraint, allowing for fixing the conversion ratio depending on the amount of online capacity.

Note that there are different parameters depending on the directions of the unit_flow variables being constrained: fix_units_on_coefficient_in_in, fix_units_on_coefficient_out_in, and fix_units_on_coefficient_out_out, all of which apply to their respective constraints. Similarly, there are different parameters for setting minimum or maximum conversion rates, e.g. min_units_on_coefficient_in_out and max_units_on_coefficient_in_out.

diff --git a/dev/concept_reference/fix_units_on_coefficient_out_in/index.html b/dev/concept_reference/fix_units_on_coefficient_out_in/index.html index 212869c1af..4668922443 100644 --- a/dev/concept_reference/fix_units_on_coefficient_out_in/index.html +++ b/dev/concept_reference/fix_units_on_coefficient_out_in/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

The fix_units_on_coefficient_out_in parameter is an optional coefficient in the unit output-input ratio constraint controlled by the fix_ratio_out_in_unit_flow parameter. Essentially, it acts as a coefficient for the units_on variable in the constraint, allowing for fixing the conversion ratio depending on the amount of online capacity.

Note that there are different parameters depending on the directions of the unit_flow variables being constrained: fix_units_on_coefficient_in_in, fix_units_on_coefficient_in_out, and fix_units_on_coefficient_out_out, all of which apply to their respective constraints. Similarly, there are different parameters for setting minimum or maximum conversion rates, e.g. min_units_on_coefficient_out_in and max_units_on_coefficient_out_in.

+- · SpineOpt.jl
GitHub

The fix_units_on_coefficient_out_in parameter is an optional coefficient in the unit output-input ratio constraint controlled by the fix_ratio_out_in_unit_flow parameter. Essentially, it acts as a coefficient for the units_on variable in the constraint, allowing for fixing the conversion ratio depending on the amount of online capacity.

Note that there are different parameters depending on the directions of the unit_flow variables being constrained: fix_units_on_coefficient_in_in, fix_units_on_coefficient_in_out, and fix_units_on_coefficient_out_out, all of which apply to their respective constraints. Similarly, there are different parameters for setting minimum or maximum conversion rates, e.g. min_units_on_coefficient_out_in and max_units_on_coefficient_out_in.

diff --git a/dev/concept_reference/fix_units_on_coefficient_out_out/index.html b/dev/concept_reference/fix_units_on_coefficient_out_out/index.html index 7ae420b02c..1cf6029a14 100644 --- a/dev/concept_reference/fix_units_on_coefficient_out_out/index.html +++ b/dev/concept_reference/fix_units_on_coefficient_out_out/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

The fix_units_on_coefficient_out_out parameter is an optional coefficient in the unit output-output ratio constraint controlled by the fix_ratio_out_out_unit_flow parameter. Essentially, it acts as a coefficient for the units_on variable in the constraint, allowing for fixing the conversion ratio depending on the amount of online capacity.

Note that there are different parameters depending on the directions of the unit_flow variables being constrained: fix_units_on_coefficient_in_in, fix_units_on_coefficient_in_out, and fix_units_on_coefficient_out_in, all of which apply to their respective constraints. Similarly, there are different parameters for setting minimum or maximum conversion rates, e.g. min_units_on_coefficient_out_out and max_units_on_coefficient_out_out.

+- · SpineOpt.jl
GitHub

The fix_units_on_coefficient_out_out parameter is an optional coefficient in the unit output-output ratio constraint controlled by the fix_ratio_out_out_unit_flow parameter. Essentially, it acts as a coefficient for the units_on variable in the constraint, allowing for fixing the conversion ratio depending on the amount of online capacity.

Note that there are different parameters depending on the directions of the unit_flow variables being constrained: fix_units_on_coefficient_in_in, fix_units_on_coefficient_in_out, and fix_units_on_coefficient_out_in, all of which apply to their respective constraints. Similarly, there are different parameters for setting minimum or maximum conversion rates, e.g. min_units_on_coefficient_out_out and max_units_on_coefficient_out_out.

diff --git a/dev/concept_reference/fixed_pressure_constant_0/index.html b/dev/concept_reference/fixed_pressure_constant_0/index.html index dd2d3d72f0..448e0b7c72 100644 --- a/dev/concept_reference/fixed_pressure_constant_0/index.html +++ b/dev/concept_reference/fixed_pressure_constant_0/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

For the MILP representation of pressure driven gas transfer, we use an outer approximation approach as described by Schwele et al.. The Weymouth equation is approximated around fixed pressure points, as described by the constraint on fixed node pressure points, constraining the average flow in each direction dependent on the adjacent node pressures. The second fixed pressure constant, which will be multiplied with the pressure of the destination node, is represented by an Array value of the fixed_pressure_constant_0. The first pressure constant corresponds to the related parameter fixed_pressure_constant_1. Note that the fixed_pressure_constant_0 parameter should be defined on a connection__node__node relationship, for which the first node corresponds to the origin node, while the second node corresponds to the destination node. For a typical gas pipeline, the will be a fixed_pressure_constant_1 for both directions of flow.

+- · SpineOpt.jl
GitHub

For the MILP representation of pressure driven gas transfer, we use an outer approximation approach as described by Schwele et al.. The Weymouth equation is approximated around fixed pressure points, as described by the constraint on fixed node pressure points, constraining the average flow in each direction dependent on the adjacent node pressures. The second fixed pressure constant, which will be multiplied with the pressure of the destination node, is represented by an Array value of the fixed_pressure_constant_0. The first pressure constant corresponds to the related parameter fixed_pressure_constant_1. Note that the fixed_pressure_constant_0 parameter should be defined on a connection__node__node relationship, for which the first node corresponds to the origin node, while the second node corresponds to the destination node. For a typical gas pipeline, the will be a fixed_pressure_constant_1 for both directions of flow.

diff --git a/dev/concept_reference/fixed_pressure_constant_1/index.html b/dev/concept_reference/fixed_pressure_constant_1/index.html index 471022f2d3..153f56e294 100644 --- a/dev/concept_reference/fixed_pressure_constant_1/index.html +++ b/dev/concept_reference/fixed_pressure_constant_1/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

For the MILP representation of pressure driven gas transfer, we use an outer approximation approach as described by Schwele et al.. The Weymouth equation is approximated around fixed pressure points, as described by the constraint on fixed node pressure points, constraining the average flow in each direction dependent on the adjacent node pressures. The first fixed pressure constant, which will be multiplied with the pressure of the origin node, is represented by an Array value of the fixed_pressure_constant_1. The second pressure constant corresponds to the related parameter fixed_pressure_constant_0. Note that the fixed_pressure_constant_1 parameter should be defined on a connection__node__node relationship, for which the first node corresponds to the origin node, while the second node corresponds to the destination node. For a typical gas pipeline, the will be a fixed_pressure_constant_1 for both directions of flow.

+- · SpineOpt.jl
GitHub

For the MILP representation of pressure driven gas transfer, we use an outer approximation approach as described by Schwele et al.. The Weymouth equation is approximated around fixed pressure points, as described by the constraint on fixed node pressure points, constraining the average flow in each direction dependent on the adjacent node pressures. The first fixed pressure constant, which will be multiplied with the pressure of the origin node, is represented by an Array value of the fixed_pressure_constant_1. The second pressure constant corresponds to the related parameter fixed_pressure_constant_0. Note that the fixed_pressure_constant_1 parameter should be defined on a connection__node__node relationship, for which the first node corresponds to the origin node, while the second node corresponds to the destination node. For a typical gas pipeline, the will be a fixed_pressure_constant_1 for both directions of flow.

diff --git a/dev/concept_reference/fom_cost/index.html b/dev/concept_reference/fom_cost/index.html index 66760cdd8a..44e506cf4a 100644 --- a/dev/concept_reference/fom_cost/index.html +++ b/dev/concept_reference/fom_cost/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

By defining the fom_cost parameter for a specific unit, a cost term will be added to the objective function to account for the fixed operation and maintenance costs associated with that unit during the current optimization window. fom_cost differs from units_on_cost in a way that the fixed operation and maintenance costs apply to both the online and offline unit.

+- · SpineOpt.jl
GitHub

By defining the fom_cost parameter for a specific unit, a cost term will be added to the objective function to account for the fixed operation and maintenance costs associated with that unit during the current optimization window. fom_cost differs from units_on_cost in a way that the fixed operation and maintenance costs apply to both the online and offline unit.

diff --git a/dev/concept_reference/frac_state_loss/index.html b/dev/concept_reference/frac_state_loss/index.html index eb4a68781e..2e5d26ba55 100644 --- a/dev/concept_reference/frac_state_loss/index.html +++ b/dev/concept_reference/frac_state_loss/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

The frac_state_loss parameter allows setting self-discharge losses for nodes with the node_state variables enabled using the has_state variable. Effectively, the frac_state_loss parameter acts as a coefficient on the node_state variable in the node injection constraint, imposing losses for the node. In simple cases, storage losses are typically fractional, e.g. a frac_state_loss parameter value of 0.01 would represent 1% of node_state lost per unit of time. However, a more general definition of what the frac_state_loss parameter represents in SpineOpt would be loss power per unit of node_state.

+- · SpineOpt.jl
GitHub

The frac_state_loss parameter allows setting self-discharge losses for nodes with the node_state variables enabled using the has_state variable. Effectively, the frac_state_loss parameter acts as a coefficient on the node_state variable in the node injection constraint, imposing losses for the node. In simple cases, storage losses are typically fractional, e.g. a frac_state_loss parameter value of 0.01 would represent 1% of node_state lost per unit of time. However, a more general definition of what the frac_state_loss parameter represents in SpineOpt would be loss power per unit of node_state.

diff --git a/dev/concept_reference/fractional_demand/index.html b/dev/concept_reference/fractional_demand/index.html index ec19644fe9..c23430b8b5 100644 --- a/dev/concept_reference/fractional_demand/index.html +++ b/dev/concept_reference/fractional_demand/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub
+- · SpineOpt.jl
GitHub
diff --git a/dev/concept_reference/fuel_cost/index.html b/dev/concept_reference/fuel_cost/index.html index 390c3eb3eb..0e3d9fed93 100644 --- a/dev/concept_reference/fuel_cost/index.html +++ b/dev/concept_reference/fuel_cost/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

By defining the fuel_cost parameter for a specific unit, node, and direction, a cost term will be added to the objective function to account for costs associated with the unit's fuel usage over the course of its operational dispatch during the current optimization window.

+- · SpineOpt.jl
GitHub

By defining the fuel_cost parameter for a specific unit, node, and direction, a cost term will be added to the objective function to account for costs associated with the unit's fuel usage over the course of its operational dispatch during the current optimization window.

diff --git a/dev/concept_reference/graph_view_position/index.html b/dev/concept_reference/graph_view_position/index.html index b24b67c22e..d7104321e0 100644 --- a/dev/concept_reference/graph_view_position/index.html +++ b/dev/concept_reference/graph_view_position/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

The graph_view_position parameter can be used to fix the positions of various objects and relationships when plotted using the Spine Toolbox Graph View. If not defined, Spine Toolbox simply plots the element in question wherever it sees fit in the graph.

+- · SpineOpt.jl
GitHub

The graph_view_position parameter can be used to fix the positions of various objects and relationships when plotted using the Spine Toolbox Graph View. If not defined, Spine Toolbox simply plots the element in question wherever it sees fit in the graph.

diff --git a/dev/concept_reference/has_binary_gas_flow/index.html b/dev/concept_reference/has_binary_gas_flow/index.html index b6ba52b7b7..835756e72b 100644 --- a/dev/concept_reference/has_binary_gas_flow/index.html +++ b/dev/concept_reference/has_binary_gas_flow/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

This parameter is necessary for the use of pressure driven gas transfer, for which the direction of flow is not known a priori. The parameter has_binary_gas_flow is a booelean method parameter, which - when set to true - triggers the generation of the binary variables binary_gas_connection_flow, which (together with the big_m parameter) forces the average flow through a pipeline to be unidirectional.

+- · SpineOpt.jl
GitHub

This parameter is necessary for the use of pressure driven gas transfer, for which the direction of flow is not known a priori. The parameter has_binary_gas_flow is a booelean method parameter, which - when set to true - triggers the generation of the binary variables binary_gas_connection_flow, which (together with the big_m parameter) forces the average flow through a pipeline to be unidirectional.

diff --git a/dev/concept_reference/has_pressure/index.html b/dev/concept_reference/has_pressure/index.html index e0d7cfc30e..3a6d06ab8a 100644 --- a/dev/concept_reference/has_pressure/index.html +++ b/dev/concept_reference/has_pressure/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

If a node is to represent a node in a pressure driven gas network, the boolean parameter has_pressure should be set true, in order to trigger the generation of the node_pressure variable. The pressure at a certain node can also be constrainted through the parameters max_node_pressure and min_node_pressure. More details on the use of pressure driven gas transfer are described here

+- · SpineOpt.jl
GitHub

If a node is to represent a node in a pressure driven gas network, the boolean parameter has_pressure should be set true, in order to trigger the generation of the node_pressure variable. The pressure at a certain node can also be constrainted through the parameters max_node_pressure and min_node_pressure. More details on the use of pressure driven gas transfer are described here

diff --git a/dev/concept_reference/has_state/index.html b/dev/concept_reference/has_state/index.html index f545395882..f99ce752be 100644 --- a/dev/concept_reference/has_state/index.html +++ b/dev/concept_reference/has_state/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

The has_state parameter is simply a Bool flag for whether a node has a node_state variable. By default, it is set to false, so the nodes enforce instantaneous commodity balance according to the nodal balance and node injection constraints. If set to true, the node will have a node_state variable generated for it, allowing for commodity storage at the node. Note that you'll also have to specify a value for the state_coeff parameter, as otherwise the node_state variable has zero commodity capacity.

+- · SpineOpt.jl
GitHub

The has_state parameter is simply a Bool flag for whether a node has a node_state variable. By default, it is set to false, so the nodes enforce instantaneous commodity balance according to the nodal balance and node injection constraints. If set to true, the node will have a node_state variable generated for it, allowing for commodity storage at the node. Note that you'll also have to specify a value for the state_coeff parameter, as otherwise the node_state variable has zero commodity capacity.

diff --git a/dev/concept_reference/has_voltage_angle/index.html b/dev/concept_reference/has_voltage_angle/index.html index cda77f9bab..ecf22caadc 100644 --- a/dev/concept_reference/has_voltage_angle/index.html +++ b/dev/concept_reference/has_voltage_angle/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

For the use of node-based lossless DC powerflow, each node will be associated with a node_voltage_angle variable. To enable the generation of the variable in the optimization model, the boolean parameter has_voltage_angle should be set true. The voltage angle at a certain node can also be constrained through the parameters max_voltage_angle and min_voltage_angle. More details on the use of lossless nodal DC power flows are described here

+- · SpineOpt.jl
GitHub

For the use of node-based lossless DC powerflow, each node will be associated with a node_voltage_angle variable. To enable the generation of the variable in the optimization model, the boolean parameter has_voltage_angle should be set true. The voltage angle at a certain node can also be constrained through the parameters max_voltage_angle and min_voltage_angle. More details on the use of lossless nodal DC power flows are described here

diff --git a/dev/concept_reference/investment_group/index.html b/dev/concept_reference/investment_group/index.html index d608c09d7e..f733ecfae4 100644 --- a/dev/concept_reference/investment_group/index.html +++ b/dev/concept_reference/investment_group/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

The investment_group class represents a group of investments that need to be done together. For example, a storage investment on a node might only make sense if done together with a unit or a connection investment.

To use this functionality, you must first create an investment_group and then specify any number of unit__investment_group, node__investment_group, and/or connection__investment_group relationships between your investment_group and the unit, node, and/or connection investments that you want to be done together. This will ensure that the investment variables of all the entities in the investment_group have the same value.

+- · SpineOpt.jl
GitHub

The investment_group class represents a group of investments that need to be done together. For example, a storage investment on a node might only make sense if done together with a unit or a connection investment.

To use this functionality, you must first create an investment_group and then specify any number of unit__investment_group, node__investment_group, and/or connection__investment_group relationships between your investment_group and the unit, node, and/or connection investments that you want to be done together. This will ensure that the investment variables of all the entities in the investment_group have the same value.

diff --git a/dev/concept_reference/is_active/index.html b/dev/concept_reference/is_active/index.html index 8495ef9ebe..6c6358488e 100644 --- a/dev/concept_reference/is_active/index.html +++ b/dev/concept_reference/is_active/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

is_acive is a universal, utility parameter that is defined for every object class. When used in conjunction with the activity_control feature, the is_active parameter allows one to control whether or not a specific object is active within a model or not.

+- · SpineOpt.jl
GitHub

is_acive is a universal, utility parameter that is defined for every object class. When used in conjunction with the activity_control feature, the is_active parameter allows one to control whether or not a specific object is active within a model or not.

diff --git a/dev/concept_reference/is_non_spinning/index.html b/dev/concept_reference/is_non_spinning/index.html index 1b42306320..b3daa5f332 100644 --- a/dev/concept_reference/is_non_spinning/index.html +++ b/dev/concept_reference/is_non_spinning/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

By setting the parameter is_non_spinning to true, a node is treated as a non-spinning reserve node. Note that this is only to differentiate spinning from non-spinning reserves. It is still necessary to define the is_reserve_node to true. reserve node in the model. To define the maximum reserve provision of a non-spinning reserve flow (defined on a unit__to_node relationship), it is also necessary to define the max_res_startup_ramp and the max_res_shutdown_ramp parameters, respectively. It is also possible to define a minimum reserve provision ramp by defining the parameters min_res_startup_ramp and min_res_shutdown_ramp. The mathematical formulation holds a chapter on Ramping and reserve constraints and the general concept of setting up a model with reserves is described in Ramping and Reserves.

+- · SpineOpt.jl
GitHub

By setting the parameter is_non_spinning to true, a node is treated as a non-spinning reserve node. Note that this is only to differentiate spinning from non-spinning reserves. It is still necessary to define the is_reserve_node to true. reserve node in the model. To define the maximum reserve provision of a non-spinning reserve flow (defined on a unit__to_node relationship), it is also necessary to define the max_res_startup_ramp and the max_res_shutdown_ramp parameters, respectively. It is also possible to define a minimum reserve provision ramp by defining the parameters min_res_startup_ramp and min_res_shutdown_ramp. The mathematical formulation holds a chapter on Ramping and reserve constraints and the general concept of setting up a model with reserves is described in Ramping and Reserves.

diff --git a/dev/concept_reference/is_renewable/index.html b/dev/concept_reference/is_renewable/index.html index 5279ef5d98..ba230f4038 100644 --- a/dev/concept_reference/is_renewable/index.html +++ b/dev/concept_reference/is_renewable/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

A boolean value indicating whether a unit is a renewable energy source (RES). If true, then the unit contributes to the share of the demand that is supplied by RES in the context of mp_min_res_gen_to_demand_ratio.

+- · SpineOpt.jl
GitHub

A boolean value indicating whether a unit is a renewable energy source (RES). If true, then the unit contributes to the share of the demand that is supplied by RES in the context of mp_min_res_gen_to_demand_ratio.

diff --git a/dev/concept_reference/is_reserve_node/index.html b/dev/concept_reference/is_reserve_node/index.html index 28d0d8d356..3e6cf18c99 100644 --- a/dev/concept_reference/is_reserve_node/index.html +++ b/dev/concept_reference/is_reserve_node/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

By setting the parameter is_reserve_node to true, a node is treated as a reserve node in the model. Units that are linked through a unit__to_node relationship will be able to provide balancing services to the reserve node, but within their technical feasibility. The mathematical formulation holds a chapter on Ramping and reserve constraints and the general concept of setting up a model with reserves is described in Ramping and Reserves.

+- · SpineOpt.jl
GitHub

By setting the parameter is_reserve_node to true, a node is treated as a reserve node in the model. Units that are linked through a unit__to_node relationship will be able to provide balancing services to the reserve node, but within their technical feasibility. The mathematical formulation holds a chapter on Ramping and reserve constraints and the general concept of setting up a model with reserves is described in Ramping and Reserves.

diff --git a/dev/concept_reference/max_cum_in_unit_flow_bound/index.html b/dev/concept_reference/max_cum_in_unit_flow_bound/index.html index 07de011b4f..37bc4b520e 100644 --- a/dev/concept_reference/max_cum_in_unit_flow_bound/index.html +++ b/dev/concept_reference/max_cum_in_unit_flow_bound/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

To impose a limit on the cumulative in flows to a unit for the entire modelling horizon, e.g. to enforce limits on emissions, the max_cum_in_unit_flow_bound parameter can be used. Defining this parameter triggers the generation of the constraint_max_cum_in_unit_flow_bound.

Assuming for instance that the total intake of a unit u_A should not exceed 10MWh for the entire modelling horizon, then the max_cum_in_unit_flow_bound would need to take the value 10. (Assuming here that the unit_flow variable is in MW, and the model duration_unit is hours)

+- · SpineOpt.jl
GitHub

To impose a limit on the cumulative in flows to a unit for the entire modelling horizon, e.g. to enforce limits on emissions, the max_cum_in_unit_flow_bound parameter can be used. Defining this parameter triggers the generation of the constraint_max_cum_in_unit_flow_bound.

Assuming for instance that the total intake of a unit u_A should not exceed 10MWh for the entire modelling horizon, then the max_cum_in_unit_flow_bound would need to take the value 10. (Assuming here that the unit_flow variable is in MW, and the model duration_unit is hours)

diff --git a/dev/concept_reference/max_gap/index.html b/dev/concept_reference/max_gap/index.html index 63c36037fa..9e21c473b0 100644 --- a/dev/concept_reference/max_gap/index.html +++ b/dev/concept_reference/max_gap/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

This determines the optimality convergence criterion and is the benders gap tolerance for the master problem in a decomposed investments model. The benders gap is the relative difference between the current objective function upper bound(zupper) and lower bound (zlower) and is defined as 2*(zupper-zlower)/(zupper + zlower). When this value is lower than max_gap the benders algorithm will terminate having achieved satisfactory optimality.

+- · SpineOpt.jl
GitHub

This determines the optimality convergence criterion and is the benders gap tolerance for the master problem in a decomposed investments model. The benders gap is the relative difference between the current objective function upper bound(zupper) and lower bound (zlower) and is defined as 2*(zupper-zlower)/(zupper + zlower). When this value is lower than max_gap the benders algorithm will terminate having achieved satisfactory optimality.

diff --git a/dev/concept_reference/max_iterations/index.html b/dev/concept_reference/max_iterations/index.html index 4f7369aae7..afadc5bee7 100644 --- a/dev/concept_reference/max_iterations/index.html +++ b/dev/concept_reference/max_iterations/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

When the model in question is of type :spineopt_benders_master, this determines the maximum number of Benders iterations.

+- · SpineOpt.jl
GitHub

When the model in question is of type :spineopt_benders_master, this determines the maximum number of Benders iterations.

diff --git a/dev/concept_reference/max_mga_iterations/index.html b/dev/concept_reference/max_mga_iterations/index.html index 24636607c8..ee726f8c12 100644 --- a/dev/concept_reference/max_mga_iterations/index.html +++ b/dev/concept_reference/max_mga_iterations/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

In the MGA algorithm the original problem is reoptimized (see also mga-advanced), and finds near-optimal solutions. The parameter max_mga_iterations defines how many MGA iterations will be performed, i.e. how many near-optimal solutions will be generated.

+- · SpineOpt.jl
GitHub

In the MGA algorithm the original problem is reoptimized (see also mga-advanced), and finds near-optimal solutions. The parameter max_mga_iterations defines how many MGA iterations will be performed, i.e. how many near-optimal solutions will be generated.

diff --git a/dev/concept_reference/max_mga_slack/index.html b/dev/concept_reference/max_mga_slack/index.html index e4cf67055c..8606bd341c 100644 --- a/dev/concept_reference/max_mga_slack/index.html +++ b/dev/concept_reference/max_mga_slack/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

In the MGA algorithm the original problem is reoptimized (see also mga-advanced), and finds near-optimal solutions. The parameter max_mga_slack defines how far from the optimum the new solutions can maximally be (e.g. a value of 0.05 would alow for a 5% increase of the orginal objective value).

+- · SpineOpt.jl
GitHub

In the MGA algorithm the original problem is reoptimized (see also mga-advanced), and finds near-optimal solutions. The parameter max_mga_slack defines how far from the optimum the new solutions can maximally be (e.g. a value of 0.05 would alow for a 5% increase of the orginal objective value).

diff --git a/dev/concept_reference/max_node_pressure/index.html b/dev/concept_reference/max_node_pressure/index.html index 2eb7035859..5064dd87ac 100644 --- a/dev/concept_reference/max_node_pressure/index.html +++ b/dev/concept_reference/max_node_pressure/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub
+- · SpineOpt.jl
GitHub
diff --git a/dev/concept_reference/max_ratio_in_in_unit_flow/index.html b/dev/concept_reference/max_ratio_in_in_unit_flow/index.html index 6371629816..33cc66bb31 100644 --- a/dev/concept_reference/max_ratio_in_in_unit_flow/index.html +++ b/dev/concept_reference/max_ratio_in_in_unit_flow/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

The definition of the max_ratio_in_in_unit_flow parameter triggers the generation of the constraint_max_ratio_in_in_unit_flow and enforces an upper bound on the ratio between incoming flows of a unit. The parameter is defined on the relationship class unit__node__node, where both nodes (or group of nodes) in this relationship represent from_nodes, i.e. the incoming flows to the unit. The ratio parameter is interpreted such that it constrains the ratio of in1 over in2, where in1 is the unit_flow variable from the first node in the unit__node__node relationship in a left-to-right reading order. This parameter can be useful, for instance if a unit requires a specific commodity mix as a fuel supply.

To enforce e.g. for a unit u a maximum share of 0.8 of its incoming flow from the node supply_fuel_1 compared to its incoming flow from the node group supply_fuel_2 (consisting of the two nodes supply_fuel_2_component_a and supply_fuel_2_component_b) the max_ratio_in_in_unit_flow parameter would be set to 0.8 for the relationship u__supply_fuel_1__supply_fuel_2.

+- · SpineOpt.jl
GitHub

The definition of the max_ratio_in_in_unit_flow parameter triggers the generation of the constraint_max_ratio_in_in_unit_flow and enforces an upper bound on the ratio between incoming flows of a unit. The parameter is defined on the relationship class unit__node__node, where both nodes (or group of nodes) in this relationship represent from_nodes, i.e. the incoming flows to the unit. The ratio parameter is interpreted such that it constrains the ratio of in1 over in2, where in1 is the unit_flow variable from the first node in the unit__node__node relationship in a left-to-right reading order. This parameter can be useful, for instance if a unit requires a specific commodity mix as a fuel supply.

To enforce e.g. for a unit u a maximum share of 0.8 of its incoming flow from the node supply_fuel_1 compared to its incoming flow from the node group supply_fuel_2 (consisting of the two nodes supply_fuel_2_component_a and supply_fuel_2_component_b) the max_ratio_in_in_unit_flow parameter would be set to 0.8 for the relationship u__supply_fuel_1__supply_fuel_2.

diff --git a/dev/concept_reference/max_ratio_in_out_unit_flow/index.html b/dev/concept_reference/max_ratio_in_out_unit_flow/index.html index 939d3eb740..0121159c57 100644 --- a/dev/concept_reference/max_ratio_in_out_unit_flow/index.html +++ b/dev/concept_reference/max_ratio_in_out_unit_flow/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

The definition of the max_ratio_in_out_unit_flow parameter triggers the generation of the constraint_max_ratio_in_out_unit_flow and sets an upper bound on the ratio between incoming and outgoing flows of a unit. The parameter is defined on the relationship class unit__node__node, where the first node (or group of nodes) in this relationship represents the from_node, i.e. the incoming flows to the unit, and the second node (or group of nodes), represents the to_node i.e. the outgoing flow from the unit. The ratio parameter is interpreted such that it constrains the ratio of in over out, where in is the unit_flow variable from the first node in the unit__node__node relationship in a left-to-right reading order.

To enforce e.g. a maximum ratio of 1.4 for a unit u between its incoming gas flow from the node ng and its outgoing flow to the node group el_heat (consisting of the two nodes el and heat), the max_ratio_in_out_unit_flow parameter would be set to 1.4 for the relationship u__ng__el_heat.

+- · SpineOpt.jl
GitHub

The definition of the max_ratio_in_out_unit_flow parameter triggers the generation of the constraint_max_ratio_in_out_unit_flow and sets an upper bound on the ratio between incoming and outgoing flows of a unit. The parameter is defined on the relationship class unit__node__node, where the first node (or group of nodes) in this relationship represents the from_node, i.e. the incoming flows to the unit, and the second node (or group of nodes), represents the to_node i.e. the outgoing flow from the unit. The ratio parameter is interpreted such that it constrains the ratio of in over out, where in is the unit_flow variable from the first node in the unit__node__node relationship in a left-to-right reading order.

To enforce e.g. a maximum ratio of 1.4 for a unit u between its incoming gas flow from the node ng and its outgoing flow to the node group el_heat (consisting of the two nodes el and heat), the max_ratio_in_out_unit_flow parameter would be set to 1.4 for the relationship u__ng__el_heat.

diff --git a/dev/concept_reference/max_ratio_out_in_connection_flow/index.html b/dev/concept_reference/max_ratio_out_in_connection_flow/index.html index 2cd2baf024..c5c98827de 100644 --- a/dev/concept_reference/max_ratio_out_in_connection_flow/index.html +++ b/dev/concept_reference/max_ratio_out_in_connection_flow/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

The definition of the max_ratio_out_in_connection_flow parameter triggers the generation of the constraint_max_ratio_out_in_connection_flow and sets an upper bound on the ratio between outgoing and incoming flows of a connection. The parameter is defined on the relationship class connection__node__node, where the first node (or group of nodes) in this relationship represents the to_node, i.e. the outgoing flow from the connection, and the second node (or group of nodes), represents the from_node, i.e. the incoming flows to the connection. The ratio parameter is interpreted such that it constrains the ratio of out over in, where out is the connection_flow variable from the first node in the connection__node__node relationship in a left-to-right reading order.

To enforce e.g. a maximum ratio of 0.8 for a connection conn between its outgoing electricity flow to node commodity1 and its incoming flows from the node node commodity2, the max_ratio_out_in_connection_flow parameter would be set to 0.8 for the relationship conn__commodity1__commodity2.

Note that the ratio can also be defined for connection__node__node relationships where one or both of the nodes correspond to node groups in order to impose a ratio on aggregated connection flows.

+- · SpineOpt.jl
GitHub

The definition of the max_ratio_out_in_connection_flow parameter triggers the generation of the constraint_max_ratio_out_in_connection_flow and sets an upper bound on the ratio between outgoing and incoming flows of a connection. The parameter is defined on the relationship class connection__node__node, where the first node (or group of nodes) in this relationship represents the to_node, i.e. the outgoing flow from the connection, and the second node (or group of nodes), represents the from_node, i.e. the incoming flows to the connection. The ratio parameter is interpreted such that it constrains the ratio of out over in, where out is the connection_flow variable from the first node in the connection__node__node relationship in a left-to-right reading order.

To enforce e.g. a maximum ratio of 0.8 for a connection conn between its outgoing electricity flow to node commodity1 and its incoming flows from the node node commodity2, the max_ratio_out_in_connection_flow parameter would be set to 0.8 for the relationship conn__commodity1__commodity2.

Note that the ratio can also be defined for connection__node__node relationships where one or both of the nodes correspond to node groups in order to impose a ratio on aggregated connection flows.

diff --git a/dev/concept_reference/max_ratio_out_in_unit_flow/index.html b/dev/concept_reference/max_ratio_out_in_unit_flow/index.html index 8c80dd0f5a..f74932e250 100644 --- a/dev/concept_reference/max_ratio_out_in_unit_flow/index.html +++ b/dev/concept_reference/max_ratio_out_in_unit_flow/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

The definition of the max_ratio_out_in_unit_flow parameter triggers the generation of the constraint_max_ratio_out_in_unit_flow and enforces an upper bound on the ratio between outgoing and incoming flows of a unit. The parameter is defined on the relationship class unit__node__node, where the first node (or group of nodes) in this relationship represents the to_node, i.e. the outgoing flow from the unit, and the second node (or group of nodes), represents the from_node, i.e. the incoming flows to the unit. The ratio parameter is interpreted such that it constrains the ratio of out over in, where out is the unit_flow variable from the first node in the unit__node__node relationship in a left-to-right reading order.

To enforce e.g. a maximum ratio of 0.8 for a unit u between its outgoing flows to the node group el_heat (consisting of the two nodes el and heat) and its incoming gas flow from ng the max_ratio_out_in_unit_flow parameter would be set to 0.8 for the relationship u__el_heat__ng.

+- · SpineOpt.jl
GitHub

The definition of the max_ratio_out_in_unit_flow parameter triggers the generation of the constraint_max_ratio_out_in_unit_flow and enforces an upper bound on the ratio between outgoing and incoming flows of a unit. The parameter is defined on the relationship class unit__node__node, where the first node (or group of nodes) in this relationship represents the to_node, i.e. the outgoing flow from the unit, and the second node (or group of nodes), represents the from_node, i.e. the incoming flows to the unit. The ratio parameter is interpreted such that it constrains the ratio of out over in, where out is the unit_flow variable from the first node in the unit__node__node relationship in a left-to-right reading order.

To enforce e.g. a maximum ratio of 0.8 for a unit u between its outgoing flows to the node group el_heat (consisting of the two nodes el and heat) and its incoming gas flow from ng the max_ratio_out_in_unit_flow parameter would be set to 0.8 for the relationship u__el_heat__ng.

diff --git a/dev/concept_reference/max_ratio_out_out_unit_flow/index.html b/dev/concept_reference/max_ratio_out_out_unit_flow/index.html index 503a02c6c0..100a2a53f7 100644 --- a/dev/concept_reference/max_ratio_out_out_unit_flow/index.html +++ b/dev/concept_reference/max_ratio_out_out_unit_flow/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

The definition of the max_ratio_out_out_unit_flow parameter triggers the generation of the constraint_max_ratio_out_out_unit_flow and sets an upper bound on the ratio between outgoing flows of a unit. The parameter is defined on the relationship class unit__node__node, where the nodes (or group of nodes) in this relationship represent the to_node's', i.e. outgoing flow from the unit. The ratio parameter is interpreted such that it constrains the ratio of out1 over out2, where out1 is the unit_flow variable from the first node in the unit__node__node relationship in a left-to-right reading order.

To enforce a maximum ratio between two products of a unit u, e.g. setting the maximum share of produced electricity flowing to node el to 0.4 of the production of heat flowing to node heat, the fix_ratio_out_out_unit_flow parameter would be set to 0.4 for the relationship u__el__heat.

+- · SpineOpt.jl
GitHub

The definition of the max_ratio_out_out_unit_flow parameter triggers the generation of the constraint_max_ratio_out_out_unit_flow and sets an upper bound on the ratio between outgoing flows of a unit. The parameter is defined on the relationship class unit__node__node, where the nodes (or group of nodes) in this relationship represent the to_node's', i.e. outgoing flow from the unit. The ratio parameter is interpreted such that it constrains the ratio of out1 over out2, where out1 is the unit_flow variable from the first node in the unit__node__node relationship in a left-to-right reading order.

To enforce a maximum ratio between two products of a unit u, e.g. setting the maximum share of produced electricity flowing to node el to 0.4 of the production of heat flowing to node heat, the fix_ratio_out_out_unit_flow parameter would be set to 0.4 for the relationship u__el__heat.

diff --git a/dev/concept_reference/max_res_shutdown_ramp/index.html b/dev/concept_reference/max_res_shutdown_ramp/index.html index 011beaed2b..187de850e2 100644 --- a/dev/concept_reference/max_res_shutdown_ramp/index.html +++ b/dev/concept_reference/max_res_shutdown_ramp/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

A unit can provide spinning and nonspinning reserves to a reserve node. These reserves can be either upward_reserve or downward_reserve. Nonspinning downward reserves are provided to a downward_reserve node by contracted units holding available to shutdown. To include the provision of nonspinning downward reserves, the parameter max_res_shutdown_ramp needs to be defined on the corresponding unit__to_node relationship. This will trigger the generation of the variables nonspin_units_shut_down and nonspin_ramp_down_unit_flow and the constraint on maximum downward nonspinning reserve provision. Note that max_res_shutdown_ramp is given as a fraction of the unit_capacity.

A detailed description of the usage of ramps and reserves is given in the chapter Ramping and Reserves. The chapter Ramping and reserve constraints in the Mathematical Formulation presents the equations related to ramps and reserves.

+- · SpineOpt.jl
GitHub

A unit can provide spinning and nonspinning reserves to a reserve node. These reserves can be either upward_reserve or downward_reserve. Nonspinning downward reserves are provided to a downward_reserve node by contracted units holding available to shutdown. To include the provision of nonspinning downward reserves, the parameter max_res_shutdown_ramp needs to be defined on the corresponding unit__to_node relationship. This will trigger the generation of the variables nonspin_units_shut_down and nonspin_ramp_down_unit_flow and the constraint on maximum downward nonspinning reserve provision. Note that max_res_shutdown_ramp is given as a fraction of the unit_capacity.

A detailed description of the usage of ramps and reserves is given in the chapter Ramping and Reserves. The chapter Ramping and reserve constraints in the Mathematical Formulation presents the equations related to ramps and reserves.

diff --git a/dev/concept_reference/max_res_startup_ramp/index.html b/dev/concept_reference/max_res_startup_ramp/index.html index 68bb0a4600..4f33d59d06 100644 --- a/dev/concept_reference/max_res_startup_ramp/index.html +++ b/dev/concept_reference/max_res_startup_ramp/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

A unit can provide spinning and nonspinning reserves to a reserve node. These reserves can be either upward_reserve or downward_reserve. Nonspinning upward reserves are provided to a upward_reserve node by contracted offline units holding available to startup. To include the provision of nonspinning upward reserves, the parameter max_res_startup_ramp needs to be defined on the corresponding unit__to_node relationship. This will trigger the generation of the variables nonspin_units_started_up and nonspin_ramp_up_unit_flow and the constraint on maximum upward nonspinning reserve provision. Note that max_res_startup_ramp is given as a fraction of the unit_capacity.

A detailed description of the usage of ramps and reserves is given in the chapter Ramping and Reserves. The chapter Ramping and reserve constraints in the Mathematical Formulation presents the equations related to ramps and reserves.

+- · SpineOpt.jl
GitHub

A unit can provide spinning and nonspinning reserves to a reserve node. These reserves can be either upward_reserve or downward_reserve. Nonspinning upward reserves are provided to a upward_reserve node by contracted offline units holding available to startup. To include the provision of nonspinning upward reserves, the parameter max_res_startup_ramp needs to be defined on the corresponding unit__to_node relationship. This will trigger the generation of the variables nonspin_units_started_up and nonspin_ramp_up_unit_flow and the constraint on maximum upward nonspinning reserve provision. Note that max_res_startup_ramp is given as a fraction of the unit_capacity.

A detailed description of the usage of ramps and reserves is given in the chapter Ramping and Reserves. The chapter Ramping and reserve constraints in the Mathematical Formulation presents the equations related to ramps and reserves.

diff --git a/dev/concept_reference/max_shutdown_ramp/index.html b/dev/concept_reference/max_shutdown_ramp/index.html index c41823d87a..eb78787b23 100644 --- a/dev/concept_reference/max_shutdown_ramp/index.html +++ b/dev/concept_reference/max_shutdown_ramp/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

The definition of the max_shutdown_ramp parameter will trigger the creation of the constraint on maximum shutdown ramp. It sets an upper bound on the unit_flow variable for the timestep right before a shutdown.

It can be defined for unit__to_node or unit__from_node relationships, as well as their counterparts for node groups. It will then impose restrictions on the unit_flow variables that indicate flows between the two members of the relationship for which the parameter is defined. The parameter is given as a fraction of the unit_capacity parameter. When the parameter is not included, the aforementioned constraint will not be created, which is equivalent to choosing a value of 1.

+- · SpineOpt.jl
GitHub

The definition of the max_shutdown_ramp parameter will trigger the creation of the constraint on maximum shutdown ramp. It sets an upper bound on the unit_flow variable for the timestep right before a shutdown.

It can be defined for unit__to_node or unit__from_node relationships, as well as their counterparts for node groups. It will then impose restrictions on the unit_flow variables that indicate flows between the two members of the relationship for which the parameter is defined. The parameter is given as a fraction of the unit_capacity parameter. When the parameter is not included, the aforementioned constraint will not be created, which is equivalent to choosing a value of 1.

diff --git a/dev/concept_reference/max_startup_ramp/index.html b/dev/concept_reference/max_startup_ramp/index.html index e7fec1a53d..0cf91a4611 100644 --- a/dev/concept_reference/max_startup_ramp/index.html +++ b/dev/concept_reference/max_startup_ramp/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

The definition of the max_startup_ramp parameter will trigger the creation of the Constraint on upward start up ramp_up. It sets an upper bound on the unit_flow variable for the timestep right after a startup.

It can be defined for unit__to_node or unit__from_node relationships, as well as their counterparts for node groups. It will then impose restrictions on the unit_flow variables that indicate flows between the two members of the relationship for which the parameter is defined. The parameter is given as a fraction of the unit_capacity parameter. When the parameter is not included, the aforementioned constraint will not be created, which is equivalent to choosing a value of 1.

+- · SpineOpt.jl
GitHub

The definition of the max_startup_ramp parameter will trigger the creation of the Constraint on upward start up ramp_up. It sets an upper bound on the unit_flow variable for the timestep right after a startup.

It can be defined for unit__to_node or unit__from_node relationships, as well as their counterparts for node groups. It will then impose restrictions on the unit_flow variables that indicate flows between the two members of the relationship for which the parameter is defined. The parameter is given as a fraction of the unit_capacity parameter. When the parameter is not included, the aforementioned constraint will not be created, which is equivalent to choosing a value of 1.

diff --git a/dev/concept_reference/max_total_cumulated_unit_flow_from_node/index.html b/dev/concept_reference/max_total_cumulated_unit_flow_from_node/index.html index 4ae280dc81..c497f87472 100644 --- a/dev/concept_reference/max_total_cumulated_unit_flow_from_node/index.html +++ b/dev/concept_reference/max_total_cumulated_unit_flow_from_node/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

The definition of the max_total_cumulated_unit_flow_from_node parameter will trigger the creation of the constraint_total_cumulated_unit_flow. It sets an upper bound on the sum of the unit_flow variable for all timesteps.

It can be defined for the unit__from_node relationships, as well as their counterparts for node- and unit groups. It will then restrict the total accumulation of unit_flow variables to be below the given value. A possible use case is limiting the consumption of commodities such as oil or gas. The parameter is given as an absolute value thus has to be coherent with the units used for the unit flows.

+- · SpineOpt.jl
GitHub

The definition of the max_total_cumulated_unit_flow_from_node parameter will trigger the creation of the constraint_total_cumulated_unit_flow. It sets an upper bound on the sum of the unit_flow variable for all timesteps.

It can be defined for the unit__from_node relationships, as well as their counterparts for node- and unit groups. It will then restrict the total accumulation of unit_flow variables to be below the given value. A possible use case is limiting the consumption of commodities such as oil or gas. The parameter is given as an absolute value thus has to be coherent with the units used for the unit flows.

diff --git a/dev/concept_reference/max_total_cumulated_unit_flow_to_node/index.html b/dev/concept_reference/max_total_cumulated_unit_flow_to_node/index.html index 7f1692f158..e142611e1f 100644 --- a/dev/concept_reference/max_total_cumulated_unit_flow_to_node/index.html +++ b/dev/concept_reference/max_total_cumulated_unit_flow_to_node/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

The definition of the max_total_cumulated_unit_flow_to_node parameter will trigger the creation of the constraint_total_cumulated_unit_flow. It sets an upper bound on the sum of the unit_flow variable for all timesteps.

It can be defined for the unit__to_node relationships, as well as their counterparts for node- and unit groups. It will then restrict the total accumulation of unit_flow variables to be below the given value. A possible use case is the capping of CO2 emissions. The parameter is given as an absolute value thus has to be coherent with the units used for the unit flows.

+- · SpineOpt.jl
GitHub

The definition of the max_total_cumulated_unit_flow_to_node parameter will trigger the creation of the constraint_total_cumulated_unit_flow. It sets an upper bound on the sum of the unit_flow variable for all timesteps.

It can be defined for the unit__to_node relationships, as well as their counterparts for node- and unit groups. It will then restrict the total accumulation of unit_flow variables to be below the given value. A possible use case is the capping of CO2 emissions. The parameter is given as an absolute value thus has to be coherent with the units used for the unit flows.

diff --git a/dev/concept_reference/max_units_on_coefficient_in_in/index.html b/dev/concept_reference/max_units_on_coefficient_in_in/index.html index 64650d9a9b..ee533c3f5a 100644 --- a/dev/concept_reference/max_units_on_coefficient_in_in/index.html +++ b/dev/concept_reference/max_units_on_coefficient_in_in/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

The max_units_on_coefficient_in_in parameter is an optional coefficient in the unit input-input ratio constraint controlled by the max_ratio_in_in_unit_flow parameter. Essentially, it acts as a coefficient for the units_on variable in the constraint, allowing for making the maximum conversion ratio dependent on the amount of online capacity.

Note that there are different parameters depending on the directions of the unit_flow variables being constrained: max_units_on_coefficient_in_out, max_units_on_coefficient_out_in, and max_units_on_coefficient_out_out, all of which apply to their respective constraints. Similarly, there are different parameters for setting minimum or fixed conversion rates, e.g. min_units_on_coefficient_in_in and fix_units_on_coefficient_in_in.

+- · SpineOpt.jl
GitHub

The max_units_on_coefficient_in_in parameter is an optional coefficient in the unit input-input ratio constraint controlled by the max_ratio_in_in_unit_flow parameter. Essentially, it acts as a coefficient for the units_on variable in the constraint, allowing for making the maximum conversion ratio dependent on the amount of online capacity.

Note that there are different parameters depending on the directions of the unit_flow variables being constrained: max_units_on_coefficient_in_out, max_units_on_coefficient_out_in, and max_units_on_coefficient_out_out, all of which apply to their respective constraints. Similarly, there are different parameters for setting minimum or fixed conversion rates, e.g. min_units_on_coefficient_in_in and fix_units_on_coefficient_in_in.

diff --git a/dev/concept_reference/max_units_on_coefficient_in_out/index.html b/dev/concept_reference/max_units_on_coefficient_in_out/index.html index 4d86e2d34a..50ab8c6fcc 100644 --- a/dev/concept_reference/max_units_on_coefficient_in_out/index.html +++ b/dev/concept_reference/max_units_on_coefficient_in_out/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

The max_units_on_coefficient_in_out parameter is an optional coefficient in the unit input-output ratio constraint controlled by the max_ratio_in_out_unit_flow parameter. Essentially, it acts as a coefficient for the units_on variable in the constraint, allowing for making the maximum conversion ratio dependent on the amount of online capacity.

Note that there are different parameters depending on the directions of the unit_flow variables being constrained: max_units_on_coefficient_in_in, max_units_on_coefficient_out_in, and max_units_on_coefficient_out_out, all of which apply to their respective constraints. Similarly, there are different parameters for setting minimum or fixed conversion rates, e.g. min_units_on_coefficient_in_out and fix_units_on_coefficient_in_out.

+- · SpineOpt.jl
GitHub

The max_units_on_coefficient_in_out parameter is an optional coefficient in the unit input-output ratio constraint controlled by the max_ratio_in_out_unit_flow parameter. Essentially, it acts as a coefficient for the units_on variable in the constraint, allowing for making the maximum conversion ratio dependent on the amount of online capacity.

Note that there are different parameters depending on the directions of the unit_flow variables being constrained: max_units_on_coefficient_in_in, max_units_on_coefficient_out_in, and max_units_on_coefficient_out_out, all of which apply to their respective constraints. Similarly, there are different parameters for setting minimum or fixed conversion rates, e.g. min_units_on_coefficient_in_out and fix_units_on_coefficient_in_out.

diff --git a/dev/concept_reference/max_units_on_coefficient_out_in/index.html b/dev/concept_reference/max_units_on_coefficient_out_in/index.html index 659e50c26c..62b16d951b 100644 --- a/dev/concept_reference/max_units_on_coefficient_out_in/index.html +++ b/dev/concept_reference/max_units_on_coefficient_out_in/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

The max_units_on_coefficient_out_in parameter is an optional coefficient in the unit output-input ratio constraint controlled by the max_ratio_out_in_unit_flow parameter. Essentially, it acts as a coefficient for the units_on in the constraint, allowing for making the maximum conversion ratio dependent on the amount of online capacity.

Note that there are different parameters depending on the directions of the unit_flow being constrained: max_units_on_coefficient_in_in, max_units_on_coefficient_in_out, and max_units_on_coefficient_out_out, all of which apply to their respective constraints. Similarly, there are different parameters for setting minimum or fixed conversion rates, e.g. min_units_on_coefficient_out_in and fix_units_on_coefficient_out_in.

+- · SpineOpt.jl
GitHub

The max_units_on_coefficient_out_in parameter is an optional coefficient in the unit output-input ratio constraint controlled by the max_ratio_out_in_unit_flow parameter. Essentially, it acts as a coefficient for the units_on in the constraint, allowing for making the maximum conversion ratio dependent on the amount of online capacity.

Note that there are different parameters depending on the directions of the unit_flow being constrained: max_units_on_coefficient_in_in, max_units_on_coefficient_in_out, and max_units_on_coefficient_out_out, all of which apply to their respective constraints. Similarly, there are different parameters for setting minimum or fixed conversion rates, e.g. min_units_on_coefficient_out_in and fix_units_on_coefficient_out_in.

diff --git a/dev/concept_reference/max_units_on_coefficient_out_out/index.html b/dev/concept_reference/max_units_on_coefficient_out_out/index.html index e784a8d524..53a62e35a9 100644 --- a/dev/concept_reference/max_units_on_coefficient_out_out/index.html +++ b/dev/concept_reference/max_units_on_coefficient_out_out/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

The max_units_on_coefficient_out_out parameter is an optional coefficient in the unit output-output ratio constraint controlled by the max_ratio_out_out_unit_flow parameter. Essentially, it acts as a coefficient for the units_on variable in the constraint, allowing for making the maximum conversion ratio dependent on the amount of online capacity.

Note that there are different parameters depending on the directions of the unit_flow variables being constrained: max_units_on_coefficient_in_in, max_units_on_coefficient_out_in, and max_units_on_coefficient_in_out, all of which apply to their respective constraints. Similarly, there are different parameters for setting minimum or fixed conversion rates, e.g. min_units_on_coefficient_out_out and fix_units_on_coefficient_out_out.

+- · SpineOpt.jl
GitHub

The max_units_on_coefficient_out_out parameter is an optional coefficient in the unit output-output ratio constraint controlled by the max_ratio_out_out_unit_flow parameter. Essentially, it acts as a coefficient for the units_on variable in the constraint, allowing for making the maximum conversion ratio dependent on the amount of online capacity.

Note that there are different parameters depending on the directions of the unit_flow variables being constrained: max_units_on_coefficient_in_in, max_units_on_coefficient_out_in, and max_units_on_coefficient_in_out, all of which apply to their respective constraints. Similarly, there are different parameters for setting minimum or fixed conversion rates, e.g. min_units_on_coefficient_out_out and fix_units_on_coefficient_out_out.

diff --git a/dev/concept_reference/max_voltage_angle/index.html b/dev/concept_reference/max_voltage_angle/index.html index 9eefe2fe27..9b620895d2 100644 --- a/dev/concept_reference/max_voltage_angle/index.html +++ b/dev/concept_reference/max_voltage_angle/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub
+- · SpineOpt.jl
GitHub
diff --git a/dev/concept_reference/mga_diff_relative/index.html b/dev/concept_reference/mga_diff_relative/index.html index 27f1e33b5f..7b72914984 100644 --- a/dev/concept_reference/mga_diff_relative/index.html +++ b/dev/concept_reference/mga_diff_relative/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

Currently, the MGA algorithm (see mga-advanced) only supports absolute differences between MGA variables (e.g. absolute differences between units_invested_available etc.). Hence, the default for this parameter is false and should not be changed for now.

+- · SpineOpt.jl
GitHub

Currently, the MGA algorithm (see mga-advanced) only supports absolute differences between MGA variables (e.g. absolute differences between units_invested_available etc.). Hence, the default for this parameter is false and should not be changed for now.

diff --git a/dev/concept_reference/min_down_time/index.html b/dev/concept_reference/min_down_time/index.html index d996a45f8f..238cadc463 100644 --- a/dev/concept_reference/min_down_time/index.html +++ b/dev/concept_reference/min_down_time/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

The definition of the min_down_time parameter will trigger the creation of the Constraint on minimum down time. It sets a lower bound on the period that a unit has to stay offline after a shutdown.

It can be defined for a unit and will then impose restrictions on the units_on variables that represent the on- or offline status of the unit. The parameter is given as a duration value. When the parameter is not included, the aforementioned constraint will not be created, which is equivalent to choosing a value of 0.

For a more complete description of unit commmitment restrictions, see Unit commitment.

+- · SpineOpt.jl
GitHub

The definition of the min_down_time parameter will trigger the creation of the Constraint on minimum down time. It sets a lower bound on the period that a unit has to stay offline after a shutdown.

It can be defined for a unit and will then impose restrictions on the units_on variables that represent the on- or offline status of the unit. The parameter is given as a duration value. When the parameter is not included, the aforementioned constraint will not be created, which is equivalent to choosing a value of 0.

For a more complete description of unit commmitment restrictions, see Unit commitment.

diff --git a/dev/concept_reference/min_node_pressure/index.html b/dev/concept_reference/min_node_pressure/index.html index 6c40c2c5bb..11865aa323 100644 --- a/dev/concept_reference/min_node_pressure/index.html +++ b/dev/concept_reference/min_node_pressure/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub
+- · SpineOpt.jl
GitHub
diff --git a/dev/concept_reference/min_ratio_in_in_unit_flow/index.html b/dev/concept_reference/min_ratio_in_in_unit_flow/index.html index e27b6c7cdd..6b00121466 100644 --- a/dev/concept_reference/min_ratio_in_in_unit_flow/index.html +++ b/dev/concept_reference/min_ratio_in_in_unit_flow/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

The definition of the min_ratio_in_in_unit_flow parameter triggers the generation of the constraint_min_ratio_in_in_unit_flow and sets a lower bound for the ratio between incoming flows of a unit. The parameter is defined on the relationship class unit__node__node, where both nodes (or group of nodes) in this relationship represent from_nodes, i.e. the incoming flows to the unit. The ratio parameter is interpreted such that it constrains the ratio of in1 over in2, where in1 is the unit_flow variable from the first node in the unit__node__node relationship in a left-to-right reading order. This parameter can be useful, for instance if a unit requires a specific commodity mix as a fuel supply.

To enforce e.g. for a unit u a minimum share of 0.2 of its incoming flow from the node supply_fuel_1 compared to its incoming flow from the node group supply_fuel_2 (consisting of the two nodes supply_fuel_2_component_a and supply_fuel_2_component_b) the min_ratio_in_in_unit_flow parameter would be set to 0.2 for the relationship u__supply_fuel_1__supply_fuel_2.

+- · SpineOpt.jl
GitHub

The definition of the min_ratio_in_in_unit_flow parameter triggers the generation of the constraint_min_ratio_in_in_unit_flow and sets a lower bound for the ratio between incoming flows of a unit. The parameter is defined on the relationship class unit__node__node, where both nodes (or group of nodes) in this relationship represent from_nodes, i.e. the incoming flows to the unit. The ratio parameter is interpreted such that it constrains the ratio of in1 over in2, where in1 is the unit_flow variable from the first node in the unit__node__node relationship in a left-to-right reading order. This parameter can be useful, for instance if a unit requires a specific commodity mix as a fuel supply.

To enforce e.g. for a unit u a minimum share of 0.2 of its incoming flow from the node supply_fuel_1 compared to its incoming flow from the node group supply_fuel_2 (consisting of the two nodes supply_fuel_2_component_a and supply_fuel_2_component_b) the min_ratio_in_in_unit_flow parameter would be set to 0.2 for the relationship u__supply_fuel_1__supply_fuel_2.

diff --git a/dev/concept_reference/min_ratio_in_out_unit_flow/index.html b/dev/concept_reference/min_ratio_in_out_unit_flow/index.html index dad177472a..d271cd986f 100644 --- a/dev/concept_reference/min_ratio_in_out_unit_flow/index.html +++ b/dev/concept_reference/min_ratio_in_out_unit_flow/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

The definition of the min_ratio_in_out_unit_flow parameter triggers the generation of the constraint_min_ratio_in_out_unit_flow and enforces a lower bound on the ratio between incoming and outgoing flows of a unit. The parameter is defined on the relationship class unit__node__node, where the first node (or group of nodes, see) in this relationship represents the from_node, i.e. the incoming flow to the unit, and the second node (or group of nodes) represents the to_node i.e. the outgoing flow from the unit. The ratio parameter is interpreted such that it constrains the ratio of in over out, where in is the unit_flow variable from the first node in the unit__node__node relationship in a left-to-right reading order.

To enforce e.g. a minimum ratio of 1.4 for a unit u between its incoming gas flow from the node ng and its outgoing flow to the node group el_heat (consisting of the two nodes el and heat), the fix_ratio_in_out_unit_flow parameter would be set to 1.4 for the relationship u__ng__el_heat.

+- · SpineOpt.jl
GitHub

The definition of the min_ratio_in_out_unit_flow parameter triggers the generation of the constraint_min_ratio_in_out_unit_flow and enforces a lower bound on the ratio between incoming and outgoing flows of a unit. The parameter is defined on the relationship class unit__node__node, where the first node (or group of nodes, see) in this relationship represents the from_node, i.e. the incoming flow to the unit, and the second node (or group of nodes) represents the to_node i.e. the outgoing flow from the unit. The ratio parameter is interpreted such that it constrains the ratio of in over out, where in is the unit_flow variable from the first node in the unit__node__node relationship in a left-to-right reading order.

To enforce e.g. a minimum ratio of 1.4 for a unit u between its incoming gas flow from the node ng and its outgoing flow to the node group el_heat (consisting of the two nodes el and heat), the fix_ratio_in_out_unit_flow parameter would be set to 1.4 for the relationship u__ng__el_heat.

diff --git a/dev/concept_reference/min_ratio_out_in_connection_flow/index.html b/dev/concept_reference/min_ratio_out_in_connection_flow/index.html index cbffe1edc6..767178bbf5 100644 --- a/dev/concept_reference/min_ratio_out_in_connection_flow/index.html +++ b/dev/concept_reference/min_ratio_out_in_connection_flow/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

The definition of the min_ratio_out_in_connection_flow parameter triggers the generation of the constraint_min_ratio_out_in_connection_flow and sets a lower bound on the ratio between outgoing and incoming flows of a connection. The parameter is defined on the relationship class connection__node__node, where the first node (or group of nodes) in this relationship represents the to_node, i.e. the outgoing flow from the connection, and the second node (or group of nodes), represents the from_node, i.e. the incoming flows to the connection. The ratio parameter is interpreted such that it constrains the ratio of out over in, where out is the connection_flow variable from the first node in the connection__node__node relationship in a left-to-right reading order.

Note that the ratio can also be defined for connection__node__node relationships, where one or both of the nodes correspond to node groups in order to impose a ratio on aggregated connection flows.

To enforce e.g. a minimum ratio of 0.2 for a connection conn between its outgoing electricity flow to node commodity1 and its incoming flows from the node node commodity2, the min_ratio_out_in_connection_flow parameter would be set to 0.8 for the relationship conn__commodity1__commodity2.

+- · SpineOpt.jl
GitHub

The definition of the min_ratio_out_in_connection_flow parameter triggers the generation of the constraint_min_ratio_out_in_connection_flow and sets a lower bound on the ratio between outgoing and incoming flows of a connection. The parameter is defined on the relationship class connection__node__node, where the first node (or group of nodes) in this relationship represents the to_node, i.e. the outgoing flow from the connection, and the second node (or group of nodes), represents the from_node, i.e. the incoming flows to the connection. The ratio parameter is interpreted such that it constrains the ratio of out over in, where out is the connection_flow variable from the first node in the connection__node__node relationship in a left-to-right reading order.

Note that the ratio can also be defined for connection__node__node relationships, where one or both of the nodes correspond to node groups in order to impose a ratio on aggregated connection flows.

To enforce e.g. a minimum ratio of 0.2 for a connection conn between its outgoing electricity flow to node commodity1 and its incoming flows from the node node commodity2, the min_ratio_out_in_connection_flow parameter would be set to 0.8 for the relationship conn__commodity1__commodity2.

diff --git a/dev/concept_reference/min_ratio_out_in_unit_flow/index.html b/dev/concept_reference/min_ratio_out_in_unit_flow/index.html index 7e80918b83..16a6a35e86 100644 --- a/dev/concept_reference/min_ratio_out_in_unit_flow/index.html +++ b/dev/concept_reference/min_ratio_out_in_unit_flow/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

The definition of the [min_ratio_out_in_unit_flow] parameter triggers the generation of the constraint_min_ratio_out_in_unit_flow and corresponds to a lower bound of the ratio between out and incoming flows of a unit. The parameter is defined on the relationship class unit__node__node, where the first node (or group of nodes) in this relationship represents the to_node, i.e. the outgoing flow from the unit, and the second node (or group of nodes), represents the from_node, i.e. the incoming flows to the unit. The ratio parameter is interpreted such that it constrains the ratio of out over in, where out is the unit_flow variable from the first node in the unit__node__node relationship in a left-to-right reading order.

To enforce e.g. a minimum ratio of 0.8 for a unit u between its outgoing flows to the node group el_heat (consisting of the two nodes el and heat) and its incoming gas flow from ng the min_ratio_out_in_unit_flow parameter would be set to 0.8 for the relationship u__el_heat__ng.

+- · SpineOpt.jl
GitHub

The definition of the [min_ratio_out_in_unit_flow] parameter triggers the generation of the constraint_min_ratio_out_in_unit_flow and corresponds to a lower bound of the ratio between out and incoming flows of a unit. The parameter is defined on the relationship class unit__node__node, where the first node (or group of nodes) in this relationship represents the to_node, i.e. the outgoing flow from the unit, and the second node (or group of nodes), represents the from_node, i.e. the incoming flows to the unit. The ratio parameter is interpreted such that it constrains the ratio of out over in, where out is the unit_flow variable from the first node in the unit__node__node relationship in a left-to-right reading order.

To enforce e.g. a minimum ratio of 0.8 for a unit u between its outgoing flows to the node group el_heat (consisting of the two nodes el and heat) and its incoming gas flow from ng the min_ratio_out_in_unit_flow parameter would be set to 0.8 for the relationship u__el_heat__ng.

diff --git a/dev/concept_reference/min_ratio_out_out_unit_flow/index.html b/dev/concept_reference/min_ratio_out_out_unit_flow/index.html index 3d9fc8f0ea..b3385d3bd6 100644 --- a/dev/concept_reference/min_ratio_out_out_unit_flow/index.html +++ b/dev/concept_reference/min_ratio_out_out_unit_flow/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

The definition of the min_ratio_out_out_unit_flow parameter triggers the generation of the constraint_min_ratio_out_out_unit_flow and enforces a lower bound on the ratio between outgoing flows of a unit. The parameter is defined on the relationship class unit__node__node, where the nodes (or group of nodes) in this relationship represent the to_node's', i.e. outgoing flow from the unit. The ratio parameter is interpreted such that it constrains the ratio of out1 over out2, where out1 is the unit_flow variable from the first node in the unit__node__node relationship in a left-to-right reading order.

To enforce a minimum ratio between two products of a unit u, e.g. setting the minimum share of produced electricity flowing to node el to 0.4 of the production of heat flowing to node heat, the fix_ratio_out_out_unit_flow parameter would be set to 0.4 for the relationship u__el__heat.

+- · SpineOpt.jl
GitHub

The definition of the min_ratio_out_out_unit_flow parameter triggers the generation of the constraint_min_ratio_out_out_unit_flow and enforces a lower bound on the ratio between outgoing flows of a unit. The parameter is defined on the relationship class unit__node__node, where the nodes (or group of nodes) in this relationship represent the to_node's', i.e. outgoing flow from the unit. The ratio parameter is interpreted such that it constrains the ratio of out1 over out2, where out1 is the unit_flow variable from the first node in the unit__node__node relationship in a left-to-right reading order.

To enforce a minimum ratio between two products of a unit u, e.g. setting the minimum share of produced electricity flowing to node el to 0.4 of the production of heat flowing to node heat, the fix_ratio_out_out_unit_flow parameter would be set to 0.4 for the relationship u__el__heat.

diff --git a/dev/concept_reference/min_res_shutdown_ramp/index.html b/dev/concept_reference/min_res_shutdown_ramp/index.html index 5d0eb9002f..fcc25bc4c7 100644 --- a/dev/concept_reference/min_res_shutdown_ramp/index.html +++ b/dev/concept_reference/min_res_shutdown_ramp/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

A unit can provide spinning and nonspinning reserves to a reserve node. These reserves can be either upward_reserve or downward_reserve. Nonspinning downward reserves are provided by contracted units holding available to shutdown to a downward_reserve node. If a unit is scheduled to provide nonspinning reserve, a limit on the minimum amount of reserves provided can be imposed by defining the parameter min_res_shutdown_ramp on a unit__to_node relationship, which triggers the constraint on minimum downward nonspinning reserve provision. The parameter min_res_shutdown_ramp is given as a fraction of the unit_capacity of the corresponding unit__to_node relationship.

Note that to include the provision of nonspinning downward reserves, the parameter max_res_shutdown_ramp needs to be defined on the corresponding unit__to_node relationship, which triggers the generation of the variables nonspin_units_shut_down and nonspin_ramp_down_unit_flow.

A detailed description of the usage of ramps and reserves is given in the chapter Ramping and Reserves. The chapter Ramping and reserve constraints in the Mathematical Formulation presents the equations related to ramps and reserves.

+- · SpineOpt.jl
GitHub

A unit can provide spinning and nonspinning reserves to a reserve node. These reserves can be either upward_reserve or downward_reserve. Nonspinning downward reserves are provided by contracted units holding available to shutdown to a downward_reserve node. If a unit is scheduled to provide nonspinning reserve, a limit on the minimum amount of reserves provided can be imposed by defining the parameter min_res_shutdown_ramp on a unit__to_node relationship, which triggers the constraint on minimum downward nonspinning reserve provision. The parameter min_res_shutdown_ramp is given as a fraction of the unit_capacity of the corresponding unit__to_node relationship.

Note that to include the provision of nonspinning downward reserves, the parameter max_res_shutdown_ramp needs to be defined on the corresponding unit__to_node relationship, which triggers the generation of the variables nonspin_units_shut_down and nonspin_ramp_down_unit_flow.

A detailed description of the usage of ramps and reserves is given in the chapter Ramping and Reserves. The chapter Ramping and reserve constraints in the Mathematical Formulation presents the equations related to ramps and reserves.

diff --git a/dev/concept_reference/min_res_startup_ramp/index.html b/dev/concept_reference/min_res_startup_ramp/index.html index 90e5f196ba..1cc2bcde48 100644 --- a/dev/concept_reference/min_res_startup_ramp/index.html +++ b/dev/concept_reference/min_res_startup_ramp/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

A unit can provide spinning and nonspinning reserves to a reserve node. These reserves can be either upward_reserve or downward_reserve. Nonspinning upward reserves are provided to an upward_reserve node by contracted offline units holding available to startup. If a unit is scheduled to provide nonspinning reserve, a limit on the minimum amount of reserves provided can be imposed by defining the parameter min_res_startup_ramp on a unit__to_node relationship, which triggers the constraint on minimum upward nonspinning reserve provision. The parameter min_res_startup_ramp is given as a fraction of the unit_capacity of the corresponding unit__to_node relationship.

Note that to include the provision of nonspinning upward reserves, the parameter max_res_startup_ramp needs to be defined on the corresponding unit__to_node relationship, which triggers the generation of the variables nonspin_units_started_up and nonspin_ramp_up_unit_flow.

A detailed description of the usage of ramps and reserves is given in the chapter Ramping and Reserves. The chapter Ramping and reserve constraints in the Mathematical Formulation presents the equations related to ramps and reserves.

+- · SpineOpt.jl
GitHub

A unit can provide spinning and nonspinning reserves to a reserve node. These reserves can be either upward_reserve or downward_reserve. Nonspinning upward reserves are provided to an upward_reserve node by contracted offline units holding available to startup. If a unit is scheduled to provide nonspinning reserve, a limit on the minimum amount of reserves provided can be imposed by defining the parameter min_res_startup_ramp on a unit__to_node relationship, which triggers the constraint on minimum upward nonspinning reserve provision. The parameter min_res_startup_ramp is given as a fraction of the unit_capacity of the corresponding unit__to_node relationship.

Note that to include the provision of nonspinning upward reserves, the parameter max_res_startup_ramp needs to be defined on the corresponding unit__to_node relationship, which triggers the generation of the variables nonspin_units_started_up and nonspin_ramp_up_unit_flow.

A detailed description of the usage of ramps and reserves is given in the chapter Ramping and Reserves. The chapter Ramping and reserve constraints in the Mathematical Formulation presents the equations related to ramps and reserves.

diff --git a/dev/concept_reference/min_shutdown_ramp/index.html b/dev/concept_reference/min_shutdown_ramp/index.html index 7a9fd13b98..e81d8b82cd 100644 --- a/dev/concept_reference/min_shutdown_ramp/index.html +++ b/dev/concept_reference/min_shutdown_ramp/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

The definition of the min_shutdown_ramp parameter will trigger the creation of the constraint on minimum shutdown ramp. It sets a lower bound on the unit_flow variable for the timestep right before a shutdown.

It can be defined for unit__to_node or unit__from_node relationships, as well as their counterparts for node groups. It will then impose restrictions on the unit_flow variables that indicate flows between the two members of the relationship for which the parameter is defined. The parameter is given as a fraction of the unit_capacity parameter. When the parameter is not included, the aforementioned constraint will not be created, which is equivalent to choosing a value of 0.

+- · SpineOpt.jl
GitHub

The definition of the min_shutdown_ramp parameter will trigger the creation of the constraint on minimum shutdown ramp. It sets a lower bound on the unit_flow variable for the timestep right before a shutdown.

It can be defined for unit__to_node or unit__from_node relationships, as well as their counterparts for node groups. It will then impose restrictions on the unit_flow variables that indicate flows between the two members of the relationship for which the parameter is defined. The parameter is given as a fraction of the unit_capacity parameter. When the parameter is not included, the aforementioned constraint will not be created, which is equivalent to choosing a value of 0.

diff --git a/dev/concept_reference/min_startup_ramp/index.html b/dev/concept_reference/min_startup_ramp/index.html index 471fd938d9..0216a0506a 100644 --- a/dev/concept_reference/min_startup_ramp/index.html +++ b/dev/concept_reference/min_startup_ramp/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

The definition of the min_startup_ramp parameter will trigger the creation of the constraint on minimum startup ramp. It sets a lower bound on the unit_flow variable for the timestep right after a startup.

It can be defined for unit__to_node or unit__from_node relationships, as well as their counterparts for node groups. It will then impose restrictions on the unit_flow variables that indicate flows between the two members of the relationship for which the parameter is defined. The parameter is given as a fraction of the unit_capacity parameter. When the parameter is not included, the aforementioned constraint will not be created, which is equivalent to choosing a value of 0.

+- · SpineOpt.jl
GitHub

The definition of the min_startup_ramp parameter will trigger the creation of the constraint on minimum startup ramp. It sets a lower bound on the unit_flow variable for the timestep right after a startup.

It can be defined for unit__to_node or unit__from_node relationships, as well as their counterparts for node groups. It will then impose restrictions on the unit_flow variables that indicate flows between the two members of the relationship for which the parameter is defined. The parameter is given as a fraction of the unit_capacity parameter. When the parameter is not included, the aforementioned constraint will not be created, which is equivalent to choosing a value of 0.

diff --git a/dev/concept_reference/min_total_cumulated_unit_flow_from_node/index.html b/dev/concept_reference/min_total_cumulated_unit_flow_from_node/index.html index f48e7d7048..3d39b2a0ae 100644 --- a/dev/concept_reference/min_total_cumulated_unit_flow_from_node/index.html +++ b/dev/concept_reference/min_total_cumulated_unit_flow_from_node/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

The definition of the min_total_cumulated_unit_flow_from_node parameter will trigger the creation of the constraint_total_cumulated_unit_flow. It sets a lower bound on the sum of the unit_flow variable for all timesteps.

It can be defined for the unit__from_node relationships, as well as their counterparts for node- and unit groups. It will then restrict the total accumulation of unit_flow variables to be above the given value. The parameter is given as an absolute value thus has to be coherent with the units used for the unit flows.

+- · SpineOpt.jl
GitHub

The definition of the min_total_cumulated_unit_flow_from_node parameter will trigger the creation of the constraint_total_cumulated_unit_flow. It sets a lower bound on the sum of the unit_flow variable for all timesteps.

It can be defined for the unit__from_node relationships, as well as their counterparts for node- and unit groups. It will then restrict the total accumulation of unit_flow variables to be above the given value. The parameter is given as an absolute value thus has to be coherent with the units used for the unit flows.

diff --git a/dev/concept_reference/min_total_cumulated_unit_flow_to_node/index.html b/dev/concept_reference/min_total_cumulated_unit_flow_to_node/index.html index ee9eff0370..19b458182c 100644 --- a/dev/concept_reference/min_total_cumulated_unit_flow_to_node/index.html +++ b/dev/concept_reference/min_total_cumulated_unit_flow_to_node/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

The definition of the min_total_cumulated_unit_flow_to_node parameter will trigger the creation of the constraint_total_cumulated_unit_flow. It sets a lower bound on the sum of the unit_flow variable for all timesteps.

It can be defined for the unit__to_node relationships, as well as their counterparts for node- and unit groups. It will then restrict the total accumulation of unit_flow variables to be above the given value. A possible use case is a minimum value for electricity generated from renewable sources. The parameter is given as an absolute value thus has to be coherent with the units used for the unit flows.

+- · SpineOpt.jl
GitHub

The definition of the min_total_cumulated_unit_flow_to_node parameter will trigger the creation of the constraint_total_cumulated_unit_flow. It sets a lower bound on the sum of the unit_flow variable for all timesteps.

It can be defined for the unit__to_node relationships, as well as their counterparts for node- and unit groups. It will then restrict the total accumulation of unit_flow variables to be above the given value. A possible use case is a minimum value for electricity generated from renewable sources. The parameter is given as an absolute value thus has to be coherent with the units used for the unit flows.

diff --git a/dev/concept_reference/min_units_on_coefficient_in_in/index.html b/dev/concept_reference/min_units_on_coefficient_in_in/index.html index ef3da74225..cfdf11e84e 100644 --- a/dev/concept_reference/min_units_on_coefficient_in_in/index.html +++ b/dev/concept_reference/min_units_on_coefficient_in_in/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

The min_units_on_coefficient_in_in parameter is an optional coefficient in the unit input-input ratio constraint controlled by the min_ratio_in_in_unit_flow parameter. Essentially, it acts as a coefficient for the units_on variable in the constraint, allowing for making the minimum conversion ratio dependent on the amount of online capacity.

Note that there are different parameters depending on the directions of the unit_flow variables being constrained: min_units_on_coefficient_in_out, min_units_on_coefficient_out_in, and min_units_on_coefficient_out_out, all of which apply to their respective constraints. Similarly, there are different parameters for setting maximum or fixed conversion rates, e.g. max_units_on_coefficient_in_in and fix_units_on_coefficient_in_in.

+- · SpineOpt.jl
GitHub

The min_units_on_coefficient_in_in parameter is an optional coefficient in the unit input-input ratio constraint controlled by the min_ratio_in_in_unit_flow parameter. Essentially, it acts as a coefficient for the units_on variable in the constraint, allowing for making the minimum conversion ratio dependent on the amount of online capacity.

Note that there are different parameters depending on the directions of the unit_flow variables being constrained: min_units_on_coefficient_in_out, min_units_on_coefficient_out_in, and min_units_on_coefficient_out_out, all of which apply to their respective constraints. Similarly, there are different parameters for setting maximum or fixed conversion rates, e.g. max_units_on_coefficient_in_in and fix_units_on_coefficient_in_in.

diff --git a/dev/concept_reference/min_units_on_coefficient_in_out/index.html b/dev/concept_reference/min_units_on_coefficient_in_out/index.html index cf71c8494c..4e844b4ac5 100644 --- a/dev/concept_reference/min_units_on_coefficient_in_out/index.html +++ b/dev/concept_reference/min_units_on_coefficient_in_out/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

The min_units_on_coefficient_in_out parameter is an optional coefficient in the unit input-output ratio constraint controlled by the min_ratio_in_out_unit_flow parameter. Essentially, it acts as a coefficient for the units_on variable in the constraint, allowing for making the minimum conversion ratio dependent on the amount of online capacity.

Note that there are different parameters depending on the directions of the unit_flow variables being constrained: min_units_on_coefficient_in_in, min_units_on_coefficient_out_in, and min_units_on_coefficient_out_out, all of which apply to their respective constraints. Similarly, there are different parameters for setting maximum or fixed conversion rates, e.g. max_units_on_coefficient_in_out and fix_units_on_coefficient_in_out.

+- · SpineOpt.jl
GitHub

The min_units_on_coefficient_in_out parameter is an optional coefficient in the unit input-output ratio constraint controlled by the min_ratio_in_out_unit_flow parameter. Essentially, it acts as a coefficient for the units_on variable in the constraint, allowing for making the minimum conversion ratio dependent on the amount of online capacity.

Note that there are different parameters depending on the directions of the unit_flow variables being constrained: min_units_on_coefficient_in_in, min_units_on_coefficient_out_in, and min_units_on_coefficient_out_out, all of which apply to their respective constraints. Similarly, there are different parameters for setting maximum or fixed conversion rates, e.g. max_units_on_coefficient_in_out and fix_units_on_coefficient_in_out.

diff --git a/dev/concept_reference/min_units_on_coefficient_out_in/index.html b/dev/concept_reference/min_units_on_coefficient_out_in/index.html index f7ffea3103..64f5f5e62c 100644 --- a/dev/concept_reference/min_units_on_coefficient_out_in/index.html +++ b/dev/concept_reference/min_units_on_coefficient_out_in/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

The min_units_on_coefficient_out_in parameter is an optional coefficient in the unit output-input ratio constraint controlled by the min_ratio_out_in_unit_flow parameter. Essentially, it acts as a coefficient for the units_on variable in the constraint, allowing for making the minimum conversion ratio dependent on the amount of online capacity.

Note that there are different parameters depending on the directions of the unit_flow variables being constrained: min_units_on_coefficient_in_in, min_units_on_coefficient_in_out, and min_units_on_coefficient_out_out, all of which apply to their respective constraints. Similarly, there are different parameters for setting maximum or fixed conversion rates, e.g. max_units_on_coefficient_out_in and fix_units_on_coefficient_out_in.

+- · SpineOpt.jl
GitHub

The min_units_on_coefficient_out_in parameter is an optional coefficient in the unit output-input ratio constraint controlled by the min_ratio_out_in_unit_flow parameter. Essentially, it acts as a coefficient for the units_on variable in the constraint, allowing for making the minimum conversion ratio dependent on the amount of online capacity.

Note that there are different parameters depending on the directions of the unit_flow variables being constrained: min_units_on_coefficient_in_in, min_units_on_coefficient_in_out, and min_units_on_coefficient_out_out, all of which apply to their respective constraints. Similarly, there are different parameters for setting maximum or fixed conversion rates, e.g. max_units_on_coefficient_out_in and fix_units_on_coefficient_out_in.

diff --git a/dev/concept_reference/min_units_on_coefficient_out_out/index.html b/dev/concept_reference/min_units_on_coefficient_out_out/index.html index e1eb36fdec..34756e378c 100644 --- a/dev/concept_reference/min_units_on_coefficient_out_out/index.html +++ b/dev/concept_reference/min_units_on_coefficient_out_out/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

The min_units_on_coefficient_out_out parameter is an optional coefficient in the unit output-output ratio constraint controlled by the min_ratio_out_out_unit_flow parameter. Essentially, it acts as a coefficient for the units_on variable in the constraint, allowing for making the minimum conversion ratio dependent on the amount of online capacity.

Note that there are different parameters depending on the directions of the unit_flow variables being constrained: min_units_on_coefficient_in_in, min_units_on_coefficient_in_out, and min_units_on_coefficient_out_in, all of which apply to their respective constraints. Similarly, there are different parameters for setting maximum or fixed conversion rates, e.g. max_units_on_coefficient_out_out and fix_units_on_coefficient_out_out.

+- · SpineOpt.jl
GitHub

The min_units_on_coefficient_out_out parameter is an optional coefficient in the unit output-output ratio constraint controlled by the min_ratio_out_out_unit_flow parameter. Essentially, it acts as a coefficient for the units_on variable in the constraint, allowing for making the minimum conversion ratio dependent on the amount of online capacity.

Note that there are different parameters depending on the directions of the unit_flow variables being constrained: min_units_on_coefficient_in_in, min_units_on_coefficient_in_out, and min_units_on_coefficient_out_in, all of which apply to their respective constraints. Similarly, there are different parameters for setting maximum or fixed conversion rates, e.g. max_units_on_coefficient_out_out and fix_units_on_coefficient_out_out.

diff --git a/dev/concept_reference/min_up_time/index.html b/dev/concept_reference/min_up_time/index.html index 4b02408e82..34acd4298d 100644 --- a/dev/concept_reference/min_up_time/index.html +++ b/dev/concept_reference/min_up_time/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

The definition of the min_up_time parameter will trigger the creation of the Constraint on minimum up time. It sets a lower bound on the period that a unit has to stay online after a startup.

It can be defined for a unit and will then impose restrictions on the units_on variables that represent the on- or offline status of the unit. The parameter is given as a duration value. When the parameter is not included, the aforementioned constraint will not be created, which is equivalent to choosing a value of 0.

For a more complete description of unit commmitment restrictions, see Unit commitment.

+- · SpineOpt.jl
GitHub

The definition of the min_up_time parameter will trigger the creation of the Constraint on minimum up time. It sets a lower bound on the period that a unit has to stay online after a startup.

It can be defined for a unit and will then impose restrictions on the units_on variables that represent the on- or offline status of the unit. The parameter is given as a duration value. When the parameter is not included, the aforementioned constraint will not be created, which is equivalent to choosing a value of 0.

For a more complete description of unit commmitment restrictions, see Unit commitment.

diff --git a/dev/concept_reference/min_voltage_angle/index.html b/dev/concept_reference/min_voltage_angle/index.html index 933ddbcae1..bd7be9a8a5 100644 --- a/dev/concept_reference/min_voltage_angle/index.html +++ b/dev/concept_reference/min_voltage_angle/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub
+- · SpineOpt.jl
GitHub
diff --git a/dev/concept_reference/minimum_operating_point/index.html b/dev/concept_reference/minimum_operating_point/index.html index acf7f83fc7..0ebdc3c092 100644 --- a/dev/concept_reference/minimum_operating_point/index.html +++ b/dev/concept_reference/minimum_operating_point/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

The definition of the minimum_operating_point parameter will trigger the creation of the Constraint on minimum operating point. It sets a lower bound on the value of the unit_flow variable for a unit that is online.

It can be defined for unit__to_node or unit__from_node relationships, as well as their counterparts for node groups. It will then impose restrictions on the unit_flow variables that indicate flows between the two members of the relationship for which the parameter is defined. The parameter is given as a fraction of the unit_capacity parameter. When the parameter is not included, the aforementioned constraint will not be created, which is equivalent to choosing a value of 0.

+- · SpineOpt.jl
GitHub

The definition of the minimum_operating_point parameter will trigger the creation of the Constraint on minimum operating point. It sets a lower bound on the value of the unit_flow variable for a unit that is online.

It can be defined for unit__to_node or unit__from_node relationships, as well as their counterparts for node groups. It will then impose restrictions on the unit_flow variables that indicate flows between the two members of the relationship for which the parameter is defined. The parameter is given as a fraction of the unit_capacity parameter. When the parameter is not included, the aforementioned constraint will not be created, which is equivalent to choosing a value of 0.

diff --git a/dev/concept_reference/minimum_reserve_activation_time/index.html b/dev/concept_reference/minimum_reserve_activation_time/index.html index 1e674f36f6..4771318ea5 100644 --- a/dev/concept_reference/minimum_reserve_activation_time/index.html +++ b/dev/concept_reference/minimum_reserve_activation_time/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

The parameter minimum_reserve_activation_time is the duration a reserve product needs to be online, before it can be replaced by another (slower) reserve product.

In SpineOpt, the parameter is used to model reserve provision through storages. If a storage provides reserves to a reserve node (see also is_reserve_node) one needs to ensure that the node state is sufficiently high to provide these scheduled reserves as least for the duration of the minimum_reserve_activation_time. The constraint on the minimum node state with reserve provision is triggered by the existence of the minimum_reserve_activation_time. See also Ramping and Reserves

+- · SpineOpt.jl
GitHub

The parameter minimum_reserve_activation_time is the duration a reserve product needs to be online, before it can be replaced by another (slower) reserve product.

In SpineOpt, the parameter is used to model reserve provision through storages. If a storage provides reserves to a reserve node (see also is_reserve_node) one needs to ensure that the node state is sufficiently high to provide these scheduled reserves as least for the duration of the minimum_reserve_activation_time. The constraint on the minimum node state with reserve provision is triggered by the existence of the minimum_reserve_activation_time. See also Ramping and Reserves

diff --git a/dev/concept_reference/model/index.html b/dev/concept_reference/model/index.html index b12460c4f9..fe6d54bcb9 100644 --- a/dev/concept_reference/model/index.html +++ b/dev/concept_reference/model/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

The model object holds general information about the optimization problem at hand. Firstly, the modelling horizon is specified on the model object, i.e. the scope of the optimization model, and if applicable the duration of the rolling window (see also model_start, model_end and roll_forward). Secondly, the model works as an overarching assembler - only through linking temporal_blocks and stochastic_structures to a model object via relationships, they become part of the optimization problem, and respectively linked nodes, connections and units. If desired the user can also specify defaults for temporals and stochastic via the designated default relationships (see e.g., model__default_temporal_block). In this case, the default temporal is populated for missing node__temporal_block relationships. Lastly, the model object contains information about the algorithm used for solving the problem (see model_type).

+- · SpineOpt.jl
GitHub

The model object holds general information about the optimization problem at hand. Firstly, the modelling horizon is specified on the model object, i.e. the scope of the optimization model, and if applicable the duration of the rolling window (see also model_start, model_end and roll_forward). Secondly, the model works as an overarching assembler - only through linking temporal_blocks and stochastic_structures to a model object via relationships, they become part of the optimization problem, and respectively linked nodes, connections and units. If desired the user can also specify defaults for temporals and stochastic via the designated default relationships (see e.g., model__default_temporal_block). In this case, the default temporal is populated for missing node__temporal_block relationships. Lastly, the model object contains information about the algorithm used for solving the problem (see model_type).

diff --git a/dev/concept_reference/model__default_investment_stochastic_structure/index.html b/dev/concept_reference/model__default_investment_stochastic_structure/index.html index 3f4aebc277..ba710b29b4 100644 --- a/dev/concept_reference/model__default_investment_stochastic_structure/index.html +++ b/dev/concept_reference/model__default_investment_stochastic_structure/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

The model__default_investment_stochastic_structure relationship can be used to set model-wide default unit__investment_stochastic_structure, connection__investment_stochastic_structure, and node__investment_stochastic_structure relationships. Its main purpose is to allow users to avoid defining each relationship individually, and instead allow them to focus on defining only the exceptions. As such, any specific unit__investment_stochastic_structure, connection__investment_stochastic_structure, and node__investment_stochastic_structure relationships take priority over the model__default_investment_stochastic_structure relationship.

+- · SpineOpt.jl
GitHub

The model__default_investment_stochastic_structure relationship can be used to set model-wide default unit__investment_stochastic_structure, connection__investment_stochastic_structure, and node__investment_stochastic_structure relationships. Its main purpose is to allow users to avoid defining each relationship individually, and instead allow them to focus on defining only the exceptions. As such, any specific unit__investment_stochastic_structure, connection__investment_stochastic_structure, and node__investment_stochastic_structure relationships take priority over the model__default_investment_stochastic_structure relationship.

diff --git a/dev/concept_reference/model__default_investment_temporal_block/index.html b/dev/concept_reference/model__default_investment_temporal_block/index.html index 177f7078fb..94e7ad29cd 100644 --- a/dev/concept_reference/model__default_investment_temporal_block/index.html +++ b/dev/concept_reference/model__default_investment_temporal_block/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

model__default_investment_temporal_block is a two-dimensional relationship between a model and a temporal_block. This relationship defines the default temporal resolution and scope for all investment decisions in the model (units, connections and storages). Specifying model__default_investment_temporal_block for a model avoids the need to specify individual node__investment_temporal_block, unit__investment_temporal_block and connection__investment_temporal_block relationships. Conversely, if any of these individual relationships are defined (e.g. connection__investment_temporal_block) along with model__temporal_block, these will override model__default_investment_temporal_block.

See also Investment Optimization

+- · SpineOpt.jl
GitHub

model__default_investment_temporal_block is a two-dimensional relationship between a model and a temporal_block. This relationship defines the default temporal resolution and scope for all investment decisions in the model (units, connections and storages). Specifying model__default_investment_temporal_block for a model avoids the need to specify individual node__investment_temporal_block, unit__investment_temporal_block and connection__investment_temporal_block relationships. Conversely, if any of these individual relationships are defined (e.g. connection__investment_temporal_block) along with model__temporal_block, these will override model__default_investment_temporal_block.

See also Investment Optimization

diff --git a/dev/concept_reference/model__default_stochastic_structure/index.html b/dev/concept_reference/model__default_stochastic_structure/index.html index 09b911c251..552ba6ba5c 100644 --- a/dev/concept_reference/model__default_stochastic_structure/index.html +++ b/dev/concept_reference/model__default_stochastic_structure/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub
+- · SpineOpt.jl
GitHub
diff --git a/dev/concept_reference/model__default_temporal_block/index.html b/dev/concept_reference/model__default_temporal_block/index.html index ff13c8f3a0..7f70300854 100644 --- a/dev/concept_reference/model__default_temporal_block/index.html +++ b/dev/concept_reference/model__default_temporal_block/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub
+- · SpineOpt.jl
GitHub
diff --git a/dev/concept_reference/model__report/index.html b/dev/concept_reference/model__report/index.html index 0da7948d7f..c4c0cbc5a7 100644 --- a/dev/concept_reference/model__report/index.html +++ b/dev/concept_reference/model__report/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub
+- · SpineOpt.jl
GitHub
diff --git a/dev/concept_reference/model__stochastic_structure/index.html b/dev/concept_reference/model__stochastic_structure/index.html index dbb9f79502..85b926c0e3 100644 --- a/dev/concept_reference/model__stochastic_structure/index.html +++ b/dev/concept_reference/model__stochastic_structure/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

The [model__stochastic_structure] relationship defines which stochastic_structures are active in which models. Essentially, this relationship allows for e.g. attributing multiple node__stochastic_structure relationships for a single node, and switching between them in different models. Any stochastic_structure in the model__default_stochastic_structure relationship is automatically assumed to be active in the connected model, so there's no need to include it in [model__stochastic_structure] separately.

+- · SpineOpt.jl
GitHub

The [model__stochastic_structure] relationship defines which stochastic_structures are active in which models. Essentially, this relationship allows for e.g. attributing multiple node__stochastic_structure relationships for a single node, and switching between them in different models. Any stochastic_structure in the model__default_stochastic_structure relationship is automatically assumed to be active in the connected model, so there's no need to include it in [model__stochastic_structure] separately.

diff --git a/dev/concept_reference/model__temporal_block/index.html b/dev/concept_reference/model__temporal_block/index.html index 2a8e6a3b99..32b0dcf335 100644 --- a/dev/concept_reference/model__temporal_block/index.html +++ b/dev/concept_reference/model__temporal_block/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

The model__temporal_block relationship is used to determine which temporal_blocks are included in a specific model. Note that defining this relationship does not yet imply that any element of the model will be governed by the specified temporal_block, for this to happen additional relationships have to be defined such as the model__default_temporal_block relationship.

+- · SpineOpt.jl
GitHub

The model__temporal_block relationship is used to determine which temporal_blocks are included in a specific model. Note that defining this relationship does not yet imply that any element of the model will be governed by the specified temporal_block, for this to happen additional relationships have to be defined such as the model__default_temporal_block relationship.

diff --git a/dev/concept_reference/model_end/index.html b/dev/concept_reference/model_end/index.html index 99c56e5e4c..6fa3aad7ab 100644 --- a/dev/concept_reference/model_end/index.html +++ b/dev/concept_reference/model_end/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

Together with the model_start parameter, it is used to define the temporal horizon of the model. In case of a single solve optimization, the parameter marks the end of the last timestep that is possibly part of the optimization. Note that it poses an upper bound, and that the optimization does not necessarily include this timestamp when the block_end parameters are more stringent.

In case of a rolling horizon optimization, it will tell to the model to stop rolling forward once an optimization has been performed for which the result of the indicated timestamp has been kept in the final results. For example, assume that a model_end value of 2030-01-01T05:00:00 has been chosen, a block_end of 3h, and a roll_forward of 2h. The roll_forward parameter indicates here that the results of the first two hours of each optimization window are kept as final, therefore the last optimization window will span the timeframe [2030-01-01T04:00:00 - 2030-01-01T06:00:00].

A DateTime value should be chosen for this parameter.

+- · SpineOpt.jl
GitHub

Together with the model_start parameter, it is used to define the temporal horizon of the model. In case of a single solve optimization, the parameter marks the end of the last timestep that is possibly part of the optimization. Note that it poses an upper bound, and that the optimization does not necessarily include this timestamp when the block_end parameters are more stringent.

In case of a rolling horizon optimization, it will tell to the model to stop rolling forward once an optimization has been performed for which the result of the indicated timestamp has been kept in the final results. For example, assume that a model_end value of 2030-01-01T05:00:00 has been chosen, a block_end of 3h, and a roll_forward of 2h. The roll_forward parameter indicates here that the results of the first two hours of each optimization window are kept as final, therefore the last optimization window will span the timeframe [2030-01-01T04:00:00 - 2030-01-01T06:00:00].

A DateTime value should be chosen for this parameter.

diff --git a/dev/concept_reference/model_start/index.html b/dev/concept_reference/model_start/index.html index 224f8f0942..0aaf37d546 100644 --- a/dev/concept_reference/model_start/index.html +++ b/dev/concept_reference/model_start/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

Together with the model_end parameter, it is used to define the temporal horizon of the model. For a single solve optimization, it marks the timestamp from which the relative offset in a temporal_block is defined by the block_start parameter. In the rolling optimization framework, it does this for the first optimization window.

A DateTime value should be chosen for this parameter.

+- · SpineOpt.jl
GitHub

Together with the model_end parameter, it is used to define the temporal horizon of the model. For a single solve optimization, it marks the timestamp from which the relative offset in a temporal_block is defined by the block_start parameter. In the rolling optimization framework, it does this for the first optimization window.

A DateTime value should be chosen for this parameter.

diff --git a/dev/concept_reference/model_type/index.html b/dev/concept_reference/model_type/index.html index 4b21fd3d78..020e3e3852 100644 --- a/dev/concept_reference/model_type/index.html +++ b/dev/concept_reference/model_type/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

This parameter controls the low-level algorithm that SpineOpt uses to solve the underlying optimization problem. Currently three values are possible:

spineopt_standard uses the standard algorithm.

spineopt_benders uses the Benders decomposition algorithm (see Decomposition.

spineopt_mga uses the Model to Generate Alternatives algorithm.

+- · SpineOpt.jl
GitHub

This parameter controls the low-level algorithm that SpineOpt uses to solve the underlying optimization problem. Currently three values are possible:

spineopt_standard uses the standard algorithm.

spineopt_benders uses the Benders decomposition algorithm (see Decomposition.

spineopt_mga uses the Model to Generate Alternatives algorithm.

diff --git a/dev/concept_reference/model_type_list/index.html b/dev/concept_reference/model_type_list/index.html index 46f7d6da79..a17d6f473c 100644 --- a/dev/concept_reference/model_type_list/index.html +++ b/dev/concept_reference/model_type_list/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

model_type_list holds the possible values for the model parameter model_type parameter. See model_type for more details

+- · SpineOpt.jl
GitHub

model_type_list holds the possible values for the model parameter model_type parameter. See model_type for more details

diff --git a/dev/concept_reference/mp_min_res_gen_to_demand_ratio/index.html b/dev/concept_reference/mp_min_res_gen_to_demand_ratio/index.html index 6a309a6527..252f08ca8f 100644 --- a/dev/concept_reference/mp_min_res_gen_to_demand_ratio/index.html +++ b/dev/concept_reference/mp_min_res_gen_to_demand_ratio/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

For investment models that are solved using the Benders algorithm (i.e., with model_type set to spineopt_benders), mp_min_res_gen_to_demand_ratio represents a lower bound on the fraction of the total system demand that must be supplied by renewable generation sources (RES).

A unit can be marked as a renewable generation source by setting is_renewable to true.

+- · SpineOpt.jl
GitHub

For investment models that are solved using the Benders algorithm (i.e., with model_type set to spineopt_benders), mp_min_res_gen_to_demand_ratio represents a lower bound on the fraction of the total system demand that must be supplied by renewable generation sources (RES).

A unit can be marked as a renewable generation source by setting is_renewable to true.

diff --git a/dev/concept_reference/mp_min_res_gen_to_demand_ratio_slack_penalty/index.html b/dev/concept_reference/mp_min_res_gen_to_demand_ratio_slack_penalty/index.html index 2491dbd8d2..0d9ae691c1 100644 --- a/dev/concept_reference/mp_min_res_gen_to_demand_ratio_slack_penalty/index.html +++ b/dev/concept_reference/mp_min_res_gen_to_demand_ratio_slack_penalty/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

A penalty for violating the mp_min_res_gen_to_demand_ratio. If set, then the lower bound on the fraction of the total system demand that must be supplied by RES becomes a 'soft' constraint. A new cost term is added to the objective, mutlitplying the penalty by the slack.

+- · SpineOpt.jl
GitHub

A penalty for violating the mp_min_res_gen_to_demand_ratio. If set, then the lower bound on the fraction of the total system demand that must be supplied by RES becomes a 'soft' constraint. A new cost term is added to the objective, mutlitplying the penalty by the slack.

diff --git a/dev/concept_reference/nodal_balance_sense/index.html b/dev/concept_reference/nodal_balance_sense/index.html index e96948fff3..43efdb8e59 100644 --- a/dev/concept_reference/nodal_balance_sense/index.html +++ b/dev/concept_reference/nodal_balance_sense/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

nodal_balance_sense determines whether or not a node is able to naturally consume or produce energy. The default value, ==, means that the node is unable to do any of that, and thus it needs to be perfectly balanced. The vale >= means that the node is a sink, that is, it can consume any amounts of energy. The value <= means that the node is a source, that is, it can produce any amounts of energy.

+- · SpineOpt.jl
GitHub

nodal_balance_sense determines whether or not a node is able to naturally consume or produce energy. The default value, ==, means that the node is unable to do any of that, and thus it needs to be perfectly balanced. The vale >= means that the node is a sink, that is, it can consume any amounts of energy. The value <= means that the node is a source, that is, it can produce any amounts of energy.

diff --git a/dev/concept_reference/node/index.html b/dev/concept_reference/node/index.html index 4cd54a2257..821fd110a1 100644 --- a/dev/concept_reference/node/index.html +++ b/dev/concept_reference/node/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

The node is perhaps the most important object class out of the Systemic object classes, as it is what connects the rest together via the Systemic relationship classes. Essentially, nodes act as points in the modelled commodity network where commodity balance is enforced via the node balance and node injection constraints, tying together the inputs and outputs from units and connections, as well as any external demand. Furthermore, nodes play a crucial role for defining the temporal and stochastic structures of the model via the node__temporal_block and node__stochastic_structure relationships. For more details about the Temporal Framework and the Stochastic Framework, please refer to the dedicated sections.

Since nodes act as the points where commodity balance is enforced, this also makes them a natural fit for implementing storage. The has_state parameter controls whether a node has a node_state variable, which essentially represents the commodity content of the node. The state_coeff parameter tells how the node_state variable relates to all the commodity flows. Storage losses are handled via the frac_state_loss parameter, and potential diffusion of commodity content to other nodes via the diff_coeff parameter for the node__node relationship.

+- · SpineOpt.jl
GitHub

The node is perhaps the most important object class out of the Systemic object classes, as it is what connects the rest together via the Systemic relationship classes. Essentially, nodes act as points in the modelled commodity network where commodity balance is enforced via the node balance and node injection constraints, tying together the inputs and outputs from units and connections, as well as any external demand. Furthermore, nodes play a crucial role for defining the temporal and stochastic structures of the model via the node__temporal_block and node__stochastic_structure relationships. For more details about the Temporal Framework and the Stochastic Framework, please refer to the dedicated sections.

Since nodes act as the points where commodity balance is enforced, this also makes them a natural fit for implementing storage. The has_state parameter controls whether a node has a node_state variable, which essentially represents the commodity content of the node. The state_coeff parameter tells how the node_state variable relates to all the commodity flows. Storage losses are handled via the frac_state_loss parameter, and potential diffusion of commodity content to other nodes via the diff_coeff parameter for the node__node relationship.

diff --git a/dev/concept_reference/node__commodity/index.html b/dev/concept_reference/node__commodity/index.html index 1402319981..a31ef39bda 100644 --- a/dev/concept_reference/node__commodity/index.html +++ b/dev/concept_reference/node__commodity/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

node__commodity is a two-dimensional relationship between a node and a commodity and specifies the commodity that flows to or from the node. Generally, since flows are not dimensioned by commodity, this has no meaning in terms of the variables and constraint equations. However, there are two specific uses for this relationship:

  1. To specify that specific network physics should apply to the network formed by the member nodes for that commodity. See powerflow
  2. Only connection flows that are between nodes of the same or no commodity are included in the node_balance constraint.
+- · SpineOpt.jl
GitHub

node__commodity is a two-dimensional relationship between a node and a commodity and specifies the commodity that flows to or from the node. Generally, since flows are not dimensioned by commodity, this has no meaning in terms of the variables and constraint equations. However, there are two specific uses for this relationship:

  1. To specify that specific network physics should apply to the network formed by the member nodes for that commodity. See powerflow
  2. Only connection flows that are between nodes of the same or no commodity are included in the node_balance constraint.
diff --git a/dev/concept_reference/node__investment_stochastic_structure/index.html b/dev/concept_reference/node__investment_stochastic_structure/index.html index 2d946b7b85..63b69cacbd 100644 --- a/dev/concept_reference/node__investment_stochastic_structure/index.html +++ b/dev/concept_reference/node__investment_stochastic_structure/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub
+- · SpineOpt.jl
GitHub
diff --git a/dev/concept_reference/node__investment_temporal_block/index.html b/dev/concept_reference/node__investment_temporal_block/index.html index 200100e169..0ec6243c6e 100644 --- a/dev/concept_reference/node__investment_temporal_block/index.html +++ b/dev/concept_reference/node__investment_temporal_block/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

node__investment_temporal_block is a two-dimensional relationship between a node and a temporal_block. This relationship defines the temporal resolution and scope of a node's investment decisions (currently only storage invesments). Note that in a decomposed investments problem with two model objects, one for the master problem model and another for the operations problem model, the link to the specific model is made indirectly through the model__temporal_block relationship. If a model__default_investment_temporal_block is specified and no node__investment_temporal_block relationship is specified, the model__default_investment_temporal_block relationship will be used. Conversely if node__investment_temporal_block is specified along with model__temporal_block, this will override model__default_investment_temporal_block for the specified node.

See also Investment Optimization

+- · SpineOpt.jl
GitHub

node__investment_temporal_block is a two-dimensional relationship between a node and a temporal_block. This relationship defines the temporal resolution and scope of a node's investment decisions (currently only storage invesments). Note that in a decomposed investments problem with two model objects, one for the master problem model and another for the operations problem model, the link to the specific model is made indirectly through the model__temporal_block relationship. If a model__default_investment_temporal_block is specified and no node__investment_temporal_block relationship is specified, the model__default_investment_temporal_block relationship will be used. Conversely if node__investment_temporal_block is specified along with model__temporal_block, this will override model__default_investment_temporal_block for the specified node.

See also Investment Optimization

diff --git a/dev/concept_reference/node__node/index.html b/dev/concept_reference/node__node/index.html index f7afaeda83..ce3322f194 100644 --- a/dev/concept_reference/node__node/index.html +++ b/dev/concept_reference/node__node/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

The node__node relationship is used for defining direct interactions between two nodes, like diffusion of commodity content. Note that the node__node relationship is assumed to be one-directional, meaning that

node__node(node1=n1, node2=n2) != node__node(node1=n2, node2=n1).

Thus, when one wants to define symmetric relationships between two nodes, one needs to define both directions as separate relationships.

+- · SpineOpt.jl
GitHub

The node__node relationship is used for defining direct interactions between two nodes, like diffusion of commodity content. Note that the node__node relationship is assumed to be one-directional, meaning that

node__node(node1=n1, node2=n2) != node__node(node1=n2, node2=n1).

Thus, when one wants to define symmetric relationships between two nodes, one needs to define both directions as separate relationships.

diff --git a/dev/concept_reference/node__stochastic_structure/index.html b/dev/concept_reference/node__stochastic_structure/index.html index 81b35cf0c8..308c666efd 100644 --- a/dev/concept_reference/node__stochastic_structure/index.html +++ b/dev/concept_reference/node__stochastic_structure/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

The node__stochastic_structure relationship defines which stochastic_structure the node uses. Essentially, it sets the stochastic_structure of all the flow variables connected to the node, as well as the potential node_state variable. Note that only one stochastic_structure can be defined per node per model, as interpreted based on the node__stochastic_structure and model__stochastic_structure relationships. Investment variables use dedicated relationships, as detailed in the Investment Optimization section.

The node__stochastic_structure relationship uses the model__default_stochastic_structure relationship if not specified.

+- · SpineOpt.jl
GitHub

The node__stochastic_structure relationship defines which stochastic_structure the node uses. Essentially, it sets the stochastic_structure of all the flow variables connected to the node, as well as the potential node_state variable. Note that only one stochastic_structure can be defined per node per model, as interpreted based on the node__stochastic_structure and model__stochastic_structure relationships. Investment variables use dedicated relationships, as detailed in the Investment Optimization section.

The node__stochastic_structure relationship uses the model__default_stochastic_structure relationship if not specified.

diff --git a/dev/concept_reference/node__temporal_block/index.html b/dev/concept_reference/node__temporal_block/index.html index 2e8e0b4398..9bc4f3dd8c 100644 --- a/dev/concept_reference/node__temporal_block/index.html +++ b/dev/concept_reference/node__temporal_block/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

This relationship links a node to a temporal_block and as such it will determine which temporal block governs the temporal horizon and resolution of the variables associated with this node. Specifically, the resolution of the temporal block will directly imply the duration of the time slices for which both the regular and ramping flow variables and their associated constraints are created.

For a more detailed description of how the temporal structure in SpineOpt can be created, see Temporal Framework.

+- · SpineOpt.jl
GitHub

This relationship links a node to a temporal_block and as such it will determine which temporal block governs the temporal horizon and resolution of the variables associated with this node. Specifically, the resolution of the temporal block will directly imply the duration of the time slices for which both the regular and ramping flow variables and their associated constraints are created.

For a more detailed description of how the temporal structure in SpineOpt can be created, see Temporal Framework.

diff --git a/dev/concept_reference/node__unit_constraint/index.html b/dev/concept_reference/node__unit_constraint/index.html index fa36890ad7..660647b44d 100644 --- a/dev/concept_reference/node__unit_constraint/index.html +++ b/dev/concept_reference/node__unit_constraint/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

node__user_constraint is a two-dimensional relationship between a node and a user_constraint. The relationship specifies that a variable associated only with the node (currently only the node_state) is involved in the constraint. For example, the node_state_coefficient defined on node__user_constraint specifies the coefficient of the node's node_state variable in the specified user_constraint.

See also user_constraint

+- · SpineOpt.jl
GitHub

node__user_constraint is a two-dimensional relationship between a node and a user_constraint. The relationship specifies that a variable associated only with the node (currently only the node_state) is involved in the constraint. For example, the node_state_coefficient defined on node__user_constraint specifies the coefficient of the node's node_state variable in the specified user_constraint.

See also user_constraint

diff --git a/dev/concept_reference/node_opf_type/index.html b/dev/concept_reference/node_opf_type/index.html index 02672fff2b..f6feee08f4 100644 --- a/dev/concept_reference/node_opf_type/index.html +++ b/dev/concept_reference/node_opf_type/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub
+- · SpineOpt.jl
GitHub
diff --git a/dev/concept_reference/node_opf_type_list/index.html b/dev/concept_reference/node_opf_type_list/index.html index c688b359e1..aae78ad233 100644 --- a/dev/concept_reference/node_opf_type_list/index.html +++ b/dev/concept_reference/node_opf_type_list/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

Houses the different possible values for the node_opf_type parameter. To identify the reference node, set node_opf_type = :node_opf_type_reference, while node_opf_type = node_opf_type_normal is the default value for non-reference nodes.

See also powerflow.

+- · SpineOpt.jl
GitHub

Houses the different possible values for the node_opf_type parameter. To identify the reference node, set node_opf_type = :node_opf_type_reference, while node_opf_type = node_opf_type_normal is the default value for non-reference nodes.

See also powerflow.

diff --git a/dev/concept_reference/node_slack_penalty/index.html b/dev/concept_reference/node_slack_penalty/index.html index fdea30443f..bfa537a55f 100644 --- a/dev/concept_reference/node_slack_penalty/index.html +++ b/dev/concept_reference/node_slack_penalty/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

node_slack_penalty triggers the creation of node slack variables, node_slack_pos and node_slack_neg. This allows the model to violate the node_balance constraint with these violations penalised in the objective function with a coefficient equal to node_slack_penalty. If node_slack_penalty = 0 the slack variables are created and violations are unpenalised. If set to none or undefined, the variables are not created and violation of the node_balance constraint is not possible.

+- · SpineOpt.jl
GitHub

node_slack_penalty triggers the creation of node slack variables, node_slack_pos and node_slack_neg. This allows the model to violate the node_balance constraint with these violations penalised in the objective function with a coefficient equal to node_slack_penalty. If node_slack_penalty = 0 the slack variables are created and violations are unpenalised. If set to none or undefined, the variables are not created and violation of the node_balance constraint is not possible.

diff --git a/dev/concept_reference/node_state_cap/index.html b/dev/concept_reference/node_state_cap/index.html index fd007fd1f2..eae6338796 100644 --- a/dev/concept_reference/node_state_cap/index.html +++ b/dev/concept_reference/node_state_cap/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

The node_state_cap parameter represents the maximum allowed value for the node_state variable. Note that in order for a node to have a node_state variable in the first place, the has_state parameter must be set to true. However, if the node has storage investments enabled using the candidate_storages parameter, the node_state_cap parameter acts as a coefficient for the storages_invested_available variable. Essentially, with investments, the node_state_cap parameter represents storage capacity per storage investment.

+- · SpineOpt.jl
GitHub

The node_state_cap parameter represents the maximum allowed value for the node_state variable. Note that in order for a node to have a node_state variable in the first place, the has_state parameter must be set to true. However, if the node has storage investments enabled using the candidate_storages parameter, the node_state_cap parameter acts as a coefficient for the storages_invested_available variable. Essentially, with investments, the node_state_cap parameter represents storage capacity per storage investment.

diff --git a/dev/concept_reference/node_state_coefficient/index.html b/dev/concept_reference/node_state_coefficient/index.html index dae14140ef..c7f42034f7 100644 --- a/dev/concept_reference/node_state_coefficient/index.html +++ b/dev/concept_reference/node_state_coefficient/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub
+- · SpineOpt.jl
GitHub
diff --git a/dev/concept_reference/node_state_min/index.html b/dev/concept_reference/node_state_min/index.html index 20613a61c9..997eb9bd11 100644 --- a/dev/concept_reference/node_state_min/index.html +++ b/dev/concept_reference/node_state_min/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub
+- · SpineOpt.jl
GitHub
diff --git a/dev/concept_reference/number_of_units/index.html b/dev/concept_reference/number_of_units/index.html index b8616f1056..ff6e5a9ea2 100644 --- a/dev/concept_reference/number_of_units/index.html +++ b/dev/concept_reference/number_of_units/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

Defines how many members a certain unit object represents. Typically this parameter takes a binary (UC) or integer (clustered UC) value. Together with the unit_availability_factor, this will determine the maximum number of members that can be online at any given time. (Thus restricting the units_on variable). It is possible to allow the model to increase the number_of_units itself, through Investment Optimization

The default value for this parameter is 1.

+- · SpineOpt.jl
GitHub

Defines how many members a certain unit object represents. Typically this parameter takes a binary (UC) or integer (clustered UC) value. Together with the unit_availability_factor, this will determine the maximum number of members that can be online at any given time. (Thus restricting the units_on variable). It is possible to allow the model to increase the number_of_units itself, through Investment Optimization

The default value for this parameter is 1.

diff --git a/dev/concept_reference/online_variable_type/index.html b/dev/concept_reference/online_variable_type/index.html index e0c141d5af..b5b15e7122 100644 --- a/dev/concept_reference/online_variable_type/index.html +++ b/dev/concept_reference/online_variable_type/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

online_variable_type is a method parameter to model the 'commitment' or 'activation' of a unit, that is the situation where the unit becomes online and active in the system. It can take the values "unit_online_variable_type_binary", "unit_online_variable_type_integer", "unit_online_variable_type_linear" and "unit_online_variable_type_none".

If unit\_online\_variable\_type\_binary, then the commitment is modelled as an online/offline decision (classic unit commitment).

If unit\_online\_variable\_type\_integer, then the commitment is modelled as the number of units that are online (clustered unit commitment).

If unit\_online\_variable\_type\_linear, then the commitment is modelled as the number of units that are online, but here it is also possible to activate 'fractions' of a unit. This should reduce computational burden compared to unit\_online\_variable\_type\_integer.

If unit\_online\_variable\_type\_none, then the committment is not modelled at all and the unit is assumed to be always online. This reduces the computational burden the most.

+- · SpineOpt.jl
GitHub

online_variable_type is a method parameter to model the 'commitment' or 'activation' of a unit, that is the situation where the unit becomes online and active in the system. It can take the values "unit_online_variable_type_binary", "unit_online_variable_type_integer", "unit_online_variable_type_linear" and "unit_online_variable_type_none".

If unit\_online\_variable\_type\_binary, then the commitment is modelled as an online/offline decision (classic unit commitment).

If unit\_online\_variable\_type\_integer, then the commitment is modelled as the number of units that are online (clustered unit commitment).

If unit\_online\_variable\_type\_linear, then the commitment is modelled as the number of units that are online, but here it is also possible to activate 'fractions' of a unit. This should reduce computational burden compared to unit\_online\_variable\_type\_integer.

If unit\_online\_variable\_type\_none, then the committment is not modelled at all and the unit is assumed to be always online. This reduces the computational burden the most.

diff --git a/dev/concept_reference/operating_cost/index.html b/dev/concept_reference/operating_cost/index.html index c719d25f87..70cebf5c66 100644 --- a/dev/concept_reference/operating_cost/index.html +++ b/dev/concept_reference/operating_cost/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

By defining the operating_cost parameter for a specific unit, node, and direction, a cost term will be added to the objective function to account for operating costs associated with that unit over the course of its operational dispatch during the current optimization window.

+- · SpineOpt.jl
GitHub

By defining the operating_cost parameter for a specific unit, node, and direction, a cost term will be added to the objective function to account for operating costs associated with that unit over the course of its operational dispatch during the current optimization window.

diff --git a/dev/concept_reference/operating_points/index.html b/dev/concept_reference/operating_points/index.html index e8dbbcffda..1be0684372 100644 --- a/dev/concept_reference/operating_points/index.html +++ b/dev/concept_reference/operating_points/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

If operating_points is defined as an array type on a certain unit__to_node or unit__from_node flow, the corresponding unit_flow flow variable is decomposed into a number of sub operating segment variables, unit_flow_op one for each operating segment, with an additional index, i to reference the specific operating segment. Each value in the array represents the upper bound of the operating segment, normalized on unit_capacity for the corresponding unit__to_node or unit__from_node flow. operating_points is used in conjunction with unit_incremental_heat_rate where the array dimension must match and is used to define the normalized operating point bounds for the corresponding incremental heat rate. operating_points is also used in conjunction with user_constraint where the array dimension must match any corresponding piecewise linear unit_flow_coefficient. Here operating_points is used also to define the normalized operating point bounds for the corresponding unit_flow_coefficients.

Note that operating_points is defined on a capacity-normalized basis and the values represent the upper bound of the corresponding operating segment variable. So if operating_points is specified as [0.5, 1], this creates two operating segments, one from zero to 50% of the corresponding unit_capacity and a second from 50% to 100% of the corresponding unit_capacity.

+- · SpineOpt.jl
GitHub

If operating_points is defined as an array type on a certain unit__to_node or unit__from_node flow, the corresponding unit_flow flow variable is decomposed into a number of sub operating segment variables, unit_flow_op one for each operating segment, with an additional index, i to reference the specific operating segment. Each value in the array represents the upper bound of the operating segment, normalized on unit_capacity for the corresponding unit__to_node or unit__from_node flow. operating_points is used in conjunction with unit_incremental_heat_rate where the array dimension must match and is used to define the normalized operating point bounds for the corresponding incremental heat rate. operating_points is also used in conjunction with user_constraint where the array dimension must match any corresponding piecewise linear unit_flow_coefficient. Here operating_points is used also to define the normalized operating point bounds for the corresponding unit_flow_coefficients.

Note that operating_points is defined on a capacity-normalized basis and the values represent the upper bound of the corresponding operating segment variable. So if operating_points is specified as [0.5, 1], this creates two operating segments, one from zero to 50% of the corresponding unit_capacity and a second from 50% to 100% of the corresponding unit_capacity.

diff --git a/dev/concept_reference/ordered_unit_flow_op/index.html b/dev/concept_reference/ordered_unit_flow_op/index.html index b34a2b1410..41954ed86a 100644 --- a/dev/concept_reference/ordered_unit_flow_op/index.html +++ b/dev/concept_reference/ordered_unit_flow_op/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

If one defines the parameter ordered_unit_flow_op in a unit__from_node or unit__to_node relationship, SpineOpt will create variable unit_flow_op_active to order each unit_flow_op of the unit_flow according to the rank of defined operating_points. This setting is only necessary when the segmental unit_flow_ops are with increasing conversion efficiency. The numerical type of unit_flow_op_active (float, binary, or integer) follows that of variable units_on which can be set via parameter online_variable_type.

Note that this functionality is based on SOS2 constraints so only a MILP configuration, i.e. make variable unit_flow_op_active a binary or integer, guarantees correct performance.

+- · SpineOpt.jl
GitHub

If one defines the parameter ordered_unit_flow_op in a unit__from_node or unit__to_node relationship, SpineOpt will create variable unit_flow_op_active to order each unit_flow_op of the unit_flow according to the rank of defined operating_points. This setting is only necessary when the segmental unit_flow_ops are with increasing conversion efficiency. The numerical type of unit_flow_op_active (float, binary, or integer) follows that of variable units_on which can be set via parameter online_variable_type.

Note that this functionality is based on SOS2 constraints so only a MILP configuration, i.e. make variable unit_flow_op_active a binary or integer, guarantees correct performance.

diff --git a/dev/concept_reference/output/index.html b/dev/concept_reference/output/index.html index da7da4f969..a322c84a0d 100644 --- a/dev/concept_reference/output/index.html +++ b/dev/concept_reference/output/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

An output is essentially a handle for a SpineOpt variable and Objective function to be included in a report and written into an output database. Typically, e.g. the unit_flow variables are desired as output from most models, so creating an output object called unit_flow allows one to designate it as something to be written in the desired report. Note that unless appropriate model__report and report__output relationships are defined, SpineOpt doesn't write any output!

+- · SpineOpt.jl
GitHub

An output is essentially a handle for a SpineOpt variable and Objective function to be included in a report and written into an output database. Typically, e.g. the unit_flow variables are desired as output from most models, so creating an output object called unit_flow allows one to designate it as something to be written in the desired report. Note that unless appropriate model__report and report__output relationships are defined, SpineOpt doesn't write any output!

diff --git a/dev/concept_reference/output_db_url/index.html b/dev/concept_reference/output_db_url/index.html index 4c05269c84..1030489af6 100644 --- a/dev/concept_reference/output_db_url/index.html +++ b/dev/concept_reference/output_db_url/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

The output_db_url parameter is the url of the databse to write the results of the model run. It overrides the value of the second argument passed to run_spineopt.

+- · SpineOpt.jl
GitHub

The output_db_url parameter is the url of the databse to write the results of the model run. It overrides the value of the second argument passed to run_spineopt.

diff --git a/dev/concept_reference/output_resolution/index.html b/dev/concept_reference/output_resolution/index.html index 3332271222..906d86e4fc 100644 --- a/dev/concept_reference/output_resolution/index.html +++ b/dev/concept_reference/output_resolution/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

The output_resolution parameter indicates the resolution at which output values should be reported.

If null (the default), then results are reported at the highest available resolution from the model. If output_resolution is a duration value, then results are aggregated at that resolution before being reported. At the moment, the aggregation is simply performed by taking the average value.

+- · SpineOpt.jl
GitHub

The output_resolution parameter indicates the resolution at which output values should be reported.

If null (the default), then results are reported at the highest available resolution from the model. If output_resolution is a duration value, then results are aggregated at that resolution before being reported. At the moment, the aggregation is simply performed by taking the average value.

diff --git a/dev/concept_reference/overwrite_results_on_rolling/index.html b/dev/concept_reference/overwrite_results_on_rolling/index.html index 8778e9cdac..72715aebd5 100644 --- a/dev/concept_reference/overwrite_results_on_rolling/index.html +++ b/dev/concept_reference/overwrite_results_on_rolling/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

The overwrite_results_on_rolling parameter allows one to define whether or not results from further optimisation windows should overwrite those from previous ones. This, of course, is relevant only if optimisation windows overlap, which in turn happens whenever a temporal_block goes beyond the end of the window.

If true (the default) then results are written as a time-series. If false, then results are written as a map from analysis time (i.e., the window start) to time-series.

+- · SpineOpt.jl
GitHub

The overwrite_results_on_rolling parameter allows one to define whether or not results from further optimisation windows should overwrite those from previous ones. This, of course, is relevant only if optimisation windows overlap, which in turn happens whenever a temporal_block goes beyond the end of the window.

If true (the default) then results are written as a time-series. If false, then results are written as a map from analysis time (i.e., the window start) to time-series.

diff --git a/dev/concept_reference/parent_stochastic_scenario__child_stochastic_scenario/index.html b/dev/concept_reference/parent_stochastic_scenario__child_stochastic_scenario/index.html index 632fc4b901..61adc15fcd 100644 --- a/dev/concept_reference/parent_stochastic_scenario__child_stochastic_scenario/index.html +++ b/dev/concept_reference/parent_stochastic_scenario__child_stochastic_scenario/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

The parent_stochastic_scenario__child_stochastic_scenario relationship defines how the individual stochastic_scenarios are related to each other, forming what is referred to as the stochastic direct acyclic graph (DAG) in the Stochastic Framework section. It acts as a sort of basis for the stochastic_structures, but doesn't contain any Parameters necessary for describing how it relates to the Temporal Framework or the Objective function.

The parent_stochastic_scenario__child_stochastic_scenario relationship and the stochastic DAG it forms are crucial for Constraint generation with stochastic path indexing. Every finite stochastic DAG has a limited number of unique ways of traversing it, called full stochastic paths, which are used when determining how many different constraints need to be generated over time periods where stochastic_structures branch or converge, or when generating constraints involving different stochastic_structures. See the Stochastic Framework section for more information.

+- · SpineOpt.jl
GitHub

The parent_stochastic_scenario__child_stochastic_scenario relationship defines how the individual stochastic_scenarios are related to each other, forming what is referred to as the stochastic direct acyclic graph (DAG) in the Stochastic Framework section. It acts as a sort of basis for the stochastic_structures, but doesn't contain any Parameters necessary for describing how it relates to the Temporal Framework or the Objective function.

The parent_stochastic_scenario__child_stochastic_scenario relationship and the stochastic DAG it forms are crucial for Constraint generation with stochastic path indexing. Every finite stochastic DAG has a limited number of unique ways of traversing it, called full stochastic paths, which are used when determining how many different constraints need to be generated over time periods where stochastic_structures branch or converge, or when generating constraints involving different stochastic_structures. See the Stochastic Framework section for more information.

diff --git a/dev/concept_reference/ramp_down_cost/index.html b/dev/concept_reference/ramp_down_cost/index.html index 31121439e1..19eb669147 100644 --- a/dev/concept_reference/ramp_down_cost/index.html +++ b/dev/concept_reference/ramp_down_cost/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

By defining the ramp_down_cost parameter for a specific unit__to_node or unit__from_node relationship, a cost term will be added to the objective function whenever the unit ramps down its activity (i.e., when the ramp_down_unit_flow is nonzero) over the course of its operational dispatch during the current optimization window.

+- · SpineOpt.jl
GitHub

By defining the ramp_down_cost parameter for a specific unit__to_node or unit__from_node relationship, a cost term will be added to the objective function whenever the unit ramps down its activity (i.e., when the ramp_down_unit_flow is nonzero) over the course of its operational dispatch during the current optimization window.

diff --git a/dev/concept_reference/ramp_down_limit/index.html b/dev/concept_reference/ramp_down_limit/index.html index 7b4b7414b6..62528c9e31 100644 --- a/dev/concept_reference/ramp_down_limit/index.html +++ b/dev/concept_reference/ramp_down_limit/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

The definition of the ramp_down_limit parameter will trigger the creation of the Constraint on spinning downward ramps. It will limit the maximum decrease in the unit_flow variable between two consecutive timesteps for which the unit is online.

It can be defined for unit__to_node or unit__from_node relationships, as well as their counterparts for node groups. It will then impose restrictions on the unit_flow variables that indicate flows between the two members of the relationship for which the parameter is defined. The parameter is given as a fraction of the unit_capacity parameter. When the parameter is not included, the aforementioned constraint will not be created, which is equivalent to choosing a value of 1.

+- · SpineOpt.jl
GitHub

The definition of the ramp_down_limit parameter will trigger the creation of the Constraint on spinning downward ramps. It will limit the maximum decrease in the unit_flow variable between two consecutive timesteps for which the unit is online.

It can be defined for unit__to_node or unit__from_node relationships, as well as their counterparts for node groups. It will then impose restrictions on the unit_flow variables that indicate flows between the two members of the relationship for which the parameter is defined. The parameter is given as a fraction of the unit_capacity parameter. When the parameter is not included, the aforementioned constraint will not be created, which is equivalent to choosing a value of 1.

diff --git a/dev/concept_reference/ramp_up_cost/index.html b/dev/concept_reference/ramp_up_cost/index.html index 77e9c2c991..a8607ab99b 100644 --- a/dev/concept_reference/ramp_up_cost/index.html +++ b/dev/concept_reference/ramp_up_cost/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

By defining the ramp_up_cost parameter for a specific unit__to_node or unit__from_node relationship, a cost term will be added to the objective function whenever the unit ramps up its activity (i.e., when the ramp_up_unit_flow is nonzero) over the course of its operational dispatch during the current optimization window.

+- · SpineOpt.jl
GitHub

By defining the ramp_up_cost parameter for a specific unit__to_node or unit__from_node relationship, a cost term will be added to the objective function whenever the unit ramps up its activity (i.e., when the ramp_up_unit_flow is nonzero) over the course of its operational dispatch during the current optimization window.

diff --git a/dev/concept_reference/ramp_up_limit/index.html b/dev/concept_reference/ramp_up_limit/index.html index bac897d6ad..e9ca31a143 100644 --- a/dev/concept_reference/ramp_up_limit/index.html +++ b/dev/concept_reference/ramp_up_limit/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

The definition of the ramp_up_limit parameter will trigger the creation of the Constraint on spinning upwards ramp_up. It limits the maximum increase in the unit_flow variable between two consecutive timesteps for which the unit is online.

It can be defined for unit__to_node or unit__from_node relationships, as well as their counterparts for node groups. It will then impose restrictions on the unit_flow variables that indicate flows between the two members of the relationship for which the parameter is defined. The parameter is given as a fraction of the unit_capacity parameter. When the parameter is not included, the aforementioned constraint will not be created, which is equivalent to choosing a value of 1.

For a more complete description of how ramping restrictions can be implemented, see Ramping and Reserves.

+- · SpineOpt.jl
GitHub

The definition of the ramp_up_limit parameter will trigger the creation of the Constraint on spinning upwards ramp_up. It limits the maximum increase in the unit_flow variable between two consecutive timesteps for which the unit is online.

It can be defined for unit__to_node or unit__from_node relationships, as well as their counterparts for node groups. It will then impose restrictions on the unit_flow variables that indicate flows between the two members of the relationship for which the parameter is defined. The parameter is given as a fraction of the unit_capacity parameter. When the parameter is not included, the aforementioned constraint will not be created, which is equivalent to choosing a value of 1.

For a more complete description of how ramping restrictions can be implemented, see Ramping and Reserves.

diff --git a/dev/concept_reference/report/index.html b/dev/concept_reference/report/index.html index 2892525b6d..ac4ebc1a2d 100644 --- a/dev/concept_reference/report/index.html +++ b/dev/concept_reference/report/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

A report is essentially a group of outputs from a model, that gets written into the output database as a result of running SpineOpt. Note that unless appropriate model__report and report__output relationships are defined, SpineOpt doesn't write any output!

+- · SpineOpt.jl
GitHub

A report is essentially a group of outputs from a model, that gets written into the output database as a result of running SpineOpt. Note that unless appropriate model__report and report__output relationships are defined, SpineOpt doesn't write any output!

diff --git a/dev/concept_reference/report__output/index.html b/dev/concept_reference/report__output/index.html index 36a192311d..03ba97b9b1 100644 --- a/dev/concept_reference/report__output/index.html +++ b/dev/concept_reference/report__output/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub
+- · SpineOpt.jl
GitHub
diff --git a/dev/concept_reference/representative_periods_mapping/index.html b/dev/concept_reference/representative_periods_mapping/index.html index 148fecdb40..ab4330a174 100644 --- a/dev/concept_reference/representative_periods_mapping/index.html +++ b/dev/concept_reference/representative_periods_mapping/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

Specifies the names of temporal_block objects to use as representative periods for certain time ranges. This indicates the model to define operational variables only for those representative periods, and map variables from normal periods to representative ones. The idea behind this is to reduce the size of the problem by using a reduced set of variables, when one knows that some reduced set of time periods can be representative for a larger one.

Note that only operational variables other than node_state are sensitive to this parameter. In other words, the model always create node_state variables and investment variables for all time periods, regardless of whether or not representative_periods_mapping is specified for any temporal_block.

To use representative periods in your model, do the following:

  1. Define one temporal_block for the 'normal' periods as you would do if you weren't using representative periods.
  2. Define a set of temporal_block objects, each corresponding to one representative period.
  3. Specify representative_periods_mapping for the 'normal' temporal_block as a map, from consecutive date-time values to the name of a representative temporal_block.
  4. Associate all the above temporal_block objects to elements in your model (e.g., via node__temporal_block and/or units_on__temporal_block relationships), to map their operational variables from normal periods, to the variable from the representative period.

See also Representative days with seasonal storages.

+- · SpineOpt.jl
GitHub

Specifies the names of temporal_block objects to use as representative periods for certain time ranges. This indicates the model to define operational variables only for those representative periods, and map variables from normal periods to representative ones. The idea behind this is to reduce the size of the problem by using a reduced set of variables, when one knows that some reduced set of time periods can be representative for a larger one.

Note that only operational variables other than node_state are sensitive to this parameter. In other words, the model always create node_state variables and investment variables for all time periods, regardless of whether or not representative_periods_mapping is specified for any temporal_block.

To use representative periods in your model, do the following:

  1. Define one temporal_block for the 'normal' periods as you would do if you weren't using representative periods.
  2. Define a set of temporal_block objects, each corresponding to one representative period.
  3. Specify representative_periods_mapping for the 'normal' temporal_block as a map, from consecutive date-time values to the name of a representative temporal_block.
  4. Associate all the above temporal_block objects to elements in your model (e.g., via node__temporal_block and/or units_on__temporal_block relationships), to map their operational variables from normal periods, to the variable from the representative period.

See also Representative days with seasonal storages.

diff --git a/dev/concept_reference/reserve_procurement_cost/index.html b/dev/concept_reference/reserve_procurement_cost/index.html index 7f3d205948..3827720683 100644 --- a/dev/concept_reference/reserve_procurement_cost/index.html +++ b/dev/concept_reference/reserve_procurement_cost/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

By defining the reserve_procurement_cost parameter for a specific unit__to_node or unit__from_node relationship, a cost term will be added to the objective function whenever that unit is used over the course of the operational dispatch during the current optimization window.

+- · SpineOpt.jl
GitHub

By defining the reserve_procurement_cost parameter for a specific unit__to_node or unit__from_node relationship, a cost term will be added to the objective function whenever that unit is used over the course of the operational dispatch during the current optimization window.

diff --git a/dev/concept_reference/resolution/index.html b/dev/concept_reference/resolution/index.html index a8cc589cd7..98d24ac92c 100644 --- a/dev/concept_reference/resolution/index.html +++ b/dev/concept_reference/resolution/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

This parameter specifies the resolution of the temporal block, or in other words: the length of the timesteps used in the optimization run. Generally speaking, variables and constraints are generated for each timestep of an optimization. For example, the nodal balance constraint must hold for each timestep.

An array of duration values can be used to have a resolution that varies with time itself. It can for example be used when uncertainty in one of the inputs rises as the optimization moves away from the model start. Think of a forecast of for instance wind power generation, which might be available in quarter hourly detail for one day in the future, and in hourly detail for the next two days. It is possible to take a quarter hourly resolution for the full horizon of three days. However, by lowering the temporal resolution after the first day, the computational burden is lowered substantially.

+- · SpineOpt.jl
GitHub

This parameter specifies the resolution of the temporal block, or in other words: the length of the timesteps used in the optimization run. Generally speaking, variables and constraints are generated for each timestep of an optimization. For example, the nodal balance constraint must hold for each timestep.

An array of duration values can be used to have a resolution that varies with time itself. It can for example be used when uncertainty in one of the inputs rises as the optimization moves away from the model start. Think of a forecast of for instance wind power generation, which might be available in quarter hourly detail for one day in the future, and in hourly detail for the next two days. It is possible to take a quarter hourly resolution for the full horizon of three days. However, by lowering the temporal resolution after the first day, the computational burden is lowered substantially.

diff --git a/dev/concept_reference/right_hand_side/index.html b/dev/concept_reference/right_hand_side/index.html index 4224c8761a..b529ac1a8f 100644 --- a/dev/concept_reference/right_hand_side/index.html +++ b/dev/concept_reference/right_hand_side/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub
+- · SpineOpt.jl
GitHub
diff --git a/dev/concept_reference/roll_forward/index.html b/dev/concept_reference/roll_forward/index.html index ddd28f12ec..79546bafc3 100644 --- a/dev/concept_reference/roll_forward/index.html +++ b/dev/concept_reference/roll_forward/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

This parameter defines how much the optimization window rolls forward in a rolling horizon optimization and should be expressed as a duration. In a rolling horizon optimization, the model is split in windows that are optimized iteratively; roll_forward indicates how much the window should roll forward after each iteration. Overlap between consecutive optimization windows is possible. In the practical approaches presented in Temporal Framework, the rolling window optimization will be explained in more detail. The default value of this parameter is the entire model time horizon, which leads to a single optimization for the entire time horizon.

In case you want your model to roll a different amount of time after each iteration, you can specify an array of durations for roll_forward. Position ith in this array indicates how much the model should roll after iteration i. This allows you to perform a rolling horizon optimization over a selection of disjoint representative periods as if they were contiguous.

+- · SpineOpt.jl
GitHub

This parameter defines how much the optimization window rolls forward in a rolling horizon optimization and should be expressed as a duration. In a rolling horizon optimization, the model is split in windows that are optimized iteratively; roll_forward indicates how much the window should roll forward after each iteration. Overlap between consecutive optimization windows is possible. In the practical approaches presented in Temporal Framework, the rolling window optimization will be explained in more detail. The default value of this parameter is the entire model time horizon, which leads to a single optimization for the entire time horizon.

In case you want your model to roll a different amount of time after each iteration, you can specify an array of durations for roll_forward. Position ith in this array indicates how much the model should roll after iteration i. This allows you to perform a rolling horizon optimization over a selection of disjoint representative periods as if they were contiguous.

diff --git a/dev/concept_reference/shut_down_cost/index.html b/dev/concept_reference/shut_down_cost/index.html index 76273b1ac5..7b017d39f8 100644 --- a/dev/concept_reference/shut_down_cost/index.html +++ b/dev/concept_reference/shut_down_cost/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

By defining the shut_down_cost parameter for a specific unit, a cost term will be added to the objective function whenever this unit shuts down over the course of its operational dispatch during the current optimization window.

+- · SpineOpt.jl
GitHub

By defining the shut_down_cost parameter for a specific unit, a cost term will be added to the objective function whenever this unit shuts down over the course of its operational dispatch during the current optimization window.

diff --git a/dev/concept_reference/start_up_cost/index.html b/dev/concept_reference/start_up_cost/index.html index 84719b6196..dc564ee816 100644 --- a/dev/concept_reference/start_up_cost/index.html +++ b/dev/concept_reference/start_up_cost/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

By defining the start_up_cost parameter for a specific unit, a cost term will be added to the objective function whenever this unit starts up over the course of its operational dispatch during the current optimization window.

+- · SpineOpt.jl
GitHub

By defining the start_up_cost parameter for a specific unit, a cost term will be added to the objective function whenever this unit starts up over the course of its operational dispatch during the current optimization window.

diff --git a/dev/concept_reference/state_coeff/index.html b/dev/concept_reference/state_coeff/index.html index fec4413a25..3c21af711a 100644 --- a/dev/concept_reference/state_coeff/index.html +++ b/dev/concept_reference/state_coeff/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

The state_coeff parameter acts as a coefficient for the node_state variable in the node injection constraint. Essentially, it tells how the node_state variable should be treated in relation to the commodity flows and demand, and can be used for e.g. scaling or unit conversions. For most use-cases a state_coeff parameter value of 1.0 should suffice, e.g. having a MWh storage connected to MW flows in a model with hour as the basic unit of time.

Note that in order for the state_coeff parameter to have an impact, the node must first have a node_state variable to begin with, defined using the has_state parameter. By default, the state_coeff is set to zero as a precaution, so that the user always has to set its value explicitly for it to have an impact on the model.

+- · SpineOpt.jl
GitHub

The state_coeff parameter acts as a coefficient for the node_state variable in the node injection constraint. Essentially, it tells how the node_state variable should be treated in relation to the commodity flows and demand, and can be used for e.g. scaling or unit conversions. For most use-cases a state_coeff parameter value of 1.0 should suffice, e.g. having a MWh storage connected to MW flows in a model with hour as the basic unit of time.

Note that in order for the state_coeff parameter to have an impact, the node must first have a node_state variable to begin with, defined using the has_state parameter. By default, the state_coeff is set to zero as a precaution, so that the user always has to set its value explicitly for it to have an impact on the model.

diff --git a/dev/concept_reference/stochastic_scenario/index.html b/dev/concept_reference/stochastic_scenario/index.html index d3585253bc..f596397984 100644 --- a/dev/concept_reference/stochastic_scenario/index.html +++ b/dev/concept_reference/stochastic_scenario/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

Essentially, a stochastic_scenario is a label for an alternative period of time, describing one possibility of what might come to pass. They are the basic building blocks of the scenario-based Stochastic Framework in SpineOpt.jl, but aren't really meaningful on their own. Only when combined into a stochastic_structure using the stochastic_structure__stochastic_scenario and parent_stochastic_scenario__child_stochastic_scenario relationships, along with Parameters like the weight_relative_to_parents and stochastic_scenario_end, they become meaningful.

+- · SpineOpt.jl
GitHub

Essentially, a stochastic_scenario is a label for an alternative period of time, describing one possibility of what might come to pass. They are the basic building blocks of the scenario-based Stochastic Framework in SpineOpt.jl, but aren't really meaningful on their own. Only when combined into a stochastic_structure using the stochastic_structure__stochastic_scenario and parent_stochastic_scenario__child_stochastic_scenario relationships, along with Parameters like the weight_relative_to_parents and stochastic_scenario_end, they become meaningful.

diff --git a/dev/concept_reference/stochastic_scenario_end/index.html b/dev/concept_reference/stochastic_scenario_end/index.html index 5e0b1e9f5b..05d9796069 100644 --- a/dev/concept_reference/stochastic_scenario_end/index.html +++ b/dev/concept_reference/stochastic_scenario_end/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

The stochastic_scenario_end is a Duration-type parameter, defining when a stochastic_scenario ends relative to the start of the current optimization. As it is a parameter for the stochastic_structure__stochastic_scenario relationship, different stochastic_structures can have different values for the same stochastic_scenario, making it possible to define slightly different stochastic_structures using the same stochastic_scenarios. See the Stochastic Framework section for more information about how different stochastic_structures interact in SpineOpt.jl.

When a stochastic_scenario ends at the point in time defined by the stochastic_scenario_end parameter, it spawns its children according to the parent_stochastic_scenario__child_stochastic_scenario relationship. Note that the children will be inherently assumed to belong to the same stochastic_structure their parent belonged to, even without explicit stochastic_structure__stochastic_scenario relationships! Thus, you might need to define the weight_relative_to_parents parameter for the children.

If no stochastic_scenario_end is defined, the stochastic_scenario is assumed to go on indefinitely.

+- · SpineOpt.jl
GitHub

The stochastic_scenario_end is a Duration-type parameter, defining when a stochastic_scenario ends relative to the start of the current optimization. As it is a parameter for the stochastic_structure__stochastic_scenario relationship, different stochastic_structures can have different values for the same stochastic_scenario, making it possible to define slightly different stochastic_structures using the same stochastic_scenarios. See the Stochastic Framework section for more information about how different stochastic_structures interact in SpineOpt.jl.

When a stochastic_scenario ends at the point in time defined by the stochastic_scenario_end parameter, it spawns its children according to the parent_stochastic_scenario__child_stochastic_scenario relationship. Note that the children will be inherently assumed to belong to the same stochastic_structure their parent belonged to, even without explicit stochastic_structure__stochastic_scenario relationships! Thus, you might need to define the weight_relative_to_parents parameter for the children.

If no stochastic_scenario_end is defined, the stochastic_scenario is assumed to go on indefinitely.

diff --git a/dev/concept_reference/stochastic_structure/index.html b/dev/concept_reference/stochastic_structure/index.html index 524ad2df8b..403c393076 100644 --- a/dev/concept_reference/stochastic_structure/index.html +++ b/dev/concept_reference/stochastic_structure/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

The stochastic_structure is the key component of the scenario-based Stochastic Framework in SpineOpt.jl, and essentially represents a group of stochastic_scenarios with set Parameters. The stochastic_structure__stochastic_scenario relationship defines which stochastic_scenarios are included in which stochastic_structures, and the weight_relative_to_parents and stochastic_scenario_end Parameters define the exact shape and impact of the stochastic_structure, along with the parent_stochastic_scenario__child_stochastic_scenario relationship.

The main reason as to why stochastic_structures are so important is, that they act as handles connecting the Stochastic Framework to the modelled system. This is handled using the Structural relationship classes e.g. node__stochastic_structure, which define the stochastic_structure applied to each object describing the modelled system. Connecting each system object to the appropriate stochastic_structure individually can be a bit bothersome at times, so there are also a number of convenience Meta relationship classes like the model__default_stochastic_structure, which allow setting model-wide defaults to be used whenever specific definitions are missing.

+- · SpineOpt.jl
GitHub

The stochastic_structure is the key component of the scenario-based Stochastic Framework in SpineOpt.jl, and essentially represents a group of stochastic_scenarios with set Parameters. The stochastic_structure__stochastic_scenario relationship defines which stochastic_scenarios are included in which stochastic_structures, and the weight_relative_to_parents and stochastic_scenario_end Parameters define the exact shape and impact of the stochastic_structure, along with the parent_stochastic_scenario__child_stochastic_scenario relationship.

The main reason as to why stochastic_structures are so important is, that they act as handles connecting the Stochastic Framework to the modelled system. This is handled using the Structural relationship classes e.g. node__stochastic_structure, which define the stochastic_structure applied to each object describing the modelled system. Connecting each system object to the appropriate stochastic_structure individually can be a bit bothersome at times, so there are also a number of convenience Meta relationship classes like the model__default_stochastic_structure, which allow setting model-wide defaults to be used whenever specific definitions are missing.

diff --git a/dev/concept_reference/stochastic_structure__stochastic_scenario/index.html b/dev/concept_reference/stochastic_structure__stochastic_scenario/index.html index b3330ee45d..823a0b8be1 100644 --- a/dev/concept_reference/stochastic_structure__stochastic_scenario/index.html +++ b/dev/concept_reference/stochastic_structure__stochastic_scenario/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

The stochastic_structure__stochastic_scenario relationship defines which stochastic_scenarios are included in which stochastic_structure, as well as holds the stochastic_scenario_end and weight_relative_to_parents Parameters defining how the stochastic_structure interacts with the Temporal Framework and the Objective function. Along with parent_stochastic_scenario__child_stochastic_scenario, this relationship is used to define the exact properties of each stochastic_structure, which are then applied to the objects describing the modelled system according to the Structural relationship classes, like the node__stochastic_structure relationship.

+- · SpineOpt.jl
GitHub

The stochastic_structure__stochastic_scenario relationship defines which stochastic_scenarios are included in which stochastic_structure, as well as holds the stochastic_scenario_end and weight_relative_to_parents Parameters defining how the stochastic_structure interacts with the Temporal Framework and the Objective function. Along with parent_stochastic_scenario__child_stochastic_scenario, this relationship is used to define the exact properties of each stochastic_structure, which are then applied to the objects describing the modelled system according to the Structural relationship classes, like the node__stochastic_structure relationship.

diff --git a/dev/concept_reference/storage_investment_cost/index.html b/dev/concept_reference/storage_investment_cost/index.html index 7f495cd74f..a6e683ea93 100644 --- a/dev/concept_reference/storage_investment_cost/index.html +++ b/dev/concept_reference/storage_investment_cost/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

By defining the storage_investment_cost parameter for a specific node, a cost term will be added to the objective function whenever a storage investment is made during the current optimization window.

+- · SpineOpt.jl
GitHub

By defining the storage_investment_cost parameter for a specific node, a cost term will be added to the objective function whenever a storage investment is made during the current optimization window.

diff --git a/dev/concept_reference/storage_investment_lifetime/index.html b/dev/concept_reference/storage_investment_lifetime/index.html index bd3cbf8433..0b604074bc 100644 --- a/dev/concept_reference/storage_investment_lifetime/index.html +++ b/dev/concept_reference/storage_investment_lifetime/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

Duration parameter that determines the minimum duration of storage investment decisions. Once a storage has been invested-in, it must remain invested-in for storage_investment_lifetime. Note that storage_investment_lifetime is a dynamic parameter that will impact the amount of solution history that must remain available to the optimisation in each step - this may impact performance.

See also Investment Optimization and candidate_storages

+- · SpineOpt.jl
GitHub

Duration parameter that determines the minimum duration of storage investment decisions. Once a storage has been invested-in, it must remain invested-in for storage_investment_lifetime. Note that storage_investment_lifetime is a dynamic parameter that will impact the amount of solution history that must remain available to the optimisation in each step - this may impact performance.

See also Investment Optimization and candidate_storages

diff --git a/dev/concept_reference/storage_investment_variable_type/index.html b/dev/concept_reference/storage_investment_variable_type/index.html index c242786027..52c3fd4176 100644 --- a/dev/concept_reference/storage_investment_variable_type/index.html +++ b/dev/concept_reference/storage_investment_variable_type/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

Within an investments problem storage_investment_variable_type determines the storage investment decision variable type. Since a node's node_state will be limited to the product of the investment variable and the corresponding node_state_cap and since candidate_storages represents the upper bound of the storage investment decision variable, storage_investment_variable_type thus determines what the investment decision represents. If storage_investment_variable_type is integer or binary, then candidate_storages represents the maximum number of discrete storages that may be invested-in. If storage_investment_variable_type is continuous, candidate_storages is more analagous to a capacity with node_state_cap being analagous to a scaling parameter. For example, if storage_investment_variable_type = integer, candidate_storages = 4 and node_state_cap = 1000 MWh, then the investment decision is how many 1000h MW storages to build. If storage_investment_variable_type = continuous, candidate_storages = 1000 and node_state_cap = 1 MWh, then the investment decision is how much storage capacity to build. Finally, if storage_investment_variable_type = integer, candidate_storages = 10 and node_state_cap = 100 MWh, then the investment decision is how many 100MWh storage blocks to build.

See also Investment Optimization and candidate_storages.

+- · SpineOpt.jl
GitHub

Within an investments problem storage_investment_variable_type determines the storage investment decision variable type. Since a node's node_state will be limited to the product of the investment variable and the corresponding node_state_cap and since candidate_storages represents the upper bound of the storage investment decision variable, storage_investment_variable_type thus determines what the investment decision represents. If storage_investment_variable_type is integer or binary, then candidate_storages represents the maximum number of discrete storages that may be invested-in. If storage_investment_variable_type is continuous, candidate_storages is more analagous to a capacity with node_state_cap being analagous to a scaling parameter. For example, if storage_investment_variable_type = integer, candidate_storages = 4 and node_state_cap = 1000 MWh, then the investment decision is how many 1000h MW storages to build. If storage_investment_variable_type = continuous, candidate_storages = 1000 and node_state_cap = 1 MWh, then the investment decision is how much storage capacity to build. Finally, if storage_investment_variable_type = integer, candidate_storages = 10 and node_state_cap = 100 MWh, then the investment decision is how many 100MWh storage blocks to build.

See also Investment Optimization and candidate_storages.

diff --git a/dev/concept_reference/storages_invested_avaiable_coefficient/index.html b/dev/concept_reference/storages_invested_avaiable_coefficient/index.html index 0c2fc71103..7b188c6d62 100644 --- a/dev/concept_reference/storages_invested_avaiable_coefficient/index.html +++ b/dev/concept_reference/storages_invested_avaiable_coefficient/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub
+- · SpineOpt.jl
GitHub
diff --git a/dev/concept_reference/storages_invested_big_m_mga/index.html b/dev/concept_reference/storages_invested_big_m_mga/index.html index c32f7bde07..0b405651ff 100644 --- a/dev/concept_reference/storages_invested_big_m_mga/index.html +++ b/dev/concept_reference/storages_invested_big_m_mga/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

The storages_invested_big_m_mga parameter is used in combination with the MGA algorithm (see mga-advanced). It defines an upper bound on the maximum difference between any MGA iteration. The big M should be chosen always sufficiently large. (Typically, a value equivalent to candidate_storages could suffice.)

+- · SpineOpt.jl
GitHub

The storages_invested_big_m_mga parameter is used in combination with the MGA algorithm (see mga-advanced). It defines an upper bound on the maximum difference between any MGA iteration. The big M should be chosen always sufficiently large. (Typically, a value equivalent to candidate_storages could suffice.)

diff --git a/dev/concept_reference/storages_invested_coefficient/index.html b/dev/concept_reference/storages_invested_coefficient/index.html index 6981e55820..3ad3417eb9 100644 --- a/dev/concept_reference/storages_invested_coefficient/index.html +++ b/dev/concept_reference/storages_invested_coefficient/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub
+- · SpineOpt.jl
GitHub
diff --git a/dev/concept_reference/storages_invested_mga/index.html b/dev/concept_reference/storages_invested_mga/index.html index 4e40520373..28d8b3c20a 100644 --- a/dev/concept_reference/storages_invested_mga/index.html +++ b/dev/concept_reference/storages_invested_mga/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

The storages_invested_mga is a boolean parameter that can be used in combination with the MGA algorithm (see mga-advanced). As soon as the value of storages_invested_mga is set to true, investment decisions in this connection, or group of storages, will be included in the MGA algorithm.

+- · SpineOpt.jl
GitHub

The storages_invested_mga is a boolean parameter that can be used in combination with the MGA algorithm (see mga-advanced). As soon as the value of storages_invested_mga is set to true, investment decisions in this connection, or group of storages, will be included in the MGA algorithm.

diff --git a/dev/concept_reference/tax_in_unit_flow/index.html b/dev/concept_reference/tax_in_unit_flow/index.html index dc49616aa8..b8f718a5d8 100644 --- a/dev/concept_reference/tax_in_unit_flow/index.html +++ b/dev/concept_reference/tax_in_unit_flow/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

By defining the tax_in_unit_flow parameter for a specific node, a cost term will be added to the objective function to account the taxes associated with all unit_flow variables with direction to_node over the course of the operational dispatch during the current optimization window.

+- · SpineOpt.jl
GitHub

By defining the tax_in_unit_flow parameter for a specific node, a cost term will be added to the objective function to account the taxes associated with all unit_flow variables with direction to_node over the course of the operational dispatch during the current optimization window.

diff --git a/dev/concept_reference/tax_net_unit_flow/index.html b/dev/concept_reference/tax_net_unit_flow/index.html index 3d4a80eccf..7f05b25808 100644 --- a/dev/concept_reference/tax_net_unit_flow/index.html +++ b/dev/concept_reference/tax_net_unit_flow/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

By defining the tax_net_unit_flow parameter for a specific node, a cost term will be added to the objective function to account the taxes associated with the net total of all unit_flow variables with the direction to_node for this specific node minus all unit_flow variables with direction from_node.

+- · SpineOpt.jl
GitHub

By defining the tax_net_unit_flow parameter for a specific node, a cost term will be added to the objective function to account the taxes associated with the net total of all unit_flow variables with the direction to_node for this specific node minus all unit_flow variables with direction from_node.

diff --git a/dev/concept_reference/tax_out_unit_flow/index.html b/dev/concept_reference/tax_out_unit_flow/index.html index 68272de85a..56c7317701 100644 --- a/dev/concept_reference/tax_out_unit_flow/index.html +++ b/dev/concept_reference/tax_out_unit_flow/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

By defining the tax_out_unit_flow parameter for a specific node, a cost term will be added to the objective function to account the taxes associated with all unit_flow variables with direction from_node over the course of the operational dispatch during the current optimization window.

+- · SpineOpt.jl
GitHub

By defining the tax_out_unit_flow parameter for a specific node, a cost term will be added to the objective function to account the taxes associated with all unit_flow variables with direction from_node over the course of the operational dispatch during the current optimization window.

diff --git a/dev/concept_reference/temporal_block/index.html b/dev/concept_reference/temporal_block/index.html index d36dcb7f32..db2a75d64a 100644 --- a/dev/concept_reference/temporal_block/index.html +++ b/dev/concept_reference/temporal_block/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

A temporal block defines the temporal properties of the optimization that is to be solved in the current window. It is the key building block of the Temporal Framework. Most importantly, it holds the necessary information about the resolution and horizon of the optimization. A single model can have multiple temporal blocks, which is one of the main sources of temporal flexibility in Spine: by linking different parts of the model to different temporal blocks, a single model can contain aspects that are solved with different temporal resolutions or time horizons.

+- · SpineOpt.jl
GitHub

A temporal block defines the temporal properties of the optimization that is to be solved in the current window. It is the key building block of the Temporal Framework. Most importantly, it holds the necessary information about the resolution and horizon of the optimization. A single model can have multiple temporal blocks, which is one of the main sources of temporal flexibility in Spine: by linking different parts of the model to different temporal blocks, a single model can contain aspects that are solved with different temporal resolutions or time horizons.

diff --git a/dev/concept_reference/the_basics/index.html b/dev/concept_reference/the_basics/index.html index 810f80b339..fe09e4a433 100644 --- a/dev/concept_reference/the_basics/index.html +++ b/dev/concept_reference/the_basics/index.html @@ -1,2 +1,2 @@ -Basics of the model structure · SpineOpt.jl
GitHub

Basics of the model structure

In SpineOpt.jl, the model structure is generated based on the input data, allowing it to be used for a multitude of different problems. Here, we aim to provide you with a basic understanding of the SpineOpt.jl model and data structure, while the Object Classes, Relationship Classes, Parameters, and Parameter Value Lists sections provide more in-depth explanations of each concept.

Introduction to object classes

Essentially, Object Classes represents different types of objects or entities that make up the model. For example, every power plant in the model is represented as an object of the object class unit, every power line as an object of the object class connection, and so forth. In order to add any new entity to a model, a new object has to be added to desired object class in the input data.

Each object class has a very specific purpose in SpineOpt.jl, so understanding their differences is key. The Object Classes can be roughly divided into three distinctive groups, namely Systemic object classes, Structural object classes, and Meta object classes.

Systemic object classes

As the name implies, system Object Classes are used to describe the system to be modelled. Essentially, they define what you want to model. These include:

  • commodity represents different goods to be generated, consumed, transported, etc.
  • connection handles the transfer of commodities between nodes.
  • node ensures the balance of the commodity flows, and can be used to store commodities as well.
  • unit handles the generation and consumption of commodities.

Structural object classes

Structural Object Classes are used to define the temporal and stochastic structure of the modelled problem, as well as custom User Constraints. Unlike the above system Object Classes, the structural Object Classes are more about how you want to model, instead of strictly what you want to model. These include:

Meta object classes

Meta Object Classes are used for defining things on the level of models or above, like model output and even multiple models for problem decompositions. These include:

  • model represents an individual model, grouping together all the things relevant for itself.
  • output defines which Variables are output from the model.
  • report groups together multiple output objects.

Introduction to relationship classes

While Object Classes define all the objects or entities that make up a model, Relationship Classes define how those entities are related to each other. Thus, Relationship Classes hold no meaning on their own, and always include at least one object class.

Similar to Object Classes, each relationship class has a very specific purpose in SpineOpt.jl, and understanding the purpose of each relationship class is paramount. The Relationship Classes can be roughly divided into Systemic relationship classes, Structural relationship classes, and Meta relationship classes, again similar to Object Classes.

Systemic relationship classes

Systemic Relationship Classes define how Systemic object classes are related to each other, thus helping define the system to be modelled. Most of these relationships deal with which units and connections interact with which nodes, and how those interactions work. This essentially defines the possible commodity flows to be modelled. Systemic Relationship Classes include:

Structural relationship classes

Structural Relationship Classes primarily relate Structural object classes to Systemic object classes, defining what structures the individual parts of the system use. These are mostly used to determine the temporal and stochastic structures to be used in different parts of the modelled system, or custom User Constraints.

SpineOpt.jl has a very flexible temporal and stochastic structure, explained in detail in the Temporal Framework and Stochastic Framework sections of the documentation. Unfortunately, this flexibility requires quite a few different structural Relationship Classes, the most important of which are the following basic structural Relationship Classes:

Furthermore, there are also a number of advanced structural Relationship Classes, which are only necessary when using some of the optional features of SpineOpt.jl. For Investment Optimization, the following relationships control the stochastic and temporal structures of the investment variables:

For User Constraints, which are essentially generic data-driven custom constraints, the following relationships are used to control which variables are included and with what coefficients:

Meta relationship classes

Meta Relationship Classes are used for defining model-level settings, like which temporal blocks or stochastic structures are active, and what the model output is. These include:

Introduction to parameters

While the primary function of Object Classes and Relationship Classes is to define the system to be modelled and it's structure, Parameters exist to constrain them. Every parameter is attributed to at least one object class or relationship class, but some appear in many classes whenever they serve a similar purpose.

Parameters accept different types of values depending on their purpose, e.g. whether they act as a flag for some specific functionality or appear as a coefficient in Constraints, so understanding each parameter is key. Most coefficient-type Parameters accept constant, time series, and even stochastic time series form input, but there are some exceptions. Most flag-type Parameters, on the other hand, have a restricted list of acceptable values defined by their Parameter Value Lists.

The existence of some Constraints is controlled based on if the relevant Parameters are defined. As a rule-of-thumb, a constraint only gets generated if at least one of the Parameters appearing in it is defined, but one should refer to the appropriate Constraints and Parameters sections when in doubt.

Introduction to groups of objects

Groups of objects are used within SpineOpt for different purposes. To create a group of objects, simply right-click the corresponding Object Class in the Spine Toolbox database editor and select Add object group. Groups are essentially special objects, that act as a single handle for all of its members.

On the one hand, groups can be used in order to impose constraints on the aggregation of a variable, e.g. on the sum of multiple unit_flow variables. Constraints based on parameters associated with the unit__node__node, unit__to_node, unit__from_node, connection__node__node, connection__to_node, connection__from_node can generally be used for this kind of flow aggregation by defining the parameters on groups of objects, typically node groups. (with the exception of variable fixing parameters, e.g. fix_unit_flow, fix_connection_flow etc.). See for instance constraint_unit_flow_capacity.

On the other hand, a node group can be used to for PTDF based powerflows. Here a node group is used to enforce a nodal balance on system level, while suppressing the node balances at individual nodes. See also balance_type and the node balance constraint.

+Basics of the model structure · SpineOpt.jl
GitHub

Basics of the model structure

In SpineOpt.jl, the model structure is generated based on the input data, allowing it to be used for a multitude of different problems. Here, we aim to provide you with a basic understanding of the SpineOpt.jl model and data structure, while the Object Classes, Relationship Classes, Parameters, and Parameter Value Lists sections provide more in-depth explanations of each concept.

Introduction to object classes

Essentially, Object Classes represents different types of objects or entities that make up the model. For example, every power plant in the model is represented as an object of the object class unit, every power line as an object of the object class connection, and so forth. In order to add any new entity to a model, a new object has to be added to desired object class in the input data.

Each object class has a very specific purpose in SpineOpt.jl, so understanding their differences is key. The Object Classes can be roughly divided into three distinctive groups, namely Systemic object classes, Structural object classes, and Meta object classes.

Systemic object classes

As the name implies, system Object Classes are used to describe the system to be modelled. Essentially, they define what you want to model. These include:

  • commodity represents different goods to be generated, consumed, transported, etc.
  • connection handles the transfer of commodities between nodes.
  • node ensures the balance of the commodity flows, and can be used to store commodities as well.
  • unit handles the generation and consumption of commodities.

Structural object classes

Structural Object Classes are used to define the temporal and stochastic structure of the modelled problem, as well as custom User Constraints. Unlike the above system Object Classes, the structural Object Classes are more about how you want to model, instead of strictly what you want to model. These include:

Meta object classes

Meta Object Classes are used for defining things on the level of models or above, like model output and even multiple models for problem decompositions. These include:

  • model represents an individual model, grouping together all the things relevant for itself.
  • output defines which Variables are output from the model.
  • report groups together multiple output objects.

Introduction to relationship classes

While Object Classes define all the objects or entities that make up a model, Relationship Classes define how those entities are related to each other. Thus, Relationship Classes hold no meaning on their own, and always include at least one object class.

Similar to Object Classes, each relationship class has a very specific purpose in SpineOpt.jl, and understanding the purpose of each relationship class is paramount. The Relationship Classes can be roughly divided into Systemic relationship classes, Structural relationship classes, and Meta relationship classes, again similar to Object Classes.

Systemic relationship classes

Systemic Relationship Classes define how Systemic object classes are related to each other, thus helping define the system to be modelled. Most of these relationships deal with which units and connections interact with which nodes, and how those interactions work. This essentially defines the possible commodity flows to be modelled. Systemic Relationship Classes include:

Structural relationship classes

Structural Relationship Classes primarily relate Structural object classes to Systemic object classes, defining what structures the individual parts of the system use. These are mostly used to determine the temporal and stochastic structures to be used in different parts of the modelled system, or custom User Constraints.

SpineOpt.jl has a very flexible temporal and stochastic structure, explained in detail in the Temporal Framework and Stochastic Framework sections of the documentation. Unfortunately, this flexibility requires quite a few different structural Relationship Classes, the most important of which are the following basic structural Relationship Classes:

Furthermore, there are also a number of advanced structural Relationship Classes, which are only necessary when using some of the optional features of SpineOpt.jl. For Investment Optimization, the following relationships control the stochastic and temporal structures of the investment variables:

For User Constraints, which are essentially generic data-driven custom constraints, the following relationships are used to control which variables are included and with what coefficients:

Meta relationship classes

Meta Relationship Classes are used for defining model-level settings, like which temporal blocks or stochastic structures are active, and what the model output is. These include:

Introduction to parameters

While the primary function of Object Classes and Relationship Classes is to define the system to be modelled and it's structure, Parameters exist to constrain them. Every parameter is attributed to at least one object class or relationship class, but some appear in many classes whenever they serve a similar purpose.

Parameters accept different types of values depending on their purpose, e.g. whether they act as a flag for some specific functionality or appear as a coefficient in Constraints, so understanding each parameter is key. Most coefficient-type Parameters accept constant, time series, and even stochastic time series form input, but there are some exceptions. Most flag-type Parameters, on the other hand, have a restricted list of acceptable values defined by their Parameter Value Lists.

The existence of some Constraints is controlled based on if the relevant Parameters are defined. As a rule-of-thumb, a constraint only gets generated if at least one of the Parameters appearing in it is defined, but one should refer to the appropriate Constraints and Parameters sections when in doubt.

Introduction to groups of objects

Groups of objects are used within SpineOpt for different purposes. To create a group of objects, simply right-click the corresponding Object Class in the Spine Toolbox database editor and select Add object group. Groups are essentially special objects, that act as a single handle for all of its members.

On the one hand, groups can be used in order to impose constraints on the aggregation of a variable, e.g. on the sum of multiple unit_flow variables. Constraints based on parameters associated with the unit__node__node, unit__to_node, unit__from_node, connection__node__node, connection__to_node, connection__from_node can generally be used for this kind of flow aggregation by defining the parameters on groups of objects, typically node groups. (with the exception of variable fixing parameters, e.g. fix_unit_flow, fix_connection_flow etc.). See for instance constraint_unit_flow_capacity.

On the other hand, a node group can be used to for PTDF based powerflows. Here a node group is used to enforce a nodal balance on system level, while suppressing the node balances at individual nodes. See also balance_type and the node balance constraint.

diff --git a/dev/concept_reference/unit/index.html b/dev/concept_reference/unit/index.html index ba3d41d608..359c0b2352 100644 --- a/dev/concept_reference/unit/index.html +++ b/dev/concept_reference/unit/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

A unit represents an energy conversion process, where energy of one commodity can be converted into energy of another commodity. For example, a gas turbine, a power plant, or even a load, can be modelled using a unit.

A unit always takes energy from one or more nodes, and releases energy to one or more (possibly the same) nodes. The former are specificed through the unit__from_node relationship, and the latter through unit__to_node. Every unit has a temporal and stochastic structures given by the units_on__temporal_block and [units_on__stochastic_structure] relationships. The model will generate unit_flow variables for every combination of unit, node, direction (from node or to node), time slice, and stochastic scenario, according to the above relationships.

The operation of the unit is specified through a number of parameter values. For example, the capacity of the unit, as the maximum amount of energy that can enter or leave it, is given by unit_capacity. The conversion ratio of input to output can be specified using any of fix_ratio_out_in_unit_flow, max_ratio_out_in_unit_flow, and min_ratio_out_in_unit_flow. The variable operating cost is given by vom_cost.

+- · SpineOpt.jl
GitHub

A unit represents an energy conversion process, where energy of one commodity can be converted into energy of another commodity. For example, a gas turbine, a power plant, or even a load, can be modelled using a unit.

A unit always takes energy from one or more nodes, and releases energy to one or more (possibly the same) nodes. The former are specificed through the unit__from_node relationship, and the latter through unit__to_node. Every unit has a temporal and stochastic structures given by the units_on__temporal_block and [units_on__stochastic_structure] relationships. The model will generate unit_flow variables for every combination of unit, node, direction (from node or to node), time slice, and stochastic scenario, according to the above relationships.

The operation of the unit is specified through a number of parameter values. For example, the capacity of the unit, as the maximum amount of energy that can enter or leave it, is given by unit_capacity. The conversion ratio of input to output can be specified using any of fix_ratio_out_in_unit_flow, max_ratio_out_in_unit_flow, and min_ratio_out_in_unit_flow. The variable operating cost is given by vom_cost.

diff --git a/dev/concept_reference/unit__commodity/index.html b/dev/concept_reference/unit__commodity/index.html index 8ec54eb95a..b22f1465e4 100644 --- a/dev/concept_reference/unit__commodity/index.html +++ b/dev/concept_reference/unit__commodity/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

To impose a limit on the cumulative amount of commodity flows, the max_cum_in_unit_flow_bound can be imposed on a unit__commodity relationship. This can be very helpful, e.g. if a certain amount of emissions should not be surpased throughout the optimization.

Note that, next to the unit__commodity relationship, also the nodes connected to the units need to be associated with their corresponding commodities, see node__commodity.

+- · SpineOpt.jl
GitHub

To impose a limit on the cumulative amount of commodity flows, the max_cum_in_unit_flow_bound can be imposed on a unit__commodity relationship. This can be very helpful, e.g. if a certain amount of emissions should not be surpased throughout the optimization.

Note that, next to the unit__commodity relationship, also the nodes connected to the units need to be associated with their corresponding commodities, see node__commodity.

diff --git a/dev/concept_reference/unit__from_node/index.html b/dev/concept_reference/unit__from_node/index.html index dbf79ccd42..2900a6508a 100644 --- a/dev/concept_reference/unit__from_node/index.html +++ b/dev/concept_reference/unit__from_node/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

The unit__to_node and unit__from_node unit relationships are core elements of SpineOpt. For each unit__to_node or unit__from_node, a unit_flow variable is automatically added to the model, i.e. a commodity flow of a unit to or from a specific node, respectively.

Various parameters can be defined on the unit__from_node relationship, in order to constrain the associated unit flows. In most cases a unit_capacity will be defined for an upper bound on the commodity flows. Apart from that, ramping abilities of a unit can be defined. For further details on ramps see Ramping and Reserves.

To associate costs with a certain commodity flows, cost terms, such as fuel_costs and vom_costs, can be included for the unit__from_node relationship.

It is important to note, that the parameters associated with the unit__from_node can be defined either for a specific node, or for a group of nodes. Grouping nodes for the described parameters will result in an aggregation of the unit flows for the triggered constraint, e.g. the definition of the unit_capacity on a group of nodes will result in an upper bound on the sum of all individual unit_flows.

+- · SpineOpt.jl
GitHub

The unit__to_node and unit__from_node unit relationships are core elements of SpineOpt. For each unit__to_node or unit__from_node, a unit_flow variable is automatically added to the model, i.e. a commodity flow of a unit to or from a specific node, respectively.

Various parameters can be defined on the unit__from_node relationship, in order to constrain the associated unit flows. In most cases a unit_capacity will be defined for an upper bound on the commodity flows. Apart from that, ramping abilities of a unit can be defined. For further details on ramps see Ramping and Reserves.

To associate costs with a certain commodity flows, cost terms, such as fuel_costs and vom_costs, can be included for the unit__from_node relationship.

It is important to note, that the parameters associated with the unit__from_node can be defined either for a specific node, or for a group of nodes. Grouping nodes for the described parameters will result in an aggregation of the unit flows for the triggered constraint, e.g. the definition of the unit_capacity on a group of nodes will result in an upper bound on the sum of all individual unit_flows.

diff --git a/dev/concept_reference/unit__from_node__unit_constraint/index.html b/dev/concept_reference/unit__from_node__unit_constraint/index.html index 2e012060fd..b0ba410663 100644 --- a/dev/concept_reference/unit__from_node__unit_constraint/index.html +++ b/dev/concept_reference/unit__from_node__unit_constraint/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

unit__from_node__user_constraint is a three-dimensional relationship between a unit, a node and a user_constraint. The relationship specifies that the unit_flow variable to the specified unit from the specified node is involved in the specified user_constraint. Parameters on this relationship generally apply to this specific unit_flow variable. For example the parameter unit_flow_coefficient defined on unit__from_node__user_constraint represents the coefficient on the specific unit_flow variable in the specified user_constraint

+- · SpineOpt.jl
GitHub

unit__from_node__user_constraint is a three-dimensional relationship between a unit, a node and a user_constraint. The relationship specifies that the unit_flow variable to the specified unit from the specified node is involved in the specified user_constraint. Parameters on this relationship generally apply to this specific unit_flow variable. For example the parameter unit_flow_coefficient defined on unit__from_node__user_constraint represents the coefficient on the specific unit_flow variable in the specified user_constraint

diff --git a/dev/concept_reference/unit__investment_stochastic_structure/index.html b/dev/concept_reference/unit__investment_stochastic_structure/index.html index 248aeae33c..30cf4bb928 100644 --- a/dev/concept_reference/unit__investment_stochastic_structure/index.html +++ b/dev/concept_reference/unit__investment_stochastic_structure/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub
+- · SpineOpt.jl
GitHub
diff --git a/dev/concept_reference/unit__investment_temporal_block/index.html b/dev/concept_reference/unit__investment_temporal_block/index.html index 60520c67a4..877e0c8830 100644 --- a/dev/concept_reference/unit__investment_temporal_block/index.html +++ b/dev/concept_reference/unit__investment_temporal_block/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

unit__investment_temporal_block is a two-dimensional relationship between a unit and a temporal_block. This relationship defines the temporal resolution and scope of a unit's investment decision. Note that in a decomposed investments problem with two model objects, one for the master problem model and another for the operations problem model, the link to the specific model is made indirectly through the model__temporal_block relationship. If a model__default_investment_temporal_block is specified and no unit__investment_temporal_block relationship is specified, the model__default_investment_temporal_block relationship will be used. Conversely if unit__investment_temporal_block is specified along with model__temporal_block, this will override model__default_investment_temporal_block for the specified unit.

See also Investment Optimization

+- · SpineOpt.jl
GitHub

unit__investment_temporal_block is a two-dimensional relationship between a unit and a temporal_block. This relationship defines the temporal resolution and scope of a unit's investment decision. Note that in a decomposed investments problem with two model objects, one for the master problem model and another for the operations problem model, the link to the specific model is made indirectly through the model__temporal_block relationship. If a model__default_investment_temporal_block is specified and no unit__investment_temporal_block relationship is specified, the model__default_investment_temporal_block relationship will be used. Conversely if unit__investment_temporal_block is specified along with model__temporal_block, this will override model__default_investment_temporal_block for the specified unit.

See also Investment Optimization

diff --git a/dev/concept_reference/unit__node__node/index.html b/dev/concept_reference/unit__node__node/index.html index 02e33ff217..b6d19cd27b 100644 --- a/dev/concept_reference/unit__node__node/index.html +++ b/dev/concept_reference/unit__node__node/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

While the relationships unit__to_node and unit__to_node take care of the automatic generation of the unit_flow variables, the unit__node__node relationships hold the information how the different commodity flows of a unit interact. Only through this relationship and the associated parameters, the topology of a unit, i.e. which intakes lead to which products etc., becomes unambiguous.

In almost all cases, at least one of the ..._ratio_... parameters will be defined, e.g. to set a fixed ratio between outgoing and incoming commodity flows of unit (see also e.g. fix_ratio_out_in_unit_flow). Note that the parameters can also be defined on a relationship between groups of objects, e.g. to force a fixed ratio between a group of nodes. In the triggered constraints, this will lead to an aggregation of the individual unit flows.

+- · SpineOpt.jl
GitHub

While the relationships unit__to_node and unit__to_node take care of the automatic generation of the unit_flow variables, the unit__node__node relationships hold the information how the different commodity flows of a unit interact. Only through this relationship and the associated parameters, the topology of a unit, i.e. which intakes lead to which products etc., becomes unambiguous.

In almost all cases, at least one of the ..._ratio_... parameters will be defined, e.g. to set a fixed ratio between outgoing and incoming commodity flows of unit (see also e.g. fix_ratio_out_in_unit_flow). Note that the parameters can also be defined on a relationship between groups of objects, e.g. to force a fixed ratio between a group of nodes. In the triggered constraints, this will lead to an aggregation of the individual unit flows.

diff --git a/dev/concept_reference/unit__to_node/index.html b/dev/concept_reference/unit__to_node/index.html index bbf5e406ef..9ba0b8ec2b 100644 --- a/dev/concept_reference/unit__to_node/index.html +++ b/dev/concept_reference/unit__to_node/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

The unit__to_node and unit__from_node unit relationships are core elements of SpineOpt. For each unit__to_node or unit__from_node, a unit_flow variable is automatically added to the model, i.e. a commodity flow of a unit to or from a specific node, respectively.

Various parameters can be defined on the unit__to_node relationship, in order to constrain the associated unit flows. In most cases a unit_capacity will be defined for an upper bound on the commodity flows. Apart from that, ramping abilities of a unit can be defined. For further details on ramps see Ramping and Reserves.

To associate costs with a certain commodity flow, cost terms, such as fuel_costs and vom_costs, can be included for the unit__to_node relationship.

It is important to note, that the parameters associated with the unit__to_node can be defined either for a specific node, or for a group of nodes. Grouping nodes for the described parameters will result in an aggregation of the unit flows for the triggered constraint, e.g. the definition of the unit_capacity on a group of nodes will result in an upper bound on the sum of all individual unit_flows.

+- · SpineOpt.jl
GitHub

The unit__to_node and unit__from_node unit relationships are core elements of SpineOpt. For each unit__to_node or unit__from_node, a unit_flow variable is automatically added to the model, i.e. a commodity flow of a unit to or from a specific node, respectively.

Various parameters can be defined on the unit__to_node relationship, in order to constrain the associated unit flows. In most cases a unit_capacity will be defined for an upper bound on the commodity flows. Apart from that, ramping abilities of a unit can be defined. For further details on ramps see Ramping and Reserves.

To associate costs with a certain commodity flow, cost terms, such as fuel_costs and vom_costs, can be included for the unit__to_node relationship.

It is important to note, that the parameters associated with the unit__to_node can be defined either for a specific node, or for a group of nodes. Grouping nodes for the described parameters will result in an aggregation of the unit flows for the triggered constraint, e.g. the definition of the unit_capacity on a group of nodes will result in an upper bound on the sum of all individual unit_flows.

diff --git a/dev/concept_reference/unit__to_node__unit_constraint/index.html b/dev/concept_reference/unit__to_node__unit_constraint/index.html index e532fd47ed..ce2d4b8e5f 100644 --- a/dev/concept_reference/unit__to_node__unit_constraint/index.html +++ b/dev/concept_reference/unit__to_node__unit_constraint/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

unit__to_node__user_constraint is a three-dimensional relationship between a unit, a node and a user_constraint. The relationship specifies that the unit_flow variable from the specified unit to the specified node is involved in the specified user_constraint. Parameters on this relationship generally apply to this specific unit_flow variable. For example the parameter unit_flow_coefficient defined on unit__to_node__user_constraint represents the coefficient on the specific unit_flow variable in the specified user_constraint

+- · SpineOpt.jl
GitHub

unit__to_node__user_constraint is a three-dimensional relationship between a unit, a node and a user_constraint. The relationship specifies that the unit_flow variable from the specified unit to the specified node is involved in the specified user_constraint. Parameters on this relationship generally apply to this specific unit_flow variable. For example the parameter unit_flow_coefficient defined on unit__to_node__user_constraint represents the coefficient on the specific unit_flow variable in the specified user_constraint

diff --git a/dev/concept_reference/unit__unit_constraint/index.html b/dev/concept_reference/unit__unit_constraint/index.html index c97828c091..d628267f7c 100644 --- a/dev/concept_reference/unit__unit_constraint/index.html +++ b/dev/concept_reference/unit__unit_constraint/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

unit__user_constraint is a two-dimensional relationship between a unit and a user_constraint. The relationship specifies that a variable or variable(s) associated only with the unit (not a unit_flow for example) are involved in the constraint. For example, the units_on_coefficient defined on unit__user_constraint specifies the coefficient of the unit's units_on variable in the specified user_constraint.

See also user_constraint

+- · SpineOpt.jl
GitHub

unit__user_constraint is a two-dimensional relationship between a unit and a user_constraint. The relationship specifies that a variable or variable(s) associated only with the unit (not a unit_flow for example) are involved in the constraint. For example, the units_on_coefficient defined on unit__user_constraint specifies the coefficient of the unit's units_on variable in the specified user_constraint.

See also user_constraint

diff --git a/dev/concept_reference/unit_availability_factor/index.html b/dev/concept_reference/unit_availability_factor/index.html index 48b372c2a9..b07e83b5cb 100644 --- a/dev/concept_reference/unit_availability_factor/index.html +++ b/dev/concept_reference/unit_availability_factor/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

To indicate that a unit is only available to a certain extent or at certain times of the optimization, the unit_availability_factor can be used. A typical use case could be an availability timeseries for a variable renewable energy source. By default the availability factor is set to 1. The availability is, among others, used in the constraint_units_available.

+- · SpineOpt.jl
GitHub

To indicate that a unit is only available to a certain extent or at certain times of the optimization, the unit_availability_factor can be used. A typical use case could be an availability timeseries for a variable renewable energy source. By default the availability factor is set to 1. The availability is, among others, used in the constraint_units_available.

diff --git a/dev/concept_reference/unit_capacity/index.html b/dev/concept_reference/unit_capacity/index.html index 40209e4d62..161f184fe3 100644 --- a/dev/concept_reference/unit_capacity/index.html +++ b/dev/concept_reference/unit_capacity/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub
+- · SpineOpt.jl
GitHub
diff --git a/dev/concept_reference/unit_conv_cap_to_flow/index.html b/dev/concept_reference/unit_conv_cap_to_flow/index.html index 0eb6730783..563d9dcc14 100644 --- a/dev/concept_reference/unit_conv_cap_to_flow/index.html +++ b/dev/concept_reference/unit_conv_cap_to_flow/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

The unit_conv_cap_to_flow, as defined for a unit__to_node or unit__from_node, allows the user to align between unit_flow variables and the unit_capacity parameter, which may be expressed in different units. An example would be when the unit_capacity is expressed in GWh, while the demand on the node is expressed in MWh. In that case, a unit_conv_cap_to_flow parameter of 1000 would be applicable.

+- · SpineOpt.jl
GitHub

The unit_conv_cap_to_flow, as defined for a unit__to_node or unit__from_node, allows the user to align between unit_flow variables and the unit_capacity parameter, which may be expressed in different units. An example would be when the unit_capacity is expressed in GWh, while the demand on the node is expressed in MWh. In that case, a unit_conv_cap_to_flow parameter of 1000 would be applicable.

diff --git a/dev/concept_reference/unit_flow_coefficient/index.html b/dev/concept_reference/unit_flow_coefficient/index.html index 7c552cbcb3..7b695d4e7c 100644 --- a/dev/concept_reference/unit_flow_coefficient/index.html +++ b/dev/concept_reference/unit_flow_coefficient/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

The unit_flow_coefficient is an optional parameter that can be used to include the unit_flow or unit_flow_op variables from or to a node in a user_constraint via the unit__from_node__user_constraint and unit__to_node__user_constraint relationships. Essentially, unit_flow_coefficient appears as a coefficient for the unit_flow and unit_flow_op variables from or to the node in the user constraint.

Note that the unit_flow_op variables are a bit of a special case, defined using the operating_points parameter.

+- · SpineOpt.jl
GitHub

The unit_flow_coefficient is an optional parameter that can be used to include the unit_flow or unit_flow_op variables from or to a node in a user_constraint via the unit__from_node__user_constraint and unit__to_node__user_constraint relationships. Essentially, unit_flow_coefficient appears as a coefficient for the unit_flow and unit_flow_op variables from or to the node in the user constraint.

Note that the unit_flow_op variables are a bit of a special case, defined using the operating_points parameter.

diff --git a/dev/concept_reference/unit_idle_heat_rate/index.html b/dev/concept_reference/unit_idle_heat_rate/index.html index 024042688a..c4ed1b8fa2 100644 --- a/dev/concept_reference/unit_idle_heat_rate/index.html +++ b/dev/concept_reference/unit_idle_heat_rate/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

Used to implement the no-load or idle heat rate of a unit. This is the y-axis offset of the heat rate function and is the fuel consumed per unit time when a unit is online and that results in no additional output. This is defined on the unit__node__node relationship and it is assumed that the input flow from node 1 represents fuel consumption and the output flow to node 2 is the elecrical output. While the units depend on the data, unit_idle_heat_rate is generally expressed in GJ/hr. Used in conjunction with unit_incremental_heat_rate. unit_idle_heat_rate is only currently considered if unit_incremental_heat_rate is specified. A trivial unit_incremental_heat_rate of zero can be defined if there is no incremental heat rate.

+- · SpineOpt.jl
GitHub

Used to implement the no-load or idle heat rate of a unit. This is the y-axis offset of the heat rate function and is the fuel consumed per unit time when a unit is online and that results in no additional output. This is defined on the unit__node__node relationship and it is assumed that the input flow from node 1 represents fuel consumption and the output flow to node 2 is the elecrical output. While the units depend on the data, unit_idle_heat_rate is generally expressed in GJ/hr. Used in conjunction with unit_incremental_heat_rate. unit_idle_heat_rate is only currently considered if unit_incremental_heat_rate is specified. A trivial unit_incremental_heat_rate of zero can be defined if there is no incremental heat rate.

diff --git a/dev/concept_reference/unit_incremental_heat_rate/index.html b/dev/concept_reference/unit_incremental_heat_rate/index.html index b08d826575..b6a05712e3 100644 --- a/dev/concept_reference/unit_incremental_heat_rate/index.html +++ b/dev/concept_reference/unit_incremental_heat_rate/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

Used to implement simple or piecewise linear incremental heat rate functions. Used in the constraint unit_pw_heat_rate - the input fuel flow at node 1 is the sum of the electrical MW output at node 2 times the incremental heat rate over all heat rate segments, plus the unit_idle_heat_rate. The units are detmerined by the data, but generally, incremental heat rates are given in GJ/MWh. Note that the formulation assumes a convex, monitonically increasing heat rate function. The formulation relies on optimality to load the heat rate segments in the correct order and no additional integer variables are created to enforce the correct loading order. The heat rate segment MW operating points are defined by operating_points.

To implement a simple incremental heat rate function,unit_incremental_heat_rate should be given as a simple scalar representing the incremental heat rate over the entire operating range of the unit. To implement a piecewise linear heat rate function, unit_incremental_heat_rate should be specified as an array type. It is then used in conjunction with the unit parameter operating_points which should also be defined as an array type of equal dimension. When defined as an array type unit_incremental_heat_rate[i] is the effective incremental heat rate between operating_points [i-1] (or zero if i=1) and operating_points[i]. Note that operating_points is defined on a capacity-normalized basis so if operating_points is specified as [0.5, 1], this creates two operating segments, one from zero to 50% of the corresponding unit_capacity and a second from 50% to 100% of the corresponding unit_capacity.

+- · SpineOpt.jl
GitHub

Used to implement simple or piecewise linear incremental heat rate functions. Used in the constraint unit_pw_heat_rate - the input fuel flow at node 1 is the sum of the electrical MW output at node 2 times the incremental heat rate over all heat rate segments, plus the unit_idle_heat_rate. The units are detmerined by the data, but generally, incremental heat rates are given in GJ/MWh. Note that the formulation assumes a convex, monitonically increasing heat rate function. The formulation relies on optimality to load the heat rate segments in the correct order and no additional integer variables are created to enforce the correct loading order. The heat rate segment MW operating points are defined by operating_points.

To implement a simple incremental heat rate function,unit_incremental_heat_rate should be given as a simple scalar representing the incremental heat rate over the entire operating range of the unit. To implement a piecewise linear heat rate function, unit_incremental_heat_rate should be specified as an array type. It is then used in conjunction with the unit parameter operating_points which should also be defined as an array type of equal dimension. When defined as an array type unit_incremental_heat_rate[i] is the effective incremental heat rate between operating_points [i-1] (or zero if i=1) and operating_points[i]. Note that operating_points is defined on a capacity-normalized basis so if operating_points is specified as [0.5, 1], this creates two operating segments, one from zero to 50% of the corresponding unit_capacity and a second from 50% to 100% of the corresponding unit_capacity.

diff --git a/dev/concept_reference/unit_investment_cost/index.html b/dev/concept_reference/unit_investment_cost/index.html index 36230f40f9..d8ad93b68e 100644 --- a/dev/concept_reference/unit_investment_cost/index.html +++ b/dev/concept_reference/unit_investment_cost/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

By defining the unit_investment_cost parameter for a specific unit, a cost term will be added to the objective function whenever a unit investment is made during the current optimization window.

+- · SpineOpt.jl
GitHub

By defining the unit_investment_cost parameter for a specific unit, a cost term will be added to the objective function whenever a unit investment is made during the current optimization window.

diff --git a/dev/concept_reference/unit_investment_lifetime/index.html b/dev/concept_reference/unit_investment_lifetime/index.html index 2ba8c18d3c..db9d997273 100644 --- a/dev/concept_reference/unit_investment_lifetime/index.html +++ b/dev/concept_reference/unit_investment_lifetime/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

Duration parameter that determines the minimum duration of unit investment decisions. Once a unit has been invested-in, it must remain invested-in for unit_investment_lifetime. Note that unit_investment_lifetime is a dynamic parameter that will impact the amount of solution history that must remain available to the optimisation in each step - this may impact performance.

See also Investment Optimization and candidate_units

+- · SpineOpt.jl
GitHub

Duration parameter that determines the minimum duration of unit investment decisions. Once a unit has been invested-in, it must remain invested-in for unit_investment_lifetime. Note that unit_investment_lifetime is a dynamic parameter that will impact the amount of solution history that must remain available to the optimisation in each step - this may impact performance.

See also Investment Optimization and candidate_units

diff --git a/dev/concept_reference/unit_investment_variable_type/index.html b/dev/concept_reference/unit_investment_variable_type/index.html index a28cec5353..7ae0425664 100644 --- a/dev/concept_reference/unit_investment_variable_type/index.html +++ b/dev/concept_reference/unit_investment_variable_type/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

Within an investments problem unit_investment_variable_type determines the unit investment decision variable type. Since the unit_flows will be limited to the product of the investment variable and the corresponding unit_capacity for each unit_flow and since candidate_units represents the upper bound of the investment decision variable, unit_investment_variable_type thus determines what the investment decision represents. If unit_investment_variable_type is integer or binary, then candidate_units represents the maximum number of discrete units that may be invested. If unit_investment_variable_type is continuous, candidate_units is more analagous to a capacity with unit_capacity being analagous to a scaling parameter. For example, if unit_investment_variable_type = integer, candidate_units = 4 and unit_capacity for a particular unit_flow = 400 MW, then the investment decision is how many 400 MW units to build. If unit_investment_variable_type = continuous, candidate_units = 400 and unit_capacity for a particular unit_flow = 1 MW, then the investment decision is how much capacity if this particular unit to build. Finally, if unit_investment_variable_type = integer, candidate_units = 10 and unit_capacity for a particular unit_flow = 50 MW, then the investment decision is many 50MW blocks of capacity of this particular unit to build.

See also Investment Optimization and candidate_units

+- · SpineOpt.jl
GitHub

Within an investments problem unit_investment_variable_type determines the unit investment decision variable type. Since the unit_flows will be limited to the product of the investment variable and the corresponding unit_capacity for each unit_flow and since candidate_units represents the upper bound of the investment decision variable, unit_investment_variable_type thus determines what the investment decision represents. If unit_investment_variable_type is integer or binary, then candidate_units represents the maximum number of discrete units that may be invested. If unit_investment_variable_type is continuous, candidate_units is more analagous to a capacity with unit_capacity being analagous to a scaling parameter. For example, if unit_investment_variable_type = integer, candidate_units = 4 and unit_capacity for a particular unit_flow = 400 MW, then the investment decision is how many 400 MW units to build. If unit_investment_variable_type = continuous, candidate_units = 400 and unit_capacity for a particular unit_flow = 1 MW, then the investment decision is how much capacity if this particular unit to build. Finally, if unit_investment_variable_type = integer, candidate_units = 10 and unit_capacity for a particular unit_flow = 50 MW, then the investment decision is many 50MW blocks of capacity of this particular unit to build.

See also Investment Optimization and candidate_units

diff --git a/dev/concept_reference/unit_investment_variable_type_list/index.html b/dev/concept_reference/unit_investment_variable_type_list/index.html index ae27aaff65..eae0d72a34 100644 --- a/dev/concept_reference/unit_investment_variable_type_list/index.html +++ b/dev/concept_reference/unit_investment_variable_type_list/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

unit_investment_variable_type_list holds the possible values for the type of a unit's investment variable which may be chosen from integer, binary or continuous.

+- · SpineOpt.jl
GitHub

unit_investment_variable_type_list holds the possible values for the type of a unit's investment variable which may be chosen from integer, binary or continuous.

diff --git a/dev/concept_reference/unit_online_variable_type_list/index.html b/dev/concept_reference/unit_online_variable_type_list/index.html index a08483281b..82013b9c08 100644 --- a/dev/concept_reference/unit_online_variable_type_list/index.html +++ b/dev/concept_reference/unit_online_variable_type_list/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

unit_online_variable_type_list holds the possible values for the type of a unit's commitment status variable which may be chosen from binary, integer, or linear.

+- · SpineOpt.jl
GitHub

unit_online_variable_type_list holds the possible values for the type of a unit's commitment status variable which may be chosen from binary, integer, or linear.

diff --git a/dev/concept_reference/unit_start_flow/index.html b/dev/concept_reference/unit_start_flow/index.html index 63ccf7022e..554eca8791 100644 --- a/dev/concept_reference/unit_start_flow/index.html +++ b/dev/concept_reference/unit_start_flow/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

Used to implement unit startup fuel consumption where node 1 is assumed to be input fuel and node 2 is assumed to be output elecrical energy. This is a flow from node 1 that is incurred when the value of the variable unitsstartedup is 1 in the corresponding time period. This flow does not result in additional output flow at node 2. Used in conjunction with unit_incremental_heat_rate. unit_start_flow is only currently considered if unit_incremental_heat_rate is specified. A trivial unit_incremental_heat_rate of zero can be defined if there is no incremental heat rate.

+- · SpineOpt.jl
GitHub

Used to implement unit startup fuel consumption where node 1 is assumed to be input fuel and node 2 is assumed to be output elecrical energy. This is a flow from node 1 that is incurred when the value of the variable unitsstartedup is 1 in the corresponding time period. This flow does not result in additional output flow at node 2. Used in conjunction with unit_incremental_heat_rate. unit_start_flow is only currently considered if unit_incremental_heat_rate is specified. A trivial unit_incremental_heat_rate of zero can be defined if there is no incremental heat rate.

diff --git a/dev/concept_reference/units_invested_avaiable_coefficient/index.html b/dev/concept_reference/units_invested_avaiable_coefficient/index.html index fb6ad61fca..8ce539f872 100644 --- a/dev/concept_reference/units_invested_avaiable_coefficient/index.html +++ b/dev/concept_reference/units_invested_avaiable_coefficient/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub
+- · SpineOpt.jl
GitHub
diff --git a/dev/concept_reference/units_invested_big_m_mga/index.html b/dev/concept_reference/units_invested_big_m_mga/index.html index 4c87fb581e..2ddffbeb70 100644 --- a/dev/concept_reference/units_invested_big_m_mga/index.html +++ b/dev/concept_reference/units_invested_big_m_mga/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

The units_invested_big_m_mga parameter is used in combination with the MGA algorithm (see mga-advanced). It defines an upper bound on the maximum difference between any MGA iteration. The big M should be chosen always sufficiently large. (Typically, a value equivalent to candidate_units could suffice.)

+- · SpineOpt.jl
GitHub

The units_invested_big_m_mga parameter is used in combination with the MGA algorithm (see mga-advanced). It defines an upper bound on the maximum difference between any MGA iteration. The big M should be chosen always sufficiently large. (Typically, a value equivalent to candidate_units could suffice.)

diff --git a/dev/concept_reference/units_invested_coefficient/index.html b/dev/concept_reference/units_invested_coefficient/index.html index 4ed070c966..2088f7ddb7 100644 --- a/dev/concept_reference/units_invested_coefficient/index.html +++ b/dev/concept_reference/units_invested_coefficient/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub
+- · SpineOpt.jl
GitHub
diff --git a/dev/concept_reference/units_invested_mga/index.html b/dev/concept_reference/units_invested_mga/index.html index 1537592e1b..20cee5c8ab 100644 --- a/dev/concept_reference/units_invested_mga/index.html +++ b/dev/concept_reference/units_invested_mga/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

The units_invested_mga is a boolean parameter that can be used in combination with the MGA algorithm (see mga-advanced). As soon as the value of units_invested_mga is set to true, investment decisions in this connection, or group of units, will be included in the MGA algorithm.

+- · SpineOpt.jl
GitHub

The units_invested_mga is a boolean parameter that can be used in combination with the MGA algorithm (see mga-advanced). As soon as the value of units_invested_mga is set to true, investment decisions in this connection, or group of units, will be included in the MGA algorithm.

diff --git a/dev/concept_reference/units_on__stochastic_structure/index.html b/dev/concept_reference/units_on__stochastic_structure/index.html index 08c1c94785..2948550cbf 100644 --- a/dev/concept_reference/units_on__stochastic_structure/index.html +++ b/dev/concept_reference/units_on__stochastic_structure/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

The units_on__stochastic_structure relationship defines the stochastic_structure used by the units_on variable. Essentially, this relationship permits defining a different stochastic_structure for the online decisions regarding the units_on variable, than what is used for the production unit_flow variables. A common use-case is e.g. using only one units_on variable across multiple stochastic_scenarios for the unit_flow variables. Note that only one units_on__stochastic_structure relationship can be defined per unit per model, as interpreted by the units_on__stochastic_structure and model__stochastic_structure relationships.

The units_on__stochastic_structure relationship uses the model__default_stochastic_structure relationship if not specified.

+- · SpineOpt.jl
GitHub

The units_on__stochastic_structure relationship defines the stochastic_structure used by the units_on variable. Essentially, this relationship permits defining a different stochastic_structure for the online decisions regarding the units_on variable, than what is used for the production unit_flow variables. A common use-case is e.g. using only one units_on variable across multiple stochastic_scenarios for the unit_flow variables. Note that only one units_on__stochastic_structure relationship can be defined per unit per model, as interpreted by the units_on__stochastic_structure and model__stochastic_structure relationships.

The units_on__stochastic_structure relationship uses the model__default_stochastic_structure relationship if not specified.

diff --git a/dev/concept_reference/units_on__temporal_block/index.html b/dev/concept_reference/units_on__temporal_block/index.html index 14aae1f97d..9dee149198 100644 --- a/dev/concept_reference/units_on__temporal_block/index.html +++ b/dev/concept_reference/units_on__temporal_block/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

units_on__temporal_block is a relationship linking the units_on variable of a unit to a specific temporal_block object. As such, this relationship will determine which temporal block governs the on- and offline status of the unit. The temporal block holds information on the temporal scope and resolution for which the variable should be optimized.

+- · SpineOpt.jl
GitHub

units_on__temporal_block is a relationship linking the units_on variable of a unit to a specific temporal_block object. As such, this relationship will determine which temporal block governs the on- and offline status of the unit. The temporal block holds information on the temporal scope and resolution for which the variable should be optimized.

diff --git a/dev/concept_reference/units_on_coefficient/index.html b/dev/concept_reference/units_on_coefficient/index.html index 8c6444cbb4..497c346485 100644 --- a/dev/concept_reference/units_on_coefficient/index.html +++ b/dev/concept_reference/units_on_coefficient/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub
+- · SpineOpt.jl
GitHub
diff --git a/dev/concept_reference/units_on_cost/index.html b/dev/concept_reference/units_on_cost/index.html index e75890a6dd..f1b746a65e 100644 --- a/dev/concept_reference/units_on_cost/index.html +++ b/dev/concept_reference/units_on_cost/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

By defining the units_on_cost parameter for a specific unit, a cost term will be added to the objective function whenever this unit is online over the current optimization window. It can be used to represent an idling cost or any fixed cost incurred when a unit is online.

+- · SpineOpt.jl
GitHub

By defining the units_on_cost parameter for a specific unit, a cost term will be added to the objective function whenever this unit is online over the current optimization window. It can be used to represent an idling cost or any fixed cost incurred when a unit is online.

diff --git a/dev/concept_reference/units_on_non_anticipativity_time/index.html b/dev/concept_reference/units_on_non_anticipativity_time/index.html index b35fe86b76..2531746432 100644 --- a/dev/concept_reference/units_on_non_anticipativity_time/index.html +++ b/dev/concept_reference/units_on_non_anticipativity_time/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

The units_on_non_anticipativity_time parameter defines the duration, starting from the begining of the optimisation window, where units_on variables need to be fixed to the result of the previous window.

This is intended to model "slow" units whose commitment decision needs to be taken in advance, e.g., in "day-ahead" mode, and cannot be changed afterwards.

+- · SpineOpt.jl
GitHub

The units_on_non_anticipativity_time parameter defines the duration, starting from the begining of the optimisation window, where units_on variables need to be fixed to the result of the previous window.

This is intended to model "slow" units whose commitment decision needs to be taken in advance, e.g., in "day-ahead" mode, and cannot be changed afterwards.

diff --git a/dev/concept_reference/units_started_up_coefficient/index.html b/dev/concept_reference/units_started_up_coefficient/index.html index 965bedce31..d0c16361f3 100644 --- a/dev/concept_reference/units_started_up_coefficient/index.html +++ b/dev/concept_reference/units_started_up_coefficient/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub
+- · SpineOpt.jl
GitHub
diff --git a/dev/concept_reference/upward_reserve/index.html b/dev/concept_reference/upward_reserve/index.html index f296dc8813..9d194d27d2 100644 --- a/dev/concept_reference/upward_reserve/index.html +++ b/dev/concept_reference/upward_reserve/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

If a node has a true is_reserve_node parameter, it will be treated as a reserve node in the model. To define whether the node corresponds to an upward or downward reserve commodity, the upward_reserve or the downward_reserve parameter needs to be set to true, respectively.

+- · SpineOpt.jl
GitHub

If a node has a true is_reserve_node parameter, it will be treated as a reserve node in the model. To define whether the node corresponds to an upward or downward reserve commodity, the upward_reserve or the downward_reserve parameter needs to be set to true, respectively.

diff --git a/dev/concept_reference/user_constraint/index.html b/dev/concept_reference/user_constraint/index.html index 350b5d7147..b05e024739 100644 --- a/dev/concept_reference/user_constraint/index.html +++ b/dev/concept_reference/user_constraint/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

The user_constraint is a generic data-driven custom constraint, which allows for defining constraints involving multiple units, nodes, or connections. The constraint_sense parameter changes the sense of the user_constraint, while the right_hand_side parameter allows for defining the constant terms of the constraint.

Coefficients for the different variables appearing in the user_constraint are defined using relationships, like e.g. unit__from_node__user_constraint and connection__to_node__user_constraint for unit_flow and connection_flow variables, or unit__user_constraint and node__user_constraint for units_on, units_started_up, and node_state variables.

For more information, see the dedicated article on User Constraints

+- · SpineOpt.jl
GitHub

The user_constraint is a generic data-driven custom constraint, which allows for defining constraints involving multiple units, nodes, or connections. The constraint_sense parameter changes the sense of the user_constraint, while the right_hand_side parameter allows for defining the constant terms of the constraint.

Coefficients for the different variables appearing in the user_constraint are defined using relationships, like e.g. unit__from_node__user_constraint and connection__to_node__user_constraint for unit_flow and connection_flow variables, or unit__user_constraint and node__user_constraint for units_on, units_started_up, and node_state variables.

For more information, see the dedicated article on User Constraints

diff --git a/dev/concept_reference/variable_type_list/index.html b/dev/concept_reference/variable_type_list/index.html index 7f394eaca6..fc60de5bba 100644 --- a/dev/concept_reference/variable_type_list/index.html +++ b/dev/concept_reference/variable_type_list/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub
+- · SpineOpt.jl
GitHub
diff --git a/dev/concept_reference/vom_cost/index.html b/dev/concept_reference/vom_cost/index.html index 255417d91f..9b95dd67ad 100644 --- a/dev/concept_reference/vom_cost/index.html +++ b/dev/concept_reference/vom_cost/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

By defining the vom_cost parameter for a specific unit, node, and direction, a cost term will be added to the objective function to account for the variable operation and maintenance costs associated with that unit over the course of its operational dispatch during the current optimization window.

+- · SpineOpt.jl
GitHub

By defining the vom_cost parameter for a specific unit, node, and direction, a cost term will be added to the objective function to account for the variable operation and maintenance costs associated with that unit over the course of its operational dispatch during the current optimization window.

diff --git a/dev/concept_reference/weight/index.html b/dev/concept_reference/weight/index.html index e7203ff023..5660cbfa8f 100644 --- a/dev/concept_reference/weight/index.html +++ b/dev/concept_reference/weight/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

The weight variable, defined for a temporal_block object can be used to assign different weights to different temporal periods that are modeled. It basically determines how important a certain temporal period is in the total cost, as it enters the Objective function. The main use of this parameter is for representative periods, where each representative period represents a specific fraction of a year or so.

+- · SpineOpt.jl
GitHub

The weight variable, defined for a temporal_block object can be used to assign different weights to different temporal periods that are modeled. It basically determines how important a certain temporal period is in the total cost, as it enters the Objective function. The main use of this parameter is for representative periods, where each representative period represents a specific fraction of a year or so.

diff --git a/dev/concept_reference/weight_relative_to_parents/index.html b/dev/concept_reference/weight_relative_to_parents/index.html index 06297819ce..961fbcd727 100644 --- a/dev/concept_reference/weight_relative_to_parents/index.html +++ b/dev/concept_reference/weight_relative_to_parents/index.html @@ -5,4 +5,4 @@ # If not a root `stochastic_scenario` -weight(scenario) = sum([weight(parent) * weight_relative_to_parents(scenario)] for parent in parents)

The above calculation is performed starting from the roots, generation by generation, until the leaves of the stochastic DAG. Thus, the final weight of each stochastic_scenario is dependent on the weight_relative_to_parents Parameters of all its ancestors.

+weight(scenario) = sum([weight(parent) * weight_relative_to_parents(scenario)] for parent in parents)

The above calculation is performed starting from the roots, generation by generation, until the leaves of the stochastic DAG. Thus, the final weight of each stochastic_scenario is dependent on the weight_relative_to_parents Parameters of all its ancestors.

diff --git a/dev/concept_reference/window_weight/index.html b/dev/concept_reference/window_weight/index.html index 0fb23cdc1e..b8ad69b142 100644 --- a/dev/concept_reference/window_weight/index.html +++ b/dev/concept_reference/window_weight/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

The window_weight parameter, defined for a model object, is used in the Benders decomposition algorithm with representative periods. In this setup, the subproblem rolls over a series of possibly disconnected windows, corresponding to the representative periods. Each of these windows can have a different weight, for example, equal to the fraction of the full model horizon that it represents. Chosing a good weigth can help the solution be more accurate.

To use weighted rolling representative periods Benders, do the following.

  • Specify roll_forward as an array of n duration values, so the subproblem rolls over representative periods.
  • Specify window_weight as an array of n + 1 floating point values, representing the weight of each window.

Note that it the problem rolls n times, then you have n + 1 windows.

+- · SpineOpt.jl
GitHub

The window_weight parameter, defined for a model object, is used in the Benders decomposition algorithm with representative periods. In this setup, the subproblem rolls over a series of possibly disconnected windows, corresponding to the representative periods. Each of these windows can have a different weight, for example, equal to the fraction of the full model horizon that it represents. Chosing a good weigth can help the solution be more accurate.

To use weighted rolling representative periods Benders, do the following.

  • Specify roll_forward as an array of n duration values, so the subproblem rolls over representative periods.
  • Specify window_weight as an array of n + 1 floating point values, representing the weight of each window.

Note that it the problem rolls n times, then you have n + 1 windows.

diff --git a/dev/concept_reference/write_lodf_file/index.html b/dev/concept_reference/write_lodf_file/index.html index 181321d4ff..f0521e92a0 100644 --- a/dev/concept_reference/write_lodf_file/index.html +++ b/dev/concept_reference/write_lodf_file/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

If this parameter value is set to true, a diagnostics file containing all the network line outage distributions factors in CSV format will be written to the current directory.

+- · SpineOpt.jl
GitHub

If this parameter value is set to true, a diagnostics file containing all the network line outage distributions factors in CSV format will be written to the current directory.

diff --git a/dev/concept_reference/write_mps_file/index.html b/dev/concept_reference/write_mps_file/index.html index caa7f1c426..10be534e86 100644 --- a/dev/concept_reference/write_mps_file/index.html +++ b/dev/concept_reference/write_mps_file/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

This parameter is deprecated and will be removed in a future version.

This parameter controls when to write a diagnostic model file in MPS format. If set to write_mps_always, the model will always be written in MPS format to the current directory. If set to write\_mps\_on\_no\_solve, the MPS file will be written when the model solve terminates with a status of false. If set to write\_mps\_never, no file will be written

+- · SpineOpt.jl
GitHub

This parameter is deprecated and will be removed in a future version.

This parameter controls when to write a diagnostic model file in MPS format. If set to write_mps_always, the model will always be written in MPS format to the current directory. If set to write\_mps\_on\_no\_solve, the MPS file will be written when the model solve terminates with a status of false. If set to write\_mps\_never, no file will be written

diff --git a/dev/concept_reference/write_mps_file_list/index.html b/dev/concept_reference/write_mps_file_list/index.html index 69df244afc..15e25766e8 100644 --- a/dev/concept_reference/write_mps_file_list/index.html +++ b/dev/concept_reference/write_mps_file_list/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

This parameter value list is deprecated and will be removed in a future version.

Houses the different values for the write_mps_file parameter. Possible values include write_mps_always, write\_mps\_on\_no\_solve, and write\_mps\_never.

+- · SpineOpt.jl
GitHub

This parameter value list is deprecated and will be removed in a future version.

Houses the different values for the write_mps_file parameter. Possible values include write_mps_always, write\_mps\_on\_no\_solve, and write\_mps\_never.

diff --git a/dev/concept_reference/write_ptdf_file/index.html b/dev/concept_reference/write_ptdf_file/index.html index 3a3dd82715..6c15d73398 100644 --- a/dev/concept_reference/write_ptdf_file/index.html +++ b/dev/concept_reference/write_ptdf_file/index.html @@ -1,2 +1,2 @@ -- · SpineOpt.jl
GitHub

If this parameter value is set to true, a diagnostics file containing all the network power transfer distributions factors in CSV format will be written to the current directory.

+- · SpineOpt.jl
GitHub

If this parameter value is set to true, a diagnostics file containing all the network power transfer distributions factors in CSV format will be written to the current directory.

diff --git a/dev/getting_started/archetypes/index.html b/dev/getting_started/archetypes/index.html index fda2fab6f1..a5973dd637 100644 --- a/dev/getting_started/archetypes/index.html +++ b/dev/getting_started/archetypes/index.html @@ -1,2 +1,2 @@ -Archetypes · SpineOpt.jl
GitHub

Archetypes

Archetypes are essentially ready-made templates for different aspects of SpineOpt.jl. They are intended to serve both as examples for how the data structure in SpineOpt.jl works, as well as pre-made modular parts that can be imported on top of existing model input data.

The templates/models/basic_model_template.json contains a ready-made template for simple energy system models, with uniform time resolution and deterministic stochastic structure. Essentially, it serves as a basis for testing how the modelled system is set up, without having to worry about setting up the temporal and stochastic structures.

The rest of the different archetypes are included under templates/archetypes in the SpineOpt.jl repository. Each archetype is stored as a .json file containing the necessary objects, relationships, and parameters to form a functioning pre-made part for a SpineOpt.jl model. The archetypes aren't completely plug-and-play, as there are always some relationships required to connect the archetype to the other input data correctly. Regardless, the following sections explain the different archetypes included in the SpineOpt.jl repository, as well as what steps the user needs to take to connect said archetype to their input data correctly.

Loading the SpineOpt Template and Archetypes into Your Model

To load the latest version of the SpineOpt template, in the Spine DB Editor, from the menu (three hirzontal bars in the top right), click on import as follows:

importing the SpineOpt Template

Change the file type to JSON and click on spineopt_template.json as follows:

importing the SpineOpt Template

Click on spineopttemplate.json and press Open. If you don't see spineopttemplate.json make sure you have navigated to Spine\SpineOpt.jl\templates.

Loading the latest version of the SpineOpt template in this way will update your datastore with the latest version of the data structure.

Branching Stochastic Tree

templates/archetypes/branching_stochastic_tree.json

This archetype contains the definitions required for an example stochastic_structure called branching, representing a branching scenario tree. The stochastic_structure starts out as a single stochastic_scenario called realistic, which then branches out into three roughly equiprobable stochastic_scenarios called forecast1, forecast2, and forecast3 after 6 hours. This archetype is the final product of following the steps in the Example of branching stochastics part of the Stochastic Framework section.

Importing this archetype into an input datastore only creates the stochastic_structure, which needs to be connected to the rest of your model using either the model__default_stochastic_structure relationship for a model-wide default, or the other relevant Structural relationship classes. Note that the model-wide default gets superceded by any conflicting definitions via e.g. the node__stochastic_structure.

Converging Stochastic Tree

templates/archetypes/converging_stochastic_tree.json

This archetype contains the definitions required for an example stochastic_structure called converging, representing a converging scenario tree (technically a directed acyclic graph DAG). The stochastic_structure starts out as a single stochastic_scenario called realization, which then branches out into three roughly equiprobable stochastic_scenarios called forecast1, forecast2, and forecast3 after 6 hours. Then, after 24 hours (1 day), these three forecasts converge into a single stochastic_scenario called converged_forecast. This archetype is the final product of following the steps in the Example of converging stochastics part of the Stochastic Framework section.

Importing this archetype into an input datastore only creates the stochastic_structure, which needs to be connected to the rest of your model using either the model__default_stochastic_structure relationship for a model-wide default, or the other relevant Structural relationship classes. Note that the model-wide default gets superceded by any conflicting definitions via e.g. the node__stochastic_structure.

Deterministic Stochastic Structure

templates/archetypes/deterministic_stochastic_structure.json

This archetype contains the definitions required for an example stochastic_structure called deterministic, representing a simple deterministic modelling case. The stochastic_structure contains only a single stochastic_scenario called realization, which continues indefinitely. This archetype is the final product of following the steps in the Example of deterministic stochastics part of the Stochastic Framework section.

Importing this archetype into an input datastore only creates the stochastic_structure, which needs to be connected to the rest of your model using either the model__default_stochastic_structure relationship for a model-wide default, or the other relevant Structural relationship classes. Note that the model-wide default gets superceded by any conflicting definitions via e.g. the node__stochastic_structure.

+Archetypes · SpineOpt.jl
GitHub

Archetypes

Archetypes are essentially ready-made templates for different aspects of SpineOpt.jl. They are intended to serve both as examples for how the data structure in SpineOpt.jl works, as well as pre-made modular parts that can be imported on top of existing model input data.

The templates/models/basic_model_template.json contains a ready-made template for simple energy system models, with uniform time resolution and deterministic stochastic structure. Essentially, it serves as a basis for testing how the modelled system is set up, without having to worry about setting up the temporal and stochastic structures.

The rest of the different archetypes are included under templates/archetypes in the SpineOpt.jl repository. Each archetype is stored as a .json file containing the necessary objects, relationships, and parameters to form a functioning pre-made part for a SpineOpt.jl model. The archetypes aren't completely plug-and-play, as there are always some relationships required to connect the archetype to the other input data correctly. Regardless, the following sections explain the different archetypes included in the SpineOpt.jl repository, as well as what steps the user needs to take to connect said archetype to their input data correctly.

Loading the SpineOpt Template and Archetypes into Your Model

To load the latest version of the SpineOpt template, in the Spine DB Editor, from the menu (three hirzontal bars in the top right), click on import as follows:

importing the SpineOpt Template

Change the file type to JSON and click on spineopt_template.json as follows:

importing the SpineOpt Template

Click on spineopttemplate.json and press Open. If you don't see spineopttemplate.json make sure you have navigated to Spine\SpineOpt.jl\templates.

Loading the latest version of the SpineOpt template in this way will update your datastore with the latest version of the data structure.

Branching Stochastic Tree

templates/archetypes/branching_stochastic_tree.json

This archetype contains the definitions required for an example stochastic_structure called branching, representing a branching scenario tree. The stochastic_structure starts out as a single stochastic_scenario called realistic, which then branches out into three roughly equiprobable stochastic_scenarios called forecast1, forecast2, and forecast3 after 6 hours. This archetype is the final product of following the steps in the Example of branching stochastics part of the Stochastic Framework section.

Importing this archetype into an input datastore only creates the stochastic_structure, which needs to be connected to the rest of your model using either the model__default_stochastic_structure relationship for a model-wide default, or the other relevant Structural relationship classes. Note that the model-wide default gets superceded by any conflicting definitions via e.g. the node__stochastic_structure.

Converging Stochastic Tree

templates/archetypes/converging_stochastic_tree.json

This archetype contains the definitions required for an example stochastic_structure called converging, representing a converging scenario tree (technically a directed acyclic graph DAG). The stochastic_structure starts out as a single stochastic_scenario called realization, which then branches out into three roughly equiprobable stochastic_scenarios called forecast1, forecast2, and forecast3 after 6 hours. Then, after 24 hours (1 day), these three forecasts converge into a single stochastic_scenario called converged_forecast. This archetype is the final product of following the steps in the Example of converging stochastics part of the Stochastic Framework section.

Importing this archetype into an input datastore only creates the stochastic_structure, which needs to be connected to the rest of your model using either the model__default_stochastic_structure relationship for a model-wide default, or the other relevant Structural relationship classes. Note that the model-wide default gets superceded by any conflicting definitions via e.g. the node__stochastic_structure.

Deterministic Stochastic Structure

templates/archetypes/deterministic_stochastic_structure.json

This archetype contains the definitions required for an example stochastic_structure called deterministic, representing a simple deterministic modelling case. The stochastic_structure contains only a single stochastic_scenario called realization, which continues indefinitely. This archetype is the final product of following the steps in the Example of deterministic stochastics part of the Stochastic Framework section.

Importing this archetype into an input datastore only creates the stochastic_structure, which needs to be connected to the rest of your model using either the model__default_stochastic_structure relationship for a model-wide default, or the other relevant Structural relationship classes. Note that the model-wide default gets superceded by any conflicting definitions via e.g. the node__stochastic_structure.

diff --git a/dev/getting_started/creating_your_own_model/index.html b/dev/getting_started/creating_your_own_model/index.html index 9eae5d5694..0845761f81 100644 --- a/dev/getting_started/creating_your_own_model/index.html +++ b/dev/getting_started/creating_your_own_model/index.html @@ -1,2 +1,2 @@ -Creating Your Own Model · SpineOpt.jl
GitHub

Creating Your Own Model

This part of the guide shows first an example how to insert objects and their parameter data. Then it shows what other objects, relationships and parameter data needs to be added for a very basic model. Lastly, the model instance is run.

This section explains the process of creating a SpineOpt.jl model from scratch in order to give you an understanding of the underlying principles of the data structure, etc. If you simply want to try something out quickly to see results, check out the Example Models section. Furthermore, if you're in a hurry, the Archetypes section provides you with some pre-made templates for the different parts of a SpineOpt.jl model to get you started quickly.

Creating a SpineOpt model instance

  • First, open the database editor by double-clicking the Input DB.
  • Right click on model in the Object tree.
  • Choose Add objects.
  • Then, add a model object by writing a name to the object name field. You can use e.g. instance.
  • Click ok.
  • The model object in SpineOpt is an abstraction that represents the model itself. Every SpineOpt database needs to have at least one model object.
  • The model object holds general information about the optimization. The whole range of functionalities is explained in Advanced Concepts chapter - in here a minimal set of parameters is used.

image

image

Add parameter values to the model instance

  • Select the model object instance from the object tree.
  • Go to the Object parameter value tab.
  • Every parameter value belongs to a specific alternative. This allows to hold multiple values for the same parameter of a particular object. The alternative values are used to create scenarios. Choose, Base for all parameter values (Base is required in Spine Toolbox - all other alternatives can be chosen freely).
  • Then define a model_start time and a model_end time.
    • Double-click on the empty row under parameter_name and select model_start.
    • A None should appear in value column.
    • To asign a start date value, right-click on None and open the editor (cannot be entered directly, since the datatype needs to be changed).
    • The parameter type of model_start is of type Datetime.
    • Set the value to e.g. 2019-01-01T00:00:00.
    • Proceed accordingly for the model_end.

image

Further reading on adding parameter values can be found here.

Add other necessary objects and parameter data for the objects.

  • Add all objects and their parameter data by replicating what has been done in the picture below. Do it the same way as explained above with the following caveats.
  • Whilst most object names can be freely defined by the user, there is one object name in the example below that needs to be written exactly since it is used internally by SpineOpt: unit_flow.
  • The parameter_name can be selected from a drop down menu.
  • The date time and time series parameter data can be added by using right-click to access the Edit... dialog. When creating the time series, use the fixed resolution with Start time of the model run and with 1h resolution. Then only values need to be entered (or copy pasted) and time stamps come automatically.
  • Parameter balance_type needs to have value balance_type_none in the gas node, since it allows the node to create energy (natural gas) against a price and therefore the energy balance is not maintained.

image

Define temporal and stochastic structures

  • To specify the temporal structure for SpineOpt, you need to define temporal_block objects. Think of a temporal_block as a distinctive way of 'slicing' time across the model horizon.
  • To link the temporal structure to the spatial structure, you need to specify node__temporal_block relationships, establishing which temporal__block applies to each node. This relationship is added by right-clicking the node__temporal_block in the relationship tree and then using the add relationships... dialog. Double clicking on an empty cell gives you the list of valid objects. The relationship name is automatically formed, but you can change it if that is desirable.
  • To keep things simple at this point, let's just define one temporal_block for our model and apply it to all nodes. We add the object hourly_temporal_block of type temporal_block following the same procedure as before and establish node__temporal_block relationships between node_gas and hourly_temporal_block, and electricity_node and hourly_temporal_block.
  • In practical terms, the above means that there energy flows over gas_node and electricity_node for each 'time-slice' comprised in hourly_temporal_block.
  • Similarly with the stochastic structure, each node is assigned a deterministic stochastic_structure.

Define the spatial structure

  • To specify the spatial structure for SpineOpt, you will need to use the node, unit, and connection objects added before.
  • Nodes can be understood as spatial aggregators. In combination with units and connections, they form the energy network.
  • Units in SpineOpt represent any kind of conversion process. As one example, a unit can represent a power plant that converts the flow of a commodity fuel into an electricity and/or heat flow.
  • Connections on the other hand describe the transport of goods from one location to another. Electricity lines and gas pipelines are examples of such connections. This example does not use connections.
  • The database should have an object gas_turbine for the unit object class and objects node_gas and node_elec for the node object class.
  • Next, define how the unit and the nodes interact with each other: create a unit__from_node relationship between gas_turbine and node_gas, and unit__to_node relationships between gas_turbine and node_elec.
  • In practical terms, the above means that there is an energy flow going from node_gas into node_elec, through the gas_turbine.

Add remaining relationships and parameter data for the relationships.

  • Similar to adding the objects and their parameter data, add the relationships and their parameter data based on the picture below.
  • The capacity of the gas_turbine has to be sufficient to meet the highest demand for electricity, otherwise the model will be infeasible (it is possible to set penalty values, but they are not included in this example).
  • The parameter fix_ratio_in_out_unit_flow forces the ratio between an input and output flow to be a constant. This is one way to establish an efficiency for a conversion process.

image

Run the model

  • Select SpineOpt
  • Press Execute selection.

image

If it fails

  • Double-check that the data is correct
  • Try to see what the problem might be
  • Ask help from the discussion forum

Explore the results

  • Double-clicking the Results database.

image

Create and run scenarios and build the model further

  • Create a new alternative
  • Add parameter data for the new alternative
  • Connect alternatives under a scenario. Toolbox modifies Base data with the data from the alternatives in the same scenario.
  • Execute multiple scenarios in parallel. First run in a new Julia instance will need to compile SpineOpt taking some time.

image

image

+Creating Your Own Model · SpineOpt.jl
GitHub

Creating Your Own Model

This part of the guide shows first an example how to insert objects and their parameter data. Then it shows what other objects, relationships and parameter data needs to be added for a very basic model. Lastly, the model instance is run.

This section explains the process of creating a SpineOpt.jl model from scratch in order to give you an understanding of the underlying principles of the data structure, etc. If you simply want to try something out quickly to see results, check out the Example Models section. Furthermore, if you're in a hurry, the Archetypes section provides you with some pre-made templates for the different parts of a SpineOpt.jl model to get you started quickly.

Creating a SpineOpt model instance

  • First, open the database editor by double-clicking the Input DB.
  • Right click on model in the Object tree.
  • Choose Add objects.
  • Then, add a model object by writing a name to the object name field. You can use e.g. instance.
  • Click ok.
  • The model object in SpineOpt is an abstraction that represents the model itself. Every SpineOpt database needs to have at least one model object.
  • The model object holds general information about the optimization. The whole range of functionalities is explained in Advanced Concepts chapter - in here a minimal set of parameters is used.

image

image

Add parameter values to the model instance

  • Select the model object instance from the object tree.
  • Go to the Object parameter value tab.
  • Every parameter value belongs to a specific alternative. This allows to hold multiple values for the same parameter of a particular object. The alternative values are used to create scenarios. Choose, Base for all parameter values (Base is required in Spine Toolbox - all other alternatives can be chosen freely).
  • Then define a model_start time and a model_end time.
    • Double-click on the empty row under parameter_name and select model_start.
    • A None should appear in value column.
    • To asign a start date value, right-click on None and open the editor (cannot be entered directly, since the datatype needs to be changed).
    • The parameter type of model_start is of type Datetime.
    • Set the value to e.g. 2019-01-01T00:00:00.
    • Proceed accordingly for the model_end.

image

Further reading on adding parameter values can be found here.

Add other necessary objects and parameter data for the objects.

  • Add all objects and their parameter data by replicating what has been done in the picture below. Do it the same way as explained above with the following caveats.
  • Whilst most object names can be freely defined by the user, there is one object name in the example below that needs to be written exactly since it is used internally by SpineOpt: unit_flow.
  • The parameter_name can be selected from a drop down menu.
  • The date time and time series parameter data can be added by using right-click to access the Edit... dialog. When creating the time series, use the fixed resolution with Start time of the model run and with 1h resolution. Then only values need to be entered (or copy pasted) and time stamps come automatically.
  • Parameter balance_type needs to have value balance_type_none in the gas node, since it allows the node to create energy (natural gas) against a price and therefore the energy balance is not maintained.

image

Define temporal and stochastic structures

  • To specify the temporal structure for SpineOpt, you need to define temporal_block objects. Think of a temporal_block as a distinctive way of 'slicing' time across the model horizon.
  • To link the temporal structure to the spatial structure, you need to specify node__temporal_block relationships, establishing which temporal__block applies to each node. This relationship is added by right-clicking the node__temporal_block in the relationship tree and then using the add relationships... dialog. Double clicking on an empty cell gives you the list of valid objects. The relationship name is automatically formed, but you can change it if that is desirable.
  • To keep things simple at this point, let's just define one temporal_block for our model and apply it to all nodes. We add the object hourly_temporal_block of type temporal_block following the same procedure as before and establish node__temporal_block relationships between node_gas and hourly_temporal_block, and electricity_node and hourly_temporal_block.
  • In practical terms, the above means that there energy flows over gas_node and electricity_node for each 'time-slice' comprised in hourly_temporal_block.
  • Similarly with the stochastic structure, each node is assigned a deterministic stochastic_structure.

Define the spatial structure

  • To specify the spatial structure for SpineOpt, you will need to use the node, unit, and connection objects added before.
  • Nodes can be understood as spatial aggregators. In combination with units and connections, they form the energy network.
  • Units in SpineOpt represent any kind of conversion process. As one example, a unit can represent a power plant that converts the flow of a commodity fuel into an electricity and/or heat flow.
  • Connections on the other hand describe the transport of goods from one location to another. Electricity lines and gas pipelines are examples of such connections. This example does not use connections.
  • The database should have an object gas_turbine for the unit object class and objects node_gas and node_elec for the node object class.
  • Next, define how the unit and the nodes interact with each other: create a unit__from_node relationship between gas_turbine and node_gas, and unit__to_node relationships between gas_turbine and node_elec.
  • In practical terms, the above means that there is an energy flow going from node_gas into node_elec, through the gas_turbine.

Add remaining relationships and parameter data for the relationships.

  • Similar to adding the objects and their parameter data, add the relationships and their parameter data based on the picture below.
  • The capacity of the gas_turbine has to be sufficient to meet the highest demand for electricity, otherwise the model will be infeasible (it is possible to set penalty values, but they are not included in this example).
  • The parameter fix_ratio_in_out_unit_flow forces the ratio between an input and output flow to be a constant. This is one way to establish an efficiency for a conversion process.

image

Run the model

  • Select SpineOpt
  • Press Execute selection.

image

If it fails

  • Double-check that the data is correct
  • Try to see what the problem might be
  • Ask help from the discussion forum

Explore the results

  • Double-clicking the Results database.

image

Create and run scenarios and build the model further

  • Create a new alternative
  • Add parameter data for the new alternative
  • Connect alternatives under a scenario. Toolbox modifies Base data with the data from the alternatives in the same scenario.
  • Execute multiple scenarios in parallel. First run in a new Julia instance will need to compile SpineOpt taking some time.

image

image

diff --git a/dev/getting_started/installation/index.html b/dev/getting_started/installation/index.html index e0625208d6..edfb377de7 100644 --- a/dev/getting_started/installation/index.html +++ b/dev/getting_started/installation/index.html @@ -2,4 +2,4 @@ Installation · SpineOpt.jl
GitHub

Installation

Compatibility

This package requires Julia 1.2 or later.

Installation

If you haven't yet installed the tools yet, please follow the installation guides:

  • For Spine Toolbox: https://github.com/spine-tools/SpineOpt.jl#installation
  • For SpineOpt: https://github.com/spine-tools/Spine-Toolbox#installation

If you are not sure whether you have the latest version, please upgrade to ensure compatibility with this guide.

  • For Spine Toolbox:
- If installed with pipx, then use `python -m pipx upgrade spinetoolbox`
 - If installed from sources using git, then<br>
     `git pull`<br>
-	`python -m pip install -U -r requirements.txt`<br>
  • For SpineOpt: https://github.com/spine-tools/SpineOpt.jl#upgrading
+ `python -m pip install -U -r requirements.txt`<br> diff --git a/dev/getting_started/output_data/index.html b/dev/getting_started/output_data/index.html index c3b487d0e0..7e5ea92a5f 100644 --- a/dev/getting_started/output_data/index.html +++ b/dev/getting_started/output_data/index.html @@ -1,2 +1,2 @@ -Managing Outputs · SpineOpt.jl
GitHub

Managing Output Data

Once a model is created and successfully run, it will hopefully produce results and output data. This section covers how the writing of output data is controlled and managed.

Specifying Your Output Data Store

In your workflow (for more details see Setting up a workflow for SpineOpt in Spine Toolbox) you will normally have a output datastore connected to your RunSpineOpt workflow tool. This is where your output data will be written. If no output datastore is specified, the results will be written by default to the input datastore. However, it is generally preferable to define a separate output data store for results. See Setting up a workflow for SpineOpt in Spine Toolbox for the steps to add an output datastore to your workflow)

Specifying Outputs to Write

Outputting of results to the output datastore is controlled using the output and report object classes. To output a specific variable to the output datastore, we need to create an output object of the same name. For example, to output the unit_flow variable, we must create an output object named unit_flow. The SpineOpt template contains output objects for most problem variables and importing or re-importing the SpineOpt template will add these to your input datastore. So it is probable these output objects will exist already in your input datastore. Once the output objects exist in your model, they must then be added to a report object by creating an report__output relationship

Creating Reports

Reports are essentially a collection of outputs that can be written to an output datastore. Any number of report objects can be created. We add output items to a report by creating report__output relationships between the output objects we want included and the desired report object. Finally, to write a specic report to the output database, we must create a model__report relationship for each report object we want included in the output datastore.

Reporting of Input Parameters

In addition to writing results as outputs to a datastore, SpineOpt can also report input parameter data. To allow specific input parameters to be included in a report, they must be first added as output objects with a name corresponding exactly to the parameter name. For example, to allow the demand parameter to be included in a report, there must be a correspondingly named output object called demand. Similarly to outputs, to include an input parameter in a report, we must create a report__output relationship between the output object representing the input parameter (e.g. demand) and the desired report object.

Reporting of Dual Values

To report the dual of a constraint, one can add an output item with the corresponding constraint name (e.g. constraint_nodal_balance) and add that to a report. This will cause the corresponding constraint's marginal value to be reported in the output DB. When adding a constraint name as an output we need to preface the actual constraint name with constraint_ to avoid ambiguity with variable names (e.g. units_available). So to report the marginal value of units_available we add an output object called constraint_units_available.

To report the reduced_cost() for a variable which is the marginal value of the associated active bound or fix constraints on that variable, one can add an output object with the variable name prepended by bound_. So, to report the unitson reducedcost value, one would create an output item called bound_units_on. If added to a report, this will cause the reduced cost of unitson in the final fixed LP to be written to the output db. Finally, if any constraint duals or reducedcost values are requested via a report, calculate_duals is set to true and the final fixed LP solve is triggered.

Output Data Temporal Resolution

To control the resolution of report data (both output data and input data appearing in reports), we use the output_resolution output parameter. For the specific output (or input), this indicates the resolution at which the values should be reported. If output_resolution is null (the default), results are reported at the highest available resolution that will follow from the temporal structure of the model. If output_resolution is a duration value, then the average value is reported.

Output Data Structure

The structure of the output data will follow the structure of the input data with the inclusion of additional dimensions as described below:

  • The report object to which the output data items belong will be added as a dimension
  • The relevant stochastic scenario will be added as a dimension to all output data items. This allows for stochastic data to be written to the output datastore. However, in deterministic models, the single deterministic scenario will still appear as an additional dimension
  • For unit flows, the flow direction is added as a dimension to the output.

Example: unit_flow

For example, consider the unit_flow) optimisation variable. This variable is dimensioned on the unit__to_node and unit__from_node relationships. In the output datastore, the report, stochastic_scenario and flow direction are added as additional dimensions. Therefore, unit__to_node values will appear in the output datastore as timeseries parameters associated with the report__unit__node__direction__stochastic_scenario relationship as shown below.

image

To view the data, simply double-click on the timeseries value

Example: units_on

Consider the units_on) optimisation variable. This variable is dimensioned on the unit object class. In the output datastore, the report and stochastic_scenario are added as additional dimensions. Therefore, units_on values will appear in the output datastore as timeseries parameters associated with the report__unit__stochastic_scenario relationship as shown below.

image

To view the data, simply double-click on the timeseries value

Alternatives and Multiple Model Runs

  • All outputs from a single run of a model will be tagged with a unique "alternative". Alternatives allow multiple values to be specified for the same parameter. If a model is run multiple times, the results will be appended to the output datastore with a new alternative which uniquely identifies the scenario and model run. This is convenient as it allows results from multiple runs and for multiple scenarios to be viewed and compared simultaneously. If a specific altnernative is not selected (the default condition) the results for all alternatives will be visible. If a single altnerative is selected or multiple alternatives are selected in the altnerative tree, then only the results for the selected alternatives will be shown.

In the example below, the relationship class report__unit__stochastic_scenario is selected in the relationship treem therefore results for that relationship class are showing in the relationship parameter pane. Furthermore, in the alternative tree, the alternative 10h TP Load _Reun SpineOpt... is selected, meaning only results for that alternative are being displayed.

image

Output Writing Summary

  • We need an output object in our intput datastore for each variable or marginal value we want included in a report
  • Inputs data can also be reported. As above, we need to create an output object named after the input parameter we want reported
  • We need to create a report object to contain our desired outputs (or input parameters) which are added to our report via report__output relationships
  • We need to create a model__report object to write a specific report to the output datastore.
  • The temporal resolution of outputs (which may also be input parameters) is controlled by the output_resolution output duration parameter. If null, the highest available resolution is reported, otherwise the average is reported over the desired duration.
  • Additional dimensions are added to the output data such as the report object, stochastic_scenario and, in the case of unit_flow, the flow direction.
  • Model outputs are tagged with altnernatives that are unique to the model run and scenario that generated them
+Managing Outputs · SpineOpt.jl
GitHub

Managing Output Data

Once a model is created and successfully run, it will hopefully produce results and output data. This section covers how the writing of output data is controlled and managed.

Specifying Your Output Data Store

In your workflow (for more details see Setting up a workflow for SpineOpt in Spine Toolbox) you will normally have a output datastore connected to your RunSpineOpt workflow tool. This is where your output data will be written. If no output datastore is specified, the results will be written by default to the input datastore. However, it is generally preferable to define a separate output data store for results. See Setting up a workflow for SpineOpt in Spine Toolbox for the steps to add an output datastore to your workflow)

Specifying Outputs to Write

Outputting of results to the output datastore is controlled using the output and report object classes. To output a specific variable to the output datastore, we need to create an output object of the same name. For example, to output the unit_flow variable, we must create an output object named unit_flow. The SpineOpt template contains output objects for most problem variables and importing or re-importing the SpineOpt template will add these to your input datastore. So it is probable these output objects will exist already in your input datastore. Once the output objects exist in your model, they must then be added to a report object by creating an report__output relationship

Creating Reports

Reports are essentially a collection of outputs that can be written to an output datastore. Any number of report objects can be created. We add output items to a report by creating report__output relationships between the output objects we want included and the desired report object. Finally, to write a specic report to the output database, we must create a model__report relationship for each report object we want included in the output datastore.

Reporting of Input Parameters

In addition to writing results as outputs to a datastore, SpineOpt can also report input parameter data. To allow specific input parameters to be included in a report, they must be first added as output objects with a name corresponding exactly to the parameter name. For example, to allow the demand parameter to be included in a report, there must be a correspondingly named output object called demand. Similarly to outputs, to include an input parameter in a report, we must create a report__output relationship between the output object representing the input parameter (e.g. demand) and the desired report object.

Reporting of Dual Values

To report the dual of a constraint, one can add an output item with the corresponding constraint name (e.g. constraint_nodal_balance) and add that to a report. This will cause the corresponding constraint's marginal value to be reported in the output DB. When adding a constraint name as an output we need to preface the actual constraint name with constraint_ to avoid ambiguity with variable names (e.g. units_available). So to report the marginal value of units_available we add an output object called constraint_units_available.

To report the reduced_cost() for a variable which is the marginal value of the associated active bound or fix constraints on that variable, one can add an output object with the variable name prepended by bound_. So, to report the unitson reducedcost value, one would create an output item called bound_units_on. If added to a report, this will cause the reduced cost of unitson in the final fixed LP to be written to the output db. Finally, if any constraint duals or reducedcost values are requested via a report, calculate_duals is set to true and the final fixed LP solve is triggered.

Output Data Temporal Resolution

To control the resolution of report data (both output data and input data appearing in reports), we use the output_resolution output parameter. For the specific output (or input), this indicates the resolution at which the values should be reported. If output_resolution is null (the default), results are reported at the highest available resolution that will follow from the temporal structure of the model. If output_resolution is a duration value, then the average value is reported.

Output Data Structure

The structure of the output data will follow the structure of the input data with the inclusion of additional dimensions as described below:

  • The report object to which the output data items belong will be added as a dimension
  • The relevant stochastic scenario will be added as a dimension to all output data items. This allows for stochastic data to be written to the output datastore. However, in deterministic models, the single deterministic scenario will still appear as an additional dimension
  • For unit flows, the flow direction is added as a dimension to the output.

Example: unit_flow

For example, consider the unit_flow) optimisation variable. This variable is dimensioned on the unit__to_node and unit__from_node relationships. In the output datastore, the report, stochastic_scenario and flow direction are added as additional dimensions. Therefore, unit__to_node values will appear in the output datastore as timeseries parameters associated with the report__unit__node__direction__stochastic_scenario relationship as shown below.

image

To view the data, simply double-click on the timeseries value

Example: units_on

Consider the units_on) optimisation variable. This variable is dimensioned on the unit object class. In the output datastore, the report and stochastic_scenario are added as additional dimensions. Therefore, units_on values will appear in the output datastore as timeseries parameters associated with the report__unit__stochastic_scenario relationship as shown below.

image

To view the data, simply double-click on the timeseries value

Alternatives and Multiple Model Runs

  • All outputs from a single run of a model will be tagged with a unique "alternative". Alternatives allow multiple values to be specified for the same parameter. If a model is run multiple times, the results will be appended to the output datastore with a new alternative which uniquely identifies the scenario and model run. This is convenient as it allows results from multiple runs and for multiple scenarios to be viewed and compared simultaneously. If a specific altnernative is not selected (the default condition) the results for all alternatives will be visible. If a single altnerative is selected or multiple alternatives are selected in the altnerative tree, then only the results for the selected alternatives will be shown.

In the example below, the relationship class report__unit__stochastic_scenario is selected in the relationship treem therefore results for that relationship class are showing in the relationship parameter pane. Furthermore, in the alternative tree, the alternative 10h TP Load _Reun SpineOpt... is selected, meaning only results for that alternative are being displayed.

image

Output Writing Summary

  • We need an output object in our intput datastore for each variable or marginal value we want included in a report
  • Inputs data can also be reported. As above, we need to create an output object named after the input parameter we want reported
  • We need to create a report object to contain our desired outputs (or input parameters) which are added to our report via report__output relationships
  • We need to create a model__report object to write a specific report to the output datastore.
  • The temporal resolution of outputs (which may also be input parameters) is controlled by the output_resolution output duration parameter. If null, the highest available resolution is reported, otherwise the average is reported over the desired duration.
  • Additional dimensions are added to the output data such as the report object, stochastic_scenario and, in the case of unit_flow, the flow direction.
  • Model outputs are tagged with altnernatives that are unique to the model run and scenario that generated them
diff --git a/dev/getting_started/setup_workflow/index.html b/dev/getting_started/setup_workflow/index.html index 7c8d490fc3..71225ee940 100644 --- a/dev/getting_started/setup_workflow/index.html +++ b/dev/getting_started/setup_workflow/index.html @@ -1,4 +1,4 @@ Setting up a workflow · SpineOpt.jl
GitHub

Setting up a workflow for SpineOpt in Spine Toolbox

The next steps will set up a SpineOpt specific input database by creating a new Spine database, loading a blank SpineOpt template, connecting it to a SpineOpt instance and setting up a database for model results.

  • Create a new Spine Toolbox project in an empty folder of your choice: File –> New project...
  • Create the input database
    • Drag an empty Data store from the toolbar to the Design View.
    • Give it a name like "Input DB".
    • Select SQL database dialect (sqlite is a local file and works without a server).
    • Click New Spine DB in the Data Store Properties window and create a new database (and save it, if it's sqlite).
    • For more information about creating and managing Spine Toolbox database, see the documentation

image

image

  • Fill the Input DB with SpineOpt data format either by:
    • Drag a tool Load template from the SpineOpt ribbon to the Design View.
    • Connect an arrow from the Load template to the new Input DB.
    • Make sure the Load template item from the Design view is selected (then you can edit the properties of that workflow item in the Tool properties window.
    • Add the url link in Available resources to the Tool arguments - you are passing the database address as a command line argument to the load_template.jl script so that it knows where to store the output.
    • Then execute the Load template tool. Please note that this process uses SpineOpt to generate the data structure. It takes time, since everything is compiled when running a tool in Julia for the first time in each Julia session. You may also see lot of messages and warnings concernging the compilation, but they should be benign.

image

image

image

image

  • ...or by:
    • Start Julia (you can start a separate Julia console in Spine Toolbox: go to Consoles –> Start Julia Console).
    • Copy the URL address of the Data Store from the 'Data Store Properties' –> a copy icon at the bottom.
    • Then run the following script with the right URL address pasted. The process uses SpineOpt itself to build the database structure. Please note that 'using SpineOpt' for the first time for each Julia session takes time - everything is being compiled.
      • Known issue: On Windows, the backslash between directories need to be changed to a double forward slash.
julia> using SpineOpt
 
-julia> SpineOpt.import_data("copied URL address, inside these quotes", SpineOpt.template(), "Load SpineOpt template")
  • Drag SpineOpt tool icon to the Design view.
  • Connect an arrow from the Input DB to SpineOpt.

image

  • Create a database for results
    • Drag a new Data store from the toolbar to the Design View.
    • You can rename it to e.g. Results. Select SQL database dialect (sqlite is a local file and works without a server).
    • Click New Spine DB in the Data Store Properties window and create a new database (and save it, if it's sqlite).
    • Connect an arrow from the SpineOpt to Results.

image

  • Select SpineOpt tool in the Design view.
  • Add the url link for the input data store and the output data store from Available resources to the Tool arguments (in that order).

image

SpineOpt would be ready to run, but for the Input DB, which is empty of content (it's just a template that contains a SpineOpt specific data structure). The next step goes through setting up and running a simple toy model.

+julia> SpineOpt.import_data("copied URL address, inside these quotes", SpineOpt.template(), "Load SpineOpt template")

image

image

image

SpineOpt would be ready to run, but for the Input DB, which is empty of content (it's just a template that contains a SpineOpt specific data structure). The next step goes through setting up and running a simple toy model.

diff --git a/dev/how_to/change_the_solver/index.html b/dev/how_to/change_the_solver/index.html index 0df1b6cae2..b8507570e7 100644 --- a/dev/how_to/change_the_solver/index.html +++ b/dev/how_to/change_the_solver/index.html @@ -1,2 +1,2 @@ -Change the solver · SpineOpt.jl
GitHub

If you want to change the solver for your optimization problem in SpineOpt, here is some guidance:

  • You can change the solvers in your input datastore using the db_lp_solver and db_mip_solver parameter values of the model object.
  • You can specify solver options via the db_lp_solver_options and db_mip_solver_options parameters respectively. These are map parameters where the first key is the solver name exactly as the db_mip_solver or db_lp_solver name, the second key is the solver option name and the value is the option value.
  • You can get a head start by copying the default map values for db_lp_solver_options and db_mip_solver_options. You can access the default values by clicking on the 'Object parameter definition' tab.
  • If you were trying to change the solver using the arguments to run_spineopt(), this is not the recommended way and will soon be deprecated.
  • The solver name corresponds to the name of the Julia package that you will need to install. Some like HiGHs.jl are self contained and include the binaries. Others like CPLEX.jl and Gurobi.jl you will need to point the package to your locally installed binaries - the julia packages have the instructions to do this.

The first option is the easiest. The more advanced way of using the solver options is illustrated below.

Set the model parameter values to choose the solvers and set the solver options:

image

This is what the solver options map parameter value looks like:

image

To get a head start with solver options, you can copy their default map values from the parameter definition tab like this:

image

+Change the solver · SpineOpt.jl
GitHub

If you want to change the solver for your optimization problem in SpineOpt, here is some guidance:

  • You can change the solvers in your input datastore using the db_lp_solver and db_mip_solver parameter values of the model object.
  • You can specify solver options via the db_lp_solver_options and db_mip_solver_options parameters respectively. These are map parameters where the first key is the solver name exactly as the db_mip_solver or db_lp_solver name, the second key is the solver option name and the value is the option value.
  • You can get a head start by copying the default map values for db_lp_solver_options and db_mip_solver_options. You can access the default values by clicking on the 'Object parameter definition' tab.
  • If you were trying to change the solver using the arguments to run_spineopt(), this is not the recommended way and will soon be deprecated.
  • The solver name corresponds to the name of the Julia package that you will need to install. Some like HiGHs.jl are self contained and include the binaries. Others like CPLEX.jl and Gurobi.jl you will need to point the package to your locally installed binaries - the julia packages have the instructions to do this.

The first option is the easiest. The more advanced way of using the solver options is illustrated below.

Set the model parameter values to choose the solvers and set the solver options:

image

This is what the solver options map parameter value looks like:

image

To get a head start with solver options, you can copy their default map values from the parameter definition tab like this:

image

diff --git a/dev/how_to/define_an_efficiency/index.html b/dev/how_to/define_an_efficiency/index.html index a0ea7d12b1..274232d03b 100644 --- a/dev/how_to/define_an_efficiency/index.html +++ b/dev/how_to/define_an_efficiency/index.html @@ -1,2 +1,2 @@ -Define an efficiency · SpineOpt.jl
GitHub

How to define an efficiency

relationships between the inputs and outputs of a unit

The image below shows an overview of the possible relationships between the inputs and outputs of a unit.

image

image

The key capability requirements are:

  • Easily define arbitrary numbers of input and output flows
  • Easily create piecewise affine linear relationships between any two flows
  • Anything more complicated can be done via user_constraints

unit__node__node relationship

image

The unit__node__node relationship allows you to constrain two nodes to each other via a number of different parameters.:

  • unit_incremental_heat_rate: Input_flow = unit_incremental_heat_rate * output_flow + unit_idle_heat_rate * units_on. It can be piecewise linear, used in conjunction with operating_points with monotonically increasing coefficients (not enforced). Used in conjunction with unit_idle_heat_rate triggers a fixed flow when the unit is online and unit_start_flow triggers a flow on a unit start (start fuel consumption)
  • fix_ratio_out_in_unit_flow: equivalent to an efficiency. Output_flow = fix_ratio_out_in_unit_flow x output_flow + fix_units_on_coefficient_out_in * units_on. Ordering of the nodes in the unit__node__node relationship matters. The first node will be the output flow and the second node will be treated as the input flow (consistently with the out_in in the parameter name. A units_on coefficient is added with fix_units_on_coefficient_out_in,
  • In addition to fix_ratio_out_in_unit_flow you have [constraint]_ratio_[direction1]_[direction2]_unit_flow where constraint can be min, max or fix and determines the sense of the constraint (max: <, min: >, fix: =) while direction1 and direction2 are used to interpret the direction of the flows involved. In signifies an input flow to the unit while out signifies an output flow from the unit. For each of these parameters, there is a corresponding [constraint]_[direction1]_[direction2]_units_on_coefficient. For example: max_ratio_in_out_unit_flow creates the following constraint:

input_flow < max_ratio_in_out_unit_flow * output_flow + max_units_on_coefficient_in_out * units_on

real world example: Compressed Air Energy Storage

To give a feeling for why these functionalities are useful, consider the following real world example for Compressed Air Energy Storage:

image

known issues

That does not mean that this implementation is perfect; there are some known issues:

  • Multiple ways to do the same thing (kind of)
  • The ordering of nodes in unit__node__node relationship matters and this can be confusing
  • When specifying a unit__node__node relationship, currently toolbox doesn’t constrain a user to choosing nodes that are connected to the unit. It’s possible to create a unit__node__node relationship between a unit and nodes where there are no flows. We actually need to define a relationship between two flows, which is really a relationship between a unit__[to/from]_node relationship and a unit__[to/from]_node relationship.
  • There is a long list of parameters (24 in total) [fix/max/min]_ratio_[in/out]_[in/out]_[unit_flow/units_on_coefficient]
  • Incremental_heat_rate supports piecewise linear but the ratio constraints don’t
+Define an efficiency · SpineOpt.jl
GitHub

How to define an efficiency

relationships between the inputs and outputs of a unit

The image below shows an overview of the possible relationships between the inputs and outputs of a unit.

image

image

The key capability requirements are:

  • Easily define arbitrary numbers of input and output flows
  • Easily create piecewise affine linear relationships between any two flows
  • Anything more complicated can be done via user_constraints

unit__node__node relationship

image

The unit__node__node relationship allows you to constrain two nodes to each other via a number of different parameters.:

  • unit_incremental_heat_rate: Input_flow = unit_incremental_heat_rate * output_flow + unit_idle_heat_rate * units_on. It can be piecewise linear, used in conjunction with operating_points with monotonically increasing coefficients (not enforced). Used in conjunction with unit_idle_heat_rate triggers a fixed flow when the unit is online and unit_start_flow triggers a flow on a unit start (start fuel consumption)
  • fix_ratio_out_in_unit_flow: equivalent to an efficiency. Output_flow = fix_ratio_out_in_unit_flow x output_flow + fix_units_on_coefficient_out_in * units_on. Ordering of the nodes in the unit__node__node relationship matters. The first node will be the output flow and the second node will be treated as the input flow (consistently with the out_in in the parameter name. A units_on coefficient is added with fix_units_on_coefficient_out_in,
  • In addition to fix_ratio_out_in_unit_flow you have [constraint]_ratio_[direction1]_[direction2]_unit_flow where constraint can be min, max or fix and determines the sense of the constraint (max: <, min: >, fix: =) while direction1 and direction2 are used to interpret the direction of the flows involved. In signifies an input flow to the unit while out signifies an output flow from the unit. For each of these parameters, there is a corresponding [constraint]_[direction1]_[direction2]_units_on_coefficient. For example: max_ratio_in_out_unit_flow creates the following constraint:

input_flow < max_ratio_in_out_unit_flow * output_flow + max_units_on_coefficient_in_out * units_on

real world example: Compressed Air Energy Storage

To give a feeling for why these functionalities are useful, consider the following real world example for Compressed Air Energy Storage:

image

known issues

That does not mean that this implementation is perfect; there are some known issues:

  • Multiple ways to do the same thing (kind of)
  • The ordering of nodes in unit__node__node relationship matters and this can be confusing
  • When specifying a unit__node__node relationship, currently toolbox doesn’t constrain a user to choosing nodes that are connected to the unit. It’s possible to create a unit__node__node relationship between a unit and nodes where there are no flows. We actually need to define a relationship between two flows, which is really a relationship between a unit__[to/from]_node relationship and a unit__[to/from]_node relationship.
  • There is a long list of parameters (24 in total) [fix/max/min]_ratio_[in/out]_[in/out]_[unit_flow/units_on_coefficient]
  • Incremental_heat_rate supports piecewise linear but the ratio constraints don’t
diff --git a/dev/how_to/print_the_model/index.html b/dev/how_to/print_the_model/index.html index f270443588..9fca8345ba 100644 --- a/dev/how_to/print_the_model/index.html +++ b/dev/how_to/print_the_model/index.html @@ -1,2 +1,2 @@ -Print the model · SpineOpt.jl
GitHub

How to print the model

As the SpineOpt model formulation is quite complex and can change depending on a few parameters (some parts of the formulation can be activated or deactivated), it can be useful to print the model that SpineOpt sends to JuMP. There are a few ways to do this.

The model that SpineOpt sends to JuMP can be saved to a file. It is not the nicest file to read but at the very least you can find the used variables and parameter values.

To write that file you need to set the write_mps_file parameter of the model object to write_mps_always.

SpineOpt will write the file to the working directory. If you are using Spine Toolbox that working directory will be the Spine Toolbox work folder which is typically in your user directory e.g. C:\Users\username\.spinetoolbox\work\run_spineopt_gibberish_toolbox\model_diagnostics.mps

An alternative approach is to directly use the write_model_file(m, filename) command in which m is a reference to your model and filename is the filename you want the model file written to.

m can be obtained from the call to run_spineopt(). In Spine Toolbox, more particularly the run_SpineOpt tool, you will have m=run_spineopt(). That means that you can call write_model_file(m,filename) in the console once SpineOpt has finished executing and the console remains open.

In either case, here are some tips if you are using this file for debugging. The file can be very large so often it is helpful to create a minimum example of your model with only one or two timesteps. Also, in the call to run_spineopt() you can add the keyword argument optimize=false so it will just build the model and not attempt to solve it.

+Print the model · SpineOpt.jl
GitHub

How to print the model

As the SpineOpt model formulation is quite complex and can change depending on a few parameters (some parts of the formulation can be activated or deactivated), it can be useful to print the model that SpineOpt sends to JuMP. There are a few ways to do this.

The model that SpineOpt sends to JuMP can be saved to a file. It is not the nicest file to read but at the very least you can find the used variables and parameter values.

To write that file you need to set the write_mps_file parameter of the model object to write_mps_always.

SpineOpt will write the file to the working directory. If you are using Spine Toolbox that working directory will be the Spine Toolbox work folder which is typically in your user directory e.g. C:\Users\username\.spinetoolbox\work\run_spineopt_gibberish_toolbox\model_diagnostics.mps

An alternative approach is to directly use the write_model_file(m, filename) command in which m is a reference to your model and filename is the filename you want the model file written to.

m can be obtained from the call to run_spineopt(). In Spine Toolbox, more particularly the run_SpineOpt tool, you will have m=run_spineopt(). That means that you can call write_model_file(m,filename) in the console once SpineOpt has finished executing and the console remains open.

In either case, here are some tips if you are using this file for debugging. The file can be very large so often it is helpful to create a minimum example of your model with only one or two timesteps. Also, in the call to run_spineopt() you can add the keyword argument optimize=false so it will just build the model and not attempt to solve it.

diff --git a/dev/implementation_details/documentation/index.html b/dev/implementation_details/documentation/index.html index 22a0ff84ba..e98d6203c3 100644 --- a/dev/implementation_details/documentation/index.html +++ b/dev/implementation_details/documentation/index.html @@ -44,4 +44,4 @@ markdownstring = SpineOpt.docs_from_instructionlist(alldocs, instructionlist) open(joinpath(mathpath, "objective_function_automatically_generated_file.md"), "w") do file write(file, markdownstring) -end

To deactivate the functionality, remove the code and rename the generated file (such that it is clearer that you now need to change things manually again).

It is also possible to introduce this feature over time. Anytime you want to add the documentation of a constraint to the docstring you need to follow a few steps:

  1. For the docstring
    1. add @doc raw before the docstring (that allows to copy paste the latex already in the current documentation)
    2. add the necessary fields somewhere in the docstring, e.g. #region formulation and #endregion formulation on different lines
  2. For the instructionfile
    1. cut the description and formulation and paste it in the fields of the docstring
    2. write the instruction to point to the correct function and corresponding fields

An example of both the docstring and the instructionfile have already been shown above.

Drag and drop

There is also a drag-and-drop feature for select chapters (e.g. the how to section). For those chapters you can simply add your markdown file to the folder of the chapter and it will be automatically added to the documentation. To allow both manually composed chapters and automatically generated chapter, the functionality is only activated for empty chapters (of the structure "chapter name" => []).

The drag-and-drop function assumes a specific structure for the documentation files.

+end

To deactivate the functionality, remove the code and rename the generated file (such that it is clearer that you now need to change things manually again).

It is also possible to introduce this feature over time. Anytime you want to add the documentation of a constraint to the docstring you need to follow a few steps:

  1. For the docstring
    1. add @doc raw before the docstring (that allows to copy paste the latex already in the current documentation)
    2. add the necessary fields somewhere in the docstring, e.g. #region formulation and #endregion formulation on different lines
  2. For the instructionfile
    1. cut the description and formulation and paste it in the fields of the docstring
    2. write the instruction to point to the correct function and corresponding fields

An example of both the docstring and the instructionfile have already been shown above.

Drag and drop

There is also a drag-and-drop feature for select chapters (e.g. the how to section). For those chapters you can simply add your markdown file to the folder of the chapter and it will be automatically added to the documentation. To allow both manually composed chapters and automatically generated chapter, the functionality is only activated for empty chapters (of the structure "chapter name" => []).

The drag-and-drop function assumes a specific structure for the documentation files.

diff --git a/dev/implementation_details/how_does_the_model_update_itself/index.html b/dev/implementation_details/how_does_the_model_update_itself/index.html index f13f31ed98..a7daac65c2 100644 --- a/dev/implementation_details/how_does_the_model_update_itself/index.html +++ b/dev/implementation_details/how_does_the_model_update_itself/index.html @@ -1,3 +1,3 @@ How does the model update itself · SpineOpt.jl
GitHub

How does the model update itself after rolling?

In SpineOpt, constraints, objective and bounds update themselves automatically whenever the model rolls. To picture this, imagine you have a rolling model with two windows, corresponding to the first and second days of 2023, and daily resolution. (In other words, each window consists of a single time-slice that covers the entire day.) Also, imagine you have a node where the demand is a time-series defined as follows:

timestampvalue
2023-01-015
2023-01-0210

To simplify things, let's say the nodal balance constraint in SpineOpt has the following form:

sum of flows entering the node - sum of flows leaving the node == node's demand
-(for each t in the current window)

You would expect the rhs of this constraint to be 5 for the first window, and 10 for the second window. That is indeed the case, but the way this works under the hood is quite 'magical' so to say.

In SpineOpt, the rhs of the above constraint would be written (roughly) using the following julia expression:

demand[(node=n, t=t, more arguments...)]

Notice the brackets ([]) around the named-tuple with the arguments. Without these (i.e., demand(node=n, t=t, more arguments...)) the expression would evaluate to a number, and the constraint would be static (non-self-updating). But with the brackets, instead of a number, the expression evaluates to a special object of type Call. The important thing about the Call is it remembers the arguments, including the t.

Right before the constraint is passed to the solver, SpineOpt 'realizes' the Call with the current value of t, and computes the actual rhs. So for the first window, where t is the first day in 2023, it will be 5.

Now, whenever SpineOpt rolls forward to solve the next window, it updates the value of t by adding the roll_forward value. (This allows SpineOpt to reuse the same time-slices in all the windows.) But when this happens, the Call is also checked to see if it would return something different now that t has been rolled. And if that's the case, the constraint is automatically updated to reflect the change. In our example, the rhs would become 10 because t is now the second day.

In sum, without the brackets, the constraint would be lhs == 5 (and it would never change), whereas with the brackets, the constraint becomes lhs == the demand at the current value of t.

And the above is valid not only for rhs, but also for any coefficient in any constraint or objective, and for any variable bound.

To see how all this is actually implemented, we suggest you to look at the code of SpineInterface. The starting point is the implementation of Base.getindex for the Parameter type so that writing, e.g., demand[...arguments...] returns a Call that remembers the arguments. From then, we proceed to extend JuMP.jl to handle our Call objects within constraints and objective. The last bit is perhaps the most complex, and consists in storing callbacks inside TimeSlice objects whenever they are used to retrieve the value of a Parameter to build a model. The callbacks are carefully crafted to update a specific part of that model (e.g., a variable coefficient, a variable bound, a constraint rhs). Whenever the TimeSlice rolls, depending on how much it rolls, the appropriate callbacks are called resulting in the model being properly updated. That's roughly it! Hopefully this brief introduction helps (but please contact us if you need more guidance).

+(for each t in the current window)

You would expect the rhs of this constraint to be 5 for the first window, and 10 for the second window. That is indeed the case, but the way this works under the hood is quite 'magical' so to say.

In SpineOpt, the rhs of the above constraint would be written (roughly) using the following julia expression:

demand[(node=n, t=t, more arguments...)]

Notice the brackets ([]) around the named-tuple with the arguments. Without these (i.e., demand(node=n, t=t, more arguments...)) the expression would evaluate to a number, and the constraint would be static (non-self-updating). But with the brackets, instead of a number, the expression evaluates to a special object of type Call. The important thing about the Call is it remembers the arguments, including the t.

Right before the constraint is passed to the solver, SpineOpt 'realizes' the Call with the current value of t, and computes the actual rhs. So for the first window, where t is the first day in 2023, it will be 5.

Now, whenever SpineOpt rolls forward to solve the next window, it updates the value of t by adding the roll_forward value. (This allows SpineOpt to reuse the same time-slices in all the windows.) But when this happens, the Call is also checked to see if it would return something different now that t has been rolled. And if that's the case, the constraint is automatically updated to reflect the change. In our example, the rhs would become 10 because t is now the second day.

In sum, without the brackets, the constraint would be lhs == 5 (and it would never change), whereas with the brackets, the constraint becomes lhs == the demand at the current value of t.

And the above is valid not only for rhs, but also for any coefficient in any constraint or objective, and for any variable bound.

To see how all this is actually implemented, we suggest you to look at the code of SpineInterface. The starting point is the implementation of Base.getindex for the Parameter type so that writing, e.g., demand[...arguments...] returns a Call that remembers the arguments. From then, we proceed to extend JuMP.jl to handle our Call objects within constraints and objective. The last bit is perhaps the most complex, and consists in storing callbacks inside TimeSlice objects whenever they are used to retrieve the value of a Parameter to build a model. The callbacks are carefully crafted to update a specific part of that model (e.g., a variable coefficient, a variable bound, a constraint rhs). Whenever the TimeSlice rolls, depending on how much it rolls, the appropriate callbacks are called resulting in the model being properly updated. That's roughly it! Hopefully this brief introduction helps (but please contact us if you need more guidance).

diff --git a/dev/index.html b/dev/index.html index 5cb85016cb..55b348b91b 100644 --- a/dev/index.html +++ b/dev/index.html @@ -1,2 +1,2 @@ -Introduction · SpineOpt.jl
GitHub

Introduction

SpineOpt.jl is an integrated energy systems optimization model, striving towards adaptability for a multitude of modelling purposes. The data-driven model structure allows for highly customizable energy system descriptions, as well as flexible temporal and stochastic structures, without the need to alter the model source code directly. The methodology is based on mixed-integer linear programming (MILP), and SpineOpt relies on JuMP.jl for interfacing with the different solvers.

While, in principle, it is possible to run SpineOpt by itself, it has been designed to be used through the Spine toolbox, and take maximum advantage of the data and modelling workflow management tools therein. Thus, we highly recommend installing Spine toolbox as well, as outlined in the Installation guide.

Getting Started

As the name implies, this chapter contains guides for starting to use SpineOpt.jl for the first time. The Installation links to the guides how to install SpineOpt.jl and Spine Toolbox on your computer. The Setting up a workflow for SpineOpt in Spine Toolbox section explains how to set up and run SpineOpt.jl from Spine Toolbox. The Creating Your Own Model section explains how to create a new model from scratch. This includes a list of the necessary Object Classes and Relationship Classes, but for more information, you will probably need to consult the Concept Reference chapter.

Tutorials

We learn a lot from examples and that is what you will find in the tutorial chapter. The tutorials come in different shapes: videos, written text and example files. The SpineOpt.jl repository includes a folder examples for ready-made example models. Each example is its own sub-folder, where the input data is provided as .json or .sqlite files. This way, you can easily get a feel for how SpineOpt works with pre-made datasets, either through Spine Toolbox, or directly from the Julia REPL.

How to

The other parts of the documentation are good as a reference when you know what you are looking for but this chapter adds explanations on how to do specific high-level things that might involve multiple elements (e.g. how to print the model).

Concept Reference

This chapter lists and explains all the important data and model structure related concepts to understand in SpineOpt.jl. For a mathematical modelling point of view, see the Mathematical Formulation chapter instead. The Basics of the model structure section briefly explains the general purpose of the most important concepts, like Object Classes and Relationship Classes. Meanwhile, the Object Classes, Relationship Classes, Parameters, and Parameter Value Lists sections contain detailed explanations of each and every aspect of SpineOpt.jl, organized into the respective sections for clarity.

Mathematical Formulation

This chapter provides the mathematical view of SpineOpt.jl, as some of the methodology-related aspects of the model are more easily understood as math than Julia code. The Variables section explains the purpose of each variable in the model, as well as how the variables are related to the different Object Classes and Relationship Classes. The Constraints section contains the mathematical formulation of each constraint, as well as explanations to their purpose and how they are controlled via different Parameters. Finally, the Objective section explains the default objective function used in SpineOpt.jl.

Advanced Concepts

This chapter explains some of the more complicated aspects of SpineOpt.jl in more detail, hopefully making it easier for you to better understand and apply them in your own modelling. The first few sections focus on aspects of SpineOpt.jl that most users are likely to use, or which are more or less required to understand for advanced use. The Temporal Framework section explains how defining time works in SpineOpt.jl, and how it can be used for different purposes. The Stochastic Framework section details how different stochastic structures can be defined, how they interact with each other, and how this impacts writing Constraints in SpineOpt.jl. The Unit commitment section explains how clustered unit-commitment is defined, while the Ramping and Reserves section explains how to enable these operational details in your model. The Investment Optimization section explains how to include investment variables in your models, while the User Constraints section details how to include generic data-driven custom constraints.

The last few sections focus on highly specialized use-cases for SpineOpt.jl, which are unlikely to be relevant for simple modelling tasks. The Decomposition section explains the Benders decomposition implementation included in SpineOpt.jl, as well as how to use it. The remaining sections, namely PTDF-Based Powerflow, Pressure driven gas transfer, Lossless nodal DC power flows, and Representative days with seasonal storages, explain various use-case specific modelling approaches supported by SpineOpt.jl.

Implementation details

For those who are interested in how things work under the hood, this chapter explains some parts of the code. Note that this chapter is particularly sensitive to changes in the code and as such might get out of sync. If you do notice a discrepancy, please create an issue in github. That is also the place to be if you don't find what you are looking for in this documentation.

+Introduction · SpineOpt.jl
GitHub

Introduction

SpineOpt.jl is an integrated energy systems optimization model, striving towards adaptability for a multitude of modelling purposes. The data-driven model structure allows for highly customizable energy system descriptions, as well as flexible temporal and stochastic structures, without the need to alter the model source code directly. The methodology is based on mixed-integer linear programming (MILP), and SpineOpt relies on JuMP.jl for interfacing with the different solvers.

While, in principle, it is possible to run SpineOpt by itself, it has been designed to be used through the Spine toolbox, and take maximum advantage of the data and modelling workflow management tools therein. Thus, we highly recommend installing Spine toolbox as well, as outlined in the Installation guide.

Getting Started

As the name implies, this chapter contains guides for starting to use SpineOpt.jl for the first time. The Installation links to the guides how to install SpineOpt.jl and Spine Toolbox on your computer. The Setting up a workflow for SpineOpt in Spine Toolbox section explains how to set up and run SpineOpt.jl from Spine Toolbox. The Creating Your Own Model section explains how to create a new model from scratch. This includes a list of the necessary Object Classes and Relationship Classes, but for more information, you will probably need to consult the Concept Reference chapter.

Tutorials

We learn a lot from examples and that is what you will find in the tutorial chapter. The tutorials come in different shapes: videos, written text and example files. The SpineOpt.jl repository includes a folder examples for ready-made example models. Each example is its own sub-folder, where the input data is provided as .json or .sqlite files. This way, you can easily get a feel for how SpineOpt works with pre-made datasets, either through Spine Toolbox, or directly from the Julia REPL.

How to

The other parts of the documentation are good as a reference when you know what you are looking for but this chapter adds explanations on how to do specific high-level things that might involve multiple elements (e.g. how to print the model).

Concept Reference

This chapter lists and explains all the important data and model structure related concepts to understand in SpineOpt.jl. For a mathematical modelling point of view, see the Mathematical Formulation chapter instead. The Basics of the model structure section briefly explains the general purpose of the most important concepts, like Object Classes and Relationship Classes. Meanwhile, the Object Classes, Relationship Classes, Parameters, and Parameter Value Lists sections contain detailed explanations of each and every aspect of SpineOpt.jl, organized into the respective sections for clarity.

Mathematical Formulation

This chapter provides the mathematical view of SpineOpt.jl, as some of the methodology-related aspects of the model are more easily understood as math than Julia code. The Variables section explains the purpose of each variable in the model, as well as how the variables are related to the different Object Classes and Relationship Classes. The Constraints section contains the mathematical formulation of each constraint, as well as explanations to their purpose and how they are controlled via different Parameters. Finally, the Objective section explains the default objective function used in SpineOpt.jl.

Advanced Concepts

This chapter explains some of the more complicated aspects of SpineOpt.jl in more detail, hopefully making it easier for you to better understand and apply them in your own modelling. The first few sections focus on aspects of SpineOpt.jl that most users are likely to use, or which are more or less required to understand for advanced use. The Temporal Framework section explains how defining time works in SpineOpt.jl, and how it can be used for different purposes. The Stochastic Framework section details how different stochastic structures can be defined, how they interact with each other, and how this impacts writing Constraints in SpineOpt.jl. The Unit commitment section explains how clustered unit-commitment is defined, while the Ramping and Reserves section explains how to enable these operational details in your model. The Investment Optimization section explains how to include investment variables in your models, while the User Constraints section details how to include generic data-driven custom constraints.

The last few sections focus on highly specialized use-cases for SpineOpt.jl, which are unlikely to be relevant for simple modelling tasks. The Decomposition section explains the Benders decomposition implementation included in SpineOpt.jl, as well as how to use it. The remaining sections, namely PTDF-Based Powerflow, Pressure driven gas transfer, Lossless nodal DC power flows, and Representative days with seasonal storages, explain various use-case specific modelling approaches supported by SpineOpt.jl.

Implementation details

For those who are interested in how things work under the hood, this chapter explains some parts of the code. Note that this chapter is particularly sensitive to changes in the code and as such might get out of sync. If you do notice a discrepancy, please create an issue in github. That is also the place to be if you don't find what you are looking for in this documentation.

diff --git a/dev/library/index.html b/dev/library/index.html index fae1a69707..74c9788e31 100644 --- a/dev/library/index.html +++ b/dev/library/index.html @@ -5,14 +5,14 @@ raw"sqlite:///C:\path\to\your\outputdb.sqlite"; filters=Dict("tool" => "object_activity_control", "scenario" => "scenario_to_run"), alternative="your_results_alternative" -)source
SpineOpt.write_report_from_intermediate_results — Function
write_report_from_intermediate_results(intermediate_results_folder, default_url; <keyword arguments>)

Collect results generated on a previous, unsuccessful SpineOpt run from intermediate_results_folder, and write the corresponding report(s) to url_out. A new Spine database is created at url_out if one doesn't exist.

Arguments

  • alternative::String="": if non empty, write results to the given alternative in the output DB.

  • log_level::Int=3: an integer to control the log level.

source
SpineOpt.generate_forced_availability_factor — Function
generate_forced_availability_factor(url_in, url_out; <keyword arguments>)

Generate forced availability factors (due to outages) from the contents of url_in and write them to url_out. At least url_in must point to a valid Spine database. A new Spine database is created at url_out if one doesn't exist.

To generate forced availability factors for an entity, specify mean_time_to_failure and optionally mean_time_to_repair for that entity as a duration in the input DB.

Parameter forced_availability_factor will be written for those entites in the output DB, holding a time series with the availability factor due to forced outages.

Arguments

  • alternative::String="": if non empty, write results to the given alternative in the output DB.

  • filters::Dict{String,String}=Dict("tool" => "object_activity_control"): a dictionary to specify filters. Possible keys are "tool" and "scenario". Values should be a tool or scenario name in the input DB.

Example

using SpineOpt
+)
source
SpineOpt.write_report_from_intermediate_results — Function
write_report_from_intermediate_results(intermediate_results_folder, default_url; <keyword arguments>)

Collect results generated on a previous, unsuccessful SpineOpt run from intermediate_results_folder, and write the corresponding report(s) to url_out. A new Spine database is created at url_out if one doesn't exist.

Arguments

  • alternative::String="": if non empty, write results to the given alternative in the output DB.

  • log_level::Int=3: an integer to control the log level.

source
SpineOpt.generate_forced_availability_factor — Function
generate_forced_availability_factor(url_in, url_out; <keyword arguments>)

Generate forced availability factors (due to outages) from the contents of url_in and write them to url_out. At least url_in must point to a valid Spine database. A new Spine database is created at url_out if one doesn't exist.

To generate forced availability factors for an entity, specify mean_time_to_failure and optionally mean_time_to_repair for that entity as a duration in the input DB.

Parameter forced_availability_factor will be written for those entites in the output DB, holding a time series with the availability factor due to forced outages.

Arguments

  • alternative::String="": if non empty, write results to the given alternative in the output DB.

  • filters::Dict{String,String}=Dict("tool" => "object_activity_control"): a dictionary to specify filters. Possible keys are "tool" and "scenario". Values should be a tool or scenario name in the input DB.

Example

using SpineOpt
 m = generate_forced_availability_factor(
     raw"sqlite:///C:\path\to\your\inputputdb.sqlite", 
     raw"sqlite:///C:\path\to\your\outputdb.sqlite"
-)
source

TODO

Internals

Variable library

SpineOpt.unit_flow_indices — Function
unit_flow_indices(
+)
source

TODO

Internals

Variable library

SpineOpt.unit_flow_indices — Function
unit_flow_indices(
     unit=anything,
     node=anything,
     direction=anything,
     s=anything
     t=anything
-)

A list of NamedTuples corresponding to indices of the unit_flow variable where the keyword arguments act as filters for each dimension.

source

TODO

Constraint library

TODO

Objective

TODO

+)

A list of NamedTuples corresponding to indices of the unit_flow variable where the keyword arguments act as filters for each dimension.

source

TODO

Constraint library

TODO

Objective

TODO

diff --git a/dev/mathematical_formulation/constraints/index.html b/dev/mathematical_formulation/constraints/index.html index 2504d47cfd..526aca9d31 100644 --- a/dev/mathematical_formulation/constraints/index.html +++ b/dev/mathematical_formulation/constraints/index.html @@ -657,4 +657,4 @@ \end{cases}\\ &+p_{right\_hand\_side}(uc,t,s)\\ &\forall uc,t,s \in constraint\_user\_constraint\_indices\\ -\end{aligned}\]

+\end{aligned}\]

diff --git a/dev/mathematical_formulation/constraints_automatically_generated_file/index.html b/dev/mathematical_formulation/constraints_automatically_generated_file/index.html index 8ef33e0f3f..dba1beb0b4 100644 --- a/dev/mathematical_formulation/constraints_automatically_generated_file/index.html +++ b/dev/mathematical_formulation/constraints_automatically_generated_file/index.html @@ -670,4 +670,4 @@ \end{cases}\\ &+p_{right\_hand\_side}(uc,t,s)\\ &\forall uc,t,s \in constraint\_user\_constraint\_indices\\ -\end{aligned}\]

+\end{aligned}\]

diff --git a/dev/mathematical_formulation/objective_function/index.html b/dev/mathematical_formulation/objective_function/index.html index 58ace60012..245beb3779 100644 --- a/dev/mathematical_formulation/objective_function/index.html +++ b/dev/mathematical_formulation/objective_function/index.html @@ -80,4 +80,4 @@ & v_{objective\_penalties} \\ & = \sum_{\substack{(u,s,t) \in node\_slack\_indices}} \left[v_{node\_slack\_neg}(n, s, t)-v_{node\_slack\_pos}(n, s, t) \right]\cdot p_{node\_slack\_penalty}(n,s,t)\cdot p_{weight}(n,s,t) \cdot p_{duration}(t)\\ -\end{aligned}\]

+\end{aligned}\]

diff --git a/dev/mathematical_formulation/variables/index.html b/dev/mathematical_formulation/variables/index.html index 6fbf48e07e..3b9ac4aacc 100644 --- a/dev/mathematical_formulation/variables/index.html +++ b/dev/mathematical_formulation/variables/index.html @@ -1,2 +1,2 @@ -Variables · SpineOpt.jl
GitHub

Variables

binary_gas_connection_flow

Math symbol: $v_{binary\_gas\_connection\_flow}$

Indices: (connection=conn, node=n, direction=d, stochastic_scenario=s, t=t)

Indices function: binary_gas_connection_flow_indices

Binary variable with the indices node $n$ over the connection $conn$ in the direction $to\_node$ for the stochastic scenario $s$ at timestep $t$ describing if the direction of gas flow for a pressure drive gas transfer is in the indicated direction.

connection_flow

Math symbol: $v_{connection\_flow }$

Indices: (connection=conn, node=n, direction=d, stochastic_scenario=s, t=t)

Indices function: connection_flow_indices

Commodity flow associated with node $n$ over the connection $conn$ in the direction $d$ for the stochastic scenario $s$ at timestep $t$

connection_intact_flow

Math symbol: $v_{connection\_intact\_flow}$

Indices: (connection=conn, node=n, direction=d, stochastic_scenario=s, t=t)

Indices function: connection_intact_flow_indices

Represents the ptdf-based flow on connections where all investment candidate connections are present in the network.

connections_decommissioned

Math symbol: $v_{connections\_decommissioned}$

Indices: (connection=conn, stochastic_scenario=s, t=t)

Indices function: connections_invested_available_indices

Number of decomissioned connections $conn$ for the stochastic scenario $s$ at timestep $t$

connections_invested

Math symbol: $v_{connections\_invested}$

Indices: (connection=conn, stochastic_scenario=s, t=t)

Indices function: connections_invested_available_indices

Number of connections $conn$ invested at timestep $t$ in for the stochastic scenario $s$

connections_invested_available

Math symbol: $v_{connections\_invested\_available}$

Indices: (connection=conn, stochastic_scenario=s, t=t)

Indices function: connections_invested_available_indices

Number of invested connections $conn$ that are available still the stochastic scenario $s$ at timestep $t$

mp_objective_lowerbound_indices

Math symbol: $v_{mp\_objective\_lowerbound\_indices}$

Indices: (t=t)

Indices function: mp_objective_lowerbound_indices

Updating lowerbound for master problem of Benders decomposition

node_injection

Math symbol: $v_{node\_injection}$

Indices: (node=n, stochastic_scenario=s, t=t)

Indices function: node_injection_indices

Commodity injections at node $n$ for the stochastic scenario $s$ at timestep $t$

node_pressure

Math symbol: $v_{node\_pressure}$

Indices: (node=n, stochastic_scenario=s, t=t)

Indices function: node_pressure_indices

Pressue at a node $n$ for a specific stochastic scenario $s$ and timestep $t$. See also: has_pressure

node_slack_neg

Math symbol: $v_{node\_slack\_neg}$

Indices: (node=n, stochastic_scenario=s, t=t)

Indices function: node_slack_indices

Negative slack variable at node $n$ for the stochastic scenario $s$ at timestep $t$

node_slack_pos

Math symbol: $v_{node\_slack\_pos}$

Indices: (node=n, stochastic_scenario=s, t=t)

Indices function: node_slack_indices

Positive slack variable at node $n$ for the stochastic scenario $s$ at timestep $t$

node_state

Math symbol: $v_{node\_state}$

Indices: (node=n, stochastic_scenario=s, t=t)

Indices function: node_state_indices

Storage state at node $n$ for the stochastic scenario $s$ at timestep $t$

node_voltage_angle

Math symbol: $v_{node\_voltage\_angle}$

Indices: (node=n, stochastic_scenario=s, t=t)

Indices function: node_voltage_angle_indices

Voltage angle at a node $n$ for a specific stochastic scenario $s$ and timestep $t$. See also: has_voltage_angle

nonspin_ramp_down_unit_flow

Math symbol: $v_{nonspin\_ramp\_down\_unit\_flow}$

Indices: (unit=u, node=n, direction=d, stochastic_scenario=s, t=t)

Indices function: nonspin_ramp_down_unit_flow_indices

Non-spinning downward reserve commodity flows of unit $u$ at node $n$ in the direction $d$ for the stochastic scenario $s$ at timestep $t$

nonspin_ramp_up_unit_flow

Math symbol: $v_{nonspin\_ramp\_up\_unit\_flow}$

Indices: (unit=u, node=n, direction=d, stochastic_scenario=s, t=t)

Indices function: nonspin_ramp_up_unit_flow_indices

Non-spinning upward reserve commodity flows of unit $u$ at node $n$ in the direction $d$ for the stochastic scenario $s$ at timestep $t$

nonspin_units_shut_down

Math symbol: $v_{nonspin\_units\_shut\_down}$

Indices: (unit=u, node=n, stochastic_scenario=s, t=t)

Indices function: nonspin_units_shut_down_indices

Number of units $u$ held available for non-spinning downward reserve provision via shutdown to node $n$ for the stochastic scenario $s$ at timestep $t$

nonspin_units_started_up

Math symbol: $v_{nonspin\_units\_started\_up}$

Indices: (unit=u, node=n, stochastic_scenario=s, t=t)

Indices function: nonspin_units_started_up_indices

Number of units $u$ held available for non-spinning upward reserve provision via startup to node $n$ for the stochastic scenario $s$ at timestep $t$

ramp_down_unit_flow

Math symbol: $v_{ramp\_down\_unit\_flow}$

Indices: (unit=u, node=n, direction=d, stochastic_scenario=s, t=t)

Indices function: ramp_down_unit_flow_indices

Spinning downward ramp commodity flow associated with node $n$ of unit $u$ with node $n$ over the connection $conn$ in the direction $d$ for the stochastic scenario $s$ at timestep $t$

ramp_up_unit_flow

Math symbol: $v_{ramp\_up\_unit\_flow}$

Indices: (unit=u, node=n, direction=d, stochastic_scenario=s, t=t)

Indices function: ramp_up_unit_flow_indices

Spinning upward ramp commodity flow associated with node $n$ of unit $u$ with node $n$ over the connection $conn$ in the direction $d$ for the stochastic scenario $s$ at timestep $t$

shut_down_unit_flow

Math symbol: $v_{shut\_down\_unit\_flow}$

Indices: (unit=u, node=n, direction=d, stochastic_scenario=s, t=t)

Indices function: shut_down_unit_flow_indices

Downward ramp commodity flow during shutdown associated with node $n$ of unit $u$ with node $n$ over the connection $conn$ in the direction $d$ for the stochastic scenario $s$ at timestep $t$

start_up_unit_flow

Math symbol: $v_{start\_up\_unit\_flow}$

Indices: (unit=u, node=n, direction=d, stochastic_scenario=s, t=t)

Indices function: start_up_unit_flow_indices

Upward ramp commodity flow during start-up associated with node $n$ of unit $u$ with node $n$ over the connection $conn$ in the direction $d$ for the stochastic scenario $s$ at timestep $t$

storages_decommissioned

Math symbol: $v_{storages\_decommissioned}$

Indices: (node=n, stochastic_scenario=s, t=t)

Indices function: storages_invested_available_indices

Number of decomissioned storage nodes $n$ for the stochastic scenario $s$ at timestep $t$

storages_invested

Math symbol: $v_{storages\_invested}$

Indices: (node=n, stochastic_scenario=s, t=t)

Indices function: storages_invested_available_indices

Number of storage nodes $n$ invested in at timestep $t$ for the stochastic scenario $s$

storages_invested_available

Math symbol: $v_{storages\_invested\_available}$

Indices: (node=n, stochastic_scenario=s, t=t)

Indices function: storages_invested_available_indices

Number of invested storage nodes $n$ that are available still the stochastic scenario $s$ at timestep $t$

unit_flow

Math symbol: $v_{unit\_flow}$

Indices: (unit=u, node=n, direction=d, stochastic_scenario=s, t=t)

Indices function: unit_flow_indices

Commodity flow associated with node $n$ over the unit $u$ in the direction $d$ for the stochastic scenario $s$ at timestep $t$

unit_flow_op

Math symbol: $v_{unit\_flow\_op}$

Indices: (unit=u, node=n, direction=d, i=i, stochastic_scenario=s, t=t)

Indices function: unit_flow_op_indices

Contribution of the unit flow assocaited with operating point i

units_available

Math symbol: $v_{units\_available}$

Indices: (unit=u, stochastic_scenario=s, t=t)

Indices function: units_on_indices

Number of available units $u$ for the stochastic scenario $s$ at timestep $t$

units_invested

Math symbol: $v_{units\_invested}$

Indices: (unit=u, stochastic_scenario=s, t=t)

Indices function: units_invested_available_indices

Number of units $u$ for the stochastic scenario $s$ invested in at timestep $t$

units_invested_available

Math symbol: $v_{units\_invested\_available}$

Indices: (unit=u, stochastic_scenario=s, t=t)

Indices function: units_invested_available_indices

Number of invested units $u$ that are available still the stochastic scenario $s$ at timestep $t$

units_mothballed

Math symbol: $v_{units\_mothballed}$

Indices: (unit=u, stochastic_scenario=s, t=t)

Indices function: units_invested_available_indices

Number of units $u$ for the stochastic scenariocenario $s$ mothballed at timestep $t$

units_on

Math symbol: $v_{units\_on}$

Indices: (unit=u, stochastic_scenario=s, t=t)

Indices function: units_on_indices

Number of online units $u$ for the stochastic scenario $s$ at timestep $t$

units_shut_down

Math symbol: $v_{units\_shut\_down}$

Indices: (unit=u, stochastic_scenario=s, t=t)

Indices function: units_on_indices

Number of units $u$ for the stochastic scenario $s$ that switched to offline status at timestep $t$

units_started_up

Math symbol: $v_{units\_started\_up}$

Indices: (unit=u, stochastic_scenario=s, t=t)

Indices function: units_on_indices

Number of units $u$ for the stochastic scenario $s$ that switched to online status at timestep $t$

+Variables · SpineOpt.jl
GitHub

Variables

binary_gas_connection_flow

Math symbol: $v_{binary\_gas\_connection\_flow}$

Indices: (connection=conn, node=n, direction=d, stochastic_scenario=s, t=t)

Indices function: binary_gas_connection_flow_indices

Binary variable with the indices node $n$ over the connection $conn$ in the direction $to\_node$ for the stochastic scenario $s$ at timestep $t$ describing if the direction of gas flow for a pressure drive gas transfer is in the indicated direction.

connection_flow

Math symbol: $v_{connection\_flow }$

Indices: (connection=conn, node=n, direction=d, stochastic_scenario=s, t=t)

Indices function: connection_flow_indices

Commodity flow associated with node $n$ over the connection $conn$ in the direction $d$ for the stochastic scenario $s$ at timestep $t$

connection_intact_flow

Math symbol: $v_{connection\_intact\_flow}$

Indices: (connection=conn, node=n, direction=d, stochastic_scenario=s, t=t)

Indices function: connection_intact_flow_indices

Represents the ptdf-based flow on connections where all investment candidate connections are present in the network.

connections_decommissioned

Math symbol: $v_{connections\_decommissioned}$

Indices: (connection=conn, stochastic_scenario=s, t=t)

Indices function: connections_invested_available_indices

Number of decomissioned connections $conn$ for the stochastic scenario $s$ at timestep $t$

connections_invested

Math symbol: $v_{connections\_invested}$

Indices: (connection=conn, stochastic_scenario=s, t=t)

Indices function: connections_invested_available_indices

Number of connections $conn$ invested at timestep $t$ in for the stochastic scenario $s$

connections_invested_available

Math symbol: $v_{connections\_invested\_available}$

Indices: (connection=conn, stochastic_scenario=s, t=t)

Indices function: connections_invested_available_indices

Number of invested connections $conn$ that are available still the stochastic scenario $s$ at timestep $t$

mp_objective_lowerbound_indices

Math symbol: $v_{mp\_objective\_lowerbound\_indices}$

Indices: (t=t)

Indices function: mp_objective_lowerbound_indices

Updating lowerbound for master problem of Benders decomposition

node_injection

Math symbol: $v_{node\_injection}$

Indices: (node=n, stochastic_scenario=s, t=t)

Indices function: node_injection_indices

Commodity injections at node $n$ for the stochastic scenario $s$ at timestep $t$

node_pressure

Math symbol: $v_{node\_pressure}$

Indices: (node=n, stochastic_scenario=s, t=t)

Indices function: node_pressure_indices

Pressue at a node $n$ for a specific stochastic scenario $s$ and timestep $t$. See also: has_pressure

node_slack_neg

Math symbol: $v_{node\_slack\_neg}$

Indices: (node=n, stochastic_scenario=s, t=t)

Indices function: node_slack_indices

Negative slack variable at node $n$ for the stochastic scenario $s$ at timestep $t$

node_slack_pos

Math symbol: $v_{node\_slack\_pos}$

Indices: (node=n, stochastic_scenario=s, t=t)

Indices function: node_slack_indices

Positive slack variable at node $n$ for the stochastic scenario $s$ at timestep $t$

node_state

Math symbol: $v_{node\_state}$

Indices: (node=n, stochastic_scenario=s, t=t)

Indices function: node_state_indices

Storage state at node $n$ for the stochastic scenario $s$ at timestep $t$

node_voltage_angle

Math symbol: $v_{node\_voltage\_angle}$

Indices: (node=n, stochastic_scenario=s, t=t)

Indices function: node_voltage_angle_indices

Voltage angle at a node $n$ for a specific stochastic scenario $s$ and timestep $t$. See also: has_voltage_angle

nonspin_ramp_down_unit_flow

Math symbol: $v_{nonspin\_ramp\_down\_unit\_flow}$

Indices: (unit=u, node=n, direction=d, stochastic_scenario=s, t=t)

Indices function: nonspin_ramp_down_unit_flow_indices

Non-spinning downward reserve commodity flows of unit $u$ at node $n$ in the direction $d$ for the stochastic scenario $s$ at timestep $t$

nonspin_ramp_up_unit_flow

Math symbol: $v_{nonspin\_ramp\_up\_unit\_flow}$

Indices: (unit=u, node=n, direction=d, stochastic_scenario=s, t=t)

Indices function: nonspin_ramp_up_unit_flow_indices

Non-spinning upward reserve commodity flows of unit $u$ at node $n$ in the direction $d$ for the stochastic scenario $s$ at timestep $t$

nonspin_units_shut_down

Math symbol: $v_{nonspin\_units\_shut\_down}$

Indices: (unit=u, node=n, stochastic_scenario=s, t=t)

Indices function: nonspin_units_shut_down_indices

Number of units $u$ held available for non-spinning downward reserve provision via shutdown to node $n$ for the stochastic scenario $s$ at timestep $t$

nonspin_units_started_up

Math symbol: $v_{nonspin\_units\_started\_up}$

Indices: (unit=u, node=n, stochastic_scenario=s, t=t)

Indices function: nonspin_units_started_up_indices

Number of units $u$ held available for non-spinning upward reserve provision via startup to node $n$ for the stochastic scenario $s$ at timestep $t$

ramp_down_unit_flow

Math symbol: $v_{ramp\_down\_unit\_flow}$

Indices: (unit=u, node=n, direction=d, stochastic_scenario=s, t=t)

Indices function: ramp_down_unit_flow_indices

Spinning downward ramp commodity flow associated with node $n$ of unit $u$ with node $n$ over the connection $conn$ in the direction $d$ for the stochastic scenario $s$ at timestep $t$

ramp_up_unit_flow

Math symbol: $v_{ramp\_up\_unit\_flow}$

Indices: (unit=u, node=n, direction=d, stochastic_scenario=s, t=t)

Indices function: ramp_up_unit_flow_indices

Spinning upward ramp commodity flow associated with node $n$ of unit $u$ with node $n$ over the connection $conn$ in the direction $d$ for the stochastic scenario $s$ at timestep $t$

shut_down_unit_flow

Math symbol: $v_{shut\_down\_unit\_flow}$

Indices: (unit=u, node=n, direction=d, stochastic_scenario=s, t=t)

Indices function: shut_down_unit_flow_indices

Downward ramp commodity flow during shutdown associated with node $n$ of unit $u$ with node $n$ over the connection $conn$ in the direction $d$ for the stochastic scenario $s$ at timestep $t$

start_up_unit_flow

Math symbol: $v_{start\_up\_unit\_flow}$

Indices: (unit=u, node=n, direction=d, stochastic_scenario=s, t=t)

Indices function: start_up_unit_flow_indices

Upward ramp commodity flow during start-up associated with node $n$ of unit $u$ with node $n$ over the connection $conn$ in the direction $d$ for the stochastic scenario $s$ at timestep $t$

storages_decommissioned

Math symbol: $v_{storages\_decommissioned}$

Indices: (node=n, stochastic_scenario=s, t=t)

Indices function: storages_invested_available_indices

Number of decomissioned storage nodes $n$ for the stochastic scenario $s$ at timestep $t$

storages_invested

Math symbol: $v_{storages\_invested}$

Indices: (node=n, stochastic_scenario=s, t=t)

Indices function: storages_invested_available_indices

Number of storage nodes $n$ invested in at timestep $t$ for the stochastic scenario $s$

storages_invested_available

Math symbol: $v_{storages\_invested\_available}$

Indices: (node=n, stochastic_scenario=s, t=t)

Indices function: storages_invested_available_indices

Number of invested storage nodes $n$ that are available still the stochastic scenario $s$ at timestep $t$

unit_flow

Math symbol: $v_{unit\_flow}$

Indices: (unit=u, node=n, direction=d, stochastic_scenario=s, t=t)

Indices function: unit_flow_indices

Commodity flow associated with node $n$ over the unit $u$ in the direction $d$ for the stochastic scenario $s$ at timestep $t$

unit_flow_op

Math symbol: $v_{unit\_flow\_op}$

Indices: (unit=u, node=n, direction=d, i=i, stochastic_scenario=s, t=t)

Indices function: unit_flow_op_indices

Contribution of the unit flow assocaited with operating point i

units_available

Math symbol: $v_{units\_available}$

Indices: (unit=u, stochastic_scenario=s, t=t)

Indices function: units_on_indices

Number of available units $u$ for the stochastic scenario $s$ at timestep $t$

units_invested

Math symbol: $v_{units\_invested}$

Indices: (unit=u, stochastic_scenario=s, t=t)

Indices function: units_invested_available_indices

Number of units $u$ for the stochastic scenario $s$ invested in at timestep $t$

units_invested_available

Math symbol: $v_{units\_invested\_available}$

Indices: (unit=u, stochastic_scenario=s, t=t)

Indices function: units_invested_available_indices

Number of invested units $u$ that are available still the stochastic scenario $s$ at timestep $t$

units_mothballed

Math symbol: $v_{units\_mothballed}$

Indices: (unit=u, stochastic_scenario=s, t=t)

Indices function: units_invested_available_indices

Number of units $u$ for the stochastic scenariocenario $s$ mothballed at timestep $t$

units_on

Math symbol: $v_{units\_on}$

Indices: (unit=u, stochastic_scenario=s, t=t)

Indices function: units_on_indices

Number of online units $u$ for the stochastic scenario $s$ at timestep $t$

units_shut_down

Math symbol: $v_{units\_shut\_down}$

Indices: (unit=u, stochastic_scenario=s, t=t)

Indices function: units_on_indices

Number of units $u$ for the stochastic scenario $s$ that switched to offline status at timestep $t$

units_started_up

Math symbol: $v_{units\_started\_up}$

Indices: (unit=u, stochastic_scenario=s, t=t)

Indices function: units_on_indices

Number of units $u$ for the stochastic scenario $s$ that switched to online status at timestep $t$

diff --git a/dev/tutorial/case_study_a5/index.html b/dev/tutorial/case_study_a5/index.html index ec1e5b473a..e8e0f5ae4d 100644 --- a/dev/tutorial/case_study_a5/index.html +++ b/dev/tutorial/case_study_a5/index.html @@ -13,4 +13,4 @@ Granfors_pwr_plant Krångfors_pwr_plant Selsfors_pwr_plant - Kvistforsen_pwr_plant
  • Go to Object tree (on the top left of the window, usually), right-click on unit and select Add objects from the context menu. This will open the Add objects dialog.
  • Select the first cell under the object name column and press Ctrl+V. This will paste the list of plant names from the clipboard into that column; the object class name column will be filled automatically with ‘unit‘. The form should now be looking similar to this: image
  • Click Ok.
  • Back in the Spine DB Editor, under Object tree, double click on unit to confirm that the objects are effectively there.
  • Commit changes with the message ‘Add power plants’.

  • Add discharge and spillway connections by creating objects of class connection with the following names:

    RebnistoBergnäsdisch SadvatoBergnäsdisch BergnästoSlagnäsdisch SlagnästoBastuseldisch BastuseltoGrytforsdisch GrytforstoGallejaurdisch GallejaurtoVargforsdisch VargforstoRengårddisch RengårdtoBåtforsdisch BåtforstoFinnforsdisch FinnforstoGranforsdisch GranforstoKrångforsdisch KrångforstoSelsforsdisch SelsforstoKvistforsendisch Kvistforsentodownstreamdisch RebnistoBergnässpill SadvatoBergnässpill BergnästoSlagnässpill SlagnästoBastuselspill BastuseltoGrytforsspill GrytforstoGallejaurspill GallejaurtoVargforsspill VargforstoRengårdspill RengårdtoBåtforsspill BåtforstoFinnforsspill FinnforstoGranforsspill GranforstoKrångforsspill KrångforstoSelsforsspill SelsforstoKvistforsenspill Kvistforsentodownstreamspill

  • Add water nodes by creating objects of class node with the following names:

    Rebnisupper Sadvaupper Bergnäsupper Slagnäsupper Bastuselupper Grytforsupper Gallejaurupper Vargforsupper Rengårdupper Båtforsupper Finnforsupper Granforsupper Krångforsupper Selsforsupper Kvistforsenupper Rebnislower Sadvalower Bergnäslower Slagnäslower Bastusellower Grytforslower Gallejaurlower Vargforslower Rengårdlower Båtforslower Finnforslower Granforslower Krångforslower Selsforslower Kvistforsenlower

  • Next, create the following objects (all names in lower-case):

  • Finally, create the following objects to get results back from SpineOpt (again, all names in lower-case):

    • Note

    To modify an object after you enter it, right click on it and select Edit... from the context menu.

    Specifying object parameter values

    Establishing relationships

    Tip

    To enter the same text on several cells, copy the text into the clipboard, then select all target cells and press Ctrl+V.

    Note

    At this point, you might be wondering what's the purpose of the unit__node__node relationship class. Shouldn't it be enough to have unit__from_node and unit__to_node to represent the topology of the system? The answer is yes; but in addition to topology, we also need to represent the conversion process that happens in the unit, where the water from one node is turned into electricty for another node. And for this purpose, we use a relationship parameter value on the unit__node__node relationships (see Specifying relationship parameter values).

    Note

    At this point, you might be wondering what's the purpose of the connection__node__node relationship class. Shouldn't it be enough to have connection__from_node and connection__to_node to represent the topology of the system? The answer is yes; but in addition to topology, we also need to represent the delay in the river branches. And for this purpose, we use a relationship parameter value on the connection__node__node relationships (see Specifying relationship parameter values).

    Specifying parameter values of the relationships

    Using the Importer

    Additional Steps for Project Setup

    Importing the model

    Executing the workflow

    Once the workflow is defined and input data is in place, the project is ready to be executed. Hit the Execute project button image on the tool bar.

    You should see ‘Executing All Directed Acyclic Graphs’ printed in the Event log (on the lower left by default). SpineOpt output messages will appear in the Process Log panel in the middle. After some processing, ‘DAG 1/1 completed successfully’ appears and the execution is complete.

    Examining the results

    Select the output data store and open the Spine DB editor.

    image

    To checkout the flow on the electricity load (i.e., the total electricity production in the system), go to Object tree, expand the unit object class, and select electricity_load, as illustrated in the picture above. Next, go to Relationship parameter value and double-click the first cell under value. The Parameter value editor will pop up. You should see something like this:

    image

    Note

    If you have used the importer to instantiate the model you can easily modify the parameters in the model worksheet, run the project and observe the differences in the results. If you need to make changes directly to the input database, in order for the importer not to overwrite them, you will need to dissassociate the importer from the input DB (right click in the connecting yellow arrow between the two items and click on remove).

    + Kvistforsen_pwr_plant
  • Go to Object tree (on the top left of the window, usually), right-click on unit and select Add objects from the context menu. This will open the Add objects dialog.
  • Select the first cell under the object name column and press Ctrl+V. This will paste the list of plant names from the clipboard into that column; the object class name column will be filled automatically with ‘unit‘. The form should now be looking similar to this: image
  • Click Ok.
  • Back in the Spine DB Editor, under Object tree, double click on unit to confirm that the objects are effectively there.
  • Commit changes with the message ‘Add power plants’.

  • Add discharge and spillway connections by creating objects of class connection with the following names:

    RebnistoBergnäsdisch SadvatoBergnäsdisch BergnästoSlagnäsdisch SlagnästoBastuseldisch BastuseltoGrytforsdisch GrytforstoGallejaurdisch GallejaurtoVargforsdisch VargforstoRengårddisch RengårdtoBåtforsdisch BåtforstoFinnforsdisch FinnforstoGranforsdisch GranforstoKrångforsdisch KrångforstoSelsforsdisch SelsforstoKvistforsendisch Kvistforsentodownstreamdisch RebnistoBergnässpill SadvatoBergnässpill BergnästoSlagnässpill SlagnästoBastuselspill BastuseltoGrytforsspill GrytforstoGallejaurspill GallejaurtoVargforsspill VargforstoRengårdspill RengårdtoBåtforsspill BåtforstoFinnforsspill FinnforstoGranforsspill GranforstoKrångforsspill KrångforstoSelsforsspill SelsforstoKvistforsenspill Kvistforsentodownstreamspill

  • Add water nodes by creating objects of class node with the following names:

    Rebnisupper Sadvaupper Bergnäsupper Slagnäsupper Bastuselupper Grytforsupper Gallejaurupper Vargforsupper Rengårdupper Båtforsupper Finnforsupper Granforsupper Krångforsupper Selsforsupper Kvistforsenupper Rebnislower Sadvalower Bergnäslower Slagnäslower Bastusellower Grytforslower Gallejaurlower Vargforslower Rengårdlower Båtforslower Finnforslower Granforslower Krångforslower Selsforslower Kvistforsenlower

  • Next, create the following objects (all names in lower-case):

  • Finally, create the following objects to get results back from SpineOpt (again, all names in lower-case):

    • Note

    To modify an object after you enter it, right click on it and select Edit... from the context menu.

    Specifying object parameter values

    Establishing relationships

    Tip

    To enter the same text on several cells, copy the text into the clipboard, then select all target cells and press Ctrl+V.

    Note

    At this point, you might be wondering what's the purpose of the unit__node__node relationship class. Shouldn't it be enough to have unit__from_node and unit__to_node to represent the topology of the system? The answer is yes; but in addition to topology, we also need to represent the conversion process that happens in the unit, where the water from one node is turned into electricty for another node. And for this purpose, we use a relationship parameter value on the unit__node__node relationships (see Specifying relationship parameter values).

    Note

    At this point, you might be wondering what's the purpose of the connection__node__node relationship class. Shouldn't it be enough to have connection__from_node and connection__to_node to represent the topology of the system? The answer is yes; but in addition to topology, we also need to represent the delay in the river branches. And for this purpose, we use a relationship parameter value on the connection__node__node relationships (see Specifying relationship parameter values).

    Specifying parameter values of the relationships

    Using the Importer

    Additional Steps for Project Setup

    Importing the model

    Executing the workflow

    Once the workflow is defined and input data is in place, the project is ready to be executed. Hit the Execute project button image on the tool bar.

    You should see ‘Executing All Directed Acyclic Graphs’ printed in the Event log (on the lower left by default). SpineOpt output messages will appear in the Process Log panel in the middle. After some processing, ‘DAG 1/1 completed successfully’ appears and the execution is complete.

    Examining the results

    Select the output data store and open the Spine DB editor.

    image

    To checkout the flow on the electricity load (i.e., the total electricity production in the system), go to Object tree, expand the unit object class, and select electricity_load, as illustrated in the picture above. Next, go to Relationship parameter value and double-click the first cell under value. The Parameter value editor will pop up. You should see something like this:

    image

    Note

    If you have used the importer to instantiate the model you can easily modify the parameters in the model worksheet, run the project and observe the differences in the results. If you need to make changes directly to the input database, in order for the importer not to overwrite them, you will need to dissassociate the importer from the input DB (right click in the connecting yellow arrow between the two items and click on remove).

    diff --git a/dev/tutorial/simple_system/index.html b/dev/tutorial/simple_system/index.html index e4846a729e..9598d15530 100644 --- a/dev/tutorial/simple_system/index.html +++ b/dev/tutorial/simple_system/index.html @@ -1,2 +1,2 @@ -Simple system · SpineOpt.jl
    GitHub

    Simple System tutorial

    Welcome to Spine Toolbox's Simple System tutorial.

    This tutorial provides a step-by-step guide to setup a simple energy system on Spine Toolbox.

    Introduction

    Model assumptions

    • Two power plants take fuel from a source node and release electricity to another node in order to supply a demand.
    • Power plant 'a' has a capacity of 100 MWh, a variable operating cost of 25 euro/fuel unit, and generates 0.7 MWh of electricity per unit of fuel.
    • Power plant 'b' has a capacity of 200 MWh, a variable operating cost of 50 euro/fuel unit, and generates 0.8 MWh of electricity per unit of fuel.
    • The demand at the electricity node is 150 MWh.
    • The fuel node is able to provide infinite energy.

    image

    Installation and upgrades

    If you haven't yet installed the tools yet, please follow the installation guides:

    If you are not sure whether you have the latest version, please upgrade to ensure compatibility with this guide.

    • For Spine Toolbox:

      • If installed with pipx, then use python -m pipx upgrade spinetoolbox
      • If installed from sources using git, then git pull, python -m pip install -U -r requirements.txt

    • For SpineOpt: SpineOpt upgrade guide

    Guide

    Entering input data

    Importing the SpineOpt database template

    • Download the SpineOpt database template and the basic SpineOpt model (right click on the links, then select Save link as...)

    • Select the 'input' Data Store item in the Design View.

    • Go to Data Store Properties and hit Open editor. This will open the newly created database in the Spine DB editor, looking similar to this:

    image

    Note

    The Spine DB editor is a dedicated interface within Spine Toolbox for visualizing and managing Spine databases.

    • Press Alt + F to display the main menu, select File -> Import..., and then select the template file you previously downloaded (spineopt_template.json). The contents of that file will be imported into the current database, and you should then see classes like 'commodity', 'connection' and 'model' under the root node in the Object tree (on the left). Then import the second file (basic_model_template.json).

    • From the main menu, select Session -> Commit. Enter 'Import SpineOpt template' as message in the popup dialog, and click Commit.

    Note

    The SpineOpt basic template contains (i) the fundamental entity classes and parameter definitions that SpineOpt recognizes and expects; and (ii) some predefined entities for a common deterministic model with a 'flat' temporal structure.

    Creating objects

    • Always in the Spine DB editor, locate the Object tree (typically at the top-left). Expand the [root] element if not expanded.

    • Right click on the [node] class, and select Add objects from the context menu. The Add objects dialog will pop up.

    • Enter the names for the system nodes as seen in the image below, then press Ok. This will create two objects of class node, called fuel_node and electricity_node.

    image

    • Right click on the unit class, and select Add objects from the context menu. The Add objects dialog will pop up.
    Note

    In SpineOpt, nodes are points where an energy balance takes place, whereas units are energy conversion devices that can take energy from nodes, and release energy to nodes.

    • Enter the names for the system units as seen in the image below, then press Ok. This will create two objects of class unit, called power_plant_a and power_plant_b.

    image

    Note

    To modify an object after you enter it, right click on it and select Edit... from the context menu.

    Establishing relationships

    • Always in the Spine DB editor, locate the Relationship tree (typically at the bottom-left). Expand the root element if not expanded.

    • Right click on the unit__from_node class, and select Add relationships from the context menu. The Add relationships dialog will pop up.

    • Select the names of the two units and their sending nodes, as seen in the image below; then press Ok. This will establish that both power_plant_a and power_plant_b take energy from the fuel_node.

    image

    • Right click on the unit__to_node class, and select Add relationships from the context menu. The Add relationships dialog will pop up.

    • Select the names of the two units and their receiving nodes, as seen in the image below; then press Ok. This will establish that both power_plant_a and power_plant_b release energy into the electricity_node.

    image

    • Right click on the report__output class, and select Add relationships from the context menu. The Add relationships dialog will pop up.

    • Enter report1 under report, and unit_flow under output, as seen in the image below; then press Ok. This will tell SpineOpt to write the value of the unit_flow optimization variable to the output database, as part of report1.

    image

    Note

    In SpineOpt, outputs represent optimization variables that can be written to the output database as part of a report.

    Specifying object parameter values

    • Back to Object tree, expand the node class and select electricity_node.

    • Locate the Object parameter table (typically at the top-center).

    • In the Object parameter table (typically at the top-center), select the demand parameter and the Base alternative, and enter the value 100 as seen in the image below. This will establish that there's a demand of '100' at the electricity node.

    image

    • Select fuel_node in the Object tree.

    • In the Object parameter table, select the balance_type parameter and the Base alternative, and enter the value balance_type_none as seen in the image below. This will establish that the fuel node is not balanced, and thus provide as much fuel as needed.

    image

    Specifying relationship parameter values

    • In Relationship tree, expand the unit__from_node class and select power_plant_a | fuel_node.

    • In the Relationship parameter table (typically at the bottom-center), select the vom_cost parameter and the Base alternative, and enter the value 25 as seen in the image below. This will set the operating cost for power_plant_a.

    image

    • Select power_plant_b | fuel_node in the Relationship tree.

    • In the Relationship parameter table, select the vom_cost parameter and the Base alternative, and enter the value 50 as seen in the image below. This will set the operating cost for power_plant_b.

    image

    • In Relationship tree, expand the unit__to_node class and select power_plant_a | electricity_node.

    • In the Relationship parameter table, select the unit_capacity parameter and the Base alternative, and enter the value 100 as seen in the image below. This will set the capacity for power_plant_a.

    image

    • Select power_plant_b | electricity_node in the Relationship tree.

    • In the Relationship parameter table, select the unit_capacity parameter and the Base alternative, and enter the value 200 as seen in the image below. This will set the capacity for power_plant_b.

    image

    • In Relationship tree, select the unit__node__node class, and come back to the Relationship parameter table.

    • In the Relationship parameter table, select power_plant_a | electricity_node | fuel_node under object name list, fix_ratio_out_in_unit_flow under parameter name, Base under alternative name, and enter 0.7 under value. Repeat the operation for power_plant_b, but this time enter 0.8 under value. This will set the conversion ratio from fuel to electricity for power_plant_a and power_plant_b to 0.7 and 0.8, respectively. It should like the image below.

    image

    When you're ready, commit all changes to the database.

    Executing the workflow

    • Go back to Spine Toolbox's main window, and hit the Execute project button image from the tool bar. You should see 'Executing All Directed Acyclic Graphs' printed in the Event log (at the bottom left by default).

    • Select the 'Run SpineOpt 1' Tool. You should see the output from SpineOpt in the Julia Console.

    Examining the results

    • Select the output data store and open the Spine DB editor.
    • Press Alt + F to display the main menu, and select Pivot -> Index.
    • Select report__unit__node__direction__stochastic_scenario under Relationship tree, and the first cell under alternative in the Frozen table.
    • Under alternative in the Frozen table, you can choose results from different runs. Pick the run you want to view. If the workflow has been run several times, the most recent run will usually be found at the bottom.
    • The Pivot table will be populated with results from the SpineOpt run. It will look something like the image below.

    image

    +Simple system · SpineOpt.jl
    GitHub

    Simple System tutorial

    Welcome to Spine Toolbox's Simple System tutorial.

    This tutorial provides a step-by-step guide to setup a simple energy system on Spine Toolbox.

    Introduction

    Model assumptions

    • Two power plants take fuel from a source node and release electricity to another node in order to supply a demand.
    • Power plant 'a' has a capacity of 100 MWh, a variable operating cost of 25 euro/fuel unit, and generates 0.7 MWh of electricity per unit of fuel.
    • Power plant 'b' has a capacity of 200 MWh, a variable operating cost of 50 euro/fuel unit, and generates 0.8 MWh of electricity per unit of fuel.
    • The demand at the electricity node is 150 MWh.
    • The fuel node is able to provide infinite energy.

    image

    Installation and upgrades

    If you haven't yet installed the tools yet, please follow the installation guides:

    If you are not sure whether you have the latest version, please upgrade to ensure compatibility with this guide.

    • For Spine Toolbox:

      • If installed with pipx, then use python -m pipx upgrade spinetoolbox
      • If installed from sources using git, then git pull, python -m pip install -U -r requirements.txt

    • For SpineOpt: SpineOpt upgrade guide

    Guide

    Entering input data

    Importing the SpineOpt database template

    • Download the SpineOpt database template and the basic SpineOpt model (right click on the links, then select Save link as...)

    • Select the 'input' Data Store item in the Design View.

    • Go to Data Store Properties and hit Open editor. This will open the newly created database in the Spine DB editor, looking similar to this:

    image

    Note

    The Spine DB editor is a dedicated interface within Spine Toolbox for visualizing and managing Spine databases.

    • Press Alt + F to display the main menu, select File -> Import..., and then select the template file you previously downloaded (spineopt_template.json). The contents of that file will be imported into the current database, and you should then see classes like 'commodity', 'connection' and 'model' under the root node in the Object tree (on the left). Then import the second file (basic_model_template.json).

    • From the main menu, select Session -> Commit. Enter 'Import SpineOpt template' as message in the popup dialog, and click Commit.

    Note

    The SpineOpt basic template contains (i) the fundamental entity classes and parameter definitions that SpineOpt recognizes and expects; and (ii) some predefined entities for a common deterministic model with a 'flat' temporal structure.

    Creating objects

    • Always in the Spine DB editor, locate the Object tree (typically at the top-left). Expand the [root] element if not expanded.

    • Right click on the [node] class, and select Add objects from the context menu. The Add objects dialog will pop up.

    • Enter the names for the system nodes as seen in the image below, then press Ok. This will create two objects of class node, called fuel_node and electricity_node.

    image

    • Right click on the unit class, and select Add objects from the context menu. The Add objects dialog will pop up.
    Note

    In SpineOpt, nodes are points where an energy balance takes place, whereas units are energy conversion devices that can take energy from nodes, and release energy to nodes.

    • Enter the names for the system units as seen in the image below, then press Ok. This will create two objects of class unit, called power_plant_a and power_plant_b.

    image

    Note

    To modify an object after you enter it, right click on it and select Edit... from the context menu.

    Establishing relationships

    • Always in the Spine DB editor, locate the Relationship tree (typically at the bottom-left). Expand the root element if not expanded.

    • Right click on the unit__from_node class, and select Add relationships from the context menu. The Add relationships dialog will pop up.

    • Select the names of the two units and their sending nodes, as seen in the image below; then press Ok. This will establish that both power_plant_a and power_plant_b take energy from the fuel_node.

    image

    • Right click on the unit__to_node class, and select Add relationships from the context menu. The Add relationships dialog will pop up.

    • Select the names of the two units and their receiving nodes, as seen in the image below; then press Ok. This will establish that both power_plant_a and power_plant_b release energy into the electricity_node.

    image

    • Right click on the report__output class, and select Add relationships from the context menu. The Add relationships dialog will pop up.

    • Enter report1 under report, and unit_flow under output, as seen in the image below; then press Ok. This will tell SpineOpt to write the value of the unit_flow optimization variable to the output database, as part of report1.

    image

    Note

    In SpineOpt, outputs represent optimization variables that can be written to the output database as part of a report.

    Specifying object parameter values

    • Back to Object tree, expand the node class and select electricity_node.

    • Locate the Object parameter table (typically at the top-center).

    • In the Object parameter table (typically at the top-center), select the demand parameter and the Base alternative, and enter the value 100 as seen in the image below. This will establish that there's a demand of '100' at the electricity node.

    image

    • Select fuel_node in the Object tree.

    • In the Object parameter table, select the balance_type parameter and the Base alternative, and enter the value balance_type_none as seen in the image below. This will establish that the fuel node is not balanced, and thus provide as much fuel as needed.

    image

    Specifying relationship parameter values

    • In Relationship tree, expand the unit__from_node class and select power_plant_a | fuel_node.

    • In the Relationship parameter table (typically at the bottom-center), select the vom_cost parameter and the Base alternative, and enter the value 25 as seen in the image below. This will set the operating cost for power_plant_a.

    image

    • Select power_plant_b | fuel_node in the Relationship tree.

    • In the Relationship parameter table, select the vom_cost parameter and the Base alternative, and enter the value 50 as seen in the image below. This will set the operating cost for power_plant_b.

    image

    • In Relationship tree, expand the unit__to_node class and select power_plant_a | electricity_node.

    • In the Relationship parameter table, select the unit_capacity parameter and the Base alternative, and enter the value 100 as seen in the image below. This will set the capacity for power_plant_a.

    image

    • Select power_plant_b | electricity_node in the Relationship tree.

    • In the Relationship parameter table, select the unit_capacity parameter and the Base alternative, and enter the value 200 as seen in the image below. This will set the capacity for power_plant_b.

    image

    • In Relationship tree, select the unit__node__node class, and come back to the Relationship parameter table.

    • In the Relationship parameter table, select power_plant_a | electricity_node | fuel_node under object name list, fix_ratio_out_in_unit_flow under parameter name, Base under alternative name, and enter 0.7 under value. Repeat the operation for power_plant_b, but this time enter 0.8 under value. This will set the conversion ratio from fuel to electricity for power_plant_a and power_plant_b to 0.7 and 0.8, respectively. It should like the image below.

    image

    When you're ready, commit all changes to the database.

    Executing the workflow

    • Go back to Spine Toolbox's main window, and hit the Execute project button image from the tool bar. You should see 'Executing All Directed Acyclic Graphs' printed in the Event log (at the bottom left by default).

    • Select the 'Run SpineOpt 1' Tool. You should see the output from SpineOpt in the Julia Console.

    Examining the results

    • Select the output data store and open the Spine DB editor.
    • Press Alt + F to display the main menu, and select Pivot -> Index.
    • Select report__unit__node__direction__stochastic_scenario under Relationship tree, and the first cell under alternative in the Frozen table.
    • Under alternative in the Frozen table, you can choose results from different runs. Pick the run you want to view. If the workflow has been run several times, the most recent run will usually be found at the bottom.
    • The Pivot table will be populated with results from the SpineOpt run. It will look something like the image below.

    image

    diff --git a/dev/tutorial/tutorialTwoHydro/index.html b/dev/tutorial/tutorialTwoHydro/index.html index 1fd6c32850..39562323d3 100644 --- a/dev/tutorial/tutorialTwoHydro/index.html +++ b/dev/tutorial/tutorialTwoHydro/index.html @@ -1,2 +1,2 @@ -Two hydro plants · SpineOpt.jl
    GitHub

    Hydro Power Planning

    Welcome to this Spine Toolbox tutorial for building hydro power planning models. The tutorial guides you through the implementation of different ways of modelling hydrodologically-coupled hydropower systems.

    Introduction

    This tutorial aims at demonstrating how we can model a hydropower system in Spine (SpineOpt.jl and Spine-Toolbox) with different assumptions and goals. It starts off by setting up a simple model of system of two hydropower plants and gradually introduces additional features. The goal of the model is to capture the combined operation of two hydropower plants (Språnget and Fallet) that operate on the same river as shown in the picture bellow. Each power plant has its own reservoir and generates electricity by discharging water. The plants might need to spill water, i.e., release water from their reservoirs without generating electricity, for various reasons. The water discharged or spilled by the upstream power plant follows the river route and becomes available to the downstream power plant.

    A system of two hydropower plants.

    A system of two hydropower plants

    In order to run this tutorial you must first execute some preliminary steps from the Simple System tutorial. Specifically, execute all steps from the guide, up to and including the step of importing-the-spineopt-database-template. It is advisable to go through the whole tutorial in order to familiarise yourself with Spine.

    Note

    Just remember to give a different name for the Spine Project of the hydropower tutorial (e.g., ‘Two_hydro’) in the corresponding step, so to not mix up the Spine Toolbox projects!

    That is all you need at the moment, you can now start inserting the data.

    Setting up a Basic Hydropower Model

    For creating a SpineOpt model you need to create Objects, Relationships (associating the objects), and in some cases, parameters values accompanying them. To do this, open the input database using the Spine DB Editor (double click on the input database in the Design View pane of Spine Toolbox).

    Note

    To save your work in the Spine DB Editor you need to commit your changes (please check the Simple System tutorial for how to do that). As a good practice, you should commit often as you enter the data in the model to avoid data loss.

    Defining objects

    Commodities

    Since we are modelling a hydropower system we will have to define two commodities, water and electricity. In the Spine DB editor, locate the Object tree, expand the root element if required, right click on the commodity class, and select Add objects from the context menu. In the Add objects dialogue that should pop up, enter the object names for the commodities as you see in the image below and then press Ok.

    image

    Defining commodities.

    Nodes

    Follow a similar path to add nodes, right click on the node class, and select Add objects from the context menu. In the dialogue, enter the node names as shown:

    image

    Defining nodes.

    Nodes in SpineOpt are used to balance commodities. As you noticed, we defined two nodes for each hydropower station (water nodes) and a single electricity node. This is one possible way to model the hydropower plant operation. This will become clearer in the next steps, but in a nutshell, the upper node represents the water arriving at each plant, while the lower node represents the water that is discharged and becomes available to the next plant.

    Connections

    Similarly, add connections, right click on the connection class, select Add objects from the context menu and add the following connections:

    image

    Defining connections.

    Connections enable the nodes to interact. Since, for each plant we need to model the amount of water that is discharged and the amount that is spilled, we must define two connections accordingly. When defining relationships we shall associate the connections with the nodes.

    Units

    To convert from one type of commodity associated with one node to another, you need a unit. You guessed it! Right click on the unit class, select Add objects from the context menu and add the following units:

    image

    Defining units.

    We have defined one unit for each hydropower plant that converts water to electricity and an additional unit that we will use to model the income from selling the electricity production in the electricity market.

    Relationships

    Assinging commodities to nodes

    Since we have defined more than one commodities, we need to assign them to nodes. In the Spine DB editor, locate the Relationship tree, expand the root element if required, right click on the node__commodity class, and select Add relationships from the context menu. In the Add relationships dialogue, enter the following relationships as you see in the image below and then press Ok.

    image

    Introducing node__commodity relationships.

    Associating connections to nodes

    Next step is to define the topology of flows between the nodes. To do that insert the following relationships in the connection__from_node class:

    image

    Introducing connection__from_node relationships.

    as well as the following the following connection__node_node relationships as you see in the figure:

    Introducing connection__node_node relationships.

    Introducing connection__node_node relationships.

    Placing the units in the model

    To define the topology of the units and be able to introduce their parameters later on, you need to define the following relationships in the unit__from_node class:

    Introducing unit__from_node relationships.

    Introducing unit__from_node relationships.

    in the unit__node_node class:

    Introducing unit__node_node relationships.

    Introducing unit__node_node relationships.

    and in the unit__to_node class as you see in the following figure:

    Introducing unit__to_node relationships.

    Introducing unit__to_node relationships.

    Defining the report outputs

    To force Spine to export the optimal values of the optimization variables to the output database you need to specify them in the form of report_output relationships. Add the following relationships to the report_output class:

    Introducing report outputs with report_output relationships.

    Introducing report outputs with report_output relationships.

    Objects and Relationships parameter values

    Defining model parameter values

    The specify modelling properties of both objects and relationships you need to introduce respective parameter values. To introduce object parameter values first select the model class in the Object tree and enter the following values in the Object parameter value pane:

    Defining model execution parameters.

    Defining model execution parameters.

    Observe the difference between the Object parameter value and the Object parameter definition sub-panes of the Object parameter value pane. The first one is for the modeller to introduce values for specific parameters, while the second one holds the definition of all available parameters with their default values (these are overwritten when the user introduces their own values). Feel free to explore the different parameters and their default values. While entering data in each row you will also observe that, in most cases, clicking on each cell activates a drop-down list of elements that the user must choose from. In the case of the value cells, however, unless you need to input a scalar value or a string, you should right-click on the cell and select edit for specifying the data type of the parameter value. As you see in the figure above, for the first duration_unit parameter you is of type string, while the model_start and model_end parameters are of type Date time. The Date time parameters can be edited by right-clicking on the corresponding value cells, selecting Edit, and then inserting the Date time values that you see in the figure above in the Datetime field using the correct format.

    Defining node parameter values

    Going back to hydropower modelling, we need to specify several parameters for the nodes of the systems. In the same pane as before, but this time selecting the node class from the Object tree, we need to add the following entries:

    Defining model execution parameters.

    Defining model execution parameters.

    Before we go through the interpretation of each parameter, click on the following link for each fix_node_state parameter (Node state Språnget, Node state Fallet), select all, copy the data and then paste them directly in the respective parameter value cell. Spine should automatically detect and input the timeseries data as a parameter value. The data type for those entries should be Timeseries as shown in the figure above. Alternatively, you can select the data type as Timeseries and manually insert the data (values with their corresponding datetimes).

    To model the reservoirs of each hydropower plant, we leverage the state feature that a node can have to represent storage capability. We only need to do this for one of the two nodes that we have used to model each plant and we choose the upper level node. To define storage, we set the value of the parameter has_state as True (be careful to not set it as a string but select the boolean true value by right clicking and selecting Edit in the respective cells). This activates the storage capability of the node. Then, we need to set the capacity of the reservoir by setting the node_state_cap parameter value. Finally, we fix the initial and final values of the reservoir by setting the parameter fix_node_state to the respective values (we introduce nan values for the time steps that we don't want to impose such constraints). To model the local inflow we use the demand parameter but using the negated value of the actual inflow, due to the definition of the parameter in Spine as a demand.

    Defining the temporal resolution of the model

    Spine automates the creation of the temporal resolution of the optimization model and even supports different temporal resolutions for different parts of the model. To define a model with an hourly resolution we select the temporal_block class in the Object tree and we set the resolution parameter value to 1h as shown in the figure:

    Setting the temporal resolution of the model.

    Setting the temporal resolution of the model.

    Defining connection parameter values

    The water that is discharged from Språnget will flow from Språnget_lower node to Fallet_upper through the Språnget_to_Fallet_disc connection, while the water that is spilled will flow from Språnget_upper directly to to Fallet_upper through the Språnget_to_Fallet_spill connection. To model this we need to select the connection__node_node class in the Relationship tree and add the following entries in the Relationship parameter value pane, as shown next:

    Defining discharge and spillage ratio flows.

    Defining discharge and spillage ratio flows.

    Defining unit parameter values

    Similarly, for each one of the unit__from_node, unit__node_node, and unit__to_node relationship classes we need to add the the maximal water that can be discharged by each hydropower plant:

    Setting the maximal water discharge of each plant.

    Setting the maximal water discharge of each plant.

    To define the income from selling the produced electricity we use the vom_cost parameter and negate the values of the electricity prices. To automatically insert the timeseries data in Spine, click on the Electricity prices timeseries, select all values, copy, and paste them, after having selected the value cell of the corresponding row. You can plot and edit the timeseries data by double clicking on the same cell afterwards:

    Previewing and editing the electricity prices timeseries.

    Previewing and editing the electricity prices timeseries.

    Carrying on with our hydropower model we must define the conversion ratios between the nodes. Assuming that water is not "lost" from the upper node toward the lower node and electricity is produced with the discharged water with a given efficiency we define the following parameter values for each hydropower plant, in the unit__node_node class:

    Defining conversion efficiencies.

    Defining conversion efficiencies.

    Lastly, we can define the maximal electricity production of each plant by inserting the following unit__to_node relationship parameter values:

    Setting the maximal electricity production of each plant.

    Setting the maximal electricity production of each plant.

    Hooray! You can now commit the database, close the Spine DB Editor and run your model! Go to the main Spine window and click on Execute image.

    Examining the results

    Select the output data store and open the Spine DB editor. To quickly plot some results, you can expand the unit class in the Object tree and select the electricity_load unit. In the Relationship parameter value pane double click on the value cell of

    report1 | electricity_load | electricity_node | from_node | realization

    object name. This will open a plotting window from were you can also examine closer and retrieve the data, as shown in the next figure. The unit_flow variable of the electricity_load unit represents the total electricity production in the system:

    Total electricity produced in the system.

    Total electricity produced in the system.

    Now, take to a minute to reflect on how you could retrieve the data representing the water that is discharged by each hydropower plant as shown in the next figure:

    Water discharge of Språnget hydropower plant.

    Water discharge of Språnget hydropower plant.

    The right answer is that you need to select some hydropower plant (e.g., Språnget) and then double-click on the value cell of the object name

    report1 | Språnget_pwr_plant | Språnget_lower | to_node | realization

    or

    report1 | Språnget_pwr_plant | Språnget_upper | from_node | realization

    It could be useful to also reflect on why these objects give the same results, and what do the results from the third element represent. (Hint: observe the to_ or from_ directions in the object names). As an exercise, you can try to retrieve the timeseries data for spilled water as well as the water levels at the reservoir of each hydropower plant.

    You can further explore the model, or make changes in the input database to observe how these affect the results, e.g., you can use different electricity prices, values for the reservoir capacity (and initialization points), as well as change the temporal resolution of the model. All you need to do is commit the changes and run your model. Every time that you run the model, your results are appended in the output database with an execution timestamp. You can however filter your results per execution, by selecting the Alternative that you want from the Alternative/Scenario tree pane. You can use the exporter too to export specific variables in an Excel sheet. Alternatively, you can export all the data of the output database by going to the main menu (Press Alt + F to display it), selecting File -> Export, then select the items that you want, click ok and export the data in Excel, or json format.

    In the following, we extend this simple hydropower system to include more elaborate modelling choices.

    Note

    In each of the next sections, we perform incremental changes to the initial simple hydropower model. If you want to keep the database that you created, you can duplicate the database file (right-click on the input database and select Duplicate and duplicate files) and perform the changes in the new database. You need to configure the workflow accordingly in order to run the database you want (please check the Simple System tutorial for how to do that).

    Maximisation of Stored Water

    Instead of fixing the water content of the reservoirs at the end of the planning period, we can consider that the remaining water in the reservoirs has a value and then maximize the value along with the revenues for producing electricity within the planning horizon. This objective term is often called the Value of stored water and we can approximate it by assuming that this water will be used to generate electricity in the future that would be sold at a forecasted price. The water stored in the upstream hydropower plant will become also available to the downstream plant and this should be taken into account.

    To model the value of stored water we need to make some additions and modifications to the initial model.

    • First, add a new node (see adding nodes) and give it a name (e.g., stored_water). This node will accumulate the water stored in the reservoirs at the end of the planning horizon. Associate the node with the water commodity (see node__commodity).

    • Add three more units (see adding units); two will transfer the water at the end of the planning horizon in the new node that we just added (e.g., Språnget_stored_water, Fallet_stored_water), and one will be used as a sink introducing the value of stored water in the objective function (e.g., value_stored_water).

    • To establish the topology of the new units and nodes (see adding unit relationships):

      • add one unit__from_node relationship, between the value_stored_water unit from the stored_water node, another one between the Språnget_stored_water unit from the Språnget_upper node and one for Faller_stored_water from Fallet_upper.
      • add one unit__node__node relationship between the Språnget_stored_water unit with the stored_water and Språnget_upper nodes and another one for Fallet_stored_water unit with the stored_water and Fallet_upper nodes,
      • add a unit__to_node relationship between the Fallet_stored_water and the stored_water node and another one between the Språnget_stored_water unit and the stored_water node.

    • Now we need to make some changes in object parameter values.

      • Extend the planning horizon of the model by one hour, i.e., change the model_end parameter value to 2021-01-02T01:00:00 (right-click on the value cell, click edit and paste the new datetime in the popup window).
      • Remove the fix_node_state parameter values for the end of the optimization horizon as you seen in the following figure: double click on the value cell of the Språnget_upper and Fallet_upper nodes, select the third data row, right-click, select Remove rows, and click OK.
      • Add an electricity price for the extra hour. Enter the parameter vom_cost on the unit__from_node relationship between the electricity_node and the electricity_load and set 0 as the price of electricity for the last hour 2021-01-02T00:00:00. The price is set to zero to ensure no electricity is sold during this hour.

      Modify the fix_node_state parameter value of Språnget_upper and Fallet_upper nodes. Modify the fix_node_state parameter value of Språnget_upper and Fallet_upper nodes.

    • Finally, we need to add some relationship parameter values for the new units:

      • Add a vom_cost parameter value on a value_stored_water|stored_water instance of a unit__from_node relationship, as you see in the figure bellow. For the timeseries you can copy-paste the data directly from this link. If you examine the timeseries data you'll notice that we have imposed a zero cost for all the optimisation horizon, while we use an assumed future electricity value for the additional time step at the end of the horizon.

      Adding vom_cost parameter value on the value_stored_water unit. Adding vom_cost parameter value on the value_stored_water unit.

      • Add two fix_ratio_out_in_unit_flow parameter values as you see in the figure bellow. The efficiency of Fallet_stored_water is the same as the Fallet_pwr_plant as the water in Fallet's reservoir will be used to produce electricity by the the Fallet plant only. On the other hand, the water from Språnget's reservoir will be used both by Fallet and Språnget plant, therefore we use the sum of the two efficiencies in the parameter value of Språnget_stored_water.

      Adding fix_ratio_out_in_unit_flow parameter values on the Språnget_stored_water and Fallet_stored_water units. Adding fix_ratio_out_in_unit_flow parameter values on the Språnget_stored_water and Fallet_stored_water units.

    You can now commit your changes in the database, execute the project and examine the results! As an exercise, try to retrieve the value of stored water as it is calculated by the model.

    Spillage Constraints - Minimisation of Spilt Water

    It might be the case that we need to impose certain limits to the amount of water that is spilt on each time step of the planning horizon, e.g., for environmental reasons, there can be a minimum and a maximum spillage level. At the same time, to avoid wasting water that could be used for producing electricity, we could explicitly impose the spillage minimisation to be added in the objective function.

    • Add one unit (see adding units) to impose the spillage constraints to each plant and name it (for example Språnget_spill).

    • Remove the Språnget_to_Fallet_spill connection (in the Object tree expand the connection class, right-click on Språnget_to_Fallet_spill, and the click Remove).

    • To establish the topology of the unit (see adding unit relationships):

      • Add a unit__from_node relationship, between the Språnget_spill unit from the Språnget_upper node,
      • add a unit__node__node relationship between the Språnget_spill unit with the Fallet_upper and Språnget_upper nodes,
      • add a unit__to_node relationship between the Språnget_spill and the Fallet_upper node,

    • Add the relationship parameter values for the new units:

      • Set the unit_capacity (to apply a maximum), the minimum_operating_point (defined as a percentage of the unit_capacity) to impose a minimum, and the vom_cost to penalise the water that is spilt:

      Setting minimum (the minimal value is defined as percentage of capacity), maximum, and spillage penalty.

      Setting minimum (the minimal value is defined as percentage of capacity), maximum, and spillage penalty.

    • For the Språnget_spill unit define the fix_ratio_out_in_unit_flow parameter value of the min_spillage|Fallet_upper|Språnget_upper relationship to 1 (see adding unit relationships).

    Commit your changes in the database, execute the project and examine the results! As an exercise, you can perform this process for and Fallet plant (you would also need to add another water node, downstream of Fallet).

    Follow Contracted Load Curve

    It is often the case that a system of hydropower plants should follow a given production profile. To model this in the given system, all we have to do is set a demand in the form of a timeseries to the electricity_node.

    Commit your changes in the database, execute the project and examine the results!

    This concludes the tutorial, we hope that you enjoyed building hydropower systems in Spine as much as we do!

    +Two hydro plants · SpineOpt.jl
    GitHub

    Hydro Power Planning

    Welcome to this Spine Toolbox tutorial for building hydro power planning models. The tutorial guides you through the implementation of different ways of modelling hydrodologically-coupled hydropower systems.

    Introduction

    This tutorial aims at demonstrating how we can model a hydropower system in Spine (SpineOpt.jl and Spine-Toolbox) with different assumptions and goals. It starts off by setting up a simple model of system of two hydropower plants and gradually introduces additional features. The goal of the model is to capture the combined operation of two hydropower plants (Språnget and Fallet) that operate on the same river as shown in the picture bellow. Each power plant has its own reservoir and generates electricity by discharging water. The plants might need to spill water, i.e., release water from their reservoirs without generating electricity, for various reasons. The water discharged or spilled by the upstream power plant follows the river route and becomes available to the downstream power plant.

    A system of two hydropower plants.

    A system of two hydropower plants

    In order to run this tutorial you must first execute some preliminary steps from the Simple System tutorial. Specifically, execute all steps from the guide, up to and including the step of importing-the-spineopt-database-template. It is advisable to go through the whole tutorial in order to familiarise yourself with Spine.

    Note

    Just remember to give a different name for the Spine Project of the hydropower tutorial (e.g., ‘Two_hydro’) in the corresponding step, so to not mix up the Spine Toolbox projects!

    That is all you need at the moment, you can now start inserting the data.

    Setting up a Basic Hydropower Model

    For creating a SpineOpt model you need to create Objects, Relationships (associating the objects), and in some cases, parameters values accompanying them. To do this, open the input database using the Spine DB Editor (double click on the input database in the Design View pane of Spine Toolbox).

    Note

    To save your work in the Spine DB Editor you need to commit your changes (please check the Simple System tutorial for how to do that). As a good practice, you should commit often as you enter the data in the model to avoid data loss.

    Defining objects

    Commodities

    Since we are modelling a hydropower system we will have to define two commodities, water and electricity. In the Spine DB editor, locate the Object tree, expand the root element if required, right click on the commodity class, and select Add objects from the context menu. In the Add objects dialogue that should pop up, enter the object names for the commodities as you see in the image below and then press Ok.

    image

    Defining commodities.

    Nodes

    Follow a similar path to add nodes, right click on the node class, and select Add objects from the context menu. In the dialogue, enter the node names as shown:

    image

    Defining nodes.

    Nodes in SpineOpt are used to balance commodities. As you noticed, we defined two nodes for each hydropower station (water nodes) and a single electricity node. This is one possible way to model the hydropower plant operation. This will become clearer in the next steps, but in a nutshell, the upper node represents the water arriving at each plant, while the lower node represents the water that is discharged and becomes available to the next plant.

    Connections

    Similarly, add connections, right click on the connection class, select Add objects from the context menu and add the following connections:

    image

    Defining connections.

    Connections enable the nodes to interact. Since, for each plant we need to model the amount of water that is discharged and the amount that is spilled, we must define two connections accordingly. When defining relationships we shall associate the connections with the nodes.

    Units

    To convert from one type of commodity associated with one node to another, you need a unit. You guessed it! Right click on the unit class, select Add objects from the context menu and add the following units:

    image

    Defining units.

    We have defined one unit for each hydropower plant that converts water to electricity and an additional unit that we will use to model the income from selling the electricity production in the electricity market.

    Relationships

    Assinging commodities to nodes

    Since we have defined more than one commodities, we need to assign them to nodes. In the Spine DB editor, locate the Relationship tree, expand the root element if required, right click on the node__commodity class, and select Add relationships from the context menu. In the Add relationships dialogue, enter the following relationships as you see in the image below and then press Ok.

    image

    Introducing node__commodity relationships.

    Associating connections to nodes

    Next step is to define the topology of flows between the nodes. To do that insert the following relationships in the connection__from_node class:

    image

    Introducing connection__from_node relationships.

    as well as the following the following connection__node_node relationships as you see in the figure:

    Introducing connection__node_node relationships.

    Introducing connection__node_node relationships.

    Placing the units in the model

    To define the topology of the units and be able to introduce their parameters later on, you need to define the following relationships in the unit__from_node class:

    Introducing unit__from_node relationships.

    Introducing unit__from_node relationships.

    in the unit__node_node class:

    Introducing unit__node_node relationships.

    Introducing unit__node_node relationships.

    and in the unit__to_node class as you see in the following figure:

    Introducing unit__to_node relationships.

    Introducing unit__to_node relationships.

    Defining the report outputs

    To force Spine to export the optimal values of the optimization variables to the output database you need to specify them in the form of report_output relationships. Add the following relationships to the report_output class:

    Introducing report outputs with report_output relationships.

    Introducing report outputs with report_output relationships.

    Objects and Relationships parameter values

    Defining model parameter values

    The specify modelling properties of both objects and relationships you need to introduce respective parameter values. To introduce object parameter values first select the model class in the Object tree and enter the following values in the Object parameter value pane:

    Defining model execution parameters.

    Defining model execution parameters.

    Observe the difference between the Object parameter value and the Object parameter definition sub-panes of the Object parameter value pane. The first one is for the modeller to introduce values for specific parameters, while the second one holds the definition of all available parameters with their default values (these are overwritten when the user introduces their own values). Feel free to explore the different parameters and their default values. While entering data in each row you will also observe that, in most cases, clicking on each cell activates a drop-down list of elements that the user must choose from. In the case of the value cells, however, unless you need to input a scalar value or a string, you should right-click on the cell and select edit for specifying the data type of the parameter value. As you see in the figure above, for the first duration_unit parameter you is of type string, while the model_start and model_end parameters are of type Date time. The Date time parameters can be edited by right-clicking on the corresponding value cells, selecting Edit, and then inserting the Date time values that you see in the figure above in the Datetime field using the correct format.

    Defining node parameter values

    Going back to hydropower modelling, we need to specify several parameters for the nodes of the systems. In the same pane as before, but this time selecting the node class from the Object tree, we need to add the following entries:

    Defining model execution parameters.

    Defining model execution parameters.

    Before we go through the interpretation of each parameter, click on the following link for each fix_node_state parameter (Node state Språnget, Node state Fallet), select all, copy the data and then paste them directly in the respective parameter value cell. Spine should automatically detect and input the timeseries data as a parameter value. The data type for those entries should be Timeseries as shown in the figure above. Alternatively, you can select the data type as Timeseries and manually insert the data (values with their corresponding datetimes).

    To model the reservoirs of each hydropower plant, we leverage the state feature that a node can have to represent storage capability. We only need to do this for one of the two nodes that we have used to model each plant and we choose the upper level node. To define storage, we set the value of the parameter has_state as True (be careful to not set it as a string but select the boolean true value by right clicking and selecting Edit in the respective cells). This activates the storage capability of the node. Then, we need to set the capacity of the reservoir by setting the node_state_cap parameter value. Finally, we fix the initial and final values of the reservoir by setting the parameter fix_node_state to the respective values (we introduce nan values for the time steps that we don't want to impose such constraints). To model the local inflow we use the demand parameter but using the negated value of the actual inflow, due to the definition of the parameter in Spine as a demand.

    Defining the temporal resolution of the model

    Spine automates the creation of the temporal resolution of the optimization model and even supports different temporal resolutions for different parts of the model. To define a model with an hourly resolution we select the temporal_block class in the Object tree and we set the resolution parameter value to 1h as shown in the figure:

    Setting the temporal resolution of the model.

    Setting the temporal resolution of the model.

    Defining connection parameter values

    The water that is discharged from Språnget will flow from Språnget_lower node to Fallet_upper through the Språnget_to_Fallet_disc connection, while the water that is spilled will flow from Språnget_upper directly to to Fallet_upper through the Språnget_to_Fallet_spill connection. To model this we need to select the connection__node_node class in the Relationship tree and add the following entries in the Relationship parameter value pane, as shown next:

    Defining discharge and spillage ratio flows.

    Defining discharge and spillage ratio flows.

    Defining unit parameter values

    Similarly, for each one of the unit__from_node, unit__node_node, and unit__to_node relationship classes we need to add the the maximal water that can be discharged by each hydropower plant:

    Setting the maximal water discharge of each plant.

    Setting the maximal water discharge of each plant.

    To define the income from selling the produced electricity we use the vom_cost parameter and negate the values of the electricity prices. To automatically insert the timeseries data in Spine, click on the Electricity prices timeseries, select all values, copy, and paste them, after having selected the value cell of the corresponding row. You can plot and edit the timeseries data by double clicking on the same cell afterwards:

    Previewing and editing the electricity prices timeseries.

    Previewing and editing the electricity prices timeseries.

    Carrying on with our hydropower model we must define the conversion ratios between the nodes. Assuming that water is not "lost" from the upper node toward the lower node and electricity is produced with the discharged water with a given efficiency we define the following parameter values for each hydropower plant, in the unit__node_node class:

    Defining conversion efficiencies.

    Defining conversion efficiencies.

    Lastly, we can define the maximal electricity production of each plant by inserting the following unit__to_node relationship parameter values:

    Setting the maximal electricity production of each plant.

    Setting the maximal electricity production of each plant.

    Hooray! You can now commit the database, close the Spine DB Editor and run your model! Go to the main Spine window and click on Execute image.

    Examining the results

    Select the output data store and open the Spine DB editor. To quickly plot some results, you can expand the unit class in the Object tree and select the electricity_load unit. In the Relationship parameter value pane double click on the value cell of

    report1 | electricity_load | electricity_node | from_node | realization

    object name. This will open a plotting window from were you can also examine closer and retrieve the data, as shown in the next figure. The unit_flow variable of the electricity_load unit represents the total electricity production in the system:

    Total electricity produced in the system.

    Total electricity produced in the system.

    Now, take to a minute to reflect on how you could retrieve the data representing the water that is discharged by each hydropower plant as shown in the next figure:

    Water discharge of Språnget hydropower plant.

    Water discharge of Språnget hydropower plant.

    The right answer is that you need to select some hydropower plant (e.g., Språnget) and then double-click on the value cell of the object name

    report1 | Språnget_pwr_plant | Språnget_lower | to_node | realization

    or

    report1 | Språnget_pwr_plant | Språnget_upper | from_node | realization

    It could be useful to also reflect on why these objects give the same results, and what do the results from the third element represent. (Hint: observe the to_ or from_ directions in the object names). As an exercise, you can try to retrieve the timeseries data for spilled water as well as the water levels at the reservoir of each hydropower plant.

    You can further explore the model, or make changes in the input database to observe how these affect the results, e.g., you can use different electricity prices, values for the reservoir capacity (and initialization points), as well as change the temporal resolution of the model. All you need to do is commit the changes and run your model. Every time that you run the model, your results are appended in the output database with an execution timestamp. You can however filter your results per execution, by selecting the Alternative that you want from the Alternative/Scenario tree pane. You can use the exporter too to export specific variables in an Excel sheet. Alternatively, you can export all the data of the output database by going to the main menu (Press Alt + F to display it), selecting File -> Export, then select the items that you want, click ok and export the data in Excel, or json format.

    In the following, we extend this simple hydropower system to include more elaborate modelling choices.

    Note

    In each of the next sections, we perform incremental changes to the initial simple hydropower model. If you want to keep the database that you created, you can duplicate the database file (right-click on the input database and select Duplicate and duplicate files) and perform the changes in the new database. You need to configure the workflow accordingly in order to run the database you want (please check the Simple System tutorial for how to do that).

    Maximisation of Stored Water

    Instead of fixing the water content of the reservoirs at the end of the planning period, we can consider that the remaining water in the reservoirs has a value and then maximize the value along with the revenues for producing electricity within the planning horizon. This objective term is often called the Value of stored water and we can approximate it by assuming that this water will be used to generate electricity in the future that would be sold at a forecasted price. The water stored in the upstream hydropower plant will become also available to the downstream plant and this should be taken into account.

    To model the value of stored water we need to make some additions and modifications to the initial model.

    • First, add a new node (see adding nodes) and give it a name (e.g., stored_water). This node will accumulate the water stored in the reservoirs at the end of the planning horizon. Associate the node with the water commodity (see node__commodity).

    • Add three more units (see adding units); two will transfer the water at the end of the planning horizon in the new node that we just added (e.g., Språnget_stored_water, Fallet_stored_water), and one will be used as a sink introducing the value of stored water in the objective function (e.g., value_stored_water).

    • To establish the topology of the new units and nodes (see adding unit relationships):

      • add one unit__from_node relationship, between the value_stored_water unit from the stored_water node, another one between the Språnget_stored_water unit from the Språnget_upper node and one for Faller_stored_water from Fallet_upper.
      • add one unit__node__node relationship between the Språnget_stored_water unit with the stored_water and Språnget_upper nodes and another one for Fallet_stored_water unit with the stored_water and Fallet_upper nodes,
      • add a unit__to_node relationship between the Fallet_stored_water and the stored_water node and another one between the Språnget_stored_water unit and the stored_water node.

    • Now we need to make some changes in object parameter values.

      • Extend the planning horizon of the model by one hour, i.e., change the model_end parameter value to 2021-01-02T01:00:00 (right-click on the value cell, click edit and paste the new datetime in the popup window).
      • Remove the fix_node_state parameter values for the end of the optimization horizon as you seen in the following figure: double click on the value cell of the Språnget_upper and Fallet_upper nodes, select the third data row, right-click, select Remove rows, and click OK.
      • Add an electricity price for the extra hour. Enter the parameter vom_cost on the unit__from_node relationship between the electricity_node and the electricity_load and set 0 as the price of electricity for the last hour 2021-01-02T00:00:00. The price is set to zero to ensure no electricity is sold during this hour.

      Modify the fix_node_state parameter value of Språnget_upper and Fallet_upper nodes. Modify the fix_node_state parameter value of Språnget_upper and Fallet_upper nodes.

    • Finally, we need to add some relationship parameter values for the new units:

      • Add a vom_cost parameter value on a value_stored_water|stored_water instance of a unit__from_node relationship, as you see in the figure bellow. For the timeseries you can copy-paste the data directly from this link. If you examine the timeseries data you'll notice that we have imposed a zero cost for all the optimisation horizon, while we use an assumed future electricity value for the additional time step at the end of the horizon.

      Adding vom_cost parameter value on the value_stored_water unit. Adding vom_cost parameter value on the value_stored_water unit.

      • Add two fix_ratio_out_in_unit_flow parameter values as you see in the figure bellow. The efficiency of Fallet_stored_water is the same as the Fallet_pwr_plant as the water in Fallet's reservoir will be used to produce electricity by the the Fallet plant only. On the other hand, the water from Språnget's reservoir will be used both by Fallet and Språnget plant, therefore we use the sum of the two efficiencies in the parameter value of Språnget_stored_water.

      Adding fix_ratio_out_in_unit_flow parameter values on the Språnget_stored_water and Fallet_stored_water units. Adding fix_ratio_out_in_unit_flow parameter values on the Språnget_stored_water and Fallet_stored_water units.

    You can now commit your changes in the database, execute the project and examine the results! As an exercise, try to retrieve the value of stored water as it is calculated by the model.

    Spillage Constraints - Minimisation of Spilt Water

    It might be the case that we need to impose certain limits to the amount of water that is spilt on each time step of the planning horizon, e.g., for environmental reasons, there can be a minimum and a maximum spillage level. At the same time, to avoid wasting water that could be used for producing electricity, we could explicitly impose the spillage minimisation to be added in the objective function.

    • Add one unit (see adding units) to impose the spillage constraints to each plant and name it (for example Språnget_spill).

    • Remove the Språnget_to_Fallet_spill connection (in the Object tree expand the connection class, right-click on Språnget_to_Fallet_spill, and the click Remove).

    • To establish the topology of the unit (see adding unit relationships):

      • Add a unit__from_node relationship, between the Språnget_spill unit from the Språnget_upper node,
      • add a unit__node__node relationship between the Språnget_spill unit with the Fallet_upper and Språnget_upper nodes,
      • add a unit__to_node relationship between the Språnget_spill and the Fallet_upper node,

    • Add the relationship parameter values for the new units:

      • Set the unit_capacity (to apply a maximum), the minimum_operating_point (defined as a percentage of the unit_capacity) to impose a minimum, and the vom_cost to penalise the water that is spilt:

      Setting minimum (the minimal value is defined as percentage of capacity), maximum, and spillage penalty.

      Setting minimum (the minimal value is defined as percentage of capacity), maximum, and spillage penalty.

    • For the Språnget_spill unit define the fix_ratio_out_in_unit_flow parameter value of the min_spillage|Fallet_upper|Språnget_upper relationship to 1 (see adding unit relationships).

    Commit your changes in the database, execute the project and examine the results! As an exercise, you can perform this process for and Fallet plant (you would also need to add another water node, downstream of Fallet).

    Follow Contracted Load Curve

    It is often the case that a system of hydropower plants should follow a given production profile. To model this in the given system, all we have to do is set a demand in the form of a timeseries to the electricity_node.

    Commit your changes in the database, execute the project and examine the results!

    This concludes the tutorial, we hope that you enjoyed building hydropower systems in Spine as much as we do!

    diff --git a/dev/tutorial/webinars/index.html b/dev/tutorial/webinars/index.html index 963b1f3def..5c8b0c3b54 100644 --- a/dev/tutorial/webinars/index.html +++ b/dev/tutorial/webinars/index.html @@ -1,2 +1,2 @@ -Webinars · SpineOpt.jl
    GitHub

    Webinars

    SpinOpt tutorial covers the entire process from installing Spine Toolbox and SpineOpt, creating and running a model with these tools and manipulating databases.

    +Webinars · SpineOpt.jl
    GitHub

    Webinars

    SpinOpt tutorial covers the entire process from installing Spine Toolbox and SpineOpt, creating and running a model with these tools and manipulating databases.