Dear all,
I noticed that GAMS fails to start the optimization algorithm if the objective function or one
of the constraints is not well defined at the origin. Take the attached example for illustration.
It models
min f(x) = x1 / x2
s.t x1 + x2 >= 3, x1  2*x2 >= 3, x2  2*x1 >= 3.
This problem is well defined in the feasible domain and all solvers tested so far (antigone,
baron, lindoglobal, scip, couenne, knitro, msnlp and ipopt) fail to start the optimization with
the error message "Exec Error at line 5: division by zero(0)".
Note that if we include an initial starting point with x2 != 0 then everything works fine.
There are many other problems that fail on all solvers for the same reason; this is only
the simplest of them.
In this test I'm running Gams 24.8.2
Kind regards,
Tiago
Problems with the initial point
Problems with the initial point
 Attachments

 simple.gms
 (239 Bytes) Downloaded 38 times

 User
 Posts: 75
 Joined: 1 year ago
Re: Problems with the initial point
This is the expected behaviour, as far as I understand.
From http://www.gams.com/latest/docs/usergui ... orial.html:
"The default initial level is zero unless zero is not within the bounded range, in which case it is the bound closest to zero"
This is of course not convenient for nonlinear functions which are not defined at zero.
I think you are expecting the GAMS engine to figure out the variable domain implicit in the constraints. As far as I understand, it does not do this.
My guess is some solvers might do it as a preprocessing step, so perhaps some of the experts here may be able to provide you a way to ignore execution errors and let the solver try to handle this.
The usual advice, and real world practice of optimization is: NLP is not as easy as it seems, initialization and bounding have drastic effects on the result.
Why wouldn't you provide a initial value for your variables where your objective function is well defined ?
Good luck!
Claudio
From http://www.gams.com/latest/docs/usergui ... orial.html:
"The default initial level is zero unless zero is not within the bounded range, in which case it is the bound closest to zero"
This is of course not convenient for nonlinear functions which are not defined at zero.
I think you are expecting the GAMS engine to figure out the variable domain implicit in the constraints. As far as I understand, it does not do this.
My guess is some solvers might do it as a preprocessing step, so perhaps some of the experts here may be able to provide you a way to ignore execution errors and let the solver try to handle this.
The usual advice, and real world practice of optimization is: NLP is not as easy as it seems, initialization and bounding have drastic effects on the result.
Why wouldn't you provide a initial value for your variables where your objective function is well defined ?
Good luck!
Claudio
Re: Problems with the initial point
Local NLP solvers need a good starting point to improve on. The starting point you provide (0,0) can't be evaluated and hence the solver could not compute a direction that improves the situation. Hence GAMS checks if the starting point can be calculated. If not, GAMS will not pass the model to the solver. With the dawn of global solvers (around year 2000) the importance of a starting point for a solve of a nonlinear model became less important and GAMS introduced an obscure option sys12 to allow sending a model to the solver independent of the starting point can be evaluated or not, see http://www.gams.com/latest/docs/solvers ... S_REQUIRED. So if you start your model simple with additional command line parameters "sys12=1 execerr=2e9 nlp=baron" you will get a successful run.
Michael
Michael
Re: Problems with the initial point
Thank you for your messages.
This test takes only complete global optimization solvers into account. Therefore the starting
point should not be so important since one reason to use a global optimization solvers in
practice is the ignorance about good starting points.
The sys12 option works fine for baron, antigone, lindoglobal and scip. Maybe you should
consider to make this option a default for complete solvers.
Regards,
Tiago
This test takes only complete global optimization solvers into account. Therefore the starting
point should not be so important since one reason to use a global optimization solvers in
practice is the ignorance about good starting points.
The sys12 option works fine for baron, antigone, lindoglobal and scip. Maybe you should
consider to make this option a default for complete solvers.
Regards,
Tiago
Re: Problems with the initial point
Tiago,
I agree that we should make sys12 more visible and give it a better name, but I also believe that this is a good default. Even global solvers benefit from a good starting point because they use local solvers for local search (e.g. BARON does a multistart based on the initial point that hopefully results in good upper bounds). If one use nonlinear optimization the starting point is still something important and not generating an evaluation error at the starting point is a good practice and makes the user aware of the potential issues one faces with nonlinear optimization.
Michael
I agree that we should make sys12 more visible and give it a better name, but I also believe that this is a good default. Even global solvers benefit from a good starting point because they use local solvers for local search (e.g. BARON does a multistart based on the initial point that hopefully results in good upper bounds). If one use nonlinear optimization the starting point is still something important and not generating an evaluation error at the starting point is a good practice and makes the user aware of the potential issues one faces with nonlinear optimization.
Michael