Storage related attributes
#1
Dear Antti,

I am trying to learn how to properly model storage processes in TIMES and thus, the following questions related to a specific case I am working on.
Hope you can provide me with some answers and clarifications.


At the moment my goal is to properly model a thermal storage, which currently is available in the district heating network of a city I model. The information I know/assume is the following (also in the attached file):

1) Installed capacity in terms of the maximum amount of heat that can be in the storage in a given moment = 900 MWh
2) Minimum capacity = 200 MWh, is an assumption, which limits the lowest level of stored heat in a given moment
3) Charge and discharge rate = 60 MW
4) STG_EFF and STG_LOSS are assumed values for efficiency and losses.

My main questions to you are related to the attributes, which regulate installed capacity (in MWh) and charge and discharge rates (in MW).
Could you please take a look at the attached file and check if my logic in defining the 
- STGIN_BND, 
- STGOUT_BND, 
- NCAP_AF~LO, 
- NCAP_AF~UP, 
- STOCK~2015 
attributes is correct and reflects the input information above (also in the file)?

I believe there is another way of defining the indicated attributes - via the NCAP_AFC attribute, but I do not think I totally understand how that would work. 
If possible, could you please provide me with an alternative, which would define the capacity and the charge/discharge rates using the NCAP_AFC attribute.


Of course, it would be great if you could check other parameters in the file as well since I have very limited experience of modelling storage processes in TIMES and still finding my way around with attributes and other modelling features. E.g., if I want my storage to be able to operate not only at the Day/Night level but at all the available levels Day/Night-Weekly-Season (please see my time-slices in the file), is it correct to identify the process with the "STS" storage type qualifier?

Looking forward to hear back from you.
Best regards,
Dmytro


Attached Files
.xlsx   VT_CITY_STG_ESK___.xlsx (Size: 1.5 MB / Downloads: 3)
Reply
#2
Ok, please find below my comments:

  • Your Stock is ok, if you want to model the capacity in terms of maximum amount stored, and if the flows are really in TJ;
  • Your NCAP_AF(UP/LO) are ok, if if you want to model the capacity in terms of maximum amount stored;
  • STG_LOSS is ok;
  • STGIN_BND / STGOUT_BND are not ok for the purpose intended.

But are the flows really in TJ (it is a rather small unit)?
Concerning the STGIN_BND / STGOUT_BND, as they are defined now, they are ANNUAL bounds, and so are not actually limiting the charge /discharge rates, but total ANNUAL flows. You could define bounds for each and every timeslice for defining those max charge / discharge rates, but in my opinion that would get rather cumbersome, and so I would suggest to use NCAP_AFC instead. Then your capacity unit could be in MW, and thus Stock=60, NCAP_AFC(NRG,DAYNITE)=1, NCAP_AFC(ACT,DAYNITE)= 0.625, NCAP_AF(ANNUAL,LO)=0.1388889 and PRC_CAPACT=31.536 (assuming TJ is indeed your flow unit).  ( 900/(60×24)=0.625;  200/(60×24)=0.13888889 ).

Yes it is correct to identify the process with the "STS" storage type qualifier.
Reply
#3
Dear Antti,

thank you very much for such a quick response.

1) the flows are in TJ and, I have checked again, should be correct. It is a district heating system with yearly heat deliveries of around 600 GWh (2160 TJ), which has a thermal storage of 900 MWh (3.24 TJ) of capacity.

2) Ok, then I will try to apply the approach of expressing storage parameters via the NCAP_AFC attribute. Thanks a lot for providing me with the instruction on how to do so!
But since this approach is new to me, could you please elaborate a little more on how to implement your suggestions in the actual file?
Because of limited TIMES knowledge I am having difficulties understanding how exactly to implement e.g.,
- NCAP_AFC(NRG,DAYNITE)=1,
- NCAP_AFC(ACT,DAYNITE)= 0.625.
It is the same attribute but one has "NRG" and another one has "ACT" in parentheses. How do I include this in my excel table(s)?

3) Also, could you please elaborate shortly what the proposed entrances mean?
- NCAP_AFC(NRG,DAYNITE)=1 - means that the capacity of the storage is available at all times, correct? all year long and in each time-slice, right?
- NCAP_AFC(ACT,DAYNITE)= 0.625 - means that each hour the storage can be charged/discharged with 60 (MW) * 0.625 = 37.5 MW of heat? this also means that over a day (24 hr) up to 37.5 * 24 = 900 MWh can be charged or discharged? Am I understanding this correct?
- NCAP_AF(ANNUAL, LO)=0.138. Could you please explain this in more details? I mean why do we indicate ANNUAL instead of DAYNITE? And how do we get mathematically to 200 MWh of lowest allowable storage level with this attribute value? I am having difficulties here.

Hope to hear back from you! I think I am learning but still need a bit more understanding.
Best regards,
Dmytro
Reply
#4
Please find my answers below:

1) Ok, fine.

2) NCAP_AFC has the indexes NCAP_AFC(r,y,p,cg,tsl).  Here r=region, y=year, p=process, cg=commgrp and tsl=timeslice level.  The shorthand notation NCAP_AFC(NRG,DAYNITE) just tells that cg='NRG' and tsl='DAYNITE'.  NCAP_AFC(NRG,DAYNITE) tells that cg='ACT' and tsl='DAYNITE'. You can specify cg in the CommGrp column, and tsl in the Timeslice column. You could also use the header NCAP_AFC~DAYNITE.  So, in one row you could write 'NRG' in the CommGrp column and put the value 1 under the column NCAP_AFC~DAYNITE.  And then in a second row you could write 'ACT' in the CommGrp column and put the value 0.625 under the column NCAP_AFC~DAYNITE. It is easy, but as always, check the parameters in Browse.

3) NCAP_AFC(NRG,DAYNITE)=1 defines a DAYNITE level availability factor for the NRG flows (NRG means energy). An availability factor of 1 (=100%) means that the full capacity can be used. The full capacity is 60 MW.  So, with an availability factor of 1 (=100%) you can discharge max. 60 MW of energy output in any timeslice, and charge energy into the storage with max. 60 MW power in any timeslice.
NCAP_AFC(ACT,DAYNITE)= 0.625 defines a DAYNITE level availability factor for the activity (ACT refers to the activity).  The activity represents the storage level.  By convention, in a DAYNITE level storage an availability factor of 1 (100%) would correspond to a maximum storage level of CAP × 24 h = 60 MW × 24 h = 1440 MWh. Therefore (for a storage with maximum storage level of 900 MWh), an availability factor of 0.625 would correspond to a maximum storage level of 60 MW × 24 h × 0.625 = 900 MWh. See the documentation, section 4.3.7 Availability factors for storage processes.

NCAP_AFC can only be used for UP/FX availability factors.  Therefore, for defining the minimum storage level of 200 MWh, NCAP_AF(ANNUAL, LO)=0.138889 is needed, because an availability factor of 0.138889 for the storage level would correspond to a storage level of 60 MW × 24 h × 0.1388889 = 200 MWh.  NCAP_AF is always levelized, and this can therefore be defined for the ANNUAL timeslice only.
Reply
#5
I forgot to give an explicit answer to this question:

> NCAP_AFC(ACT,DAYNITE)= 0.625 - means that each hour the storage can be charged/discharged with 60 (MW) * 0.625 = 37.5 MW of heat? this also means that over a day (24 hr) up to 37.5 * 24 = 900 MWh can be charged or discharged? Am I understanding this correct?

NO, that is not correct at all.  NCAP_AFC(ACT,DAYNITE) defines an availability factor for the activity (ACT).  The activity represents the storage level, and so this parameter defines the maximum amount of energy that can be stored at any timeslice. It does NOT define a limit for the amount charged or discharged.  The bounds for the amount charged or discharged are defined by the availability factors for the input / output flows (NCAP_AFC(NRG,DAYNITE)).
Reply
#6
Dear Antti,

thanks again for your prompt and detailed answers. Much appreciated!

I will now absorb the received information and try to play with the model and storage parameters to get a better hands-on experience.

Hope it is going to be OK to write to you hear again if I have new questions or clarifications.

Have a great day,
Dmytro
Reply
#7
(01-09-2021, 02:48 PM)Antti-L Wrote: 2) NCAP_AFC has the indexes NCAP_AFC(r,y,p,cg,tsl).  Here r=region, y=year, p=process, cg=commgrp and tsl=timeslice level.  The shorthand notation NCAP_AFC(NRG,DAYNITE) just tells that cg='NRG' and tsl='DAYNITE'.  NCAP_AFC(NRG,DAYNITE) tells that cg='ACT' and tsl='DAYNITE'. You can specify cg in the CommGrp column, and tsl in the Timeslice column. You could also use the header NCAP_AFC~DAYNITE.  So, in one row you could write 'NRG' in the CommGrp column and put the value 1 under the column NCAP_AFC~DAYNITE.  And then in a second row you could write 'ACT' in the CommGrp column and put the value 0.625 under the column NCAP_AFC~DAYNITE. It is easy, but as always, check the parameters in Browse.
3) NCAP_AFC(NRG,DAYNITE)=1 defines a DAYNITE level availability factor for the NRG flows (NRG means energy). An availability factor of 1 (=100%) means that the full capacity can be u

Dear Antti,

sorry for being back with yet another question so quickly.

I am trying to follow your instructions (above) on how to indicate indexes for the NCAP_AFC attribute but keep getting the "VI: Commodity expected for parameter" error when synchronizing the file. Cell J:12 in the attached Excel file is highlighted when I double-click on the error.

Could you please check the file and see if I made any entrances in some rows or columns in a wrong way. Maybe I misunderstood some instructions.

Again, thanks a lot for your help.
Dmytro 

.xlsx   VT_CITY_STG_ESK.xlsx (Size: 1.5 MB / Downloads: 4)
Reply
#8
That spurious error is a VEDA issue. It seems you are using some old version of VEDA, is that correct?

Old versions of VEDA may have some bugs. I remember having seen a similar issue myself years ago, when using an old version of VEDA. But there is an easy work-around: Just put HETHTHP also into Cell F12. Putting it there is correct (it is an output) and so it will do no harm, but by doing so you should get rid of the buggy error.

Of course, you should also consider upgrading your VEDA... But anyway, this is not the VEDA Forum.
Reply
#9
May I kindly ask you also, why have you now changed the process type from STS to STG?  Huh
Reply
#10
Dear Antti,

thanks, adding HETHTHP commodity helped! We are doing our best to move our models from the old VEDA to the new one. Hope that VEDA related issues will not be a problem soon.

Ah, I have changed it back to STG in order to compare model results with a storage process being described as STG and STS. This is simply a learning exercise. Smile But thanks for this attention to details and bringing this up.

Thanks again,
Dmytro
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)