[Wien] Compiling Wien2k 21.1 on Ubuntu 20.04 with gfortran
Gavin Abo
gabo13279 at gmail.com
Fri Nov 26 09:44:59 CET 2021
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20211126/ad94da11/attachment.htm>
More information about the Wien
mailing list