Reference

ExistingKeyError(msg)

Error indicating that a key is already present. The msg should help specify which key and where.

Internal structure to hold all information of a given asset. It's used internally inside the graph that's inside the TulipaData object.

Main structure to hold all tulipa data.

Internal structure to hold all information of a given Flow. It's used internally inside the graph that's inside the TulipaData object.

_get_select_query_row(schema, key, value, table_name)

Using the schema for table_name,

_validate_schema(schema)

Checks that schema contains the table names required by create_connection. Throws an ArgumentError listing any missing tables if they are absent. This function is for internal use only.

add_asset!(tulipa_data, asset_name, type; kwargs...)

Add a new asset named asset_name of type type with data provided by the keyword arguments. The keywords can be any of the fields in the asset, asset_milestone, asset_commission, and asset_both tables.

For multi-year problems, the data will be propagated for each year, even those yet undefined.

add_asset!(tulipa_data, asset::TulipaAsset)

Add asset to the tulipa data. This version of the function is mostly for internal use, but it is part of the public API.

add_asset_group!(tulipa_data, group_name, year; kwargs...)

Add a new asset group group_name for the given year.

add_flow!(tulipa_data, from_asset_name, to_asset_name; kwargs...)

Add a new flow between the assets named from_asset_name and to_asset_name with data provided by the keyword arguments. The keywords can be any of the fields in the flow, flow_milestone, flow_commission, and flow_both tables.

For multi-year problems, the data will be propagated for each year, even those yet undefined.

add_flow!(tulipa_data, flow::TulipaFlow)

Add flow to the tulipa data. This version of the function is mostly for internal use, but it is part of the public API.

add_or_update_year!(tulipa_data, year; kwargs...)

Add year, or updates its information, using the provided keyword arguments.

attach_both_years_data!(asset::TulipaAsset, commission_year, milestone_year; kwargs...)

Internal version of attach_both_years_data! acting directly on a TulipaAsset object.

attach_both_years_data!(flow::TulipaFlow, commission_year, milestone_year; on_conflict=:overwrite, kwargs...)

Internal version of attach_both_years_data! acting directly on a TulipaFlow object.

attach_both_yeards_data!(tulipa_data, asset_name, commission_year,
    milestone_year; kwargs...)

Set data of the asset named asset_name and the combination of years commission_year and milestone_year provided by the keyword arguments. The keywords must be fields in the asset_both table, or:

• on_conflict: (Default: :overwrite) How to handle key conflicts. Expected values are
  • :error: Raise an ExistingKeyError
  • :overwrite: Replace existing value
  • :skip: Ignore the key

attach_both_years_data!(tulipa_data, from_asset_name, to_asset_name,
    commission_year, milestone_year; kwargs...)

Set data of the flow (from_asset_name, to_asset_name) and the combination of years commission_year and milestone_year provided by the keyword arguments. The keywords must be fields in the flow_both table.

attach_commission_data!(asset::TulipaAsset, year; kwargs...)

Internal version of attach_commission_data! acting directly on a TulipaAsset object.

attach_commission_data!(flow::TulipaFlow, year; on_conflict=:overwrite, kwargs...)

Internal version of attach_commission_data! acting directly on a TulipaFlow object.

attach_commission_data!(tulipa_data, asset_name, year; kwargs...)

Set data of the asset named asset_name and commission year year provided by the keyword arguments. The keywords must be fields in the asset_commission table, or:

• on_conflict: (Default: :overwrite) How to handle key conflicts. Expected values are
  • :error: Raise an ExistingKeyError
  • :overwrite: Replace existing value
  • :skip: Ignore the key

attach_commission_data!(tulipa_data, from_asset_name, to_asset_name, year; kwargs...)

Set data of the flow (from_asset_name, to_asset_name) and commission year year provided by the keyword arguments. The keywords must be fields in the flow_commission table.

attach_milestone_data!(asset::TulipaAsset, year; kwargs...)

Internal version of attach_milestone_data! acting directly on a TulipaAsset object.

attach_milestone_data!(flow::TulipaFlow, year; on_conflict=:overwrite, kwargs...)

Internal version of attach_milestone_data! acting directly on a TulipaFlow object.

attach_milestone_data!(tulipa_data, asset_name, year; kwargs...)

Set data of the asset named asset_name and milestone year year provided by the keyword arguments. The keywords must be fields in the asset_milestone table, or:

• on_conflict: (Default: :overwrite) How to handle key conflicts. Expected values are
  • :error: Raise an ExistingKeyError
  • :overwrite: Replace existing value
  • :skip: Ignore the key

attach_milestone_data!(tulipa_data, from_asset_name, to_asset_name, year; kwargs...)

Set data of the flow (from_asset_name, to_asset_name) and milestone year year provided by the keyword arguments. The keywords must be fields in the flow_milestone table.

attach_profile!(asset::TulipaAsset, profile_type, milestone_year, profile_value; commission_year=milestone_year, scenario=DEFAULT_SCENARIO)

Internal version of attach_profile! acting directly on a TulipaAsset object. The commission_year defaults to milestone_year when not specified.

attach_profile!(flow::TulipaFlow, profile_type, milestone_year, profile_value; commission_year=milestone_year, scenario=DEFAULT_SCENARIO)

Internal version of attach_profile! acting directly on a TulipaFlow object. The commission_year defaults to milestone_year when not specified.

attach_profile!(tulipa_data, from_asset_name, to_asset_name, profile_type, milestone_year, profile_value; commission_year=milestone_year, scenario=DEFAULT_SCENARIO)

Attach the profile vector profile_value to the flow between from_asset_name and to_asset_name of the type profile_type for the milestone_year.

The commission_year defaults to milestone_year. When a different commission_year is given, the profile data is stored for the milestone_year but the flows_profiles table will use the given commission_year.

This will also inform the length of the year using the length of the profile_value.

attach_profile!(tulipa_data, asset_name, profile_type, milestone_year, profile_value; commission_year=milestone_year, scenario=DEFAULT_SCENARIO)

Attach the profile vector profile_value to the asset named asset_name of the type profile_type for the milestone_year.

The commission_year defaults to milestone_year. When a different commission_year is given, the profile data is stored for the milestone_year but the assets_profiles table will use the given commission_year. The commission_year will NOT be marked as a milestone year.

This will also inform the length of the year using the length of the profile_value.

attach_timeframe_profile!(asset::TulipaAsset, profile_type, year, profile_value; scenario=DEFAULT_SCENARIO)

Internal version of attach_timeframe_profile! acting directly on a TulipaAsset object.

attach_timeframe_profile!(tulipa_data, asset_name, profile_type, year, profile_value; scenario=DEFAULT_SCENARIO)

Attach the timeframe profile vector profile_value to the asset named asset_name of the type profile_type for year.

For the definition of timeframes, see the TulipaEnergyModel concepts.

year is registered as a milestone year. The year length is NOT inferred from this profile (use attach_profile! or add_or_update_year! to set it).

create_case_study_csv_folder(connection, schema, case_study_folder; overwrite = true)

Creates the CSV files that correspond to the Tulipa input tables in connection and saves them in the case_study_folder. If overwrite, then the files are overwritten if they exist.

The tables that are exported are the ones that are defined in schema, and the profiles table.

create_connection(tulipa_data, schema)
create_connection(tulipa_data, schema, db)

Creates a DuckDB connection and populates it with the data from tulipa_data.

The schema must be a Dict{String, Dict{String, Dict{String, Any}}} whose top-level keys are TulipaEnergyModel table names. The following table names are required:

• "asset", "asset_both", "asset_commission", "asset_milestone"
• "flow", "flow_both", "flow_commission", "flow_milestone"

Each table entry maps column names to dicts with at least a "type" key and an optional "default" key. This structure matches TulipaEnergyModel.schema (derived from input-schemas.json in TulipaEnergyModel.jl), which is the intended source for this argument.

Throws ArgumentError if any required table name is missing from schema.

If db is not given, a memory connection is created.

create_empty_table_from_schema!(connection, table_name, schema, columns)

Create an empty table with name table_name, overwritting an existing table, if necessary. The table should have the columns specified in columns, and their type and default values are informed by the schema. The schema is expected to be from TulipaEnergyModel for a given table.

This function is for internal use only.

propagate_year_data!(tulipa_data, schema)

Propagates keys from asset to asset_milestone, asset_commission and asset_both, to avoid explicitly attaching a global value.

set_partition!(asset::TulipaAsset, year, rep_period, specification, partition)
set_partition!(asset::TulipaAsset, year, rep_period, partition)

Internal version of set_partition! acting directly on a TulipaAsset object.

set_partition!(flow::TulipaFlow, year, rep_period, specification, partition)
set_partition!(flow::TulipaFlow, year, rep_period, partition)

Internal version of set_partition! acting directly on a TulipaFlow object.

set_partition!(tulipa_data, asset_name, year, rep_period, specification, partition)
set_partition!(tulipa_data, asset_name, year, rep_period, partition)
set_partition!(tulipa_data, from_asset_name, to_asset_name, year, rep_period, specification, partition)
set_partition!(tulipa_data, from_asset_name, to_asset_name, year, rep_period, partition)

Set partition of the asset named asset_name or the flow (from_asset_name, to_asset_name). In both cases, if specification is ommitted, then "uniform" is used.

Notice that the representative period rep_period is expected, even though no other part of the code deals with it, because partitions are tied to clustering. This might change in the future.