(Pumped) Storage modelling

[Antti-L]

Re-post, because my earlier reply to fg's post seems to have disappeared.

My task is to integrate pumped hydro storages as STGTSS properly into our model and I've now been reading both through the documentation and a couple of threads here in the forum, but still remain somewhat puzzled.

Issue I
According to my understanding, the term capacity is unfortunately blurry when it comes to storages, as in literature it can refer both to
a) the rated power output of the turbine / input of the pump, measured in e.g. [GW]
or
b) the amount of energy that can be stored in, measured in e.g. [GWh]

Do I understand this thread ( http://forum.kanors-emr.org/showthread.p...ht=storage )
correctly, that the attributes STOCK or PRC_RESID define for storage devices only the amount of energy, where in contrast in any other technology it refers to the rated power output?

All processes in TIMES have only a single capacity, including storage processes. Therefore, one can only limit the output flow, the input flow, and the amount of energy stored in proportion to that single capacity.

If using only NCAP_AF for the process timeslices (and not NCAP_AFC), the capacity of a storage refers to the amount of energy stored. But by using NCAP_AFC you can instead define the capacity in terms of the max. nominal output, just like with power plants. And then you can also define availability factors for the amount of energy stored, such that the maximum amount of energy stored is also limited, proportionally to the rated output capacity.

For more information, see the TIMES documentation, Part II: http://iea-etsap.org/index.php/documentation

See Section 4.3.7 : Availability factors for storage processes.

Let me know if you have additional questions with respect to the TIMES attributes.

[fg]

Let me know if you have additional questions with respect to the TIMES attributes.

Dear Antti,
after your reply, I thought I had understood how the NCAP_AFC attribute is to be used to limit the flows, but just noticed that our model is not working as expected.
Therefore, I digged into the topic again and read through subchapter 4.3 of the TIMES doc Part II, especially section 4.3.7 as you suggested.

I'm just experimenting with different timeslice resolutions, right now I work with four representative weeks, i.e. 4 SEASONs, 168 hours each (DAYNITE), thus no WEEKDAY tslvl.
YRFR(s) = 1/4/168 = ~0.0014881 for all s.
PRC_CAPACT = 8.76 since energy flows are given in [TWh] and capacity in [GW].
Say, I want to model a pumped storage plant as a timeslice storage (Set='STGTSS') with an electrical capacity of 4.85 GW and a storage capacity of 8 GWh/GW as proposed in section 4.3.7.
Since the attribute is given in ANNUAL but the storage works on DAYNITE level, I set NCAP_AFC = 8/4/168 = 0.011904762
Would that be correct?
(The roundtrip efficiency is given with STG_EFF=0.75 and the yearly availability with NCAP_AFA=0.95)

Since the electrical capacity is limited to 4.85 GW, the outbound and inbound flows VAR_FOut and VAR_FIn should never exceed
    VAR_Cap * PRC_CAPACT / YRFR (= 4.85*8.76/4/168 TWh =) 0.0632232 TWh.

Unfortunately, I see this threshold being exceeded in some timeslices in the results.

Any ideas what I did wrong here?

Thank you in advance for any help!
Fabian

[Antti-L]

From your post, I cannot really see which NCAP_AFC attributes you are actually defining. It would help if you would post all the process parameters, and the process topology.

But very well, assume that the storage process is named EXSTG and it is both charging and discharging the same electricity commodity, say ELCSS. If you want the capacity to be bounding the process output, allowing 100% capacity utilization in any single timeslice, you should use NCAP_AFC(r,y,EXSTG,ELCSS,DAYNITE) = 1.  If the capacity is 4.85 GW, that should bound the output flow in any single timeslice to at most 0.0632232 TWh. Does it not?

Then, as the documentation describes (Part II, section 4.3.7), you can additionally require that the capacity is bounding also the amount stored (=activity). If you want that the amount stored can be at most 8 GWh/GW, the maximum availability factor should be set to 8/24 = 0.333, as stated in the documentation. So, you should define NCAP_AFC(r,y,EXSTG,ACT,DAYNITE) = 0.333.

Both of these availability factors should thus be defined on the DAYNITE level. You can of course define additional availability factors on the SEASON/ANNUAL level, if necessary.

[fg]

From your post, I cannot really see which NCAP_AFC attributes you are actually defining. It would help if you would post all the process parameters, and the process topology.

First of all, thank you for your quick reply!

That was really helpful since I seem to have defined in a wrong way, i.e. without the Other_Indexes column where I can put the 'ACT' or 'NRG' as given in the documentation. Now, I'm very close to a solution by defining it that way:
   

But very well, assume that the storage process is named EXSTG and it is both charging and discharging the same electricity commodity, say ELCSS. If you want the capacity to be bounding the process output, allowing 100% capacity utilization in any single timeslice, you should use NCAP_AFC(r,y,EXSTG,ELCSS,DAYNITE) = 1.  If the capacity is 4.85 GW, that should bound the output flow in any single timeslice to at most 0.0632232 TWh. Does it not?

Beforehand, it did not. Now it does!

Then, as the documentation describes (Part II, section 4.3.7), you can additionally require that the capacity is bounding also the amount stored (=activity). If you want that the amount stored can be at most 8 GWh/GW, the maximum availability factor should be set to 8/24 = 0.333, as stated in the documentation. So, you should define NCAP_AFC(r,y,EXSTG,ACT,DAYNITE) = 0.333.

This here is actually my remaining question:
In the documentation is said that the full DAYNITE cycle is assumed to be 24 hours. In my case, the DAYNITE level represents a full week, i.e. 168 hours, so shouldn't it be then NCAP_AFC(r,y,EXSTG,ACT,DAYNITE) = 8/168 = 0.04762 ?
Or even the other way round 8/24*7 = 2.333 ?

Bascially, the 8 GWh/GW mean that after 8 hours of charging/discharging the storage is full/empty. So in consequence, the factor should avoid that there happens charging or discharging in more than 8 consecutive hours.
However, from what I understood, the timeslices are not ordered, right? So, is it possible to model this behaviour at all?

I checked the results with 8/24 = 0.333 as you suggested and they seem plausible, but I'm not sure whether this behaviour is random or not.

Both of these availability factors should thus be defined on the DAYNITE level. You can of course define additional availability factors on the SEASON/ANNUAL level, if necessary.

Ok, as you can see above I defined it as DAYNITE.

[Antti-L]

Ah yes, I overlooked the implications of your unusual DAYNITE cycle.

If your DAYNITE cycle is in fact 168 hours (a whole week) and not 24 hours, you should define G_CYCLE(DAYNITE)= 365/7 = 52.14. Then your nominal maximum output in your DAYNITE cycle would be 168 GWh/GW instead of the usual 24 GWh/GW, and in that case the storage availability for a 8 GWh energy capacity should be set to 8/168 = 0.04762.  So, NCAP_AFC(r,y,EXSTG,ACT,DAYNITE) = 0.04762.

Does that answer your remaining question?

Timeslices are of course ordered, from one hour to the next in sequence, how did you think they were not?

[fg]

Ah yes, I overlooked the implications of your unusual DAYNITE cycle.

If your DAYNITE cycle is in fact 168 hours (a whole week) and not 24 hours, you should define G_CYCLE(DAYNITE)= 365/7 = 52.14. Then your nominal maximum output in your DAYNITE cycle would be 168 GWh/GW instead of the usual 24 GWh/GW, and in that case the storage availability for a 8 GWh energy capacity should be set to 8/168 = 0.04762.  So, NCAP_AFC(r,y,EXSTG,ACT,DAYNITE) = 0.04762.

Does that answer your remaining question?

I just tried it out by defining G_CYCLE in the SysSettings file like this:
   

However, this is rejected as an unknown attribute (I am using VFE v4.5.512 with GAMS_SRCTIMESV414)
   

Any ideas what I need to do? Or do I have to add this manually into the .DD files after their creation?

Timeslices are of course ordered, from one hour to the next in sequence, how did you think they were not?

Oh okay, then I was wrong, but very good that my assumption is not the case!
I thought so, since one can also define very basic timeslices like Day, Night, Peak - how would one bring these into any order?

[Antti-L]

Well, it was the original design, and also a hard-coded assumption in TIMES that the DAYNITE cycle represents a DAY, i.e. 24 hours.  

G_CYCLE is a TIMES attribute that was introduced a few years ago, because I felt someone may want to have it configurable. I believe it is supported in the latest VEDA-FE.  Ask Kanors if unsure.  It actually only affects storage (when capacity is the amount stored) and the various dispatching and unit commitment attributes, and so you will see a difference only if these features are used.

The timeslices are ordered in the sequence they are defined.  So, it is the responsibility of the user to define the order.

[fg]

OK, I just did.

So for now, I would like to add it to the created syssettings.dd file manually and tried:

Code:

PARAMETER
G_CYCLE ' '/
AT.2015.DAYNITE 52.14285714
BE.2015.DAYNITE 52.14285714
...

This seems to be the wrong way, as I get *ERRORS IN GAMS COMPILE*.

And yes, I agree with you that modelling entire weeks hourly is somewhat unusual. We're doing so in order to capture the effects of renewable characteristics that last longer than one day, e.g. one week with strong wind+strong solar+high loads, one with strong wind+strong solar+low loads, one with strong wind in the beginning and getting lower throughtout the week, etc.

And thank you for clarifying that the timeslices are ordered by users definition.

[Antti-L]

It might be easier to put it in the RUN template, close to the bottom, but before the call for maindrv.mod.
Anyway, you can define it as follows:

PARAMETER G_CYCLE / DAYNITE 52.14285714 /;

So, the parameter is global, and has only the TSLVL dimension: G_CYCLE(TSLVL).
I realize that someone might even want it to be region-specific, but that's not supported now.

[Gargiulo]

It might be easier to put it in the RUN template, close to the bottom, but before the call for maindrv.mod.
Anyway, you can define it as follows:

PARAMETER G_CYCLE / DAYNITE 52.14285714 /;

So, the parameter is global, and has only the TSLVL dimension: G_CYCLE(TSLVL).
I realize that someone might even want it to be region-specific, but that's not supported now.

The G_CYCLE is also supported in the last VEDA-FE version you can download running the installer on the Kanors web site. We are using it in one of the our models

[fg]

Hm, I always get a Termination of Run. The bottom of my  Run Template looks like this:

Code:

*<INCLUDE DD FILES>

*<GLOBAL Parameters>

$ SET VEDAVDD 'YES'
PARAMETER G_CYCLE / DAYNITE 52.14285714 /;

* do the rest
$ BATINCLUDE maindrv.mod mod

I also tried with $ and SET before the line begins, but doesn't seem to work.

[Antti-L]

Works here, but due to VEDA-FE processing, you may need to add a ; before the line, to terminate any preceding statement:

; PARAMETER G_CYCLE / DAYNITE 52.14285714 /;

Please try that.

[fg]

Ah, Maurizio's post overlapped mine. I just updated to VFE v.4.5.609 and it acceptes G_CYCLE now.

However, I had to define a CommGroup, so I set it to NRG. Is that correct?

[Antti-L]

What, CommGroup??  
Maybe you mean "Other_Indexes", which would be the TSLVL.

[Gargiulo]

What, CommGroup??  
Maybe you mean "Other_Indexes", which would be the TSLVL.

As said by Antti, you need Other_Indexes. See an example in attachment