compiler & lapack issues
Hi, gcc-2.95.3 is an order of magnitude faster than Mandrake-8.2's gcc-2.96 in compiling the Atlas libraries. Use of 2.95.3 decreased the time from an estimated 8 hours to far less than 1 hour on a 1 GHz AMD. It is really worthwhile to install a minimal version of th gcc-2.95.3 compilers (no shared libraries) in /usr/local/bin. The fact that running scipy.test() on my system dies with .zswap:n=3 ....... ** On entry to DGESDD parameter number 12 had an illegal value [packer@venus packer]$ is related to a LAPACK issue. Mandrake's LAPACK rpms come with a lot of patches that have been released after "Update, Version 3.0: May 31, 2000", see http://netlib2.cs.utk.edu/lapack/release_notes.html This includes new versions of ?gesdd.f with corrected work space calculations. Probably, the parameter checks in the corresponding *.pyf files are out of sync with those post-latest-Update release. What to do about this? Changing the *.pyf files will uncover errors in LAPACK installations without those patches. On the other hand, one one would not like to see a bridge collapse, due to an unapplied patch, isn't it? Gerard --------------------------------------------- This message was sent using Endymion MailMan. http://www.endymion.com/products/mailman/
On Sat, 25 May 2002 gvermeul@polycnrs-gre.fr wrote:
The fact that running scipy.test() on my system dies with
.zswap:n=3 ....... ** On entry to DGESDD parameter number 12 had an illegal value [packer@venus packer]$
is related to a LAPACK issue.
Mandrake's LAPACK rpms come with a lot of patches that have been released after "Update, Version 3.0: May 31, 2000", see http://netlib2.cs.utk.edu/lapack/release_notes.html
This includes new versions of ?gesdd.f with corrected work space calculations. Probably, the parameter checks in the corresponding *.pyf files are out of sync with those post-latest-Update release.
What to do about this? Changing the *.pyf files will uncover errors in LAPACK installations without those patches. On the other hand, one one would not like to see a bridge collapse, due to an unapplied patch, isn't it?
The latest official LAPACK release update does not include these patches. We could fix *.pyf according to these LAPACK patches but then we must include these patches also to SciPy distribution so that people can use their existing LAPACK libraries and only the latest routines come from SciPy. It complicates things a bit but it should work. Meanwhile you can downgrade gesdd routines by copying official ?gesdd.f files to scipy/linalg/src directory and add the names ?gesdd.f to the flinalg list in setup_linalg.py similarly to files det.f and lu.f. The same technique can be later used for upgrading gesdd routines but let us know if it works. Pearu
On Sat, 25 May 2002 gvermeul@polycnrs-gre.fr wrote:
The fact that running scipy.test() on my system dies with
.zswap:n=3 ....... ** On entry to DGESDD parameter number 12 had an illegal value [packer@venus packer]$
is related to a LAPACK issue.
Mandrake's LAPACK rpms come with a lot of patches that have been released after "Update, Version 3.0: May 31, 2000", see http://netlib2.cs.utk.edu/lapack/release_notes.html
This includes new versions of ?gesdd.f with corrected work space calculations. Probably, the parameter checks in the corresponding *.pyf files are out of sync with those post-latest-Update release.
I just downloaded LAPACK patches from ftp://netlib2.cs.utk.edu/lapack/patch/src/ and compiled linalg with it. And I don't get this error. I even put a print statement into dgesdd.f to see that it was actually used (indeed, it was but in different places, not after the "zswap:n=3" message). Can you determine which test in linalg/tests/test_*.py actually fails? Also, where can I get Mandrake lapack.src.rpm's to see what they have done? Pearu
participants (2)
-
gvermeulï¼ polycnrs-gre.fr
-
Pearu Peterson