[petsc-dev] BLAS/LAPACK with PETSc MATLAB interface

[Barry Smith]

  Dave,

    Ok, I have "solved" the problem (though Satish will likely hate my solution). 

    Tried a bunch of things even using objcopy to change the symbol names (but  objcopy doesn't yet handle 64 bit Mac OS X dynamic libraries properly). Ghastly nightmare.

    Anyways, in poking around I discovered that the MATLAB BLAS/LAPACK libraries only contain the _ version on the Mac (haven't checked Linux). This means if we can build PETSc with BLAS/LAPACK with a different name mangling then there will be no identical symbols and hence no problems with using the wrong function. So I changed the --download-c-blas-lapack libraries to NOT use any name mangling in the function names and fixed all the places that know about the f2c libraries to handle the no name mangling.  (Fortunately ML, hypre and many of the external packages handle correctly the three variants of BLAS/LAPACK name mangling).

   What you need to do.

rm ${PETSC_ARCH}/conf/ml ${PETSC_ARCH}/conf/hypre
rm -rf externalpackages/f2c*
hg pull; hg update;
pushd config/BuildSystem; hg pull; hg update; popd
${PETSC_ARCH/conf/reconfigure*.py --download-c-blas-lapack
make all 

  Works for me, so should work for you. Let me know if you have any problems. If you could test on Linux that would be great also!

  Barry

Note you only need the --download-c-blas-lapack with 64 bit MATLAB versions


On Dec 28, 2010, at 12:08 PM, Dave May wrote:

> Hi Barry,
>  I can confirm that problem I reported with PCML does indeed
> disappear if I use 2010a, 32 bit Matlab.
> I haven't tried pursue making the 64 bit version work.
> 
> Cheers,
>  Dave
> 
> 
> On 27 December 2010 19:53, Barry Smith <bsmith at mcs.anl.gov> wrote:
>> 
>>  Dave,
>> 
>>    We've seen this problem in spades on Linux. It seems that it is passing some (but only some) Blas/Lapack calls to Matlab's copy of Blas/Lapack instead of the Blas/Lapack linked with PETSc. This is a problem on 64 bit Matlab because 64 bit Matlab uses 64 bit integers and hence its copy of Blas/Lapack expects 64 bit integers while PETSc (of course) uses the normal 32 bit integer Blas/Lapack. At least we think this is the problem.
>> 
>>   You could try the 2010a 32 bit Matlab and see if you get the same problem. Or (harder) build PETSc to use 64 bit PetscBLASInt and link against appropriate Blas/Lapack; note that we don't have a mechanism to automatically use 64 bit integers and you need to edit petscsys.h to change PetscBLASInt and we've never tried it.
>> 
>>  I'll try to reproduce this problem if I have time but got lots of things on my stack at the moment.
>> 
>>   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>
>> 
>> 
>