[Ipopt] problems on OS X 10.7 Lion

[Ray Zimmerman]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.coin-or.org/pipermail/ipopt/attachments/20111014/1bdd935f/attachment.html>