Hi there, I am new to scipy and have the following installation problem: I work on a dual processor Xeon box, and try to install scipy. After various unsuccessful attempts, I now compiled BLAS, LAPACK ATLAS and FFTW3.1 from scratch, then installed numpy-0.9.5 and then installed scipy-0.4.6 under python 2.4.2. The installation went fine but after import scipy scipy.test(level=1) I get the following error message: ====================================================================== FAIL: check_simple (scipy.linalg.decomp.test_decomp.test_eig) ---------------------------------------------------------------------- Traceback (most recent call last): File "/scratch/python2.4/lib/python2.4/site-packages/scipy/linalg/tests/test_decomp.py", line 89, in check_simple assert_array_almost_equal(w,exact_w) File "/scratch/python2.4/lib/python2.4/site-packages/numpy/testing/utils.py", line 183, in assert_array_almost_equal assert cond,\ AssertionError: Arrays are not almost equal (mismatch 66.6666666667%): Array 1: [ 9.4371906+0.j -0.1153653+0.j -0.3218254+0.j] Array 2: [ 9.3218254 0. -0.3218254] ====================================================================== FAIL: check_simple (scipy.linalg.decomp.test_decomp.test_eigvals) ---------------------------------------------------------------------- Traceback (most recent call last): File "/scratch/python2.4/lib/python2.4/site-packages/scipy/linalg/tests/test_decomp.py", line 37, in check_simple assert_array_almost_equal(w,exact_w) File "/scratch/python2.4/lib/python2.4/site-packages/numpy/testing/utils.py", line 183, in assert_array_almost_equal assert cond,\ AssertionError: Arrays are not almost equal (mismatch 66.6666666667%): Array 1: [ 9.4371906+0.j -0.1153653+0.j -0.3218254+0.j] Array 2: [ 9.3218254 0. -0.3218254] ====================================================================== FAIL: check_simple_tr (scipy.linalg.decomp.test_decomp.test_eigvals) ---------------------------------------------------------------------- Traceback (most recent call last): File "/scratch/python2.4/lib/python2.4/site-packages/scipy/linalg/tests/test_decomp.py", line 45, in check_simple_tr assert_array_almost_equal(w,exact_w) File "/scratch/python2.4/lib/python2.4/site-packages/numpy/testing/utils.py", line 183, in assert_array_almost_equal assert cond,\ AssertionError: Arrays are not almost equal (mismatch 66.6666666667%): Array 1: [ 9.4371906+0.j -0.1153653+0.j -0.3218254+0.j] Array 2: [ 9.3218254 0. -0.3218254] ---------------------------------------------------------------------- Ran 1067 tests in 2.250s FAILED (failures=3) <unittest.TextTestRunner object at 0x2aa03923d0> Could anybody please tell me what to do with that? If that is important: I compiled everything with gcc. gcc --version gives: gcc (GCC) 3.2.3 20030502 (Red Hat Linux 3.2.3-52) In order to get scipy to use the atlas libraries I had to add an option -fPIC in the compiler flags in atlas and friends. Any help would be much appreciated! Thanks in advance, Hanno -- Hanno Klemm klemm@phys.ethz.ch
Hi,
I work on a dual processor Xeon box, and try to install scipy. After various unsuccessful attempts, I now compiled BLAS, LAPACK ATLAS and FFTW3.1 from scratch, then installed numpy-0.9.5 and then installed scipy-0.4.6 under python 2.4.2. The installation went fine but after
import scipy scipy.test(level=1)
I get the following error message:
====================================================================== FAIL: check_simple (scipy.linalg.decomp.test_decomp.test_eig) ----------------------------------------------------------------------
I get the same errors. I think we are both working on a 64 bit system. I noticed the comments in the test_fblas.py file in the linalg/tests directory: # These test really need to be checked on 64 bit architectures. # What does complex32 become on such machines? complex64 I'll bet. # If so, I think we are OK. # Check when we have a machine to check on. Is it possible that this is the source of our problem? Best, Matthew
Hi,
I work on a dual processor Xeon box, and try to install scipy. After various unsuccessful attempts, I now compiled BLAS, LAPACK ATLAS and FFTW3.1 from scratch, then installed numpy-0.9.5 and then installed scipy-0.4.6 under python 2.4.2. The installation went fine but after
import scipy scipy.test(level=1)
I get the following error message:
====================================================================== FAIL: check_simple (scipy.linalg.decomp.test_decomp.test_eig) ----------------------------------------------------------------------
Sorry to press the team - but a) Has anyone got this test to pass on an Intel 64bit system? If so, would they mind forwarding the details of their setup? b) Any suggestions of where to start in debugging the problem? The following replicates the errors Hanno and I are getting: python -c 'import scipy.linalg ; scipy.linalg.test()' Thanks a lot, Matthew
Hi I've built Scipy/numpy on an Intel P4 based 64bit system and only get one test failure (different from yours though). Build environment : SVN scipy version: '0.4.7.1677' SVN numpy version: '0.9.6.2226' with ATLAS 3.7.11/LAPACK built with GCC 3.4.3 Perhaps you should try with the latest SVN versions of scipy/numpy and see what you get? Brett ====================================================================== FAIL: W.II.A.0. Print ROUND with only one digit. ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib64/python2.4/site-packages/scipy/stats/tests/test_stats.py", line 85, in check_rounding0 assert_equal(y,i+1) File "/usr/lib64/python2.4/site-packages/numpy/testing/utils.py", line 128, in assert_equal assert desired == actual, msg AssertionError: Items are not equal: DESIRED: 1 ACTUAL: 0.0 ---------------------------------------------------------------------- Ran 1123 tests in 43.839s On Tuesday 14 March 2006 12:43, Matthew Brett wrote:
Hi,
I work on a dual processor Xeon box, and try to install scipy. After various unsuccessful attempts, I now compiled BLAS, LAPACK ATLAS and FFTW3.1 from scratch, then installed numpy-0.9.5 and then installed scipy-0.4.6 under python 2.4.2. The installation went fine but after
import scipy scipy.test(level=1)
I get the following error message:
====================================================================== FAIL: check_simple (scipy.linalg.decomp.test_decomp.test_eig) ----------------------------------------------------------------------
Sorry to press the team - but
a) Has anyone got this test to pass on an Intel 64bit system? If so, would they mind forwarding the details of their setup? b) Any suggestions of where to start in debugging the problem?
The following replicates the errors Hanno and I are getting:
python -c 'import scipy.linalg ; scipy.linalg.test()'
Thanks a lot,
Matthew
_______________________________________________ SciPy-user mailing list SciPy-user@scipy.net http://www.scipy.net/mailman/listinfo/scipy-user
-- Brett G. Olivier PhD Triple-J Group for Molecular Cell Physiology Stellenbosch University
Brett Olivier wrote:
Hi
I've built Scipy/numpy on an Intel P4 based 64bit system and only get one test failure (different from yours though).
Build environment : SVN scipy version: '0.4.7.1677' SVN numpy version: '0.9.6.2226' with ATLAS 3.7.11/LAPACK built with GCC 3.4.3
Perhaps you should try with the latest SVN versions of scipy/numpy and see what you get?
Brett
====================================================================== FAIL: W.II.A.0. Print ROUND with only one digit. ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib64/python2.4/site-packages/scipy/stats/tests/test_stats.py", line 85, in check_rounding0 assert_equal(y,i+1) File "/usr/lib64/python2.4/site-packages/numpy/testing/utils.py", line 128, in assert_equal assert desired == actual, msg AssertionError: Items are not equal: DESIRED: 1 ACTUAL: 0.0
---------------------------------------------------------------------- Ran 1123 tests in 43.839s
I've built scipy/numpy on an AMD based 64bit system. I can reproduce the error reported by Tim.
scipy.__version__ '0.4.7.1707' numpy.__version__ '0.9.7.2243'
====================================================================== FAIL: check_lu (scipy.linalg.tests.test_decomp.test_lu_solve) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib64/python2.4/site-packages/scipy/linalg/tests/test_decomp.py", line 138, in check_lu assert_array_equal(x1,x2) File "/usr/lib64/python2.4/site-packages/numpy/testing/utils.py", line 204, in assert_array_equal assert cond,\ AssertionError: Arrays are not equal (mismatch 100.0%): Array 1: [-0.2788866064997962 3.5000435636821954 0.2273024982361812 -0.4566513297109564 2.1391760680488212 -0.132995040912662... Array 2: [ 0.1037139891362202 -0.6723715892452233 0.1226811680403352 -0.3152497111751822 -0.1347991093520258 -0.711241441748883... ---------------------------------------------------------------------- Ran 1109 tests in 1.909s FAILED (failures=1) Nils
On Tuesday 14 March 2006 12:43, Matthew Brett wrote:
Hi,
I work on a dual processor Xeon box, and try to install scipy. After various unsuccessful attempts, I now compiled BLAS, LAPACK ATLAS and FFTW3.1 from scratch, then installed numpy-0.9.5 and then installed scipy-0.4.6 under python 2.4.2. The installation went fine but after
import scipy scipy.test(level=1)
I get the following error message:
====================================================================== FAIL: check_simple (scipy.linalg.decomp.test_decomp.test_eig) ----------------------------------------------------------------------
Sorry to press the team - but
a) Has anyone got this test to pass on an Intel 64bit system? If so, would they mind forwarding the details of their setup? b) Any suggestions of where to start in debugging the problem?
The following replicates the errors Hanno and I are getting:
python -c 'import scipy.linalg ; scipy.linalg.test()'
Thanks a lot,
Matthew
_______________________________________________ SciPy-user mailing list SciPy-user@scipy.net http://www.scipy.net/mailman/listinfo/scipy-user
Hi, Just to update on 64 bit, scipy tests. I have now tested on two identical 64 bit linux P4 systems: 1) Fedora core 4 gcc (GCC) 4.0.2 20051125 (Red Hat 4.0.2-8) GNU Fortran (GCC 3.2.3 20030502 (Red Hat Linux 3.2.3-47.fc4)) 2) Ubuntu gcc (GCC) 4.0.2 20050808 (prerelease) GNU Fortran (GCC) 3.4.5 20050809 Both have: nocona optimized atlas, fftw 3.1, numpy '0.9.7.2248', scipy '0.4.7.1713' System 1 generates error messages Hanno and I have reported for scipy.linalg.test()
FAIL: check_simple (scipy.linalg.decomp.test_decomp.test_eig)
System 2 passes all scipy.linalg.test() Neither system generates an error for scipy.stats.test() - which appears to be the source of the errors reported by Nils and Brett Both systems hang indefinitely for: scipy.lib.lapack.test() I guess I'm going to conclude that At least the combination of gcc 4.0.2 and g77 3.2.3 and ATLAS is not compatible with linalg At least the combination of ATLAS, gcc 4.0.2 and either version of g77 that I have is not going to work for lib.lapack There is some other incompatibility for the setup of Nils and Brett. Best, Matthew
Matthew Brett wrote:
Hi,
Just to update on 64 bit, scipy tests. I have now tested on two identical 64 bit linux P4 systems:
1) Fedora core 4 gcc (GCC) 4.0.2 20051125 (Red Hat 4.0.2-8) GNU Fortran (GCC 3.2.3 20030502 (Red Hat Linux 3.2.3-47.fc4))
2) Ubuntu gcc (GCC) 4.0.2 20050808 (prerelease) GNU Fortran (GCC) 3.4.5 20050809
Both have: nocona optimized atlas, fftw 3.1, numpy '0.9.7.2248', scipy '0.4.7.1713'
System 1 generates error messages Hanno and I have reported for scipy.linalg.test()
FAIL: check_simple (scipy.linalg.decomp.test_decomp.test_eig)
System 2 passes all scipy.linalg.test() Neither system generates an error for scipy.stats.test() - which appears to be the source of the errors reported by Nils and Brett
Both systems hang indefinitely for:
scipy.lib.lapack.test()
I guess I'm going to conclude that
At least the combination of gcc 4.0.2 and g77 3.2.3 and ATLAS is not compatible with linalg At least the combination of ATLAS, gcc 4.0.2 and either version of g77 that I have is not going to work for lib.lapack There is some other incompatibility for the setup of Nils and Brett.
Hmm. On my AMD64 Ubuntu Breezy with the same compilers that you list above and ATLAS from the atlas3-base package, scipy.lib.lapack.test() runs perfectly. -- Robert Kern robert.kern@gmail.com "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco
Hi,
Hmm. On my AMD64 Ubuntu Breezy with the same compilers that you list above and ATLAS from the atlas3-base package, scipy.lib.lapack.test() runs perfectly.
More Ubuntu 64 bit platform trivia. Compiling against atlas3 provided with Ubuntu allows scipy.test to run without error (including lib.lapack.test() obviously). I suppose there must be something wrong with the compilation of lapack or ATLAS then. Maybe a problem with 3.7.11. Etc etc. Dammit, what a way to spend your day. Incidentally, scipy.test(10) still dies at scipy.linalg with: Finding matrix determinant ================================== | contiguous | non-contiguous ---------------------------------------------- size | scipy | basic | scipy | basic 20 | 0.20 | 0.28 | 0.23 | 0.30 (secs for 2000 calls) 100 | 0.32 | 0.45 | 0.38 | 0.53 (secs for 300 calls) 500Illegal instruction This error does not occur with my home-compiled atlas libraries. AMD specific compile for Ubuntu atlas maybe? Best, Matthew
Hi Matthew On Friday 17 March 2006 14:50, Matthew Brett wrote:
I suppose there must be something wrong with the compilation of lapack or ATLAS then. Maybe a problem with 3.7.11. Etc etc. Dammit, what a way to spend your day.
Just out of interest, what compiler options are you using to build LAPACK and ATLAS? On the 64 bit P4 I use for LAPACK (in make.inc): OPTS = -funroll-all-loops -O3 -m64 -fno-second-underscore -fPIC NOOPT = -m64 -fno-second-underscore -fPIC and if I remember correctly, for ATLAS 3.7.11 I added (to Make.<arch> after ATLAS configuration): -fPIC and -m64 to various compiler options. All compiled with gcc/g77 3.4.3. Brett
Incidentally, scipy.test(10) still dies at scipy.linalg with:
Finding matrix determinant ==================================
| contiguous | non-contiguous
---------------------------------------------- size | scipy | basic | scipy | basic 20 | 0.20 | 0.28 | 0.23 | 0.30 (secs for 2000 calls) 100 | 0.32 | 0.45 | 0.38 | 0.53 (secs for 300 calls) 500Illegal instruction
This error does not occur with my home-compiled atlas libraries. AMD specific compile for Ubuntu atlas maybe?
Best,
Matthew
_______________________________________________ SciPy-user mailing list SciPy-user@scipy.net http://www.scipy.net/mailman/listinfo/scipy-user
Hi,
Just out of interest, what compiler options are you using to build LAPACK and ATLAS? On the 64 bit P4 I use for LAPACK (in make.inc):
OPTS = -funroll-all-loops -O3 -m64 -fno-second-underscore -fPIC NOOPT = -m64 -fno-second-underscore -fPIC
OPTS = -funroll-all-loops -fno-f2c -O3 -m64 -fPIC NOOPT = -m64 -fPIC
and if I remember correctly, for ATLAS 3.7.11 I added (to Make.<arch> after ATLAS configuration): -fPIC and -m64 to various compiler options.
-fomit-frame-pointer -funroll-all-loops -mfpmath=sse -m64 -fPIC with -03, -O as per the atlas defaults, and -march=nocona for gcc... I've attached my build scripts in case they're useful. Best, Matthew
participants (5)
-
Brett Olivier -
Hanno Klemm -
Matthew Brett -
Nils Wagner -
Robert Kern