# Parameters

## balance_type

A selector for how the :nodal_balance constraint should be handled.

Default value: balance_type_node

Related Object Classes: node

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

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

## big_m

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

Default value: 1000000

Related Object Classes: model

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

## block_end

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

Related Object Classes: temporal_block

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

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

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

## block_start

The start time for the temporal_block. Can be given either as a DateTime for a static start point, or as a Duration for an start point relative to the start of the current optimization.

Related Object Classes: temporal_block

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

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

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

## candidate_connections

The number of connections that may be invested in

Related Object Classes: connection

The candidate_connections parameter denotes the possibility of investing on a certain connection.

The default value of nothing means that the connection can't be invested in, because it's already in operation. An integer value represents the maximum investment possible at any point in time, as a factor of the connection_capacity.

In other words, candidate_connections is the upper bound of the connections_invested_available variable.

## candidate_storages

Determines the maximum number of new storages which may be invested in

Related Object Classes: node

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

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

## candidate_units

Number of units which may be additionally constructed

Related Object Classes: unit

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

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

## commodity_lodf_tolerance

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

Default value: 0.1

Related Object Classes: commodity

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

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

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

## commodity_physics

Defines if the commodity follows lodf or ptdf physics.

Default value: commodity_physics_none

Related Object Classes: commodity

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

## commodity_ptdf_threshold

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

Default value: 0.0001

Related Object Classes: commodity

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

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

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

## compression_factor

The compression factor establishes a compression from an origin node to a receiving node, which are connected through a connection. The first node corresponds to the origin node, the second to the (compressed) destination node. Typically the value is >=1.

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

## connection_availability_factor

Availability of the connection, acting as a multiplier on its connection_capacity. Typically between 0-1.

Default value: 1.0

Related Object Classes: connection

To indicate that a connection is only available to a certain extent or at certain times of the optimization, the connection_availability_factor can be used. A typical use case could be an availability timeseries for connection with expected outage times. By default the availability factor is set to 1. The availability is, among others, used in the constraint_connection_flow_capacity.

## connection_capacity

Limits the connection_flow variable to the to_node. to_node can be a group of nodes, in which case the sum of the connection_flow is constrained.

Defines the upper bound on the corresponding connection_flow variable. If the connection is a candidate connection, the effective connection_flow upper bound is the product of the investment variable, connections_invested_available and connection_capacity. If ptdf based dc load flow is enabled, connection_capacity represents the normal rating of a connection (line) while connection_emergency_capacity represents the maximum post contingency flow.

## connection_contingency

A boolean flag for defining a contingency connection.

Related Object Classes: connection

Specifies that the connection in question is to be included as a contingency when security constrained unit commitment is enabled. When using security constrained unit commitment by setting commodity_physics to commodity_physics_lodf, an N-1 security constraint is created for each monitored line (connection_monitored = true) for each specified contingency (connection_contingency = true).

## connection_conv_cap_to_flow

Optional coefficient for connection_capacity unit conversions in the case the connection_capacity value is incompatible with the desired connection_flow units.

Default value: 1.0

The connection_conv_cap_to_flow can be used to perform the conversion between the measurement unit of the connection_capacity to the measurement unit of the connection_flow variable. The default of this parameter is 1, i.e. assuming that both are given in the same measurement unit.

## connection_emergency_capacity

The maximum post-contingency flow on a monitored connection.

The connection_emergency_capacity parameter represents the maximum post-contingency flow on a monitored connection if ptdf and lodf based security constrained unit commitment is enabled (commodity_physics is set to [commodity_physics_lodf]).

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

## connection_flow_coefficient

defines the unit constraint coefficient on the connection flow variable in the to direction

Default value: 0.0

The connection_flow_coefficient is an optional parameter that can be used to include the connection_flow variable from or to a node in a unit_constraint via the connection__from_node__unit_constraint and connection__to_node__unit_constraint relationships. Essentially, connection_flow_coefficient appears as a coefficient for the connection_flow variable from or to the node in the unit constraint.

## connection_flow_cost

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

Related Object Classes: connection

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

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_investment_cost

The per unit investment cost for the connection over the connection_investment_lifetime

Related Object Classes: connection

By defining the connection_investment_cost parameter for a specific connection, a cost term will be added to the objective function whenever a connection investment is made during the current optimization window.

## connection_investment_lifetime

Determines the minimum investment lifetime of a connection. Once invested, it remains in service for this long

Related Object Classes: connection

connection_investment_lifetime is the minimum amount of time that a connection has to stay in operation once it's invested-in. Only after that time, the connection can be decomissioned. Note that connection_investment_lifetime is a dynamic parameter that will impact the amount of solution history that must remain available to the optimisation in each step - this may impact performance.

## connection_investment_variable_type

Determines whether the investment variable is integer variable_type_integer or continuous variable_type_continuous

Default value: variable_type_integer

Related Object Classes: connection

The connection_investment_variable_type parameter represents the type of the connections_invested_available decision variable.

The default value, variable_type_integer, means that only integer factors of the connection_capacity can be invested in. The value variable_type_continuous means that any fractional factor can also be invested in. The value variable_type_binary means that only a factor of 1 or zero are possible.

## connection_linepack_constant

The linepack constant is a property of gas pipelines and relates the linepack to the pressure of the adjacent nodes.

The linepack constant is a physical property of a connection representing a pipeline and holds information on how the linepack flexibility relates to pressures of the adjacent nodes. If, and only if, this parameter is defined, the linepack flexibility of a pipeline can be modelled. The existence of the parameter triggers the generation of the constraint on line pack storage. The connection_linepack_constant should always be defined on the tuple (connection pipeline, linepack storage node, node group (containing both pressure nodes, i.e. start and end of the pipeline)). See also.

## connection_monitored

A boolean flag for defining a contingency connection.

Default value: false

Related Object Classes: connection

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

## connection_reactance

The per unit reactance of a connection.

Related Object Classes: connection

The per unit reactance of a transmission line. Used in ptdf based dc load flow where the relative reactances of lines determine the ptdfs of the network and in lossless dc powerflow where the flow on a line is given by flow = 1/x(theta_to-theta_from) where x is the reatance of the line, thetato is the voltage angle of the remote node and thetafrom is the voltage angle of the sending node.

## connection_reactance_base

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

Default value: 1

Related Object Classes: connection

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

## connection_resistance

The per unit resistance of a connection.

Related Object Classes: connection

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

## connection_type

A selector between a normal and a lossless bidirectional connection.

Default value: connection_type_normal

Related Object Classes: connection

Used to control specific pre-processing actions on connections. Currently, the primary purpose of connection_type is to simplify the data that is required to define a simple bi-directional, lossless line. If connection_type=:connection_type_lossless_bidirectional, it is only necessary to specify the following minimum data:

If connection_type=:connection_type_lossless_bidirectional the following pre-processing actions are taken:

## constraint_sense

A selector for the sense of the unit_constraint.

Default value: ==

Related Object Classes: unit_constraint

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

See User constraints for details.

## curtailment_cost

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

Related Object Classes: unit

By defining the curtailment_cost parameter for a specific unit, a cost term will be added to the objective function whenever this unit's available capacity exceeds its activity (i.e., the unit_flow variable) over the course of the operational dispatch during the current optimization window.

## cyclic_condition

If the cyclic condition is set to true for a storage node, the node_state at the end of the optimization window has to be larger than or equal to the initial storage state.

Default value: false

The cyclic_condition parameter is used to enforce that the storage level at the end of the optimization window is higher or equal to the storage level at the beginning optimization. If the cyclic_condition parameter is set to true for a node__temporal_block relationship, and the has_state parameter of the corrresponding node is set to true, the constraint_cyclic_node_state will be triggered.

## demand

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

Default value: 0.0

Related Object Classes: node

The demand parameter represents a "demand" or a "load" of a commodity on a node. It appears in the node injection constraint, with positive values interpreted as "demand" or "load" for the modelled system, while negative values provide the system with "influx" or "gain". When the node is part of a group, the fractional_demand parameter can be used to split demand into fractions, when desired. See also: Introduction to groups of objects

The demand parameter can also be included in custom unit_constraints using the demand_coefficient parameter for the node__unit_constraint relationship.

## demand_coefficient

coefficient of the specified node's demand in the specified unit constraint

Default value: 0.0

The demand_coefficient is an optional parameter that can be used to include the demand of the a node in a unit_constraint via the node__unit_constraint relationship. Essentially, demand_coefficient appears as a coefficient for the demand parameter of the connected node in the unit constraint.

## diff_coeff

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 Relationship Classes: node__node

The diff_coeff parameter represents diffusion of a commodity between the two nodes in the node__node relationship. It appears as a coefficient on the node_state variable in the node injection constraint, essentially representing diffusion power per unit of state. Note that the diff_coeff is interpreted as one-directional, meaning that if one defines

diff_coeff(node1=n1, node2=n2),

there will only be diffusion from n1 to n2, but not vice versa. Symmetric diffusion is likely used in most cases, requiring defining the diff_coeff both ways

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

## downward_reserve

Identifier for nodes providing downward reserves

Default value: false

Related Object Classes: node

If a node has a true is_reserve_node parameter, it will be treated as a reserve node in the model. To define whether the node corresponds to an upward or downward reserve commodity, the upward_reserve or the downward_reserve parameter needs to be set to true, respectively.

## duration_unit

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

Default value: minute

Related Object Classes: model

The duration_unit parameter specifies the base unit of time in a model. Two values are currently supported, hour and the default minute. E.g. if the duration_unit is set to hour, a Duration of one minute gets converted into 1/60 hours for the calculations.

## fix_binary_gas_connection_flow

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

The binary flow of a gas pipelines for pressure driven gas transfer is enables through the binary variable binary_gas_connection_flow and the big_m constant. To fix this binary variable, i.e. pre-define the direction of gas through the pipelines, the fix_binary_gas_connection_flow parameter can be used.

## fix_connection_flow

Fix the value of the connection_flow variable.

The fix_connection_flow parameter fixes the value of the connection_flow variable.

## fix_connection_intact_flow

Fix the value of the connection_intact_flow variable.

The fix_connection_intact_flow parameter can be used to fix the values of the connection_intact_flow variable to preset values. If set to a Scalar type value, the connection_intact_flow variable is fixed to that value for all time steps and stochastic_scenarios. Values for individual time steps can be fixed using TimeSeries type values.

## fix_connections_invested

Setting a value fixes the connections_invested variable accordingly

Related Object Classes: connection

The fix_connections_invested parameter can be used to fix the values of the connections_invested variable to preset values. If set to a Scalar type value, the connections_invested variable is fixed to that value for all time steps and stochastic_scenarios. Values for individual time steps can be fixed using TimeSeries type values.

## fix_connections_invested_available

Setting a value fixes the connectionsinvestedavailable variable accordingly

Related Object Classes: connection

The fix_connections_invested_available parameter represents a forced connection investment.

In other words, it is the fix value of the connections_invested_available variable.

## fix_node_pressure

Fixes the corresponding node_pressure variable to the provided value

Related Object Classes: node

In a pressure driven gas model, gas network nodes are associated with the node_pressure variable. In order to fix the pressure at a certain node or to give intial conditions the fix_node_pressure parameter can be used.

## fix_node_state

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

Related Object Classes: node

The fix_node_state parameter simply fixes the value of the node_state variable to the provided value, if one is found. Common uses for the parameter include e.g. providing initial values for node_state variables, by fixing the value on the first modelled time step (or the value before the first modelled time step) using a TimeSeries type parameter value with an appropriate timestamp. Due to the way SpineOpt handles TimeSeries data, the node_state variables are only fixed for time steps with defined fix_node_state parameter values.

## fix_node_voltage_angle

Fixes the corresponding node_voltage_angle variable to the provided value

Related Object Classes: node

For a lossless nodal DC power flow network, each node is associated with a node_voltage_angle variable. In order to fix the voltage angle at a certain node or to give initial conditions the fix_node_voltage_angle parameter can be used.

## fix_nonspin_ramp_down_unit_flow

Fix the nonspin_ramp_down_unit_flow variable.

Related Relationship Classes: unit__to_node

The fix_nonspin_ramp_down_unit_flow parameter simply fixes the value of the nonspin_ramp_down_unit_flow variable to the provided value. As such, it determines directly how much non-spinning downward reserve commodity flows the relevant unit is providing to the node to which it is linked by the unit__to_node relationship.

When a single value is selected, this value is kept constant throughout the model. It is also possible to provide a timeseries of values, which can be used for example to impose initial conditions by providing a value only for the first timestep included in the model.

## fix_nonspin_ramp_up_unit_flow

Fix the nonspin_ramp_up_unit_flow variable.

Related Relationship Classes: unit__from_node and unit__to_node

The fix_nonspin_ramp_up_unit_flow parameter simply fixes the value of the nonspin_ramp_up_unit_flow variable to the provided value. As such, it determines directly how much non-spinning upward reserve commodity flows the relevant unit is providing to the node to which it is linked by the unit__to_node relationship.

When a single value is selected, this value is kept constant throughout the model. It is also possible to provide a timeseries of values, which can be used for example to impose initial conditions by providing a value only for the first timestep included in the model.

## fix_nonspin_units_shut_down

Fix the nonspin_units_shut_down variable.

Related Relationship Classes: unit__to_node

The fix_nonspin_units_shut_down parameter simply fixes the value of the nonspin_units_shut_down variable to the provided value. As such, it determines directly how many member units are involved in providing downward reserve commodity flows to the node to which it is linked by the unit__to_node relationship.

When a single value is selected, this value is kept constant throughout the model. It is also possible to provide a timeseries of values, which can be used for example to impose initial conditions by providing a value only for the first timestep included in the model.

## fix_nonspin_units_started_up

Fix the nonspin_units_started_up variable.

Related Relationship Classes: unit__from_node and unit__to_node

The fix_nonspin_units_started_up parameter simply fixes the value of the nonspin_units_started_up variable to the provided value. As such, it determines directly how many member units are involved in providing upward reserve commodity flows to the node to which it is linked by the unit__to_node relationship.

When a single value is selected, this value is kept constant throughout the model. It is also possible to provide a timeseries of values, which can be used for example to impose initial conditions by providing a value only for the first timestep included in the model.

## fix_ramp_down_unit_flow

Fix the ramp_down_unit_flow variable.

Related Relationship Classes: unit__to_node

The fix_ramp_down_unit_flow parameter simply fixes the value of the ramp_down_unit_flow variable to the provided value. It is possible to provide an incomplete timeseries of values, which can be used for example to impose initial conditions by providing a value only for the first timestep included in the model.

## fix_ramp_up_unit_flow

Fix the ramp_up_unit_flow variable.

Related Relationship Classes: unit__from_node and unit__to_node

The fix_ramp_up_unit_flow parameter simply fixes the value of the ramp_up_unit_flow variable to the provided value. It is possible to provide an incomplete timeseries of values, which can be used for example to impose initial conditions by providing a value only for the first timestep included in the model.

## fix_ratio_in_in_unit_flow

Fix the ratio between two unit_flows coming into the unit from the two nodes.

Related Relationship Classes: unit__node__node

The definition of the fix_ratio_in_in_unit_flow parameter triggers the generation of the constraint_fix_ratio_in_in_unit_flow and fixes the ratio between incoming flows of a unit. The parameter is defined on the relationship class unit__node__node, where both nodes (or group of nodes) in this relationship represent from_nodes, i.e. the incoming flows to the unit. The ratio parameter is interpreted such that it constrains the ratio of in1 over in2, where in1 is the unit_flow variable from the first node in the unit__node__node relationship in a left-to-right order. This parameter can be useful, for instance if a unit requires a specific commodity mix as a fuel supply.

To enforce e.g. for a unit u a fixed share of 0.8 of its incoming flow from the node supply_fuel_1 compared to its incoming flow from the node group supply_fuel_2 (consisting of the two nodes supply_fuel_2_component_a and supply_fuel_2_component_b) the fix_ratio_in_in_unit_flow parameter would be set to 0.8 for the relationship u__supply_fuel_1__supply_fuel_2.

## fix_ratio_in_out_unit_flow

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

Related Relationship Classes: unit__node__node

The definition of the fix_ratio_in_out_unit_flow parameter triggers the generation of the constraint_fix_ratio_in_out_unit_flow and fixes the ratio between incoming and outgoing flows of a unit. The parameter is defined on the relationship class unit__node__node, where the first node (or group of nodes) in this relationship represents the from_node,i i.e. the incoming flows to the unit, and the second node (or group of nodes), represents the to_node i.e. the outgoing flow from the unit. The ratio parameter is interpreted such that it constrains the ratio of in over out, where in is the unit_flow variable from the first node in the unit__node__node relationship in a left-to-right order.

To enforce e.g. a fixed ratio of 1.4 for a unit u between its incoming gas flow from the node ng and its outgoing flows to the node group el_heat (consisting of the two nodes el and heat), the fix_ratio_in_out_unit_flow parameter would be set to 1.4 for the relationship u__ng__el_heat.

## fix_ratio_out_in_connection_flow

Fix the ratio between the connection_flow from the first node and the connection_flow to the second 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.

## fix_ratio_out_in_unit_flow

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

Related Relationship Classes: unit__node__node

The definition of the fix_ratio_out_in_unit_flow parameter triggers the generation of the constraint_fix_ratio_out_in_unit_flow and fixes the ratio between out and incoming flows of a unit. The parameter is defined on the relationship class unit__node__node, where the first node (or group of nodes) in this relationship represents the to_node, i.e. the outgoing flow from the unit, and the second node (or group of nodes), represents the from_node, i.e. the incoming flows to the unit. The ratio parameter is interpreted such that it constrains the ratio of out over in, where out is the unit_flow variable from the first node in the unit__node__node relationship in a left-to-right order.

To enforce e.g. a fixed ratio of 0.8 for a unit u between its outgoing flows to the node group el_heat (consisting of the two nodes el and heat) and its incoming gas flow from ngthe fix_ratio_out_in_unit_flow parameter would be set to 0.8 for the relationship u__el_heat__ng.

## fix_ratio_out_out_unit_flow

Fix the ratio between two unit_flows going from the unit into the two nodes.

Related Relationship Classes: unit__node__node

The definition of the fix_ratio_out_out_unit_flow parameter triggers the generation of the constraint_fix_ratio_out_out_unit_flow and fixes the ratio between outgoing flows of a unit. The parameter is defined on the relationship class unit__node__node, where the nodes (or group of nodes) in this relationship represent the to_node's', i.e. outgoing flow from the unit. The ratio parameter is interpreted such that it constrains the ratio of out1 over out2, where out1 is the unit_flow variable from the first node in the unit__node__node relationship in a left-to-right reading order.

To enforce a fixed ratio between two products of a unit u, e.g. fixing the share of produced electricity flowing to node el to 0.4 of the production of heat flowing to node heat, the fix_ratio_out_out_unit_flow parameter would be set to 0.4 for the relationship u__el__heat.

## fix_shut_down_unit_flow

Fix the shut_down_unit_flow variable.

Related Relationship Classes: unit__to_node

The fix_shut_down_unit_flow parameter fixes the value of the shut_down_unit_flow to the provided value, if the parameter is defined.

Common uses for the parameter include e.g. providing initial values for the shut_down_unit_flow, by fixing the value on the first modelled time step (or the value before the first modelled time step) using a TimeSeries type parameter value with an appropriate timestamp. Due to the way SpineOpt handles TimeSeries data, the shut_down_unit_flow variable is only fixed for time steps with defined fix_shut_down_unit_flow parameter values.

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

Note that the mentioned shut_down_unit_flow variable is only included if the parameter max_startup_ramp exist for the correspond unit__to_node or unit__from_node relationship. The usage of ramps is described in Ramping and Reserves.

## fix_start_up_unit_flow

Fix the start_up_unit_flow variable.

Related Relationship Classes: unit__from_node and unit__to_node

The fix_start_up_unit_flow parameter fixes the value of the start_up_unit_flow to the provided value, if the parameter is defined.

Common uses for the parameter include e.g. providing initial values for the start_up_unit_flow, by fixing the value on the first modelled time step (or the value before the first modelled time step) using a TimeSeries type parameter value with an appropriate timestamp. Due to the way SpineOpt handles TimeSeries data, the start_up_unit_flow variable is only fixed for time steps with defined fix_start_up_unit_flow parameter values.

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

Note that the mentioned start_up_unit_flow variable is only included if the parameter max_startup_ramp exist for the correspond unit__to_node or unit__from_node relationship. The usage of ramps is described in Ramping and Reserves.

## fix_storages_invested

Used to fix the value of the storages_invested variable

Related Object Classes: node

Used primarily to fix the value of the storages_invested variable which represents the point-in-time storage investment decision variable at a node and how many candidate storages are invested-in in a particular timeslice at the corresponding node.

## fix_storages_invested_available

Used to fix the value of the storagesinvestedavailable variable

Related Object Classes: node

Used primarily to fix the value of the storages_invested_available variable which represents the storages investment decision variable and how many candidate storages are available at the corresponding node, time step and stochastic scenario. Used also in the decomposition framework to communicate the value of the master problem solution variables to the operational sub-problem.

## fix_unit_flow

Fix the unit_flow variable.

Related Relationship Classes: unit__from_node and unit__to_node

The fix_unit_flow parameter fixes the value of the unit_flow variable to the provided value, if the parameter is defined.

Common uses for the parameter include e.g. providing initial values for the unit_flow variable, by fixing the value on the first modelled time step (or the value before the first modelled time step) using a TimeSeries type parameter value with an appropriate timestamp. Due to the way SpineOpt handles TimeSeries data, the unit_flow variable is only fixed for time steps with defined fix_unit_flow parameter values.

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

## fix_unit_flow_op

Fix the unit_flow_op variable.

Related Relationship Classes: unit__from_node and unit__to_node

If operating_points is defined on a certain unit__to_node or unit__from_node flow, the corresponding unit_flow flow variable is decomposed into a number of sub-variables, unit_flow_op one for each operating point, with an additional index, i to reference the specific operating point. fix_unit_flow_op can thus be used to fix the value of one or more of the variables as desired.

## fix_units_invested

Fix the value of the units_invested variable.

Related Object Classes: unit

Used primarily to fix the value of the units_invested variable which represents the point-in-time unit investment decision variable and how many candidate units are invested-in in a particular timeslice.

## fix_units_invested_available

Fix the value of the units_invested_available variable

Related Object Classes: unit

Used primarily to fix the value of the units_invested_available variable which represents the unit investment decision variable and how many candidate units are invested-in and available at the corresponding node, time step and stochastic scenario. Used also in the decomposition framework to communicate the value of the master problem solution variables to the operational sub-problem.

## fix_units_on

Fix the value of the units_on variable.

Related Object Classes: unit

The fix_units_on parameter simply fixes the value of the units_on variable to the provided value. As such, it determines directly how many members of the specific unit will be online throughout the model when a single value is selected. It is also possible to provide a timeseries of values, which can be used for example to impose initial conditions by providing a value only for the first timestep included in the model.

## fix_units_on_coefficient_in_in

Optional coefficient for the units_on variable impacting the fix_ratio_in_in_unit_flow constraint.

Default value: 0.0

Related Relationship Classes: unit__node__node

The fix_units_on_coefficient_in_in parameter is an optional coefficient in the unit input-input ratio constraint controlled by the fix_ratio_in_in_unit_flow parameter. Essentially, it acts as a coefficient for the units_on variable in the constraint, allowing for fixing the conversion ratio depending on the amount of online capacity.

Note that there are different parameters depending on the directions of the unit_flow variables being constrained: fix_units_on_coefficient_in_out, fix_units_on_coefficient_out_in, and fix_units_on_coefficient_out_out, all of which apply to their respective constraints. Similarly, there are different parameters for setting minimum or maximum conversion rates, e.g. min_units_on_coefficient_in_in and max_units_on_coefficient_in_in.

## fix_units_on_coefficient_in_out

Optional coefficient for the units_on variable impacting the fix_ratio_in_out_unit_flow constraint.

Default value: 0.0

Related Relationship Classes: unit__node__node

The fix_units_on_coefficient_in_out parameter is an optional coefficient in the unit input-output ratio constraint controlled by the fix_ratio_in_out_unit_flow parameter. Essentially, it acts as a coefficient for the units_on variable in the constraint, allowing for fixing the conversion ratio depending on the amount of online capacity.

Note that there are different parameters depending on the directions of the unit_flow variables being constrained: fix_units_on_coefficient_in_in, fix_units_on_coefficient_out_in, and fix_units_on_coefficient_out_out, all of which apply to their respective constraints. Similarly, there are different parameters for setting minimum or maximum conversion rates, e.g. min_units_on_coefficient_in_out and max_units_on_coefficient_in_out.

## fix_units_on_coefficient_out_in

Optional coefficient for the units_on variable impacting the fix_ratio_out_in_unit_flow constraint.

Default value: 0.0

Related Relationship Classes: unit__node__node

The fix_units_on_coefficient_out_in parameter is an optional coefficient in the unit output-input ratio constraint controlled by the fix_ratio_out_in_unit_flow parameter. Essentially, it acts as a coefficient for the units_on variable in the constraint, allowing for fixing the conversion ratio depending on the amount of online capacity.

Note that there are different parameters depending on the directions of the unit_flow variables being constrained: fix_units_on_coefficient_in_in, fix_units_on_coefficient_in_out, and fix_units_on_coefficient_out_out, all of which apply to their respective constraints. Similarly, there are different parameters for setting minimum or maximum conversion rates, e.g. min_units_on_coefficient_out_in and max_units_on_coefficient_out_in.

## fix_units_on_coefficient_out_out

Optional coefficient for the units_on variable impacting the fix_ratio_out_out_unit_flow constraint.

Default value: 0.0

Related Relationship Classes: unit__node__node

The fix_units_on_coefficient_out_out parameter is an optional coefficient in the unit output-output ratio constraint controlled by the fix_ratio_out_out_unit_flow parameter. Essentially, it acts as a coefficient for the units_on variable in the constraint, allowing for fixing the conversion ratio depending on the amount of online capacity.

Note that there are different parameters depending on the directions of the unit_flow variables being constrained: fix_units_on_coefficient_in_in, fix_units_on_coefficient_in_out, and fix_units_on_coefficient_out_in, all of which apply to their respective constraints. Similarly, there are different parameters for setting minimum or maximum conversion rates, e.g. min_units_on_coefficient_out_out and max_units_on_coefficient_out_out.

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

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.

For the MILP representation of pressure driven gas transfer, we use an outer approximation approach as described by Schwele et al.. The Weymouth equation is approximated around fixed pressure points, as described by the constraint on fixed node pressure points, constraining the average flow in each direction dependent on the adjacent node pressures. The first fixed pressure constant, which will be multiplied with the pressure of the origin node, is represented by an Array value of the fixed_pressure_constant_1. The second pressure constant corresponds to the related parameter fixed_pressure_constant_0. Note that the fixed_pressure_constant_1 parameter should be defined on a connection__node__node relationship, for which the first node corresponds to the origin node, while the second node corresponds to the destination node. For a typical gas pipeline, the will be a fixed_pressure_constant_1 for both directions of flow.

## fom_cost

Fixed operation and maintenance costs of a unit. Essentially, a cost coefficient on the number_of_units and unit_capacity parameters. E.g. EUR/MWh

Related Object Classes: unit

By defining the fom_cost parameter for a specific unit, a cost term will be added to the objective function to account for the fixed operation and maintenance costs associated with that unit during the current optimization window.

## frac_state_loss

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

Default value: 0.0

Related Object Classes: node

The frac_state_loss parameter allows setting self-discharge losses for nodes with the node_state variables enabled using the has_state variable. Effectively, the frac_state_loss parameter acts as a coefficient on the node_state variable in the node injection constraint, imposing losses for the node. In simple cases, storage losses are typically fractional, e.g. a frac_state_loss parameter value of 0.01 would represent 1% of node_state lost per unit of time. However, a more general definition of what the frac_state_loss parameter represents in SpineOpt would be loss power per unit of node_state.

## fractional_demand

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

Default value: 0.0

Related Object Classes: node

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

## fuel_cost

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

Related Relationship Classes: unit__from_node and unit__to_node

By defining the fuel_cost parameter for a specific unit, node, and direction, a cost term will be added to the objective function to account for costs associated with the unit's fuel usage over the course of its operational dispatch during the current optimization window.

## graph_view_position

An optional setting for tweaking the position of the different elements when drawing them via Spine Toolbox Graph View.

Related Object Classes: connection, node and unit

The graph_view_position parameter can be used to fix the positions of various objects and relationships when plotted using the Spine Toolbox Graph View. If not defined, Spine Toolbox simply plots the element in question wherever it sees fit in the graph.

## has_binary_gas_flow

This parameter needs to be set to true in order to represent bidirectional pressure drive gas transfer.

Default value: false

Related Object Classes: connection

This parameter is necessary for the use of pressure driven gas transfer, for which the direction of flow is not known a priori. The parameter has_binary_gas_flow is a booelean method parameter, which - when set to true - triggers the generation of the binary variables binary_gas_connection_flow, which (together with the big_m parameter) forces the average flow through a pipeline to be unidirectional.

## has_pressure

A boolean flag for whether a node has a node_pressure variable.

Default value: false

Related Object Classes: node

If a node is to represent a node in a pressure driven gas network, the boolean parameter has_pressure should be set true, in order to trigger the generation of the node_pressure variable. The pressure at a certain node can also be constrainted through the parameters max_node_pressure and min_node_pressure. More details on the use of pressure driven gas transfer are described here

## has_state

A boolean flag for whether a node has a node_state variable.

Default value: false

Related Object Classes: node

The has_state parameter is simply a Bool flag for whether a node has a node_state variable. By default, it is set to false, so the nodes enforce instantaneous commodity balance according to the nodal balance and node injection constraints. If set to true, the node will have a node_state variable generated for it, allowing for commodity storage at the node. Note that you'll also have to specify a value for the state_coeff parameter, as otherwise the node_state variable has zero commodity capacity.

## has_voltage_angle

A boolean flag for whether a node has a node_voltage_angle variable.

Default value: false

Related Object Classes: node

For the use of node-based lossless DC powerflow, each node will be associated with a node_voltage_angle variable. To enable the generation of the variable in the optimization model, the boolean parameter has_voltage_angle should be set true. The voltage angle at a certain node can also be constrained through the parameters max_voltage_angle and min_voltage_angle. More details on the use of lossless nodal DC power flows are described here

## is_active

If false, the object is excluded from the model if the tool filter object activity control is specified

Default value: true

is_acive is a universal, utility parameter that is defined for every object class. When used in conjunction with the activity_control feature, the is_active parameter allows one to control whether or not a specific object is active within a model or not.

## is_reserve_node

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

Default value: false

Related Object Classes: node

By setting the parameter is_reserve_node to true, a node is treated as a reserve node in the model. Units that are linked through a unit__to_node relationship will be able to provide balancing services to the reserve node, but within their technical feasibility. The mathematical formulation holds a chapter on Ramping and reserve constraints and the general concept of setting up a model with reserves is described in Ramping and Reserves.

## max_cum_in_unit_flow_bound

Set a maximum cumulative upper bound for a unit_flow

Related Relationship Classes: unit__commodity

To impose a limit on the cumulative in flows to a unit for the entire modelling horizon, e.g. to enforce limits on emissions, the max_cum_in_unit_flow_bound parameter can be used. Defining this parameter triggers the generation of the constraint_max_cum_in_unit_flow_bound.

Assuming for instance that the total intake of a unit u_A should not exceed 10MWh for the entire modelling horizon, then the max_cum_in_unit_flow_bound would need to take the value 10. (Assuming here that the unit_flow variable is in MW, and the model duration_unit is hours)

## max_gap

Specifies the maximum optimality gap for the model. Currently only used for the master problem within a decomposed structure

Default value: 0.05

Related Object Classes: model

This determines the optimality convergence criterion and is the benders gap tolerance for the master problem in a decomposed investments model. The benders gap is the relative difference between the current objective function upper bound(zupper) and lower bound (zlower) and is defined as 2*(zupper-zlower)/(zupper + zlower). When this value is lower than max_gap the benders algorithm will terminate having achieved satisfactory optimality.

## max_iterations

Specifies the maximum number of iterations for the model. Currently only used for the master problem within a decomposed structure

Default value: 10.0

Related Object Classes: model

When the model in question is of type :spineopt_master, this determines the maximum number of Benders iterations.

## max_node_pressure

Maximum allowed gas pressure at node.

Related Object Classes: node

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

## max_ratio_in_in_unit_flow

Maximum ratio between two unit_flows coming into the unit from the two nodes.

Related Relationship Classes: unit__node__node

The definition of the max_ratio_in_in_unit_flow parameter triggers the generation of the constraint_max_ratio_in_in_unit_flow and enforces an upper bound on the ratio between incoming flows of a unit. The parameter is defined on the relationship class unit__node__node, where both nodes (or group of nodes) in this relationship represent from_nodes, i.e. the incoming flows to the unit. The ratio parameter is interpreted such that it constrains the ratio of in1 over in2, where in1 is the unit_flow variable from the first node in the unit__node__node relationship in a left-to-right reading order. This parameter can be useful, for instance if a unit requires a specific commodity mix as a fuel supply.

To enforce e.g. for a unit u a maximum share of 0.8 of its incoming flow from the node supply_fuel_1 compared to its incoming flow from the node group supply_fuel_2 (consisting of the two nodes supply_fuel_2_component_a and supply_fuel_2_component_b) the max_ratio_in_in_unit_flow parameter would be set to 0.8 for the relationship u__supply_fuel_1__supply_fuel_2.

## max_ratio_in_out_unit_flow

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

Related Relationship Classes: unit__node__node

The definition of the max_ratio_in_out_unit_flow parameter triggers the generation of the constraint_max_ratio_in_out_unit_flow and sets an upper bound on the ratio between incoming and outgoing flows of a unit. The parameter is defined on the relationship class unit__node__node, where the first node (or group of nodes) in this relationship represents the from_node, i.e. the incoming flows to the unit, and the second node (or group of nodes), represents the to_node i.e. the outgoing flow from the unit. The ratio parameter is interpreted such that it constrains the ratio of in over out, where in is the unit_flow variable from the first node in the unit__node__node relationship in a left-to-right reading order.

To enforce e.g. a maximum ratio of 1.4 for a unit u between its incoming gas flow from the node ng and its outgoing flow to the node group el_heat (consisting of the two nodes el and heat), the max_ratio_in_out_unit_flow parameter would be set to 1.4 for the relationship u__ng__el_heat.

## max_ratio_out_in_connection_flow

Maximum ratio between the connection_flow from the first node and the connection_flow to the second 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 node commodity2, the max_ratio_out_in_connection_flow parameter would be set to 0.8 for the relationship conn__commodity1__commodity2.

Note that the ratio can also be defined for connection__node__node relationships where one or both of the nodes correspond to node groups in order to impose a ratio on aggregated connection flows.

## max_ratio_out_in_unit_flow

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

Related Relationship Classes: unit__node__node

The definition of the max_ratio_out_in_unit_flow parameter triggers the generation of the constraint_max_ratio_out_in_unit_flow and enforces an upper bound on the ratio between outgoing and incoming flows of a unit. The parameter is defined on the relationship class unit__node__node, where the first node (or group of nodes) in this relationship represents the to_node, i.e. the outgoing flow from the unit, and the second node (or group of nodes), represents the from_node, i.e. the incoming flows to the unit. The ratio parameter is interpreted such that it constrains the ratio of out over in, where out is the unit_flow variable from the first node in the unit__node__node relationship in a left-to-right reading order.

To enforce e.g. a maximum ratio of 0.8 for a unit u between its outgoing flows to the node group el_heat (consisting of the two nodes el and heat) and its incoming gas flow from ng the max_ratio_out_in_unit_flow parameter would be set to 0.8 for the relationship u__el_heat__ng.

## max_ratio_out_out_unit_flow

Maximum ratio between two unit_flows going from the unit into the two nodes.

Related Relationship Classes: unit__node__node

The definition of the max_ratio_out_out_unit_flow parameter triggers the generation of the constraint_max_ratio_out_out_unit_flow and sets an upper bound on the ratio between outgoing flows of a unit. The parameter is defined on the relationship class unit__node__node, where the nodes (or group of nodes) in this relationship represent the to_node's', i.e. outgoing flow from the unit. The ratio parameter is interpreted such that it constrains the ratio of out1 over out2, where out1 is the unit_flow variable from the first node in the unit__node__node relationship in a left-to-right reading order.

To enforce a maximum ratio between two products of a unit u, e.g. setting the maximum share of produced electricity flowing to node el to 0.4 of the production of heat flowing to node heat, the fix_ratio_out_out_unit_flow parameter would be set to 0.4 for the relationship u__el__heat.

## max_res_shutdown_ramp

Maximum non-spinning reserve ramp-down for online units providing reserves during shut-downs

Related Relationship Classes: unit__from_node and unit__to_node

A unit can provide spinning and nonspinning reserves to a reserve node. These reserves can be either upward_reserve or downward_reserve. Nonspinning downward reserves are provided to a downward_reserve node by contracted units holding available to shutdown. To include the provision of nonspinning downward reserves, the parameter max_res_shutdown_ramp needs to be defined on the corresponding unit__to_node relationship. This will trigger the generation of the variables nonspin_units_shut_down and nonspin_ramp_down_unit_flow and the constraint on maximum downward nonspinning reserve provision. Note that max_res_shutdown_ramp is given as a fraction of the unit_capacity.

A detailed description of the usage of ramps and reserves is given in the chapter Ramping and Reserves. The chapter Ramping and reserve constraints in the Mathematical Formulation presents the equations related to ramps and reserves.

## max_res_startup_ramp

Maximum non-spinning reserve ramp-up for offline units scheduled for reserve provision

Related Relationship Classes: unit__from_node and unit__to_node

A unit can provide spinning and nonspinning reserves to a reserve node. These reserves can be either upward_reserve or downward_reserve. Nonspinning upward reserves are provided to a upward_reserve node by contracted offline units holding available to startup. To include the provision of nonspinning upward reserves, the parameter max_res_startup_ramp needs to be defined on the corresponding unit__to_node relationship. This will trigger the generation of the variables nonspin_units_started_up and nonspin_ramp_up_unit_flow and the constraint on maximum upward nonspinning reserve provision. Note that max_res_startup_ramp is given as a fraction of the unit_capacity.

A detailed description of the usage of ramps and reserves is given in the chapter Ramping and Reserves. The chapter Ramping and reserve constraints in the Mathematical Formulation presents the equations related to ramps and reserves.

## max_shutdown_ramp

Maximum ramp-down during shutdowns

Related Relationship Classes: unit__from_node and unit__to_node

The definition of the max_shutdown_ramp parameter will trigger the creation of the constraint on maximum shutdown ramp. It sets an upper bound on the unit_flow variable for the timestep right before a shutdown.

It can be defined for unit__to_node or unit__from_node relationships, as well as their counterparts for node groups. It will then impose restrictions on the unit_flow variables that indicate flows between the two members of the relationship for which the parameter is defined. The parameter is given as a fraction of the unit_capacity parameter. When the parameter is not included, the aforementioned constraint will not be created, which is equivalent to choosing a value of 1.

## max_startup_ramp

Maximum ramp-up during startups

Related Relationship Classes: unit__from_node and unit__to_node

The definition of the max_startup_ramp parameter will trigger the creation of the Constraint on upward start up ramp_up. It sets an upper bound on the unit_flow variable for the timestep right after a startup.

It can be defined for unit__to_node or unit__from_node relationships, as well as their counterparts for node groups. It will then impose restrictions on the unit_flow variables that indicate flows between the two members of the relationship for which the parameter is defined. The parameter is given as a fraction of the unit_capacity parameter. When the parameter is not included, the aforementioned constraint will not be created, which is equivalent to choosing a value of 1.

## max_units_on_coefficient_in_in

Optional coefficient for the units_on variable impacting the max_ratio_in_in_unit_flow constraint.

Default value: 0.0

Related Relationship Classes: unit__node__node

The max_units_on_coefficient_in_in parameter is an optional coefficient in the unit input-input ratio constraint controlled by the max_ratio_in_in_unit_flow parameter. Essentially, it acts as a coefficient for the units_on variable in the constraint, allowing for making the maximum conversion ratio dependent on the amount of online capacity.

Note that there are different parameters depending on the directions of the unit_flow variables being constrained: max_units_on_coefficient_in_out, max_units_on_coefficient_out_in, and max_units_on_coefficient_out_out, all of which apply to their respective constraints. Similarly, there are different parameters for setting minimum or fixed conversion rates, e.g. min_units_on_coefficient_in_in and fix_units_on_coefficient_in_in.

## max_units_on_coefficient_in_out

Optional coefficient for the units_on variable impacting the max_ratio_in_out_unit_flow constraint.

Default value: 0.0

Related Relationship Classes: unit__node__node

The max_units_on_coefficient_in_out parameter is an optional coefficient in the unit input-output ratio constraint controlled by the max_ratio_in_out_unit_flow parameter. Essentially, it acts as a coefficient for the units_on variable in the constraint, allowing for making the maximum conversion ratio dependent on the amount of online capacity.

Note that there are different parameters depending on the directions of the unit_flow variables being constrained: max_units_on_coefficient_in_in, max_units_on_coefficient_out_in, and max_units_on_coefficient_out_out, all of which apply to their respective constraints. Similarly, there are different parameters for setting minimum or fixed conversion rates, e.g. min_units_on_coefficient_in_out and fix_units_on_coefficient_in_out.

## max_units_on_coefficient_out_in

Optional coefficient for the units_on variable impacting the max_ratio_out_in_unit_flow constraint.

Default value: 0.0

Related Relationship Classes: unit__node__node

The max_units_on_coefficient_out_in parameter is an optional coefficient in the unit output-input ratio constraint controlled by the max_ratio_out_in_unit_flow parameter. Essentially, it acts as a coefficient for the units_on in the constraint, allowing for making the maximum conversion ratio dependent on the amount of online capacity.

Note that there are different parameters depending on the directions of the unit_flow being constrained: max_units_on_coefficient_in_in, max_units_on_coefficient_in_out, and max_units_on_coefficient_out_out, all of which apply to their respective constraints. Similarly, there are different parameters for setting minimum or fixed conversion rates, e.g. min_units_on_coefficient_out_in and fix_units_on_coefficient_out_in.

## max_units_on_coefficient_out_out

Optional coefficient for the units_on variable impacting the max_ratio_out_out_unit_flow constraint.

Default value: 0.0

Related Relationship Classes: unit__node__node

The max_units_on_coefficient_out_out parameter is an optional coefficient in the unit output-output ratio constraint controlled by the max_ratio_out_out_unit_flow parameter. Essentially, it acts as a coefficient for the units_on variable in the constraint, allowing for making the maximum conversion ratio dependent on the amount of online capacity.

Note that there are different parameters depending on the directions of the unit_flow variables being constrained: max_units_on_coefficient_in_in, max_units_on_coefficient_out_in, and max_units_on_coefficient_in_out, all of which apply to their respective constraints. Similarly, there are different parameters for setting minimum or fixed conversion rates, e.g. min_units_on_coefficient_out_out and fix_units_on_coefficient_out_out.

## max_voltage_angle

Maximum allowed voltage angle at node.

Related Object Classes: node

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

## min_down_time

Minimum downtime of a unit after it shuts down.

Related Object Classes: unit

The definition of the min_down_time parameter will trigger the creation of the Constraint on minimum down time. It sets a lower bound on the period that a unit has to stay offline after a shutdown.

It can be defined for a unit and will then impose restrictions on the units_on variables that represent the on- or offline status of the unit. The parameter is given as a duration value. When the parameter is not included, the aforementioned constraint will not be created, which is equivalent to choosing a value of 0.

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

## min_node_pressure

Minimum allowed gas pressure at node.

Related Object Classes: node

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

## min_ratio_in_in_unit_flow

Minimum ratio between two unit_flows coming into the unit from the two nodes.

Related Relationship Classes: unit__node__node

The definition of the min_ratio_in_in_unit_flow parameter triggers the generation of the constraint_min_ratio_in_in_unit_flow and sets a lower bound for the ratio between incoming flows of a unit. The parameter is defined on the relationship class unit__node__node, where both nodes (or group of nodes) in this relationship represent from_nodes, i.e. the incoming flows to the unit. The ratio parameter is interpreted such that it constrains the ratio of in1 over in2, where in1 is the unit_flow variable from the first node in the unit__node__node relationship in a left-to-right reading order. This parameter can be useful, for instance if a unit requires a specific commodity mix as a fuel supply.

To enforce e.g. for a unit u a minimum share of 0.2 of its incoming flow from the node supply_fuel_1 compared to its incoming flow from the node group supply_fuel_2 (consisting of the two nodes supply_fuel_2_component_a and supply_fuel_2_component_b) the min_ratio_in_in_unit_flow parameter would be set to 0.2 for the relationship u__supply_fuel_1__supply_fuel_2.

## min_ratio_in_out_unit_flow

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

Related Relationship Classes: unit__node__node

The definition of the min_ratio_in_out_unit_flow parameter triggers the generation of the constraint_min_ratio_in_out_unit_flow and enforces a lower bound on the ratio between incoming and outgoing flows of a unit. The parameter is defined on the relationship class unit__node__node, where the first node (or group of nodes, see) in this relationship represents the from_node, i.e. the incoming flow to the unit, and the second node (or group of nodes) represents the to_node i.e. the outgoing flow from the unit. The ratio parameter is interpreted such that it constrains the ratio of in over out, where in is the unit_flow variable from the first node in the unit__node__node relationship in a left-to-right reading order.

To enforce e.g. a minimum ratio of 1.4 for a unit u between its incoming gas flow from the node ng and its outgoing flow to the node group el_heat (consisting of the two nodes el and heat), the fix_ratio_in_out_unit_flow parameter would be set to 1.4 for the relationship u__ng__el_heat.

## min_ratio_out_in_connection_flow

Minimum ratio between the connection_flow from the first node and the connection_flow to the second 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 node commodity2, the min_ratio_out_in_connection_flow parameter would be set to 0.8 for the relationship conn__commodity1__commodity2.

## min_ratio_out_in_unit_flow

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

Related Relationship Classes: unit__node__node

The definition of the [min_ratio_out_in_unit_flow] parameter triggers the generation of the constraint_min_ratio_out_in_unit_flow and corresponds to a lower bound of the ratio between out and incoming flows of a unit. The parameter is defined on the relationship class unit__node__node, where the first node (or group of nodes) in this relationship represents the to_node, i.e. the outgoing flow from the unit, and the second node (or group of nodes), represents the from_node, i.e. the incoming flows to the unit. The ratio parameter is interpreted such that it constrains the ratio of out over in, where out is the unit_flow variable from the first node in the unit__node__node relationship in a left-to-right reading order.

To enforce e.g. a minimum ratio of 0.8 for a unit u between its outgoing flows to the node group el_heat (consisting of the two nodes el and heat) and its incoming gas flow from ng the min_ratio_out_in_unit_flow parameter would be set to 0.8 for the relationship u__el_heat__ng.

## min_ratio_out_out_unit_flow

Minimum ratio between two unit_flows going from the unit into the two nodes.

Related Relationship Classes: unit__node__node

The definition of the min_ratio_out_out_unit_flow parameter triggers the generation of the constraint_min_ratio_out_out_unit_flow and enforces a lower bound on the ratio between outgoing flows of a unit. The parameter is defined on the relationship class unit__node__node, where the nodes (or group of nodes) in this relationship represent the to_node's', i.e. outgoing flow from the unit. The ratio parameter is interpreted such that it constrains the ratio of out1 over out2, where out1 is the unit_flow variable from the first node in the unit__node__node relationship in a left-to-right reading order.

To enforce a minimum ratio between two products of a unit u, e.g. setting the minimum share of produced electricity flowing to node el to 0.4 of the production of heat flowing to node heat, the fix_ratio_out_out_unit_flow parameter would be set to 0.4 for the relationship u__el__heat.

## min_res_shutdown_ramp

Minimum non-spinning reserve ramp-down for online units providing reserves during shut-downs

Related Relationship Classes: unit__from_node and unit__to_node

A unit can provide spinning and nonspinning reserves to a reserve node. These reserves can be either upward_reserve or downward_reserve. Nonspinning downward reserves are provided by contracted units holding available to shutdown to a downward_reserve node. If a unit is scheduled to provide nonspinning reserve, a limit on the minimum amount of reserves provided can be imposed by defining the parameter min_res_shutdown_ramp on a unit__to_node relationship, which triggers the constraint on minimum downward nonspinning reserve provision. The parameter min_res_shutdown_ramp is given as a fraction of the unit_capacity of the corresponding unit__to_node relationship.

Note that to include the provision of nonspinning downward reserves, the parameter max_res_shutdown_ramp needs to be defined on the corresponding unit__to_node relationship, which triggers the generation of the variables nonspin_units_shut_down and nonspin_ramp_down_unit_flow.

A detailed description of the usage of ramps and reserves is given in the chapter Ramping and Reserves. The chapter Ramping and reserve constraints in the Mathematical Formulation presents the equations related to ramps and reserves.

## min_res_startup_ramp

Minimum non-spinning reserve ramp-up for offline units scheduled for reserve provision

Related Relationship Classes: unit__from_node and unit__to_node

A unit can provide spinning and nonspinning reserves to a reserve node. These reserves can be either upward_reserve or downward_reserve. Nonspinning upward reserves are provided to an upward_reserve node by contracted offline units holding available to startup. If a unit is scheduled to provide nonspinning reserve, a limit on the minimum amount of reserves provided can be imposed by defining the parameter min_res_startup_ramp on a unit__to_node relationship, which triggers the constraint on minimum upward nonspinning reserve provision. The parameter min_res_startup_ramp is given as a fraction of the unit_capacity of the corresponding unit__to_node relationship.

Note that to include the provision of nonspinning upward reserves, the parameter max_res_startup_ramp needs to be defined on the corresponding unit__to_node relationship, which triggers the generation of the variables nonspin_units_started_up and nonspin_ramp_up_unit_flow.

A detailed description of the usage of ramps and reserves is given in the chapter Ramping and Reserves. The chapter Ramping and reserve constraints in the Mathematical Formulation presents the equations related to ramps and reserves.

## min_shutdown_ramp

Minimum ramp-up during startups

Related Relationship Classes: unit__from_node and unit__to_node

The definition of the min_shutdown_ramp parameter will trigger the creation of the constraint on minimum shutdown ramp. It sets a lower bound on the unit_flow variable for the timestep right before a shutdown.

It can be defined for unit__to_node or unit__from_node relationships, as well as their counterparts for node groups. It will then impose restrictions on the unit_flow variables that indicate flows between the two members of the relationship for which the parameter is defined. The parameter is given as a fraction of the unit_capacity parameter. When the parameter is not included, the aforementioned constraint will not be created, which is equivalent to choosing a value of 0.

## min_startup_ramp

Minimum ramp-up during startups

Related Relationship Classes: unit__from_node and unit__to_node

The definition of the min_startup_ramp parameter will trigger the creation of the constraint on minimum startup ramp. It sets a lower bound on the unit_flow variable for the timestep right after a startup.

It can be defined for unit__to_node or unit__from_node relationships, as well as their counterparts for node groups. It will then impose restrictions on the unit_flow variables that indicate flows between the two members of the relationship for which the parameter is defined. The parameter is given as a fraction of the unit_capacity parameter. When the parameter is not included, the aforementioned constraint will not be created, which is equivalent to choosing a value of 0.

## min_units_on_coefficient_in_in

Optional coefficient for the units_on variable impacting the min_ratio_in_in_unit_flow constraint.

Default value: 0.0

Related Relationship Classes: unit__node__node

The min_units_on_coefficient_in_in parameter is an optional coefficient in the unit input-input ratio constraint controlled by the min_ratio_in_in_unit_flow parameter. Essentially, it acts as a coefficient for the units_on variable in the constraint, allowing for making the minimum conversion ratio dependent on the amount of online capacity.

Note that there are different parameters depending on the directions of the unit_flow variables being constrained: min_units_on_coefficient_in_out, min_units_on_coefficient_out_in, and min_units_on_coefficient_out_out, all of which apply to their respective constraints. Similarly, there are different parameters for setting maximum or fixed conversion rates, e.g. max_units_on_coefficient_in_in and fix_units_on_coefficient_in_in.

## min_units_on_coefficient_in_out

Optional coefficient for the units_on variable impacting the min_ratio_in_out_unit_flow constraint.

Default value: 0.0

Related Relationship Classes: unit__node__node

The min_units_on_coefficient_in_out parameter is an optional coefficient in the unit input-output ratio constraint controlled by the min_ratio_in_out_unit_flow parameter. Essentially, it acts as a coefficient for the units_on variable in the constraint, allowing for making the minimum conversion ratio dependent on the amount of online capacity.

Note that there are different parameters depending on the directions of the unit_flow variables being constrained: min_units_on_coefficient_in_in, min_units_on_coefficient_out_in, and min_units_on_coefficient_out_out, all of which apply to their respective constraints. Similarly, there are different parameters for setting maximum or fixed conversion rates, e.g. max_units_on_coefficient_in_out and fix_units_on_coefficient_in_out.

## min_units_on_coefficient_out_in

Optional coefficient for the units_on variable impacting the min_ratio_out_in_unit_flow constraint.

Default value: 0.0

Related Relationship Classes: unit__node__node

The min_units_on_coefficient_out_in parameter is an optional coefficient in the unit output-input ratio constraint controlled by the min_ratio_out_in_unit_flow parameter. Essentially, it acts as a coefficient for the units_on variable in the constraint, allowing for making the minimum conversion ratio dependent on the amount of online capacity.

Note that there are different parameters depending on the directions of the unit_flow variables being constrained: min_units_on_coefficient_in_in, min_units_on_coefficient_in_out, and min_units_on_coefficient_out_out, all of which apply to their respective constraints. Similarly, there are different parameters for setting maximum or fixed conversion rates, e.g. max_units_on_coefficient_out_in and fix_units_on_coefficient_out_in.

## min_units_on_coefficient_out_out

Optional coefficient for the units_on variable impacting the min_ratio_out_out_unit_flow constraint.

Default value: 0.0

Related Relationship Classes: unit__node__node

The min_units_on_coefficient_out_out parameter is an optional coefficient in the unit output-output ratio constraint controlled by the min_ratio_out_out_unit_flow parameter. Essentially, it acts as a coefficient for the units_on variable in the constraint, allowing for making the minimum conversion ratio dependent on the amount of online capacity.

Note that there are different parameters depending on the directions of the unit_flow variables being constrained: min_units_on_coefficient_in_in, min_units_on_coefficient_in_out, and min_units_on_coefficient_out_in, all of which apply to their respective constraints. Similarly, there are different parameters for setting maximum or fixed conversion rates, e.g. max_units_on_coefficient_out_out and fix_units_on_coefficient_out_out.

## min_up_time

Minimum uptime of a unit after it starts up.

Related Object Classes: unit

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

It can be defined for a unit and will then impose restrictions on the units_on variables that represent the on- or offline status of the unit. The parameter is given as a duration value. When the parameter is not included, the aforementioned constraint will not be created, which is equivalent to choosing a value of 0.

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

## min_voltage_angle

Minimum allowed voltage angle at node.

Related Object Classes: node

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

## minimum_operating_point

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

Related Relationship Classes: unit__from_node and unit__to_node

The definition of the minimum_operating_point parameter will trigger the creation of the Constraint on minimum operating point. It sets a lower bound on the value of the unit_flow variable for a unit that is online.

It can be defined for unit__to_node or unit__from_node relationships, as well as their counterparts for node groups. It will then impose restrictions on the unit_flow variables that indicate flows between the two members of the relationship for which the parameter is defined. The parameter is given as a fraction of the unit_capacity parameter. When the parameter is not included, the aforementioned constraint will not be created, which is equivalent to choosing a value of 0.

## minimum_reserve_activation_time

Duration a certain reserve product needs to be online/available

Related Object Classes: node

The parameter minimum_reserve_activation_time is the duration a reserve product needs to be online, before it can be replaced by another (slower) reserve product.

In SpineOpt, the parameter is used to model reserve provision through storages. If a storage provides reserves to a reserve node (see also is_reserve_node) one needs to ensure that the node state is sufficiently high to provide these scheduled reserves as least for the duration of the minimum_reserve_activation_time. The constraint on the minimum node state with reserve provision is triggered by the existence of the minimum_reserve_activation_time. See also Ramping and Reserves

## model_end

Defines the last timestamp to be modelled. Rolling optimization terminates after passing this point.

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

Related Object Classes: model

Together with the model_start parameter, it is used to define the temporal horizon of the model. In case of a single solve optimization, the parameter marks the end of the last timestep that is possibly part of the optimization. Note that it poses an upper bound, and that the optimization does not necessarily include this timestamp when the block_end parameters are more stringent.

In case of a rolling horizon optimization, it will tell to the model to stop rolling forward once an optimization has been performed for which the result of the indicated timestamp has been kept in the final results. For example, assume that a model_end value of 2030-01-01T05:00:00 has been chosen, a block_end of 3h, and a roll_forward of 2h. The roll_forward parameter indicates here that the results of the first two hours of each optimization window are kept as final, therefore the last optimization window will span the timeframe [2030-01-01T04:00:00 - 2030-01-01T06:00:00].

A DateTime value should be chosen for this parameter.

## model_start

Defines the first timestamp to be modelled. Relative temporal_blocks refer to this value for their start and end.

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

Related Object Classes: model

Together with the model_end parameter, it is used to define the temporal horizon of the model. For a single solve optimization, it marks the timestamp from which the relative offset in a temporal_block is defined by the block_start parameter. In the rolling optimization framework, it does this for the first optimization window.

A DateTime value should be chosen for this parameter.

## model_type

Used to identify model objects as relating to the master problem or operational sub problems (default)

Default value: spineopt_operations

Related Object Classes: model

This parameter is used, generally, to control model dependent functionality and specify model-level parameters for different models. Currently, the main use is to identify the model objects that represent the master and operational sub problems within a decomposed investment problem structure. To trigger the decomposed structure, a model object with model_type=:spineopt_master must exist and another with model_type=:spineopt_operations must also be present. To deactivate the decomposition functionality, the model_type of the master problem can be set to :spineopt_other.

## nodal_balance_sense

A selector for nodal_balance constraint sense.

Default value: ==

Related Object Classes: node

nodal_balance_sense determines whether or not a node is able to naturally consume or produce energy. The default value, ==, means that the node is unable to do any of that, and thus it needs to be perfectly balanced. The vale >= means that the node is a sink, that is, it can consume any amounts of energy. The value <= means that the node is a source, that is, it can produce any amounts of energy.

## node_opf_type

A selector for the reference node (slack bus) when PTDF-based DC load-flow is enabled.

Default value: node_opf_type_normal

Related Object Classes: node

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

## node_slack_penalty

A penalty cost for node_slack_pos and node_slack_neg variables. The slack variables won't be included in the model unless there's a cost defined for them.

Related Object Classes: node

node_slack_penalty triggers the creation of node slack variables, node_slack_pos and node_slack_neg. This allows the model to violate the node_balance constraint with these violations penalised in the objective function with a coefficient equal to node_slack_penalty. If node_slack_penalty = 0 the slack variables are created and violations are unpenalised. If set to none or undefined, the variables are not created and violation of the node_balance constraint is not possible.

## node_state_cap

The maximum permitted value for a node_state variable.

Related Object Classes: node

The node_state_cap parameter represents the maximum allowed value for the node_state variable. Note that in order for a node to have a node_state variable in the first place, the has_state parameter must be set to true. However, if the node has storage investments enabled using the candidate_storages parameter, the node_state_cap parameter acts as a coefficient for the storages_invested_available variable. Essentially, with investments, the node_state_cap parameter represents storage capacity per storage investment.

## node_state_coefficient

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

Default value: 0.0

The node_state_coefficient is an optional parameter that can be used to include the node_state variable of a node in a unit_constraint via the node__unit_constraint relationship. Essentially, node_state_coefficient appears as a coefficient for the node_state variable of the node in the unit constraint.

## node_state_min

The minimum permitted value for a node_state variable.

Default value: 0.0

Related Object Classes: node

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

## number_of_units

Denotes the number of 'sub units' aggregated to form the modelled unit.

Default value: 1.0

Related Object Classes: unit

Defines how many members a certain unit object represents. Typically this parameter takes a binary (UC) or integer (clustered UC) value. Together with the unit_availability_factor, this will determine the maximum number of members that can be online at any given time. (Thus restricting the units_on variable). It is possible to allow the model to increase the number_of_units itself, through Investment Optimization

The default value for this parameter is 1.

## online_variable_type

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

Default value: unit_online_variable_type_linear

Related Object Classes: unit

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

## operating_points

Decomposes the flow variable into a number of separate operating segment variables. Used to in conjunction with unit_incremental_heat_rate and/or unit_constraints

Related Relationship Classes: unit__from_node and unit__to_node

If operating_points is defined as an array type on a certain unit__to_node or unit__from_node flow, the corresponding unit_flow flow variable is decomposed into a number of sub operating segment variables, unit_flow_op one for each operating segment, with an additional index, i to reference the specific operating segment. Each value in the array represents the upper bound of the operating segment, normalized on unit_capacity for the corresponding unit__to_node or unit__from_node flow. operating_points is used in conjunction with unit_incremental_heat_rate where the array dimension must match and is used to define the normalized operating point bounds for the corresponding incremental heat rate. operating_points is also used in conjunction with unit_constraint where the array dimension must match any corresponding piecewise linear unit_flow_coefficient. Here operating_points is used also to define the normalized operating point bounds for the corresponding unit_flow_coefficients.

Note that operating_points is defined on a capacity-normalized basis and the values represent the upper bound of the corresponding operating segment variable. So if operating_points is specified as [0.5, 1], this creates two operating segments, one from zero to 50% of the corresponding unit_capacity and a second from 50% to 100% of the corresponding unit_capacity.

## output_db_url

Database url for SpineOpt output.

Related Object Classes: report

The output_db_url parameter is the url of the databse to write the results of the model run. It overrides the value of the second argument passed to run_spineopt.

## ramp_down_cost

Costs of ramping down

Related Relationship Classes: unit__from_node and unit__to_node

By defining the ramp_down_cost parameter for a specific unit__to_node or unit__from_node relationship, a cost term will be added to the objective function whenever the unit ramps down its activity (i.e., when the ramp_down_unit_flow is nonzero) over the course of its operational dispatch during the current optimization window.

## ramp_down_limit

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

Related Relationship Classes: unit__from_node and unit__to_node

The definition of the ramp_down_limit parameter will trigger the creation of the Constraint on spinning downward ramps. It will limit the maximum decrease in the unit_flow variable between two consecutive timesteps for which the unit is online.

It can be defined for unit__to_node or unit__from_node relationships, as well as their counterparts for node groups. It will then impose restrictions on the unit_flow variables that indicate flows between the two members of the relationship for which the parameter is defined. The parameter is given as a fraction of the unit_capacity parameter. When the parameter is not included, the aforementioned constraint will not be created, which is equivalent to choosing a value of 1.

## ramp_up_cost

Costs of ramping up

Related Relationship Classes: unit__from_node and unit__to_node

By defining the ramp_up_cost parameter for a specific unit__to_node or unit__from_node relationship, a cost term will be added to the objective function whenever the unit ramps up its activity (i.e., when the ramp_up_unit_flow is nonzero) over the course of its operational dispatch during the current optimization window.

## ramp_up_limit

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

Related Relationship Classes: unit__from_node and unit__to_node

The definition of the ramp_up_limit parameter will trigger the creation of the Constraint on spinning upwards ramp_up. It limits the maximum increase in the unit_flow variable between two consecutive timesteps for which the unit is online.

It can be defined for unit__to_node or unit__from_node relationships, as well as their counterparts for node groups. It will then impose restrictions on the unit_flow variables that indicate flows between the two members of the relationship for which the parameter is defined. The parameter is given as a fraction of the unit_capacity parameter. When the parameter is not included, the aforementioned constraint will not be created, which is equivalent to choosing a value of 1.

For a more complete description of how ramping restrictions can be implemented, see Ramping and Reserves.

## representative_periods_mapping

Mapping from real timelices to their corresponding representative days

Related Object Classes: temporal_block

For representative periods with seasonal storages, SpineOpt.jl can be interlinked with the package SpinePeriods.jl. SpinePeriods.jl provides the representative_periods_mapping parameter, which maps each non-representative period of the whole optimization window to its representative temporal_block. The map is organized as timeseries (indicating the start of each the non-representative period) with the names of the representative temporal_blocks as entries.

## reserve_procurement_cost

Procurement cost for reserves

Related Relationship Classes: unit__from_node and unit__to_node

By defining the reserve_procurement_cost parameter for a specific unit__to_node or unit__from_node relationship, a cost term will be added to the objective function whenever that unit is used over the course of the operational dispatch during the current optimization window.

## resolution

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

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

Related Object Classes: temporal_block

This parameter specifies the resolution of the temporal block, or in other words: the length of the timesteps used in the optimization run. Generally speaking, variables and constraints are generated for each timestep of an optimization. For example, the nodal balance constraint must hold for each timestep.

An array of duration values can be used to have a resolution that varies with time itself. It can for example be used when uncertainty in one of the inputs rises as the optimization moves away from the model start. Think of a forecast of for instance wind power generation, which might be available in quarter hourly detail for one day in the future, and in hourly detail for the next two days. It is possible to take a quarter hourly resolution for the full horizon of three days. However, by lowering the temporal resolution after the first day, the computational burden is lowered substantially.

## right_hand_side

The right-hand side, constant term in a unit_constraint. Can be time-dependent and used e.g. for complicated efficiency approximations.

Default value: 0.0

Related Object Classes: unit_constraint

Used to specify the right-hand-side, constant term in a unit_constraint. See also unit_constraint.

## roll_forward

Defines how much the model moves ahead in time between solves in a rolling optimization. Without this parameter, everything is solved in as a single optimization.

Related Object Classes: model

This parameter defines how much the optimization window rolls forward in a rolling horizon optimization and should be expressed as a duration. In a rolling horizon optimization, a (small) part of the model is optimized at each iteration, after which the window rolls forward to optimize a different part. 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.

## shut_down_cost

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

Related Object Classes: unit

By defining the shut_down_cost parameter for a specific unit, a cost term will be added to the objective function whenever this unit shuts down over the course of its operational dispatch during the current optimization window.

## start_up_cost

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

Related Object Classes: unit

By defining the start_up_cost parameter for a specific unit, a cost term will be added to the objective function whenever this unit starts up over the course of its operational dispatch during the current optimization window.

## state_coeff

Represents 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: 0.0

Related Object Classes: node

The state_coeff parameter acts as a coefficient for the node_state variable in the node injection constraint. Essentially, it tells how the node_state variable should be treated in relation to the commodity flows and demand, and can be used for e.g. scaling or unit conversions. For most use-cases a state_coeff parameter value of 1.0 should suffice, e.g. having a MWh storage connected to MW flows in a model with hour as the basic unit of time.

Note that in order for the state_coeff parameter to have an impact, the node must first have a node_state variable to begin with, defined using the has_state parameter. By default, the state_coeff is set to zero as a precaution, so that the user always has to set its value explicitly for it to have an impact on the model.

## stochastic_scenario_end

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

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_investment_cost

Determines the investment cost per unit state_cap over the investment life of a storage

Related Object Classes: node

By defining the storage_investment_cost parameter for a specific node, a cost term will be added to the objective function whenever a storage investment is made during the current optimization window.

## storage_investment_lifetime

Minimum lifetime for storage investment decisions.

Related Object 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_investment_lifetime. Note that storage_investment_lifetime is a dynamic parameter that will impact the amount of solution history that must remain available to the optimisation in each step - this may impact performance.

## storage_investment_variable_type

Determines whether the storage investment variable is continuous (usually representing capacity) or integer (representing discrete units invested)

Default value: variable_type_integer

Related Object Classes: node

Within an investments problem storage_investment_variable_type determines the storage investment decision variable type. Since a node's node_state will be limited to the product of the investment variable and the corresponding node_state_cap and since candidate_storages represents the upper bound of the storage investment decision variable, storage_investment_variable_type thus determines what the investment decision represents. If storage_investment_variable_type is integer or binary, then candidate_storages represents the maximum number of discrete storages that may be invested-in. If storage_investment_variable_type is continuous, candidate_storages is more analagous to a capacity with node_state_cap being analagous to a scaling parameter. For example, if storage_investment_variable_type = integer, candidate_storages = 4 and node_state_cap = 1000 MWh, then the investment decision is how many 1000h MW storages to build. If storage_investment_variable_type = continuous, candidate_storages = 1000 and node_state_cap = 1 MWh, then the investment decision is how much storage capacity to build. Finally, if storage_investment_variable_type = integer, candidate_storages = 10 and node_state_cap = 100 MWh, then the investment decision is how many 100MWh storage blocks to build.

## tax_in_unit_flow

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

Default value: 0.0

Related Object Classes: node

By defining the tax_in_unit_flow parameter for a specific node, a cost term will be added to the objective function to account the taxes associated with all unit_flow variables with direction to_node over the course of the operational dispatch during the current optimization window.

## tax_net_unit_flow

Tax costs for net incoming and outgoing unit_flows on this node. Incoming flows accrue positive net taxes, and outgoing flows accrue negative net taxes.

Default value: 0.0

Related Object Classes: node

By defining the tax_net_unit_flow parameter for a specific node, a cost term will be added to the objective function to account the taxes associated with the net total of all unit_flow variables with the direction to_node for this specific node minus all unit_flow variables with direction from_node.

## tax_out_unit_flow

Tax costs for outgoing unit_flows from this node. E.g. EUR/MWh.

Default value: 0.0

Related Object Classes: node

By defining the tax_out_unit_flow parameter for a specific node, a cost term will be added to the objective function to account the taxes associated with all unit_flow variables with direction from_node over the course of the operational dispatch during the current optimization window.

## unit_availability_factor

Availability of the unit, acting as a multiplier on its unit_capacity. Typically between 0-1.

Default value: 1.0

Related Object Classes: unit

To indicate that a unit is only available to a certain extent or at certain times of the optimization, the unit_availability_factor can be used. A typical use case could be an availability timeseries for a variable renewable energy source. By default the availability factor is set to 1. The availability is, among others, used in the constraint_units_available.

## unit_capacity

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

Related Relationship Classes: unit__from_node and unit__to_node

To set an upper bound on the commodity flow of a unit in a certain direction, the unit_capacity constraint needs to be defined on a unit__to_node or unit__from_node relationship. By defining the parameter, the unit_flow variables to or from a node or a group of nodes will be constrained by the capacity constraint.

Note that if the unit_capacity parameter is defined on a node group, the sum of all unit_flows within the specified node group will be constrained by the unit_capacity.

## unit_conv_cap_to_flow

Optional coefficient for unit_capacity unit conversions in the case the unit_capacity value is incompatible with the desired unit_flow units.

Default value: 1.0

Related Relationship Classes: unit__from_node and unit__to_node

The unit_conv_cap_to_flow, as defined for a unit__to_node or unit__from_node, allows the user to align between unit_flow variables and the unit_capacity parameter, which may be expressed in different units. An example would be when the unit_capacity is expressed in GWh, while the demand on the node is expressed in MWh. In that case, a unit_conv_cap_to_flow parameter of 1000 would be applicable.

## unit_flow_coefficient

Coefficient of a unit_flow variable for a custom unit_constraint.

Default value: 0.0

The unit_flow_coefficient is an optional parameter that can be used to include the unit_flow or unit_flow_op variables from or to a node in a unit_constraint via the unit__from_node__unit_constraint and unit__to_node__unit_constraint relationships. Essentially, unit_flow_coefficient appears as a coefficient for the unit_flow and unit_flow_op variables from or to the node in the unit constraint.

Note that the unit_flow_op variables are a bit of a special case, defined using the operating_points parameter.

## unit_idle_heat_rate

Flow from node1 per unit time and per units_on that results in no additional flow to node2

Default value: 0.0

Related Relationship Classes: unit__node__node

Used to implement the no-load or idle heat rate of a unit. This is the y-axis offset of the heat rate function and is the fuel consumed per unit time when a unit is online and that results in no additional output. This is defined on the unit__node__node relationship and it is assumed that the input flow from node 1 represents fuel consumption and the output flow to node 2 is the elecrical output. While the units depend on the data, unit_idle_heat_rate is generally expressed in GJ/hr. Used in conjunction with unit_incremental_heat_rate. unit_idle_heat_rate is only currently considered if unit_incremental_heat_rate is specified. A trivial unit_incremental_heat_rate of zero can be defined if there is no incremental heat rate.

## unit_incremental_heat_rate

Standard piecewise incremental heat rate where node1 is assumed to be the fuel and node2 is assumed to be electriciy. Assumed monotonically increasing. Array type or single coefficient where the number of coefficients must match the dimensions of unit_operating_points

Related Relationship Classes: unit__node__node

Used to implement simple or piecewise linear incremental heat rate functions. Used in the constraint unit_pw_heat_rate - the input fuel flow at node 1 is the sum of the electrical MW output at node 2 times the incremental heat rate over all heat rate segments, plus the unit_idle_heat_rate. The units are detmerined by the data, but generally, incremental heat rates are given in GJ/MWh. Note that the formulation assumes a convex, monitonically increasing heat rate function. The formulation relies on optimality to load the heat rate segments in the correct order and no additional integer variables are created to enforce the correct loading order. The heat rate segment MW operating points are defined by operating_points.

To implement a simple incremental heat rate function,unit_incremental_heat_rate should be given as a simple scalar representing the incremental heat rate over the entire operating range of the unit. To implement a piecewise linear heat rate function, unit_incremental_heat_rate should be specified as an array type. It is then used in conjunction with the unit parameter operating_points which should also be defined as an array type of equal dimension. When defined as an array type unit_incremental_heat_rate[i] is the effective incremental heat rate between operating_points [i-1] (or zero if i=1) and operating_points[i]. Note that operating_points is defined on a capacity-normalized basis so if operating_points is specified as [0.5, 1], this creates two operating segments, one from zero to 50% of the corresponding unit_capacity and a second from 50% to 100% of the corresponding unit_capacity.

## unit_investment_cost

Investment cost per 'sub unit' built.

Related Object Classes: unit

By defining the unit_investment_cost parameter for a specific unit, a cost term will be added to the objective function whenever a unit investment is made during the current optimization window.

## unit_investment_lifetime

Minimum lifetime for unit investment decisions.

Related Object Classes: 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 unit_investment_lifetime. Note that unit_investment_lifetime is a dynamic parameter that will impact the amount of solution history that must remain available to the optimisation in each step - this may impact performance.

## unit_investment_variable_type

Determines whether investment variable is integer or continuous.

Default value: unit_investment_variable_type_continuous

Related Object Classes: unit

Within an investments problem unit_investment_variable_type determines the unit investment decision variable type. Since the unit_flows will be limited to the product of the investment variable and the corresponding unit_capacity for each unit_flow and since candidate_units represents the upper bound of the investment decision variable, unit_investment_variable_type thus determines what the investment decision represents. If unit_investment_variable_type is integer or binary, then candidate_units represents the maximum number of discrete units that may be invested. If unit_investment_variable_type is continuous, candidate_units is more analagous to a capacity with unit_capacity being analagous to a scaling parameter. For example, if unit_investment_variable_type = integer, candidate_units = 4 and unit_capacity for a particular unit_flow = 400 MW, then the investment decision is how many 400 MW units to build. If unit_investment_variable_type = continuous, candidate_units = 400 and unit_capacity for a particular unit_flow = 1 MW, then the investment decision is how much capacity if this particular unit to build. Finally, if unit_investment_variable_type = integer, candidate_units = 10 and unit_capacity for a particular unit_flow = 50 MW, then the investment decision is many 50MW blocks of capacity of this particular unit to build.

## unit_start_flow

Flow from node1 that is incurred when a unit is started up.

Default value: 0.0

Related Relationship Classes: unit__node__node

Used to implement unit startup fuel consumption where node 1 is assumed to be input fuel and node 2 is assumed to be output elecrical energy. This is a flow from node 1 that is incurred when the value of the variable unitsstartedup is 1 in the corresponding time period. This flow does not result in additional output flow at node 2. Used in conjunction with unit_incremental_heat_rate. unit_start_flow is only currently considered if unit_incremental_heat_rate is specified. A trivial unit_incremental_heat_rate of zero can be defined if there is no incremental heat rate.

## units_on_coefficient

Coefficient of a units_on variable for a custom unit_constraint.

Default value: 0.0

The units_on_coefficient is an optional parameter that can be used to include the units_on variable of a unit in a unit_constraint via the unit__unit_constraint relationship. Essentially, units_on_coefficient appears as a coefficient for the units_on variable of the unit in the unit constraint.

## units_started_up_coefficient

Coefficient of a units_started_up variable for a custom unit_constraint.

Default value: 0.0

The units_started_up_coefficient is an optional parameter that can be used to include the units_started_up variable of a unit in a unit_constraint via the unit__unit_constraint relationship. Essentially, units_started_up_coefficient appears as a coefficient for the units_started_up variable of the unit in the unit constraint.

## upward_reserve

Identifier for nodes providing upward reserves

Default value: false

Related Object Classes: node

If a node has a true is_reserve_node parameter, it will be treated as a reserve node in the model. To define whether the node corresponds to an upward or downward reserve commodity, the upward_reserve or the downward_reserve parameter needs to be set to true, respectively.

## vom_cost

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

Related Relationship Classes: unit__from_node and unit__to_node

By defining the vom_cost parameter for a specific unit, node, and direction, a cost term will be added to the objective function to account for the variable operation and maintenance costs associated with that unit over the course of its operational dispatch during the current optimization window.

## weight

Weighting factor of the temporal block associated with the objective function

Default value: 1.0

Related Object Classes: temporal_block

The weight variable, defined for a temporal_block object can be used to assign different weights to different temporal periods that are modeled. It basically determines how important a certain temporal period is in the total cost, as it enters the Objective function. The main use of this parameter is for representative periods, where each representative period represents a specific fraction of a year or so.

## weight_relative_to_parents

The weight of the stochastic_scenario in the objective function relative to its parents.

Default value: 1.0

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.

## write_lodf_file

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

Default value: false

Related Object Classes: model

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

## write_mps_file

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

Related Object Classes: model

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

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

## write_ptdf_file

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

Default value: false

Related Object Classes: model

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