Veda2.0 Released!


Fix investments
#1
Hi,

Is there a possibility to implement a way to fix investments only from another model run? Now the fix result fix both investment and operational. It would be grate to have the possibility to only fix investments and optimize only operation. 

Regards, 
Lisa Kvalbein
Reply
#2
If you referred by "fix" to the TIMES FIXBOH feature, only the support for setting the switch $SET FIXBOH has been implemented in VEDA-FE, all the rest of the functionality has been implemented in TIMES.

A similar support can of course be implemented for fixing only some variables, such as new capacities (VAR_NCAP). However, concerning investment costs, the only variable directly related to them in TIMES is VAR_OBJ(OBJINV).  If you would like to suggest an option for fixing only the discounted cumulative investments (VAR_OBJ(OBJINV)), or  possibly the new capacity variables (VAR_NCAP), I guess either could be implemented completely within VEDA, or mostly within TIMES. Were you thinking that it should be all implemented in VEDA 2.0?

Anyway, whichever way it may be implemented, there would be design issues to be clarified, e.g.:

  • What kind of an input attribute / switch should activate the new feature?
  • Should such fixing be supported individually by region, like FIXBOH is via REG_FIXT(reg)?
  • If VAR_NCAP is to be fixed, should any NCAP_BNDs in the current scenario be ignored or retained?
Reply
#3
If there is general interest, I can implement a new feature for bounding new capacity variables in TIMES according to the solution of a previous run loaded by LPOINT.

I have already tested it, by implementing a new input attribute REG_BDNCAP(reg,bd), which defines the year up to which all new capacity variables should be bounded in region reg, using the previous solution. The bounds may be FX, LO or UP.

To confirm whether there is general interest, any Forum readers please post your opinion here.  @Akanudia : it would also be useful to get the opinion of VEDA developers about it, whether the new attribute seems to make sense for implementing into VEDA.
Reply
#4
Dear Antti,
Thank you very much for investigating this.
 
For IFE this is of great interest and I believe such a feature can be valuable for other modelers as well.
 
First, this feature enables using TIMES for simulation purposes and can be valuable for doing sensitivity analysis without changing capacity.
 
Second. This feature is highly valuable, and will save a lot of time for teams that are doing stochastics with SPINES. All capacity needs to be fixed to e.g. determine Value og Stochastic Solution (VSS) as well as testing for out-of-sample stability. These parameters says something about the value of using a stochastic model and the quality of your model results, and it will be significant easier to provide these parameters with this feature.
 
Best,
Lisa Kvalbein
Reply
#5
Dear Antti and Amit,
I assume users of this forum does not necessarily receive e-mail notifications of this this new folder, VEDA2.0. Maybe this can be reflected by the response...

Best,
Pernille
Reply
#6
(12-06-2020, 04:32 PM)Antti-L Wrote: If there is general interest, I can implement a new feature for bounding new capacity variables in TIMES according to the solution of a previous run loaded by LPOINT.

I have already tested it, by implementing a new input attribute REG_BDNCAP(reg,bd), which defines the year up to which all new capacity variables should be bounded in region reg, using the previous solution. The bounds may be FX, LO or UP.

To confirm whether there is general interest, any Forum readers please post your opinion here.  @Akanudia : it would also be useful to get the opinion of VEDA developers about it, whether the new attribute seems to make sense for implementing into VEDA.

sorry for the delay.

REG_BDNCAP(reg,bd) looks like a great idea. Like Pernille says, it could be very useful for testing robustness of the "capacity plan" of a certain solution.

further clarifications:
  • REG_BDNCAP would be a regular TIMES attribute that could be declared in any table in any scenario file. Would this parameter be ignored if there is no LPOINT? I think there should be some boolean switch, in addition, so that one doesn't need to remove the REG_BDNCAP declarations if LPOINT is being used for some other reason. This could be user responsibility too - create a separate scenario file for this attribute so that it can be easily included/excluded.

  • Will this be usable in parallel with FIXBOH?


Reply
#7
Thanks Amit for your valued judgement!

Yes, the idea was that REG_BDNCAP would be a regular TIMES attribute, to be defined in any scenario file. It would indeed be ignored if no LPOINT is used.  I was myself thinking that no additional switch would be needed, as I would think the user would typically define it in a separate scenario file used for such NCAP bounding runs anyway. However, if e.g. the IFE users would prefer a switch as well, that could also be implemented, but would then probably require some additional work for supporting that in VEDA-FE.

Yes, it would be usable also together with FIXBOH, for periods beyond the fixed ones.
Reply
#8
very good, I think we should encourage users to use separate scenario files for these attributes and avoid the additional switch. As you rightly say, no point cluttering the interface. And as the switches can come from scenario files as well, careless users will be just as vulnerable even with a switch.
Reply
#9
Dear Amit and Antti,

Nice to se you so positive about this feature. If neede I would like to help you test a beta version.

Regards, 
Lisa Kvalbein
Reply
#10
Thanks Lisa.
As you presented strong support, and Amit also seemed supportive and willing to implement it, I can make it available in the next version of TIMES. Once the VEDA support is available as well, you could thus start testing with it.
Reply
#11
The latest TIMES v4.4.2 is now available for download, and so you could test the new feature. Let us know of any issues you may identify with it.

https://www.kanors-emr.org/download.php
Reply
#12
Dear Antti,

It would be helpful to see how a scenario file with the use of REG_BNDCAP would look like.

Regards,
Lisa Kvalbein
Reply
#13
I have not tested it under VEDA-FE, only under TIMES, but I think it should be straightforward:
In a ~TFM_INS table, put the year(s) up to which you want new capacities bounded into the AllRegions column or into columns for individual regions, and the Limtype in the Limtype column (I can see the default is FX in VEDA).  If you see some problems with that, I guess we would need Amit's help.
Reply
#14
Dear Amit,

I have now tried to get the REG_BNDCAP to work in Veda2.0, but I am not able to get it right. 

I created the scenario file as described, se the screenshot attached (ScenFile.png), but when syncing I get a warning that no records were generated for that row (errorMsg.png). As there is no GDX reference in the scenario file I guess the model would not know to what sizes capacities should be fixed. 

When running a model I try to use the GDX reference option in the run manager to set the old run I want the capacities to be fixed. In the option of Use Solution everything is fixed, not just the capacities. 

My question is if the scenario file is right, and how do I make the GDX reference?

Regards,
Lisa Kvalbein


Attached Files Thumbnail(s)
       
Reply
#15
the attribute is REG_BDNCAP. BD on NCAP, not BND on CAP.

and just click the "As starting point" option and let "Fix years upto" be None.
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)