Fix investments

[Kannan]

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.

Hi Pernille,

Good to know you've tested this approach and it works.

I'm curious to know about model database.  Do you use two separate models, one with coarse timeslice and another with 8760 TS (with common topoloy), or the same model with just a different SysSetting file (to declare TS & YRFR?). 

If it's the latter, how do you clean up the parameters (e.g., AFA~), which are declared at TS in the coarse model (if they are not in separate scearnio file)?

I appreciate some insight.

Thanks,

[miguel.chang]

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.

Hi Pernille,

Good to know you've tested this approach and it works.

I'm curious to know about model database.  Do you use two separate models, one with coarse timeslice and another with 8760 TS (with common topoloy), or the same model with just a different SysSetting file (to declare TS & YRFR?). 

If it's the latter, how do you clean up the parameters (e.g., AFA~), which are declared at TS in the coarse model (if they are not in separate scearnio file)?

I appreciate some insight.

Thanks,

Hi Kannan,

We use only one model, but instead of SysSettings the TimeSlices and YRFR are declared in a scenario file (along with any other Daynite or Season inputs). This allows for more flexibility, if you -for example- want to use some script to generate profiles with different temporal resolution(s).

[miguel.chang]

Dear Antti and Amit,

Regarding the functionality described by Pernille: is there any option or workaround to conduct the aforementioned operational runs with fixed capacities but as a snapshot for only 1 target year? For example, if we are only interested in testing the system's operation for 2050 with different temporal resolutions and profiles, but do not need the previous milestone years (and thereby also reducing the computational effort for solving for those additional years).

Thanks in advance for any insight.

Regards,
Miguel Chang

[Antti-L]

For example, if you have made a previous run including milestone years 2020, 2025,..., 2045, 2050 (and maybe even further ,2055,...), you could then run the model with a horizon using 2050 as the last milestone, and fixing the initial periods up to 2045 to that previous run, and fix (or bound) the capacities up to 2050.  Would that possibly correspond to what you describe?

[miguel.chang]

Hi Antti,
Thanks for the prompt reply.

Yes, exactly.

Is that initial period (2045 in your example) then be what's defined in the GDX references options in VEDA (attached img)?
or must it be defined by some other Attribute?

[Antti-L]

Yes, I guess so, if you also select a GDX file.
But I am not sure what the "As Starting Point" means in VEDA.
I have not used it (leaving it unselected), and I think it works well without it.
I hope the VEDA developers could explain the meaning of "As Starting Point".

[miguel.chang]

Great, thanks for the pointer! It seems to be working.

We had "As Starting Point" selected since it was suggested by Amit in a previous post. On a a quick look, it appears selecting this seems to yield the same results.
It would indeed be good to understand the difference in use case for this option in VEDA.