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

See also Investment Optimization and storage_investment_variable_type

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

See also Investment Optimization and unit_investment_variable_type

`commodity_lodf_tolerance`

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

Default value:0.1

Related Object Classes:commodity

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

The LODFs are used to model contingencies on some connections and their impact on some other connections. To model contingencies on a connection, set connection_contingency to `true`

; to study the impact of such contingencies on another connection, set connection_monitored to `true`

.

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

`commodity_physics`

Defines if the

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

See also powerflow

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

Related Relationship Classes:connection__from_node and connection__to_node

Defines the upper bound on the corresponding `connection_flow`

variable. If the connection is a candidate connection, the effective `connection_flow`

upper bound is the product of the investment variable, `connections_invested_available`

and `connection_capacity`

. If ptdf based dc load flow is enabled, `connection_capacity`

represents the normal rating of a `connection`

(line) while connection_emergency_capacity represents the maximum post contingency flow.

`connection_contingency`

A boolean flag for defining a contingency

`connection`

.

Related Object Classes:connection

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

= `true`

) for each specified contingency (`connection_contingency`

= `true`

).

See also powerflow

`connection_conv_cap_to_flow`

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

Related Relationship Classes:connection__from_node and connection__to_node

The connection_conv_cap_to_flow can be used to perform the conversion between the measurement unit of the connection_capacity to the measurement unit of the connection_flow variable. The default of this parameter is `1`

, i.e. assuming that both are given in the same measurement unit.

`connection_emergency_capacity`

The maximum post-contingency flow on a monitored

`connection`

.

Related Relationship Classes:connection__from_node and connection__to_node

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

If you set this value, make sure that you also set connection_monitored to `true`

for the involved connection.

`connection_flow_coefficient`

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

Default value:0.0

Related Relationship Classes:connection__from_node__user_constraint and connection__to_node__user_constraint

The connection_flow_coefficient is an optional parameter that can be used to include the connection_flow variable from or to a node in a user_constraint via the connection__from_node__user_constraint and connection__to_node__user_constraint relationships. Essentially, connection_flow_coefficient appears as a coefficient for the connection_flow variable from or to the node in the user constraint.

`connection_flow_cost`

Variable costs of a flow through a

`connection`

. E.g. EUR/MWh of energy throughput.

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`

.

See also powerflow

`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, theta*to is the voltage angle of the remote node and theta*from 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:

- relationship: connection__from_node
- relationship: connection__to_node
- parameter: connection_capacity (defined on connection__from_node and/or connection__to_node)

If `connection_type`

=`:connection_type_lossless_bidirectional`

the following pre-processing actions are taken:

- reciprocal connection__from_node and connection__to_node relationships are created if they don't exist
- a new connection__node__node relationship is created if none exists already
- fix_ratio_out_in_connection_flow parameter is created with the value of 1 if no existing parameter found (therefore this value can be overridden)
- The first connection_capacity parameter found is copied to connection__from_nodes and connection__to_nodes without a defined connection_capacity.

`connections_invested_available_coefficient`

coefficient of

`connections_invested_available`

in the specific`user_constraint`

Default value:0.0

TODO

`connections_invested_coefficient`

coefficient of

`connections_invested`

in the specific`user_constraint`

Default value:0.0

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

`constraint_sense`

A selector for the sense of the

`user_constraint`

.

Default value:==

Related Object Classes:user_constraint

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

See User constraints for details.

`curtailment_cost`

Costs for curtailing generation. Essentially, accrues costs whenever

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

Related Relationship Classes:node__temporal_block

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

`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 user_constraints using the demand_coefficient parameter for the node__user_constraint relationship.

`demand_coefficient`

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

Default value:0.0

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

`diff_coeff`

Commodity diffusion coefficient between two

`nodes`

. Effectively, denotes thediffusion power per unit of statefrom 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

`node`

s 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:hour

Related Object Classes:model

The duration_unit parameter specifies the base unit of time in a model. Two values are currently supported, `hour`

and the default `minute`

. E.g. if the duration_unit is set to `hour`

, a `Duration`

of one `minute`

gets converted into `1/60 hours`

for the calculations.

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

Related Relationship Classes:connection__from_node and connection__to_node

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

`fix_connection_flow`

Fix the value of the

`connection_flow`

variable.

Related Relationship Classes:connection__from_node and connection__to_node

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.

Related Relationship Classes:connection__from_node and connection__to_node

The fix_connection_intact_flow parameter can be used to fix the values of the connection_intact_flow variable to preset values. If set to a `Scalar`

type value, the connection_intact_flow variable is fixed to that value for all time steps and stochastic_scenarios. Values for individual time steps can be fixed using `TimeSeries`

type values.

`fix_connections_invested`

Setting a value fixes the connections_invested variable accordingly

Related Object Classes:connection

The fix_connections_invested parameter can be used to fix the values of the connections_invested variable to preset values. If set to a `Scalar`

type value, the connections_invested variable is fixed to that value for all time steps and stochastic_scenarios. Values for individual time steps can be fixed using `TimeSeries`

type values.

See Investment Optimization for more information about the investment framework in *SpineOpt.jl*.

`fix_connections_invested_available`

Setting a value fixes the connections

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

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

s, 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 `ng`

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

See also Investment Optimization, candidate_storages and storage_investment_variable_type

`fix_storages_invested_available`

Used to fix the value of the storages

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

See also candidate_storages and Investment Optimization

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

See also Investment Optimization, candidate_units and unit_investment_variable_type

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

See also Investment Optimization, candidate_units and unit_investment_variable_type

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

Related Relationship Classes:connection__from_node, connection__to_node, unit__from_node__user_constraint, unit__from_node, unit__to_node__user_constraint and unit__to_node

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

`has_binary_gas_flow`

This parameter needs to be set to

`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

Related Object Classes:commodity, connection, model, node, output, report, stochastic_scenario, stochastic_structure, temporal_block, unit and user_constraint

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

A boolean flag for whether a

`node`

is acting as a non-spinning reserve

Default value:false

Related Object Classes:node

By setting the parameter is_non_spinning to `true`

, a node is treated as a non-spinning reserve node. Note that this is only to differentiate spinning from non-spinning reserves. It is still necessary to define the is_reserve_node to `true`

. reserve node in the model. To define the maximum reserve provision of a non-spinning reserve flow (defined on a unit__to_node relationship), it is also necessary to define the max_res_startup_ramp and the max_res_shutdown_ramp parameters, respectively. It is also possible to define a minimum reserve provision ramp by defining the parameters min_res_startup_ramp and min_res_shutdown_ramp. The mathematical formulation holds a chapter on Ramping and reserve constraints and the general concept of setting up a model with reserves is described in Ramping and Reserves.

`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(z*upper) and lower bound (z*lower) and is defined as 2*(z*upper-z*lower)/(z*upper + z*lower). 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_node`

s, 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_node`

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

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

.

See also Decomposition.

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

See also powerflow.

`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 user constraint.

Default value:0.0

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

`node_state_min`

The minimum permitted value for a

`node_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`user_constraint`

s

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 user_constraint where the array dimension must match any corresponding piecewise linear unit_flow_coefficient. Here `operating_points`

is used also to define the normalized operating point bounds for the corresponding unit_flow_coefficients.

Note that `operating_points`

is defined on a capacity-normalized basis and the values represent the upper bound of the corresponding operating segment variable. So if `operating_points`

is specified as [0.5, 1], this creates two operating segments, one from zero to 50% of the corresponding unit_capacity and a second from 50% to 100% of the corresponding unit_capacity.

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

.

`output_resolution`

Temporal resolution of the output variables assosciated with this

`output`

.

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

Related Object Classes:output

TODO

`overwrite_results_on_rolling`

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

Default value:true

Related Relationship Classes:report__output

The overwrite_results_on_rolling parameter allows one to define whether or not results from further optimisation windows should overwrite those from previous ones. This, of course, is relevant only if optimisation windows overlap, which in turn happens whenever a temporal_block goes beyond the end of the window.

If `true`

(the default) then results are written as a time-series. If `false`

, then results are written as a map from analysis time (i.e., the window start) to time-series.

`ramp_down_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 unit

capacity. [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 unit

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

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

Map from date time to representative temporal block name

Related Object Classes:temporal_block

Specifies the names of temporal_block objects to use as representative periods for certain time ranges. This indicates the model to define operational variables only for those representative periods, and map variables from normal periods to representative ones. The idea behind this is to reduce the size of the problem by using a reduced set of variables, when one knows that some reduced set of time periods can be representative for a larger one.

**Note that only operational variables other than node_state are sensitive to this parameter.** In other words, the model always create `node_state`

variables and investment variables for all time periods, regardless of whether or not `representative_periods_mapping`

is specified for any `temporal_block`

.

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

- Define one
`temporal_block`

for the 'normal' periods as you would do if you weren't using representative periods. - Define a set of
`temporal_block`

objects, each corresponding to one representative period. - Specify
`representative_periods_mapping`

for the 'normal'`temporal_block`

as a*map*, from consecutive date-time values to the name of a representative`temporal_block`

. - Associate all the above
`temporal_block`

objects to elements in your model (e.g., via node__temporal_block and/or units_on__temporal_block relationships), to map their operational variables from normal periods, to the variable from the representative period.

See also Representative days with seasonal storages.

`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

`user_constraint`

. Can be time-dependent and used e.g. for complicated efficiency approximations.

Default value:0.0

Related Object Classes:user_constraint

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

`roll_forward`

Defines how much the model moves ahead in time between solves in a rolling optimization. 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:1.0

Related Object Classes:node

The state_coeff parameter acts as a coefficient for the `node_state`

variable in the node injection constraint. Essentially, it tells how the `node_state`

variable should be treated in relation to the commodity flows and demand, and can be used for e.g. scaling or unit conversions. For most use-cases a state_coeff parameter value of `1.0`

should suffice, e.g. having a MWh storage connected to MW flows in a model with hour as the basic unit of time.

Note that in order for the state_coeff parameter to have an impact, the node must first have a `node_state`

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

`stochastic_scenario_end`

A

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

Related Relationship Classes:stochastic_structure__stochastic_scenario

The stochastic_scenario_end is a `Duration`

-type parameter, defining when a stochastic_scenario ends relative to the start of the current optimization. As it is a parameter for the stochastic_structure__stochastic_scenario relationship, different stochastic_structures can have different values for the same stochastic_scenario, making it possible to define slightly different stochastic_structures using the same stochastic_scenarios. See the Stochastic Framework section for more information about how different stochastic_structures interact in *SpineOpt.jl*.

When a stochastic_scenario ends at the point in time defined by the stochastic_scenario_end parameter, it spawns its children according to the parent_stochastic_scenario__child_stochastic_scenario relationship. Note that the children will be inherently assumed to belong to the same stochastic_structure their parent belonged to, even without explicit stochastic_structure__stochastic_scenario relationships! Thus, you might need to define the weight_relative_to_parents parameter for the children.

If no stochastic_scenario_end is defined, the stochastic_scenario is assumed to go on indefinitely.

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

See also Investment Optimization and candidate_storages

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

See also Investment Optimization and candidate_storages.

`storages_invested_available_coefficient`

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

Default value:0.0

TODO

`storages_invested_coefficient`

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

Default value:0.0

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

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

.

Default value:0.0

Related Relationship Classes:unit__from_node__user_constraint and unit__to_node__user_constraint

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

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

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

See also Investment Optimization and candidate_units

`unit_investment_variable_type`

Determines whether investment variable is integer or continuous.

Default value:unit_investment_variable_type_continuous

Uses Parameter Value Lists:unit_investment_variable_type_list

Related Object Classes:unit

Within an investments problem `unit_investment_variable_type`

determines the unit investment decision variable type. Since the `unit_flow`

s will be limited to the product of the investment variable and the corresponding unit_capacity for each `unit_flow`

and since candidate_units represents the upper bound of the investment decision variable, `unit_investment_variable_type`

thus determines what the investment decision represents. If unit_investment_variable_type is integer or binary, then candidate_units represents the maximum number of discrete units that may be invested. If unit_investment_variable_type is continuous, `candidate_units`

is more analagous to a capacity with unit_capacity being analagous to a scaling parameter. For example, if `unit_investment_variable_type`

= `integer`

, `candidate_units`

= 4 and `unit_capacity`

for a particular `unit_flow`

= 400 MW, then the investment decision is how many 400 MW units to build. If `unit_investment_variable_type`

= continuous, `candidate_units`

= 400 and `unit_capacity`

for a particular `unit_flow`

= 1 MW, then the investment decision is how much capacity if this particular unit to build. Finally, if `unit_investment_variable_type`

= `integer`

, `candidate_units`

= 10 and `unit_capacity`

for a particular `unit_flow`

= 50 MW, then the investment decision is many 50MW blocks of capacity of this particular unit to build.

See also Investment Optimization and candidate_units

`unit_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 units*started*up 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_invested_available_coefficient`

Coefficient of the

`units_invested_available`

variable in the specified`user_constraint`

.

Default value:0.0

TODO

`units_invested_coefficient`

Coefficient of the

`units_invested`

variable in the specified`user_constraint`

.

Default value:0.0

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

`units_on_coefficient`

Coefficient of a

`units_on`

variable for a custom`user_constraint`

.

Default value:0.0

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

`units_on_cost`

Objective function coefficient on

`units_on`

. An idling cost, for example

Related Object Classes:unit

By defining the units_on_cost parameter for a specific `unit`

, a cost term will be added to the objective function whenever this unit is online over the current optimization window. It can be used to represent an idling cost or any fixed cost incurred when a unit is online.

`units_on_non_anticipativity_time`

Period of time where the value of the

`units_on`

variable has to be fixed to the result from the previous window.

Related Object Classes:unit

The units_on_non_anticipativity_time parameter defines the duration, starting from the begining of the optimisation window, where units_on variables need to be fixed to the result of the previous window.

This is intended to model "slow" units whose commitment decision needs to be taken in advance, e.g., in "day-ahead" mode, and cannot be changed afterwards.

`units_started_up_coefficient`

Coefficient of a

`units_started_up`

variable for a custom`user_constraint`

.

Default value:0.0

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

`upward_reserve`

Identifier for

`node`

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

`version`

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

Default value:2

Related Object Classes:settings

TODO

`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

Related Relationship Classes:stochastic_structure__stochastic_scenario

The weight_relative_to_parents parameter defines how much weight the stochastic_scenario gets in the Objective function. As a stochastic_structure__stochastic_scenario relationship parameter, different stochastic_structures can use different weights for the same stochastic_scenario. Note that every stochastic_scenario that appears in the model must have a weight_relative_to_parents defined for it related to the used stochastic_structure! See the Stochastic Framework section for more information about how different stochastic_structures interact in *SpineOpt.jl*.)

Since the Stochastic Framework in *SpineOpt.jl* supports *stochastic directed acyclic graphs* instead of simple *stochastic trees*, it is possible to define stochastic_structures with converging stochastic_scenarios. In these cases, the child stochastic_scenarios inherint the weight of all of their parents, and the final weight that will appear in the Objective function is calculated as shown below:

```
# For root `stochastic_scenarios` (meaning no parents)
weight(scenario) = weight_relative_to_parents(scenario)
# If not a root `stochastic_scenario`
weight(scenario) = sum([weight(parent) * weight_relative_to_parents(scenario)] for parent in parents)
```

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

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