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> >> >> >
