A quick question about day-by-day connectiveness

[[email protected]]

Hi,


I’m considering adding a weekly resolution to improve the temporal granularity of my model (which currently only includes seasonal and hourly time slices). However, I have a question regarding the structure of the TIMES framework:

Even if I introduce more representative days (e.g. one per week), these days are not inherently linked across time—unless additional constraints are introduced. What is the recommended approach if I want to capture day-by-day variations and ensure temporal continuity between consecutive days?

Best,
Xiao

[Antti-L]

> I’m considering adding a weekly resolution to improve the temporal granularity of my model (which currently only includes seasonal and hourly time slices).

If you currently have seasonal timeslices and then a representative day for each season, you currently have explicit temporal connectivity between the consecutive hours within each day, and between the consecutive seasons within each year. But you also have implicit temporal connectivity between consecutive days within each season, in the sense that within each season all days are assumed to be equal to each other, and DAYNITE storage works consistently with that assumption: the storage level at the end of each day is passed correctly to the beginning of the next day, because the DAYNITE timeslices under each season are assumed to form a cycle. However, this implicit connectivity cannot directly connect the hourly timeslices between seasons.  Seasonal connectivity is thus only accomplished at the SEASON level, whereby the hourly timeslices between seasons are connected only through seasonal storage (including the seasonal storage pool of general storage). The linkage between individual days in successive seasons can thus only account for the average time difference between those seasons.

In the above, I was describing only the linkages inherent to the timeslice tree concept of TIMES (without additional constraints). By introducing additional constraints one could of course have more linkages.

> if I introduce more representative days (e.g. one per week), these days are not inherently linked across time—unless additional constraints are introduced.

Can you elaborate in more detail why you say so?  I think it is obvious that they are linked across time (e.g. through storage processes and dispatching constraints), in the ways described above.

> What is the recommended approach if I want to capture day-by-day variations and ensure temporal continuity between consecutive days?

As explained above, in the representative day approach temporal continuity is, in fact, implicitly ensured between consecutive days. But if you want to capture day-by-day variations, that is not possible by using representative days. I would recommend using, for example, a representative week (168 hours) instead.  With such a week, you could capture day-by-day variations within the representative week of each season, and you would have implicit temporal continuity between successive weeks in each season. A representative week might be a reasonable choice for the modeling of e.g. electric vehicles more realistically, because the charging patterns may be much better captured with a weekly cycle compared to a much shorter daily cycle.  With 4 seasons the total number of finest level timeslices would be 672 (assuming one would want to use hourly timeslices), which could still be workable for a long term model.

[[email protected]]

> I’m considering adding a weekly resolution to improve the temporal granularity of my model (which currently only includes seasonal and hourly time slices).

If you currently have seasonal timeslices and then a representative day for each season, you currently have explicit temporal connectivity between the consecutive hours within each day, and between the consecutive seasons within each year. But you also have implicit temporal connectivity between consecutive days within each season, in the sense that within each season all days are assumed to be equal to each other, and DAYNITE storage works consistently with that assumption: the storage level at the end of each day is passed correctly to the beginning of the next day, because the DAYNITE timeslices under each season are assumed to form a cycle. However, this implicit connectivity cannot directly connect the hourly timeslices between seasons.  Seasonal connectivity is thus only accomplished at the SEASON level, whereby the hourly timeslices between seasons are connected only through seasonal storage (including the seasonal storage pool of general storage). The linkage between individual days in successive seasons can thus only account for the average time difference between those seasons.

In the above, I was describing only the linkages inherent to the timeslice tree concept of TIMES (without additional constraints). By introducing additional constraints one could of course have more linkages.

> if I introduce more representative days (e.g. one per week), these days are not inherently linked across time—unless additional constraints are introduced.

Can you elaborate in more detail why you say so?  I think it is obvious that they are linked across time (e.g. through storage processes and dispatching constraints), in the ways described above.

> What is the recommended approach if I want to capture day-by-day variations and ensure temporal continuity between consecutive days?

As explained above, in the representative day approach temporal continuity is, in fact, implicitly ensured between consecutive days. But if you want to capture day-by-day variations, that is not possible by using representative days. I would recommend using, for example, a representative week (168 hours) instead.  With such a week, you could capture day-by-day variations within the representative week of each season, and you would have implicit temporal continuity between successive weeks in each season. A representative week might be a reasonable choice for the modeling of e.g. electric vehicles more realistically, because the charging patterns may be much better captured with a weekly cycle compared to a much shorter daily cycle.  With 4 seasons the total number of finest level timeslices would be 672 (assuming one would want to use hourly timeslices), which could still be workable for a long term model.

Hi Antti,

Many thanks! Yes, week-split-to-hour maybe a better option but the same thing: the system only sees intra-week variation (e.g., weekday/weekend patterns), not variation across multiple weeks [week-by-week variations]. 

I assume multiple representative weeks per season is also possible in TIMES model? 

Best,
Xiao

[Antti-L]

> I assume multiple representative weeks per season is also possible in TIMES model?

Yes of course.  One could of course even go to a 8760 hours' representative year as well, but I have noticed that the performance of the GAMS code is degrading notably when going above 4000 timeslices.