[Ipopt] NaN's on eval_f

Stefan Vigerske stefan at math.hu-berlin.de
Sat Dec 21 12:13:04 EST 2013


the post you cite states that Ipopt tries to work with function 
evaluation issues during line search. If you start Ipopt at a point that 
cannot be evaluated or Ipopt is not able to find any steplength that 
gives a point in the domain of all functions, then it will stop.

If you cannot evaluate your objective in some point, you should return 
false from eval_f. This will tell Ipopt that you could not evaluate the 
point and that it should try a smaller steplength.


On 12/21/2013 01:25 PM, Marco Correia wrote:
> Hi,
>  From what I understood from this post (
> http://list.coin-or.org/pipermail/ipopt/2006-November/000655.html) one
> may safely set the objective value to NaN or a Inf from the eval_f
> callback.
>   (by the way, in this case "Inf" is really the
> std::numeric_limits<double>::infinity() and not the 1e19 constants, right?)
> I have a problem that is returning a NaN from eval_f and where Ipopt is
> calling finalize_solution with
> status==Ipopt::SolverReturn::INVALID_NUMBER_DETECTED.
> I would like to know if setting the objective to NaN in eval_f could
> generate this status error.
> Some more information:
> - I am allowing the objective value to be NaN or Inf, but I'm always
> returning true from eval_f function.
> - The option "check_derivatives_for_naninf"  doesn't seem to make any
> difference.
> Thanks!
> Marco Correia
> _______________________________________________
> Ipopt mailing list
> Ipopt at list.coin-or.org
> http://list.coin-or.org/mailman/listinfo/ipopt

More information about the Ipopt mailing list