Veda2.0 Released!


Fix investments
#16
Thank you for youre fast answer Smile.

Using an attribute that exist worked regarding the warning message. 

But I am still not able to get it to work right. Stating the GDX reference with "As starting point" option and "Fix years upto" as None gives error in GAMS compilation. I have attached the lst-file.

The contex for us to use the attribute is to check if results from one stochastic/spines model is feasible in another stochastic/spines model. The only thing that changes between them is the number of SOWs.


Attached Files
.txt   Test_3scen_fixedTo9Scen_4.txt (Size: 90.29 KB / Downloads: 9)
Reply
#17
please upload the .RUN file from this run. It will help Antti to figure things out.
Reply
#18
The RUN file is attached, I just changed the endig to .txt as RUN-file is not allowed.


Attached Files
.txt   Test_3scen_fixedTo9Scen_4.RUN.txt (Size: 2.12 KB / Downloads: 6)
Reply
#19
Many thanks Lisa for providing the listing file and the run file, and thanks Amit for the help shooting the trouble.

I identified the problem now (which was related to using REG_BDNCAP for a stochastic run without FIXBOH). It will be fixed in the next version (should be available within a week). Meanwhile, you could try adding e.g. SET FIXBOH 1990 (fixing years up to a very old year, which will not have any impact), and it should already work for you.
Reply
#20
I didn't shoot Antti... just lined up the distance and wind speed information for you Smile
Reply
#21
Veda UI will not let you go any earlier than the first milestone year for FIXBOH. If that is not acceptable, then you will have to declare this FIXBOH in the RUN file.
Reply
#22
(01-09-2020, 08:22 PM)AKanudia Wrote: I didn't shoot Antti... just lined up the distance and wind speed information for you Smile
Sorry I meant troubleshooting, for which I appreciate your help. I am not so good at English and so I thought shooting the trouble means the same thing. Blush
Reply
#23
Dear Amit and Antti,

Setting FIXBOH to the first milestone year and also setting Fix Years Upto the last milestone year (same as the year for REG_BDNCAP) in the GDX references window did make it work. I was able to get different operational decisions for each of the SOW with the same capacities as the fixed GDX. 

Thank you very much for implementing this function and youre help. It will help us alot and save us for even more time Big Grin .

Best regards,
Lisa and Pernille
Reply
#24
Dear Antti, Amit and all TIMES colleagues.

We are currently using REG_BDNCAP to fix capacities from one run in another model run with other operational details, for example with higher temporal resolution. We are very satisfied with this feature.

We now wish to extend this functionality to allow for investments in selected technologies, like energy storages only, in model runs with higher temporal resolution. Meaning all other capacities, except energy storages, are fixed from a previous model run. Do you know if this has been done previously?

In relation to this, is it possible to make an exception for selected processes in REG_BDNCAP? Or should this be solved by facilitating for new investments in a subRES?

Let me know if anything is unclear.

Your suggestions on how to proceed is highly appreciated.


Best,

Pernille
Reply
#25
>  is it possible to make an exception for selected processes in REG_BDNCAP?

Well, because there was a related ETSAP project proposal, which was not realized, I did, in fact, implement a mechanism for defining exceptions, as now described also in the documentation.  This process-specific exception mechanism is based on using NCAP_BND(r,'0',p,'N') = ± 1, where −1 means that the process capacity will be defined with a lower bound only, and +1 means that the process capacity will be defined with an upper bound only (when using REG_BDNCAP). Although this has its limitations, it seems that this option (with −1) would satisfy your need?

As an aside, may I ask why you have decided not to allow for investments in storage technologies, in model runs with a coarser temporal resolution? Have you been able to identify some distinct problem related to TIMES storage processes when using coarser temporal resolutions?
Reply
#26
Tank you very much for the fast reply. It is good news that you already have implemented this feature to the code. We will test this feature out soon.

Regarding storages, we have a hypothesis that the cost-optimal storage capacity depends on the temporal resolution of the model. I do no not know if it is valid, but it will be interesting to test. Other types of capacity that can be tested by this approach is for example investments in renewables and transmission capacities. This methodology is inspired by the features of the Balmorel model.
Reply
#27
We are currently testing to solve the Norwegian model with 8760 h time-slices with fixing the capacities from a previous run with that uses a coarser temporal resolution.
 
This seems to work with that the capacities are equal between the two runs, and that the two runs provide operational decisions and parameters with different temporal resolutions. Including that the time-slice dependent production seems to work.
 
However, one challenge we face, is that the 8760-h model is using dummies if we include demand profiles in the 8760-h run. If we include demand profiles at an hourly level, the model uses dummies, for all time-slices,  instead of using other energy carriers. If we disable COM_FR from the demand,  the use of dummies is not there anymore.

Do you have any tips on how to solve this issue?
 
Let me know if anything is unclear.


Attached Files Thumbnail(s)
   
Reply
#28
Make IMPNRGZ operate at the DAYNITE level - you can use PRC_TSL attribute in a TFM_INS-txt table in SysSettings to do this.

Maybe there is a genuine shortage in some timeslice and it ends up importing in all slices because IMPNRGZ is ANNUAL by default.
[+] 1 user Likes AKanudia's post
Reply
#29
(22-11-2024, 05:20 PM)AKanudia Wrote: Make IMPNRGZ operate at the DAYNITE level - you can use PRC_TSL attribute in a TFM_INS-txt table in SysSettings to do this.

Maybe there is a genuine shortage in some timeslice and it ends up importing in all slices because IMPNRGZ is ANNUAL by default.

Thank you very much for the fast reply. This makes sense and I will try it out.
Reply
#30
(22-11-2024, 05:20 PM)AKanudia Wrote: Make IMPNRGZ operate at the DAYNITE level - you can use PRC_TSL attribute in a TFM_INS-txt table in SysSettings to do this.

Maybe there is a genuine shortage in some timeslice and it ends up importing in all slices because IMPNRGZ is ANNUAL by default.

Thank you very much for the fast reply. This makes sense and I will try it out.
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)