[Ipopt] problems on OS X 10.7 Lion

Tue Oct 18 12:44:41 EDT 2011

Passing in -fdefault-integer-8 is probably not going to work unless 
you've done some major hacking; ipfint is typedefed in config.h, and if 
it is a 4-byte type things will not be good for you.

Have you used "otool -L" to make sure that the blas/lapack linking is 
working the way you think it is?  I would focus on getting it to work 
with Netlib blas first, then veclib.

Tom

On 10/18/2011 09:18 AM, Ray Zimmerman wrote:
> 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> 
>>>> <mailto:Ipopt at list.coin-or.org>
>>>> http://list.coin-or.org/mailman/listinfo/ipopt
>>>
>>>
>>>
>>> _______________________________________________
>>> Ipopt mailing list
>>> Ipopt at list.coin-or.org <mailto: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 <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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.coin-or.org/pipermail/ipopt/attachments/20111018/68dddfc7/attachment-0001.html>