[Wien] errors @ wien2k_21.1 compilation

venky ch chvenkateshphy at gmail.com
Tue Aug 3 23:06:36 CEST 2021


Dear Prof. Gerhard and Prof. Blaha,

Thanks for your replies. I have installed OneApi of Intel. I have installed
prerequisites first (3.25 Gb) and later, I have installed the HPC tool kit
(1.25 Gb) in my local folder (intel/oneapi/). However, although I have seen
the ifort, icc, mpiifort, mpicc executables, I don't find the mkl libraries
inside the "intel/oneapi/" path. Do I need to install a separate mkl tool
kit (I don't know whether a free version is available or not )..?  or
whether I missed it while installing OneApi..? Kindly give me a suggestion
about the mkl libraries path.

thanks

Venkatesh
Postdoctoral Fellow,
Department of Instrumentation and Applied Physics
IISc Bangalore, India


On Tue, Aug 3, 2021 at 3:33 PM Fecher, Gerhard <fecher at uni-mainz.de> wrote:

> why do you mix different versions of the intel compilers from 2013 and
> 2018 ?
> -I/opt/intel/composer_xe_2013.1.117/mkl/include
>  -I/home/proj/21/isuch/intel/compilers_and_libraries_2018.0.128/linux/mpi/intel64/include
>
>
> seems your setup is still faulty
>
> I am able to compile the latest Wien2k Version with the OneApi of Intel
> without problems, the same is true for older Versions, if I don't mix them
> up
>
> Ciao
> Gerhard
>
> DEEP THOUGHT in D. Adams; Hitchhikers Guide to the Galaxy:
> "I think the problem, to be quite honest with you,
> is that you have never actually known what the question is."
>
> ====================================
> Dr. Gerhard H. Fecher
> Institut of Physics
> Johannes Gutenberg - University
> 55099 Mainz
> ________________________________________
> Von: Wien [wien-bounces at zeus.theochem.tuwien.ac.at] im Auftrag von venky
> ch [chvenkateshphy at gmail.com]
> Gesendet: Dienstag, 3. August 2021 11:48
> An: L-marks at northwestern.edu
> Cc: A Mailing list for WIEN2k users
> Betreff: Re: [Wien] errors @ wien2k_21.1 compilation
>
> Dear Prof. Marks,
> Thanks for your email and suggestions. I have updated the mpi compiler and
> re-compiled the wien2k again. Although, the earlier problems seem to be
> solved. However, I have another error as given below.
>
> This is related to "seclit_par_tmp_.F:(.text+0x4755): undefined reference
> to `pzheevr_'"
>
> =========
>
> mpiifort -O1 -FR -mp1 -w -prec_div -pc80 -pad -ip -DINTEL_VML -traceback
> -assume buffered_io -I/opt/intel/composer_xe_2013.1.117/mkl/include
> -I/home/proj/21/isuch/intel/compilers_and_libraries_2018.0.128/linux/mpi/intel64/include
> -DParallel -c seclit_par_tmp_.F
> mv seclit_par_tmp_.o seclit_par.o
> rm seclit_par_tmp_.F
> mpiifort  -o ./lapw1c_mpi abc.o atpar.o bandv1.o calkpt.o cbcomb.o
> charge.o coors.o cputim.o dblr2k.o dgeqrl.o dgewy.o dgewyg.o dlbrfg.o
> dsbein1.o dscgst.o dstebz2.o dsyevx2.o dsyr2m.o dsyrb4.o dsyrb5l.o
> dsyrdt4.o dsywyv.o dsyxev4.o dvbes1.o eisps.o errclr.o errflg.o
> find_nloat.o forfhs.o gaunt.o gbass.o gtfnam.o hamilt.o hns.o horb.o
> inikpt.o inilpw.o lapw1.o latgen.o lmsort.o locdef.o lohns.o lopw.o matmm.o
> modules.o nn.o outerr.o outwinb.o ph.o prtkpt.o prtres.o pzheevx16.o
> rdswar.o rint13.o rotate.o rotdef.o seclit.o seclr4.o seclr5.o select.o
> service.o setkpt.o setwar.o sphbes.o stern.o SymmRot.o tapewf.o t3j.o
> t3j0.o ustphx.o vectf.o warpin.o wfpnt.o wfpnt1.o ylm.o zhcgst.o zheevx2.o
> zher2m.o jacdavblock.o make_albl.o global2local.o par_syrk.o my_dsygst.o
> refblas_dtrsm.o seclit_par.o pdsyevx17.o pdstebz17.o pdgetri_my.o
> pzgetri_my.o pdgetrf_my.o pzgetrf_my.o W2kutils.o W2kinit.o  -O1 -FR -mp1
> -w -prec_div -pc80 -pad -ip -DINTEL_VML -traceback -assume buffered_io
> -I/opt/intel/composer_xe_2013.1.117/mkl/include
> -I/home/proj/21/isuch/intel/compilers_and_libraries_2018.0.128/linux/mpi/intel64/include
> -L/opt/intel/composer_xe_2013.1.117/mkl/lib/intel64 -lpthread -lm -ldl
> -liomp5 -L/opt/intel/composer_xe_2013.1.117/mkl/lib/intel64
> -lmkl_scalapack_lp64 -L/opt/intel/composer_xe_2013.1.117/mkl/lib/intel64
> -lmkl_blacs_intelmpi_lp64  -lmkl_intel_lp64 -lmkl_intel_thread -lmkl_core
> seclit_par.o: In function `seclit_par_':
> seclit_par_tmp_.F:(.text+0x4755): undefined reference to `pzheevr_'
> seclit_par_tmp_.F:(.text+0x4d80): undefined reference to `pzheevr_'
> make[1]: *** [lapw1c_mpi] Error 1
> make[1]: Leaving directory
> `/home/proj/21/isuch/soft/wien2k_install/18/SRC_lapw1'
> make: *** [cp] Error 2
>
> ==============
>
> Thanks in advance
>
> Venkatesh
> Postdoctoral Fellow,
> Instrumentation and Applied Physics Department
> IISc Bangalore, India
>
> On Thu, Jul 29, 2021 at 9:07 PM Laurence Marks <laurence.marks at gmail.com
> <mailto:laurence.marks at gmail.com>> wrote:
> See
> https://www.google.com/search?q=locale%3A+Cannot+set+LC_CTYPE+to+default+locale%3A+No+such+file+or+directory
>
> 1) If it is a cluster, ask the sys_admin
> 2) Reinstall/update your OS
> 3) Check your .bashrc and similar
> 4) Post to one of those lists. I know enough to know this is a problem,
> but not enough to solve the issue. This is certainly not the right list for
> help on this, it is an OS problem.
>
> On Thu, Jul 29, 2021 at 10:25 AM venky ch <chvenkateshphy at gmail.com
> <mailto:chvenkateshphy at gmail.com>> wrote:
>
> Dear Prof. Marks,
>
> thanks for your reply. I have searched in the internet and tried to solve
> it.  But yet it is not solved . Whenever I tried with " export
> LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/opt/glibc-2.14/build ", there is an error
> as shown in below. Can you suggest me what are steps to be followed to
> solve this issue. I am also requesting wien2k users to help me to solve
> this issue.
>
> thanks
>
> venkatesh
> =============
>
> [isuch at delta-cluster ~]$ export
> LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/opt/glibc-2.14/build
> [isuch at delta-cluster ~]$ locale
> locale: Cannot set LC_CTYPE to default locale: No such file or directory
> locale: Cannot set LC_MESSAGES to default locale: No such file or directory
> locale: Cannot set LC_ALL to default locale: No such file or directory
> LANG=en_US.UTF-8
> LC_CTYPE="en_US.UTF-8"
> LC_NUMERIC="en_US.UTF-8"
> LC_TIME="en_US.UTF-8"
> LC_COLLATE="en_US.UTF-8"
> LC_MONETARY="en_US.UTF-8"
> LC_MESSAGES="en_US.UTF-8"
> LC_PAPER="en_US.UTF-8"
> LC_NAME="en_US.UTF-8"
> LC_ADDRESS="en_US.UTF-8"
> LC_TELEPHONE="en_US.UTF-8"
> LC_MEASUREMENT="en_US.UTF-8"
> LC_IDENTIFICATION="en_US.UTF-8"
> LC_ALL=en_US.UTF-8
> [isuch at delta-cluster ~]$
>
>
>  /etc/environment  is empty
>
>  /usr/bin contains locale
>
>
>
> echo "en_US.UTF-8 UTF-8" > /etc/locale.gen
> echo "fr_FR.UTF-8 UTF-8" >> /etc/locale.gen
> locale-gen
>
> but don't have the locale.gen file at /etc/
>
>
>
>
> echo "LC_ALL=en_US.UTF-8" >> /etc/environment
> echo "en_US.UTF-8 UTF-8" >> /etc/locale.gen
> echo "LANG=en_US.UTF-8" > /etc/locale.conf
> locale-gen en_US.UTF-8
>
>
> but don't have the locale.conf file at /etc/
>
>
> ===========
>
> On Thu, Jul 29, 2021 at 2:14 PM Laurence Marks <laurence.marks at gmail.com
> <mailto:laurence.marks at gmail.com>> wrote:
> You have serious problems with how your computer/cluster is setup. These
> need to be resolved for Wien2k to work, and for many other things as well.
>
> The most obvious one is your locale, which you almost certainly cannot
> cure by just using the -no-multibyte-chars flag.
>
> You can look it up, but briefly, most code is written for the Latin
> alphabet which fits into 256 ASCII code, i.e 1 byte. Computers can use
> other alphabets, but these can require more than one byte. This can work
> for some things, but many others can fail. I very much doubt that Wien2k
> (including the parts for w2web, python and others) will work beyond English
> or similar languages (French, German etc). It probably does not work with
> Russian, Japanese, Chinese or Korean alphabets -- maybe someone can
> confirm. What language is your computer set to?
>
> I strongly suggest that you reset your computer/login to use a Latin
> alphabet, when the LC_ALL issues should go away. In the process you will
> probably update your OS, which will probably solve the memcpy problem,
> which is perhaps due to messed up gcc libraries although it might be other
> compile options.
>
> A partial response.
>
> _____
> Professor Laurence Marks
> "Research is to see what everybody else has seen, and to think what nobody
> else has thought", Albert Szent-Györgyi
> www.numis.northwestern.edu<http://www.numis.northwestern.edu>
>
> On Thu, Jul 29, 2021, 01:11 venkatesh chandragiri <
> venkyphysicsiitm at gmail.com<mailto:venkyphysicsiitm at gmail.com>> wrote:
> Dear Wien2k users,
>
> Recently, I got an opportunity to work with Wien2k after a very long time.
> I have tried to compile the Wien2k_21.1. At first, i tried to compile using
> old ifort compilers and this leads to an error as given below
>
> ====
> SRC_lapw0/compile.msg:lapw0.F(2370): error #6404: This name does not have
> a type, and must have an explicit type.   [FINDLOC]
> =====
> Later, I have searched in the mailing-list and found out that  I need to
> use the latest ifort compilers to compile the Wien2k.
>
> Now, I tried to compile the Wien2k again using recent ifort compilers.
> This leads to another kind of error as given below
>
> ====
> icc -c W2kutils.c
> Catastrophic error: could not set locale "" to allow processing of
> multibyte characters
>
> compilation aborted for W2kutils.c (code 4)
> make[1]: *** [W2kutils.o] Error 4
>
> ========
>
> Again, I did  a search on the website to bypass this error using flag
> setting " -no-multibyte-chars " for both ifort and icc. This time it gives
> only a warning message as given below
> =====
> /bin/sh: warning: setlocale: LC_ALL: cannot change locale (en_US.utf8)
> /bin/sh: warning: setlocale: LC_ALL: cannot change locale (en_US.utf8)
>
> =====
>
> Although, if one can neglect these warning messages, there is an error in
> the compilation process in almost all SRC_* directories as given below and
> I am unable to find the details of it.
>
> ========
> /home/pkg/lic/intel_parallel_studio_composer/2020/compilers_and_libraries_2020.0.166/linux/compiler/lib/intel64_lin/libintlc.so.5:
> undefined reference to `memcpy at GLIBC_2.14'
> make[1]: *** [nmrc_mpi] Error 1
>
> ======
>
> Kindly help me to resolve this error as well as those warning messages.
>
> thanks
> venkatesh
>
> _______________________________________________
> Wien mailing list
> Wien at zeus.theochem.tuwien.ac.at<mailto:Wien at zeus.theochem.tuwien.ac.at>
>
> https://urldefense.com/v3/__http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien__;!!Dq0X2DkFhyF93HkjWTBQKhk!GlvDr8a5j_OzBBtEZDLeeGx19MDcIwP10bYBsogvmUuP3dtsSw3oi-udxb22w-xBfU_01Q$
> SEARCH the MAILING-LIST at:
> https://urldefense.com/v3/__http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html__;!!Dq0X2DkFhyF93HkjWTBQKhk!GlvDr8a5j_OzBBtEZDLeeGx19MDcIwP10bYBsogvmUuP3dtsSw3oi-udxb22w-zoa2Hr1w$
>
>
> --
> Professor Laurence Marks
> Department of Materials Science and Engineering
> Northwestern University
> www.numis.northwestern.edu<http://www.numis.northwestern.edu/>
> "Research is to see what everybody else has seen, and to think what nobody
> else has thought" Albert Szent-Györgyi
> _______________________________________________
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20210804/2786b0c4/attachment.htm>


More information about the Wien mailing list