Closed n-claes closed 1 year ago
Users having this issue can temporarily fix it by changing zggev3
to zggev
(remove the 3) in the QZ-direct solver module src/solvers/smod_qz_direct
.
Apply the change in line https://github.com/n-claes/legolas/blob/2dac2414c11de55d1c4fb89fd797e76e710dc956/src/solvers/smod_qz_direct.f08#L64-L67 and in line https://github.com/n-claes/legolas/blob/2dac2414c11de55d1c4fb89fd797e76e710dc956/src/solvers/smod_qz_direct.f08#L75-L78
After doing this recompilation should work until a fix has been rolled out.
To my knowledge, zggev3
has been included in LAPACK ever since v3.6.0 (November 2015). Presumably, these users thus have a highly outdated version of LAPACK. Performance is indeed less of a concern, but zggev3
(especially in more recent versions) is in certain cases significantly more accurate than zggev
, so I would try to find a different solution.
If I remember correctly, there is some logic in the build process to check for ARPACK, maybe something similar can be done to disable QZ for users with too old LAPACK versions.
Alternatively, you could sharpen the version requirements. The current recommended minimum version 3.5 will be a decade old in a few months. So putting 3.6 as bare minimum (already almost 8 years old) and the most recent release (as of writing 3.11) as recommended should ensure linking.
Issue description
Various users have reported compilation errors in the linking step due to
zggev3
not being found.This routine is the blocked variant of
zggev
, used in the QZ-direct solver. The weird thing is thatzggev
does in fact link and works properly, whereas both routines should be standard in the LAPACK library. Other solvers are also fine. I'm unable to reproduce this locallyBug report
Minimal example for reproduction I'm unable to reproduce this locally, it seems to depend on the machine and/or BLAS/LAPACK library versions though apparently it happens across multiple versions.
Actual result When compiling:
Expected result Proper compilation and linking.
Version info