Posts: 20
Threads: 5
Likes Received: 0 in 0 posts
Likes Given: 0
Joined: May 2021
Hi Everyone,
When Times generates the timeslice dd file, the order that the timeslices appear is not the same as the one we defined in the SysSettings.
We have reorganized them in the order we defined in the dd file, and the results are the same as the original way TIMES has ordered them.
What happens is: We define in the SysSettings
Season (R S F W)
Daynite (h01 .. h24)
The order we expected is:
ANNUAL
R
S
F
W
Rh01
...
Rh24
Sh01
...
Wh24
But instead, it shows like:
ANNUAL
R
S
F
W
Rh01
Rh02
Rh03
Rh04
Rh05
Rh06
Rh07
Rh08
Rh09
Rh10
Sh01
Rh11
Sh02
Rh12
Rh13
Sh03
Rh14
Sh04
Rh15
Sh05
Sh06
Rh16
Rh17
Sh07
Sh08
Rh18
Rh19
Sh09
Rh20
Sh10
Rh21
...
We have seen no problem with the results, but I want to investigate why this happens.
Anyone has faced anything like this ? Could this be a problem ?
Thank you for your attention.
Posts: 2,010
Threads: 26
Likes Received: 80 in 69 posts
Likes Given: 26
Joined: Jun 2010
I think this is a valid VEDA-related question. Yes, I would like to stress that it is VEDA-related, because the discrepancy you see in the timeslice order is not at all generated by TIMES, but it is solely coming from VEDA.
TIMES respects the timeslice order exactly as it is defined in the timeslice dd file (which is generated by VEDA). The order of the timeslices is very important for correct model results, especially with respect to storage, but also dispatching and unit commitment modelling.
However, the correct order is important only for the timeslices under each parent timeslice. For example, the seasons under the ANNUAL timeslice must be in the correct order, and on the DAYNITE level, the hourly (or the 2-hourly, minutely, or whatever) timeslices under each parent must be in the correct order.
Looking at the timeslice order in your post, it seems the correct order, as described above, is indeed preserved, although the discrepancy with your SysSettings definition is confusing. I have myself been similarly confused in the past, but then I have verified that the correct order is being maintained after all. So, I think there is nothing to worry about, apart from the seemingly random, unexplained aspects in the VEDA-generated ordering.
Posts: 20
Threads: 5
Likes Received: 0 in 0 posts
Likes Given: 0
Joined: May 2021
(16-07-2021, 03:18 AM)Antti-L Wrote: I think this is a valid VEDA-related question. Yes, I would like to stress that it is VEDA-related, because the discrepancy you see in the timeslice order is not at all generated by TIMES, but it is solely coming from VEDA.
TIMES respects the timeslice order exactly as it is defined in the timeslice dd file (which is generated by VEDA). The order of the timeslices is very important for correct model results, especially with respect to storage, but also dispatching and unit commitment modelling.
However, the correct order is important only for the timeslices under each parent timeslice. For example, the seasons under the ANNUAL timeslice must be in the correct order, and on the DAYNITE level, the hourly (or the 2-hourly, minutely, or whatever) timeslices under each parent must be in the correct order.
Looking at the timeslice order in your post, it seems the correct order, as described above, is indeed preserved, although the discrepancy with your SysSettings definition is confusing. I have myself been similarly confused in the past, but then I have verified that the correct order is being maintained after all. So, I think there is nothing to worry about, apart from the seemingly random, unexplained aspects in the VEDA-generated ordering.
Thank very much Antti for your clarification. Indeed, I was worried how it could affect the storage processes outputs as I just started to model them.
