[Coin-ipopt] Function/Gradient Evaluations in IPOPT callbacks
Stefan Vigerske
stefan at math.hu-berlin.de
Tue Nov 14 04:16:19 EST 2006
Hi,
> When evaluating the functions or gradients for IPOPT in it's designated call
> back functions (e.g. eval_grad_f, eval_g),
> sometimes given the current iterate values fed from IPOPT solver (i.e. Number
> *x), my function or gradients may evaluate to "NaN" or may need to throw an
> exception, because "x" may not be defined for the function (e.g. ln(x[1]) where
> x[1] < 0).
>
> So the question is:
> Does IPOPT actually detects and handles these abnormal situations (e.g. it
> catches some exception or takes some kind of message from the callback)?
As far as I know you should return "false" in the evaluation methods in
case that something goes wrong, like the function (or its derivative) is
not defined in this point.
> If IPOPT handles it, how is it done -- does IPOPT quit naturally or try to
> change or reverse the search direction?
I think I've once been reading that if IPOPT is at a feasible point and
want to make a step forward, then they shorten the steplength in order
to stay in the area where the functions are defined.
> Can anybody tell me how and/or refer me to a good reference or some examples
> somewhere?
>
> As an example, if my natural log evaluation returns NaN, I may be instructed to
> throw something like a "IPOPTFunctionInvalidException" (which could defined in
> one of IPOPT's header file) and hopefully IPOPT can just carry on.
I think you just need to return false in such a case.
Stefan
--
Stefan Vigerske
Humboldt University Berlin, Numerical Mathematics
http://www.math.hu-berlin.de/~stefan
More information about the Coin-ipopt
mailing list