[Ipopt] problems on OS X 10.7 Lion

Tue Oct 18 10:18:49 EDT 2011

Thanks for the suggestion.

I'm inclined to think that I'm encountering a single problem (when it manifests, the symptom is the same) and it is not related to Matlab, since it occurs at the 'make test' stage of the Ipopt build when using MUMPS, before even attempting to build the Matlab interface. In this case, adding ' -fdefault-integer-8' to the FFLAGS passed to configure allows it to compile and link just fine, but it results in the following error when running make test:

Testing C++ Example...

 ---- 8< ---- Start of test program output ---- 8< ----
  ** Instance Error 1 in DMUMPS_F77                    0
 ** MPI_ABORT called
 ---- 8< ----  End of test program output  ---- 8< ----

    ******** Test FAILED! ********
Output of the test program is above.

Likewise for the C and Fortran tests. I'm not sure what this means, but I get the same result with both the system BLAS/LAPACK (-framework vecLib) or with the ones I can download with get.Blas and get.Lapack in the ThirdParty directory.

So, I'm thinking that if I can get 'make test' to pass consistently for a build with MUMPS, it will probably fix the issue with the Matlab MEX file as well.

-- 
Ray Zimmerman
Senior Research Associate
419A Warren Hall, Cornell University, Ithaca, NY 14853
phone: (607) 255-9645

On Oct 17, 2011, at 3:39 AM, Jonathan Hogg wrote:

> I'm not too familiar with the Ipopt matlab interface, and this may already be taken care of there, but given the variety of different Fortran compilers recommended by Mathworks on different platforms it might not be:
> 
> One generic problem with matlab mex files is that you need to be careful which BLAS you end up using - matlab's own BLAS library is ILP64, which won't work with most Fortran compilers unless you've forced default integer to be 64-bit (gfortran -fdefault-integer-8). Alternatively link against a standard BLAS library rather than Matlab's.
> 
> It may be worth checking if this is the case? It would certainly be one explanation for the errors you are reporting.
> 
> Jonathan.
> 
> On 14/10/11 22:10, Ray Zimmerman 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-
>>> <http://list.coin-/>or.org/pipermail/ipopt/2011-October/002609.html
>>> <http://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 <mailto: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
> 
> -- 
> Scanned by iCritical.
> _______________________________________________
> 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/20111018/24f3b3bb/attachment-0001.html>