For technology comparison, it is very useful to have the cost/benefit ratios or the competitiveness gaps. Thanks to Antti, it is implemented in the TIMES code. From his presentation in Stockholm, I understood we should use $SET BENCOST YES.
I added this in the Run file, but no new parameter appears. Not in Back-end and not in .gdx results file. From my past experience, I added objrng VAR_NCAP and rngrestart timesrng.incin cplex.opt. It produces a timesrng.inc with the ranging information for VAR_NCAP, but I still do not see the information appearing in the .gdx results file.
What exactly do I need to do to see the new cost information in Back-end ?
20-09-2010, 10:08 AM (This post was last modified: 20-09-2010, 10:14 AM by Antti-L.)
If I understand correctly, you are not seeing the VAR_NCAPR reporting attribute in VEDA-BE.
When the setting $SET BENCOST YES is used, this attribute should include the following indicators:
COST - the total cost coefficient of VAR_NCAP (in terms of investment costs)
CGAP - competitiveness gap (in terms of investment costs),
obtained directly from the VAR_NCAP marginals (and optional ranging
information)
GGAP - competitiveness gap (in terms of investment costs), obtained by
checking also the VAR_ACT, VAR_FLO and VAR_CAP marginals, in case
VAR_NCAP happens to be basic at zero
RATIO - benefit / cost ratio, based on CGAP
GRATIO - benefit / cost ratio, based on GGAP
RNGLO - ranging information (LO) for VAR_NCAP (when activated; in terms of investment costs)
RNGUP - ranging information (UP) for VAR_NCAP (when activated; in terms of investment costs)
It is strange if you are not getting these indicators reported. In my tests they do appear.
It seems that by adding $SET BENCOST YES to the Runfile, no ranging happens and no VAR_NCAPR is reported. I use Gams_srcTIMESv306. Is this the only action required ? Thanks again,
20-09-2010, 11:36 AM (This post was last modified: 20-09-2010, 11:43 AM by Antti-L.)
Yes, that's the required setting, which works at least with versions 3.0.4 and above. In addition, you should add the following lines into the file cplex.opt if you want to activate ranging:
objrng VAR_NCAP rngrestart timesrng.inc
If it doesn't work for you, while it does work for me, I can only say that I am very puzzled. I hope you understand that, on the basis of the information you have given, it is impossible for me to figure out why it does not work for you.
It is working now. Since only a change in the Runfile is required, I double checked this file.
I moved $SET BENCOST YES to the beginning of the Runfile and now it is working.
Although it is may be evident, it is good for everybody to know that it has to be in the "body" of the Runfile.
Glad I can use the routine now !
Another small question is related to damage cost. I don't get damage costs in the results although there are values for DAM_COST in Veda Front-End and I ask "Damage LP" to be used.
Hmmm... this is interesting. When I run a small test model including damage costs with GAMS v22.0, the damage equations are created and the costs are reported as expected. But when I run the same model with a newer version of GAMS (23.3), the damage equations are not generated and the damage costs are thus neither reported!
I must investigate this in some more detail. My initial impression is that the newer GAMS versions may have a bug, but I may be able to find a workaround for it.
If you can test with GAMS 22.0, could you please confirm whether that version works for you?
Indeed, it seems that I can now confirm that there appears to be a problem in some of the newer versions of GAMS, causing loss of user-specified data. For now, I have only tested GAMS v23.3 versus my "last known good version", GAMS v22.0. However, there may be also newer versions of GAMS that don't manifest the problem. Depending on the assessor, the problem might also be called "a serious break in backwards compatibility", but on the basis of the existing documentation and my tests so far, I would myself definitely call it a bug.
Specifically, with respect to Damage costs, GAMS version 23.3 appers to delete all user-specified input data for DAM_COST, without any warning. As long as I don't have the full picture of possible other implications for TIMES, I must warn that data might get deleted also from other parameters. Therefore, at this point I can only recommend downgrading (or upgrading, assuming that it has been fixed in the latest versions) to a version of GAMS not manifesting this problem.
Attached please find a small GAMS test file. If you get an error when running this GAMS program, you are vulnerable to this problem: uploads/30/testgams.zip
Thanks for testing the latest version of GAMS. I myself tested with v23.0 and that one also worked without manifesting the problem. Hence, it seems that the bug has been introduced some time after v23.0, but has been fixed in the latest version. This is good news, because it means that only some TIMES users will be affected, and they should all have the possibility to downgrade or upgrade in order to avoid the bug.
Nonetheless, I will change the TIMES code a bit in the next version, such that the Damage costs would work also with those broken GAMS versions between 23.0 and 23.5.