* Propagate dependencies in CMake configuration file
* Test that CMake find_package(arpackng) finds arpack in standard locations
Co-authored-by: Franck HOUSSEN <fghoussen@users.noreply.github.com>
lapack ?larnv.
This means killing inits variable:
- Using MPI, inits (shared variable) may be set to false by one proc,
and prevent other procs to initialize seeds (as inits is shared by
use of the save fortran keyword).
- Not using MPI, inits only prevents from re-initializing seeds which
have already been initialized.
This commit is not-op. From a functional point of view, we are doing
the same thing. From an implementation point of view, we make sure
iseed is always (for all MPI procs) initialized to values allowed
by lapack (if not, lapack crashes).
This problem doesn't occur with sequential code. Changes have been
done in both sequential and MPI code to keep things symmetric.
* [CI] Test pyarpack on macos.
* Fix pyarpack compilation warning: seems like default is python3 now.
* Improve pyarpack doc.
* pyarpack: run with latest boost-python version and require Boost >= 1.78.
Replaced _Complex types with a_fcomplex and a_dcomplex in all C/C++ files.
Replaced uses of I and _Complex_I with the CMPLXand CMPLXF constructors.
For MSVC, defined those constructors as macros that call MSVC's functions.
Updated the CHANGES file.
Change the continuation line format for stat.h, debug.h
AOCC flang compiler is complaining about the continuation lines in these
two files. It does not complain about similar continuation lines in
files (e.g. SRC/icbacn.F90), so I believe this is due to flang setting
the Fortran dialect to something like F77 for most of the compilations,
which cause problems with these *.h files.
I cannot find a way to force flang Fortran dialect to accept the & at
end of line continuation marker, so this patch changes the continuation
lines in these two files (stat.h, debug.h) to use continuation marker in
column 6.
This should fix#300
c45094c broke the workflow: CI triggered on PR (modified code) was
actually testing master codebase (untouched code). Solution:
- Drop pull_request_target: use pull_request
- Drop all docker jobs (which need pull_request_target to be based
on master to be able to access opencollab secrets)
- Remove opencollab secrets (docker login and password)
- Drop coverage jobs (OK with TravisCI but never worked with
github-actions)
Franck HOUSSEN