[Ipopt] problems on OS X 10.7 Lion
Andreas Waechter
waechter at iems.northwestern.edu
Fri Oct 14 17:53:14 EDT 2011
If you set the (file_)print_level large enough, you can see what matrix
entries are given to the linear solver, and what the linear solver returns.
Maybe there are some Nan/Inf ?
On Fri, Oct 14, 2011 at 4:10 PM, Ray Zimmerman <rz10 at cornell.edu> wrote:
> Here's an update ...
>
> 1. As I suspected, it's unrelated to the hardware specs. When I rebooted
> the machine under Snow Leopard, my MEX builds work fine. I only mention this
> since I have encountered software for which the 64 GB of RAM triggered bugs.
>
> 2. After upgrading to Mac OS X 10.7.2 and Xcode 4.2, I see no change.
>
> 3. I was able to successfully compile Ipopt and the MEX interface using
> MA57 as the linear solver instead of MUMPS. In this case, the 'make test'
> step for Ipopt does not show any failures, at least in the several attempts
> I tried. However, the MEX file, while it executes, does not pass most of my
> tests and still spits out lots of ...
>
> WARNING: Problem in step computation; switching to emergency mode.
>
> ... even for the examples in Ipopt/contrib/MatlabInterface/examples.
>
> Any ideas?
>
> --
> Ray Zimmerman
> Senior Research Associate
> 419A Warren Hall, Cornell University, Ithaca, NY 14853
> phone: (607) 255-9645
>
>
>
>
> On Oct 12, 2011, at 12:49 PM, Ray Zimmerman wrote:
>
> I used the same basic instructions as in my previous post about building
> Ipopt and the Matlab interface on Mac OS X Snow Leopard (http://list.coin-
> or.org/pipermail/ipopt/2011-October/002609.html) to attempt to build them
> on a different machine running OS X Lion 10.7.1, with the dev tools from
> XCode 4.1 and the gfortran for Lion (gfortran-lion-5666-3.pkg from
> http://r.research.att.com/tools/).
>
> Everything builds just fine, but when I run 'make test' for Ipopt in step
> 4. I get inconsistent results. Sometimes it passes all 3 tests, sometimes it
> fails one or more of the tests, and when they fail, it's always in the same
> way, with the following sort of output.
>
> iter objective inf_pr inf_du lg(mu) ||d|| lg(rg) alpha_du
> alpha_pr ls
> 0 1.6109693e+01 1.12e+01 1.21e+01 0.0 0.00e+00 - 0.00e+00
> 0.00e+00 0
> WARNING: Problem in step computation; switching to emergency mode.
> 1r 1.6109693e+01 1.12e+01 9.99e+02 1.1 0.00e+00 20.0 0.00e+00
> 0.00e+00R 1
> WARNING: Problem in step computation; switching to emergency mode.
> Restoration phase is called at point that is almost feasible,
> with constraint violation 0.000000e+00. Abort.
> Restoration phase in the restoration phase failed.
>
> I get this with both 32-bit and 64-bit builds.
>
> I assume this is related to MUMPS? Any ideas?
>
> I should mention that this is on a 12-core Mac Pro with 64 GB RAM, in case
> those specs would somehow come into play. I've also noticed that using a MEX
> file on this machine that I built under Snow Leopard on my MacBook Pro often
> results in failures as well with the same warning about "problem in step
> computation".
>
> My next step is to try building with Pardiso or another linear solver to
> see if that fixes it, but if anyone has any ideas what might be causing
> this, I'd love to hear them.
>
> --
> Ray Zimmerman
> Senior Research Associate
> 419A Warren Hall, Cornell University, Ithaca, NY 14853
> phone: (607) 255-9645
>
>
>
>
> _______________________________________________
> Ipopt mailing list
> Ipopt at list.coin-or.org
> http://list.coin-or.org/mailman/listinfo/ipopt
>
>
>
> _______________________________________________
> Ipopt mailing list
> Ipopt at list.coin-or.org
> http://list.coin-or.org/mailman/listinfo/ipopt
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.coin-or.org/pipermail/ipopt/attachments/20111014/c16ffb20/attachment-0001.html>
More information about the Ipopt
mailing list