Storage processes in peaking constraints

[Antti-L]

In the TIMES model generator, storage flows have never been taken into account in the peaking constraints, even if peaking constraints are defined for the stored commodity. Only the storage capacity is taken into account, in the same way as power plant capacities.

This may not be fully satisfactory for several reasons:

1. In TIMES, the capacity of a DAYNITE level timeslice storage represents the daily storage capacity. For example, if there is a winter season timeslice (W) corresponding to 20% of the whole year, and the winter peak timeslice (WD) is half of that (10%), and the storage capacity is 1 PJ, the maximum amount that could be discharged from the storage in the winter peak timeslice would be 1*365*0.2 = 73 PJ (assuming PRC_CAPACT=1, NCAP_AF=1, and no storage losses). However, in the peaking equation the contribution of the capacity to the peak supply is assumed to be  1*G_YRFR(WD)*NCAP_PKCNT, which amounts to 0.1 PJ if NCAP_PKCNT has the default value 1 (ignoring the peak reserve margin for simplicity). Therefore, the user should always remember to define an appropriate NCAP_PKCNT multiplier for a storage process producing a peaking commodity. In this case NCAP_PKCNT should be set to 730 if the full storage capacity would be assumed to be available in the peak timeslice!

2. Instead of the storage capacity, the user might want to use in the peaking equation the actual net output from the storage during the peak timeslice, because for various reasons it might not be possible that the full storage capacity is discharged at the peak time.

3. A storage process could, in principle, also have the peaking commodity as an input, but some other commodity as an output. In such a case the input flow into the storage, which might occur also during the peak timeslice, should perhaps be included on the consumption side of the peaking equation.

I would like to get some opinions about these issues. Should they be addressed in the code, and if so, how?

Thanks,
Antti (Current maintainer of the TIMES code)

[AL_GA]

Hello Antti !

 

I discovered your post by chance and I found it really interesting. I am actually working on Demand Response modeling to measure its impacts on electric system and I am thinking if it's possible to represent DR by a storage process. But the problem i, as you said, TIMES takes into account only the capacity of the storage process and not its response time or its flexibility.

 

Do you have any ideas?

 

Thanks in advance!

[Antti-L]

Well, to some extent you can model demand response by a storage process. You could simulate the load shifting potential by introducing a storage process.

Concerning the peaking equations, the current TIMES code allows the user to decide whether the storage process should contribute to the peak by its capacity or flows.  If you set PRC_PKNO for the process, the process will now contribute to peak by its flows (with the output multiplied by NCAP_PKCNT, which has to be then also explicitly specified).

[Poncelet_K]

I'm only discovering this topic now. Thanks for bringing this issue up Antti, I would probably not have noticed this issue.

However, for me it seems to be the case that it is essential to take into account the electrical generating capacities for storage processes.

For example, in my model, I work with a specific pumped storage plant (Coo, Belgium) with following characteristics:

Storage capacity: 0.02031PJ

Electrical capacity: 1.164 GW

With a NCAP_PKCNT equal to 1, the contribution of the pumped storage to the peaking equation would be 0.25*(2/24)*0.02031 PJ = 4.23125*10^-4 PJ

Now suppose I would have the following TS division:

(WI, SP, SU, FA) with each 25% of the year

Day, Night, Peak, in which Peak represents the 2 hours of the day with the highest demand.

Following your reasoning with only the storage (energy) capacity would result in the following:

Maximal contribution to peak demand = (365/4)*0.02031 PJ = 1.853 PJ

According to the limited electrical capacity, the maximal contribution to the peak demand would however be: 1.164*CAP2ACT*0.25*(2/24) = 0.764748 PJ, which is significantly smaller.

NCAP_PKCNT would therfore need to be 1807.4 (instead of 4379.3 when taking into account only the energy storage capacity).

[Antti-L]

I am not fully able to follow you, because in TIMES, you can only have a single capacity for each process. So, you must choose between having the storage capacity or the electrical output capacity.

If you choose to model the process with the storage capacity of 0.02031 PJ, you are right, in that case it would have a peak contribution 4.23125*10^-4 PJ, if NCAP_PKCNT=1 and PRC_CAPACT=1.

However, if you choose to model the storage process with an electrical capacity of 1.164 GW, the process would then have a peak contribution 0.764748 PJ,  if NCAP_PKCNT=1 and PRC_CAPACT=31.536. Your max. output flow during the peak timeslice would also be automatically limited by the capacity to the amount of 0.764748 PJ.

Of course, in the first case you could set  NCAP_PKCNT=1807.4, and then your peak contribution would become  0.764748 PJ also in that case.  However, your max. output flow during the peak would still remain 0.02031*365/4 = 1.853 PJ (full discharge during the peak timeslice).

[Poncelet_K]

Indeed, in TIMES you can only have a single capacity for each process.

As my example shows, however, the energetic storage capacity (energy units) is not the only parameter of importance for storage facilities and the maximal power in/out of the storage should also be taken into account. So for a reasonable modeling of storage devices, the energetic capacity as well as the 'flow rate capacity' should be taken into account.

This has some consequences (assuming the storage is modeled following the convention that capacity corresponds to the energetic storage size):

1) Additional equations need to be set up by the user to limit the flow rates to realistic values

2) When determining the storage contribution to delivering the peak (NCAP_PKCNT), one would need to check whether it is the energy aspect or the power aspect, that limits the contribution of the storage (see the example in the previous reply), and the user has to calculate this NCAP_PKCNT by hand, taking these things into account.

So for me, it seems reasonable to make some changes in the modeling part of storage devices, which would allow having an energetic storage capacity as well as a 'flow rate capacity'. When these parameters would be entered by the user, ideally TIMES would automatically take care of both issues (1) and 2)). 

[Antti-L]

Yes, but on the other hand, both of your issues (1) and (2) would be eliminated, if you would model the storage with a capacity defined by the max. electrical output.  Then one might of course have the issue of having too much energy stored in the storage, which could be addressed by ACT_BNDs or user constraints.

Anyway, if you can formulate your proposal for improving the storage modeling in terms of new input parameters, equations and variables, I am sure it can be implemented. You are welcome to submit your proposal to the ETSAP Operating Agent.

[Poncelet_K]

I realize that both the issues can be avoided and so this is not a major issue. However, a modeler would have to be aware of the issues in order to avoid them.

If I have some time, I will take a look on how this could be implemented in the easiest way.