Re: [SciPy-user] Numpy/Scipy on AIX
I'm using svn version of scipy. As far as i observed scipy 0.5.2 is not compatibile with numpy-svn. Below i'm pasting what setup.py produces. I seems things are compiled and there is only linking problem with lapack. Thanks for help.
Where are your blas and lapack coming from ? Did you compile them by yourself ? How ? (compiler, version, etc...)
I'm using IBM(R) XL Fortran Enterprise Edition V9.1 and IBM(R) XL C Enterprise Edition V7.0. Maybe there is some incompatibility between compilers for Fortran and C? That's what is installed on the machine i'm working on. I have to compile lapack by myself (actually scipy installer can do that), this is lapack-lite-3.1.1 downloaded from the web, and blas is the one shipped with XL Fortran. Are there some obvious incompatibilities? Thanks Marek
I'm using svn version of scipy. As far as i observed scipy 0.5.2 is not compatibile with numpy-svn. Below i'm pasting what setup.py produces. I seems things are compiled and there is only linking problem with lapack. Thanks for help.
Where are your blas and lapack coming from ? Did you compile them by yourself ? How ? (compiler, version, etc...)
I'm using IBM(R) XL Fortran Enterprise Edition V9.1 and IBM(R) XL C Enterprise Edition V7.0. Maybe there is some incompatibility between compilers for Fortran and C? That's what is installed on the machine i'm working on. I have to compile lapack by myself (actually scipy installer can do that), scipy cannot compile lapack by itself. I don't know the exact process in
Marek Wojciechowski wrote: this case, but scipy has a "lite" lapack as a fall back; I am not 100 % sure, though. There is a pretty good chance that the LAPACK you compiled has something wrong: LAPACK is difficult to compile correctly when you want to use it in a non Fortran environment; at least it is on Linux. Did you test LAPACK ? LAPACK 3.1.1 causes problems with scipy at the moment, too, so I recommend you to compile the version 3.0 (beware though, you should NOT use the BLAS from LAPACK 3.0, because it is buggy). If I were you, I would do this first: compile LAPACK 3.0 with the AIX BLAS, and compile the testers and run them (doing a make lapack_testing should be enough). If this works, then the problem is either in the calling convention (python calls fortran code "through C", so you need to be sure that C and Fortran convention are the same; I would guess that AIX being proprietary and used for HPC, IBM tries to have compatible convention by default), or in scipy. If this is the case, we can focus on this point. Cheers, David
David Cournapeau wrote:
scipy cannot compile lapack by itself.
yes, it can. Just define env. variables BLAS_SRC, LAPACK_SRC pointing to blas, lapack source directories, respectively. If there are some blas or lapack libraries lying around in the system then one must also set BLAS=None, LAPACK=None, ATLAS=None so that numpy.distutils will not pick up the unwanted libraries.
I don't know the exact process in this case, but scipy has a "lite" lapack as a fall back; I am not 100 % sure, though.
Did you mean numpy? numpy has lite lapack, not scipy.
There is a pretty good chance that the LAPACK you compiled has something wrong: LAPACK is difficult to compile correctly when you want to use it in a non Fortran environment; at least it is on Linux. Did you test LAPACK ?
LAPACK 3.1.1 causes problems with scipy at the moment, too, so I recommend you to compile the version 3.0 (beware though, you should NOT use the BLAS from LAPACK 3.0, because it is buggy). If I were you, I would do this first: compile LAPACK 3.0 with the AIX BLAS, and compile the testers and run them (doing a make lapack_testing should be enough).
I have fixed the problems with LAPACK 3.1.1 recently. Just use numpy from SVN and scipy should compile fine with LAPACK 3.1.1. Pearu
Pearu Peterson wrote:
David Cournapeau wrote:
scipy cannot compile lapack by itself.
yes, it can. Just define env. variables BLAS_SRC, LAPACK_SRC pointing to blas, lapack source directories, respectively. If there are some blas or lapack libraries lying around in the system then one must also set BLAS=None, LAPACK=None, ATLAS=None so that numpy.distutils will not pick up the unwanted libraries.
Wow, I didn't see this feature while I packaged scipy. Sorry for the misinformation.
There is a pretty good chance that the LAPACK you compiled has something wrong: LAPACK is difficult to compile correctly when you want to use it in a non Fortran environment; at least it is on Linux. Did you test LAPACK ?
LAPACK 3.1.1 causes problems with scipy at the moment, too, so I recommend you to compile the version 3.0 (beware though, you should NOT use the BLAS from LAPACK 3.0, because it is buggy). If I were you, I would do this first: compile LAPACK 3.0 with the AIX BLAS, and compile the testers and run them (doing a make lapack_testing should be enough).
I have fixed the problems with LAPACK 3.1.1 recently. Just use numpy from SVN and scipy should compile fine with LAPACK 3.1.1.
Do all the tests pass now ? As far as I remembered (but this was a few months ago), building with LAPACK 3.1.1 is possible, but some tests fail. I don't have the time right now to recompile my own lapack to reproduce the problem, but I can do it within the new few days if you need more precise informations. David
participants (3)
-
David Cournapeau -
Marek Wojciechowski -
Pearu Peterson