opencollab / arpack-ng Goto Github PK

View Code? Open in Web Editor NEW

271.0 19.0 117.0 2.61 MB

Collection of Fortran77 subroutines designed to solve large scale eigenvalue problems.

License: Other

Fortran 92.27% C 0.79% Shell 0.71% CMake 0.79% Makefile 0.29% M4 1.11% C++ 2.81% Python 1.24%

eigenvalue linear-algebra arpack parpack

arpack-ng's People

Contributors

Stargazers

Watchers

Forkers

thrasibule turboencabulator wpoely86 elezar m-reuter fxia22 rwirth davydden galileo73 tkelman alvesjose matzeri vtjnash mikeaddison93 jschueller iskakoff opoplawski hainanwang quanshengwu certik solertis yanshangongzi edwardbetts dlluxat cncae sylvestre luzpaz chchang810716 rohitnarayan wuwenbin2006 sanglier91 10110111 fghoussen exphp-forks geocug ypnos brioglade tlming16 renierm caliarim navytensor jurajhasik adamadanandy asartori86 ivan-pi subhadeep-maishal shenmidelin aamaricci 994148196 zuoluo201008 pv leaf-ym hikari126 thorben-frank gilliangrayson dschwoerer panagiotisrep j-b-o myroikon yihsuanliu zeta1999 anguschkan vegaandagev phillcli asellappen davidace ryanbernx dotlambda jonathanseng lwk205 ratnania dariomangoni kaihsin dimpase mathiaseugene 3rav robert-anderson mmuetzel payerle kingboxing dgleich 23abudushalamu joseeroman wztzjhn fermiq daiyixin liuyangzhuan fastamp mfernba 20170213 yxuanwang easifem secondmover fabienpean zhuyidong-yp eminsight tranqv rqzhang0 szhorvat hbliu80

arpack-ng's Issues

dnsimp test fails in VPATH builds

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.

Incorrect largest magnitude eigenvalue

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.

arpack-ng 3.2.0 test failure on x86_64-linux: bug_1315_double

$./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

[3.4.0] cmake build shortcomings

as of now cmake build miss the following important features:

install target with CMAKE_INSTALL_PREFIX
a way to specify Blas/Lapack libraries
building shared libraries is broken due to a missing dependency of parpack on arpack.

Some tests fail in Mac OS X 10.7.5 compiling with gfortran 4.8.4

Steps to reproduce the problem:

env F77=gnugfortran ./configure --prefix=/usr/local
make
make check

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

Test failure on i686-linux-gnu with ATLAS

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:

=========================================
arpack-ng 3.1.3: TESTS/test-suite.log

TOTAL: 2

PASS: 1

SKIP: 0

XFAIL: 0

FAIL: 1

XPASS: 0

ERROR: 0

.. contents:: :depth: 2

FAIL: dnsimp

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

arpack installs very generically named header files that conflict with other packages

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.

Wrong results with mode=LR

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.

Q.zip

p*napps cause deadlock when using custom communicators

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.

3.4.0 Libtool wrongly set for cygwin

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

Parpack segmentation fault in pdsaupd -> pdlamch -> dgamx2d

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

cannot compile with mpi

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

dneupd selects/calculates wrong eigenpairs if rvec = true

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.

COMMON block variables are not initialized in pArpack

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

TESTS/bug_1315_double hangs (indefinitely?) on ppc64le when built with 64-bit interface

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.

MPI examples should not be installed

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

Timing statistics refer to the old 2.4 version

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.

Building the Visual Studio project fails

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.

arpack-ng 3.2.0 test failure on OS-X 10.10 w gfortran 5.1: bug_1315_[single|double]

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?

Attach a post-bootstrap tarball to github releases for 3.3.0

(and future releases) for installation on systems without autotools present. Thanks!

Problems linking to OpenBLAS

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 toclarnv_'
libarpack.a(dgetv0.o): In function dgetv0_': arpack-ng/SRC/dgetv0.f:236: undefined reference todlarnv_'
libarpack.a(sgetv0.o): In function sgetv0_': arpack-ng/SRC/sgetv0.f:236: undefined reference toslarnv_'
libarpack.a(zgetv0.o): In function zgetv0_': arpack-ng/SRC/zgetv0.f:233: undefined reference tozlarnv_'

Using nm (and strings), i verify that my libopenblas.a does indeed define these symbols. So what is the problem?

cmake build offers no option to run EXAMPLES tests

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.

Enable ILP64 testing in Travis CI

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

cmake build can't generate static libraries

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?

C/C++ bindings const and std::complex

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.

bug_1315 fails intermittently on travis

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

Problem with Complex Generalized Eigenvalue problem (Double precision ok)

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.

pdlamch10 return variable not correct after renaming pdlamch

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.

github repo must contain generated configure script

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.

No reduction in iterations when supplying a starting vector to dsaupd

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

icb_arpack_cpp: testsuite fails on i386

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?

Wrong type corresponding to arrays of `logical` in arpack.hpp

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.

NaN eigenvector in shift-invert mode

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

Travis ci should be moved to the new infra

http://docs.travis-ci.com/user/migrating-from-legacy/

Not sure how to do apt-get build-dep arpack-ng with this new infra.

Release a new version of arpack-ng

@dbeurle @fghoussen @davydden Are you ok?

rename pslamch to pslamch10 to avoid symbol collision with ScaLAPACK

Could you rename pslamch to pslamch10 to avoid symbol collision with ScaLAPACK, as you did with pdlamch in #21

Centos 6.6 libtool too old

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)

OpenMP support

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

icb_parpack_cpp test is failing on ppc64el and others archs

https://buildd.debian.org/status/fetch.php?pkg=arpack&arch=ppc64el&ver=3.6.1-1&stamp=1529756139&raw=0

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)

Wrong results with generalized eigenvalue problem

I'm using arpack on visual studio 2015 + intel fortran 2017 to solve generalized eigenvalue of finite element method.

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.

Arpack-ng make check fail on OSX 10.10.5 with gfortran 5.1 [bug_1315_single]

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.

Linking with OpenBlas fails

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?

cmake build doesn't install arpack.pc

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)

Compilation fails with ifort -warn all

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

test failure on x86_64-linux: bug_1315_single

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.

dssimp result incorrect?

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.

PkgConfig file?

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.

Can you please commit configure to repo too?

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.

CMake minimum version not tested

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?

Allow calling BLAS functions with suffix to use ILP64 BLAS

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