Simple cases/convenience of missing info

[abelsiqueira]

This question can be framed as "What is the minimum amount of info that can be passed to TEM and still allow an energy model to be created with reasonable, sensible defaults?"

Here, reasonable, sensible defaults in the sense that there is no surprise: When the user does not set some optional value, their expectation of what happens and what actually happens match.

In user words, it could be "Oh, I did not realise this was an option, so I did not use this option, but it worked exactly as I would expect".

In more details:

• If there is no timeframe profiles, do users need to give an empty table? Does it make sense to silently ignore that this table is missing, or should be error and say that we need this table.
• Same for various partitions. If the user does not provide any partition information (table does not exist), does it make sense to use hourly silently?

What existing metadata should be optional?

[datejada]

I will list the minimum amount of parameter values in the asset and flow files that a user needs to run the model and suggest some defaults if there is no data in this issue later.

Regarding the other timeframe and partition files. A beginner user might not want/know how to use these files, so to make it easy, if they don't provide the file, we should create a default empty table to continue internally. This means that the profiles will be assumed to have default values (i.e., 1.0 p.u. for availabilities and 0.0 p.u. for inflows) and that the model runs in the representative period resolution (i.e., which by default will be 1, so hourly).

They can provide the file and then use it in their pipeline as they get more expertise.

[abelsiqueira]

Just thought about missing clustering information. Since we're going to have a dummy clustering, does it make sense to have something working if all rep-period information is missing? Technically it can work, but does it make sense? Or should be user explicitly call dummy clustering?

[datejada]

On second thought, the answer is that it doesn't make sense to don't have the rep-period information. At least there should be an explicit call to the dummy clustering.

I'm worried about a person using only TEM who does not know that they need to run TulipaClustering to get a call dummy. So, how can we tackle that? documentation? in the code?...

[abelsiqueira]

Looking at the DB diagram (😉), the clustering part is just

• RepPeriod (the short table with description of the rep periods)
• RepPeriodProfile (the clustered Profile table, with a column for rep_period)
• TimeframePeriod (the current mapping table, that describes per period (timeframe_period?) how much (weight) of the rep_period there is.

So the dummy clustering is (assuming N periods in the original time horizon, N = 365 * 24 in most cases)

• Create 1 entry in RepPeriod with num_timesteps = N
• Add a column to Profile to create RepPeriodProfile with rep_period = 1
• Add N entries to TimeframePeriod with period = k, rep_period=1 and weight = 1.0.

(I think, @greg-neustroev can correct me. My mind whispered N entries with num_timesteps = 1, but that would break most constraints, right?)

In that case, the "dummy" case is pretty simple to create without loading TulipaClustering.
We could create an argument to create_input_dataframes and EnergyProblem called use_hourly_resolution and treat that case there.

Also, documentation.

[datejada]

For the assets-data.csv file:

Parameter	Origin of Data	Default	Comment
name	ESDL/COMPETES	N.A.	Minimum requirement
type	ESDL/COMPETES	N.A.	The minimum requirement is one producer and one consumer
active	Scenario	TRUE	we don't use this value yet
investable	Scenario	FALSE
investment_integer	Scenario	FALSE
investment_cost	ESDL/COMPETES	0
investment_limit	ESDL/COMPETES	0
capacity	ESDL/COMPETES	0
initial_capacity	ESDL/COMPETES	N.A.**	**minimum requirement for all assets except hubs and consumers, which can use default of 0.0
peak_demand	ESDL/COMPETES	N.A.**	**minimum requirement for consumers, all the other asset types can use a default of 0.0
consumer_balance_sense	Scenario	==
is_seasonal	Scenario	FALSE
storage_inflows	ESDL/COMPETES	0
initial_storage_capacity	ESDL/COMPETES	N.A.**	**minimum requirement for storage assets, all the other asset types can use a default of 0.0
initial_storage_level	ESDL/COMPETES	0
energy_to_power_ratio	ESDL/COMPETES	0
storage_method_energy	Scenario	FALSE
investment_cost_storage_energy	ESDL/COMPETES	0
investment_limit_storage_energy	ESDL/COMPETES	0
capacity_storage_energy	ESDL/COMPETES	0
investment_integer_storage_energy	Scenario	FALSE
use_binary_storage_method	Scenario	FALSE
max_energy_timeframe_partition	Scenario	FALSE
min_energy_timeframe_partition	Scenario	FALSE

[abelsiqueira]

cc. @suvayu

[datejada]

For the flows-data.csv file:

Parameter	Origin of Data	Default	Comment
carrier	ESDL/COMPETES	N.A.	we don't use this column yet
from_asset	ESDL/COMPETES	N.A.	minimum requirement from a producer
to_asset	Scenario	N.A.	minimum requirement to a consumer
active	Scenario	TRUE	we don't use this column yet
is_transport	Scenario	FALSE
investable	Scenario	FALSE
investment_integer	Scenario	FALSE
variable_cost	ESDL/COMPETES	0
investment_cost	ESDL/COMPETES	0
investment_limit	ESDL/COMPETES	0
capacity	ESDL/COMPETES	0
initial_export_capacity	ESDL/COMPETES	0
initial_import_capacity	ESDL/COMPETES	0
efficiency	ESDL/COMPETES	1

[datejada]

To complete the minimal data for a run in the model the user will need information in the files: rep-periods-data.csv and rep-periods-mapping.csv. These files should be created in the TulipaClustering (I'm not sure, but I think they are...otherwise, we need to make an issue there), but just in case the default values of these files should be:

For the rep-periods-data.csv file:

Parameter	Origin of Data	Default	Comment
rep_period	TulipaClustering	1
num_timesteps	TulipaClustering	1
resolution	TulipaClustering	1

For the rep-periods-mapping.csv file:

Parameter	Origin of Data	Default	Comment
period	TulipaClustering	1
rep_period	TulipaClustering	1
weight	TulipaClustering	1

[clizbe]

@suvayu This might be relevant for your ESDL checks. https://github.com/TulipaEnergy/esdl4tulipa/issues/5

[suvayu]

IIUC, this is not something we expect to read from ESDL. This is more like configuration or options related to building the model. ESDL only has asset and flow related info. Maybe things like period, or resolution is derived from the profiles read from ESDL, but thats part of post-processing.

[clizbe]

I meant more the table @datejada posted that says for instance that a minimum requirement for a consumer is a "to_asset."