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

[Andreas Waechter]

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.

This is all correct.

Each iterate that Ipopt accepts is such that the problem functions can be 
evaluated.  After Ipopt computed a search direction it does a line search, 
where it evaluates the problem functions (but not their derivatives) at 
the "trial points".  If at a trial point an evaulation callback function 
returns false, or if the returned value(s) contain a non-finite number 
(such as Inf or NaN), then this trial step is not accepted, and another 
trial step is computed, until a point is found where the functions can be 
evaluations.

Note that a trial point might be accepted if the function values can be 
evaluated, but the derivatives can't.  In that case, Ipopt might continue 
and produce NaN values.  In order to make sure that the algorithm stops in 
that case with a proper error message, you can set the option 
"check_derivatives_for_naninf" to "yes". However, Ipopt will still fail, 
but at least not with a criptic error.  In order to safe computation time, 
the default of this option is "no".

>> 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.

Yes.  Or you can just return "NaN" in the objective function or an 
constraint value, and Ipopt will catch it for you.

Cheers

Andreas