ABINIT Discussion Forums

some versions of publically available blas / lapack are either incomplete or buggy, and could be tested for fairly simply in the configure stage

1) on mac OSX but also some ifort, the zdotc has a problem, and returns garbage (a simple loop on the side shows it is false)

2) some versions of mkl (at least 9.1 to my knowledge) do not provide ilaver (and possibly other routines). A small conftest with this call would be nice. Matteo now uses ilaver in some module somewhere...

Matthieu

mverstra wrote:some versions of publically available blas / lapack are either incomplete or buggy, and could be tested for fairly simply in the configure stage

1) on mac OSX but also some ifort, the zdotc has a problem, and returns garbage (a simple loop on the side shows it is false)

I usually use the overloaded interface xdotc defined in m_blas when I want a complex scalar product.
Therefore one can wrap the intrinsic DOT_PRODUCT instad of the blas version If the configure stage reported that
the blas version is buggy.

mverstra wrote:2) some versions of mkl (at least 9.1 to my knowledge) do not provide ilaver (and possibly other routines). A small conftest with this call would be nice. Matteo now uses ilaver in some module somewhere...

ilaver has been removed in v6.1.1. It makes life easier but it causes a lot of portability problems
since some (crappy) Lapack implementations do not provide it
M

For 1), just send me a simple program that triggers the problem and I'll add it into the build system. It will define HAVE_LINALG_ZDOTC_BUG.

For 2), I'll add a little test that defines HAVE_LINALG_ILAVER.

Please tell me if this is what you want.

HAVE_LINALG_ILAVER is not needed as ilaver is not called anymore.

It seems that only CDOTC, CDOTU, ZDOTC, and ZDOTU are problematic
when Mac OS X's Vec lib is used.
See http://developer.apple.com/hardwaredriv ... rrata.html.

In my branch I've introduced two new CPP flags
HAVE_LINALG_ZDOTC_BUG
HAVE_LINALG_ZDOTU_BUG

The overloaded interface (xdotc and xdotu) will fall back
to a plain Fortran implementation if the functions provided
by the external library are problematic.
After this change, almost all the tests in the GW test suite passed on my mac.
Only wannier90_t03 failed, but I don't know if the failure is related to blas.

I've also tried the wrappers suggested in the link above
but it didn't work on my mac 10.6.3
gfortran supports the hpf extension %val() but I got
an undefined reference during the lik of the clib wrappers.
I'm completely new to Mac OS, but I will try to understand
what's wrong in my environment.

For the time being, one has to define manually the CPP flags
in abi_common.h. However these flags should be defined during the configuration
of the package. I can provide simple F90 tests if not yet done, just let me know.

Matteo

Unfortunately it's not only MacOSX, but some versions of blas/lapack bundled with old RHEL distros are bad as well. And a _lot_ of people still have these crappy old RHE versions. Being conservative is good for stability, but not fixing bugs is borderline ridiculous.

Great, so we have the macros set. Thanks!

Matthieu