[Ipopt] Matlab interface crashes for limited memory Hessian

[Jonathan Hogg]

This is a problem we've had with the HSL matlab interfaces, though we've 
found that linking against your desired BLAS library that uses the 
standard interface rather than libmwlapack and libmwblas solves the 
problem. Did the backtrace you got involving linking against these in 
addition to goto?

An alternative to wrapping the BLAS for MA27/MA57 is to force default 
integer to 64-bit when compiling (e.g. gfortran -fdefault-integer-8). 
This will slow them down as it doubles the memory traffic associated 
with the integer data (particularly bad for the solve phase).

I see this as a Mathworks problem, as they are the only ones I am aware 
of that provide only the 64-bit integer BLAS interface. The proper way 
to address this problem would be to provide both 32-bit and 64-bit 
options at link time in much the same way that the Intel MKL does 
(though I have yet to come across a situation where any of the BLAS 
parameters wanted to be bigger than the largest 32-bit integer, and 
we've had to spend a significant amount of time adjusting our solvers to 
cope with 64-bit in a nice way. I suspect BLAS1 are the only case this 
is likely to happen in for several years).

Jonathan.

On 13/03/11 17:50, Tom Vacek wrote:
> Follow-up:
>
> The problem is caused by an API difference between mwblas/mwlapack and
> the prototypes in IpBlas.cpp/IpLapackcpp.  mwblas/mwlapack uses an
> 8-byte integral type whereas ipfint is typedef-ed as int, which is 4
> bytes on my system (Ubuntu x86_64).  Given the backtrace I reported
> below, the problem is obvious.
>
> I suspect that the behavior reported in the backtrace is caused by a
> name space collision.  The symbols in my libgoto2 are the same as those
> in mwblas, and the collision occurs when both libraries are loaded.  I
> have no idea why the problem seems to arise only when the limited memory
> Hessian option is invoked.
>
> I hacked a solution by modifying the IpBlas.cpp and IpLapack.cpp files
> to reflect the matlab API.  I also had to write FORTRAN wrappers for
> blas calls in ma57.  Then I linked everything to mwblas/mwlapack.
> Everything works!  In hindsight, it might have been easier to redefine
> the ipfint, Index, and Int types to int64_t.
>
> Finally, I think it would be good practice to encourage users to supply
> cblas and clapack headers, so that they would get a compiler error if
> the API did not match the assumed one.
>
> Thanks,
>
> Tom
>
>
>
> On 03/11/2011 06:26 PM, Thomas Vacek wrote:
>> This is a follow up on the Matlab interface problem when using the
>> Hessian approximation.  In short, my mex file has no dependency on mwlapack:
>>
>> % ldd ipopt.mexa64
>>       linux-vdso.so.1 =>    (0x00007fff1ddff000)
>>       libipopt.so.1 =>
>> /home/it02/vacek008/Linux-x86_64/lib/coin/libipopt.so.1 (0x00007f1757d32000)
>>       libdl.so.2 =>   /lib/libdl.so.2 (0x00007f1757b07000)
>>       libcoinhsl.so.1 =>
>> /home/it02/vacek008/Linux-x86_64/lib/coin/ThirdParty/libcoinhsl.so.1
>> (0x00007f17578d7000)
>>       libgoto2.so =>   /home/it02/vacek008/Linux-x86_64/lib/libgoto2.so
>> (0x00007f1756c07000)
>>       libmetis.so.1 =>   /home/it02/vacek008/Linux-x86_64/lib/libmetis.so.1
>> (0x00007f17569bf000)
>>       libgfortran.so.3 =>   /soft/gcc-4.3/ubuntuamd1/lib64/libgfortran.so.3
>> (0x00007f17567e5000)
>>       libgcc_s.so.1 =>   /soft/gcc-4.3/ubuntuamd1/lib64/libgcc_s.so.1
>> (0x00007f17566ce000)
>>       libmx.so =>   not found
>>       libmex.so =>   not found
>>       libmat.so =>   not found
>>       libm.so.6 =>   /lib/libm.so.6 (0x00007f1756449000)
>>       libstdc++.so.6 =>   /soft/gcc-4.3/ubuntuamd1/lib64/libstdc++.so.6
>> (0x00007f1756244000)
>>       libpthread.so.0 =>   /lib/libpthread.so.0 (0x00007f1756027000)
>>       libc.so.6 =>   /lib/libc.so.6 (0x00007f1755ca3000)
>>       /lib64/ld-linux-x86-64.so.2 (0x00007f17584c0000)
>>
>> But yet a backtrace in GDB shows that the Lapack library being used is
>> actually mwlapack:
>>
>> #0  0x00007fffeb99ed6d in dpotrf_ ()
>>      from
>> /soft/matlab2010b/bin/glnxa64/../../bin/glnxa64/../../bin/glnxa64/../../bin/glnxa64/libmwlapack.so
>> #1  0x00007fffd92f0506 in Ipopt::IpLapackDpotrf (ndim=1, a=0x3e7aa90,
>> lda=1, info=@0x7fffe8781ed0) at IpLapack.cpp:76
>> #2  0x00007fffd92e5341 in Ipopt::DenseGenMatrix::ComputeCholeskyFactor
>> (this=0x3e7aa20, M=...) at IpDenseGenMatrix.cpp:156
>> ...
>>
>> I assume that the C wrappers are different, and hence the problem.  Does
>> anyone have other ideas?  How can I make Matlab use the Blas library
>> that the code is really linked to?  I'll ask about this on the Matlab
>> forum, too.
>>
>> Thanks!
>>
>> _______________________________________________
>> 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

-- 
Scanned by iCritical.