# 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__unit_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 unit_constraint

Related Parameters:connection_flow_coefficient

`connection__from_node__unit_constraint`

is a three-dimensional relationship between a connection, a node and a unit_constraint. The relationship specifies that the `connection_flow`

variable to the specified connection from the specified node is involved in the specified unit_constraint. Parameters on this relationship generally apply to this specific `connection_flow`

variable. For example the parameter connection_flow_coefficient defined on `connection__from_node__unit_constraint`

represents the coefficient on the specific `connection_flow`

variable in the specified unit_constraint

`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_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__unit_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 unit_constraint

Related Parameters:connection_flow_coefficient

`connection__to_node__unit_constraint`

is a three-dimensional relationship between a connection, a node and a unit_constraint. The relationship specifies that the `connection_flow`

variable from the specified connection to the specified node is involved in the specified unit_constraint. Parameters on this relationship generally apply to this specific `connection_flow`

variable. For example the parameter connection_flow_coefficient defined on `connection__to_node__unit_constraint`

represents the coefficient on the specific `connection_flow`

variable in the specified unit_constraint

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

s are included in which`model`

s.

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

s are included in which`model`

s.

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:

- To specify that specific network physics should apply to the network formed by the member nodes for that commodity. See powerflow
- 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__unit_constraint`

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

Related Object Classes:node and unit_constraint

Related Parameters:demand_coefficient and node_state_coefficient

`node__unit_constraint`

is a two-dimensional relationship between a node and a unit_constraint. The relationship specifies that a variable associated only with the node (currently only the `node_state`

) is involved in the constraint. For example, the node_state_coefficient defined on `node__unit_constraint`

specifies the coefficient of the node's `node_state`

variable in the specified unit_constraint.

See also unit_constraint

`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

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

Defines which input

`unit_flows`

are included in the`unit_constraint`

, and holds their parameters.

Related Object Classes:node, unit_constraint and unit

Related Parameters:graph_view_position and unit_flow_coefficient

`unit__from_node__unit_constraint`

is a three-dimensional relationship between a unit, a node and a unit_constraint. The relationship specifies that the `unit_flow`

variable to the specified unit from the specified node is involved in the specified unit_constraint. Parameters on this relationship generally apply to this specific `unit_flow`

variable. For example the parameter unit_flow_coefficient defined on `unit__from_node__unit_constraint`

represents the coefficient on the specific `unit_flow`

variable in the specified unit_constraint

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

Defines which output

`unit_flows`

are included in the`unit_constraint`

, and holds their parameters.

Related Object Classes:node, unit_constraint and unit

Related Parameters:graph_view_position and unit_flow_coefficient

`unit__to_node__unit_constraint`

is a three-dimensional relationship between a unit, a node and a unit_constraint. The relationship specifies that the `unit_flow`

variable from the specified unit to the specified node is involved in the specified unit_constraint. Parameters on this relationship generally apply to this specific `unit_flow`

variable. For example the parameter unit_flow_coefficient defined on `unit__to_node__unit_constraint`

represents the coefficient on the specific `unit_flow`

variable in the specified unit_constraint

`unit__unit_constraint`

Defines which

`units_on`

variables are included in the`unit_constraint`

, and holds their parameters.

Related Object Classes:unit_constraint and unit

Related Parameters:units_on_coefficient and units_started_up_coefficient

`unit__unit_constraint`

is a two-dimensional relationship between a unit and a unit_constraint. The relationship specifies that a variable or variable(s) associated only with the unit (not a `unit_flow`

for example) are involved in the constraint. For example, the units_on_coefficient defined on `unit__unit_constraint`

specifies the coefficient of the unit's `units_on`

variable in the specified unit_constraint.

See also unit_constraint

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