[petsc-dev] ML used from MATLAB interface

[Barry Smith]

On Dec 29, 2010, at 10:13 AM, Mark F. Adams wrote:

>> 
>> 
>> 2) somehow force the BLAS/LAPACK calls from the PETSc shared library to go to the regular BLAS/LAPACK and not Matlab's. I have no idea how to do this :-(.
>> 
>> Note that if hypre/superlu etc use an BLAS/LAPACK calls they __could__ have the same problem (as could the BLAS/LAPACK calls in PETSc) but it seems that sometimes (most of the time?) it uses the "regular" BLAS/LAPACK instead of MATLAB's funny one. I don't understand how or why this happens, perhaps if I understood we could get it to be "always".  It seems to get to the MATLAB ones for "less common" calls.
>> 
> 
> Just a note, ML (smoothed aggregation) requires an obscure LAPACK call, to get the explicit Q matrix from QR factorizations.  I've found that some LAPCK distributions (IBM) do not even have it.  So there might just be one call that you need to protect if its the "less common" routines that cause problems.

 It is curious that it is this odd-ball Lapack routine that gets mapped to the Matlab lapack and not others but I've verified that both libraries have it so it is not a matter of "it had to use that one".

   Barry

> 
> Mark
> 
>> Note also that PETSc handles the int argument to BLAS/LAPACK with PetscBLASInt which can, in theory be switched to use 64 bit integers and thus happily use the MATLAB BLAS/LAPACK I've tried changing this but have not been happy yet.
>> 
>> To make things even harder MATLAB has three libraries with the word blas in them and 2 with the word lapack.  In addition it appears to use some dynamic loading to get at the mkl libraries.
>> 
>> bsmith-laptop:petsc-dev barrysmith$ ls /Applications/MATLAB_R2010b.app/bin/maci64/*blas*
>> /Applications/MATLAB_R2010b.app/bin/maci64/blas.spec
>> /Applications/MATLAB_R2010b.app/bin/maci64/libmwblas.dylib
>> /Applications/MATLAB_R2010b.app/bin/maci64/libmwblascompat32.dylib
>> /Applications/MATLAB_R2010b.app/bin/maci64/refblas.dylib
>> bsmith-laptop:petsc-dev barrysmith$ ls /Applications/MATLAB_R2010b.app/bin/maci64/*lapack*
>> /Applications/MATLAB_R2010b.app/bin/maci64/libmwlapack.dylib
>> /Applications/MATLAB_R2010b.app/bin/maci64/mllapack.dylib
>> 
>> Note also if you think the Mac is bad, it seems to switch to the MATLAB Blas/lapack more under LINUX making the MATLAB interface for PETSc not all that usable at this point, while it is pretty usable from the Apple.
>> 
>> I'll screw around a little more to see if I can understand 2) better.
>> 
>> Barry
>> 
>> 
>> 
>> On Dec 27, 2010, at 11:44 AM, Dave May wrote:
>> 
>>> I'm trying to use PCML via the matlab interface with petsc-dev.
>>> 
>>> Every time -pc_type is set to "ml", I find matlab crashes. I've
>>> attached the matlab script I was using.
>>> I don't know the "best" way to track this crash down, but I've pasted
>>> what appears to be the interesting part reported by system stack trace
>>> (I've attached the entire trace in the rtf file).
>>> 
>>> Thread 3:
>>> 0   libSystem.B.dylib             	0x00007fff84201541 log + 145
>>> 1   mllapack.dylib                	0x000000014ea229b0 dsteqr_ + 2208
>>> 2   libpetsc.dylib                	0x000000014e104d3f
>>> ML_CG_ComputeEigenvalues + 2799 (ml_cg.c:384)
>>> 3   libpetsc.dylib                	0x000000014e106940 ML_Krylov_Solve
>>> + 112 (ml_krylov.c:370)
>>> 4   libpetsc.dylib                	0x000000014e0b0685
>>> ML_AGG_Gen_Prolongator + 3141 (ml_agg_genP.c:531)
>>> 5   libpetsc.dylib                	0x000000014e0aeb18
>>> ML_Gen_MultiLevelHierarchy + 2600 (ml_agg_genP.c:2559)
>>> 6   libpetsc.dylib                	0x000000014e0af4c4
>>> ML_Gen_MultiLevelHierarchy_UsingAggregation + 564 (ml_agg_genP.c:2444)
>>> 7   libpetsc.dylib                	0x000000014da60c91 PCSetUp_ML +
>>> 3173 (ml.c:601)
>>> 8   libpetsc.dylib                	0x000000014dc08eeb PCSetUp + 2076
>>> (precon.c:785)
>>> 
>>> It appears that the symbol dsteqr called by ML_CG_ComputeEigenvalues()
>>> is taken from matlab's own lapack library.
>>> Does this sound like the right thing which should happen, or is this a
>>> configuration problem on my end?
>>> I've attached the configure.log in case.
>>> 
>>> I should also point out that I can reliably call hypre through the
>>> matlab interface without any crashes.
>>> 
>>> If there are any tips for debugging this type of error, please let me know.  :)
>>> And let me know if this type of discussion should be moved over to
>>> petsc-dev rather than maint.
>>> 
>>> Cheers,
>>> Dave
>>> 
>>> Additional info:
>>> 
>>> Matlab version: 7.11.0.584 (R2010b), 64bit
>>> OS Version: Darwin geop-217.ethz.ch 10.5.0 Darwin Kernel Version
>>> 10.5.0: Fri Nov  5 23:20:39 PDT 2010;
>>> root:xnu-1504.9.17~1/RELEASE_I386 i386
>>> 
>>> <PCSetUp_ML.rtf><exml.m><configure.log.tar.gz>
>> 
>> 
>