Relationship Classes

connection__from_node

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

Related Object Classes: connection and node

Related Parameters: connection_capacity, connection_conv_cap_to_flow, connection_emergency_capacity, fix_binary_gas_connection_flow, fix_connection_flow, fix_connection_intact_flow and graph_view_position

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

connection__from_node__user_constraint

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

Related Object Classes: connection, node and user_constraint

Related Parameters: connection_flow_coefficient

TODO

connection__investment_stochastic_structure

Defines the stochastic structure of the connections investments variable

Related Object Classes: connection and stochastic_structure

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

The connection__investment_stochastic_structure relationship uses the model__default_investment_stochastic_structure relationship if not defined.

connection__investment_temporal_block

Defines the temporal resolution of the connections investments variable

Related Object Classes: connection and temporal_block

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

See also Investment Optimization

connection__node__node

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

Related Object Classes: connection and node

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

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

connection__to_node

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

Related Object Classes: connection and node

Related Parameters: connection_capacity, connection_conv_cap_to_flow, connection_emergency_capacity, fix_binary_gas_connection_flow, fix_connection_flow, fix_connection_intact_flow and graph_view_position

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

connection__to_node__user_constraint

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

Related Object Classes: connection, node and user_constraint

Related Parameters: connection_flow_coefficient

TODO

connection__user_constraint

Relationship required to involve a connections investment variables in a user_constraint

Related Object Classes: connection and user_constraint

Related Parameters: connections_invested_available_coefficient and connections_invested_coefficient

TODO

model__default_investment_stochastic_structure

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

Related Object Classes: model and stochastic_structure

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

model__default_investment_temporal_block

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

Related Object Classes: model and temporal_block

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

See also Investment Optimization

model__default_stochastic_structure

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

Related Object Classes: model and stochastic_structure

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

model__default_temporal_block

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

Related Object Classes: model and temporal_block

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

model__report

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

Related Object Classes: model and report

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

model__stochastic_structure

Defines which stochastic_structures are included in which models.

Related Object Classes: model and stochastic_structure

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

model__temporal_block

Defines which temporal_blocks are included in which models.

Related Object Classes: model and temporal_block

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

node__commodity

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

Related Object Classes: commodity and node

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

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

node__investment_stochastic_structure

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

Related Object Classes: node and stochastic_structure

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

The node__investment_stochastic_structure relationship uses the model__default_investment_stochastic_structure relationship if not defined.

node__investment_temporal_block

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

Related Object Classes: node and temporal_block

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

See also Investment Optimization

node__node

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

Related Object Classes: node

Related Parameters: diff_coeff

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

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

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

node__stochastic_structure

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

Related Object Classes: node and stochastic_structure

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

The node__stochastic_structure relationship uses the model__default_stochastic_structure relationship if not specified.

node__temporal_block

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

Related Object Classes: node and temporal_block

Related Parameters: cyclic_condition

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

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

node__user_constraint

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

Related Object Classes: node and user_constraint

Related Parameters: demand_coefficient, node_state_coefficient, storages_invested_available_coefficient and storages_invested_coefficient

TODO

parent_stochastic_scenario__child_stochastic_scenario

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

Related Object Classes: stochastic_scenario

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

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

report__output

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

Related Object Classes: output and report

Related Parameters: overwrite_results_on_rolling

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

stochastic_structure__stochastic_scenario

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

Related Object Classes: stochastic_scenario and stochastic_structure

Related Parameters: stochastic_scenario_end and weight_relative_to_parents

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

unit__commodity

Holds parameters for commodities used by the unit.

Related Object Classes: commodity and unit

Related Parameters: max_cum_in_unit_flow_bound

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

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

unit__from_node

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

Related Object Classes: node and unit

Related Parameters: fix_nonspin_ramp_up_unit_flow, fix_nonspin_units_started_up, fix_ramp_up_unit_flow, fix_start_up_unit_flow, fix_unit_flow_op, fix_unit_flow, fuel_cost, graph_view_position, max_res_shutdown_ramp, max_res_startup_ramp, max_shutdown_ramp, max_startup_ramp, min_res_shutdown_ramp, min_res_startup_ramp, min_shutdown_ramp, min_startup_ramp, minimum_operating_point, operating_points, ramp_down_cost, ramp_down_limit, ramp_up_cost, ramp_up_limit, reserve_procurement_cost, unit_capacity, unit_conv_cap_to_flow and vom_cost

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

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

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

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

unit__from_node__user_constraint

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

Related Object Classes: node, unit and user_constraint

Related Parameters: graph_view_position and unit_flow_coefficient

TODO

unit__investment_stochastic_structure

Sets the stochastic structure for investment decisions - overrides model__default_investment_stochastic_structure.

Related Object Classes: stochastic_structure and unit

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

The unit__investment_stochastic_structure relationship uses the model__default_investment_stochastic_structure relationship if not defined.

unit__investment_temporal_block

Sets the temporal resolution of investment decisions - overrides model__default_investment_temporal_block

Related Object Classes: temporal_block and unit

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

See also Investment Optimization

unit__node__node

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

Related Object Classes: node and unit

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

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

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

unit__to_node

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

Related Object Classes: node and unit

Related Parameters: fix_nonspin_ramp_down_unit_flow, fix_nonspin_ramp_up_unit_flow, fix_nonspin_units_shut_down, fix_nonspin_units_started_up, fix_ramp_down_unit_flow, fix_ramp_up_unit_flow, fix_shut_down_unit_flow, fix_start_up_unit_flow, fix_unit_flow_op, fix_unit_flow, fuel_cost, graph_view_position, max_res_shutdown_ramp, max_res_startup_ramp, max_shutdown_ramp, max_startup_ramp, min_res_shutdown_ramp, min_res_startup_ramp, min_shutdown_ramp, min_startup_ramp, minimum_operating_point, operating_points, ramp_down_cost, ramp_down_limit, ramp_up_cost, ramp_up_limit, reserve_procurement_cost, unit_capacity, unit_conv_cap_to_flow and vom_cost

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

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

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

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

unit__to_node__user_constraint

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

Related Object Classes: node, unit and user_constraint

Related Parameters: graph_view_position and unit_flow_coefficient

TODO

unit__user_constraint

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

Related Object Classes: unit and user_constraint

Related Parameters: units_invested_available_coefficient, units_invested_coefficient, units_on_coefficient and units_started_up_coefficient

TODO

units_on__stochastic_structure

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

Related Object Classes: stochastic_structure and unit

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

The units_on__stochastic_structure relationship uses the model__default_stochastic_structure relationship if not specified.

units_on__temporal_block

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

Related Object Classes: temporal_block and unit

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