Page 1 of 1

GAMS is not responding

Posted: Mon Mar 27, 2017 6:10 pm
by conor
I am solving a problem in GAMS using the SNOPT solver. I am working with nonlinear problem, so I use an iterative procedure randomizing my starting values for variables.

My question is: every once and a while (maybe every 500-1000 tries) a popup will appear letting me know that GAMS has stopped working. The program will then pause until I close the popup, then it will resume where I left off.

The crashing itself is not an issue (I run a few thousand times over the course of ~24 hours compute time), but the fact that it pauses is. It is difficult to babysit the computer via remote desktop and close the "has stopped working" popup, as soon as it comes up (i.e. in the middle of the
night) so this slows my computations down considerably.

Is there a way to fix it so that this popup does not appear, or can be closed automatically?

This is running on Windows 10, 64 bit. GAMS 24.8.

Thanks in advance!

Re: GAMS is not responding

Posted: Mon Mar 27, 2017 9:22 pm
by bussieck

First it would be good to figure out why some program in the GAMS distribution fails this badly. If we (i.e. could reproduce such a run we could potentially suggest how avoid the problem (and fix the problem). Is it the solver (gmsgennx.exe) that crashes or gams itself (gamscmex.exe). If it is gamscmex.exe it could be still the solver if you solve with solvelink=5. Anyhow, you can also suppress the "has stopped working" dialog. There is a nice post about this at ... rver-2008/



Re: GAMS is not responding

Posted: Tue Mar 28, 2017 3:50 pm
by conor
It is gmsgennx.exe that is responsible for the crashing. The crashes are fairly sporadic, and I am not sure exactly how to reproduce them, but if I end up with extra time, I can try.

Thank you for the tip on silencing Windows error reporting!


Re: GAMS is not responding

Posted: Thu Mar 30, 2017 10:44 am
by bussieck
gmsgennx.exe is indeed the solver. SNOPT is a fairly stable solver and we don't see crashes with "good" models. Perhaps the the numerics of the model cause some trouble. If you get a crash the model status will be 13. In this case you can just zip up the scratch directory and send this to support and if we can reproduce this, then we (or the SNOPT developer) can look into ways how to avoid this:

Code: Select all

solve mymodel min z using nlp;
if (mymodel.modelstat=13, execute 'gmszip -r "%gams.scrdir%"');