Large number of TS

[Poncelet88]

Hi,

When setting up a model with a high to very high number of TS, I'm running into some problems.

I want to enter the demand load profile as follows:

~FI_T: COM_FR
CommName	Demand	TS_1	TS_2	TS_3
*Demand Commodity Name	Demand Value	Load Curve by time slice
ELCDEM	288.9797

However, excel 97 is limited in the number of columns in a worksheet (256 = max). To prevent this, I tried to copy the data to a excel 2010 file (which allows a much larger number of columns), but when I do this, VEDA-FE indicates that the file is missing.

Is VEDA-FE only capable of reading excel 97 files? If so, is there a way I could enter the profile in a different way (e.g. different rows instead of columns for each data entry)?

[Poncelet88]

Ok, so after rebooting the computer, this was no longer a problem.

[AKanudia]

thanks for the update.

when you have a large number of timeslices, you might be better off using an INS table. Or DINS, if you can avoid wild cards and commas.

VFE does support XLSX files, and this will be quite robust starting from version 4.3.65 (expected to be released this week).

[Antti-L]

I hope it supports XLSB files equally well, too? They load and save faster....

[Poncelet88]

Thank you for the responses.

Amit, what do you mean with "being better off using an INS table". In what aspect would this be better?

I have created 3 versions of a model, which only differ in the number of TS (and the way the original input data is aggregated into these TS). The model focuses on the generation side of the electricity system and is quite small, containing 6 periods, 10 commodities 27 processes. 

Solving the first 2 versions of the model, with respectively 12 TS and 288 TS did not cause any problems.

However, the third versions, which operated with 8736 TS (52 weeks/year, 7 days/week, 24h/day) causes problems. I expected that solving this might become tricky. However, I'm getting into trouble even before trying to solve this model. When synchronizing, VEDA-FE gives the error statement "7 Out of Memory" after 2 seconds.

Is there a way to avoid this error? I expect that reading in this data should still be possible?

[AKanudia]

First of all, you should avoid creating tables that are too wide. Normally we are far more comfortable with vertical scrolling than horizontal. Even in FI_T tables, you can use a column "TimeSlice" in the index region (under or to the left of ~FI_T tag), to create a vertical table.

I suggested INS/DINS because they are read more efficiently compared to FI_T.

How many columns does your table have in the version that throws the "out of memory" error?

[Poncelet88]

Thank you for clearing this out. I will change it to INS table and see if this changes anything.

The out of memory error occurs in when processing the BYT, in which the COM_FR is specified for 8736 different TS (listed in different columns).

[Poncelet88]

I have no luck with entering the demand profile into a TFM~INS table.

I first tried to insert it into a ~FI_T table, and this gave no problem.

When inserting the following table in the BYT, no information can be found on ELCDEM in the TIMES view. Note that I tested this for the scenario with only 12 TS.

~TFM_INS
TimeSlice	Attribute	Year	AllRegions	BE	Pset_Set	Pset_PN	Cset_Set	Cset_CN
	COM_PROJ	2014		288.9825709				ELCDEM
WIDay	COM_FR	2014		0.190855778				ELCDEM
WIPeak	COM_FR	2014		0.025751537				ELCDEM
WINight	COM_FR	2014		0.06175635				ELCDEM
SPDay	COM_FR	2014		0.164667443				ELCDEM
SPPeak	COM_FR	2014		0.020647485				ELCDEM
SPNight	COM_FR	2014		0.055253649				ELCDEM
SUDay	COM_FR	2014		0.154691943				ELCDEM
SUPeak	COM_FR	2014		0.01945323				ELCDEM
SUNight	COM_FR	2014		0.051175128				ELCDEM
FADay	COM_FR	2014		0.176824294				ELCDEM
FAPeak	COM_FR	2014		0.023599257				ELCDEM
FANight	COM_FR	2014		0.055323907				ELCDEM

[AKanudia]

The table looks good. just move it to the BY Trans file.

[Poncelet88]

Good news. The problem has disappeared. I'm not sure why (changing the data entry had no effect on the error), but the error suddenly disappeared today.

I was even more surprised that it solved the model with 8736 TS from the first time (in about 1000sec).