Parameters
balance_type
A selector for how the
nodal_balanceconstraint should be handled.
Default value: balance_type_node
Related Object Classes: node
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.
benders_starting_connections_invested
Fixes the number of connections invested during the first Benders iteration
Default value: nothing
Related Object Classes: connection
benders_starting_storages_invested
Fixes the number of storages invested during the first Benders iteration
Default value: nothing
Related Object Classes: node
benders_starting_units_invested
Fixes the number of units invested during the first Benders iteration
Default value: nothing
Related Object Classes: unit
big_m
Sufficiently large number used for linearization bilinear terms, e.g. to enforce bidirectional flow for gas pipielines
Default value: 1000000
Related Object Classes: model
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.
block_end
The end time for the
temporal_block. Can be given either as aDateTimefor a static end point, or as aDurationfor an end point relative to the start of the current optimization.
Default value: nothing
Related Object Classes: temporal_block
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.
block_start
The start time for the
temporal_block. Can be given either as aDateTimefor a static start point, or as aDurationfor an start point relative to the start of the current optimization.
Default value: nothing
Related Object Classes: temporal_block
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.
candidate_connections
The number of connections that may be invested in
Default value: nothing
Related Object Classes: connection
The candidate_connections parameter denotes the possibility of investing on a certain connection.
The default value of nothing means that the connection can't be invested in, because it's already in operation. An integer value represents the maximum investment possible at any point in time, as a factor of the connection_capacity.
In other words, candidate_connections is the upper bound of the connections_invested_available variable.
candidate_storages
Determines the maximum number of new storages which may be invested in
Default value: nothing
Related Object Classes: node
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
candidate_units
Number of units which may be additionally constructed
Default value: nothing
Related Object Classes: unit
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
commodity_lodf_tolerance
The minimum absolute value of the line outage distribution factor (LODF) that is considered meaningful.
Default value: 0.1
Related Object Classes: commodity
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).
commodity_physics
Defines if the
commodityfollows lodf or ptdf physics.
Default value: commodity_physics_none
Related Object Classes: commodity
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
commodity_physics_duration
For how long the
commodity_physicsshould apply relative to the start of the window.
Default value: nothing
Related Object Classes: commodity
This parameter determines the duration, relative to the start of the optimisation window, over which the physics determined by commodity_physics should be applied. This is useful when the optimisation window includes a long look-ahead where the detailed physics are not necessary. In this case one can set commodity_physics_duration to a shorter value to reduce problem size and increase performace.
See also powerflow
commodity_ptdf_threshold
The minimum absolute value of the power transfer distribution factor (PTDF) that is considered meaningful.
Default value: 0.001
Related Object Classes: commodity
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).
compression_factor
The compression factor establishes a compression from an origin node to a receiving node, which are connected through a connection. The first node corresponds to the origin node, the second to the (compressed) destination node. Typically the value is >=1.
Default value: nothing
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.
connection_availability_factor
Availability of the
connection, acting as a multiplier on itsconnection_capacity. Typically between 0-1.
Default value: 1.0
Related Object Classes: connection
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.
connection_capacity
- For
connection__from_node: Limits theconnection_flowvariable from thefrom_node.from_nodecan be a group ofnodes, in which case the sum of theconnection_flowis constrained.- For
connection__to_node: Limits theconnection_flowvariable to theto_node.to_nodecan be a group ofnodes, in which case the sum of theconnection_flowis constrained.
Default value: nothing
Related Relationship Classes: connection__from_node and connection__to_node
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.
connection_contingency
A boolean flag for defining a contingency
connection.
Default value: nothing
Related Object Classes: connection
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
connection_conv_cap_to_flow
- For
connection__from_node: Optional coefficient forconnection_capacityunit conversions in the case that theconnection_capacityvalue is incompatible with the desiredconnection_flowunits.- For
connection__to_node: Optional coefficient forconnection_capacityunit conversions in the case theconnection_capacityvalue is incompatible with the desiredconnection_flowunits.
Default value: 1.0
Related Relationship Classes: connection__from_node and connection__to_node
The connection_conv_cap_to_flow can be used to perform the conversion between the measurement unit of the connection_capacity to the measurement unit of the connection_flow variable. The default of this parameter is 1, i.e. assuming that both are given in the same measurement unit.
connection_decommissioning_cost
Costs associated with decommissioning a power plant. The costs will b discounted to the
discount_year`at distribted equally over the decommissioning time.
Default value: nothing
Related Object Classes: connection
connection_decommissioning_time
A connection's decommissioning time, i.e., the time between the moment at which a connection decommissioning decision is takien, and the moment at which decommissioning is complete.
Default value: Dict{String, Any}("data" => "0h", "type" => "duration")
Related Object Classes: connection
connection_discount_rate_technology_specific
connection-specific discount rate used to calculate the connection's investment costs. If not specified, the model discount rate is used.
Default value: 0.0
Related Object Classes: connection
connection_emergency_capacity
- For
connection__from_node: Post contingency flow capacity of aconnection. Sometimes referred to as emergency rating- For
connection__to_node: The maximum post-contingency flow on a monitoredconnection.
Default value: nothing
Related Relationship Classes: connection__from_node and connection__to_node
The connection_emergency_capacity parameter represents the maximum post-contingency flow on a monitored connection if ptdf and lodf based security constrained unit commitment is enabled (commodity_physics is set to [commodity_physics_lodf]).
If you set this value, make sure that you also set connection_monitored to true for the involved connection.
connection_flow_coefficient
- For
connection__from_node__user_constraint: defines the user constraint coefficient on the connection flow variable in the from direction- For
connection__to_node__user_constraint: defines the user constraint coefficient on the connection flow variable in the to direction
Default value: 0.0
Related Relationship Classes: connection__from_node__user_constraint and connection__to_node__user_constraint
The connection_flow_coefficient is an optional parameter that can be used to include the connection_flow variable from or to a node in a user_constraint via the connection__from_node__user_constraint and connection__to_node__user_constraint relationships. Essentially, connection_flow_coefficient appears as a coefficient for the connection_flow variable from or to the node in the user constraint.
connection_flow_cost
Variable costs of a flow through a
connection. E.g. EUR/MWh of energy throughput.
Default value: nothing
Related Relationship Classes: connection__from_node and connection__to_node
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.
connection_flow_delay
Delays the
connection_flowsassociated with the latternodein respect to theconnection_flowsassociated with the firstnode.
Default value: Dict{String, Any}("data" => "0h", "type" => "duration")
The connection_flow_delay parameter denotes the amount of time that it takes for the flow to go through a connection. In other words, the flow that enters the connection is only seen at the other side after connection_flow_delay units of time.
connection_flow_non_anticipativity_margin
Margin by which
connection_flowvariable can differ from the value in the previous window duringnon_anticipativity_time.
Default value: nothing
Related Relationship Classes: connection__from_node and connection__to_node
connection_flow_non_anticipativity_time
Period of time where the value of the
connection_flowvariable has to be fixed to the result from the previous window.
Default value: nothing
Related Relationship Classes: connection__from_node and connection__to_node
connection_intact_flow_non_anticipativity_margin
Margin by which
connection_intact_flowvariable can differ from the value in the previous window duringnon_anticipativity_time.
Default value: nothing
Related Relationship Classes: connection__from_node and connection__to_node
connection_intact_flow_non_anticipativity_time
Period of time where the value of the
connection_intact_flowvariable has to be fixed to the result from the previous window.
Default value: nothing
Related Relationship Classes: connection__from_node and connection__to_node
connection_investment_cost
The per unit investment cost for the connection over the
connection_investment_tech_lifetime
Default value: nothing
Related Object Classes: connection
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.
connection_investment_econ_lifetime
Determines the minimum economical investment lifetime of a connection.
Default value: nothing
Related Object Classes: connection
connection_investment_lifetime_sense
A selector for
connection_lifetimeconstraint sense.
Default value: >=
Related Object Classes: connection
connection_investment_tech_lifetime
Determines the maximum technical lifetime of a connection. Once invested, it remains in service for this long
Default value: nothing
Related Object Classes: connection
connection_investment_variable_type
Determines whether the investment variable is integer
variable_type_integeror continuousvariable_type_continuous
Default value: connection_investment_variable_type_integer
Uses Parameter Value Lists: connection_investment_variable_type_list
Related Object Classes: connection
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.
connection_lead_time
A connection's lead time, i.e., the time between the moment at which a connection investment decision is takien, and the moment at which the connection investment becomes operational.
Default value: Dict{String, Any}("data" => "0h", "type" => "duration")
Related Object Classes: connection
connection_linepack_constant
The linepack constant is a property of gas pipelines and relates the linepack to the pressure of the adjacent nodes.
Default value: nothing
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.
connection_monitored
A boolean flag for defining a contingency
connection.
Default value: false
Related Object Classes: connection
When using ptdf-based load flow by setting commodity_physics to either commodity_physics_ptdf or commodity_physics_ptdf, a constraint is created for each connection for which connection_monitored = true. Thus, to monitor the ptdf-based flow on a particular connection connection_monitored must be set to true.
See also powerflow
connection_reactance
The per unit reactance of a
connection.
Default value: nothing
Related Object Classes: connection
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.
connection_reactance_base
If the reactance is given for a p.u. (e.g. p.u. = 100MW), the
connection_reactance_basecan be set to perform this conversion (e.g. *100).
Default value: 1
Related Object Classes: connection
As the connection_reactance is often given on a per unit basis, often different than the units used elsewhere, the connection_reactance_base parameter serves as a conversion factor, scaling the connection_reactance with its p.u..
connection_resistance
The per unit resistance of a
connection.
Default value: nothing
Related Object Classes: connection
The per unit resistance of a transmission line. Currently unimplemented!## connection_type
A selector between a normal and a lossless bidirectional
connection.
Default value: connection_type_normal
Related Object Classes: connection
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:
- relationship: connection__from_node
- relationship: connection__to_node
- parameter: connection_capacity (defined on connection__from_node and/or connection__to_node)
If connection_type=:connection_type_lossless_bidirectional the following pre-processing actions are taken:
- reciprocal connection__from_node and connection__to_node relationships are created if they don't exist
- a new connection__node__node relationship is created if none exists already
- fix_ratio_out_in_connection_flow parameter is created with the value of 1 if no existing parameter found (therefore this value can be overridden)
- The first connection_capacity parameter found is copied to connection__from_nodes and connection__to_nodes without a defined connection_capacity.
connections_invested_available_coefficient
coefficient of
connections_invested_availablein the specificuser_constraint
Default value: 0.0
connections_invested_big_m_mga
bigmmga should be chosen as small as possible but sufficiently large. For unitsinvestedmga an appropriate bigmmga would be twice the candidate connections.
Default value: nothing
Related Object Classes: connection
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.)
connections_invested_coefficient
coefficient of
connections_investedin the specificuser_constraint
Default value: 0.0
The connections_invested_coefficient is an optional parameter that can be used to include the connections_invested variable in a user_constraint via the connection__user_constraint relationship. Essentially, connections_invested_coefficient appears as a coefficient for the connections_invested variable in the user constraint.
connections_invested_mga
Defines whether a certain variable (here: connections_invested) will be considered in the maximal-differences of the mga objective
Default value: false
Related Object Classes: connection
The connections_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 connections_invested_mga is set to true, investment decisions in this connection, or group of connections, will be included in the MGA algorithm.
connections_invested_mga_weight
Used to scale mga variables. For weightd sum mga method, the length of this weight given as an Array will determine the number of iterations.
Default value: 1
Related Object Classes: connection
constraint_sense
A selector for the sense of the
user_constraint.
Default value: ==
Related Object Classes: user_constraint
The constraint_sense parameter determines the sense of a custom user constraint.
See User constraints for details.
curtailment_cost
Costs for curtailing generation. Essentially, accrues costs whenever
unit_flownot operating at its maximum available capacity. E.g. EUR/MWh
Default value: nothing
Related Object Classes: unit
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.
cyclic_condition
If the cyclic condition is set to true for a storage node, the
node_stateat the end of the optimization window has to be (depending on the value of cyclicconditionsense) either greater than, equal to, or lower than, the initial storage state.
Default value: false
Related Relationship Classes: node__temporal_block
The cyclic_condition parameter is used to enforce that the storage level at the end of the optimization window is higher or equal to the storage level at the beginning optimization. If the cyclic_condition parameter is set to true for a node__temporal_block relationship, and the has_state parameter of the corrresponding node is set to true, the constraint_cyclic_node_state will be triggered.
cyclic_condition_sense
Sense for the cyclic condition constraint of a node.
Default value: >=
Related Relationship Classes: node__temporal_block
db_lp_solver
Solver for MIP problems. Solver package must be added and pre-configured in Julia. Overrides lp_solver RunSpineOpt kwarg
Default value: HiGHS.jl
Related Object Classes: model
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 lpsolver keyword argument specified, this will override this parameter.## `dblpsolveroptions`
Map parameter containing LP solver option name option value pairs. See solver documentation for supported solver options
Default value: Dict{String, Any}("data" => Any[Any["HiGHS.jl", Dict{String, Any}("data" => Any[Any["presolve", "on"], Any["time_limit", 300.01]], "type" => "map", "index_type" => "str")], Any["Clp.jl", Dict{String, Any}("data" => Any[Any["LogLevel", 0.0]], "type" => "map", "index_type" => "str")]], "type" => "map", "index_type" => "str")
Related Object Classes: model
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. 
## db_mip_solver
Solver for MIP problems. Solver package must be added and pre-configured in Julia. Overrides mip_solver RunSpineOpt kwarg
Default value: HiGHS.jl
Related Object Classes: model
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 mipsolver keyword argument specified, this will override this parameter.## `dbmipsolveroptions`
Map parameter containing MIP solver option name option value pairs for MIP. See solver documentation for supported solver options
Default value: Dict{String, Any}("data" => Any[Any["HiGHS.jl", Dict{String, Any}("data" => Any[Any["presolve", "on"], Any["mip_rel_gap", 0.01], Any["threads", 0.0], Any["time_limit", 300.01]], "type" => "map", "index_type" => "str")], Any["Cbc.jl", Dict{String, Any}("data" => Any[Any["ratioGap", 0.01], Any["logLevel", 0.0]], "type" => "map", "index_type" => "str")], Any["CPLEX.jl", Dict{String, Any}("data" => Any[Any["CPX_PARAM_EPGAP", 0.01]], "type" => "map", "index_type" => "str")]], "type" => "map", "index_type" => "str")
Related Object Classes: model
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. ## demand
Demand for the
commodityof anode. Energy gains can be represented using negativedemand.
Default value: 0.0
Related Object Classes: node
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.
demand_coefficient
coefficient of the specified node's demand in the specified user constraint
Default value: 0.0
The demand_coefficient is an optional parameter that can be used to include the demand of the a node in a user_constraint via the node__user_constraint relationship. Essentially, demand_coefficient appears as a coefficient for the demand parameter of the connected node in the user constraint.## diff_coeff
Commodity diffusion coefficient between two
nodes. Effectively, denotes the diffusion power per unit of state from the firstnodeto the second.
Default value: 0.0
Related Relationship Classes: node__node
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).discount_rate
The discount rate used for the discounting of future cashflows
Default value: 0
Related Object Classes: model
discount_year
The year to which all cashflows are discounted.
Default value: nothing
Related Object Classes: model
downward_reserve
Identifier for
nodes providing downward reserves
Default value: false
Related Object Classes: node
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.
duration_unit
Defines the base temporal unit of the
model. Currently supported values are either anhouror aminute.
Default value: hour
Related Object Classes: model
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.## equal_investments
Whether all entities in the group must have the same investment decision.
Default value: false
Related Object Classes: investment_group
fix_binary_gas_connection_flow
Fix the value of the
connection_flow_binaryvariable, and hence pre-determine the direction of flow in the connection.
Default value: nothing
Related Relationship Classes: connection__from_node and connection__to_node
The binary flow of a gas pipelines for pressure driven gas transfer is enables through the binary variable binary_gas_connection_flow and the big_m constant. To fix this binary variable, i.e. pre-define the direction of gas through the pipelines, the fix_binary_gas_connection_flow parameter can be used.
fix_connection_flow
Fix the value of the
connection_flowvariable.
Default value: nothing
Related Relationship Classes: connection__from_node and connection__to_node
The fixconnectionflow parameter fixes the value of the connection_flow variable.
Warning: that this parameter should be set to 0 for history timeslices to avoid free energy in the model when using the connectionflowdelay parameter.
fix_connection_intact_flow
Fix the value of the
connection_intact_flowvariable.
Default value: nothing
Related Relationship Classes: connection__from_node and connection__to_node
The fix_connection_intact_flow parameter can be used to fix the values of the connection_intact_flow variable to preset values. If set to a Scalar type value, the connection_intact_flow variable is fixed to that value for all time steps and stochastic_scenarios. Values for individual time steps can be fixed using TimeSeries type values.## fix_connections_invested
Setting a value fixes the connections_invested variable accordingly
Default value: nothing
Related Object Classes: connection
The fix_connections_invested parameter can be used to fix the values of the connections_invested variable to preset values. If set to a Scalar type value, the connections_invested variable is fixed to that value for all time steps and stochastic_scenarios. Values for individual time steps can be fixed using TimeSeries type values.
See Investment Optimization for more information about the investment framework in SpineOpt.jl.## fix_connections_invested_available
Setting a value fixes the connectionsinvestedavailable variable accordingly
Default value: nothing
Related Object Classes: connection
The fix_connections_invested_available parameter represents a forced connection investment.
In other words, it is the fix value of the connections_invested_available variable.
fix_node_pressure
Fixes the corresponding
node_pressurevariable to the provided value
Default value: nothing
Related Object Classes: node
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.
fix_node_state
Fixes the corresponding
node_statevariable to the provided value. Can be used for e.g. fixing boundary conditions.
Default value: nothing
Related Object Classes: node
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.## fix_node_voltage_angle
Fixes the corresponding
node_voltage_anglevariable to the provided value
Default value: nothing
Related Object Classes: node
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.
fix_nonspin_units_shut_down
Fix the
nonspin_units_shut_downvariable.
Default value: nothing
Related Relationship Classes: unit__to_node
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.
fix_nonspin_units_started_up
Fix the
nonspin_units_started_upvariable.
Default value: nothing
Related Relationship Classes: unit__from_node and unit__to_node
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.
fix_ratio_in_in_unit_flow
Fix the ratio between two
unit_flowscoming into theunitfrom the twonodes.
Default value: nothing
Related Relationship Classes: unit__node__node
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.
fix_ratio_in_out_unit_flow
Fix the ratio between an incoming
unit_flowfrom the firstnodeand an outgoingunit_flowto the secondnode.
Default value: nothing
Related Relationship Classes: unit__node__node
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.
To implement a piecewise linear ratio, the parameter 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, fix\_ratio\_in\_out\_unit\_flow[i] is the effective incremental ratio 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. Note also that the formulation assumes a convex, monotonically increasing function. The formulation relies on optimality to load the segments in the correct order and no additional integer variables are created to enforce the correct loading order.
fix_ratio_out_in_connection_flow
Fix the ratio between an outgoing
connection_flowto the firstnodeand an incomingconnection_flowfrom the secondnode.
Default value: nothing
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.
fix_ratio_out_in_unit_flow
Fix the ratio between an outgoing
unit_flowto the firstnodeand an incomingunit_flowfrom the secondnode.
Default value: nothing
Related Relationship Classes: unit__node__node
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.
fix_ratio_out_out_unit_flow
Fix the ratio between two
unit_flowsgoing from theunitinto the twonodes.
Default value: nothing
Related Relationship Classes: unit__node__node
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.
fix_storages_invested
Used to fix the value of the storages_invested variable
Default value: nothing
Related Object Classes: node
Used primarily to fix the value of the storages_invested variable which represents the point-in-time storage investment decision variable at a node and how many candidate storages are invested-in in a particular timeslice at the corresponding node.
See also Investment Optimization, candidate_storages and storage_investment_variable_type
fix_storages_invested_available
Used to fix the value of the storagesinvestedavailable variable
Default value: nothing
Related Object Classes: node
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
fix_unit_flow
Fix the
unit_flowvariable.
Default value: nothing
Related Relationship Classes: unit__from_node and unit__to_node
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.
fix_unit_flow_op
Fix the
unit_flow_opvariable.
Default value: nothing
Related Relationship Classes: unit__from_node and unit__to_node
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.## fix_units_invested
Fix the value of the
units_investedvariable.
Default value: nothing
Related Object Classes: unit
Used primarily to fix the value of the units_invested variable which represents the point-in-time unit investment decision variable and how many candidate units are invested-in in a particular timeslice.
See also Investment Optimization, candidate_units and unit_investment_variable_type
fix_units_invested_available
Fix the value of the
units_invested_availablevariable
Default value: nothing
Related Object Classes: unit
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
fix_units_on
Fix the value of the
units_onvariable.
Default value: nothing
Related Object Classes: unit
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.
fix_units_on_coefficient_in_in
Optional coefficient for the
units_onvariable impacting thefix_ratio_in_in_unit_flowconstraint.
Default value: 0.0
Related Relationship Classes: unit__node__node
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.
fix_units_on_coefficient_in_out
Optional coefficient for the
units_onvariable impacting thefix_ratio_in_out_unit_flowconstraint.
Default value: 0.0
Related Relationship Classes: unit__node__node
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.## fix_units_on_coefficient_out_in
Optional coefficient for the
units_onvariable impacting thefix_ratio_out_in_unit_flowconstraint.
Default value: 0.0
Related Relationship Classes: unit__node__node
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.## fix_units_on_coefficient_out_out
Optional coefficient for the
units_onvariable impacting thefix_ratio_out_out_unit_flowconstraint.
Default value: 0.0
Related Relationship Classes: unit__node__node
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.## fix_units_out_of_service
Fix the value of the
units_out_of_servicevariable.
Default value: nothing
Related Object Classes: unit
fixed_pressure_constant_0
Fixed pressure points for pipelines for the outer approximation of the Weymouth approximation. The direction of flow is the first node in the relationship to the second node in the relationship.
Default value: nothing
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.
fixed_pressure_constant_1
Fixed pressure points for pipelines for the outer approximation of the Weymouth approximation. The direction of flow is the first node in the relationship to the second node in the relationship.
Default value: nothing
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.
fom_cost
Fixed operation and maintenance costs of a
unit. Essentially, a cost coefficient on the existing units (incl.number_of_unitsandunits_invested_available) andunit_capacityparameters. Currently, the value needs to be defined per duration unit (i.e. 1 hour), E.g. EUR/MW/h
Default value: nothing
Related Object Classes: unit
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.
frac_state_loss
Self-discharge coefficient for
node_statevariables. Effectively, represents the loss power per unit of state.
Default value: 0.0
Related Object Classes: node
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.
fractional_demand
The fraction of a
nodegroup'sdemandapplied for thenodein question.
Default value: 0.0
Related Object Classes: node
Whenever a node is a member of a group, the fractional_demand parameter represents its share of the group's demand.
fuel_cost
Variable fuel costs than can be attributed to a
unit_flow. E.g. EUR/MWh
Default value: nothing
Related Relationship Classes: unit__from_node and unit__to_node
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.
graph_view_position
An optional setting for tweaking the position of the different elements when drawing them via Spine Toolbox Graph View.
Default value: nothing
Related Object Classes: connection, node and unit
Related Relationship Classes: connection__from_node, connection__to_node, unit__from_node__user_constraint, unit__from_node, unit__to_node__user_constraint and unit__to_node
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.## has_binary_gas_flow
This parameter needs to be set to
truein order to represent bidirectional pressure drive gas transfer.
Default value: false
Related Object Classes: connection
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.
has_pressure
A boolean flag for whether a
nodehas anode_pressurevariable.
Default value: false
Related Object Classes: node
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
has_state
A boolean flag for whether a
nodehas anode_statevariable.
Default value: false
Related Object Classes: node
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.
has_voltage_angle
A boolean flag for whether a
nodehas anode_voltage_anglevariable.
Default value: false
Related Object Classes: node
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
include_in_non_representative_periods
If using representative periods, this boolean parameter determines whether or not the constraint is enforced in non-representative periods.
Default value: false
Related Object Classes: user_constraint
initial_binary_gas_connection_flow
Initialize the value of the
connection_flow_binaryvariable, and hence pre-determine the direction of flow in the connection.
Default value: nothing
Related Relationship Classes: connection__from_node and connection__to_node
initial_connection_flow
Initialize the value of the
connection_flowvariable.
Default value: nothing
Related Relationship Classes: connection__from_node and connection__to_node
initial_connection_intact_flow
Initialize the value of the
connection_intact_flowvariable.
Default value: nothing
Related Relationship Classes: connection__from_node and connection__to_node
initial_connections_invested
Setting a value fixes the connections_invested variable at the beginning
Default value: nothing
Related Object Classes: connection
initial_connections_invested_available
Setting a value fixes the connectionsinvestedavailable variable at the beginning
Default value: nothing
Related Object Classes: connection
initial_node_pressure
Initializes the corresponding
node_pressurevariable to the provided value
Default value: nothing
Related Object Classes: node
initial_node_state
Initializes the corresponding
node_statevariable to the provided value.
Default value: nothing
Related Object Classes: node
initial_node_voltage_angle
Initializes the corresponding
node_voltage_anglevariable to the provided value
Default value: nothing
Related Object Classes: node
initial_nonspin_units_shut_down
Initialize the
nonspin_units_shut_downvariable.
Default value: nothing
Related Relationship Classes: unit__to_node
initial_nonspin_units_started_up
Initialize the
nonspin_units_started_upvariable.
Default value: nothing
Related Relationship Classes: unit__from_node and unit__to_node
initial_storages_invested
Used to initialze the value of the storages_invested variable
Default value: nothing
Related Object Classes: node
initial_storages_invested_available
Used to initialze the value of the storagesinvestedavailable variable
Default value: nothing
Related Object Classes: node
initial_unit_flow
Initialize the
unit_flowvariable.
Default value: nothing
Related Relationship Classes: unit__from_node and unit__to_node
initial_unit_flow_op
Initialize the
unit_flow_opvariable.
Default value: nothing
Related Relationship Classes: unit__from_node and unit__to_node
initial_units_invested
Initialize the value of the
units_investedvariable.
Default value: nothing
Related Object Classes: unit
initial_units_invested_available
Initialize the value of the
units_invested_availablevariable
Default value: nothing
Related Object Classes: unit
initial_units_on
Initialize the value of the
units_onvariable.
Default value: nothing
Related Object Classes: unit
initial_units_out_of_service
Initialize the value of the
units_out_of_servicevariable.
Default value: nothing
Related Object Classes: unit
is_longterm_storage
If true,
nodehas a state variable for representative and non-representative timeslices
Default value: false
Related Object Classes: node
is_non_spinning
A boolean flag for whether a
nodeis acting as a non-spinning reserve
Default value: false
Related Object Classes: node
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 set is_reserve_node to true. The mathematical formulation holds a chapter on Reserve constraints and the general concept of setting up a model with reserves is described in Reserves.
is_renewable
Whether the unit is renewable - used in the minimum renewable generation constraint within the Benders master problem
Default value: false
Related Object Classes: unit
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.## is_reserve_node
A boolean flag for whether a
nodeis acting as areserve_node
Default value: false
Related Object Classes: node
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 Reserve constraints and the general concept of setting up a model with reserves is described in Reserves.
max_cum_in_unit_flow_bound
Set a maximum cumulative upper bound for a
unit_flow
Default value: nothing
Related Relationship Classes: unit__commodity
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)
max_gap
Specifies the maximum optimality gap for the model. Currently only used for the master problem within a decomposed structure
Default value: 0.05
Related Object Classes: model
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.## max_iterations
Specifies the maximum number of iterations for the model. Currently only used for the master problem within a decomposed structure
Default value: 10.0
Related Object Classes: model
When the model in question is of type :spineopt_benders_master, this determines the maximum number of Benders iterations.## max_mga_iterations
Define the number of mga iterations, i.e. how many alternative solutions will be generated.
Default value: nothing
Related Object Classes: model
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.
max_mga_slack
Defines the maximum slack by which the alternative solution may differ from the original solution (e.g. 5% more than initial objective function value)
Default value: 0.05
Related Object Classes: model
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).
max_node_pressure
Maximum allowed gas pressure at
node.
Default value: nothing
Related Object Classes: node
If a node has a node_pressure variable (see also the parameter has_pressure and this chapter), an upper bound on the pressure can be introduced through the max_node_pressure parameter, which triggers the generation of the maxmimum node pressure constraint.
max_ratio_in_in_unit_flow
Maximum ratio between two
unit_flowscoming into theunitfrom the twonodes.
Default value: nothing
Related Relationship Classes: unit__node__node
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.
max_ratio_in_out_unit_flow
Maximum ratio between an incoming
unit_flowfrom the firstnodeand an outgoingunit_flowto the secondnode.
Default value: nothing
Related Relationship Classes: unit__node__node
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.
max_ratio_out_in_connection_flow
Maximum ratio between an outgoing
connection_flowto the firstnodeand an incomingconnection_flowfrom the secondnode.
Default value: nothing
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.## max_ratio_out_in_unit_flow
Maximum ratio between an outgoing
unit_flowto the firstnodeand an incomingunit_flowfrom the secondnode.
Default value: nothing
Related Relationship Classes: unit__node__node
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.
max_ratio_out_out_unit_flow
Maximum ratio between two
unit_flowsgoing from theunitinto the twonodes.
Default value: nothing
Related Relationship Classes: unit__node__node
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.
max_total_cumulated_unit_flow_from_node
Bound on the maximum cumulated flows of a unit group from a node group e.g max consumption of certain commodity.
Default value: nothing
Related Relationship Classes: unit__from_node
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.
max_total_cumulated_unit_flow_to_node
Bound on the maximum cumulated flows of a unit group to a node group, e.g. total GHG emissions.
Default value: nothing
Related Relationship Classes: unit__to_node
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.
max_units_on_coefficient_in_in
Optional coefficient for the
units_onvariable impacting themax_ratio_in_in_unit_flowconstraint.
Default value: 0.0
Related Relationship Classes: unit__node__node
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.## max_units_on_coefficient_in_out
Optional coefficient for the
units_onvariable impacting themax_ratio_in_out_unit_flowconstraint.
Default value: 0.0
Related Relationship Classes: unit__node__node
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.## max_units_on_coefficient_out_in
Optional coefficient for the
units_onvariable impacting themax_ratio_out_in_unit_flowconstraint.
Default value: 0.0
Related Relationship Classes: unit__node__node
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.
max_units_on_coefficient_out_out
Optional coefficient for the
units_onvariable impacting themax_ratio_out_out_unit_flowconstraint.
Default value: 0.0
Related Relationship Classes: unit__node__node
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.## max_voltage_angle
Maximum allowed voltage angle at
node.
Default value: nothing
Related Object Classes: node
If a node has a node_voltage_angle variable (see also the parameter has_voltage_angle and this chapter), an upper bound on the voltage angle can be introduced through the max_voltage_angle parameter, which triggers the generation of the maximum node voltage angle constraint.
maximum_capacity_invested_available
Upper bound on the capacity invested available in the group at any point in time.
Default value: nothing
Related Object Classes: investment_group
maximum_entities_invested_available
Upper bound on the number of entities invested available in the group at any point in time.
Default value: nothing
Related Object Classes: investment_group
min_capacity_margin
minimum capacity margin applying to the
nodeornode_group
Default value: nothing
Related Object Classes: node
The parameter min_capacity_margin triggers the creation of a constraint of the same name which ensures that the difference between available unit capacity and demand at the corresponding node is at least min_capacity_margin. In the calculation of capacity_margin, storage units' actual flows are used in place of the capacity. Defining a min_capacity_margin can be useful for scheduling unit maintenance outages (see scheduled_outage_duration for how to define a unit outage requirement) and for triggering unit investments due to capacity shortage. The min_capacity_margin constraint can be softened by defining min_capacity_margin_penalty this allows violation of the constraint which are penalised in the objective function.## min_capacity_margin_penalty
penalty to apply to violations of the min capacitymargin constraint of the
nodeor `nodegroup`
Default value: nothing
Related Object Classes: node
The min_capacity_margin_penalty parameter triggers the addition of the min_capacity_margin_slack slack variable in the min_capacity_margin constraint. This allows violation of the constraint which are penalised in the objective function. This can be used to capture the capacity_value of investments. This can also be used to disincentivise scheduling of maintenance outages during times of low capacity. See scheduled_outage_duration for how to define a unit scheduled outage requirement## min_down_time
Minimum downtime of a
unitafter it shuts down.
Default value: nothing
Related Object Classes: unit
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.
min_iterations
Specifies the minimum number of iterations for the model. Currently only used for the master problem within a decomposed structure
Default value: 1.0
Related Object Classes: model
min_node_pressure
Minimum allowed gas pressure at
node.
Default value: nothing
Related Object Classes: node
If a node has a node_pressure variable (see also the parameter has_pressure and this chapter), a lower bound on the pressure can be introduced through the min_node_pressure parameter, which triggers the generation of the minimum node pressure constraint.
min_ratio_in_in_unit_flow
Minimum ratio between two
unit_flowscoming into theunitfrom the twonodes.
Default value: nothing
Related Relationship Classes: unit__node__node
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.
min_ratio_in_out_unit_flow
Minimum ratio between an incoming
unit_flowfrom the firstnodeand an outgoingunit_flowto the secondnode.
Default value: nothing
Related Relationship Classes: unit__node__node
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.
min_ratio_out_in_connection_flow
Minimum ratio between an outgoing
connection_flowto the firstnodeand an incomingconnection_flowfrom the secondnode.
Default value: nothing
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.
min_ratio_out_in_unit_flow
Minimum ratio between an outgoing
unit_flowto the firstnodeand an incomingunit_flowfrom the secondnode.
Default value: nothing
Related Relationship Classes: unit__node__node
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.
min_ratio_out_out_unit_flow
Minimum ratio between two
unit_flowsgoing from theunitinto the twonodes.
Default value: nothing
Related Relationship Classes: unit__node__node
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.
min_total_cumulated_unit_flow_from_node
Bound on the minimum cumulated flows of a unit group from a node group.
Default value: nothing
Related Relationship Classes: unit__from_node
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.
min_total_cumulated_unit_flow_to_node
Bound on the minimum cumulated flows of a unit group to a node group, e.g. total renewable production.
Default value: nothing
Related Relationship Classes: unit__to_node
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.
min_unit_flow
Set lower bound of the
unit_flowvariable.
Default value: 0.0
Related Relationship Classes: unit__from_node and unit__to_node
min_units_on_coefficient_in_in
Optional coefficient for the
units_onvariable impacting themin_ratio_in_in_unit_flowconstraint.
Default value: 0.0
Related Relationship Classes: unit__node__node
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.## min_units_on_coefficient_in_out
Optional coefficient for the
units_onvariable impacting themin_ratio_in_out_unit_flowconstraint.
Default value: 0.0
Related Relationship Classes: unit__node__node
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.
min_units_on_coefficient_out_in
Optional coefficient for the
units_onvariable impacting themin_ratio_out_in_unit_flowconstraint.
Default value: 0.0
Related Relationship Classes: unit__node__node
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.## min_units_on_coefficient_out_out
Optional coefficient for the
units_onvariable impacting themin_ratio_out_out_unit_flowconstraint.
Default value: 0.0
Related Relationship Classes: unit__node__node
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.## min_up_time
Minimum uptime of a
unitafter it starts up.
Default value: nothing
Related Object Classes: unit
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.
min_voltage_angle
Minimum allowed voltage angle at
node.
Default value: nothing
Related Object Classes: node
If a node has a node_voltage_angle variable (see also the parameter has_voltage_angle and this chapter), a lower bound on the pressure can be introduced through the min_voltage_angle parameter, which triggers the generation of the minimum node voltage angle constraint.
minimum_capacity_invested_available
Lower bound on the capacity invested available in the group at any point in time.
Default value: nothing
Related Object Classes: investment_group
minimum_entities_invested_available
Lower bound on the number of entities invested available in the group at any point in time.
Default value: nothing
Related Object Classes: investment_group
minimum_operating_point
Minimum level for the
unit_flowrelative to theunits_ononline capacity.
Default value: nothing
Related Relationship Classes: unit__from_node and unit__to_node
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.
minimum_reserve_activation_time
Duration a certain reserve product needs to be online/available
Default value: nothing
Related Object Classes: node
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 Reserves
model_algorithm
The algorithm to run (e.g., basic, MGA)
Default value: basic_algorithm
Related Object Classes: model
model_end
Defines the last timestamp to be modelled. Rolling optimization terminates after passing this point.
Default value: Dict{String, Any}("data" => "2000-01-02T00:00:00", "type" => "date_time")
Related Object Classes: model
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.
model_start
Defines the first timestamp to be modelled. Relative
temporal_blocksrefer to this value for their start and end.
Default value: Dict{String, Any}("data" => "2000-01-01T00:00:00", "type" => "date_time")
Related Object Classes: model
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.
model_type
The model type which gives the solution method (e.g. standerd, Benders)
Default value: spineopt_standard
Related Object Classes: model
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.
monte_carlo_scenarios
A map from scenario key, to array of scenario values
Default value: nothing
Related Object Classes: model
mp_min_res_gen_to_demand_ratio
Minimum ratio of renewable generation to demand for this commodity - used in the minimum renewable generation constraint within the Benders master problem
Default value: nothing
Related Object Classes: commodity
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.## mp_min_res_gen_to_demand_ratio_slack_penalty
Penalty for violating the minimum renewable generation to demand ratio.
Default value: nothing
Related Object Classes: commodity
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.## nodal_balance_sense
A selector for
nodal_balanceconstraint sense.
Default value: ==
Related Object Classes: node
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.## node_opf_type
A selector for the reference
node(slack bus) when PTDF-based DC load-flow is enabled.
Default value: node_opf_type_normal
Related Object Classes: node
Used to identify the reference node (or slack bus) when ptdf based dc load flow is enabled (commodity_physics set to commodity_physics_ptdf or commodity_physics_lodf. To identify the reference node, set node_opf_type = :node_opf_type_reference
See also powerflow.
node_slack_penalty
A penalty cost for
node_slack_posandnode_slack_negvariables. The slack variables won't be included in the model unless there's a cost defined for them.
Default value: nothing
Related Object Classes: node
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.
node_state_cap
The maximum permitted value for a
node_statevariable.
Default value: nothing
Related Object Classes: node
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.
node_state_coefficient
Coefficient of the specified node's state variable in the specified user constraint.
Default value: 0.0
The node_state_coefficient is an optional parameter that can be used to include the node_state variable of a node in a user_constraint via the node__user_constraint relationship. Essentially, node_state_coefficient appears as a coefficient for the node_state variable of the node in the user constraint.
node_state_min
The minimum permitted value for a
node_statevariable.
Default value: 0.0
Related Object Classes: node
The node_state_min parameter sets the lower bound for the node_state variable, if one has been enabled by the has_state parameter. For reserve nodes with minimum_reserve_activation_time, the node_state_min is considered also via a special constraint.## number_of_connections
Denotes the number of 'sub connections' aggregated to form the modelled
connection.
Default value: 1.0
Related Object Classes: connection
number_of_storages
Denotes the number of 'sub storages' aggregated to form the modelled
node.
Default value: 1.0
Related Object Classes: node
number_of_units
Denotes the number of 'sub units' aggregated to form the modelled
unit. The default value becomes zero ifcandidate_unitshas been defined.
Default value: 1.0
Related Object Classes: unit
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 and units_unavailable, 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. It is also possible to schedule maintenance outages using outage_variable_type and scheduled_outage_duration.
The default value for this parameter is 1. The default value is 0 when candidate_units has been defined for the unit in question.
online_variable_type
A selector for how the
units_onvariable is represented within the model.
Default value: unit_online_variable_type_linear
Related Object Classes: unit
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.
operating_points
- For
unit__from_node: Operating points for piecewise-linearunitefficiency approximations.- For
unit__to_node: Decomposes the flow variable into a number of separate operating segment variables. Used to in conjunction withunit_incremental_heat_rateand/oruser_constraints
Default value: nothing
Related Relationship Classes: unit__from_node and unit__to_node
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 fix_ratio_in_out_unit_flow where the array dimension must match and is used to define the normalized operating point bounds for the corresponding incremental ratio. 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.## ordered_unit_flow_op
Defines whether the segments of this unit flow are ordered as per the rank of their operating points.
Default value: false
Related Relationship Classes: unit__from_node and unit__to_node
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.
outage_variable_type
Determines whether the outage variable is integer or continuous or none(no optimisation of maintenance outages).
Default value: unit_online_variable_type_none
Related Object Classes: unit
outage_variable_type is a method parameter to model the 'commitment' or 'activation' of unit maintenance outages.
To scheduled maintenance outages, one must activate the units_out\of_service variable. This is done by changing the value of the outage_variable_type to either online_variable_type_integer (for clustered units) or online_variable_type_binary for binary units or unit_online_variable_type_linear for continuous units. Setting outage_variable_type to online_variable_type_none will deactivate the units_out\of_service variable and this is the default value.## output_db_url
Database url for SpineOpt output.
Default value: nothing
Related Object Classes: report
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.## output_resolution
- For
output: Temporal resolution of the output variables associated with thisoutput.- For
stage__output,stage__output__connection,stage__output__node,stage__output__unit: A duration or array of durations indicating the points in time where the output of this stage should be fixed in the children. If not specified, then the output is fixed at the end of each child's roling window (EXPERIMENTAL).
Default value: nothing
Related Object Classes: output
Related Relationship Classes: stage__output__connection, stage__output__node, stage__output__unit and stage__output
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.
output_type
Type of this
output.
Default value: nothing
Related Object Classes: output
overwrite_results_on_rolling
Whether or not results from further windows should overwrite results from previous ones.
Default value: true
Related Relationship Classes: report__output
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.## ramp_down_limit
Limit the maximum ramp-down rate of an online unit, given as a fraction of the unitcapacity. [rampdown_limit] = %/t, e.g. 0.2/h
Default value: nothing
Related Relationship Classes: unit__from_node and unit__to_node
The definition of the ramp_down_limit parameter limits the maximum decrease in the unit_flow over a period of time of one duration_unit whenever 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 specified, the limit will not be imposed, which is equivalent to choosing a value of 1.
For a more complete description of how ramping restrictions can be implemented, see Ramping.
ramp_up_limit
Limit the maximum ramp-up rate of an online unit, given as a fraction of the unitcapacity. [rampup_limit] = %/t, e.g. 0.2/h
Default value: nothing
Related Relationship Classes: unit__from_node and unit__to_node
The definition of the ramp_up_limit parameter limits the maximum increase in the unit_flow over a period of time of one duration_unit whenever 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 specified, the limit will not be imposed, which is equivalent to choosing a value of 1.
For a more complete description of how ramping restrictions can be implemented, see Ramping.
report_benders_iterations
Whether to save results from Benders iterations before convergence.
Default value: false
Related Object Classes: model
representative_period_index
Index for the array of coefficients defined in
representative_periods_mapping
Default value: nothing
Related Object Classes: temporal_block
representative_periods_mapping
Map from date time to representative temporal block combination (either a single block's name, or an array of coefficients for each block that has a
representative_period_index)
Default value: nothing
Related Object Classes: temporal_block
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:
- Define one
temporal_blockfor the 'normal' periods as you would do if you weren't using representative periods. - Define a set of
temporal_blockobjects, each corresponding to one representative period. - Specify
representative_periods_mappingfor the 'normal'temporal_blockas a map, from consecutive date-time values to the name of a representativetemporal_block. - Associate all the above
temporal_blockobjects 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.## reserve_procurement_cost
Procurement cost for reserves
Default value: nothing
Related Relationship Classes: unit__from_node and unit__to_node
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.
resolution
Temporal resolution of the
temporal_block. Essentially, divides the period betweenblock_startandblock_endintoTimeSliceswith the inputresolution.
Default value: Dict{String, Any}("data" => "1h", "type" => "duration")
Related Object Classes: temporal_block
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.
right_hand_side
The right-hand side, constant term in a
user_constraint. Can be time-dependent and used e.g. for complicated efficiency approximations.
Default value: 0.0
Related Object Classes: user_constraint
Used to specify the right-hand-side, constant term in a user_constraint. See also user_constraint.
roll_forward
Defines how much the model moves ahead in time between solves in a rolling optimization. If null, everything is solved in as a single optimization.
Default value: nothing
Related Object Classes: model
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.## scheduled_outage_duration
Specifies the amount of time a unit must be out of service for maintenance as a single block over the course of the optimisation window
Default value: nothing
Related Object Classes: unit
shared_values
A map from symbol to shared value.
Default value: nothing
Related Object Classes: model
shut_down_cost
Costs of shutting down a 'sub unit', e.g. EUR/shutdown.
Default value: nothing
Related Object Classes: unit
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.
shut_down_limit
Maximum ramp-down during shutdowns
Default value: nothing
Related Relationship Classes: unit__from_node and unit__to_node
The definition of the shut_down_limit parameter 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 specified the limit will not be imposed, which is equivalent to choosing a value of 1.
slack_penalty
A penalty for violating the constraint that fixes this output for this stage (EXPERIMENTAL).
Default value: nothing
Related Relationship Classes: stage__output__connection, stage__output__node and stage__output__unit
stage_scenario
The scenario that this
stageshould run (EXPERIMENTAL).
Default value: nothing
Related Object Classes: stage
start_up_cost
Costs of starting up a 'sub unit', e.g. EUR/startup.
Default value: nothing
Related Object Classes: unit
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.
start_up_limit
Maximum ramp-up during startups
Default value: nothing
Related Relationship Classes: unit__from_node and unit__to_node
The definition of the start_up_limit parameter 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 specified the limit will not be imposed, which is equivalent to choosing a value of 1.
state_coeff
Represents the
commoditycontent of anode_statevariable in respect to theunit_flowandconnection_flowvariables. Essentially, acts as a coefficient on thenode_statevariable in thenode_injectionconstraint.
Default value: 1.0
Related Object Classes: node
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.
stochastic_scenario_end
A
Durationfor when astochastic_scenarioends and itschild_stochastic_scenariosstart. Values are interpreted relative to the start of the current solve, and if no value is given, thestochastic_scenariois assumed to continue indefinitely.
Default value: nothing
Related Relationship Classes: stochastic_structure__stochastic_scenario
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.## storage_decommissioning_cost
Costs associated with decommissioning a power plant. The costs will b discounted to the
discount_year`at distribted equally over the decommissioning time.
Default value: nothing
Related Object Classes: node
storage_decommissioning_time
A storage's decommissioning time, i.e., the time between the moment at which a storage decommissioning decision is takien, and the moment at which decommissioning is complete.
Default value: Dict{String, Any}("data" => "0h", "type" => "duration")
Related Object Classes: node
storage_discount_rate_technology_specific
storage-specific discount rate used to calculate the storage's investment costs. If not specified, the model discount rate is used.
Default value: 0.0
Related Object Classes: node
storage_fom_cost
Fixed operation and maintenance costs of a
node. Essentially, a cost coefficient on the number of installed units andnode_state_capparameters. E.g. EUR/MWh
Default value: nothing
Related Object Classes: node
storage_investment_cost
Determines the investment cost per unit state_cap over the investment life of a storage
Default value: nothing
Related Object Classes: node
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.
storage_investment_econ_lifetime
Economic lifetime for storage investment decisions.
Default value: nothing
Related Object Classes: node
storage_investment_lifetime_sense
A selector for
storage_lifetimeconstraint sense.
Default value: >=
Related Object Classes: node
storage_investment_tech_lifetime
Maximum technical lifetime for storage investment decisions.
Default value: nothing
Related Object Classes: node
storage_investment_variable_type
Determines whether the storage investment variable is continuous (usually representing capacity) or integer (representing discrete units invested)
Default value: storage_investment_variable_type_integer
Uses Parameter Value Lists: storage_investment_variable_type_list
Related Object Classes: node
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.
storage_lead_time
A storage's lead time, i.e., the time between the moment at which a storage investment decision is takien, and the moment at which the storage investment becomes operational.
Default value: Dict{String, Any}("data" => "0h", "type" => "duration")
Related Object Classes: node
storages_invested_available_coefficient
Coefficient of the specified node's storages invested available variable in the specified user constraint.
Default value: 0.0
storages_invested_big_m_mga
bigmmga should be chosen as small as possible but sufficiently large. For unitsinvestedmga an appropriate bigmmga would be twice the candidate storages.
Default value: nothing
Related Object Classes: node
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.)
storages_invested_coefficient
Coefficient of the specified node's storage investment variable in the specified user constraint.
Default value: 0.0
The storages_invested_coefficient is an optional parameter that can be used to include the storages_invested variable in a user_constraint via the node__user_constraint relationship. Essentially, storages_invested_coefficient appears as a coefficient for the storages_invested variable in the user constraint. For more information, see the [User Constraints Concept Reference][#User-Constraints]
storages_invested_mga
Defines whether a certain variable (here: storages_invested) will be considered in the maximal-differences of the mga objective
Default value: false
Related Object Classes: node
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.
storages_invested_mga_weight
Used to scale mga variables. For weighted-sum mga method, the length of this weight given as an Array will determine the number of iterations.
Default value: 1
Related Object Classes: node
tax_in_unit_flow
Tax costs for incoming
unit_flowson thisnode. E.g. EUR/MWh.
Default value: nothing
Related Object Classes: node
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.
tax_net_unit_flow
Tax costs for net incoming and outgoing
unit_flowson thisnode. Incoming flows accrue positive net taxes, and outgoing flows accrue negative net taxes.
Default value: nothing
Related Object Classes: node
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.
tax_out_unit_flow
Tax costs for outgoing
unit_flowsfrom thisnode. E.g. EUR/MWh.
Default value: nothing
Related Object Classes: node
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.
unit_availability_factor
Availability of the
unit, acting as a multiplier on itsunit_capacity. Typically between 0-1.
Default value: 1.0
Related Object Classes: unit
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.
unit_capacity
Maximum
unit_flowcapacity of a single 'sub_unit' of theunit.
Default value: nothing
Related Relationship Classes: unit__from_node and unit__to_node
To set an upper bound on the commodity flow of a unit in a certain direction, the unit_capacity constraint needs to be defined on a unit__to_node or unit__from_node relationship. By defining the parameter, the unit_flow variables to or from a node or a group of nodes will be constrained by the capacity constraint.
Note that if the unit_capacity parameter is defined on a node group, the sum of all unit_flows within the specified node group will be constrained by the unit_capacity.
unit_conv_cap_to_flow
Optional coefficient for
unit_capacityunit conversions in the case theunit_capacityvalue is incompatible with the desiredunit_flowunits.
Default value: 1.0
Related Relationship Classes: unit__from_node and unit__to_node
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.
unit_decommissioning_cost
Costs associated with decommissioning a power plant. The costs will b discounted to the
discount_year`at distribted equally over the decommissioning time.
Default value: nothing
Related Object Classes: unit
unit_decommissioning_time
A unit's decommissioning time, i.e., the time between the moment at which a unit decommissioning decision is takien, and the moment at which decommissioning is complete.
Default value: Dict{String, Any}("data" => "0h", "type" => "duration")
Related Object Classes: unit
unit_discount_rate_technology_specific
Unit-specific discount rate used to calculate the unit's investment costs. If not specified, the model discount rate is used.
Default value: 0.0
Related Object Classes: unit
unit_flow_coefficient
Coefficient of a
unit_flowvariable for a customuser_constraint.
Default value: 0.0
Related Relationship Classes: unit__from_node__user_constraint and unit__to_node__user_constraint
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.
unit_flow_non_anticipativity_margin
Margin by which
unit_flowvariable can differ from the value in the previous window duringnon_anticipativity_time.
Default value: nothing
Related Relationship Classes: unit__from_node and unit__to_node
unit_flow_non_anticipativity_time
Period of time where the value of the
unit_flowvariable has to be fixed to the result from the previous window.
Default value: nothing
Related Relationship Classes: unit__from_node and unit__to_node
unit_investment_cost
Investment cost per 'sub unit' built.
Default value: nothing
Related Object Classes: unit
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.
unit_investment_econ_lifetime
Economic lifetime for unit investment decisions.
Default value: nothing
Related Object Classes: unit
unit_investment_lifetime_sense
A selector for
unit_lifetimeconstraint sense.
Default value: >=
Related Object Classes: unit
unit_investment_tech_lifetime
Maximum technical lifetime for unit investment decisions.
Default value: nothing
Related Object Classes: unit
unit_investment_variable_type
Determines whether investment variable is integer or continuous.
Default value: unit_investment_variable_type_continuous
Uses Parameter Value Lists: unit_investment_variable_type_list
Related Object Classes: unit
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
unit_lead_time
A unit's lead time, i.e., the time between the moment at which a unit investment decision is takien, and the moment at which the unit investment becomes operational.
Default value: Dict{String, Any}("data" => "0h", "type" => "duration")
Related Object Classes: unit
unit_start_flow
Flow from node1 that is incurred when a unit is started up.
Default value: 0.0
Related Relationship Classes: unit__node__node
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.
units_invested_available_coefficient
Coefficient of the
units_invested_availablevariable in the specifieduser_constraint.
Default value: 0.0
units_invested_big_m_mga
bigmmga should be chosen as small as possible but sufficiently large. For unitsinvestedmga an appropriate bigmmga would be twice the candidate units.
Default value: nothing
Related Object Classes: unit
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.)
units_invested_coefficient
Coefficient of the
units_investedvariable in the specifieduser_constraint.
Default value: 0.0
The units_invested_coefficient is an optional parameter that can be used to include the units_invested variable in a user_constraint via the unit__user_constraint relationship. Essentially, units_invested_coefficient appears as a coefficient for the units_invested variable in the user constraint. For more information, see the [User Constraints Concept Reference][#User-Constraints]
units_invested_mga
Defines whether a certain variable (here: units_invested) will be considered in the maximal-differences of the mga objective
Default value: false
Related Object Classes: unit
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.
units_invested_mga_weight
Used to scale mga variables. For weightd sum mga method, the length of this weight given as an Array will determine the number of iterations.
Default value: 1
Related Object Classes: unit
units_on_coefficient
Coefficient of a
units_onvariable for a customuser_constraint.
Default value: 0.0
The units_on_coefficient is an optional parameter that can be used to include the units_on variable of a unit in a user_constraint via the unit__user_constraint relationship. Essentially, units_on_coefficient appears as a coefficient for the units_on variable of the unit in the user constraint.
units_on_cost
Objective function coefficient on
units_on. An idling cost, for example
Default value: nothing
Related Object Classes: unit
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.
units_on_non_anticipativity_margin
Margin by which
units_onvariable can differ from the value in the previous window duringnon_anticipativity_time.
Default value: nothing
Related Object Classes: unit
units_on_non_anticipativity_time
Period of time where the value of the
units_onvariable has to be fixed to the result from the previous window.
Default value: nothing
Related Object Classes: unit
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.
units_started_up_coefficient
Coefficient of a
units_started_upvariable for a customuser_constraint.
Default value: 0.0
The units_started_up_coefficient is an optional parameter that can be used to include the units_started_up variable of a unit in a user_constraint via the unit__user_constraint relationship. Essentially, units_started_up_coefficient appears as a coefficient for the units_started_up variable of the unit in the user constraint.
units_unavailable
Represents the number of units out of service
Default value: 0
Related Object Classes: unit
For clustered units, defines how many members of that unit are out of service, generally, or at a particular time. This can be used to, for example, to model maintenance outages. Typically this parameter takes a binary (UC) or integer (clustered UC) value. Together with the unit_availability_factor, and number_of_units, 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 schedule maintenance outages using outage_variable_type and scheduled_outage_duration.
The default value for this parameter is 0.
upward_reserve
Identifier for
nodes providing upward reserves
Default value: false
Related Object Classes: node
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.
use_connection_intact_flow
Whether to use
connection_intact_flowvariables, to capture the impact of connection investments on network characteristics via line outage distribution factors (LODF).
Default value: true
Related Object Classes: model
use_economic_representation
If set to true, the investment models uses economic represenation, i.e., multi-year investments will be modeled considering discounts etc.
Default value: false
Related Object Classes: model
use_highest_resolution_constraint_ratio_out_in_connection_flow
Whether to use highest resolution for constraint ratio out in connection flow.
Default value: true
Related Object Classes: model
use_milestone_years
If set to true, the investment models uses milestone years. In other words, operational temporal blocks for one (milestone) year will be scaled up by the discounted duration to represent the entire investment period.
Default value: false
Related Object Classes: model
use_tight_compact_formulations
Whether to use tight and compact constraint formulations.
Default value: false
Related Object Classes: model
user_constraint_slack_penalty
A penalty for violating a user constraint.
Default value: nothing
Related Object Classes: user_constraint
version
Current version of the SpineOpt data structure. Modify it at your own risk (but please don't).
Default value: 16
Related Object Classes: settings
vom_cost
Variable operating costs of a
unit_flowvariable. E.g. EUR/MWh.
Default value: nothing
Related Relationship Classes: unit__from_node and unit__to_node
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.
weight
Weighting factor of the temporal block associated with the objective function
Default value: 1.0
Related Object Classes: temporal_block
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.
weight_relative_to_parents
The weight of the
stochastic_scenarioin the objective function relative to its parents.
Default value: 1.0
Related Relationship Classes: stochastic_structure__stochastic_scenario
The weight_relative_to_parents parameter defines how much weight the stochastic_scenario gets in the Objective function. As a stochastic_structure__stochastic_scenario relationship parameter, different stochastic_structures can use different weights for the same stochastic_scenario. Note that every stochastic_scenario that appears in the model must have a weight_relative_to_parents defined for it related to the used stochastic_structure! See the Stochastic Framework section for more information about how different stochastic_structures interact in SpineOpt.jl.)
Since the Stochastic Framework in SpineOpt.jl supports stochastic directed acyclic graphs instead of simple stochastic trees, it is possible to define stochastic_structures with converging stochastic_scenarios. In these cases, the child stochastic_scenarios inherint the weight of all of their parents, and the final weight that will appear in the Objective function is calculated as shown below:
# For root `stochastic_scenarios` (meaning no parents)
weight(scenario) = weight_relative_to_parents(scenario)
# 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
Default value: nothing
Related Object Classes: model
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.
- Specify roll_forward as an array of n duration values, so the subproblem rolls over representative periods.
- Specify
window_weightas 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.
write_lodf_file
A boolean flag for whether the LODF values should be written to a results file.
Default value: false
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.
Default value: nothing
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 PTDF values should be written to a results file.
Default value: false
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.