Parameters

`availability_factor`

For connection: Availability of the connection, acting as a multiplier on its capacity_per_connection. Typically between 0-1.
For unit: Availability of the unit, acting as a multiplier on its capacity_per_unit. Typically between 0-1.

Default value: 1.0

Related Entity Classes: connection and unit

Connection: To indicate that a connection is only available to a certain extent or at certain times of the optimization, the 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.

Unit: To indicate that a unit is only available to a certain extent or at certain times of the optimization, the 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.

`balance_penalty`

Penalty cost applied to violations of the nodal_balance constraint, i.e., to the node_slack_pos and node_slack_neg variables. The slack variables won't be included in the model unless there's a penalty defined for them.

Default value: nothing

Related Entity Classes: node

balance_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 balance_penalty. If balance_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.

`balance_sense`

A selector for nodal_balance constraint sense.

Default value: ==

Uses Parameter Value Lists: constraint_sense_list

Supported parameter value types: str

Related Entity Classes: node

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.

`balance_type`

A selector for how the nodal_balance constraint should be handled: whether the constraint is created for nodes, node groups, or not at all, and whether the flows are instantaneously balanced or the node can store its commodity.

Default value: node_balance

Uses Parameter Value Lists: balance_type_list

Supported parameter value types: str

Related Entity 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 node_balance (the default) and group_balance mean that the node is always balanced according to the nodal balance and node injection constraints.

The only exceptions to enforcing the balance in the options above are if the node belongs in a group that has itself balance_type equal to group_balance.

The value none means that the node doesn't need to be balanced.

`benders_iterations_reporting_active`

Whether to save results from Benders iterations before convergence.

Default value: false

Uses Parameter Value Lists: boolean_value_list

Supported parameter value types: bool

Related Entity Classes: model

TODO: IMPROVE THIS EXPLANATION!

Primarily used for debugging purposes?

See Decomposition.

`benders_starting_connections_invested`

Fixes the number of connections invested during the first Benders iteration.

Default value: nothing

Related Entity Classes: connection

TODO: IMPROVE THIS EXPLANATION!

See Decomposition.

`benders_starting_storages_invested`

Fixes the number of storages invested during the first Benders iteration.

Default value: nothing

Related Entity Classes: node

TODO: IMPROVE THIS EXPLANATION!

See Decomposition.

`benders_starting_units_invested`

Fixes the number of units invested during the first Benders iteration.

Default value: nothing

Related Entity Classes: unit

TODO: IMPROVE THIS EXPLANATION!

See Decomposition.

`big_m`

Sufficiently large number used for linearization bilinear terms, e.g. to enforce bidirectional flow for gas pipielines

Default value: 1000000

Related Entity 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.

`binary_gas_flow_active`

A boolean flag for activating a representation based on bidirectional pressure driven gas transfer.

Default value: false

Uses Parameter Value Lists: boolean_value_list

Supported parameter value types: bool

Related Entity 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 binary_gas_flow_active 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.

`binary_gas_flow_limits_fix`

Fix the value of the connection_flow_binary variable, and hence pre-determine the direction of flow in the connection.

Default value: nothing

Related Entity 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 binary_gas_flow_limits_fix parameter can be used.

`binary_gas_flow_limits_initial`

Set the initial value for the connection_flow_binary variable, and hence pre-determine the direction of flow in the connection.

Default value: nothing

Related Entity Classes: connection__from_node and connection__to_node

Set the initial value for the binary_gas_connection_flow variable, i.e. its value prior to model_start.

`block_end`

The end time for the temporal_block. Can be given either as a DateTime for a static end point, or as a Duration for an end point relative to the model_start.

Default value: nothing

Supported parameter value types: date_time, duration

Related Entity 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 a DateTime for a static start point, or as a Duration for an start point relative to model_start.

Default value: nothing

Supported parameter value types: date_time, duration

Related Entity 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.

`capacity_margin_min`

Minimum capacity margin for the node or node_group. The required margin by which available production capacity must exceed demand.

Default value: nothing

Related Entity Classes: node

The parameter capacity_margin_min triggers the creation of a capacity_margin_min constraint which ensures that the difference between available unit capacity and demand at the corresponding node is at least capacity_margin_min. In SpineOpt.add_expression_capacity_margin!, storage units' actual flows are used in place of the capacity. Defining a capacity_margin_min can be useful for scheduling unit maintenance outages (see outage_scheduled_duration for how to define a unit outage requirement) and for triggering unit investments due to capacity shortage. The capacity_margin_min constraint can be softened by defining capacity_margin_penalty this allows violation of the constraint which are penalised in the objective function.

`capacity_margin_penalty`

Penalty cost applied to violations of the min capacitymargin constraint of the node or `nodegroup`.

Default value: nothing

Related Entity Classes: node

The capacity_margin_penalty parameter triggers the addition of the min_capacity_margin_slack slack variable in the minimum 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 outage_scheduled_duration for how to define a unit scheduled outage requirement.

`capacity_per_connection`

For connection__fromnode: Limits the `connectionflowvariable from thefromnode.fromnodecan be a group ofnodes, in which case the sum of theconnection_flow` is constrained.
For connection__tonode: Limits the `connectionflowvariable to thetonode.tonodecan be a group ofnodes, in which case the sum of theconnection_flow` is constrained.

Default value: nothing

Related Entity 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 capacity_per_connection. If PTDF based DC load flow is enabled, capacity_per_connection represents the normal rating of a connection (line) while connection_emergency_capacity represents the maximum post contingency flow.

`capacity_per_unit`

Maximum unit_flow capacity of a single 'sub_unit' of the unit.

Default value: nothing

Related Entity Classes: node__to_unit and unit__to_node

To set an upper bound on the commodity flow of a unit in a certain direction, the capacity_per_unit constraint needs to be defined on a unit__to_node or node__to_unit 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 capacity_per_unit parameter is defined on a node group, the sum of all unit_flows within the specified node group will be constrained by the capacity_per_unit.

`capacity_to_flow_conversion_factor`

For connection__fromnode: Optional coefficient for `capacityperconnectionunit conversions in the case that thecapacityperconnectionvalue is incompatible with the desiredconnectionflow` units.
For connection__tonode: Optional coefficient for `capacityperconnectionunit conversions in the case thecapacityperconnectionvalue is incompatible with the desiredconnectionflow` units.
For nodeto_unit, unittonode: Optional coefficient for `capacityperunitunit conversions in the case thecapacityperunitvalue is incompatible with the desiredunitflow` units.

Default value: 1.0

Related Entity Classes: connection__from_node, connection__to_node, node__to_unit and unit__to_node

For units, the capacity_to_flow_conversion_factor, as defined for a unit__to_node or node__to_unit, allows the user to align between unit_flow variables and the capacity_per_unit parameter, which may be expressed in different units. An example would be when the capacity_per_unit is expressed in GWh, while the demand on the node is expressed in MWh. In that case, a capacity_to_flow_conversion_factor parameter of 1000 would be applicable. The default of this parameter is 1, i.e. assuming that both are given in the same measurement unit.

Similarly for connections, the capacity_to_flow_conversion_factor can be used to perform the conversion between the measurement unit of the capacity_per_connection to the measurement unit of the connection_flow variable.

`coefficient_for_connection_flow`

For connectionfrom_nodeuser_constraint: Defines the user constraint coefficient on the connection flow variable in the from direction.
For connectionto_nodeuser_constraint: Defines the user constraint coefficient on the connection flow variable in the to direction.

Default value: nothing

Related Entity Classes: connection__from_node__user_constraint and connection__to_node__user_constraint

The coefficient_for_connection_flow 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, coefficient_for_connection_flow appears as a coefficient for the connection_flow variable from or to the node in the user constraint.

`coefficient_for_connections_invested`

Coefficient of connections_invested in the specific user_constraint

Default value: nothing

Related Entity Classes: connection__user_constraint

The coefficient_for_connections_invested 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, coefficient_for_connections_invested appears as a coefficient for the connections_invested variable in the user constraint.

`coefficient_for_connections_invested_available`

Coefficient of connections_invested_available in the specific user_constraint

Default value: nothing

Related Entity Classes: connection__user_constraint

The coefficient_for_connections_invested_available is an optional parameter that can be used to include the connections_invested_available variable in a user_constraint via the connection__user_constraint relationship. Essentially, coefficient_for_connections_invested_available appears as a coefficient for the connections_invested_available variable in the user constraint.

`coefficient_for_demand`

Coefficient of the specified node's demand in the specified user constraint.

Default value: nothing

Related Entity Classes: node__user_constraint

The coefficient_for_demand is an optional parameter that can be used to include the demand of a node in a user_constraint via the node__user_constraint relationship. Essentially, coefficient_for_demand appears as a coefficient for the demand parameter of the connected node in the user constraint.

`coefficient_for_node_state`

Coefficient of the specified node's state variable in the specified user constraint.

Default value: nothing

Related Entity Classes: node__user_constraint

The coefficient_for_node_state 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, coefficient_for_node_state appears as a coefficient for the node_state variable of the node in the user constraint.

`coefficient_for_storages_invested`

Coefficient of the specified node's storage investment variable in the specified user constraint.

Default value: nothing

Related Entity Classes: node__user_constraint

The coefficient_for_storages_invested 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, coefficient_for_storages_invested appears as a coefficient for the storages_invested variable in the user constraint. For more information, see the [User Constraints Concept Reference][#User-Constraints]

`coefficient_for_storages_invested_available`

Coefficient of the specified node's storages invested available variable in the specified user constraint.

Default value: nothing

Related Entity Classes: node__user_constraint

The coefficient_for_storages_invested_available is an optional parameter that can be used to include the storages_invested_available variable in a user_constraint via the node__user_constraint relationship. Essentially, coefficient_for_storages_invested_available appears as a coefficient for the storages_invested_available variable in the user constraint. For more information, see the [User Constraints Concept Reference][#User-Constraints]

`coefficient_for_unit_flow`

Coefficient of a unit_flow variable for a custom user_constraint.

Default value: nothing

Related Entity Classes: unit_flow__user_constraint

The coefficient_for_unit_flow 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_flow__user_constraint relationship. Essentially, coefficient_for_unit_flow 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.

`coefficient_for_units_invested`

Coefficient of the units_invested variable in the specified user_constraint.

Default value: nothing

Related Entity Classes: unit__user_constraint

The coefficient_for_units_invested 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, coefficient_for_units_invested appears as a coefficient for the units_invested variable in the user constraint. For more information, see the [User Constraints Concept Reference][#User-Constraints]

`coefficient_for_units_invested_available`

Coefficient of the units_invested_available variable in the specified user_constraint.

Default value: nothing

Related Entity Classes: unit__user_constraint

The coefficient_for_units_invested_available is an optional parameter that can be used to include the units_invested_available variable in a user_constraint via the unit__user_constraint relationship. Essentially, coefficient_for_units_invested_available appears as a coefficient for the units_invested_available variable in the user constraint. For more information, see the [User Constraints Concept Reference][#User-Constraints]

`coefficient_for_units_on`

Coefficient of a units_on variable for a custom user_constraint.

Default value: nothing

Related Entity Classes: unit__user_constraint

The coefficient_for_units_on 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, coefficient_for_units_on appears as a coefficient for the units_on variable of the unit in the user constraint.

`coefficient_for_units_started_up`

Coefficient of a units_started_up variable for a custom user_constraint.

Default value: nothing

Related Entity Classes: unit__user_constraint

Effectively includes a term of the form

coefficient_for_units_started_up times units_started_up

for the desired unit into the user constraint.

`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

Related Entity Classes: connection__node__node

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_emergency_capacity`

For connection__from_node: Post contingency flow capacity of a connection. Sometimes referred to as emergency rating
For connection__to_node: The maximum post-contingency flow on a monitored connection.

Default value: nothing

Related Entity 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 (physics_type is set to [lodf_physics]).

If you set this value, make sure that you also set monitoring_active to true for the involved connection.

`connection_flow_cost`

Variable costs of a flow through a connection. E.g. EUR/MWh of energy throughput.

Default value: nothing

Related Entity 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_flows associated with the latter node in respect to the connection_flows associated with the first node.

Default value: Dict{String, Any}("data" => "0h", "type" => "duration")

Supported parameter value types: duration

Related Entity Classes: connection__node__node

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_highest_resolution_active`

Whether to use highest resolution for constraint ratio out in connection flow.

Default value: true

Uses Parameter Value Lists: boolean_value_list

Supported parameter value types: bool

Related Entity Classes: model

Affects the temporal resolution of the connection flow ratio constraints. When set to true, imposes a strict "power equality" on the flows, so that the powers between the input and output connection_flows match exactly for each time step. When set to false, the constraint relaxes to an "energy equality", only matching the delivered energy over the coarser time steps. Effectively, the higher resolution connection_flow is allowed to vary its instantaneous "power", as long as the "delivered energy" obeys the ratio.

`connection_flow_non_anticipativity_margin`

Margin by which connection_flow variable can differ from the value in the previous window during non_anticipativity_time.

Default value: nothing

Related Entity Classes: connection__from_node and connection__to_node

Used to constrain the upper and lower bounds of the connection_flow variables based on the values in the previous solve in a rolling problem (see Rolling horizon tutorial), up to connection_flow_non_anticipativity_time. Effectively, if connection_flow is within connection_flow_non_anticipativity_time of the start of the current window, its values are constrained to its previous values plus/minus connection_flow_non_anticipativity_margin.

`connection_flow_non_anticipativity_time`

Period of time where the value of the connection_flow variable has to be fixed to the result from the previous window.

Default value: nothing

Supported parameter value types: duration

Related Entity Classes: connection__from_node and connection__to_node

Defines the duration from the start of the current window of a rolling problem (see Rolling horizon tutorial) during which the connection_flow variables obey the connection_flow_non_anticipativity_margin.

`connection_intact_flow_non_anticipativity_margin`

Margin by which connection_intact_flow variable can differ from the value in the previous window during non_anticipativity_time.

Default value: nothing

Related Entity Classes: connection__from_node and connection__to_node

Used to constrain the upper and lower bounds of the connection_intact_flow variables based on the values in the previous solve in a rolling problem (see Rolling horizon tutorial), up to connection_intact_flow_non_anticipativity_time. Effectively, if connection_intact_flow is within connection_intact_flow_non_anticipativity_time of the start of the current window, its values are constrained to its previous values plus/minus connection_intact_flow_non_anticipativity_margin.

`connection_intact_flow_non_anticipativity_time`

Period of time where the value of the connection_intact_flow variable has to be fixed to the result from the previous window.

Default value: nothing

Supported parameter value types: duration

Related Entity Classes: connection__from_node and connection__to_node

Defines the duration from the start of the current window of a rolling problem (see Rolling horizon tutorial) during which the connection_intact_flow variables obey the connection_intact_flow_non_anticipativity_margin.

`connection_investment_cost`

Investment cost per 'sub connection' over the lifetime_technical. E.g. EUR/'sub connection'.

Default value: nothing

Related Entity 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_power_flow_impact_active`

Whether to use connection_intact_flow variables, to capture the impact of connection investments on network characteristics via line outage distribution factors (LODF).

Default value: true

Uses Parameter Value Lists: boolean_value_list

Supported parameter value types: bool

Related Entity Classes: model

TODO: IMPROVE THIS EXPLANATION!

See Lossless nodal DC power flows and PTDF-Based Powerflow.

`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

Related Entity Classes: connection__node__node

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_min_factor`

Minimum availability of the connection

Default value: 0.0

Related Entity Classes: connection

Acts as a multiplier on its [capacity_per_connection], typically set between 0-1. Affects the connection minimum flow constraint.

`connection_type`

A selector between a normal and a lossless bidirectional connection.

Default value: connection_type_normal

Uses Parameter Value Lists: connection_type_list

Supported parameter value types: str

Related Entity 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: capacity_per_connection (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 capacity_per_connection parameter found is copied to connection__from_nodes and connection__to_nodes without a defined capacity_per_connection.

`constraint_sense`

A selector for the sense of the user_constraint.

Default value: ==

Uses Parameter Value Lists: constraint_sense_list

Supported parameter value types: str

Related Entity Classes: user_constraint

The constraint_sense parameter determines the sense of a custom user constraint.

See User constraints for details.

`contingency_active`

A boolean flag for defining a contingency connection.

Default value: nothing

Uses Parameter Value Lists: boolean_value_list

Supported parameter value types: bool

Related Entity 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 physics_type to lodf_physics, an N-1 security constraint is created for each monitored line (monitoring_active = true) for each specified contingency (contingency_active = true).

`curtailment_cost`

Costs for curtailing generation. Essentially, accrues costs whenever unit_flow not operating at its maximum available capacity. E.g. EUR/MWh

Default value: nothing

Related Entity 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_state at 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

Uses Parameter Value Lists: boolean_value_list

Supported parameter value types: bool

Related Entity 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 storage_active parameter of the corresponding 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: >=

Uses Parameter Value Lists: constraint_sense_list

Supported parameter value types: str

Related Entity Classes: node__temporal_block

Sets the sense for the cyclic node state constraint. The default value of >= forces the node_state variable to end up at a value higher than where it started from.

`decommissioning_cost`

To be implemented. Costs associated with decommissioning a connection. The costs will be distributed equally over the decommissioning_time and discounted to the discount_year.

Default value: nothing

Related Entity Classes: connection

Warning

TODO: IS THIS IMPLEMENTED?

`decommissioning_time`

For connection: The decommissioning time of the connection, i.e., the time between the moment at which a connection decommissioning decision is taken, and the moment at which decommissioning is complete.
For unit: The decommissioning time of the unit, i.e., the time between the moment at which a unit decommissioning decision is taken, and the moment at which decommissioning is complete.

Default value: Dict{String, Any}("data" => "0h", "type" => "duration")

Supported parameter value types: duration

Related Entity Classes: connection and unit

Warning

TODO: IS THIS IMPLEMENTED?

`decomposition_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 Entity 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 decomposition_max_gap the benders algorithm will terminate having achieved satisfactory optimality.

`decomposition_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 Entity Classes: model

The parameter decomposition_max_iterations determines the maximum number of Benders iterations for a model of type :spineopt_benders_master.

`decomposition_min_iterations`

Specifies the minimum number of iterations for the model

Default value: 1.0

Related Entity Classes: model

Warning

EXPERIMENTAL

Currently only used for the master problem within a decomposed structure.

See Decomposition.

`demand`

Demand for the commodity of a node. Energy gains can be represented using negative demand.

Default value: 0.0

Related Entity 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 demand_fraction 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 coefficient_for_demand parameter for the node__user_constraint relationship.

`demand_fraction`

The fraction of a node group's demand applied for the node in question.

Default value: 0.0

Related Entity Classes: node

Whenever a node is a member of a group, the demand_fraction parameter represents its share of the group's demand.

`diffusion_coefficient`

Commodity diffusion coefficient between two nodes. Effectively, denotes the diffusion power per unit of state from the first node to the second.

Default value: 0.0

Related Entity Classes: node__node

The diffusion_coefficient 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 diffusion_coefficient is interpreted as one-directional, meaning that if one defines

diffusion_coefficient(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 diffusion_coefficient both ways

diffusion_coefficient(node1=n1, node2=n2) == diffusion_coefficient(node1=n2, node2=n1).

`discount_rate`

The discount rate used for the discounting of future cashflows

Default value: 0

Related Entity Classes: model

TODO: IMPROVE THIS EXPLANATION!

`discount_rate_technology_specific`

For connection: Connection-specific discount rate for calculating the investment costs of the connection.
For unit: Unit-specific discount rate for calculating the investment costs of the unit. If not specified, the model discount rate is used.

Default value: 0.0

Related Entity Classes: connection and unit

Optional technology-specific discount rate. If not specified, the model default discount_rate is used.

See Multi-year investments.

`discount_year`

The year to which all cashflows are discounted.

Default value: nothing

Supported parameter value types: date_time, duration

Related Entity Classes: model

Can be given either as a DateTime for a static point, or as a Duration relative to the model_start.

See Multi-year investments.

`duration_unit`

Defines the base temporal unit of the model. Currently supported values are either an hour or a minute.

Default value: hour

Uses Parameter Value Lists: duration_unit_list

Supported parameter value types: str

Related Entity 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_active`

Whether all entities in the group must have the same investment decision.

Default value: false

Uses Parameter Value Lists: boolean_value_list

Supported parameter value types: bool

Related Entity Classes: investment_group

Effectively imposes the equal group investment constraint on the investment_group, forcing all investment decisions inside the group to match.

`existing_connections`

The number of 'sub connections' aggregated to form the modelled connection.

Default value: 1.0

Related Entity Classes: connection

Effectively represents pre-existing connections prior to investments (if any). The default value becomes zero when investments are enabled through the investment_count_max_cumulative parameter.

`existing_storages`

The number of 'sub storages' aggregated to form the modelled node.

Default value: 1.0

Related Entity Classes: node

Effectively represents pre-existing nodes with storage_active prior to investments (if any). The default value becomes zero when investments are enabled through the storage_investment_count_max_cumulative parameter.

`existing_units`

The number of 'sub units' aggregated to form the modelled unit. The default value becomes zero if investment_count_max_cumulative has been defined.

Default value: 1.0

Related Entity 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 availability_factor and out_of_service_count_fix, 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 existing_units itself, through Investment Optimization. It is also possible to schedule maintenance outages using outage_variable_type and outage_scheduled_duration.

The default value for this parameter is 1. The default value is 0 when investment_count_max_cumulative has been defined for the unit in question.

`fix_nonspin_units_shut_down`

Fix the nonspin_units_shut_down variable.

Default value: nothing

Related Entity 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_up variable.

Default value: nothing

Related Entity Classes: node__to_unit 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.

`fix_ratio_out_in_connection_flow`

Fix the ratio between an outgoing connection_flow to the first node and an incoming connection_flow from the second node.

Default value: nothing

Related Entity Classes: connection__node__node

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.

`fixed_annual_cost`

Fixed annual operation and maintenance costs of the connection.

Default value: nothing

Related Entity Classes: connection

Essentially, a cost coefficient on the number of installed connections and capacity_per_connection parameters. E.g. in EUR/MWh/a.

See fom_cost for units, which is pending changes.

`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

Related Entity Classes: connection__node__node

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

Related Entity Classes: connection__node__node

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.

`flow_limits_fix`

For connectionfrom_node, connectiontonode: Fix the value of the `connectionflow` variable.
For nodeto_unit, unittonode: Fix the values of the `unitflow` variable.

Default value: nothing

Related Entity Classes: connection__from_node, connection__to_node, node__to_unit and unit__to_node

The flow_limits_fix parameter fixes the value of the unit_flow or connection_flow variable.

For units, If operating_points is defined on a certain unit__to_node or node__to_unit 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. flow_limits_fix_op can thus be used to fix the value of one or more of the variables as desired.

Warning: that this parameter should be set to 0 for history timeslices to avoid free energy in the model when using the connection_flow_delay parameter.

`flow_limits_fix_intact`

Fix the value of the connection_intact_flow variable.

Default value: nothing

Related Entity Classes: connection__from_node and connection__to_node

The flow_limits_fix_intact 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.

`flow_limits_fix_op`

Fix the values of the unit_flow_op variable, essentially fixing the flows per operating point.

Default value: nothing

Related Entity Classes: node__to_unit and unit__to_node

The flow_limits_fix 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 flow_limits_fix parameter values.

Other uses can include e.g. a constant or time-varying exogenous commodity flow from or to a unit.

`flow_limits_initial`

For connectionfrom_node, connectiontonode: Set the initial value for the `connectionflow` variable.
For nodeto_unit, unittonode: Set the initial value for the `unitflow` variable.

Default value: nothing

Related Entity Classes: connection__from_node, connection__to_node, node__to_unit and unit__to_node

Sets the initial values for the unit_flow and connection_flow variables, i.e. their values prior to model_start.

`flow_limits_initial_intact`

Set the initial value for the connection_intact_flow variable.

Default value: nothing

Related Entity Classes: connection__from_node and connection__to_node

Sets the initial values for the connection_intact_flow variables, i.e. their values prior to model_start.

`flow_limits_initial_op`

Set the initial value for the unit_flow_op variable, essentially fixing the initial flow per operating point.

Default value: nothing

Related Entity Classes: node__to_unit and unit__to_node

Sets the initial values for the unit_flow_op variables, i.e. their values prior to model_start.

`flow_limits_max_cumulative`

For node__to_unit: Bound on the maximum cumulated flows of a unit group from a node group e.g max consumption of certain commodity.
For unit__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 Entity Classes: node__to_unit and unit__to_node

The definition of the flow_limits_max_cumulative 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 node__to_unit and 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. Possible use cases are limiting CO2 emissions, or 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.

`flow_limits_min`

Set lower bound of the unit_flow variable.

Default value: 0.0

Related Entity Classes: node__to_unit and unit__to_node

Sets and absolute lower bound for unit_flow variables. For capacity-dependent lower bounds, see minimum_operating_point.

`flow_limits_min_cumulative`

For node__to_unit: Bound on the minimum cumulated flows of a unit group from a node group.
For unit__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 Entity Classes: node__to_unit and unit__to_node

The definition of the flow_limits_min_cumulative 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 and node__to_unit 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.

`flow_ratio_equality_coefficient`

Coefficient defining the ratio between two unit_flows for a strict equality like uf1/uf2=X. Triggers flow ratio equality constraint generation.

Default value: nothing

Related Entity Classes: unit_flow__unit_flow

Triggers flow ratio constraint generation of the form flow1 == ratio * flow2. Additional terms can be included through flow_ratio_equality_online_coefficient for units_on variables, and flow_ratio_start_flow for units_started_up variables.

`flow_ratio_equality_online_coefficient`

Optional coefficient for the units_on variable impacting the flow_ratio_equality_coefficient constraint.

Default value: 0.0

Related Entity Classes: unit_flow__unit_flow

Adds a term to the right-hand side of the unit flow ratio constraint, multiplying the units_on variable with this coefficient. Only applies to the "equality" variant.

`flow_ratio_greater_than_coefficient`

Coefficient defining the ratio between two unit_flows for an inequality like uf1/uf2>=X. Triggers flow ratio inequality constraint generation.

Default value: nothing

Related Entity Classes: unit_flow__unit_flow

Triggers flow ratio constraint generation of the form flow1 >= ratio * flow2. Additional terms can be included through flow_ratio_greater_than_online_coefficient for units_on variables, and flow_ratio_start_flow for units_started_up variables.

`flow_ratio_greater_than_online_coefficient`

Optional coefficient for the units_on variable impacting the flow_ratio_greater_than_coefficient constraint.

Default value: 0.0

Related Entity Classes: unit_flow__unit_flow

Adds a term to the right-hand side of the unit flow ratio constraint, multiplying the units_on variable with this coefficient. Only applies to the "greater than" variant.

`flow_ratio_less_than_coefficient`

Coefficient defining the ratio between two unit_flows for an inequality like uf1/uf2<=X.

Default value: nothing

Related Entity Classes: unit_flow__unit_flow

Triggers flow ratio constraint generation of the form flow1 <= ratio * flow2. Additional terms can be included through flow_ratio_less_than_online_coefficient for units_on variables, and flow_ratio_start_flow for units_started_up variables.

`flow_ratio_less_than_online_coefficient`

Optional coefficient for the units_on variable impacting the flow_ratio_less_than_coefficient constraint.

Default value: 0.0

Related Entity Classes: unit_flow__unit_flow

Adds a term to the right-hand side of the unit flow ratio constraint, multiplying the units_on variable with this coefficient. Only applies to the "less than" variant.

`flow_ratio_start_flow`

Enforces additional flow for the first unit_flow based on the units_started_up.

Default value: 0.0

Related Entity Classes: unit_flow__unit_flow

Adds a term to the right-hand side of unit flow ratio constraint, multiplying the units_started_up variable with the flow_ratio_start_flow.

`fom_cost`

Fixed operation and maintenance costs of a unit. Essentially, a cost coefficient on the existing units (incl. existing_units and units_invested_available) and capacity_per_unit parameters. Currently, the value needs to be defined per duration unit (i.e. 1 hour). E.g. EUR/MW/h.

Default value: nothing

Related Entity 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.

`fuel_cost`

Variable fuel costs than can be attributed to a unit_flow. E.g. EUR/MWh

Default value: nothing

Related Entity Classes: node__to_unit 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.

`has_free_start`

Whether the block requires a fresh start (own independent history)

Default value: false

Uses Parameter Value Lists: boolean_value_list

Related Entity Classes: temporal_block

temporal_blocks with true generate their own independent history, meaning that any prior time slices do not affect their variables. The main use of this feature is to allow certain temporal_blocks to neglect time steps prior to their starting, thus permitting them the titular "free start".

`initial_nonspin_units_shut_down`

Initialize the nonspin_units_shut_down variable.

Default value: nothing

Related Entity Classes: unit__to_node

Set the initial value for the nonspin_units_shut_down variable, i.e. its value prior to model_start.

`initial_nonspin_units_started_up`

Initialize the nonspin_units_started_up variable.

Default value: nothing

Related Entity Classes: node__to_unit and unit__to_node

Set the initial value for the nonspin_units_started_up variable, i.e. its value prior to model_start.

`investment_capacity_total_max_cumulative`

Upper bound on the capacity invested available in the group at any point in time.

Default value: nothing

Related Entity Classes: investment_group

Sets an upper bound over the total capacity investments over the investment_group, triggering the group maximum invested capacity constraint.

`investment_capacity_total_min_cumulative`

Lower bound on the capacity invested available in the group at any point in time.

Default value: nothing

Related Entity Classes: investment_group

Sets a lower bound over the total capacity investments over the investment_group, triggering the group minimum invested capacity constraint.

`investment_count_fix_cumulative`

For connection: Fixes the cumulative number of new connection investments, i.e., the connections_invested_available variable, to the provided value.
For unit: Fixes the cumulative number of new unit investments, i.e., the units_invested_available variable, to the provided value.

Default value: nothing

Related Entity Classes: connection and unit

Connection: The investment_count_fix_cumulative parameter represents a forced connection investment. In other words, it is the fix value of the connections_invested_available variable.

Unit: The investment_count_fix_cumulative parameter is 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.

`investment_count_fix_new`

For connection: Fixes the number of new connection investments, i.e., the connections_invested variable, to the provided value.
For unit: Fixes the number of new unit investments, i.e., the units_invested variable, to the provided value.

Default value: nothing

Related Entity Classes: connection and unit

Connection: The investment_count_fix_new 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.

Unit: The investment_count_fix_new parameter is 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.

`investment_count_initial_cumulative`

For connection: Initializes the cumulative number of new connection investments, i.e., the connections_invested_available variable, to the provided value.
For unit: Initializes the cumulative number of new unit investments, i.e., the units_invested_available variable, to the provided value.

Default value: nothing

Related Entity Classes: connection and unit

Sets the initial value for the units_invested_available or connections_invested_available variables, i.e. their values prior to model_start.

`investment_count_initial_new`

For connection: Initializes the number of new connection investments, i.e., the connections_invested variable, to the provided value.
For unit: Initializes the number of new unit investments, i.e., the units_invested variable, to the provided value.

Default value: nothing

Related Entity Classes: connection and unit

Sets the initial value for the units_invested or connections_invested variables, i.e. its value prior to model_start.

`investment_count_max_cumulative`

For connection: Maximum cumulative number of new connections that may be invested in.
For unit: Maximum cumulative number of new units which may be invested in.

Default value: nothing

Related Entity Classes: connection and unit

Connection: The investment_count_max_cumulative 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 capacity_per_connection. In other words, investment_count_max_cumulative is the upper bound of the connections_invested_available variable.

Unit: Within an investments problem investment_count_max_cumulative determines the upper bound on the unit investment decision variable in constraint units_invested_available. In the unit flow capacity constraint the maximum unit_flow will be the product of the units_invested_available and the corresponding capacity_per_unit. Thus, the interpretation of investment_count_max_cumulative depends on investment_variable_type which determines the unit investment decision variable type. If investment_variable_type is integer or binary, then investment_count_max_cumulative represents the maximum number of discrete units that may be invested in. If investment_variable_type is linear, investment_count_max_cumulative is more analogous to a maximum storage capacity. Note that investment_count_max_cumulative 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.

`investment_count_total_max_cumulative`

Upper bound on the number of entities invested available in the group at any point in time.

Default value: nothing

Related Entity Classes: investment_group

Enforces a maximum number of investments in the investment_group, triggering the maximum investments in a group constraint.

`investment_count_total_min_cumulative`

Lower bound on the number of entities invested available in the group at any point in time.

Default value: nothing

Related Entity Classes: investment_group

Enforces a minimum number of investments in the investment_group, triggering the minimum investments in a group constraint.

`investment_variable_type`

For connection: A selector for the type of the connection investment variable (connections_invested): whether it is continuous (usually representing invested capacity) or integer (representing discrete 'sub connection' investments).
For unit: A selector for the type of the unit investment variable (units_invested): whether it is continuous (usually representing invested capacity), integer (representing discrete 'sub unit' investments), binary (0 or 1 'sub unit' investments) or none (no investments).

Default value: linear

Uses Parameter Value Lists: variable_type_list

Supported parameter value types: str

Related Entity Classes: connection and unit

Defines the type of the variables used for investment decisions. Setting investment_variable_type = none can be used to disable investments regardless of investment_count_max_cumulative. See the following for more details for connections and units, respectively.

Connection: The investment_variable_type parameter represents the type of the connections_invested_available decision variable. The default value, linear, means that any arbitrary fraction of capacity_per_connection can be invested in. Meanwhile, integer and binary limit these according to their names, respectively.

Unit: Within an investment problem 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 capacity_per_unit for each unit_flow and since investment_count_max_cumulative represents the upper bound of the investment decision variable, investment_variable_type thus determines what the investment decision represents. If investment_variable_type is integer or binary, then investment_count_max_cumulative represents the maximum number of discrete units that may be invested. If investment_variable_type is linear (default), investment_count_max_cumulative is more analogous to a capacity with capacity_per_unit being analogous to a scaling parameter.

For example, if investment_variable_type = integer, investment_count_max_cumulative = 4 and capacity_per_unit for a particular unit_flow = 400 MW, then the investment decision is how many 400 MW units to build. If investment_variable_type = linear, investment_count_max_cumulative = 400 and capacity_per_unit for a particular unit_flow = 1 MW, then the investment decision is how much capacity if this particular unit to build. Finally, if investment_variable_type = integer, investment_count_max_cumulative = 10 and capacity_per_unit for a particular unit_flow = 50 MW, then the investment decision is many 50MW blocks of capacity of this particular unit to build.

`is_non_spinning`

A boolean flag for whether a node is acting as a non-spinning reserve.

Default value: false

Uses Parameter Value Lists: boolean_value_list

Supported parameter value types: bool

Related Entity 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 reserve_active 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`

A boolean flag for whether the unit is renewable - used in the minimum renewable generation constraint within the Benders master problem.

Default value: false

Uses Parameter Value Lists: boolean_value_list

Supported parameter value types: bool

Related Entity 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.

`lead_time`

For connection: The lead time of the connection, i.e., the time between the moment at which a connection investment decision is taken, and the moment at which the connection investment becomes operational.
For unit: The lead time of the unit, i.e., the time between the moment at which a unit investment decision is taken, and the moment at which the unit investment becomes operational.

Default value: Dict{String, Any}("data" => "0h", "type" => "duration")

Supported parameter value types: duration

Related Entity Classes: connection and unit

TODO

`lifetime_constraint_sense`

For connection: A selector for connection_lifetime constraint sense.
For unit: A selector for unit_lifetime constraint sense.

Default value: >=

Uses Parameter Value Lists: constraint_sense_list

Supported parameter value types: str

Related Entity Classes: connection and unit

Defines the sense of the unit lifetime and connection lifetime constraints. The default >= represents minimum technical lifetime.

`lifetime_economic`

Economic lifetime of investments, i.e. the duration for investment cost payment.

Default value: nothing

Supported parameter value types: duration

Related Entity Classes: connection and unit

Economic lifetime of unit and connection investments, affecting their investment costs through discounting.

`lifetime_technical`

For connection: Technical lifetime for connection investments. Represents minimum technical lifetime by default, but the interpretation can be changed via lifetime_constraint_sense.
For unit: Technical lifetime for unit investments. Represents minimum technical lifetime by default, but the interpretation can be changed via lifetime_constraint_sense.

Default value: nothing

Supported parameter value types: duration

Related Entity Classes: connection and unit

Connection: Duration parameter that determines the minimum duration of connection investment decisions. Once a connection has been invested-in, it must remain invested-in for lifetime_technical.

Unit: Duration parameter that determines the minimum duration of unit investment decisions. Once a unit has been invested-in, it must remain invested-in for lifetime_technical.

Note that lifetime_technical is a dynamic parameter that will impact the amount of solution history that must remain available to the optimisation in each step - this may impact performance.

`lodf_tolerance`

The minimum absolute value of the line outage distribution factor (LODF) that is considered meaningful.

Default value: 0.1

Related Entity Classes: grid

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. 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 contingency_active to true; to study the impact of such contingencies on another connection, set monitoring_active to true.

In addition, define a grid with physics_type set to lodf_physics, and associate that grid (via node__grid) to both connections' nodes (given by connection__to_node and connection__from_node).

`max_ratio_out_in_connection_flow`

Maximum ratio between an outgoing connection_flow to the first node and an incoming connection_flow from the second node.

Default value: nothing

Related Entity Classes: connection__node__node

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 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.

`mga_investment_active`

For connection: A boolean flag for whether a certain variable (here: connections_invested) will be considered in the maximal-differences of the MGA objective.
For unit: A boolean flag for whether a certain variable (here: units_invested) will be considered in the maximal-differences of the MGA objective.

Default value: false

Uses Parameter Value Lists: boolean_value_list

Supported parameter value types: bool

Related Entity Classes: connection and unit

The mga_investment_active is a boolean parameter that can be used in combination with the MGA algorithm (see mga-advanced).

Connection: As soon as the value of mga_investment_active is set to true, investment decisions in this connection, or group of connections, will be included in the MGA algorithm.

Unit: As soon as the value of mga_investment_active is set to true, investment decisions in this unit, or group of units, will be included in the MGA algorithm.

`mga_investment_big_m`

Upper bound on the maximum difference between any MGA iteration. Should be chosen as small as possible but sufficiently large. For mgainvestmentactive an appropriate mga_investment_big_m would be twice the investment_count_max_cumulative.

Default value: nothing

Related Entity Classes: connection and unit

The mga_investment_big_m 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 investment_count_max_cumulative could suffice.)

`mga_investment_weight`

Weight for scaling the MGA variables.

Default value: 1

Related Entity Classes: connection and unit

For weighted-sum MGA method, the length of this weight given as an Array will determine the number of iterations.

See Modelling to generate alternatives.

`mga_max_iterations`

Define the number of mga iterations, i.e. how many alternative solutions will be generated.

Default value: nothing

Related Entity Classes: model

In the MGA algorithm the original problem is re-optimized (see also mga-advanced), and finds near-optimal solutions. The parameter mga_max_iterations defines how many MGA iterations will be performed, i.e. how many near-optimal solutions will be generated.

`mga_max_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 Entity Classes: model

In the MGA algorithm the original problem is re-optimized (see also mga-advanced), and finds near-optimal solutions. The parameter mga_max_slack defines how far from the optimum the new solutions can maximally be (e.g. a value of 0.05 would allow for a 5% increase of the original objective value).

`mga_storage_investment_active`

A boolean flag for whether a certain variable (here: storages_invested) will be considered in the maximal-differences of the MGA objective.

Default value: false

Uses Parameter Value Lists: boolean_value_list

Supported parameter value types: bool

Related Entity Classes: node

The mga_storage_investment_active is a boolean parameter that can be used in combination with the MGA algorithm (see mga-advanced). As soon as the value of mga_storage_investment_active is set to true, investment decisions in this connection, or group of storages, will be included in the MGA algorithm.

`mga_storage_investment_big_m`

Upper bound on the maximum difference between any MGA iteration. Should be chosen as small as possible but sufficiently large. For mgastorageinvestmentactive an appropriate `mgastorageinvestmentbigmwould be twice thestorageinvestmentcountmax_cumulative`.

Default value: nothing

Related Entity Classes: node

The mga_storage_investment_big_m 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 storage_investment_count_max_cumulative could suffice.)

`mga_storage_investment_weight`

Weight for scaling the Modelling to Generate Alternatives (MGA) variables.

Default value: 1

Related Entity Classes: node

For weighted-sum MGA method, the length of this weight given as an Array will determine the number of iterations.

See Modelling to generate alternatives.

`min_down_time`

Minimum downtime of a unit after it shuts down.

Default value: nothing

Supported parameter value types: duration

Related Entity Classes: unit

The definition of the min_down_time parameter will trigger the creation of the Constraint on minimum downtime. 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 commitment restrictions, see Unit commitment.

`min_ratio_out_in_connection_flow`

Minimum ratio between an outgoing connection_flow to the first node and an incoming connection_flow from the second node.

Default value: nothing

Related Entity Classes: connection__node__node

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 commodity2, the min_ratio_out_in_connection_flow parameter would be set to 0.8 for the relationship conn__commodity1__commodity2.

`min_up_time`

Minimum uptime of a unit after it starts up.

Default value: nothing

Supported parameter value types: duration

Related Entity Classes: unit

The definition of the min_up_time parameter will trigger the creation of the Constraint on minimum uptime. It sets a lower bound on the period that a unit has to stay online after a startup.

For a more complete description of unit commitment restrictions, see Unit commitment.

`minimum_operating_point`

Minimum level for the unit_flow relative to the units_on online capacity.

Default value: nothing

Related Entity Classes: node__to_unit 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 node__to_unit 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 capacity_per_unit 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

Supported parameter value types: duration

Related Entity 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 reserve_active) 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

Uses Parameter Value Lists: model_algorithm_list

Supported parameter value types: str

Related Entity Classes: model

Select the algorithm to be run from the model_algorithm_list.

See the Algorithms chapter for descriptions of (some of) the supported ones. E.g. Decomposition, Modelling to generate alternatives, and Multi-stage optimisation.

`model_end`

Defines the last timestamp to be modelled, either as a static date-time or a duration relative to model_start. Rolling optimization terminates after passing this point.

Default value: Dict{String, Any}("data" => "2000-01-02T00:00:00", "type" => "date_time")

Supported parameter value types: date_time, duration

Related Entity 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_blocks refer to this value for their start and end.

Default value: Dict{String, Any}("data" => "2000-01-01T00:00:00", "type" => "date_time")

Supported parameter value types: date_time

Related Entity 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

Uses Parameter Value Lists: model_type_list

Supported parameter value types: str

Related Entity 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 the Decomposition section.

spineopt_mga uses the Model to Generate Alternatives algorithm.

`monitoring_active`

A boolean flag for activating monitoring of a connection in PTDF-based load flow.

Default value: false

Uses Parameter Value Lists: boolean_value_list

Supported parameter value types: bool

Related Entity Classes: connection

When using ptdf-based load flow by setting physics_type to either ptdf_physics or ptdf_physics, a constraint is created for each connection for which monitoring_active = true. Thus, to monitor the ptdf-based flow on a particular connection monitoring_active must be set to true.

`monte_carlo_scenarios`

A map from scenario key, to array of scenario values

Default value: nothing

Related Entity Classes: model

TODO

See model_algorithm.

`mp_min_res_gen_to_demand_ratio`

Minimum ratio of renewable generation to demand for this grid - used in the minimum renewable generation constraint within the Benders master problem

Default value: nothing

Related Entity Classes: grid

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 Entity Classes: grid

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.

`multiyear_economic_discounting`

If set, the model automatically calculates the discounting effect of given costs for multi-year investments under either consecutive_years or milestone_years mode.

Default value: nothing

Uses Parameter Value Lists: multiyear_economic_discounting_value_list

Related Entity Classes: model

Selects multi-year economic discounting method from multiyear_economic_discounting_value_list.

See Multi-year investments.

`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

Uses Parameter Value Lists: node_opf_type_list

Supported parameter value types: str

Related Entity Classes: node

Used to identify the reference node (or slack bus) when ptdf based dc load flow is enabled (physics_type set to ptdf_physics or lodf_physics. To identify the reference node, set node_opf_type = :node_opf_type_reference

`online_count_fix`

Fixes the units_on variable to the provided value.

Default value: nothing

Related Entity Classes: unit

The online_count_fix 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.

`online_count_initial`

Initializes the units_on variable to the provided value.

Default value: nothing

Related Entity Classes: unit

Set the initial value of the units_on_ variable, i.e. its value prior to model_start.

`online_variable_type`

A selector for how the units_on variable is represented within the model.

Default value: linear

Uses Parameter Value Lists: variable_type_list

Supported parameter value types: str

Related Entity 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 "binary", "integer", "linear" and "none".

If binary, then the commitment is modelled as an online/offline decision (classic unit commitment).

If integer, then the commitment is modelled as the number of units that are online (clustered unit commitment).

If 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 integer. Note that linear is a special case for which online variables are omitted if they are deemed unnecessary by the preprocessing.

If 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 node__to_unit: Operating points for piecewise-linear unit efficiency approximations.
For unit__tonode: Decomposes the flow variable into a number of separate operating segment variables. Used to in conjunction with `unitincrementalheatrateand/oruser_constraint`s

Default value: nothing

Supported parameter value types: array

Related Entity Classes: node__to_unit and unit__to_node

If operating_points is defined as an array type on a certain unit__to_node or node__to_unit flow, the corresponding unit_flow variable is decomposed into a number of sub-operating segment unit_flow_op variables, 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 capacity_per_unit for the corresponding unit__to_node or node__to_unit flow. operating_points is used in conjunction with flow_ratio_equality_coefficient 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 coefficient_for_unit_flow. Here operating_points is used also to define the normalized operating point bounds for the corresponding coefficient_for_unit_flows.

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 capacity_per_unit and a second from 50% to 100% of the corresponding capacity_per_unit.

`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

Uses Parameter Value Lists: boolean_value_list

Supported parameter value types: bool

Related Entity Classes: node__to_unit and unit__to_node

If one defines the parameter ordered_unit_flow_op in a node__to_unit 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.

`out_of_service_count_fix`

Fixes the units_out_of_service variable to the provided value.

Default value: nothing

Related Entity 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 availability_factor, and existing_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 outage_scheduled_duration.

`out_of_service_count_initial`

Initializes the units_out_of_service variable to the provided value.

Default value: nothing

Related Entity Classes: unit

Set the initial value for the units_out_of_service variable, i.e. its value prior to model_start.

`outage_scheduled_duration`

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 Entity Classes: unit

The definition of the outage_scheduled_duration duration parameter will trigger the creation of the Constraint on minimum uptime. It sets a lower bound on the sum of the units_out_of_service variable over the optimisation window. The primary function of this parameter is thus, to schedule maintenance outages for units. This parameter enforces that the unit must be taken out of service for at least an amount of time equal to outage_scheduled_duration

It can be defined for a unit and will then impose restrictions on the units_out_of_service variables that represent whether a unit is on maintenance outage at that particular time. 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.

To scheduled maintenance outages using this functionality, one must activate the units_out_of_service variable. This is done by changing the value of the outage_variable_type to either integer (for clustered units) or binary for binary units or linear for continuous units. Setting outage_variable_type to none will deactivate the units_out_of_service variable and this is the default value.

`outage_variable_type`

A selector for whether the outage variable (units_out_of_service) is integer or continuous or none. None means no optimisation of maintenance outages.

Default value: none

Uses Parameter Value Lists: variable_type_list

Supported parameter value types: str

Related Entity 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 integer (for clustered units) or binary for binary units or linear for continuous units. Setting outage_variable_type to 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

Supported parameter value types: str

Related Entity 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 this output.
For stageoutput, stageoutputconnection, stageoutputnode, stageoutput__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

Supported parameter value types: duration, array

Related Entity Classes: output, 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

Uses Parameter Value Lists: output_type_list

Supported parameter value types: str

Related Entity Classes: output

Parameter separating different outputs by type. Presumably useful for post-processing? Not used inside SpineOpt.

`overwrite_results_on_rolling`

Whether or not results from further windows should overwrite results from previous ones.

Default value: true

Uses Parameter Value Lists: boolean_value_list

Supported parameter value types: bool

Related Entity 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.

`physics_duration`

For how long the physics_type (currently only for PTDF and LODF) should apply relative to the start of the window.

Default value: nothing

Supported parameter value types: duration

Related Entity Classes: grid

This parameter determines the duration, relative to the start of the optimisation window, over which the physics determined by physics_type 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 physics_duration to a shorter value to reduce problem size and increase performace.

This parameter is currently only used with ptdf_physics and lodf_physics.

`physics_type`

Defines if the grid follows lodf, ptdf, or other types of special physics.

Default value: none

Uses Parameter Value Lists: grid_physics_list

Supported parameter value types: str

Related Entity Classes: grid

This parameter determines the specific formulation used to carry out flow calculations within a model.

To enable power transfer distribution factor (ptdf) based dc load flow for a network of nodes and connections, all nodes must be related to a grid with physics_type set to ptdf_physics. To enable security constraint unit comment based on ptdfs and line outage distribution factors (lodf) all nodes must be related to a grid with physics_type set to lodf_physics. See also powerflow.

To enable 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, all nodes must be related to a grid with physics_type set to voltage_angle_physics. The voltage angle at a certain node can also be constrained through the parameters voltage_angle_max and voltage_angle_min. More details on the use of lossless nodal DC power flows are described here.

To enable pressure driven gas network calculations, all nodes must be related to a grid with physics_type set to pressure_physics, in order to trigger the generation of the node_pressure variable. The pressure at a certain node can also be constrainted through the parameters pressure_max and pressure_min. More details on the use of pressure driven gas transfer are described here.

`pressure_fix`

Fixes the node_pressure variable to the provided value.

Default value: nothing

Related Entity 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 pressure_fix parameter can be used.

`pressure_initial`

Initializes the node_pressure variable to the provided value

Default value: nothing

Related Entity Classes: node

Set the initial value for the node_pressure variable, i.e. the value prior to model_start.

`pressure_max`

Maximum allowed gas pressure at node.

Default value: nothing

Related Entity Classes: node

If a node has a node_pressure variable (see also the parameter physics_type and this chapter), an upper bound on the pressure can be introduced through the pressure_max parameter, which triggers the generation of the maxmimum node pressure constraint.

`pressure_min`

Minimum allowed gas pressure at node.

Default value: nothing

Related Entity Classes: node

If a node has a node_pressure variable (see also the parameter physics_type and this chapter), a lower bound on the pressure can be introduced through the pressure_min parameter, which triggers the generation of the minimum node pressure constraint.

`ptdf_threshold`

The minimum absolute value of the power transfer distribution factor (PTDF) that is considered meaningful.

Default value: 0.001

Related Entity Classes: grid

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. 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 monitoring_active to true.

In addition, define a grid with physics_type set to either ptdf_physics, or lodf_physics. and associate that grid (via node__grid) to both connections' nodes (given by connection__to_node and connection__from_node).

`ramp_limits_down`

Limit the maximum ramp-down rate of an online unit, given as a fraction of the capacityperunit. [ramplimitsdown] = %/t, e.g. 0.2/h

Default value: nothing

Related Entity Classes: node__to_unit and unit__to_node

The definition of the ramp_limits_down 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 node__to_unit 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 capacity_per_unit 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_limits_shutdown`

Maximum ramp-down during shutdowns

Default value: nothing

Related Entity Classes: node__to_unit and unit__to_node

The definition of the ramp_limits_shutdown 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 node__to_unit 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 capacity_per_unit parameter. When the parameter is not specified the limit will not be imposed, which is equivalent to choosing a value of 1.

`ramp_limits_startup`

Maximum ramp-up during startups

Default value: nothing

Related Entity Classes: node__to_unit and unit__to_node

The definition of the ramp_limits_startup 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 node__to_unit 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 capacity_per_unit parameter. When the parameter is not specified the limit will not be imposed, which is equivalent to choosing a value of 1.

`ramp_limits_up`

Limit the maximum ramp-up rate of an online unit, given as a fraction of the capacityperunit. [ramplimitsup] = %/t, e.g. 0.2/h

Default value: nothing

Related Entity Classes: node__to_unit and unit__to_node

The definition of the ramp_limits_up 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 node__to_unit 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 capacity_per_unit 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.

`reactance`

The per unit reactance of a connection.

Default value: nothing

Related Entity Classes: connection

The parameter reactance represents 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 reactance of the line, thetato is the voltage angle of the remote node and thetafrom is the voltage angle of the sending node.

`reactance_base`

If the reactance is given for a p.u. (e.g. p.u. = 100MW), the reactance_base can be set to perform this conversion (e.g. *100).

Default value: 1

Related Entity Classes: connection

As the reactance is often given on a per unit basis, often different than the units used elsewhere, the reactance_base parameter serves as a conversion factor, scaling the reactance with its p.u..

`representative_block_index`

Index for the array of coefficients defined in representative_blocks_by_period

Default value: nothing

Related Entity Classes: temporal_block

See representative_blocks_by_period, Representative periods tutorial.

`representative_blocks_by_period`

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_block_index)

Default value: nothing

Related Entity 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 creates node_state variables and investment variables for all time periods, regardless of whether representative_blocks_by_period is specified for any temporal_block.

To use representative periods in your model, do the following:

Define one temporal_block for the 'normal' periods as you would do if you weren't using representative periods.
Define a set of temporal_block objects, each corresponding to one representative period.
Specify representative_blocks_by_period for the 'normal' temporal_block as a map, from consecutive date-time values to the name of a representative temporal_block.
Associate all the above temporal_block objects to elements in your model (e.g., via node__temporal_block and/or units_on__temporal_block relationships), to map their operational variables from normal periods, to the variable from the representative period.

`reserve_active`

A boolean flag for whether a node is acting as a reserve_node.

Default value: false

Uses Parameter Value Lists: boolean_value_list

Supported parameter value types: bool

Related Entity Classes: node

By setting the parameter reserve_active 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.

`reserve_downward`

Identifier for nodes providing downward reserves.

Default value: false

Uses Parameter Value Lists: boolean_value_list

Supported parameter value types: bool

Related Entity Classes: node

If a node has a true reserve_active 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 reserve_upward or the reserve_downward parameter needs to be set to true, respectively.

`reserve_procurement_cost`

Procurement cost for reserves

Default value: nothing

Related Entity Classes: node__to_unit and unit__to_node

By defining the reserve_procurement_cost parameter for a specific unit__to_node or node__to_unit 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.

`reserve_upward`

A boolean flag for whether a node corresponds to upward reserves. The node will not be treated as a reserve node unless reserve_active is also set to true.

Default value: false

Uses Parameter Value Lists: boolean_value_list

Supported parameter value types: bool

Related Entity Classes: node

`resistance`

To be implemented. The per unit resistance of a connection.

Default value: nothing

Related Entity Classes: connection

The parameter resistance represents the per unit resistance of a transmission line. Currently unimplemented!

`resolution`

Temporal resolution of the temporal_block. Essentially, divides the period between block_start and block_end into TimeSlices with the input resolution.

Default value: Dict{String, Any}("data" => "1h", "type" => "duration")

Supported parameter value types: duration

Related Entity 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 Entity 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

Supported parameter value types: duration

Related Entity 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.

`shared_values`

A map from symbol to shared value.

Default value: nothing

Related Entity Classes: model

TODO.

Related to Multi-stage optimisation?

`shut_down_cost`

Costs of shutting down a 'sub unit'. E.g. EUR/shutdown.

Default value: nothing

Related Entity 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.

`slack_penalty`

A penalty for violating the constraint that fixes this output for this stage (EXPERIMENTAL).

Default value: nothing

Related Entity Classes: stage__output__connection, stage__output__node and stage__output__unit

TODO.

Related to Multi-stage optimisation?

`solver_lp`

Solver for LP problems. Solver package must be added and pre-configured in Julia. Overrides lp_solver RunSpineOpt kwarg

Default value: HiGHS.jl

Uses Parameter Value Lists: solver_lp_list

Supported parameter value types: str

Related Entity 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 solver_lp_options parameter for the model. Note also that if run_spineopt() is called with the lp_solver keyword argument specified, this will override this parameter.

`solver_lp_options`

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")

Supported parameter value types: map

Related Entity Classes: model

LP solver options are specified for a model using the solver_lp_options parameter. This parameter value must take the form of a nested map where the outer key corresponds to the solver package name (case sensitive). E.g. Clp.jl. The inner map consists of option name and value pairs. See the below example. By default, the SpineOpt template contains some common parameters for some common solvers. For a list of supported solver options, one should consult the documentation for the solver and//or the julia solver wrapper package. example solver_lp_options map parameter

`solver_mip`

Solver for MIP problems. Solver package must be added and pre-configured in Julia. Overrides mip_solver RunSpineOpt kwarg

Default value: HiGHS.jl

Uses Parameter Value Lists: solver_mip_list

Supported parameter value types: str

Related Entity 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 solver_mip_options parameter for the model. Note also that if run_spineopt() is called with the mip_solver keyword argument specified, this will override this parameter.

`solver_mip_options`

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")

Supported parameter value types: map

Related Entity Classes: model

MIP solver options are specified for a model using the solver_mip_options parameter. This parameter value must take the form of a nested map where the outer key corresponds to the solver package name (case sensitive). E.g. Cbc.jl. The inner map consists of option name and value pairs. See the below example. By default, the SpineOpt template contains some common parameters for some common solvers. For a list of supported solver options, one should consult the documentation for the solver and//or the julia solver wrapper package. example solver_mip_options map parameter

`stage_scenario`

The scenario that this stage should run (EXPERIMENTAL).

Default value: nothing

Related Entity Classes: stage

TODO.

Related to Multi-stage optimisation?

`start_up_cost`

Costs of starting up a 'sub unit'. E.g. EUR/startup.

Default value: nothing

Related Entity 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.

`stochastic_scenario_end`

A duration for when a stochastic_scenario ends and its child_stochastic_scenarios start. Values are interpreted relative to the start of the current solve, and if no value is given, the stochastic_scenario is assumed to continue indefinitely.

Default value: nothing

Supported parameter value types: duration

Related Entity 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_active`

A boolean flag for whether the flows are instantaneously balanced (false) or the node can store its commodity (true).

Default value: false

Uses Parameter Value Lists: boolean_value_list

Supported parameter value types: bool

Related Entity Classes: node

The storage_active parameter determines whether the node has a node_state variable generated for it that can increase and decrease based on the flows entering and leaving the node, allowing for commodity storage at the node.

The default value is false, meaning that the node cannot store the commodity. Define the value as true to allow for commodity storage.

Note that you'll also have to specify a value for the storage_state_coefficient parameter, as otherwise the node_state variable has zero commodity capacity.

`storage_decommissioning_cost`

To be implemented. Costs associated with decommissioning a storage. The costs will be distributed equally over the storage_decommissioning_time and discounted to the discount_year.

Default value: nothing

Related Entity Classes: node

Warning

UNIMPLEMENTED

`storage_decommissioning_time`

The decommissioning time of the storage, i.e., the time between the moment at which a storage decommissioning decision is taken, and the moment at which decommissioning is complete.

Default value: Dict{String, Any}("data" => "0h", "type" => "duration")

Supported parameter value types: duration

Related Entity Classes: node

Warning

UNIMPLEMENTED

`storage_discount_rate_technology_specific`

Storage-specific discount rate for calculating the investment costs.

Default value: 0.0

Related Entity Classes: node

If not specified, the model default discount_rate is used.

See also discount_rate_technology_specific for units and connections.

`storage_fixed_annual_cost`

Fixed annual operation and maintenance costs of the storage.

Default value: nothing

Related Entity Classes: node

Effectively, a cost coefficient on storage_state_max times (existing_storages + storages_invested_available). E.g. EUR/MWh/a.

`storage_investment_cost`

Investment cost per 'sub storage' over the lifetime of a storage. E.g. EUR/'sub storage'.

Default value: nothing

Related Entity 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_count_fix_cumulative`

Fixes the cumulative number of new storage investments, i.e., the storages_invested_available variable, to the provided value.

Default value: nothing

Related Entity Classes: node

The storage_investment_count_fix_cumulative parameter is used primarily to fix the value of the storages_invested_available variable which represents the storage 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.

`storage_investment_count_fix_new`

Fixes the number of new storage investments, i.e., the storages_invested variable, to the provided value.

Default value: nothing

Related Entity Classes: node

The storage_investment_count_fix_new parameter is 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.

`storage_investment_count_initial_cumulative`

Initializes the cumulative number of new storage investments, i.e., the storages_invested_available variable, to the provided value.

Default value: nothing

Related Entity Classes: node

Sets the initial value for the storages_invested_available variable, i.e. its value prior to model_start.

`storage_investment_count_initial_new`

Initializes the number of new storage investments, i.e., the storages_invested variable, to the provided value.

Default value: nothing

Related Entity Classes: node

Sets the initial value for the storages_invested variable, i.e. its value prior to model_start.

`storage_investment_count_max_cumulative`

Maximum cumulative number of new storages which may be invested in.

Default value: nothing

Related Entity Classes: node

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

Note that storage_investment_count_max_cumulative 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.

`storage_investment_variable_type`

A selector for the type of the storage investment variable (storages_invested): whether it is continuous (usually representing invested capacity) or integer (representing discrete 'sub storage' investments).

Default value: linear

Uses Parameter Value Lists: variable_type_list

Supported parameter value types: str

Related Entity Classes: node

Within an investment 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 storage_state_max and since storage_investment_count_max_cumulative represents the upper bound of the storage investment decision variable, storage_investment_variable_type thus determines what the investment decision represents.

Setting storage_investment_variable_type = none disables investment decisions regardless of storage_investment_count_max_cumulative. If storage_investment_variable_type is integer or binary, then storage_investment_count_max_cumulative represents the maximum number of discrete storages that may be invested-in. If storage_investment_variable_type is linear (default), storage_investment_count_max_cumulative is more analogous to a capacity with storage_state_max being analogous to a scaling parameter. For example, if storage_investment_variable_type = integer, storage_investment_count_max_cumulative = 4 and storage_state_max = 1000 MWh, then the investment decision is how many 1000h MW storages to build. If storage_investment_variable_type = linear, storage_investment_count_max_cumulative = 1000 and storage_state_max = 1 MWh, then the investment decision is how much storage capacity to build. Finally, if storage_investment_variable_type = integer, storage_investment_count_max_cumulative = 10 and storage_state_max = 100 MWh, then the investment decision is how many 100MWh storage blocks to build.

`storage_lead_time`

The lead time of the storage, i.e., the time between the moment at which a storage investment decision is taken, and the moment at which the storage investment becomes operational.

Default value: Dict{String, Any}("data" => "0h", "type" => "duration")

Supported parameter value types: duration

Related Entity Classes: node

Warning

UNIMPLEMENTED!

`storage_lifetime_constraint_sense`

A selector for storage_lifetime constraint sense.

Default value: >=

Uses Parameter Value Lists: constraint_sense_list

Supported parameter value types: str

Related Entity Classes: node

Defines the sense of the storage lifetime constraint. The default '>=' represents minimum technical lifetime.

`storage_lifetime_economic`

Economic lifetime for storage investments: the duration for investment cost payment.

Default value: nothing

Supported parameter value types: duration

Related Entity Classes: node

The economic lifetime of a storage. Effectively, affects the manipulation of the overnight investment costs, i.e. annualization, discounting, etc.

`storage_lifetime_technical`

Technical lifetime for storage investments. Represents minimum technical lifetime by default, but the interpretation can be changed via storage_lifetime_constraint_sense.

Default value: nothing

Supported parameter value types: duration

Related Entity Classes: node

Duration parameter that determines the minimum duration of storage investment decisions. Once a storage has been invested-in, it must remain invested-in for storage_lifetime_technical. Note that storage_lifetime_technical is a dynamic parameter that will impact the amount of solution history that must remain available to the optimisation in each step - this may impact performance.

`storage_longterm_active`

If true, node has a state variable for representative and non-representative timeslices

Default value: false

Uses Parameter Value Lists: boolean_value_list

Supported parameter value types: bool

Related Entity Classes: node

Defines whether a storage is considered a "long-term storage" when using representative periods. If set to true, the storage state is represented using two variables: The regular node_state will depict the storage state deviations within representative periods, while node_state_longterm will be created to track the storage state dynamics between the representatives.

See the Representative periods tutorial.

`storage_self_discharge`

Self-discharge coefficient for the node_state variable. Effectively, represents the loss power per unit of state.

Default value: 0.0

Related Entity Classes: node

The storage_self_discharge parameter allows setting self-discharge losses for nodes with the node_state variables enabled using the storage_active parameter. Effectively, the storage_self_discharge 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 storage_self_discharge parameter value of 0.01 would represent 1% of node_state lost per unit of time. However, a more general definition of what the storage_self_discharge parameter represents in SpineOpt would be loss power per unit of node_state.

`storage_state_coefficient`

The commodity content of a node_state variable in respect to the unit_flow and connection_flow variables. Essentially, acts as a coefficient on the node_state variable in the node_injection constraint.

Default value: 1.0

Related Entity Classes: node

The storage_state_coefficient 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 storage_state_coefficient 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 storage_state_coefficient parameter to have an impact, the node must first have a node_state variable to begin with, defined using the storage_active parameter. By default, the storage_state_coefficient 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.

`storage_state_fix`

Fixes the node_state variable to the provided value. Can be used for e.g. fixing boundary conditions.

Default value: nothing

Related Entity Classes: node

The storage_state_fix 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 storage_state_fix parameter values.

`storage_state_initial`

Initializes the node_state variable to the provided value.

Default value: nothing

Related Entity Classes: node

Sets the initial value for the node_state variable, i.e. the values prior to model_start.

`storage_state_max`

Maximum allowed storage state per 'sub storage', i.e., maximum allowed value for the node_state variable.

Default value: nothing

Related Entity Classes: node

The storage_state_max 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 storage_active parameter must be set to true. However, if the node has storage investments enabled using the storage_investment_count_max_cumulative parameter, the storage_state_max parameter acts as a coefficient for the storages_invested_available variable. Essentially, with investments, the storage_state_max parameter represents storage capacity per storage investment.

`storage_state_max_fraction`

Fraction of storage_state_max that is actually available. Typically between 0-1.

Default value: 1.0

Related Entity Classes: node

Allows reducing storage_state_max by the desired fraction, as the final capacity is calculated as storage_state_max times storage_state_max_fraction.

`storage_state_min`

Minimum allowed storage state per 'sub storage', i.e., minimum allowed value for the node_state variable.

Default value: 0.0

Related Entity Classes: node

The storage_state_min parameter sets the lower bound for the node_state variable, if one has been enabled by the storage_active parameter. For reserve nodes with minimum_reserve_activation_time, the storage_state_min is considered also via a special constraint.

`storage_state_min_fraction`

Fraction of storage_state_max that is the minimum allowed level. Typically between 0-1.

Default value: 0.0

Related Entity Classes: node

Effectively defines the lower bound of the node_state as a fraction of storage_state_max. Useful for e.g. storage investments (see Investments in storages), where the maximum and minimum storage capacities are subject to change.

`tax_in_unit_flow`

Tax costs for incoming unit_flows on this node. E.g. EUR/MWh.

Default value: nothing

Related Entity Classes: node

By defining tax_in_unit_flow 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_flows on this node. Incoming flows accrue positive net taxes, and outgoing flows accrue negative net taxes.

Default value: nothing

Related Entity 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_flows from this node. E.g. EUR/MWh.

Default value: nothing

Related Entity 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.

`tight_compact_formulations_active`

Whether to use tight and compact constraint formulations.

Default value: false

Uses Parameter Value Lists: boolean_value_list

Supported parameter value types: bool

Related Entity Classes: model

If set to true, select constraints will use a tighter formulation. Currently, changed constraints include: connection flow capacity constraint, connection minimum flow constraint, and the unit flow capacity constraint.

`unit_decommissioning_cost`

To be implemented. Costs associated with decommissioning a unit. The costs will be distributed equally over the decommissioning_time and discounted to the discount_year.

Default value: nothing

Related Entity Classes: unit

Warning

UNIMPLEMENTED!

`unit_flow_non_anticipativity_margin`

Margin by which unit_flow variable can differ from the value in the previous window during non_anticipativity_time.

Default value: nothing

Related Entity Classes: node__to_unit and unit__to_node

Used to constrain the upper and lower bounds of the unit_flow variables based on the values in the previous solve in a rolling problem (see Rolling horizon tutorial), up to unit_flow_non_anticipativity_time. Effectively, if unit_flow is within unit_flow_non_anticipativity_time of the start of the current window, its values are constrained to its previous values plus/minus unit_flow_non_anticipativity_margin.

`unit_flow_non_anticipativity_time`

Period of time where the value of the unit_flow variable has to be fixed to the result from the previous window.

Default value: nothing

Supported parameter value types: duration

Related Entity Classes: node__to_unit and unit__to_node

Defines the duration from the start of the current window of a rolling problem (see Rolling horizon tutorial) during which the unit_flow variables obey the unit_flow_non_anticipativity_margin.

`unit_investment_cost`

Investment cost per 'sub unit' over the lifetime of a unit. E.g. EUR/'sub unit'.

Default value: nothing

Related Entity 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.

`units_on_cost`

Costs of keeping a 'sub unit' online. An idling cost, for example. E.g. EUR/'sub unit'.

Default value: nothing

Related Entity 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_on variable can differ from the value in the previous window during non_anticipativity_time.

Default value: nothing

Related Entity Classes: unit

Used to constrain the upper and lower bounds of the units_on variable based on the values in the previous solve in a rolling problem (see Rolling horizon tutorial), up to units_on_non_anticipativity_time. Effectively, if units_on is within units_on_non_anticipativity_time of the start of the current window, its values are constrained to its previous values plus/minus units_on_non_anticipativity_margin.

`units_on_non_anticipativity_time`

Period of time where the value of the units_on variable has to be fixed to the result from the previous window.

Default value: nothing

Supported parameter value types: duration

Related Entity 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.

`user_constraint_slack_penalty`

A penalty for violating a user constraint.

Default value: nothing

Related Entity Classes: user_constraint

Penalty terms for violating the user_constraint in question. By default (value nothing), the positive and negative slack variables are omitted. Effectively, this means that the user_constraint is treated as absolute, with zero violations allowed.

Defining a value for this variable spawns the slack variables. However, note that both the positive and negative slacks are currently always included. There is no way to include only the other slack, nor is it possible to define "asymmetric" penalties for them.

`version`

Current version of the SpineOpt data structure. Modify it at your own risk (but please don't).

Default value: 22

Supported parameter value types: float

Related Entity Classes: settings

Warning

Regular users should never have the need to change this manually, and should not touch this unless they really know what they are doing!

This parameter is used solely for versioning the data structure of SpineOpt. Effectively, it keeps track of what migration scripts need to be run to transition to later versions.

`voltage_angle_fix`

Fixes the node_voltage_angle variable to the provided value.

Default value: nothing

Related Entity 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 voltage_angle_fix parameter can be used.

`voltage_angle_initial`

Initializes the node_voltage_angle variable to the provided value.

Default value: nothing

Related Entity Classes: node

Set the initial value for the node_voltage_angle variable, meaning the values before model_start.

`voltage_angle_max`

Maximum allowed voltage angle at node.

Default value: nothing

Related Entity Classes: node

If a node has a node_voltage_angle variable (see also the parameter physics_type and this chapter), an upper bound on the voltage angle can be introduced through the voltage_angle_max parameter, which triggers the generation of the maximum node voltage angle constraint.

`voltage_angle_min`

Minimum allowed voltage angle at node.

Default value: nothing

Related Entity Classes: node

If a node has a node_voltage_angle variable (see also the parameter physics_type and this chapter), a lower bound on the pressure can be introduced through the voltage_angle_min parameter, which triggers the generation of the minimum node voltage angle constraint.

`vom_cost`

Variable operating costs of a unit_flow variable. E.g. EUR/MWh.

Default value: nothing

Related Entity Classes: node__to_unit 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

Supported parameter value types: float

Related Entity 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_scenario in the objective function relative to its parents.

Default value: 1.0

Supported parameter value types: float

Related Entity 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

Supported parameter value types: duration

Related Entity Classes: model

Defines the length of the "window" (aka "horizon") of a single solve within a "rolling horizon" (aka "receding horizon") optimization. Effectively, each solve (aka "window") contains variables between model_start and model_start + window_duration.

Defined as a Duration from model_start for the initial solve, and the starting time is then moved forward by roll_forward each solve. Results are saved sequentially for each roll_forward, with the simulation stopping once the window start has rolled past model_end.

See the Rolling horizon tutorial for examples.

`window_weight`

The weight of the window in the rolling subproblem

Default value: 1

Related Entity 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_weight as an array of n + 1 floating point values, representing the weight of each window.

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

`write_lodf_file`

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

Default value: false

Uses Parameter Value Lists: boolean_value_list

Supported parameter value types: bool

Related Entity 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

Uses Parameter Value Lists: write_mps_file_list

Supported parameter value types: str

Related Entity 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

Uses Parameter Value Lists: boolean_value_list

Supported parameter value types: bool

Related Entity 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.