Basics of the model structure

In SpineOpt.jl, the model structure is generated based on the input data, allowing it to be used for a multitude of different problems. Here, we aim to provide you with a basic understanding of the SpineOpt.jl model and data structure, while the Entity Classes, Parameters, and Parameter Value Lists sections provide more in-depth explanations of each concept.

The following sections still use the "legacy" terminology, separating object and relationship classes despite both being Entity Classes.

Introduction to object classes

Essentially, zero-dimensional Entity Classes represent different types of objects that make up the model. For example, every power plant in the model is represented as an object of the object class unit, every power line as an object of the object class connection, and so forth. In order to add any new entity to a model, a new object has to be added to desired object class in the input data.

Each object class has a very specific purpose in SpineOpt.jl, so understanding their differences is key. These can be roughly divided into three distinctive groups, namely Systemic object classes, Structural object classes, and Meta object classes.

Systemic object classes

As the name implies, systemic object classes are used to describe the system to be modelled. Essentially, they define what you want to model. These include:

• connection handles the transfer of commodities between nodes.
• grid represents different networks where different commodities can be generated, consumed, transported, etc.
• node ensures the balance of the commodity flows, and can be used to store commodities as well.
• unit handles the generation and consumption of commodities.

Structural object classes

Structural object classes are used to define the temporal and stochastic structure of the modelled problem, as well as custom User Constraints. Unlike the above Systemic object classes, the structural object classes are more about how you want to model, instead of strictly what you want to model. These include:

• stochastic_scenario represents a different forecast or another type of an alternative time period.
• stochastic_structure acts as a handle for a group of stochastic_scenarios with set properties.
• temporal_block defines a period of time with the desired temporal resolution.
• user_constraint is an optional custom constraint generated based on the input data.

Meta object classes

Meta object classes are used for defining things on the level of models or above, like output and even other models for problem decompositions. These include:

• model represents an individual model, grouping together all the things relevant for itself.
• output defines which Variables are output from the model.
• report groups together multiple output objects.

Introduction to relationship classes

While object_classes define all the objects that make up a model, relationship classes (multidimensional Entity Classes) define how those entities are related to each other. Thus, they hold no meaning on their own, and always include at least one object class.

Similar to object classes, each relationship class has a very specific purpose in SpineOpt.jl, and understanding the purpose of each relationship class is paramount. The relationship classes can be roughly divided into Systemic relationship classes, Structural relationship classes, and Meta relationship classes, again similar to object classes.

Systemic relationship classes

Systemic relationship classes define how Systemic object classes are related to each other, thus helping define the system to be modelled. Most of these relationships deal with which units and connections interact with which nodes, and how those interactions work. This essentially defines the possible commodity flows to be modelled. Systemic relationship classes include:

• connection__from_node defines which node the connection can transfer a commodity from.
• connection__to_node defines which node the connection can transfer a commodity to.
• connection__node__node holds Parameters for connections between two nodes.
• node__grid defines which node is part of which grid.
• node__node holds parameters for direct node-node interactions, like diffusion of commodities.
• node__to_unit defines which node the unit can take an input commodity from.
• unit__to_node defines which node the unit can output a commodity to.
• unit_flow__unit_flow defines parameters between node__to_unit and unit__to_node flows.

Structural relationship classes

Structural relationship classes primarily relate Structural object classes to Systemic object classes, defining what structures the individual parts of the system use. These are mostly used to determine the temporal and stochastic structures to be used in different parts of the modelled system, or custom User Constraints.

SpineOpt.jl has a very flexible temporal and stochastic structure, explained in detail in the Temporal Framework and Stochastic Framework sections of the documentation. Unfortunately, this flexibility requires quite a few different structural relationship classes, the most important of which are the following:

• node__stochastic_structure defines the stochastic_structure used for the node balance.
• node__temporal_block defines the temporal_blocks used for the node balance.
• parent_stochastic_scenario__child_stochastic_scenario defines the stochastic directed acyclic graph (DAG) of the Stochastic Framework.
• stochastic_structure__stochastic_scenario holds parameters for stochastic_scenarios in the stochastic_structure.
• units_on__stochastic_structure defines the stochastic_structure used for the online variable of the unit.
• units_on__temporal_block defines the temporal_blocks used for the online variable of the unit.

Furthermore, there are also a number of advanced structural relationship classes, which are only necessary when using some of the optional features of SpineOpt.jl. For Investment Optimization, the following relationships control the stochastic and temporal structures of the investment variables:

• connection__investment_stochastic_structure defines the stochastic_structure used for the investment Variables for the connection.
• connection__investment_temporal_block defines the temporal_blocks used for the investment Variables for the connection.user_constraint.
• node__investment_stochastic_structure defines the stochastic_structure used for the investment Variables for the node.
• node__investment_temporal_block defines the stochastic_structure used for the investment Variables for the node.
• unit__investment_stochastic_structure defines the stochastic_structure used for the investment Variables for the unit.
• unit__investment_temporal_block defines the temporal_blocks used for the investment Variables for the unit.

For User Constraints, which are essentially generic data-driven custom constraints, the following relationships are used to control which variables are included and with what coefficients:

• connection__from_node__user_constraint holds Parameters for the connection_flow variable from the node in question in the custom user_constraint.
• connection__to_node__user_constraint holds Parameters for the connection_flow variable to the node in question in the custom user_constraint.
• node__user_constraint holds Parameters for the node_state variable in the custom user_constraint.
• unit_flow__user_constraint holds Parameters for the unit_flow variable in the custom user_constraint.

Meta relationship classes

Meta relationship classes are used for defining model-level settings, like which temporal_blocks or stochastic_structures are active, and what the model output is. These include:

• model__default_investment_stochastic_structure defines a default stochastic_structure to be used for investment Variables when no other definitions exist.
• model__default_investment_temporal_block defines a default temporal_block to be used for investment Variables when no other definitions exist.
• model__default_stochastic_structure defines a default stochastic_structure to be used for nodes and units when no other definitions exist.
• model__default_temporal_block defines a default temporal_block to be used for nodes and units when no other definitions exist.
• model__report connects each report to the desired model.
• report__output defines which outputs are part of which report.

Introduction to parameters

While the primary function of Entity Classes (both object and relationship classes) is to define the system to be modelled and its structure, Parameters exist to constrain them. Every parameter is attributed to at least one object class or relationship class, but some appear in many classes whenever they serve a similar purpose.

Parameters accept different types of values depending on their purpose, e.g. whether they act as a flag for some specific functionality or appear as a coefficient in Constraints, so understanding each parameter is key. Most coefficient-type Parameters accept constant, time series, and even stochastic time series form input, but there are some exceptions. Most flag-type Parameters, on the other hand, have a restricted list of acceptable values defined by their Parameter Value Lists.

The existence of some Constraints is controlled based on if the relevant Parameters are defined. As a rule-of-thumb, a constraint only gets generated if at least one of the Parameters appearing in it is defined, but one should refer to the appropriate Constraints and Parameters sections when in doubt.

Introduction to groups of objects

Groups of objects are used within SpineOpt for different purposes. To create a group of objects, simply right-click the corresponding Entity Classes in the Spine Toolbox database editor and select Add object group. Groups are essentially special objects, that act as a single handle for all of its members.

On the one hand, groups can be used in order to impose constraints on the aggregation of a variable, e.g. on the sum of multiple unit_flow variables. Constraints based on parameters associated with the unit_flow__unit_flow, unit__to_node, node__to_unit, connection__node__node, connection__to_node, connection__from_node can generally be used for this kind of flow aggregation by defining the parameters on groups of objects, typically node groups. (with the exception of variable fixing parameters, e.g. flow_limits_fix etc.). See for instance constraint_unit_flow_capacity.

On the other hand, a node group can be used to for PTDF based powerflows. Here a node group is used to enforce a nodal balance on system level, while suppressing the node balances at individual nodes. See also balance_type and the node balance constraint.