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 a SIGSEGV segmentation fault (core dumped)
runtime error when running lapw1 even though OpenBLAS 0.3.18 compiled
successfully. I try to use the latest stable release of OpenBLAS, which
is currently 0.3.18 [2]. However, in my case: My system has an AMD
processor that targets Barcelona, and as it turns out, I found an
OpenBLAS issue report at [3]. There it describes how OpenBLAS 0.3.15
works but OpenBLAS 0.3.16, 0.3.17, and 0.3.18 crashes for a processor
that has a Barcelona target where the fix won't be available until a
future 0.3.19 release. As a workaround until 0.3.19 becomes available,
I found that I could use the current OpenBLAS development version
(0.3.18.dev) to have the fix.
I have not tried the compile settings at [4]. I'm using just a 'basic'
set of compile settings for being able to do serial, k-point parallel,
or mpi parallel with WIEN2k. By 'basic', I mean I using non-optimized
flags as I haven't went through the GNU documentation [5] to optimize
all the flags for my specific processor.
Should you be interested in the details on how I installed WIEN2k 21.1
for my system. I have made it available at [6], which you will probably
find to be very similar to the older install described at [7].
[1] https://github.com/gsabo/WIEN2k-Patches/tree/master/21.1
[2] https://github.com/xianyi/OpenBLAS/releases
[3] https://github.com/xianyi/OpenBLAS/issues/3421
[4]
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg21482.html
[5] https://gcc.gnu.org/wiki/GFortran
[6]
https://github.com/gsabo/WIEN2k-Docs/blob/main/WIEN2k21.1_Install_with_gfortran.pdf
[7]
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg21134.html
Kind Regards,
Gavin
WIEN2k user
On 11/24/2021 3:09 AM, David Holec wrote:
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 lapw1 (on the test case from
http://www.wien2k.at/reg_user/benchmark/). The current setting are:
L Linker Flags: $(FOPT)
-L/usr/lib/x86_64-linux-gnu/openblas64-openmp
R R_LIBS (LAPACK+BLAS):
/usr/lib/x86_64-linux-gnu/openblas64-openmp/libopenblas64.so.0
-lpthread
(The rest is as I wrote in my first email.) Here is the list of linked
libraries:
$ ldd lapw1
linux-vdso.so.1 (0x00007ffea57d6000)
*libopenblas64.so.0 => /lib/x86_64-linux-gnu/libopenblas64.so.0
(0x000014fe2b2e5000) *
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
(0x000014fe2b2c2000)
libgfortran.so.5 => /lib/x86_64-linux-gnu/libgfortran.so.5
(0x000014fe2affa000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x000014fe2aeab000)
libmvec.so.1 => /lib/x86_64-linux-gnu/libmvec.so.1
(0x000014fe2ae7f000)
libgomp.so.1 => /lib/x86_64-linux-gnu/libgomp.so.1
(0x000014fe2ae3d000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x000014fe2ac49000)
/lib64/ld-linux-x86-64.so.2 (0x000014fe2d4d3000)
libquadmath.so.0 => /lib/x86_64-linux-gnu/libquadmath.so.0
(0x000014fe2abff000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1
(0x000014fe2abe4000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x000014fe2abde000)
And here is the stacking fault (it doesn't tell me anything):
$x lapw1
Program received signal SIGSEGV: Segmentation fault - invalid memory
reference.
Backtrace for this error:
#0 0x148fb48b8d21 in ???
#1 0x148fb48b7ef5 in ???
#2 0x148fb452d20f in ???
#3 0x148fb54495fb in ???
Segmentation fault
0.949u 0.472s 0:00.84 167.8% 0+0k 14400+10992io 31pf+0w
Any idea?
With the settings I reported yesterday, everything works just fine
(though probably not very efficiently - but this is not a problem for
me as this binary is not a "production" binary on any HPC):
$ ldd lapw1
linux-vdso.so.1 (0x00007ffc60765000)
*libblas.so.3 => /lib/x86_64-linux-gnu/libblas.so.3 (0x0000150cec90f000)
liblapack.so.3 => /lib/x86_64-linux-gnu/liblapack.so.3
(0x0000150cec26b000) *
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
(0x0000150cec248000)
libgfortran.so.5 => /lib/x86_64-linux-gnu/libgfortran.so.5
(0x0000150cebf80000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x0000150cebe31000)
libmvec.so.1 => /lib/x86_64-linux-gnu/libmvec.so.1
(0x0000150cebe05000)
libgomp.so.1 => /lib/x86_64-linux-gnu/libgomp.so.1
(0x0000150cebdc1000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x0000150cebbcf000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1
(0x0000150cebbb4000)
/lib64/ld-linux-x86-64.so.2 (0x0000150cec9fc000)
libquadmath.so.0 => /lib/x86_64-linux-gnu/libquadmath.so.0
(0x0000150cebb6a000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x0000150cebb64000)
and:
$ x lapw1
STOP LAPW1 END
162.045u 0.918s 2:31.25 107.7% 0+0k 8976+37856io 35pf+0w
$ grep HORB *output1*
test_case.output1: TIME HAMILT (CPU) = 16.3, HNS = 20.0,
HORB= 0.0, DIAG = 125.9, SYNC = 0.0
test_case.output1: TIME HAMILT (WALL) = 4.4, HNS = 20.0,
HORB= 0.0, DIAG = 126.0, SYNC = 0.0
(I am using it on my 10-year old "type writer":
$lscpu
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
Vendor ID: GenuineIntel
CPU family: 6
Model: 26
Model name: Intel(R) Xeon(R) CPU W3550
@ 3.07GHz
)
---
*Dr David Holec*
/Computational Materials Science group/
Department of Materials Science
Montanuniversität Leoben/
/
/
/
Franz-Josef-Strasse 18, A-8700 Leoben, Austria
tel. +43-(0)3842-4024211
fax. +43-(0)3842-4024202
materials.unileoben.ac.at <http://materials.unileoben.ac.at/>
cms.unileoben.ac.at <http://cms.unileoben.ac.at/>
________________________________
WHERE RESEARCH MEETS FUTURE
_______________________________________________
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at:
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
