Running selected weeks without scaling to full year

[IdaGJ]

Hi all,
 
I am trying to configure a very detailed TIMES model that we have been running with 8760 time slices. Now I want to look at a specific week of the year to test how the system reacts under more stress than the default assumptions on e.g. demand profiles and capacity availability.
 
Ideally, I want to see the results for this week only, meaning that I would not want to see the results scaled to the full year. Is that possible? And which parameters would I need to change to get the results unscaled?
 
Some more details of my model:
- Time slices: 168 time slices under DAYNITE level (Weekly and season is blank)
- COM_FR: Setting COM_FR = demand in timeslice / demand for full year
 
I have tested different settings of YRFR and TS_CYCLE but either I am trying the wrong settings or that is not enough.
 
Thanks in advance for your help,

Ida

[Antti-L]

Thank you for an interesting question. However, I am not fully following what you are exactly wishing.  Can you elaborate on what you mean by "I would not want to see the results scaled to the full year.".  What exactly do you mean by this scaling of results to the full year?

Anyway, TIMES has basically been designed to work with full years only, because e.g. optimizing investments would not make much sense if you have only one week represented in the model. Therefore, if using only a timeslice cycle representing one week, TIMES assumes that there are 52 weeks in a year that are identical to that one week, because then the optimization of investments and capacities would make sense.

But maybe you are not interested in any capacity optimization when looking at one week?

You can, of course, define one week as the only DAYNITE cycle as you have done.  By default, however, any DAYNITE cycle is assumed to be a representative day, and therefore, if you just have 168 DAYNITE timeslices under ANNUAL, that cycle is by default assumed to be repeated 365 times, meaning that each of those 168 timeslices represents only 514 seconds.  To make them each represent one hour instead, you would need to define TS_CYCLE(r,ANNUAL) = 7 (i.e. the length of the cycle under ANNUAL is 7 days or one week). Of course, the demands in this case would need to be the one week's demand multiplied by 365/7. Have you already tried that, and can you clarify what are the "scaling issues" you encounter when doing so?

[IdaGJ]

Hi Antti,

Let me try to elaborate on my question. I have all capacities fixed in my model, so I basically just want to make a simulation of this one week of the year where I try to simulate a very cold week and some capacities shutting off (I am simulating a DH-system). So the results for e.g. the activity variable I would like to see as the actual production in my week and not the scaled up version for serving the full year's demand.

I hope this is more clear.

I started with setting TS_CYCLE annual to 7 (as you recommend below) and YRFR for each time slice to 1/168. The demand is set to the one year's demand and then the COM_FR as laid out in my original post (demand in timeslice / demand for full year). 

When running with the above settings, I still get the yearly demand served, while I would like to see only the demand for the week.

Best,
Ida

[Antti-L]

But if "the demand is set to the one year's demand", how do you expect to see only one week's demand to be served? Do you perhaps mean that your COM_FR values do not sum up to 1, but only to a small fraction corresponding to one week's fraction of the yearly demand?

[AKanudia]

would hybrid timeslices be an option? Can you aggregate the remaining 51 weeks into a few timeslices?

[Antti-L]

Good point, Amit! That might pretty well correspond to what IdaGJ wishes.

[IdaGJ]

To your first question on the COM_FR, Antti: Yes, it sums only to around 5%.

It sounds like a possible workaround with the hybrid timeslices. I will try to set it up

So I just make a dummy timeslice under daynite that represents the rest of the year - setting YRFR for this timeslices to (8760-168)/8760 and for the other time slices 1/8760. Should TS_CYCLE for ANNUAL then be 365 as the length would now be the full year again?

Would it mess up something with my storages that I need to think about? I have both regular storages (modelled with input and output processes and an STS storage process in between) and demand flexibility storages (STG type as in the demo models)

[Antti-L]

I would think it would be better to introduce two SEASONs: For example OW (oneweek) and RW (rest of weeks).  Under RW, you could define maybe even just a single DAYNITE timeslice (e.g. RWD), and under OW you would have the 168 hourly timeslices.  TS_CYCLE(r, OW)=7; TS_CYCLE(r, RW)=358; whereas TS_CYCLE(r,ANNUAL) should remain at its default.

Yes, you would have YRFR(RWD) = (8760-168)/8760 and for the other time slices 1/8760. And of course the COM_FRs for RWD should all be 1 minus the sum of the fractions for the 168 hourly timeslices.

[IdaGJ]

Okay, I have set it up now following your guidance and so far everything seems to work, so thank you!

Is the reason why you suggest to have the dummy hour in another season related to the storages, Antti? Just to understand your reasoning for splitting it up.

[Antti-L]

Well, in my view the storage cycle would be peculiar if it would contain 168 hourly timeslices and then 51 weeks. I would think it might tend to cause unnecessary losses if you have modeled such, or otherwise abnormal behaviour. Besides, with two seasons it would better correspond to your original description (you wanted to look at just one week). But you could of course test it both ways and see if either suits you better.