How to Use

How to Use

The connection should have been created and the data loaded into it using TulipaIO. See the tutorials for a complete guide on how to achieve this. The output_folder is optional if the user wants to export the output.

Input

Currently, we only accept input from CSV files that follow the Schemas. You can also check the test/inputs folder for examples.

CSV Files

Below, we have a description of the files. At the end, in Schemas, we have the expected columns in these CSVs.

Tip: If you modify CSV files and want to see your modifications, the normal git diff command will not be informative. Instead, you can use
git diff --word-diff-regex="[^[:space:],]+"
to make git treat the , as word separators. You can also compare two CSV files with
git diff --no-index --word-diff-regex="[^[:space:],]+" file1 file2

`graph-assets-data.csv`

This file contains the list of assets and the static data associated with each of them.

The meaning of Missing data depends on the parameter, for instance:

group: No group assigned to the asset.

`graph-flows-data.csv`

The same as graph-assets-data.csv, but for flows. Each flow is defined as a pair of assets.

`assets-data.csv`

This file contains the yearly data of each asset.

The investment parameters are as follows:

The investable parameter determines whether there is an investment decision for the asset or flow.
The investment_integer parameter determines if the investment decision is integer or continuous.
The investment_cost parameter represents the cost in the defined timeframe. Thus, if the timeframe is a year, the investment cost is the annualized cost of the asset.
The investment_limit parameter limits the total investment capacity of the asset or flow. This limit represents the potential of that particular asset or flow. Without data in this parameter, the model assumes no investment limit.

The meaning of Missing data depends on the parameter, for instance:

investment_limit: There is no investment limit.
initial_storage_level: The initial storage level is free (between the storage level limits), meaning that the optimization problem decides the best starting point for the storage asset. In addition, the first and last time blocks in a representative period are linked to create continuity in the storage level.

`flows-data.csv`

The same as assets-data.csv, but for flows. Each flow is defined as a pair of assets.

The meaning of Missing data depends on the parameter, for instance:

investment_limit: There is no investment limit.

`assets-profiles.csv`

These files contain information about assets and their associated profiles. Each row lists an asset, the type of profile (e.g., availability, demand, maximum or minimum storage level), and the profile's name. These profiles are used in the intra-temporal constraints.

`flows-profiles.csv`

This file contains information about flows and their representative period profiles for intra-temporal constraints. Each flow is defined as a pair of assets.

`rep-periods-data.csv`

Describes the representative periods by their unique ID, the number of timesteps per representative period, and the resolution per timestep. Note that in the test files the resolution units are given as hours for understandability, but the resolution is technically unitless.

`rep-periods-mapping.csv`

Describes the periods of the timeframe that map into a representative period and the weight of the representative periods that construct a period. Note that each weight is a decimal between 0 and 1, and that the sum of weights for a given period must also be between 0 and 1 (but do not have to sum to 1).

`profiles-rep-periods.csv`

Define all the profiles for the rep-periods. The profile_name is a unique identifier, the period and value define the profile, and the rep_period field informs the representative period.

The profiles are linked to assets and flows in the files assets-profiles, assets-timeframe-profiles, and flows-profiles.

`assets-timeframe-profiles.csv`

Like the assets-profiles.csv, but for the inter-temporal constraints.

`groups-data.csv` (optional)

This file contains the list of groups and the methods that apply to each group, along with their respective parameters.

`profiles-timeframe.csv` (optional)

Define all the profiles for the timeframe. This is similar to the profiles-rep-periods.csv except that it doesn't have a rep-period field and if this is not passed, default values are used in the timeframe constraints.

`assets-rep-periods-partitions.csv` (optional)

Contains a description of the partition for each asset with respect to representative periods. If not specified, each asset will have the same time resolution as the representative period, which is hourly by default.

There are currently three ways to specify the desired resolution, indicated in the column specification. The column partition serves to define the partitions in the specified style.

specification = uniform: Set the resolution to a uniform amount, i.e., a time block is made of X timesteps. The number X is defined in the column partition. The number of timesteps in the representative period must be divisible by X.
specification = explicit: Set the resolution according to a list of numbers separated by ; on the partition. Each number in the list is the number of timesteps for that time block. For instance, 2;3;4 means that there are three time blocks, the first has 2 timesteps, the second has 3 timesteps, and the last has 4 timesteps. The sum of the list must be equal to the total number of timesteps in that representative period, as specified in num_timesteps of rep-periods-data.csv.
specification = math: Similar to explicit, but using + and x for simplification. The value of partition is a sequence of elements of the form NxT separated by +, indicating N time blocks of length T. For instance, 2x3+3x6 is 2 time blocks of 3 timesteps, followed by 3 time blocks of 6 timesteps, for a total of 24 timesteps in the representative period.

The table below shows various results for different formats for a representative period with 12 timesteps.

Time Block	:uniform	:explicit	:math
1:3, 4:6, 7:9, 10:12	3	3;3;3;3	4x3
1:4, 5:8, 9:12	4	4;4;4	3x4
1:1, 2:2, …, 12:12	1	1;1;1;1;1;1;1;1;1;1;1;1	12x1
1:3, 4:6, 7:10, 11:12	NA	3;3;4;2	2x3+1x4+1x2

Note: If an asset is not specified in this file, the balance equation will be written in the lowest resolution of both the incoming and outgoing flows to the asset.

`flows-rep-periods-partitions.csv` (optional)

The same as assets-rep-periods-partitions.csv, but for flows.

If a flow is not specified in this file, the flow time resolution will be for each timestep by default (e.g., hourly).

`assets-timeframe-partitions.csv` (optional)

The same as their assets-rep-periods-partitions.csv counterpart, but for the periods in the timeframe of the model.

Schemas

assets_data
- name: VARCHAR
- active: BOOLEAN
- year: INTEGER
- commission_year: INTEGER
- investable: BOOLEAN
- investment_integer: BOOLEAN
- investment_limit: DOUBLE
- initial_units: DOUBLE
- peak_demand: DOUBLE
- consumer_balance_sense: VARCHAR
- is_seasonal: BOOLEAN
- storage_inflows: DOUBLE
- initial_storage_units: DOUBLE
- initial_storage_level: DOUBLE
- energy_to_power_ratio: DOUBLE
- storage_method_energy: BOOLEAN
- investment_limit_storage_energy: DOUBLE
- investment_integer_storage_energy: BOOLEAN
- use_binary_storage_method: VARCHAR
- max_energy_timeframe_partition: DOUBLE
- min_energy_timeframe_partition: DOUBLE
- unit_commitment: BOOLEAN
- unit_commitment_method: VARCHAR
- units_on_cost: DOUBLE
- unit_commitment_integer: BOOLEAN
- min_operating_point: DOUBLE
- ramping: BOOLEAN
- max_ramp_up: DOUBLE
- max_ramp_down: DOUBLE
assets_profiles
- asset: VARCHAR
- commission_year: INTEGER
- profile_type: VARCHAR
- profile_name: VARCHAR
assets_rep_periods_partitions
- asset: VARCHAR
- year: INTEGER
- rep_period: INTEGER
- specification: VARCHAR
- partition: VARCHAR
assets_timeframe_partitions
- asset: VARCHAR
- year: INTEGER
- specification: VARCHAR
- partition: VARCHAR
assets_timeframe_profiles
- asset: VARCHAR
- commission_year: INTEGER
- profile_type: VARCHAR
- profile_name: VARCHAR
flows_data
- from_asset: VARCHAR
- to_asset: VARCHAR
- year: INTEGER
- active: BOOLEAN
- investable: BOOLEAN
- investment_integer: BOOLEAN
- variable_cost: DOUBLE
- investment_limit: DOUBLE
- initial_export_units: DOUBLE
- initial_import_units: DOUBLE
- efficiency: DOUBLE
flows_profiles
- from_asset: VARCHAR
- to_asset: VARCHAR
- year: INTEGER
- profile_type: VARCHAR
- profile_name: VARCHAR
flows_rep_periods_partitions
- from_asset: VARCHAR
- to_asset: VARCHAR
- year: INTEGER
- rep_period: INTEGER
- specification: VARCHAR
- partition: VARCHAR
graph_assets_data
- name: VARCHAR
- type: VARCHAR
- group: VARCHAR
- investment_method: VARCHAR
- capacity: DOUBLE
- technical_lifetime: INTEGER
- economic_lifetime: INTEGER
- discount_rate: DOUBLE
- capacity_storage_energy: DOUBLE
graph_flows_data
- from_asset: VARCHAR
- to_asset: VARCHAR
- carrier: VARCHAR
- is_transport: BOOLEAN
- capacity: DOUBLE
- technical_lifetime: INTEGER
- economic_lifetime: INTEGER
- discount_rate: DOUBLE
groups_data
- name: VARCHAR
- year: INTEGER
- invest_method: BOOLEAN
- min_investment_limit: DOUBLE
- max_investment_limit: DOUBLE
profiles_rep_periods
- profile_name: VARCHAR
- year: INTEGER
- rep_period: INTEGER
- timestep: INTEGER
- value: DOUBLE
profiles_timeframe
- profile_name: VARCHAR
- year: INTEGER
- period: INTEGER
- value: DOUBLE
rep_periods_data
- year: INTEGER
- rep_period: INTEGER
- num_timesteps: INTEGER
- resolution: DOUBLE
rep_periods_mapping
- year: INTEGER
- period: INTEGER
- rep_period: INTEGER
- weight: DOUBLE
vintage_assets_data
- name: VARCHAR
- commission_year: INTEGER
- fixed_cost: DOUBLE
- investment_cost: DOUBLE
- fixed_cost_storage_energy: DOUBLE
- investment_cost_storage_energy: DOUBLE
vintage_flows_data
- from_asset: VARCHAR
- to_asset: VARCHAR
- commission_year: INTEGER
- fixed_cost: DOUBLE
- investment_cost: DOUBLE
year_data
- year: INTEGER
- length: INTEGER
- is_milestone: BOOLEAN

Structures

The list of relevant structures used in this package are listed below:

EnergyProblem

The EnergyProblem structure is a wrapper around various other relevant structures. It hides the complexity behind the energy problem, making the usage more friendly, although more verbose.

Fields

graph: The Graph object that defines the geometry of the energy problem.
representative_periods: A vector of Representative Periods.
constraints_partitions: Dictionaries that connect pairs of asset and representative periods to time partitions (vectors of time blocks).
timeframe: The number of periods in the representative_periods.
dataframes: A Dictionary of dataframes used to linearize the variables and constraints. These are used internally in the model only.
groups: A vector of Groups.
model: A JuMP.Model object representing the optimization model.
solution: A structure of the variable values (investments, flows, etc) in the solution.
solved: A boolean indicating whether the model has been solved or not.
objective_value: The objective value of the solved problem (Float64).
termination_status: The termination status of the optimization model.
time_read_data: Time taken (in seconds) for reading the data (Float64).
time_create_model: Time taken (in seconds) for creating the model (Float64).
time_solve_model: Time taken (in seconds) for solving the model (Float64).

Constructor

The EnergyProblem can also be constructed using the minimal constructor below.

EnergyProblem(connection): Constructs a new EnergyProblem object with the given connection that has been created and the data loaded into it using TulipaIO. The graph, representative_periods, and timeframe are computed using create_internal_structures. The constraints_partitions field is computed from the representative_periods, and the other fields are initialized with default values.

See the basic example tutorial to see how these can be used.

Graph

The energy problem is defined using a graph. Each vertex is an asset, and each edge is a flow.

We use MetaGraphsNext.jl to define the graph and its objects. Using MetaGraphsNext we can define a graph with metadata, i.e., associate data with each asset and flow. Furthermore, we can define the labels of each asset as keys to access the elements of the graph. The assets in the graph are of type GraphAssetData, and the flows are of type GraphFlowData.

The graph can be created using the create_internal_structures function, or it can be accessed from an EnergyProblem.

See how to use the graph in the graph tutorial.

GraphAssetData

This structure holds all the information of a given asset. These are stored inside the Graph. Given a graph graph, an asset a can be accessed through graph[a].

GraphFlowData

This structure holds all the information of a given flow. These are stored inside the Graph. Given a graph graph, a flow from asset u to asset v can be accessed through graph[u, v].

Partition

A representative period will be defined with a number of timesteps. A partition is a division of these timesteps into time blocks such that the time blocks are disjunct (not overlapping) and that all timesteps belong to some time block. Some variables and constraints are defined over every time block in a partition.

For instance, for a representative period with 12 timesteps, all sets below are partitions:

\[\{\{1, 2, 3\}, \{4, 5, 6\}, \{7, 8, 9\}, \{10, 11, 12\}\}\]
\[\{\{1, 2, 3, 4\}, \{5, 6, 7, 8\}, \{9, 10, 11, 12\}\}\]
\[\{\{1\}, \{2, 3\}, \{4\}, \{5, 6, 7, 8\}, \{9, 10, 11, 12\}\}\]

Timeframe

The timeframe is the total period we want to analyze with the model. Usually this is a year, but it can be any length of time. A timeframe has two fields:

num_periods: The timeframe is defined by a certain number of periods. For instance, a year can be defined by 365 periods, each describing a day.
map_periods_to_rp: Indicates the periods of the timeframe that map into a representative period and the weight of the representative period to construct that period.

Representative Periods

The timeframe (e.g., a full year) is described by a selection of representative periods, for instance, days or weeks, that nicely summarize other similar periods. For example, we could model the year into 3 days, by clustering all days of the year into 3 representative days. Each one of these days is called a representative period. TulipaEnergyModel.jl has the flexibility to consider representative periods of different lengths for the same timeframe (e.g., a year can be represented by a set of 4 days and 2 weeks). To obtain the representative periods, we recommend using TulipaClustering.

A representative period has three fields:

weight: Indicates how many representative periods are contained in the timeframe; this is inferred automatically from map_periods_to_rp in the timeframe.
timesteps: The number of timesteps blocks in the representative period.
resolution: The duration in time of each timestep.

The number of timesteps and resolution work together to define the coarseness of the period. Nothing is defined outside of these timesteps; for instance, if the representative period represents a day and you want to specify a variable or constraint with a coarseness of 30 minutes. You need to define the number of timesteps to 48 and the resolution to 0.5.

Solution

The solution object energy_problem.solution is a mutable struct with the following fields:

assets_investment[a]: The investment for each asset, indexed on the investable asset a.
flows_investment[u, v]: The investment for each flow, indexed on the investable flow (u, v).
storage_level_intra_rp[a, rp, timesteps_block]: The storage level for the storage asset a within (intra) a representative period rp and a time block timesteps_block. The list of time blocks is defined by constraints_partitions, which was used to create the model.
storage_level_inter_rp[a, periods_block]: The storage level for the storage asset a between (inter) representative periods in the periods block periods_block.
flow[(u, v), rp, timesteps_block]: The flow value for a given flow (u, v) at a given representative period rp, and time block timesteps_block. The list of time blocks is defined by graph[(u, v)].partitions[rp].
objective_value: A Float64 with the objective value at the solution.
duals: A Dictionary containing the dual variables of selected constraints.

Check the tutorial for tips on manipulating the solution.

Time Blocks

A time block is a range for which a variable or constraint is defined. It is a range of numbers, i.e., all integer numbers inside an interval. Time blocks are used for the periods in the timeframe and the timesteps in the representative period. Time blocks are disjunct (not overlapping), but do not have to be sequential.

Group

This structure holds all the information of a given group with the following fields:

name: The name of the group.
invest_method: Boolean value to indicate whether or not the group has an investment method.
min_investment_limit: A minimum investment limit in MW is imposed on the total investments of the assets belonging to the group.
max_investment_limit: A maximum investment limit in MW is imposed on the total investments of the assets belonging to the group.

Exploring infeasibility

If your model is infeasible, you can try exploring the infeasibility with JuMP.compute_conflict! and JuMP.copy_conflict.

Note: Not all solvers support this functionality.

Use energy_problem.model for the model argument. For instance:

if energy_problem.termination_status == INFEASIBLE
 compute_conflict!(energy_problem.model)
 iis_model, reference_map = copy_conflict(energy_problem.model)
 print(iis_model)
end

Storage specific setups

Seasonal and non-seasonal storage

Section Storage Modeling explains the main concepts for modeling seasonal and non-seasonal storage in TulipaEnergyModel.jl. To define if an asset is one type or the other then consider the following:

Seasonal storage: When the storage capacity of an asset is greater than the total length of representative periods, we recommend using the inter-temporal constraints. To apply these constraints, you must set the input parameter is_seasonal to true in the assets-data.csv.
Non-seasonal storage: When the storage capacity of an asset is lower than the total length of representative periods, we recommend using the intra-temporal constraints. To apply these constraints, you must set the input parameter is_seasonal to false in the assets-data.csv.

Note: If the input data covers only one representative period for the entire year, for example, with 8760-hour timesteps, and you have a monthly hydropower plant, then you should set the is_seasonal parameter for that asset to false. This is because the length of the representative period is greater than the storage capacity of the storage asset.

The energy storage investment method

Energy storage assets have a unique characteristic wherein the investment is based not solely on the capacity to charge and discharge, but also on the energy capacity. Some storage asset types have a fixed duration for a given capacity, which means that there is a predefined ratio between energy and power. For instance, a battery of 10MW/unit and 4h duration implies that the energy capacity is 40MWh. Conversely, other storage asset types don't have a fixed ratio between the investment of capacity and storage capacity. Therefore, the energy capacity can be optimized independently of the capacity investment, such as hydrogen storage in salt caverns. To define if an energy asset is one type or the other then consider the following parameter setting in the file assets-data.csv:

Investment energy method: To use this method, set the parameter storage_method_energy to true. In addition, it is necessary to define:
- investment_cost_storage_energy: To establish the cost of investing in the storage capacity (e.g., kEUR/MWh/unit).
- fixed_cost_storage_energy: To establish the fixed cost of energy storage capacity (e.g., kEUR/MWh/unit).
- investment_limit_storage_energy: To define the potential of the energy capacity investment (e.g., MWh). Missing values mean that there is no limit.
- investment_integer_storage_energy: To determine whether the investment variables of storage capacity are integers of continuous.
Fixed energy-to-power ratio method: To use this method, set the parameter storage_method_energy to false. In addition, it is necessary to define the parameter energy_to_power_ratio to establish the predefined duration of the storage asset or ratio between energy and power. Note that all the investment costs should be allocated in the parameter investment_cost.

In addition, the parameter capacity_storage_energy in the graph-assets-data.csv defines the energy per unit of storage capacity invested in (e.g., MWh/unit).

For more details on the constraints that apply when selecting one method or the other, please visit the mathematical formulation section.

Control simultaneous charging and discharging

Depending on the configuration of the energy storage assets, it may or may not be possible to charge and discharge them simultaneously. For instance, a single battery cannot charge and discharge at the same time, but some pumped hydro storage technologies have separate components for charging (pump) and discharging (turbine) that can function independently, allowing them to charge and discharge simultaneously. To account for these differences, the model provides users with three options for the use_binary_storage_method parameter in the assets-data.csv file:

binary: the model adds a binary variable to prevent charging and discharging simultaneously.
relaxed_binary: the model adds a binary variable that allows values between 0 and 1, reducing the likelihood of charging and discharging simultaneously. This option uses a tighter set of constraints close to the convex hull of the full formulation, resulting in fewer instances of simultaneous charging and discharging in the results.
If no value is set, i.e., missing value, the storage asset can charge and discharge simultaneously.

For more details on the constraints that apply when selecting this method, please visit the mathematical formulation section.

Setting up unit commitment constraints

The unit commitment constraints are only applied to producer and conversion assets. The unit_commitment parameter must be set to true to include the constraints in the assets-data.csv. Additionally, the following parameters should be set in that same file:

unit_commitment_method: It determines which unit commitment method to use. The current version of the code only includes the basic version. Future versions will add more detailed constraints as additional options.
units_on_cost: Objective function coefficient on units_on variable. (e.g., no-load cost or idling cost in kEUR/h/unit)
unit_commitment_integer: It determines whether the unit commitment variables are considered as integer or not (true or false)
min_operating_point: Minimum operating point or minimum stable generation level defined as a portion of the capacity of asset (p.u.)

For more details on the constraints that apply when selecting this method, please visit the mathematical formulation section.

Setting up ramping constraints

The ramping constraints are only applied to producer and conversion assets. The ramping parameter must be set to true to include the constraints in the assets-data.csv. Additionally, the following parameters should be set in that same file:

max_ramp_up: Maximum ramping up rate as a portion of the capacity of asset (p.u./h)
max_ramp_down:Maximum ramping down rate as a portion of the capacity of asset (p.u./h)

For more details on the constraints that apply when selecting this method, please visit the mathematical formulation section.

Setting up a maximum or minimum outgoing energy limit

For the model to add constraints for a maximum or minimum energy limit for an asset throughout the model's timeframe (e.g., a year), we need to establish a couple of parameters:

is_seasonal = true in the assets-data.csv. This parameter enables the model to use the inter-temporal constraints.
max_energy_timeframe_partition $\neq$ missing or min_energy_timeframe_partition $\neq$ missing in the assets-data.csv. This value represents the peak energy that will be then multiplied by the profile for each period in the timeframe.
Note: These parameters are defined per period, and the default values for profiles are 1.0 p.u. per period. If the periods are determined daily, the energy limit for the whole year will be 365 times maxor min_energy_timeframe_partition.
(optional) profile_type and profile_name in the assets-timeframe-profiles.csv and the profile values in the profiles-timeframe.csv. If there is no profile defined, then by default it is 1.0 p.u. for all periods in the timeframe.
(optional) define a period partition in assets-timeframe-partitions.csv. If there is no partition defined, then by default the constraint is created for each period in the timeframe, otherwise, it will consider the partition definition in the file.

Tip: If you want to set a limit on the maximum or minimum outgoing energy for a year with representative days, you can use the partition definition to create a single partition for the entire year to combine the profile.

Example: Setting Energy Limits

Let's assume we have a year divided into 365 days because we are using days as periods in the representatives from TulipaClustering.jl. Also, we define the max_energy_timeframe_partition = 10 MWh, meaning the peak energy we want to have is 10MWh for each period or period partition. So depending on the optional information, we can have:

Profile	Period Partitions	Example
None	None	The default profile is 1.p.u. for each period and since there are no period partitions, the constraints will be for each period (i.e., daily). So the outgoing energy of the asset for each day must be less than or equal to 10MWh.
Defined	None	The profile definition and value will be in the `assets-timeframe-profiles.csv` and `profiles-timeframe.csv` files. For example, we define a profile that has the following first four values: 0.6 p.u., 1.0 p.u., 0.8 p.u., and 0.4 p.u. There are no period partitions, so constraints will be for each period (i.e., daily). Therefore the outgoing energy of the asset for the first four days must be less than or equal to 6MWh, 10MWh, 8MWh, and 4MWh.
Defined	Defined	Using the same profile as above, we now define a period partition in the `assets-timeframe-partitions.csv` file as `uniform` with a value of 2. This value means that we will aggregate every two periods (i.e., every two days). So, instead of having 365 constraints, we will have 183 constraints (182 every two days and one last constraint of 1 day). Then the profile is aggregated with the sum of the values inside the periods within the partition. Thus, the outgoing energy of the asset for the first two partitions (i.e., every two days) must be less than or equal to 16MWh and 12MWh, respectively.

Defining a group of assets

A group of assets refers to a set of assets that share certain constraints. For example, the investments of a group of assets may be capped at a maximum value, which represents the potential of a specific area that is restricted in terms of the maximum allowable MW due to limitations on building licenses.

In order to define the groups in the model, the following steps are necessary:

Create a group in the groups-data.csv file by defining the name property and its parameters.
In the file graph-assets-data.csv, assign assets to the group by setting the name in the group parameter/column.
Note: A missing value in the parameter group in the graph-assets-data.csv means that the asset does not belong to any group.

Groups are useful to represent several common constraints, the following group constraints are available.

Setting up a maximum or minimum investment limit for a group

The mathematical formulation of the maximum and minimum investment limit for group constraints is available here. The parameters to set up these constraints in the model are in the groups-data.csv file.

invest_method = true. This parameter enables the model to use the investment group constraints.
min_investment_limit $\neq$ missing or max_investment_limit $\neq$ missing. This value represents the limits that will be imposed on the investment that belongs to the group.
Notes:
1. A missing value in the parameters min_investment_limit and max_investment_limit means that there is no investment limit.
2. These constraints are applied to the investments each year. The model does not yet have investment limits to a group's accumulated invested capacity.

Example: Group of Assets

Let's explore how the groups are set up in the test case called Norse. First, let's take a look at the groups-data.csv file:

2×5 DataFrame

Row	name	year	invest_method	min_investment_limit	max_investment_limit
	String15	Int64	Bool	Int64?	Int64?
1	renewables	2030	true	missing	40000
2	ccgt	2030	true	10000	missing

In the given data, there are two groups: renewables and ccgt. Both groups have the invest_method parameter set to true, indicating that investment group constraints apply to both. For the renewables group, the min_investment_limit parameter is missing, signifying that there is no minimum limit imposed on the group. However, the max_investment_limit parameter is set to 40000 MW, indicating that the total investments of assets in the group must be less than or equal to this value. In contrast, the ccgt group has a missing value in the max_investment_limit parameter, indicating no maximum limit, while the min_investment_limit is set to 10000 MW for the total investments in that group.

Let's now explore which assets are in each group. To do so, we can take a look at the graph-assets-data.csv file:

4×3 DataFrame

Row	name	type	group
	String31	String15	String15?
1	Asgard_Solar	producer	renewables
2	Asgard_CCGT	conversion	ccgt
3	Midgard_Wind	producer	renewables
4	Midgard_CCGT	conversion	ccgt

Here we can see that the assets Asgard_Solar and Midgard_Wind belong to the renewables group, while the assets Asgard_CCGT and Midgard_CCGT belong to the ccgt group.

Note: If the group has a min_investment_limit, then assets in the group have to allow investment (investable = true) for the model to be feasible. If the assets are not investable then they cannot satisfy the minimum constraint.