My Community

Is it intentional that 5.2.11 david_inner.F uses dlasrt2()?
That's a ScaLAPACK routine, as far as I can tell, not in LAPACK (dlasrt() is). I understand why it's being used (the KEY argument), but is it really expected that the serial version be linked with ScaLAPACK now?

Noam

I was stumped by that as well. I located the Netlib version of the routine. It only requires lsame() and xerbla(), so a small addition to the Makefile did the trick:

# New  at vasp.5.2.11/david_inner.F:627: ScaLAPACK/LAPACK-3.1 routine dlasrt2()
# Plug in the standalone Netlib version from http://www.netlib.org/scalapack/html/src/dlasrt2.f .
LAPACK = -L${MKLROOT}/lib/em64t ../dlasrt2.f

I could successfully link with Intel-11 and MKL-10.2.6.038.


Michael
<span class='smallblacktext'>[ Edited Wed Dec 01 2010, 12:41AM ]</span>

I guess dlasrt2.f should be put to vasp.5.lib/ and the makefile should be modified:
DOBJ= ... dlasrt2.o
...
dlasrt2.o: dlasrt2.f
$(FC) $(FFLAGS) $(NOFREE) -c dlasrt2.f

anyway the effect is the same

Tamas

Although presumably you'll need to exclude it if you actually link in scalapack, because having 2 definitions of the same routine will confuse the linker. Not a huge deal, but it does suggest that maybe the local copy should have a special name, so as not to conflict with scalapack, or maybe be in vasp.5.2, rather than vasp.5.lib, so that it can be surrounded by #ifndef scaLAPACK.

Noam

It is not a problem, it is in an archive lib. However, mixing static and dynamic linking so can have unwanted side effects. Maybe it is better to make the object but not include it in libdmy and use it only in the serial makefile like lapack.

Tamas

please retrieve the latest version (dated to Dec 23rd) of vasp.5.2.11 and
check whether the error persists.

please retrieve the latest version (dated to Dec 23rd) of vasp.5.2.11 and
check whether the error persists.