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)

[zyzhang1992]

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

[boegel]

Duplicate of #21, fixed in #26

[dev-zero]

well, the warning might be something we should also take care of, but yes, the error should be solved in the latest HEAD

[boegel]

@dev-zero Any plans for a new release that includes the fix?

[dev-zero]

@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?

[scivision]

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.

[julielangou]

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

[scivision]

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?

[julielangou]

for sure , yes - I think this is a nice addition

[scivision]

Thanks @julielangou I made #77 for this.