Veda2.0 Released!


Capacity for storage
#1
Good aternoon, 
I have been reading about the storages in the documentation but i still do not understand some things. My problem is that in my model the capacity that the results are showing are extrmly small when actually the capacity needed is quite high. For example, i would need capacities over 1 PJ (or PJa) and the results in my model says a capacity of 0.0083. 
How exactly are the capacitues calculated when I use STS as process type?
To clarify, the results for my capacity is this: 
   
In this image you can see the evolution of the activity of the same storage in the different hours:
   

I do not understand why the capacity is that value, I am defining the process as STS with a CAP2ACT of 1 and PJ as activity and PJa as capacity
Reply
#2
I am willing to look at it and explain what is going on with that storage, if you can provide me with the TIMES input files (*.DD and *.RUN) as well as the listing file (*.LST) for this case, if they reproduce your results.

If that is ok for you, you could just pack those files into a ZIP file and provide me the download link (via e.g. Dropbox, Google Drive or equivalent).  If the model is confidential, you can send me the link in a private Forum message.
Reply
#3
Thanks, Antti.

@frangb99, please consider creating this case in Veda online. It will make the process of supporting much more efficient. It may also encourage more users to look into your issue as accessing your files will not be a prerequisite.
Reply
#4
Google said there, that I still need to request access from you. So, please grant that when you get the request (by Gmail I guess).
Reply
#5
(27-04-2024, 07:58 PM)Antti-L Wrote: Google said there, that I still need to request access from you.  So, please grant that when you get the request (by Gmail I guess).

Okay now i have granted you access i believe
Reply
#6
Yes it worked, thanks. I will let you know when I have investigated the issue.
Reply
#7
Thank you for the model files.  As I was able to think of multiple possibilities about your issue, it was good to see the whole model, and eliminate the possibilities. But the issue turned out to be just a very basic mistake in your model, which I was quickly able to see.

I hope you have read the documentation, which describes the timeslice tree and the related timeslice cycle concepts, employed in TIMES.  These basic features are accompanied with certain default assumptions, which your model did not seem to comply with.

Briefly reiterating the basics, the default assumption in TIMES for DAYNITE timeslices is that under each parent timeslice, they form a cycle representing one day (24 hours), a representative day under that parent timeslice. And that cycle is assumed to be repeated over the number of days under that parent timeslice. The assumptions are consistent and similar also for WEEKLY and SEASON timesices, but just the default cycle length is one week for WEEKLY and one year for SEASON.

In your case, your model had 4380 DAYNITE timeslices under a single parent timeslice, ANNUAL. That is unusual, both by omitting both the SEASON and the WEEKLY levels, and by the high number of timeslices defined for a single cycle. But anyway, the defaults apply also in your model, because you had not overridden them. Consequently, your DAYNITE timeslices were assumed to represent one representative day (24 hours) under the ANNUAL timeslice.  The results, which you found confusing, were indeed consistent and correct with those default assumptions. Each of your DAYNITE timeslices was thereby effectively representing about 20 seconds (while I think you meant that they should each represent 2 hours).

I am assuming that it was not your intention to define a DAYNITE cycle corresponding to a single day with those 4380 timeslices, but you intended to define a full-year cycle instead, with a length of 365 days, such that each of the individual DAYNITE timeslices represents 2 hours. However, you apparently did not realize that such a model would be inconsistent with the defaults. But whenever diverting away from the standard conventions, you should explicitly override the defaults. In your case, all you would need to do is to define the following parameter:

   TS_CYCLE('REG1','ANNUAL') = 365;

With this simple parameter definition, you can request that the length of the cycles under the ANNUAL timeslice should be 365 days, while the default is 1 day in your model (because in your model the next level under ANNUAL is DAYNITE).  I tested it with your model, and the issue you saw was indeed eliminated.

I hope that can be of some help.
Reply
#8
(28-04-2024, 04:59 AM)Antti-L Wrote: Thank you for the model files.  As I was able to think of multiple possibilities about your issue, it was good to see the whole model, and eliminate the possibilities. But the issue turned out to be just a very basic mistake in your model, which I was quickly able to see.

I hope you have read the documentation, which describes the timeslice tree and the related timeslice cycle concepts, employed in TIMES.  These basic features are accompanied with certain default assumptions, which your model did not seem to comply with.

Briefly reiterating the basics, the default assumption in TIMES for DAYNITE timeslices is that under each parent timeslice, they form a cycle representing one day (24 hours), a representative day under that parent timeslice. And that cycle is assumed to be repeated over the number of days under that parent timeslice. The assumptions are consistent and similar also for WEEKLY and SEASON timesices, but just the default cycle length is one week for WEEKLY and one year for SEASON.

In your case, your model had 4380 DAYNITE timeslices under a single parent timeslice, ANNUAL. That is unusual, both by omitting both the SEASON and the WEEKLY levels, and by the high number of timeslices defined for a single cycle. But anyway, the defaults apply also in your model, because you had not overridden them. Consequently, your DAYNITE timeslices were assumed to represent one representative day (24 hours) under the ANNUAL timeslice.  The results, which you found confusing, were indeed consistent and correct with those default assumptions. Each of your DAYNITE timeslices was thereby effectively representing about 20 seconds (while I think you meant that they should each represent 2 hours).

I am assuming that it was not your intention to define a DAYNITE cycle corresponding to a single day with those 4380 timeslices, but you intended to define a full-year cycle instead, with a length of 365 days, such that each of the individual DAYNITE timeslices represents 2 hours. However, you apparently did not realize that such a model would be inconsistent with the defaults. But whenever diverting away from the standard conventions, you should explicitly override the defaults. In your case, all you would need to do is to define the following parameter:

   TS_CYCLE('REG1','ANNUAL') = 365;

With this simple parameter definition, you can request that the length of the cycles under the ANNUAL timeslice should be 365 days, while the default is 1 day in your model (because in your model the next level under ANNUAL is DAYNITE).  I tested it with your model, and the issue you saw was indeed eliminated.

I hope that can be of some help.

But where should i put this: TS_CYCLE('REG1','ANNUAL') = 365; then?' in the sys settings or where? like where i have to define that??
Reply
#9
(28-04-2024, 04:59 AM)Antti-L Wrote: Thank you for the model files.  As I was able to think of multiple possibilities about your issue, it was good to see the whole model, and eliminate the possibilities. But the issue turned out to be just a very basic mistake in your model, which I was quickly able to see.

I hope you have read the documentation, which describes the timeslice tree and the related timeslice cycle concepts, employed in TIMES.  These basic features are accompanied with certain default assumptions, which your model did not seem to comply with.

Briefly reiterating the basics, the default assumption in TIMES for DAYNITE timeslices is that under each parent timeslice, they form a cycle representing one day (24 hours), a representative day under that parent timeslice. And that cycle is assumed to be repeated over the number of days under that parent timeslice. The assumptions are consistent and similar also for WEEKLY and SEASON timesices, but just the default cycle length is one week for WEEKLY and one year for SEASON.

In your case, your model had 4380 DAYNITE timeslices under a single parent timeslice, ANNUAL. That is unusual, both by omitting both the SEASON and the WEEKLY levels, and by the high number of timeslices defined for a single cycle. But anyway, the defaults apply also in your model, because you had not overridden them. Consequently, your DAYNITE timeslices were assumed to represent one representative day (24 hours) under the ANNUAL timeslice.  The results, which you found confusing, were indeed consistent and correct with those default assumptions. Each of your DAYNITE timeslices was thereby effectively representing about 20 seconds (while I think you meant that they should each represent 2 hours).

I am assuming that it was not your intention to define a DAYNITE cycle corresponding to a single day with those 4380 timeslices, but you intended to define a full-year cycle instead, with a length of 365 days, such that each of the individual DAYNITE timeslices represents 2 hours. However, you apparently did not realize that such a model would be inconsistent with the defaults. But whenever diverting away from the standard conventions, you should explicitly override the defaults. In your case, all you would need to do is to define the following parameter:

   TS_CYCLE('REG1','ANNUAL') = 365;

With this simple parameter definition, you can request that the length of the cycles under the ANNUAL timeslice should be 365 days, while the default is 1 day in your model (because in your model the next level under ANNUAL is DAYNITE).  I tested it with your model, and the issue you saw was indeed eliminated.

I hope that can be of some help.
I mean, this parameter where and how should i define it?
Reply
#10
(28-04-2024, 04:59 AM)Antti-L Wrote: Thank you for the model files.  As I was able to think of multiple possibilities about your issue, it was good to see the whole model, and eliminate the possibilities. But the issue turned out to be just a very basic mistake in your model, which I was quickly able to see.

I hope you have read the documentation, which describes the timeslice tree and the related timeslice cycle concepts, employed in TIMES.  These basic features are accompanied with certain default assumptions, which your model did not seem to comply with.

Briefly reiterating the basics, the default assumption in TIMES for DAYNITE timeslices is that under each parent timeslice, they form a cycle representing one day (24 hours), a representative day under that parent timeslice. And that cycle is assumed to be repeated over the number of days under that parent timeslice. The assumptions are consistent and similar also for WEEKLY and SEASON timesices, but just the default cycle length is one week for WEEKLY and one year for SEASON.

In your case, your model had 4380 DAYNITE timeslices under a single parent timeslice, ANNUAL. That is unusual, both by omitting both the SEASON and the WEEKLY levels, and by the high number of timeslices defined for a single cycle. But anyway, the defaults apply also in your model, because you had not overridden them. Consequently, your DAYNITE timeslices were assumed to represent one representative day (24 hours) under the ANNUAL timeslice.  The results, which you found confusing, were indeed consistent and correct with those default assumptions. Each of your DAYNITE timeslices was thereby effectively representing about 20 seconds (while I think you meant that they should each represent 2 hours).

I am assuming that it was not your intention to define a DAYNITE cycle corresponding to a single day with those 4380 timeslices, but you intended to define a full-year cycle instead, with a length of 365 days, such that each of the individual DAYNITE timeslices represents 2 hours. However, you apparently did not realize that such a model would be inconsistent with the defaults. But whenever diverting away from the standard conventions, you should explicitly override the defaults. In your case, all you would need to do is to define the following parameter:

   TS_CYCLE('REG1','ANNUAL') = 365;

With this simple parameter definition, you can request that the length of the cycles under the ANNUAL timeslice should be 365 days, while the default is 1 day in your model (because in your model the next level under ANNUAL is DAYNITE).  I tested it with your model, and the issue you saw was indeed eliminated.

I hope that can be of some help.
And just to be sure, I have been reading the documentation, and i was wondering if maybe, using the parameter like that, wouldnt I be saying that ANNUAL is 365 days??? instead of the ones under? Anyways i still do not know where and how to add it
Reply
#11
> Anyways i still do not know where and how to add it

I have never needed to add it to VEDA templates myself, and so please ask the VEDA support team. 
But how did you know how to add e.g. G_YRFR then?  It is a similar parameter. Could you take a look at the TIMES and VEDA Attributes function under VEDA?  (I myself added it to the RUN file for my test.) Note that I have implemented this parameter into TIMES, and so I know what it does.
Reply
#12
(28-04-2024, 06:22 PM)Antti-L Wrote: > Anyways i still do not know where and how to add it

I have never needed to add it to VEDA templates myself, and so please ask the VEDA support. 
But how did you know how to add e.g. G_YRFR then?  It is a similar parameter. Could you take a look at the TIMES and VEDA Attributes function under VEDA?  (I myself added it to the RUN file for my test.) Note that I have implemented this parameter into TIMES, and so I know what it does.
Then i understand it should be in the system settings somehow
Reply
#13
(28-04-2024, 06:22 PM)Antti-L Wrote: > Anyways i still do not know where and how to add it

I have never needed to add it to VEDA templates myself, and so please ask the VEDA support team. 
But how did you know how to add e.g. G_YRFR then?  It is a similar parameter. Could you take a look at the TIMES and VEDA Attributes function under VEDA?  (I myself added it to the RUN file for my test.) Note that I have implemented this parameter into TIMES, and so I know what it does.

The only idea i have is maybe this in the sys setting:
   
Reply


Possibly Related Threads…
Thread Author Replies Views Last Post
  Early retirement of capacity Mahmoud 9 6,366 23-01-2025, 09:01 PM
Last Post: farzin
  Investment bound on new capacity [email protected] 2 155 31-12-2024, 10:40 AM
Last Post: [email protected]
  NCAP_AFC and seasonal storage Kristina.Haaskjold 14 2,936 14-11-2024, 08:03 PM
Last Post: Antti-L
  Battery storage double check Ryo Ishida 4 440 24-10-2024, 09:31 AM
Last Post: Ryo Ishida
  Battery storage double check Ryo Ishida 0 156 15-10-2024, 06:16 PM
Last Post: Ryo Ishida
  A quick question about hydrogen storage [email protected] 0 181 11-09-2024, 12:17 AM
Last Post: [email protected]
Lightbulb Battery/Storage, NCAP_AFCS for individual timeslices anik 2 436 17-07-2024, 05:10 PM
Last Post: anik
  The power storage [email protected] 0 443 15-05-2024, 11:30 PM
Last Post: [email protected]
  Batteries input capacity constraint [email protected] 5 1,426 05-04-2024, 06:00 PM
Last Post: Antti-L
  problem with kre storage frangb99 24 6,051 23-02-2024, 07:56 PM
Last Post: frangb99

Forum Jump:


Users browsing this thread: 1 Guest(s)