[Wien] Compiling Wien2k 21.1 on Ubuntu 20.04 with gfortran
Pavel Ondračka
pavel.ondracka at email.cz
Fri Nov 26 14:42:12 CET 2021
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 think you get the point).
IMO there is no point compiling libraries on your own, especially if
you don't use any extra flags or optimizations. I think everything
relevant is in Ubuntu repos (maybe except ELPA?).
I've been linking with system libraries (even the mpi ones like
scalapack and ELPA) in Fedora for ages with no issues and no noticeable
performance loss. Everything important for performance (like openblas,
fftw or elpa has optimized kernels for multiple architectures and
proper runtime selection anyway).
Best regards
Pavel
On Fri, 2021-11-26 at 01:44 -0700, Gavin Abo wrote:
> 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 HolecComputational 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
> > cms.unileoben.ac.at
> > ________________________________
> > WHERE RESEARCH MEETS FUTURE
> _______________________________________________
> Wien mailing list
> Wien at 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
More information about the Wien
mailing list