After running my model I get the attached message, GAMS basically says "Solution available but not proven optimal due to numerical difficulties", do you have any idea what I should do and how I can debug my model? I get this message after changing a small things, however, since we have dummy variables I think the model should solve and give me dummy imports wherever the problem is.
TIMES triggers an abort when the solution status appears erroneous. This is checked from the GAMS modelStat parameter, which can have the following values:
1 Optimal solution achieved
2 Local optimal solution achieved (Only type found in an NLP)
3 Unbounded model found
4 Infeasible model found
5 Locally infeasible model found (in NLPs)
6 Solver terminated early and model was infeasible
7 Solver terminated early and model was feasible but not yet optimal
8 Integer solution model found
9 Solver terminated early with a non integer solution found (only in MIPs)
10 No feasible integer solution could be found
11 Licensing problem
12 Error achieved – No cause known
13 Error achieved – No solution attained
The abort is triggered when the status is not one of {1,2,8}.
I am not sure which value is returned in your case. Do you know?
But this is done in a file called err_stat.mod in the TIMES source code folder.
You could try editing this file, putting the following line at the top:
$EXIT
Then try running again, and the error check should be by-passed.
Thank you! Where can I find GAMS modelStat parameter?
In the lst file I have:
**** Exec Error at line 316392: Execution halted: abort$1 '*** ERRORS IN OPTIMIZATION ***'
11-12-2017, 12:20 AM (This post was last modified: 11-12-2017, 12:20 AM by Antti-L.)
The numerical value can only be found with GAMS code. The description should be found in the file END_GAMS.
At a second look, I can see now that the SET ERR_ABORT NO switch unfortunately does not work for the bad solution statuses.
But I will make sure that it will work in the next release. Therefore, meanwhile, you can try editing the file...
Finished reading from "C:\VEDA\VEDA_FE\GAMS_WrkTIMES_WECC\cplex.opt"
Space for names approximately 101.23 Mb
Use option 'names no' to turn use of names off
LP status(6): non-optimal
Cplex Time: 1667.78sec (det. 1218820.95 ticks)
Solution available but not proven optimal due to numerical difficulties.
11-12-2017, 04:30 AM (This post was last modified: 11-12-2017, 04:32 AM by Antti-L.)
(10-12-2017, 11:18 PM)Antti-L Wrote: You could try editing this file, putting the following line at the top:
$EXIT
Was that "at the top" not clear, meaning top of the file?
Anyway, please note that this suggestion is meant only as a "temporary workaround". Editing the TIMES code by your own is, in general, discouraged, because you will then not have ETSAP support, reproducibility etc.
Ok, my bad. I didn't edit the code myself, but it is good that you saw how editing the TIMES code by yourself may lead to problems. I now tried it myself, and the following works at the top:
$IF DEFINED TIMES $EXIT
However, I would again like to stress that such an edit should only be used for a temporary workaround, and you should take the updated TIMES code at the next release (available within the next few weeks).
16-12-2017, 05:27 AM (This post was last modified: 16-12-2017, 05:50 AM by saleh.)
Thank you, but even with doing that I still get "Solution available but not proven optimal due to numerical difficulties", I'm using CPLEX and the LP status is 6 in this case.
I know that using that option doesn't help the model to solve it properly and probably it leads to generating vd file even in this case, however, I wonder about the cause of this problem and how we can debug it.
At the start of the thread you said:
"…however, since we have dummy variables I think the model should solve and give me dummy imports wherever the problem is."
Consequently, I understood that you would like to obtain the solution, so that you can investigate yourself where the problem is.
But now you are asking about the cause of the problem and how you can debug it. However, we had a similar discussion already in February 2016, where I also already gave my answers to it. See here: Solution is available, but not proved optimal
I think the answers I gave then remain valid to your current problem.
In particular, if you have specified artificially high costs for some processes, you are deliberately seeking trouble with numerical problems. For example, if you have the dummy import processes enabled, you should make sure that the costs for them are reasonably low. Better yet, disable the dummy imports completely.
Looking at the model files you provided to me recently, I can see you have ignored my earlier advice, and instead you have defined even extremely high costs, like the ones below I found in your SysSettings (unit cost 10**10) :
PARAMETER ACT_COST ' '/
CA.2010.IMPMATZ.CUR 10000000000
CA.2010.IMPDEMZ.CUR 10000000000
CA.2010.IMPNRGZ.CUR 10000000000
/
I also found some extremely high bound values (ACT_BND, COM_BNDNET), and some very high investment costs (NCAP_COST) in that model. In general, one should never use artificially high costs for the purpose of disabling processes.
Thak you very much Antti for your help, we managed to resolve the previous problem and I completely forgot about our previous discussion, thank you for reminding me, that's definitely helpful!