scalapack
scalapack copied to clipboard
mpif90 -O0 -c blacstest.f for blacstest.f with error Rank mismatch between actual argument at (1) and actual argument at (2) (scalar and rank-1)
I encountered the following error while installing the development version of scalapack with openmpi 4.0.5/gcc 10.1.0:
Warning: Fortran 2018 deleted feature: Shared DO termination label 10 at (1) blacstest.f:8492:39:
8489 | CALL BTRECV(3, 1, NERR2, K, IBTMSGID()+50) | 2 ...... 8492 | CALL BTRECV(3, NERR2*6, IERR, K, IBTMSGID()+51) | 1 Error: Rank mismatch between actual argument at (1) and actual argument at (2) (scalar and rank-1) blacstest.f:8493:39:
8489 | CALL BTRECV(3, 1, NERR2, K, IBTMSGID()+50) | 2
Duplicate of #21, fixed in #26
well, the warning might be something we should also take care of, but yes, the error should be solved in the latest HEAD
@dev-zero Any plans for a new release that includes the fix?
@boegel Sorry, by "we" I meant we as in "the community of ScaLAPACK users", I am not a ScaLAPACK developer with the power to make a release.
But there seem to be only a few minor bugs (documentation and build system) which could probably be easily solved, and maybe one should ask @scivision (https://github.com/scivision/scalapack) @pradeeptrgit @nagendra (https://github.com/amd/scalapack) to submit PRs to issues they found before finalizing a ScaLAPACK 2.1.1. @julielangou what do you think?
I made my Scalapack fork to allow building only the numerical precision desired, which can be a 4x Scalapack build speedup. Also I took out a lot of the ancient Scalapack CMake syntax and assumed a fairly recent CMake 3.x. This makes the Scalapack build noticeably faster and more stable.
Note: next CMake release will deprecate a wide swath of CMake 2.x syntax, so perhaps a melding of the approach I used with the existing Official Scalapack CMake will be of wider benefit in the future.
@dev-zero , yes seems like a good plan. We usually release end of November. We did not plan to have a release this November, but plan can changed especially if the CMake build needs rework.
@scivision, would you be able to submit a PR for the update to the Cmake ? - to only build the numerical precision desired is a great option, we would not mind integrating it.
Hi @julielangou, are you still interested in a CMake PR for Scalapack to build only certain precisions? That would avoid me needing to maintain scivision/scalapack repo.
Would you like the four CMake precision option()
to be just like Lapack e.g. BUILD_SINGLE
BUILD_COMPLEX16
and so on?
for sure , yes - I think this is a nice addition
Thanks @julielangou I made https://github.com/Reference-ScaLAPACK/scalapack/pull/77 for this.