Hi Gavin,
I think steps 1-5 (more or less the first 6 pages) can simplified to
something like "sudo apt instal libxc-dev openblas-openmp-dev
libscalapack-openmpi-dev openmpi-common libopenmpi-dev libfftw3-dev
libfftw3-mpi-dev ...". (I just googled the package names as I'm not
Ubuntu user, but I
I'm using Ubuntu 20.04 LTS also but with a patched WIEN2k 21.1 that was
compiled with gfortran and OpenBLAS. The WIEN2k 21.1 bug fixes
(patches) I got from the past posts in the mailing list. A list of the
url links to those posts are in the README file at [1].
I also recently encountered
Hi David,
this is as good as it goes I guess, the HAMILT was speed up by ~30%,
but it is not so noticeable, because it actually scales much better
with the thread number than the rest (so it is actually running much
faster than the other parts at 4 threads, therefore further
improvements are not
Hi Pavel,
I have added now -DHAVE_LIBMVEC to the compiler options as you have
suggested (and removed it from the preprocessor flags).
O Compiler options:-ffree-form -O2 -ftree-vectorize
-march=native -ffree-line-length-none -ffpe-summary=none -DHAVE_LIBMVEC
P Preprocessor flags
On Wed, 2021-11-24 at 16:51 +0100, Peter Blaha wrote:
> Just for information: the -DHAVE_LIBMVEC is a preprocessor option
> (like -DINTEL_VML for ifort) and will speedup the HAMILT part due to
> a vectorization of cosine/sine functions.
Sorry for not being specific enough, -DHAVE_LIBMVEC should
I see... I have added it to preprocessor flags (hopefully that is correct):
P Preprocessor flags -DParallel -DHAVE_LIBM
recompiled and ran the test again - not a significant speed-up though:
$ x lapw1
STOP LAPW1 END
115.970u 2.083s 0:31.90 370.0% 0+0k 22400+37864io 43pf+0w
David
Just for information: the -DHAVE_LIBMVEC is a preprocessor option (like
-DINTEL_VML for ifort) and will speedup the HAMILT part due to a
vectorization of cosine/sine functions.
As far as I remember, it is available only with more recent
gfortran/openblas versions, therefore not yet a
Dear David,
nice, ~30 seconds instead of ~150 :-)
BTW is this already with "-DHAVE_LIBMVEC" in compiler options?
For your real workflow you might also try to experiment with the number
of threads vs number of k-points in parallel (now it seems you are
already running at 4 threads for the
This is a prime example how one can benefit from using the proper
software, much more than when buying a more expensive hardware.
The speedup from 150 to 30 seconds (wall-time factor 5) on a 4-core cpu
is impressive.
Peter Blaha
Am 24.11.2021 um 13:55 schrieb David Holec:
Dear Pavel,
Many
Dear Pavel,
Many thanks again for your patience and guidance. With the
libopenblas-openmp-dev package it seems to work well!
$ ldd lapw1
linux-vdso.so.1 (0x7ffca83d8000)
*libopenblas.so.0 => /lib/x86_64-linux-gnu/libopenblas.so.0
(0x14563f924000) *
libgfortran.so.5
Hi David,
well, it is hard to say without the debug info why the OpenBLAS crahes.
My guess is that you link with the 64bit interface, try to install the
standard one (openblas-openmp-devel) and replace openblas64-openmp with
openblas-openmp everywhere in you config. Also remove the -lpthread
Hi Pavel,
Many thanks for your insights. As you know, I am not an expert on how to
compile codes, for me, this is sadly a trial and error adventure.
I tried to compile it against the openblas library, but although the
compilation ends without any errors, I get a segmentation fault when
running
Hi David,
as you said it works for you, so feel free to ignore, but I have some
further tips if you are interested. Ubuntu switches between the
different blas and lapack using the "alternatives", so its difficult to
say if you actually link with the correct one.
"ldd lapw1" in WIENROOT should
Dear all,
I have just spent some time making Wien2k run on my single machine running
Ubuntu 20.04 with gfortran/gcc. Since I am not an expert, it was a trial
and error, but it seems that I found a working combination (sadly, the
default parameters didn't work for me). Maybe this will help
14 matches
Mail list logo
