opencollab / arpack-ng Goto Github PK
View Code? Open in Web Editor NEWCollection of Fortran77 subroutines designed to solve large scale eigenvalue problems.
License: Other
Collection of Fortran77 subroutines designed to solve large scale eigenvalue problems.
License: Other
Without re-generating and committing configure to repo, every downloader then needs to have correct version of autoconf installed before they can use configure to build it. Having to download and installing autoconf to build another package is onerous.
Steps to reproduce the problem:
Expected result:
4 tests fails with a segmentation fault
../../test-driver: line 95: 28671 Segmentation fault: 11
"$@" > $log_file 2>&1
FAIL: cnbdr3
../../test-driver: line 95: 29166 Segmentation fault: 11
"$@" > $log_file 2>&1
FAIL: znbdr1
../../test-driver: line 95: 29185 Segmentation fault: 11
"$@" > $log_file 2>&1
FAIL: znbdr2
../../test-driver: line 95: 29204 Segmentation fault: 11
"$@" > $log_file 2>&1
FAIL: znbdr3
===================================================
arpack-ng 3.1.5: EXAMPLES/BAND/test-suite.log
===================================================
# TOTAL: 32
# PASS: 28
# SKIP: 0
# XFAIL: 0
# FAIL: 4
# XPASS: 0
# ERROR: 0
.. contents:: :depth: 2
FAIL: cnbdr3
============
Program received signal SIGSEGV: Segmentation fault - invalid memory reference.
Backtrace for this error:
#0 0x10ed59632
#1 0x10ed59dfe
#2 0x7fff91650cf9
#3 0x7fff86d7f257
#4 0x10ecf9461
#5 0x10ecfc51a
#6 0x10ecfd5e9
#7 0x10eb5e657
#8 0x10eb5daa1
#9 0x10eb5f9de
FAIL: znbdr1
============
Program received signal SIGSEGV: Segmentation fault - invalid memory reference.
Backtrace for this error:
#0 0x10edca632
#1 0x10edcadfe
#2 0x7fff91650cf9
#3 0x7fff86885d9a
#4 0x10ed9eb66
#5 0x10ea2e1d1
#6 0x10ea2cb0d
#7 0x10ea2e99e
FAIL: znbdr2
============
Program received signal SIGSEGV: Segmentation fault - invalid memory reference.
Backtrace for this error:
#0 0x10b37d632
#1 0x10b37ddfe
#2 0x7fff91650cf9
#3 0x7fff86885d9a
#4 0x10b352b66
#5 0x10afe41d1
#6 0x10afe2b0d
#7 0x10afe499e
FAIL: znbdr3
============
Program received signal SIGSEGV: Segmentation fault - invalid memory reference.
Backtrace for this error:
#0 0x10b3a5632
#1 0x10b3a5dfe
#2 0x7fff91650cf9
#3 0x7fff86885d9a
#4 0x10b370cd5
#5 0x10b3737fc
#6 0x10b374718
#7 0x10b0035b7
#8 0x10b0029c8
#9 0x10b0049ae
When building arpack-ng 3.5.0 using cmake, I don't see any option to build static libraries. Would it be possible to add it?
Maybe not really an issue, but on Centos 6.6. the libtool version is
libtool --version
ltmain.sh (GNU libtool) 2.2.6b
bootstrap announces:
Libtool version 2.4.2 or higher is required
Is there a way to make this work with earlier libtool versions? Centos 6.6. is only 6months old. Maybe there is a workaround, if only a simple static libarpack.a is needed?
(Furthermore, cmake support would be awesome, to support out-of-source builds)
Could you rename pslamch to pslamch10 to avoid symbol collision with ScaLAPACK, as you did with pdlamch in #21
I'm packaging arpack-ng for GNU Guix and encountered a test failure:
...
make check-TESTS
make[2]: Entering directory '/buildtmp/nix-build-arpack-ng-3.2.0.drv-0/arpack-ng-3.2.0/TESTS'
make[3]: Entering directory '/buildtmp/nix-build-arpack-ng-3.2.0.drv-0/arpack-ng-3.2.0/TESTS'
FAIL: bug_1315_single
PASS: dnsimp
PASS: bug_1315_double
make[4]: Entering directory '/buildtmp/nix-build-arpack-ng-3.2.0.drv-0/arpack-ng-3.2.0/TESTS'
make[4]: Nothing to be done for 'all'.
make[4]: Leaving directory '/buildtmp/nix-build-arpack-ng-3.2.0.drv-0/arpack-ng-3.2.0/TESTS'
============================================================================
Testsuite summary for arpack-ng 3.2.0
============================================================================
# TOTAL: 3
# PASS: 2
# SKIP: 0
# XFAIL: 0
# FAIL: 1
# XPASS: 0
# ERROR: 0
============================================================================
See TESTS/test-suite.log
Please report to https://github.com/opencollab/arpack-ng/issues/
============================================================================
Makefile:699: recipe for target 'test-suite.log' failed
...
These are the contents of the log file:
===========================================
arpack-ng 3.2.0: TESTS/test-suite.log
===========================================
# TOTAL: 3
# PASS: 2
# SKIP: 0
# XFAIL: 0
# FAIL: 1
# XPASS: 0
# ERROR: 0
.. contents:: :depth: 2
FAIL: bug_1315_single
=====================
999.997742
998.996643
997.997253
996.997314
995.996338
993.996948
I'm compiling with gfortran 4.8.4 and linking against ATLAS 3.10.2.
Recently, it started to fail (even if we didn't change anything to this):
https://travis-ci.org/opencollab/arpack-ng/builds/84871142
/bin/bash ../libtool --tag=F77 --mode=link gfortran -g -O2 -o bug_1323 bug_1323.o ../libarpack.la -lblas -llapack
libtool: link: gfortran -g -O2 -o .libs/bug_1323 bug_1323.o ../.libs/libarpack.so -lblas -llapack -Wl,-rpath -Wl,/home/travis/build/opencollab/arpack-ng/arpack-ng-3.3.0/_inst/lib
make[3]: Leaving directory `/home/travis/build/opencollab/arpack-ng/arpack-ng-3.3.0/_build/TESTS'
make check-TESTS
make[3]: Entering directory `/home/travis/build/opencollab/arpack-ng/arpack-ng-3.3.0/_build/TESTS'
/bin/bash: line 5: 23508 Segmentation fault (core dumped) ${dir}$tst
FAIL: test-dnsimp.sh
/bin/bash: line 5: 23532 Segmentation fault (core dumped) ${dir}$tst
FAIL: bug_1315_single
/bin/bash: line 5: 23555 Segmentation fault (core dumped) ${dir}$tst
FAIL: bug_1315_double
/bin/bash: line 5: 23579 Segmentation fault (core dumped) ${dir}$tst
FAIL: bug_1323
I cannot reproduce it on my debian
I'm installing Arpack 3.4.0 using CMake on OSX but I'm missing the pkgconfig file arpack.pc
. It's installed when I used configure
, but not cmake
. Any ideas?
Thanks.
arpack installs a header called "debug.h" in ${prefix}/include that collides with several other packages such as doxygen. See https://trac.macports.org/ticket/56718.
The header stat.h also seems sufficiently generic that I can imagine there are other packages with the same header file name.
rank 0 - 1000.15 1000.15
Correct eigenvalues not computed
--------------------------------------------------------------------------
MPI_ABORT was invoked on rank 0 in communicator MPI_COMM_WORLD
with errorcode 1.
NOTE: invoking MPI_ABORT causes Open MPI to kill all MPI processes.
You may or may not see output from other processes, depending on
exactly when Open MPI kills them.
--------------------------------------------------------------------------
FAIL icb_parpack_cpp (exit status: 1)
ILP64 support (#32) is currently not tested in Travis CI since Ubuntu does not provide an ILP64 BLAS. When/if they include such a package (most likely via OpenBLAS), separate CMake and autotools builds should be added for this.
It would also be useful to test for suffixed BLAS and LAPACK at the same time (at least if Ubuntu provides it).
When building the Visual Studio project, the build fails complaining about undefined symbols. These are:
_slahqr2_
_dlahqr2_
This seems to be as simple as adding them to the list of source files. I have forked the repo, and will see if I can submit a pull request.
When arpack-ng 3.5.0 is configured using cmake, the tests in EXAMPLES are not run, whereas when using autotools, they are (72 more tests are run this way). Please update the CMakeFiles.txt to include running EXAMPLES tests, like configure'd Makefile does.
I've got a couple of questions regarding the C/C++ bindings and examples for arpack-ng.
Firstly, is it possible to make the C/C++ bindings const correct? This would help signal what changes when passing in char pointers, or better yet accept a std::string
and use c_str()
.
Secondly, the C++ example uses _Complex
(C style) and most C++ codes use the standard library implementation of std::complex<>
. Is it possible to change the bindings and example to accept a std::complex<>* instead of the C style pointer to _Complex? It's possible to cast this back to an array with the same object representation for C compatibility: http://en.cppreference.com/w/cpp/numeric/complex.
I have spent some spare time improving the C++ example and I'm happy to help with these changes.
http://docs.travis-ci.com/user/migrating-from-legacy/
Not sure how to do apt-get build-dep arpack-ng with this new infra.
I found that if nev is too small, the eigenvalue is completely error, like following:
bmat = 'G', which = 'SM'
N=15129, nev=5, ncv=4*nev
lambda | Frequency (Hz) |
---|---|
0.000000000000000E+000 | 0.000000000000000E+000 |
0.000000000000000E+000 | 0.000000000000000E+000 |
0.000000000000000E+000 | 0.000000000000000E+000 |
0.000000000000000E+000 | 0.000000000000000E+000 |
0.000000000000000E+000 | 0.000000000000000E+000 |
N=15129, nev=8 , ncv=4*nev, right results
lambda | Frequency (Hz) |
---|---|
9073.84572612423 | 15.1605803744355 |
36429.4114333670 | 30.3770928736707 |
36429.4693770658 | 30.3771170321782 |
76216.1904237645 | 43.9383506359923 |
111258.263873727 | 53.0867662079674 |
112660.851363559 | 53.4203397834319 |
168718.970107423 | 65.3735530512918 |
168719.000352898 | 65.3735589108999 |
But if I set a larger ncv for small nev, then obtain right results:
N=15129, nev=5, ncv=8*nev
lambda | Frequency (Hz) |
---|---|
9073.91416641185 | 15.1606375493399 |
36429.3509892708 | 30.3770676726502 |
36429.4365992089 | 30.3771033660854 |
76216.4177657186 | 43.9384161668395 |
111258.264313797 | 53.0867663129568 |
So, I don't know how to set ncv aromatically. Excuse me for my poor English.
Compiled arpack-ng for the first time here.
make check
Making check in UTIL
make[1]: Nothing to be done for `check'.
Making check in SRC
make[1]: Nothing to be done for `check'.
Making check in .
make[1]: Nothing to be done for `check-am'.
Making check in TESTS
/Applications/Xcode.app/Contents/Developer/usr/bin/make dnsimp bug_1315_single bug_1315_double bug_1323
gfortran -g -O2 -c -o dnsimp.o dnsimp.f
gfortran -g -O2 -c -o mmio.o mmio.f
/bin/sh ../libtool --tag=F77 --mode=link gfortran -g -O2 -o dnsimp dnsimp.o mmio.o ../libarpack.la -lblas -llapack
libtool: link: gfortran -g -O2 -o .libs/dnsimp dnsimp.o mmio.o ../.libs/libarpack.dylib -lblas -llapack
gcc -DPACKAGE_NAME=\"ARPACK-NG\" -DPACKAGE_TARNAME=\"arpack-ng\" -DPACKAGE_VERSION=\"3.3.0\" -DPACKAGE_STRING=\"ARPACK-NG\ 3.3.0\" -DPACKAGE_BUGREPORT=\"https://github.com/opencollab/arpack-ng/issues/\" -DPACKAGE_URL=\"https://github.com/opencollab/arpack-ng/\" -DPACKAGE=\"arpack-ng\" -DVERSION=\"3.3.0\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -DHAVE_BLAS=1 -DHAVE_LAPACK=1 -I. -g -O2 -MT bug_1315_single.o -MD -MP -MF .deps/bug_1315_single.Tpo -c -o bug_1315_single.o bug_1315_single.c
mv -f .deps/bug_1315_single.Tpo .deps/bug_1315_single.Po
/bin/sh ../libtool --tag=CC --mode=link gcc -g -O2 -o bug_1315_single bug_1315_single.o ../libarpack.la -lblas -llapack
libtool: link: gcc -g -O2 -o .libs/bug_1315_single bug_1315_single.o ../.libs/libarpack.dylib -lblas -llapack
gcc -DPACKAGE_NAME=\"ARPACK-NG\" -DPACKAGE_TARNAME=\"arpack-ng\" -DPACKAGE_VERSION=\"3.3.0\" -DPACKAGE_STRING=\"ARPACK-NG\ 3.3.0\" -DPACKAGE_BUGREPORT=\"https://github.com/opencollab/arpack-ng/issues/\" -DPACKAGE_URL=\"https://github.com/opencollab/arpack-ng/\" -DPACKAGE=\"arpack-ng\" -DVERSION=\"3.3.0\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -DHAVE_BLAS=1 -DHAVE_LAPACK=1 -I. -g -O2 -MT bug_1315_double.o -MD -MP -MF .deps/bug_1315_double.Tpo -c -o bug_1315_double.o bug_1315_double.c
mv -f .deps/bug_1315_double.Tpo .deps/bug_1315_double.Po
/bin/sh ../libtool --tag=CC --mode=link gcc -g -O2 -o bug_1315_double bug_1315_double.o ../libarpack.la -lblas -llapack
libtool: link: gcc -g -O2 -o .libs/bug_1315_double bug_1315_double.o ../.libs/libarpack.dylib -lblas -llapack
gfortran -g -O2 -c -o bug_1323.o bug_1323.f
/bin/sh ../libtool --tag=F77 --mode=link gfortran -g -O2 -o bug_1323 bug_1323.o ../libarpack.la -lblas -llapack
libtool: link: gfortran -g -O2 -o .libs/bug_1323 bug_1323.o ../.libs/libarpack.dylib -lblas -llapack
/Applications/Xcode.app/Contents/Developer/usr/bin/make check-TESTS
PASS: dnsimp
FAIL: bug_1315_single
PASS: bug_1315_double
PASS: bug_1323
============================================================================
Testsuite summary for ARPACK-NG 3.3.0
============================================================================
# TOTAL: 4
# PASS: 3
# SKIP: 0
# XFAIL: 0
# FAIL: 1
# XPASS: 0
# ERROR: 0
============================================================================
See TESTS/test-suite.log
Please report to https://github.com/opencollab/arpack-ng/issues/
============================================================================
make[3]: *** [test-suite.log] Error 1
make[2]: *** [check-TESTS] Error 2
make[1]: *** [check-am] Error 2
make: *** [check-recursive] Error 1
From test-suite.log
===========================================
ARPACK-NG 3.3.0: TESTS/test-suite.log
===========================================
# TOTAL: 4
# PASS: 3
# SKIP: 0
# XFAIL: 0
# FAIL: 1
# XPASS: 0
# ERROR: 0
.. contents:: :depth: 2
FAIL: bug_1315_single
=====================
0.000000
FAIL bug_1315_single (exit status: 1)
I also pulled down thrasibule:dlaqrb and get the same result.
For dseupd_c
we have bool * select
in arpack.hpp
, which, if really passed an buffer bool[ncv]
, will result in buffer overflow, because (on Linux x86) sizeof(bool)==1
while size of Fortran's logical
is 4.
It seems actual type for this pointer should be int*
or something like this.
The same might be true for arpack.h
.
Steps to reproduce the problem:
./configure \
F77=/usr/local/bin/mpif77 \
--disable-dependency-tracking \
--prefix=/usr/local/Cellar/arpack/3.2.0/libexec \
--enable-mpi \
--with-blas="-L/usr/local/opt/veclibfort/lib -lvecLibFort"
make
make check
Result:
$ make check
Making check in UTIL
make[1]: Nothing to be done for `check'.
Making check in SRC
make[1]: Nothing to be done for `check'.
Making check in .
make[1]: Nothing to be done for `check-am'.
Making check in TESTS
/Applications/Xcode.app/Contents/Developer/usr/bin/make dnsimp bug_1315_single bug_1315_double
/usr/local/bin/mpif77 -g -O2 -c -o dnsimp.o dnsimp.f
/usr/local/bin/mpif77 -g -O2 -c -o mmio.o mmio.f
/bin/sh ../libtool --tag=F77 --mode=link /usr/local/bin/mpif77 -g -O2 -o dnsimp dnsimp.o mmio.o ../libarpack.la -L/usr/local/opt/veclibfort/lib -lvecLibFort
libtool: link: /usr/local/bin/mpif77 -g -O2 -o .libs/dnsimp dnsimp.o mmio.o ../.libs/libarpack.dylib -L/usr/local/opt/veclibfort/lib -lvecLibFort
gcc -DPACKAGE_NAME=\"arpack-ng\" -DPACKAGE_TARNAME=\"arpack-ng\" -DPACKAGE_VERSION=\"3.2.0\" -DPACKAGE_STRING=\"arpack-ng\ 3.2.0\" -DPACKAGE_BUGREPORT=\"https://github.com/opencollab/arpack-ng/issues/\" -DPACKAGE_URL=\"\" -DPACKAGE=\"arpack-ng\" -DVERSION=\"3.2.0\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -DHAVE_BLAS=1 -DHAVE_LAPACK=1 -DHAVE_MPI=1 -I. -g -O2 -c -o bug_1315_single.o bug_1315_single.c
/bin/sh ../libtool --tag=CC --mode=link gcc -g -O2 -o bug_1315_single bug_1315_single.o ../libarpack.la -L/usr/local/opt/veclibfort/lib -lvecLibFort
libtool: link: gcc -g -O2 -o .libs/bug_1315_single bug_1315_single.o ../.libs/libarpack.dylib -L/usr/local/opt/veclibfort/lib -lvecLibFort
gcc -DPACKAGE_NAME=\"arpack-ng\" -DPACKAGE_TARNAME=\"arpack-ng\" -DPACKAGE_VERSION=\"3.2.0\" -DPACKAGE_STRING=\"arpack-ng\ 3.2.0\" -DPACKAGE_BUGREPORT=\"https://github.com/opencollab/arpack-ng/issues/\" -DPACKAGE_URL=\"\" -DPACKAGE=\"arpack-ng\" -DVERSION=\"3.2.0\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -DHAVE_BLAS=1 -DHAVE_LAPACK=1 -DHAVE_MPI=1 -I. -g -O2 -c -o bug_1315_double.o bug_1315_double.c
/bin/sh ../libtool --tag=CC --mode=link gcc -g -O2 -o bug_1315_double bug_1315_double.o ../libarpack.la -L/usr/local/opt/veclibfort/lib -lvecLibFort
libtool: link: gcc -g -O2 -o .libs/bug_1315_double bug_1315_double.o ../.libs/libarpack.dylib -L/usr/local/opt/veclibfort/lib -lvecLibFort
/Applications/Xcode.app/Contents/Developer/usr/bin/make check-TESTS
PASS: dnsimp
FAIL: bug_1315_single
FAIL: bug_1315_double
make[4]: Nothing to be done for `all'.
============================================================================
Testsuite summary for arpack-ng 3.2.0
============================================================================
# TOTAL: 3
# PASS: 1
# SKIP: 0
# XFAIL: 0
# FAIL: 2
# XPASS: 0
# ERROR: 0
and
===========================================
arpack-ng 3.2.0: TESTS/test-suite.log
===========================================
# TOTAL: 3
# PASS: 1
# SKIP: 0
# XFAIL: 0
# FAIL: 2
# XPASS: 0
# ERROR: 0
.. contents:: :depth: 2
FAIL: bug_1315_single
=====================
999.997314
998.996887
997.997314
995.997131
FAIL: bug_1315_double
=====================
1000.000000
999.000000
997.000000
any ideas?
Is there any way we can use OpenMP support in ARPACK rather than MPI? Also, a CMakeLists file would also be useful. I have a f2c version of arpack-ng and that is what I use
When I use the single & double precision complex ARPACK routines using the generalized approach, for the non-shift-invert version the problem does not converge, and for the shift-invert problem the eigenvalues become all zero.
To investigate further, I tried a simpler problem with real eigenvalues & eigenvectors.
Double precision ARPACK: works for all forms of generalized (& not generalized)
Single & double complex ARPACK:
Generalized No shift-invert: does not converge
Generalized With shift-invert: converges to zero eigenvalues (well, eigenvalues = shift)
Not Generalized: works (convert "Ax = LMx" to "M^-1 A x = L I x" & solve as not generalized)
I have attached sample A and M matrices to this message. The problem is designed so that the eigenvalues should be 0, 1, 4, 9, 16, 25, 36, etc. A is the Laplacian, so technically Ax = 0 (0 eigenvalue) is a solution, which makes A technically singular, but I don't think it is a problem as it still works in double precision.
Please let me know if there's anything else that I could supply in order to help fix this problem.
It doesn't appear to allow me to attach the files - instructions on how to do that would help.
I am trying to link OpenBlas with arpack-ng. However, there are link errors. Is there a way to build arpack-ng with OpenBlas?
Also, any plans on getting a CMake version of this library?
After configuring arpack-ng 3.5.0 using cmake, make install
doesn't install the arpack.pc
file. Indeed, the relevant lines are commented out in CMakeLists.txt:
configure_file(arpack.pc.in arpack${LIBSUFFIX}.pc @ONLY)
#install(FILES ${CMAKE_CURRENT_BINARY_DIR}/arpack${LIBSUFFIX}.pc
# DESTINATION ${CMAKE_INSTALL_LIBDIR}/pkgconfig)
The following in Octave produces wrong results (arpack-ng 3.4.0):
octave:31> load Q.h5
octave:32> opts = struct(); opts.p=30; eigs(Q, 10, 'lr', opts)
ans =
7.6562 - 0.1236i
7.6562 + 0.1236i
7.0731 - 0.9404i
7.0731 + 0.9404i
6.7639 + 0.3453i
6.7639 - 0.3453i
6.7362 + 1.3872i
6.7362 - 1.3872i
6.3870 - 2.8622i
6.3870 + 2.8622i
octave:33> max(abs(eig(Q)))
ans = 0.99615
Behavior in Scipy is similar, so I assume this is an ARPACK issue. For small p/ncv it sometimes converges to the right result, but this appears to depend on the platform. Problematic matrix is attached.
in PARPACK/EXAMPLES/MPI/Makefile.am
-bin_PROGRAMS = pzndrv1 psndrv3 pdndrv1 pdndrv3 pssdrv1 pdsdrv1 pcndrv1
+check_PROGRAMS = pzndrv1 psndrv3 pdndrv1 pdndrv3 pssdrv1 pdsdrv1 pcndrv1
to avoid the installation of examples in /usr/bin
Some programs like Julia and Numpy have started to (or tried to) use ILP64 BLAS in order to get rid of size limitations on arrays. But this creates conflicts with libraries that expect a LP64 BLAS when they are loaded in the same process (see JuliaLang/julia#4923, numpy/numpy#5906 and linked issues). The solution that has been found is to export a different BLAS API, by adding a suffix to all functions and to the library name. OpenBLAS now supports a build flag for that (OpenMathLib/OpenBLAS#459), which is used in Fedora to ship an ILP64 package.
The most common suffix is 64_
, as it's already used by several programs (OpenMathLib/OpenBLAS#646). SuiteSparse offers the -DSUN64
build flag to use the suffixed API.
Would you consider supporting a similar API? It appears to be possible with the current build system. Julia uses the following Makefile instructions: https://github.com/JuliaLang/julia/blob/69fb335efe6975c52f8b3d1c66d4008ce2d0b1cb/deps/Makefile#L1316-L1332
It would be great if these could be included upstream so that a single flag needs to be switched. That would make it easier for packagers to ship both the LP64 and ILP64 versions (https://bugzilla.redhat.com/show_bug.cgi?id=1294201).
This is a followup discussion to the following bug: http://forge.scilab.org/index.php/p/arpack-ng/issues/1315/. I'm creating an issue here so that I can reference it from the PR on github.
It would appear that the bug_1315_double
test hangs (indefinitely?) on ppc64le when built with 64-bit interface (arpack-ng 3.5.0, openblas 0.2.19). This is reproducible on Fedora rawhide (27) and RHEL 7. I cancelled both builds after a couple of hours. They take less than 10 minutes on other arches or with 32-bit interfaces only.
@nalimilan , FYI.
For the matrix in http://mhauru.org/trouble_matrix.zip, scipy.sparse.linalg.eigs, which calls ARPACK, gives the wrong dominant eigenvalue. The result depends on the initial guess for the eigenvector. Example python 3 code:
import sys
import numpy as np
import scipy as sp
import scipy.sparse.linalg as spsla
print(sp.__version__, np.__version__, sys.version_info)
M = np.loadtxt("trouble_matrix.out", dtype=np.complex_)
nev = 1
d = M.shape[0]
# Exact, full eig.
S, U = np.linalg.eig(M)
S = S[np.argsort(-np.abs(S))]
print(S[:nev])
# ARPACK, with different initial guesses.
v0 = np.random.rand(d)
S, U = spsla.eigs(M, k=nev, v0=v0)
print(S)
S, U = spsla.eigs(M, k=nev, v0=v0)
print(S)
v0 = np.random.rand(d)
S, U = spsla.eigs(M, k=nev, v0=v0)
print(S)
# Finding the dominant eigenvalue with a simple power iteration.
v = np.random.rand(d)
for _ in range(100):
v /= np.linalg.norm(v)
old_v = v
v = np.dot(M, v)
print(np.average(v/old_v))
For fun, I've added a piece at the end that finds the correct dominant eigenvalue with a simple power iteration.
Output:
1.0.0 1.14.0 sys.version_info(major=3, minor=6, micro=3, releaselevel='final', serial=0)
[0.65419337-8.24548726e-17j]
[21.48733815-0.03849766j]
[21.48733815-0.03849766j]
[0.76760502-15.73229065j]
(0.654193372268301+1.8123127532736513e-16j)
Asking for more than one dominant eigenvalue goes equally wrong, I'm just choosing to showcase the simplest possible thing. I tried increasing ncv and maxiter, but to no help. In case it matters, the dominant eigenvalue of M
is not degenerate.
I originally filed this as a scipy issue (scipy/scipy#8307), but @pv checked the same matrix in Octave and ran into the same behavior, so presuming then that this is a problem with ARPACK.
I think I'm using ARPACK 3.3.0 since that's what comes with scipy 1.0.0.
When providing an autoconf enabled project, the maintains should actually run the generation scripts and check the results into the git repo. If not, then everyone who wants to build the software will need to make all the autoconf related tools installed just to build your software. That is not how autoconf is should to work. One should be able to download the source, run the ./configure script and be building right away.
When compiling with the Intel Fortran compiler and -warn all I get many errors like the following:
ifort -O3 -g -warn all -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -grecord-gcc-switches -m64 -axSSE3,SSSE3,SSE4.1,SSE4.2,CORE-AVX2,COMMON-AVX512 -c -o zndrv2.o zndrv2.f
zndrv2.f(343): error #6633: The type of the actual argument differs from the type of the dummy argument. [V]
call av(n, v(1,j), ax)
--------------------------^
zndrv2.f(343): error #6633: The type of the actual argument differs from the type of the dummy argument. [AX]
call av(n, v(1,j), ax)
----------------------------------^
Hi, the attached file (a modification of dndrv2) tries to compute eigenvalues and eigenvectors of a slightly modified identity matrix (which turns out to be singular). Applying a proper shift makes OP non-singular. However, the eigenvector corresponding to the eigenvalue 0 is a column of NaN. Even if I do not know exactly what happens, I would propose a simple fix. At the end of dneupd.f, there is the purification stage (do 110) in which some divisions by real numbers take place. The problem is that those numbers can be zero, as in the attached example. My proposal is to avoid the purification if it is the case. I would rewrite the block as
do 110 j=1, nconv
if ((workl(iheigi+j-1) .eq. zero) .and.
& (workl(iheigr+j-1) .ne. zero)) then
workev(j) = workl(invsub+(j-1)*ldq+ncv-1) /
& workl(iheigr+j-1)
else if (iconj .eq. 0) then
temp = dlapy2 ( workl(iheigr+j-1), workl(iheigi+j-1) )
if (temp .ne. zero) then
workev(j) = ( workl(invsub+(j-1)*ldq+ncv-1) *
& workl(iheigr+j-1) +
& workl(invsub+j*ldq+ncv-1) *
& workl(iheigi+j-1) ) / temp / temp
workev(j+1) = ( workl(invsub+j*ldq+ncv-1) *
& workl(iheigr+j-1) -
& workl(invsub+(j-1)*ldq+ncv-1) *
& workl(iheigi+j-1) ) / temp / temp
end if
iconj = 1
else
iconj = 0
end if
110 continue
I think it is a safe fix, it cannot do worse than dividing by zero.
dndrv2_47236.f.zip
(and future releases) for installation on systems without autotools present. Thanks!
I have some errors on HPC cluster (don't see anything like that on macOS or Ubuntu 16 or 17):
At line 68 of file <blabla>/arpack-ng-3.4.0/PARPACK/UTIL/MPI/pdvout.f
Fortran runtime error: Bad unit number in statement
The same issue with 3.5.0
.
From the description, it seems that the routine is for printing https://github.com/opencollab/arpack-ng/blob/master/PARPACK/UTIL/MPI/pdvout.f#L68
but I don't see where/why Arpack would print anything while solving symmetric hermitian generalized eigenproblem with shift-and-invert spectral transformation.
EDIT: I googled and it looks like COMMON variables do not have default initialization. Since I call arpack from C++ and link against both Arpack and pArpack, for now my workaround of this problem is
sed -i -e 's/\(\s*msglvl = \)\(.*\)/\10/g' *.f
Hi,
I'm not sure if this is an issue, or I am misunderstanding how starting vectors are applied.
Running dsdrv1 by default supplies me with a set of m eigenvectors after X major iterations. I figured if I used these vectors as initial guesses in a new dsdrv1 run on the same eigenvalue problem, the number of iterations would be dramatically reduced. I found this documentation on starting vectors, which recommends using the first column of v (the first eigenvector) as a starting vector.
This does indeed result in fewer iterations (down from 150 or so to 16), but only if nev (the number of eigenvectors/eigenvalues desired) is set to 1. If nev > 1, no reduction in iterations occurs.
I ask because I am using arpack to solve a set of nearly-identical eigenvalue problems, and would like to use the results from one as a starting point for another. Does arpack facilitate this when nev > 1?
Thanks
See: https://buildd.debian.org/status/fetch.php?pkg=arpack&arch=i386&ver=3.6.0-1&stamp=1528229606&raw=0
../build-aux/test-driver: line 107: 7229 Segmentation fault "$@" > $log_file 2>&1
FAIL: icb_arpack_cpp
../build-aux/test-driver: line 107: 7200 Segmentation fault "$@" > $log_file 2>&1
FAIL: icb_arpack_c
@dbeurle @fghoussen Rings a bell?
The function pdlamch10 ends with the following code:
PDLAMCH = TEMP
*
* End of PDLAMCH
*
END
Since the variable was not renamed to PDLAMCH10, the return variable is not set and the correct tolerance values are not being used.
Referencing http://forge.scilab.org/index.php/p/arpack-ng/issues/1430/
The dnsimp test fails when the build tree is not the source tree because a matrix file needed for the test is not present.
I built arpack-ng with ATLAS 3 installed by full LAPACK interface. Then tried to run tests and get a test failure in 'dnsimp'
This is test-suite log:
.. contents:: :depth: 2
At line 194 of file /media/home/programs/arpack-ng-3.1.4/TESTS/dnsimp.f (unit = 10, file = '')
Fortran runtime error: File 'testA.mtx' does not exist
i experience a segmentation fault error in Parpack 3.1.4
and 3.2.0
compiled
with Scalapack 2.0.2
and veclibfort
. I don't know whether this is an issue of
Parpack, Scalapack or a mistake in a driving program.
I get the SEGV error when using Parpack inside a FEM code deal.II dealii/dealii#1146
but a more straight forward way to reproduce the problem is:
1. download a simple program from here (not written by myself)
http://forge.scilab.org/index.php/p/arpack-ng/issues/1480/
2. compile and run it even with 1 processor.
Expected result: pass
Actual result:
Process 12397 stopped
* thread #1: tid = 0xb446d, 0x0000000115765ccc
libscalapack.dylib`dgamx2d_ + 64, queue = 'com.apple.main-thread',
stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
frame #0: 0x0000000115765ccc libscalapack.dylib`dgamx2d_ + 64
libscalapack.dylib`dgamx2d_:
-> 0x115765ccc <+64>: movq (%rax,%rdi,8), %r14
0x115765cd0 <+68>: movb (%rdx), %bl
0x115765cd2 <+70>: movb %bl, %al
0x115765cd4 <+72>: addb $-0x41, %al
(lldb) bt
* thread #1: tid = 0xb446d, 0x0000000115765ccc
libscalapack.dylib`dgamx2d_ + 64, queue = 'com.apple.main-thread',
stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
* frame #0: 0x0000000115765ccc libscalapack.dylib`dgamx2d_ + 64
frame #1: 0x00000001158f9157 libscalapack.dylib`pdlamch_ + 167
frame #2: 0x000000011601d75b libparpack.2.dylib`pdsaupd_ + 2267
frame #3: 0x0000000100027aac dvr_parpack`pdsaupd(n=256, nev=10,
Evals=0x000000011f311fa0, Evecs=0x0000000120803200) + 1100 at
dvr_parpack.cc:308
frame #4: 0x0000000100026621 dvr_parpack`main(nr_arguments=2,
arguments=0x00007fff5fbffa60) + 449 at dvr_parpack.cc:142
frame #5: 0x00007fff92e545c9 libdyld.dylib`start + 1
I would appreciate if somebody could try to compile the driver
program above to see if the issue is there on his/her system.
p.s. i also reported this issue in Scalapack forum, but did not have
any replies there so far
http://icl.cs.utk.edu/lapack-forum/viewtopic.php?f=13&t=4676&p=11434#p11434
I've tried both the automake and the CMake methods - same problem. I can build arpack-ng (while linking it to libopenblas.a) successfully, but when i go to use the library i always get:
libarpack.a(cgetv0.o): In function cgetv0_': arpack-ng/SRC/cgetv0.f:233: undefined reference to
clarnv_'
libarpack.a(dgetv0.o): In function dgetv0_': arpack-ng/SRC/dgetv0.f:236: undefined reference to
dlarnv_'
libarpack.a(sgetv0.o): In function sgetv0_': arpack-ng/SRC/sgetv0.f:236: undefined reference to
slarnv_'
libarpack.a(zgetv0.o): In function zgetv0_': arpack-ng/SRC/zgetv0.f:233: undefined reference to
zlarnv_'
Using nm (and strings), i verify that my libopenblas.a does indeed define these symbols. So what is the problem?
as of now cmake build miss the following important features:
install
target with CMAKE_INSTALL_PREFIX
shared
libraries is broken due to a missing dependency of parpack on arpack.On Cygwin, latest 3.4.0 arpack sets libtool wrongly.
Comparing 3.3.0 libtool version with 3.4.0 on the build trees, I have (as extract)
-libext=a
+libext=lib
-shlibpath_overrides_runpath=yes
+shlibpath_overrides_runpath=unknown
-library_names_spec="$libname.dll.a"
+library_names_spec="$libnameecho \$release | \$SED -e s/[.]/-/g
$versuffix$shared_ext $libname.lib"
-soname_spec="echo \$libname | sed -e s/^lib/cyg/``echo \$release | \$SED -e s/[.]/-/g
$versuffix$shared_ext"
+soname_spec=""
It seems libtool is incorrectly set for MSVC platform
As the changes on configure.ac are mainly base on the addition of "ax_check_compile_flag.m4"
and its call, I guess the root cause is there but I was unable to identify the exact culprit.
$ libtool --version
libtool (GNU libtool) 2.4.6
$ automake --version
automake (GNU automake) 1.15
$./configure
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... no
checking for mawk... mawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking whether to enable maintainer-specific portions of Makefiles... no
checking for g77... no
checking for xlf... no
checking for f77... no
checking for frt... no
checking for pgf77... no
checking for cf77... no
checking for fort77... no
checking for fl32... no
checking for af77... no
checking for xlf90... no
checking for f90... no
checking for pgf90... no
checking for pghpf... no
checking for epcf90... no
checking for gfortran... gfortran
checking whether the Fortran 77 compiler works... yes
checking for Fortran 77 compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU Fortran 77 compiler... yes
checking whether gfortran accepts -g... yes
checking for gcc... gcc
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking whether gcc understands -c and -o together... yes
checking for style of include used by make... GNU
checking dependency style of gcc... gcc3
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking how to print strings... printf
checking for a sed that does not truncate output... /bin/sed
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for fgrep... /bin/grep -F
checking for ld used by gcc... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... yes
checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B
checking the name lister (/usr/bin/nm -B) interface... BSD nm
checking whether ln -s works... yes
checking the maximum length of command line arguments... 1572864
checking whether the shell understands some XSI constructs... yes
checking whether the shell understands "+="... yes
checking how to convert x86_64-unknown-linux-gnu file names to x86_64-unknown-linux-gnu format... func_convert_file_noop
checking how to convert x86_64-unknown-linux-gnu file names to toolchain format... func_convert_file_noop
checking for /usr/bin/ld option to reload object files... -r
checking for objdump... objdump
checking how to recognize dependent libraries... pass_all
checking for dlltool... no
checking how to associate runtime and link libraries... printf %s\n
checking for ar... ar
checking for archiver @FILE support... @
checking for strip... strip
checking for ranlib... ranlib
checking command to parse /usr/bin/nm -B output from gcc object... ok
checking for sysroot... no
checking for mt... mt
checking if mt is a manifest tool... no
checking how to run the C preprocessor... gcc -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking for dlfcn.h... yes
checking for objdir... .libs
checking if gcc supports -fno-rtti -fno-exceptions... no
checking for gcc option to produce PIC... -fPIC -DPIC
checking if gcc PIC flag -fPIC -DPIC works... yes
checking if gcc static flag -static works... yes
checking if gcc supports -c -o file.o... yes
checking if gcc supports -c -o file.o... (cached) yes
checking whether the gcc linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes
checking whether -lc should be explicitly linked in... no
checking dynamic linker characteristics... GNU/Linux ld.so
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... yes
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... yes
checking for gfortran option to produce PIC... -fPIC
checking if gfortran PIC flag -fPIC works... yes
checking if gfortran static flag -static works... yes
checking if gfortran supports -c -o file.o... yes
checking if gfortran supports -c -o file.o... (cached) yes
checking whether the gfortran linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes
checking dynamic linker characteristics... (cached) GNU/Linux ld.so
checking how to hardcode library paths into programs... immediate
checking how to get verbose linking output from gfortran... -v
checking for Fortran 77 libraries of gfortran... -L/usr/lib/gcc/x86_64-linux-gnu/4.6 -L/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../x86_64-linux-gnu -L/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../../lib -L/lib/x86_64-linux-gnu -L/lib/../lib -L/usr/lib/x86_64-linux-gnu -L/usr/lib/../lib -L/usr/lib/gcc/x86_64-linux-gnu/4.6/../../.. -lgfortran -lm -lquadmath
checking for dummy main to link with Fortran 77 libraries... none
checking for Fortran 77 name-mangling scheme... lower case, underscore, no extra underscore
checking if sgemm_ is being linked in already... no
checking for ATL_xerbla in -latlas... no
checking for sgemm_ in -lblas... yes
checking for dgemm_ in -ldgemm... no
checking for sgemm_ in -lmkl... no
checking for sgemm_ in -framework vecLib... no
checking for sgemm_ in -lcxml... no
checking for sgemm_ in -ldxml... no
checking for sgemm_ in -lscs... no
checking for sgemm_ in -lcomplib.sgimath... no
checking for sgemm_ in -lblas... (cached) yes
checking for sgemm_ in -lessl... no
checking for sgemm_ in -lblas... (cached) yes
checking for cheev_... no
checking for cheev_ in -llapack... yes
checking for MPI mode... checking that generated files are newer than configure... done
configure: creating ./config.status
config.status: creating arpack.pc
config.status: creating Makefile
config.status: creating SRC/Makefile
config.status: creating UTIL/Makefile
config.status: creating TESTS/Makefile
config.status: creating EXAMPLES/Makefile
config.status: creating EXAMPLES/BAND/Makefile
config.status: creating EXAMPLES/COMPLEX/Makefile
config.status: creating EXAMPLES/NONSYM/Makefile
config.status: creating EXAMPLES/SIMPLE/Makefile
config.status: creating EXAMPLES/SVD/Makefile
config.status: creating EXAMPLES/SYM/Makefile
config.status: creating PARPACK/Makefile
config.status: creating PARPACK/SRC/Makefile
config.status: creating PARPACK/SRC/MPI/Makefile
config.status: creating PARPACK/UTIL/Makefile
config.status: creating PARPACK/UTIL/MPI/Makefile
config.status: creating PARPACK/UTIL/BLACS/Makefile
config.status: creating PARPACK/EXAMPLES/MPI/Makefile
config.status: creating PARPACK/EXAMPLES/BLACS/Makefile
config.status: creating PARPACK/SRC/BLACS/Makefile
config.status: executing depfiles commands
config.status: executing libtool commands
$make check
Making check in UTIL
make[1]: Entering directory `/home/f2/Documents/arpack-ng/UTIL'
make[1]: Nothing to be done for `check'.
make[1]: Leaving directory `/home/f2/Documents/arpack-ng/UTIL'
Making check in SRC
make[1]: Entering directory `/home/f2/Documents/arpack-ng/SRC'
make[1]: Nothing to be done for `check'.
make[1]: Leaving directory `/home/f2/Documents/arpack-ng/SRC'
Making check in .
make[1]: Entering directory `/home/f2/Documents/arpack-ng'
make[1]: Nothing to be done for `check-am'.
make[1]: Leaving directory `/home/f2/Documents/arpack-ng'
Making check in TESTS
make[1]: Entering directory `/home/f2/Documents/arpack-ng/TESTS'
make dnsimp bug_1315_single bug_1315_double
make[2]: Entering directory `/home/f2/Documents/arpack-ng/TESTS'
make[2]: `dnsimp' is up to date.
make[2]: `bug_1315_single' is up to date.
make[2]: `bug_1315_double' is up to date.
make[2]: Leaving directory `/home/f2/Documents/arpack-ng/TESTS'
make check-TESTS
make[2]: Entering directory `/home/f2/Documents/arpack-ng/TESTS'
make[3]: Entering directory `/home/f2/Documents/arpack-ng/TESTS'
PASS: dnsimp
PASS: bug_1315_single
FAIL: bug_1315_double
make[4]: Entering directory `/home/f2/Documents/arpack-ng/TESTS'
make[4]: Nothing to be done for `all'.
make[4]: Leaving directory `/home/f2/Documents/arpack-ng/TESTS'
============================================================================
Testsuite summary for arpack-ng 3.2.0
============================================================================
# TOTAL: 3
# PASS: 2
# SKIP: 0
# XFAIL: 0
# FAIL: 1
# XPASS: 0
# ERROR: 0
============================================================================
See TESTS/test-suite.log
Please report to https://github.com/opencollab/arpack-ng/issues/
============================================================================
make[3]: *** [test-suite.log] Error 1
make[3]: Leaving directory `/home/f2/Documents/arpack-ng/TESTS'
make[2]: *** [check-TESTS] Error 2
make[2]: Leaving directory `/home/f2/Documents/arpack-ng/TESTS'
make[1]: *** [check-am] Error 2
make[1]: Leaving directory `/home/f2/Documents/arpack-ng/TESTS'
make: *** [check-recursive] Error 1
===========================================
arpack-ng 3.2.0: TESTS/test-suite.log
===========================================
# TOTAL: 3
# PASS: 2
# SKIP: 0
# XFAIL: 0
# FAIL: 1
# XPASS: 0
# ERROR: 0
.. contents:: :depth: 2
FAIL: bug_1315_double
=====================
1000.000000
999.000000
997.000000
I am trying to verify the results printed by the Examples/simple/dssimp
example:
...
==========================================
= Symmetric implicit Arnoldi update code =
= Version Number: 2.4 =
= Version Date: 07/31/96 =
==========================================
= Summary of timing statistics =
==========================================
Total number update iterations = 8
Total number of OP*x operations = 125
Total number of B*x operations = 0
Total number of reorthogonalization steps = 125
Total number of iterative refinement steps = 0
Total number of restart steps = 0
Total time in user OP*x operation = 0.000000
Total time in user B*x operation = 0.000000
Total time in Arnoldi update routine = 0.000000
Total time in saup2 routine = 0.000000
Total time in basic Arnoldi iteration loop = 0.000000
Total time in reorthogonalization phase = 0.000000
Total time in (re)start vector generation = 0.000000
Total time in trid eigenvalue subproblem = 0.000000
Total time in getting the shifts = 0.000000
Total time in applying the shifts = 0.000000
Total time in convergence testing = 0.000000
Ritz values and relative residuals
----------------------------------
Col 1 Col 2
Row 1: 8.91167D+02 1.82720D-15
Row 2: 9.19781D+02 1.22638D-15
Row 3: 9.19781D+02 9.11187D-16
Row 4: 9.48395D+02 1.16257D-15
_SSIMP
======
Size of the matrix is 100
The number of Ritz values requested is 4
The number of Arnoldi vectors generated (NCV) is 20
What portion of the spectrum: LM
The number of converged Ritz values is 4
The number of Implicit Arnoldi update iterations taken is 8
The number of OP*x is 125
The convergence criterion is 1.1102230246251565E-016
If I understand the output properly, it is calculating the largest magnitude (LM) and it found the following 4 eigenvalues:
Row 1: 8.91167D+02
Row 2: 9.19781D+02
Row 3: 9.19781D+02
Row 4: 9.48395D+02
When I do the same calculation using NumPy:
n = 10
A = diag([4]*n)+diag([-1]*(n-1), 1)+diag([-1]*(n-1), -1)
print A
print eigvalsh(A)
I however get:
[[ 4 -1 0 0 0 0 0 0 0 0]
[-1 4 -1 0 0 0 0 0 0 0]
[ 0 -1 4 -1 0 0 0 0 0 0]
[ 0 0 -1 4 -1 0 0 0 0 0]
[ 0 0 0 -1 4 -1 0 0 0 0]
[ 0 0 0 0 -1 4 -1 0 0 0]
[ 0 0 0 0 0 -1 4 -1 0 0]
[ 0 0 0 0 0 0 -1 4 -1 0]
[ 0 0 0 0 0 0 0 -1 4 -1]
[ 0 0 0 0 0 0 0 0 -1 4]]
[ 2.08101405 2.31749293 2.69027853 3.16916997 3.71537032 4.28462968
4.83083003 5.30972147 5.68250707 5.91898595]
So the 4 largest eigenvalues should be:
4.83083003 5.30972147 5.68250707 5.91898595
Where did I make a mistake? Is the result of dssimp wrong, or am I doing something wrong? The NumPy calculation seems correct to me.
In the X{n,s}aupd.f file, the final timing statistics refer to version 2.4 (07/31/96). Moreover, there is a file version.h which sets VERSION_NUMBER to ' 2.1' and VERSION_DATE to ' 11/15/95', but it appears to be unused. I think X{n,s}aupd.f should use version.h, which in turn should be synchronized with configure.ac.
If the arnoldi runs on a custom communicator created for some subset of available cpus and after successful completion the second execution of the arnoldi with a communicator for a larger number subset of available cpus it will cause deadlock due to the following condition in code:
data first / .true. /
c
c %-----------------------%
c | Executable Statements |
c %-----------------------%
c
if (first) then
...
first = .false.
...
endif
the variable first
is set to false
in the first subset of cpus and will avoid a condition body evaluation, but other cpus have first
equals to true
and will evaluate condition body. Inside the condition body there is a p*lamch10
call where the MPI_ALLREDUCE
is called.
the possible workaround is to perform MPI_ALLREDUCE(...MPI_LAND...)
for the variable first
to be sure that all cpus inside communicator have the same value. But maybe there is a better solution.
Hi,
I cannot compile with support for mpi. I got
/usr/bin/ld: cannot find -lmpi
collect2: error: ld returned 1 exit status
Makefile:497: recipe for target 'libparpack.la' failed
make[2]: *** [libparpack.la] Error 1
make[2]: Leaving directory '/home/alberto/programs/sources/arpack-ng/PARPACK/SRC/MPI'
Makefile:366: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory '/home/alberto/programs/sources/arpack-ng/PARPACK'
Makefile:456: recipe for target 'all-recursive' failed
any help?
Thanks in advance
I noticed the Travis build script doesn't test against the specified minimum 2.8.6 but 3.1.9 instead. Which one is the intended version?
@dbeurle @fghoussen @davydden Are you ok?
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.