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

simple.gms (239 Bytes)

This is the expected behaviour, as far as I understand.

From http://www.gams.com/latest/docs/userguides/userguide/_u_g__tutorial.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

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 non-linear 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/baron/index.html#BARON_NO_STARTING_POINT_IS_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

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

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 multi-start based on the initial point that hopefully results in good upper bounds). If one use non-linear 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 non-linear optimization.

-Michael