[Coin-ipopt] Function/Gradient Evaluations in IPOPT callbacks

[Stefan Vigerske]

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