From jxzhu at lanl.gov Tue Dec 2 06:11:30 2014 From: jxzhu at lanl.gov (Zhu, Jianxin) Date: Tue, 2 Dec 2014 05:11:30 +0000 Subject: [Wannier] Hamiltonian in MLWF basis In-Reply-To: <82B712ED-8B43-42C1-B21C-1029F5164E0B@lanl.gov> Message-ID: Dear Jonathan and Respectful Wannier Users, I have recently been using wien2wannier (thanks to Jan Kunes, Philipp Wissgott, and Elias Assmann) together with wannier90 for several physical systems. Noticeably, for some systems (e.g., tetragonal LaOFeAs etc.), the Hamiltonian matrix elements in the MLWF basis are diagonal in the WF orbitals on the same atomic site. However, for some other systems (e.g., hexagonal YCo5 etc.), the Hamiltonian matrix elements in the MLWF basis are not diagonal in the WF orbitals on the same atomic site. The latter case is surprising to me because the conventional tight-binding approximated Hamiltonian (based on a local atomic orbitals) are always diagonal on the same atomic site. I check back to the paper by Mostofi et al., Computer Physics Communications 178. 685 (2008), and see the Hamiltonian is derived from rotated Bloch states through U^k and U^dis(k) (cf. Eqs. (19-20) in the above mentioned paper). Due to these U^k and U^dis(k), it seems to me that there is no guarantee that the Hamiltonian matrix elements must be diagonal in the basis of MLWF on the same site. Do I understand correctly? Have you encountered this kind of situations in applying MLWF to practical systems? Your suggestions/thoughts are appreciated. Best, Jianxin P.S.: Elias, I cc this message to you in case you also have suggestions. ################################# Jian-Xin Zhu, Ph.D Theoretical Division, MS B262 Los Alamos National Laboratory Los Alamos, New Mexico 87545 Phone: (505) 667 2363 (T-4); (505) 667 6602 (CINT) Fax: (505) 665 4063 Email (main): jxzhu at lanl.gov Email (backup): physjxzhu at gmail.com URL: http://theory.lanl.gov ################################# From nicola.marzari at epfl.ch Tue Dec 2 13:48:15 2014 From: nicola.marzari at epfl.ch (Nicola Marzari) Date: Tue, 02 Dec 2014 13:48:15 +0100 Subject: [Wannier] Hamiltonian in MLWF basis In-Reply-To: References: Message-ID: <547DB50F.4060004@epfl.ch> Dear Jian Xin, have a look at this http://www.chrismarianetti.org/static/publications/prb_90_165125_2014_wang.pdf nicola On 02/12/2014 06:11, Zhu, Jianxin wrote: > Dear Jonathan and Respectful Wannier Users, > > > I have recently been using wien2wannier (thanks to Jan Kunes, Philipp > Wissgott, and Elias Assmann) together with wannier90 for several physical > systems. > > Noticeably, for some systems (e.g., tetragonal LaOFeAs etc.), the > Hamiltonian matrix elements in the MLWF basis are diagonal in the WF > orbitals on the same atomic site. > However, for some other systems (e.g., hexagonal YCo5 etc.), the > Hamiltonian matrix elements in the MLWF basis are not diagonal in the WF > orbitals on the same atomic site. > The latter case is surprising to me because the conventional tight-binding > approximated Hamiltonian (based on a local atomic orbitals) are always > diagonal on the same atomic site. > > I check back to the paper by Mostofi et al., Computer Physics > Communications 178. 685 (2008), and see the Hamiltonian is derived from > rotated Bloch states through U^k and U^dis(k) (cf. Eqs. (19-20) in the > above mentioned paper). > Due to these U^k and U^dis(k), it seems to me that there is no guarantee > that the Hamiltonian matrix elements must be diagonal in the basis of MLWF > on the same site. > Do I understand correctly? > > Have you encountered this kind of situations in applying MLWF to practical > systems? > > Your suggestions/thoughts are appreciated. > > Best, > > Jianxin > > P.S.: Elias, I cc this message to you in case you also have suggestions. > > > > ################################# > Jian-Xin Zhu, Ph.D > Theoretical Division, MS B262 > Los Alamos National Laboratory > Los Alamos, New Mexico 87545 > Phone: (505) 667 2363 (T-4); > (505) 667 6602 (CINT) > Fax: (505) 665 4063 > Email (main): jxzhu at lanl.gov > Email (backup): physjxzhu at gmail.com > URL: http://theory.lanl.gov > ################################# > > > > _______________________________________________ > Wannier mailing list > Wannier at quantum-espresso.org > http://mailman.qe-forge.org/cgi-bin/mailman/listinfo/wannier > -- ---------------------------------------------------------------------- Prof Nicola Marzari, Chair of Theory and Simulation of Materials, EPFL From guzmanar at cab.cnea.gov.ar Thu Dec 4 17:24:00 2014 From: guzmanar at cab.cnea.gov.ar (robert.guzman) Date: Thu, 04 Dec 2014 13:24:00 -0300 Subject: [Wannier] About UNK files In-Reply-To: <547DB50F.4060004@epfl.ch> References: <547DB50F.4060004@epfl.ch> Message-ID: <3998032ce01da34de3666f7d609d4449@cab.cnea.gov.ar> Dear wannier users I have a question, In my compute I have the UNK files generated to plot the wannier functions of my system. I would like to calculate the wannier functions of the same system using other initial conditions of projections. Can I use the same UNK files? Thank for your attention. Mgter. R. M. Guzm?n Arellano Balseiro Institute. From a.mostofi at imperial.ac.uk Fri Dec 5 10:33:45 2014 From: a.mostofi at imperial.ac.uk (Mostofi, Arash) Date: Fri, 5 Dec 2014 09:33:45 +0000 Subject: [Wannier] No space left on device In-Reply-To: <2698a524aaed9ee997b7a95c341145f0@cab.cnea.gov.ar> References: <2698a524aaed9ee997b7a95c341145f0@cab.cnea.gov.ar> Message-ID: <1B44ED06-A9E9-4560-B2DA-A107152B8195@imperial.ac.uk> Dear Robert, If you are using the PWscf interface, there is a keyword ?reduce_unk? that you can set to true in the pw2wannier90 input file. This results in the code outputting the UNK to file at only every other grid point, reducing the disk space required by almost an order of magnitude. Often this is plenty good enough for visualisation purposes, especially if you use a visualisation program that can do good spline interpolation to give you smooth images of the WFs. See Section 5.5.1 of the W90 User Guide. Hope this helps. Best wishes, Arash ? Dr Arash Mostofi ? www.mostofigroup.org Imperial College London Director, Thomas Young Centre @Imperial Assistant Director, CDT in Theory & Simulation of Materials Warden, Wilkinson & Weeks Hall On 27 Nov 2014, at 12:56, robert.guzman > wrote: Dear users and owners of wannier90. To plot the wannier functions is necessary to obtain the UNK archives. Someone of yours know if is possible to reduce the size of the archive UNK? I used 4 pools in pw2wannier90.x The last message in my calculation was: forrtl: No space left on device forrtl: severe (38): error during write, unit 98, file /state/partition1/25931.1.utopia/UNK00037.1 Best Regards. Mgter. R. M. Guzm?n A. Insituto Balseiro. Argentina. _______________________________________________ Wannier mailing list Wannier at quantum-espresso.org http://mailman.qe-forge.org/cgi-bin/mailman/listinfo/wannier -------------- next part -------------- An HTML attachment was scrubbed... URL: From ustc.scgyer at gmail.com Tue Dec 9 20:56:28 2014 From: ustc.scgyer at gmail.com (xiaochuan Ge) Date: Tue, 9 Dec 2014 14:56:28 -0500 Subject: [Wannier] Property of the hopping term in MLWFs Message-ID: Dear all, I wonder how the hopping term decays when it goes to further neighbours: H_ij=< W_i | H | W_j > I suppose that this term should decay exponentially as a function of the distance between the centres of W_i and W_j, but I cannot find a very rigid argument. Would you please give some comments on this or suggestions of reference that discusses about this issue? Thank you very much in advance. =================== Dr. Xiaochuan Ge (Giovanni) Center for Functional Nanomaterials Brookhaven national laboratory =================== -------------- next part -------------- An HTML attachment was scrubbed... URL: From whuliujian at gmail.com Wed Dec 10 15:46:36 2014 From: whuliujian at gmail.com (liujian) Date: Wed, 10 Dec 2014 22:46:36 +0800 Subject: [Wannier] fail to compile pw2wannier90.f90 Message-ID: <54885CCC.2070803@gmail.com> hello,all I am trying to install PWscf and wannier90. First, in the "espresso-5.1.1" directory, ./configure MPIF90=mpiifort make all installed successfully. Then , I copy pw2wannier90.f90 to ./PP/src make pp I got this: mpiifort -O2 -assume byterecl -g -traceback -nomodule -fpp -D__INTEL -D__FFTW -D__MPI -D__PARA -D__SCALAPACK -I../../iotk/src -I../../Modules -I../../PW/src -I. -c pw2wannier90.f90 pw2wannier90.f90(85): error #6580: Name in only-list does not exist. [MPIME] USE mp_global, ONLY : mp_startup, mpime, kunit -------------------------------------^ pw2wannier90.f90(162): error #6285: There is no matching specific subroutine for this generic subroutine call. [MP_BCAST] CALL mp_bcast(ios,ionode_id) -------^ pw2wannier90.f90(167): error #6285: There is no matching specific subroutine for this generic subroutine call. [MP_BCAST] CALL mp_bcast(outdir,ionode_id) -------^ pw2wannier90.f90(168): error #6285: There is no matching specific subroutine for this generic subroutine call. [MP_BCAST] CALL mp_bcast(tmp_dir,ionode_id) -------^ pw2wannier90.f90(169): error #6285: There is no matching specific subroutine for this generic subroutine call. [MP_BCAST] CALL mp_bcast(prefix,ionode_id) -------^ pw2wannier90.f90(170): error #6285: There is no matching specific subroutine for this generic subroutine call. [MP_BCAST] CALL mp_bcast(seedname,ionode_id) -------^ pw2wannier90.f90(171): error #6285: There is no matching specific subroutine for this generic subroutine call. [MP_BCAST] CALL mp_bcast(spin_component,ionode_id) -------^ pw2wannier90.f90(172): error #6285: There is no matching specific subroutine for this generic subroutine call. [MP_BCAST] CALL mp_bcast(wan_mode,ionode_id) -------^ pw2wannier90.f90(173): error #6285: There is no matching specific subroutine for this generic subroutine call. [MP_BCAST] CALL mp_bcast(wvfn_formatted,ionode_id) -------^ pw2wannier90.f90(174): error #6285: There is no matching specific subroutine for this generic subroutine call. [MP_BCAST] CALL mp_bcast(write_unk,ionode_id) -------^ pw2wannier90.f90(175): error #6285: There is no matching specific subroutine for this generic subroutine call. [MP_BCAST] CALL mp_bcast(write_amn,ionode_id) -------^ pw2wannier90.f90(176): error #6285: There is no matching specific subroutine for this generic subroutine call. [MP_BCAST] CALL mp_bcast(write_mmn,ionode_id) -------^ pw2wannier90.f90(178): error #6285: There is no matching specific subroutine for this generic subroutine call. [MP_BCAST] CALL mp_bcast(write_uhu,ionode_id) -------^ pw2wannier90.f90(179): error #6285: There is no matching specific subroutine for this generic subroutine call. [MP_BCAST] CALL mp_bcast(write_uIu,ionode_id) !ivo -------^ pw2wannier90.f90(181): error #6285: There is no matching specific subroutine for this generic subroutine call. [MP_BCAST] CALL mp_bcast(write_spn,ionode_id) -------^ pw2wannier90.f90(182): error #6285: There is no matching specific subroutine for this generic subroutine call. [MP_BCAST] CALL mp_bcast(reduce_unk,ionode_id) -------^ pw2wannier90.f90(183): error #6285: There is no matching specific subroutine for this generic subroutine call. [MP_BCAST] CALL mp_bcast(write_unkg,ionode_id) -------^ pw2wannier90.f90(468): error #6285: There is no matching specific subroutine for this generic subroutine call. [MP_BCAST] CALL mp_bcast(nnb,ionode_id) -------^ pw2wannier90.f90(469): error #6285: There is no matching specific subroutine for this generic subroutine call. [MP_BCAST] CALL mp_bcast(kpb,ionode_id) -------^ pw2wannier90.f90(470): error #6285: There is no matching specific subroutine for this generic subroutine call. [MP_BCAST] CALL mp_bcast(g_kpb,ionode_id) -------^ pw2wannier90.f90(471): error #6285: There is no matching specific subroutine for this generic subroutine call. [MP_BCAST] CALL mp_bcast(num_bands,ionode_id) -------^ pw2wannier90.f90(472): error #6285: There is no matching specific subroutine for this generic subroutine call. [MP_BCAST] CALL mp_bcast(n_wannier,ionode_id) -------^ pw2wannier90.f90(473): error #6285: There is no matching specific subroutine for this generic subroutine call. [MP_BCAST] CALL mp_bcast(center_w,ionode_id) -------^ pw2wannier90.f90(474): error #6285: There is no matching specific subroutine for this generic subroutine call. [MP_BCAST] CALL mp_bcast(l_w,ionode_id) -------^ pw2wannier90.f90(475): error #6285: There is no matching specific subroutine for this generic subroutine call. [MP_BCAST] CALL mp_bcast(mr_w,ionode_id) -------^ pw2wannier90.f90(476): error #6285: There is no matching specific subroutine for this generic subroutine call. [MP_BCAST] CALL mp_bcast(r_w,ionode_id) -------^ pw2wannier90.f90(477): error #6285: There is no matching specific subroutine for this generic subroutine call. [MP_BCAST] CALL mp_bcast(zaxis,ionode_id) -------^ pw2wannier90.f90(478): error #6285: There is no matching specific subroutine for this generic subroutine call. [MP_BCAST] CALL mp_bcast(xaxis,ionode_id) -------^ pw2wannier90.f90(479): error #6285: There is no matching specific subroutine for this generic subroutine call. [MP_BCAST] CALL mp_bcast(alpha_w,ionode_id) -------^ pw2wannier90.f90(480): error #6285: There is no matching specific subroutine for this generic subroutine call. [MP_BCAST] CALL mp_bcast(exclude_bands,ionode_id) -------^ /tmp/ifortmxcbgR.i90(565): catastrophic error: Too many errors, exiting compilation aborted for pw2wannier90.f90 (code 1) make[2]: *** [pw2wannier90.o] Error 1 Here is the make.sys in "espresso-5.1.1" # make.sys. Generated from make.sys.in by configure. # compilation rules .SUFFIXES : .SUFFIXES : .o .c .f .f90 # most fortran compilers can directly preprocess c-like directives: use # $(MPIF90) $(F90FLAGS) -c $< # if explicit preprocessing by the C preprocessor is needed, use: # $(CPP) $(CPPFLAGS) $< -o $*.F90 # $(MPIF90) $(F90FLAGS) -c $*.F90 -o $*.o # remember the tabulator in the first column !!! .f90.o: $(MPIF90) $(F90FLAGS) -c $< # .f.o and .c.o: do not modify .f.o: $(F77) $(FFLAGS) -c $< .c.o: $(CC) $(CFLAGS) -c $< # topdir for linking espresso libs with plugins TOPDIR = /home/liu/tools/PWscf/espresso-5.1.1 # DFLAGS = precompilation options (possible arguments to -D and -U) # used by the C compiler and preprocessor # FDFLAGS = as DFLAGS, for the f90 compiler # See include/defs.h.README for a list of options and their meaning # With the exception of IBM xlf, FDFLAGS = $(DFLAGS) # For IBM xlf, FDFLAGS is the same as DFLAGS with separating commas # MANUAL_DFLAGS = additional precompilation option(s), if desired # You may use this instead of tweaking DFLAGS and FDFLAGS # BEWARE: will not work for IBM xlf! Manually edit FDFLAGS MANUAL_DFLAGS = DFLAGS = -D__INTEL -D__FFTW -D__MPI -D__PARA -D__SCALAPACK $(MANUAL_DFLAGS) FDFLAGS = $(DFLAGS) $(MANUAL_DFLAGS) # IFLAGS = how to locate directories where files to be included are # In most cases, IFLAGS = -I../include IFLAGS = -I../include # MOD_FLAGS = flag used by f90 compiler to locate modules # Each Makefile defines the list of needed modules in MODFLAGS MOD_FLAG = -I # Compilers: fortran-90, fortran-77, C # If a parallel compilation is desired, MPIF90 should be a fortran-90 # compiler that produces executables for parallel execution using MPI # (such as for instance mpif90, mpf90, mpxlf90,...); # otherwise, an ordinary fortran-90 compiler (f90, g95, xlf90, ifort,...) # If you have a parallel machine but no suitable candidate for MPIF90, # try to specify the directory containing "mpif.h" in IFLAGS # and to specify the location of MPI libraries in MPI_LIBS MPIF90 = mpiifort #F90 = ifort CC = icc F77 = ifort # C preprocessor and preprocessing flags - for explicit preprocessing, # if needed (see the compilation rules above) # preprocessing flags must include DFLAGS and IFLAGS CPP = cpp CPPFLAGS = -P -C -traditional $(DFLAGS) $(IFLAGS) # compiler flags: C, F90, F77 # C flags must include DFLAGS and IFLAGS # F90 flags must include MODFLAGS, IFLAGS, and FDFLAGS with appropriate syntax CFLAGS = -O3 $(DFLAGS) $(IFLAGS) F90FLAGS = $(FFLAGS) -nomodule -fpp $(FDFLAGS) $(IFLAGS) $(MODFLAGS) FFLAGS = -O2 -assume byterecl -g -traceback # compiler flags without optimization for fortran-77 # the latter is NEEDED to properly compile dlamch.f, used by lapack FFLAGS_NOOPT = -O0 -assume byterecl -g -traceback # compiler flag needed by some compilers when the main is not fortran # Currently used for Yambo FFLAGS_NOMAIN = -nofor_main # Linker, linker-specific flags (if any) # Typically LD coincides with F90 or MPIF90, LD_LIBS is empty LD = mpiifort LDFLAGS = -static-intel LD_LIBS = # External Libraries (if any) : blas, lapack, fft, MPI # If you have nothing better, use the local copy : # BLAS_LIBS = /your/path/to/espresso/BLAS/blas.a # BLAS_LIBS_SWITCH = internal BLAS_LIBS = -lmkl_intel_lp64 -lmkl_sequential -lmkl_core BLAS_LIBS_SWITCH = external # If you have nothing better, use the local copy : # LAPACK_LIBS = /your/path/to/espresso/lapack-3.2/lapack.a # LAPACK_LIBS_SWITCH = internal # For IBM machines with essl (-D__ESSL): load essl BEFORE lapack ! # remember that LAPACK_LIBS precedes BLAS_LIBS in loading order LAPACK_LIBS = LAPACK_LIBS_SWITCH = external ELPA_LIBS_SWITCH = disabled SCALAPACK_LIBS = -lmkl_scalapack_lp64 -lmkl_blacs_intelmpi_lp64 # nothing needed here if the the internal copy of FFTW is compiled # (needs -D__FFTW in DFLAGS) FFT_LIBS = # For parallel execution, the correct path to MPI libraries must # be specified in MPI_LIBS (except for IBM if you use mpxlf) MPI_LIBS = # IBM-specific: MASS libraries, if available and if -D__MASS is defined in FDFLAGS MASS_LIBS = # ar command and flags - for most architectures: AR = ar, ARFLAGS = ruv AR = ar ARFLAGS = ruv # ranlib command. If ranlib is not needed (it isn't in most cases) use # RANLIB = echo RANLIB = ranlib # all internal and external libraries - do not modify FLIB_TARGETS = all LIBOBJS = ../flib/ptools.a ../flib/flib.a ../clib/clib.a ../iotk/src/libiotk.a LIBS = $(SCALAPACK_LIBS) $(LAPACK_LIBS) $(FFT_LIBS) $(BLAS_LIBS) $(MPI_LIBS) $(MASS_LIBS) $(LD_LIBS) # wget or curl - useful to download from network WGET = wget -O # Install directory PREFIX = $(INSTALLDIR) It would be very kind of you to help me fix it. A beginner : Jian From giovanni.pizzi at epfl.ch Wed Dec 10 20:40:14 2014 From: giovanni.pizzi at epfl.ch (Giovanni Pizzi) Date: Wed, 10 Dec 2014 19:40:14 +0000 Subject: [Wannier] fail to compile pw2wannier90.f90 In-Reply-To: <54885CCC.2070803@gmail.com> References: <54885CCC.2070803@gmail.com> Message-ID: <3688D6F6-56D5-4A98-A149-6E928C03474B@epfl.ch> Dear Jian, for QE 5.1 and following, you must not copy the file pw2wannier90.f90 from the W90 code to QE. Just use the file provided in QE, that is the most recent, up to date version. (In your case: put back the original file from QE, then 'make clean', and then 'make pp'). Best, Giovanni P.S.: Please remember to always provide your affiliation. -- Giovanni Pizzi Post-doctoral Research Scientist EPFL STI IMX THEOS MXC 340 (B?timent MXC) Station 12 CH-1015 Lausanne (Switzerland) Phone: +41 21 69 31124 On 10 Dec 2014, at 15:46, liujian wrote: hello,all I am trying to install PWscf and wannier90. First, in the "espresso-5.1.1" directory, ./configure MPIF90=mpiifort make all installed successfully. Then , I copy pw2wannier90.f90 to ./PP/src make pp I got this: mpiifort -O2 -assume byterecl -g -traceback -nomodule -fpp -D__INTEL -D__FFTW -D__MPI -D__PARA -D__SCALAPACK -I../../iotk/src -I../../Modules -I../../PW/src -I. -c pw2wannier90.f90 pw2wannier90.f90(85): error #6580: Name in only-list does not exist. [MPIME] USE mp_global, ONLY : mp_startup, mpime, kunit -------------------------------------^ pw2wannier90.f90(162): error #6285: There is no matching specific subroutine for this generic subroutine call. [MP_BCAST] CALL mp_bcast(ios,ionode_id) -------^ pw2wannier90.f90(167): error #6285: There is no matching specific subroutine for this generic subroutine call. [MP_BCAST] CALL mp_bcast(outdir,ionode_id) -------^ pw2wannier90.f90(168): error #6285: There is no matching specific subroutine for this generic subroutine call. [MP_BCAST] CALL mp_bcast(tmp_dir,ionode_id) -------^ pw2wannier90.f90(169): error #6285: There is no matching specific subroutine for this generic subroutine call. [MP_BCAST] CALL mp_bcast(prefix,ionode_id) -------^ pw2wannier90.f90(170): error #6285: There is no matching specific subroutine for this generic subroutine call. [MP_BCAST] CALL mp_bcast(seedname,ionode_id) -------^ pw2wannier90.f90(171): error #6285: There is no matching specific subroutine for this generic subroutine call. [MP_BCAST] CALL mp_bcast(spin_component,ionode_id) -------^ pw2wannier90.f90(172): error #6285: There is no matching specific subroutine for this generic subroutine call. [MP_BCAST] CALL mp_bcast(wan_mode,ionode_id) -------^ pw2wannier90.f90(173): error #6285: There is no matching specific subroutine for this generic subroutine call. [MP_BCAST] CALL mp_bcast(wvfn_formatted,ionode_id) -------^ pw2wannier90.f90(174): error #6285: There is no matching specific subroutine for this generic subroutine call. [MP_BCAST] CALL mp_bcast(write_unk,ionode_id) -------^ pw2wannier90.f90(175): error #6285: There is no matching specific subroutine for this generic subroutine call. [MP_BCAST] CALL mp_bcast(write_amn,ionode_id) -------^ pw2wannier90.f90(176): error #6285: There is no matching specific subroutine for this generic subroutine call. [MP_BCAST] CALL mp_bcast(write_mmn,ionode_id) -------^ pw2wannier90.f90(178): error #6285: There is no matching specific subroutine for this generic subroutine call. [MP_BCAST] CALL mp_bcast(write_uhu,ionode_id) -------^ pw2wannier90.f90(179): error #6285: There is no matching specific subroutine for this generic subroutine call. [MP_BCAST] CALL mp_bcast(write_uIu,ionode_id) !ivo -------^ pw2wannier90.f90(181): error #6285: There is no matching specific subroutine for this generic subroutine call. [MP_BCAST] CALL mp_bcast(write_spn,ionode_id) -------^ pw2wannier90.f90(182): error #6285: There is no matching specific subroutine for this generic subroutine call. [MP_BCAST] CALL mp_bcast(reduce_unk,ionode_id) -------^ pw2wannier90.f90(183): error #6285: There is no matching specific subroutine for this generic subroutine call. [MP_BCAST] CALL mp_bcast(write_unkg,ionode_id) -------^ pw2wannier90.f90(468): error #6285: There is no matching specific subroutine for this generic subroutine call. [MP_BCAST] CALL mp_bcast(nnb,ionode_id) -------^ pw2wannier90.f90(469): error #6285: There is no matching specific subroutine for this generic subroutine call. [MP_BCAST] CALL mp_bcast(kpb,ionode_id) -------^ pw2wannier90.f90(470): error #6285: There is no matching specific subroutine for this generic subroutine call. [MP_BCAST] CALL mp_bcast(g_kpb,ionode_id) -------^ pw2wannier90.f90(471): error #6285: There is no matching specific subroutine for this generic subroutine call. [MP_BCAST] CALL mp_bcast(num_bands,ionode_id) -------^ pw2wannier90.f90(472): error #6285: There is no matching specific subroutine for this generic subroutine call. [MP_BCAST] CALL mp_bcast(n_wannier,ionode_id) -------^ pw2wannier90.f90(473): error #6285: There is no matching specific subroutine for this generic subroutine call. [MP_BCAST] CALL mp_bcast(center_w,ionode_id) -------^ pw2wannier90.f90(474): error #6285: There is no matching specific subroutine for this generic subroutine call. [MP_BCAST] CALL mp_bcast(l_w,ionode_id) -------^ pw2wannier90.f90(475): error #6285: There is no matching specific subroutine for this generic subroutine call. [MP_BCAST] CALL mp_bcast(mr_w,ionode_id) -------^ pw2wannier90.f90(476): error #6285: There is no matching specific subroutine for this generic subroutine call. [MP_BCAST] CALL mp_bcast(r_w,ionode_id) -------^ pw2wannier90.f90(477): error #6285: There is no matching specific subroutine for this generic subroutine call. [MP_BCAST] CALL mp_bcast(zaxis,ionode_id) -------^ pw2wannier90.f90(478): error #6285: There is no matching specific subroutine for this generic subroutine call. [MP_BCAST] CALL mp_bcast(xaxis,ionode_id) -------^ pw2wannier90.f90(479): error #6285: There is no matching specific subroutine for this generic subroutine call. [MP_BCAST] CALL mp_bcast(alpha_w,ionode_id) -------^ pw2wannier90.f90(480): error #6285: There is no matching specific subroutine for this generic subroutine call. [MP_BCAST] CALL mp_bcast(exclude_bands,ionode_id) -------^ /tmp/ifortmxcbgR.i90(565): catastrophic error: Too many errors, exiting compilation aborted for pw2wannier90.f90 (code 1) make[2]: *** [pw2wannier90.o] Error 1 Here is the make.sys in "espresso-5.1.1" # make.sys. Generated from make.sys.in by configure. # compilation rules .SUFFIXES : .SUFFIXES : .o .c .f .f90 # most fortran compilers can directly preprocess c-like directives: use # $(MPIF90) $(F90FLAGS) -c $< # if explicit preprocessing by the C preprocessor is needed, use: # $(CPP) $(CPPFLAGS) $< -o $*.F90 # $(MPIF90) $(F90FLAGS) -c $*.F90 -o $*.o # remember the tabulator in the first column !!! .f90.o: $(MPIF90) $(F90FLAGS) -c $< # .f.o and .c.o: do not modify .f.o: $(F77) $(FFLAGS) -c $< .c.o: $(CC) $(CFLAGS) -c $< # topdir for linking espresso libs with plugins TOPDIR = /home/liu/tools/PWscf/espresso-5.1.1 # DFLAGS = precompilation options (possible arguments to -D and -U) # used by the C compiler and preprocessor # FDFLAGS = as DFLAGS, for the f90 compiler # See include/defs.h.README for a list of options and their meaning # With the exception of IBM xlf, FDFLAGS = $(DFLAGS) # For IBM xlf, FDFLAGS is the same as DFLAGS with separating commas # MANUAL_DFLAGS = additional precompilation option(s), if desired # You may use this instead of tweaking DFLAGS and FDFLAGS # BEWARE: will not work for IBM xlf! Manually edit FDFLAGS MANUAL_DFLAGS = DFLAGS = -D__INTEL -D__FFTW -D__MPI -D__PARA -D__SCALAPACK $(MANUAL_DFLAGS) FDFLAGS = $(DFLAGS) $(MANUAL_DFLAGS) # IFLAGS = how to locate directories where files to be included are # In most cases, IFLAGS = -I../include IFLAGS = -I../include # MOD_FLAGS = flag used by f90 compiler to locate modules # Each Makefile defines the list of needed modules in MODFLAGS MOD_FLAG = -I # Compilers: fortran-90, fortran-77, C # If a parallel compilation is desired, MPIF90 should be a fortran-90 # compiler that produces executables for parallel execution using MPI # (such as for instance mpif90, mpf90, mpxlf90,...); # otherwise, an ordinary fortran-90 compiler (f90, g95, xlf90, ifort,...) # If you have a parallel machine but no suitable candidate for MPIF90, # try to specify the directory containing "mpif.h" in IFLAGS # and to specify the location of MPI libraries in MPI_LIBS MPIF90 = mpiifort #F90 = ifort CC = icc F77 = ifort # C preprocessor and preprocessing flags - for explicit preprocessing, # if needed (see the compilation rules above) # preprocessing flags must include DFLAGS and IFLAGS CPP = cpp CPPFLAGS = -P -C -traditional $(DFLAGS) $(IFLAGS) # compiler flags: C, F90, F77 # C flags must include DFLAGS and IFLAGS # F90 flags must include MODFLAGS, IFLAGS, and FDFLAGS with appropriate syntax CFLAGS = -O3 $(DFLAGS) $(IFLAGS) F90FLAGS = $(FFLAGS) -nomodule -fpp $(FDFLAGS) $(IFLAGS) $(MODFLAGS) FFLAGS = -O2 -assume byterecl -g -traceback # compiler flags without optimization for fortran-77 # the latter is NEEDED to properly compile dlamch.f, used by lapack FFLAGS_NOOPT = -O0 -assume byterecl -g -traceback # compiler flag needed by some compilers when the main is not fortran # Currently used for Yambo FFLAGS_NOMAIN = -nofor_main # Linker, linker-specific flags (if any) # Typically LD coincides with F90 or MPIF90, LD_LIBS is empty LD = mpiifort LDFLAGS = -static-intel LD_LIBS = # External Libraries (if any) : blas, lapack, fft, MPI # If you have nothing better, use the local copy : # BLAS_LIBS = /your/path/to/espresso/BLAS/blas.a # BLAS_LIBS_SWITCH = internal BLAS_LIBS = -lmkl_intel_lp64 -lmkl_sequential -lmkl_core BLAS_LIBS_SWITCH = external # If you have nothing better, use the local copy : # LAPACK_LIBS = /your/path/to/espresso/lapack-3.2/lapack.a # LAPACK_LIBS_SWITCH = internal # For IBM machines with essl (-D__ESSL): load essl BEFORE lapack ! # remember that LAPACK_LIBS precedes BLAS_LIBS in loading order LAPACK_LIBS = LAPACK_LIBS_SWITCH = external ELPA_LIBS_SWITCH = disabled SCALAPACK_LIBS = -lmkl_scalapack_lp64 -lmkl_blacs_intelmpi_lp64 # nothing needed here if the the internal copy of FFTW is compiled # (needs -D__FFTW in DFLAGS) FFT_LIBS = # For parallel execution, the correct path to MPI libraries must # be specified in MPI_LIBS (except for IBM if you use mpxlf) MPI_LIBS = # IBM-specific: MASS libraries, if available and if -D__MASS is defined in FDFLAGS MASS_LIBS = # ar command and flags - for most architectures: AR = ar, ARFLAGS = ruv AR = ar ARFLAGS = ruv # ranlib command. If ranlib is not needed (it isn't in most cases) use # RANLIB = echo RANLIB = ranlib # all internal and external libraries - do not modify FLIB_TARGETS = all LIBOBJS = ../flib/ptools.a ../flib/flib.a ../clib/clib.a ../iotk/src/libiotk.a LIBS = $(SCALAPACK_LIBS) $(LAPACK_LIBS) $(FFT_LIBS) $(BLAS_LIBS) $(MPI_LIBS) $(MASS_LIBS) $(LD_LIBS) # wget or curl - useful to download from network WGET = wget -O # Install directory PREFIX = $(INSTALLDIR) It would be very kind of you to help me fix it. A beginner : Jian _______________________________________________ Wannier mailing list Wannier at quantum-espresso.org http://mailman.qe-forge.org/cgi-bin/mailman/listinfo/wannier -------------- next part -------------- An HTML attachment was scrubbed... URL: From sharmajncasr at gmail.com Fri Dec 12 10:51:33 2014 From: sharmajncasr at gmail.com (SRKC Sharma Yamijala) Date: Fri, 12 Dec 2014 15:21:33 +0530 Subject: [Wannier] Restarting the calculation with increased dis_num_iter Message-ID: Dear Wannier member, I would like to restart the calculation with increased disentaglement interations. Could you tell me which restart flag I need to consider? I tried with restart=default, but it didn't work. Thanking you, Sincerely, Sharma. ******************************************************** *Chaitanya Sharma,* *Prof. Pati'*s group, Chemistry and Physics Materials unit, JNCASR, BANGLORE, Lab:: (080-2208) 2581, 2809 https://sites.google.com/site/sharmasrkcyamijala/ ********************************************************* -------------- next part -------------- An HTML attachment was scrubbed... URL: From raullaasner at gmail.com Fri Dec 12 11:09:12 2014 From: raullaasner at gmail.com (Raul Laasner) Date: Fri, 12 Dec 2014 12:09:12 +0200 Subject: [Wannier] DOS calculation with full and IBZ giving different results Message-ID: Dear all, When I calculate the density of the lowest conduction states of NaI (see attachment), I get different results for using k-points from the full and irreducible Brillouin zones. The difference is smaller when the k-mesh is allowed to use less symmetries, e.g. only the time reversal symmetry. There is no difference if the 'kpoint.dat' file contains the full BZ. This suggests the code I use for generating IBZ points might be in error, but I get the same results with both abinit and elk (they deliver different, but equivalent IBZ points). Could it be that the DOS calculation is very sensitive to small numerical inaccuracies and this leads to slightly different results for full and irreducible BZs? The DOS related part of my input file is the following: dos true dos_kmesh 20 dos_adpt_smr true wanint_kpoint_file false # true for the second run The difference is also present with dos_kmesh 50. Please ask for other details I'm not showing. Any suggestions are welcome. Thanks, Raul Laasner -- Raul Laasner Institute of Physics University of Tartu Ravila 14c, 50411, Estonia e-mail: raullaasner at gmail.com cell: (+372)5182268 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: plot.png Type: image/png Size: 5725 bytes Desc: not available URL: From whuliujian at gmail.com Fri Dec 12 16:00:28 2014 From: whuliujian at gmail.com (liujian) Date: Fri, 12 Dec 2014 23:00:28 +0800 Subject: [Wannier] where is libwannier.a Message-ID: <548B030C.4060804@gmail.com> Dear all, According to this direction: http://cms.mpi.univie.ac.at/wiki/index.php/LWANNIER90 LIB = -L../vasp.5.lib -ldmy \ ../vasp.5.lib/linpack_double.o ../wannier90-1.2/libwannier.a $(SCA) $(LAPACK) $(BLAS) There should be a libwannier.a where the wannier90-1.2 installed. But I can't find it. I used ifort and mkl library. There does have a warning: ifort wannier_prog.F90 -O2 -Vaxlib constants.o io.o utility.o parameters.o hamiltonian.o overlap.o kmesh.o disentangle.o wannierise.o plot.o transport.o -L/home/liu/intel/mkl/lib/intel64 -lmkl_core -lmkl_intel_lp64 -lmkl_sequential -lpthread -o ../wannier90.x ifort: command line remark #10148: option '-Vaxlib' not supported Thanks, Jian Liu -- Jain Liu College of Materials Science and Engineering Hunan University Changsha, 434100, China e-mail: whuliujian at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From whuliujian at gmail.com Fri Dec 12 16:09:13 2014 From: whuliujian at gmail.com (liujian) Date: Fri, 12 Dec 2014 23:09:13 +0800 Subject: [Wannier] where is libwannier.a In-Reply-To: <548B030C.4060804@gmail.com> References: <548B030C.4060804@gmail.com> Message-ID: <548B0519.1030202@gmail.com> Problem solved Sorry -- Jain Liu College of Materials Science and Engineering Hunan University Changsha, 434100, China e-mail: whuliujian at gmail.com On 12/12/2014 11:00 PM, liujian wrote: > Dear all, > > According to this direction: > http://cms.mpi.univie.ac.at/wiki/index.php/LWANNIER90 > > LIB = -L../vasp.5.lib -ldmy \ > ../vasp.5.lib/linpack_double.o ../wannier90-1.2/libwannier.a $(SCA) $(LAPACK) $(BLAS) > > There should be a libwannier.a where the wannier90-1.2 installed. > > But I can't find it. > > I used ifort and mkl library. > There does have a warning: > > > ifort wannier_prog.F90 -O2 -Vaxlib constants.o io.o utility.o > parameters.o hamiltonian.o overlap.o kmesh.o disentangle.o > wannierise.o plot.o transport.o -L/home/liu/intel/mkl/lib/intel64 > -lmkl_core -lmkl_intel_lp64 -lmkl_sequential -lpthread -o ../wannier90.x > ifort: command line remark #10148: option '-Vaxlib' not supported > > > Thanks, > Jian Liu > > > -- > Jain Liu > College of Materials Science and Engineering > Hunan University > Changsha, 434100, China > e-mail: whuliujian at gmail.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From giovanni.pizzi at epfl.ch Fri Dec 12 16:38:28 2014 From: giovanni.pizzi at epfl.ch (Giovanni Pizzi) Date: Fri, 12 Dec 2014 16:38:28 +0100 Subject: [Wannier] DOS calculation with full and IBZ giving different results In-Reply-To: References: Message-ID: <548B0BF4.5020107@epfl.ch> Dear Raul, in order to understand if the problem is in the dos routine, or in the routine that generated the IBZ points, could you run the same thing (i.e. DOS, with and without wanint_kpoint_file), but using dos_adpt_smr=False, and instead a fixed-width smearing? (e.g. a gaussian smearing) And then compare the results, and report them here? As a further detail, could you also check if the units for the kpoints that you are passing in the wanint file are the one expected by the code? Thanks, Giovanni On 12/12/2014 11:09 AM, Raul Laasner wrote: > Dear all, > > When I calculate the density of the lowest conduction states of NaI > (see attachment), I get different results for using k-points from the > full and irreducible Brillouin zones. The difference is smaller when > the k-mesh is allowed to use less symmetries, e.g. only the time > reversal symmetry. There is no difference if the 'kpoint.dat' file > contains the full BZ. This suggests the code I use for generating IBZ > points might be in error, but I get the same results with both abinit > and elk (they deliver different, but equivalent IBZ points). Could it > be that the DOS calculation is very sensitive to small numerical > inaccuracies and this leads to slightly different results for full and > irreducible BZs? The DOS related part of my input file is the following: > > dos true > dos_kmesh 20 > dos_adpt_smr true > wanint_kpoint_file false # true for the second run > > The difference is also present with dos_kmesh 50. Please ask for other > details I'm not showing. Any suggestions are welcome. > > Thanks, > Raul Laasner > > > -- > Raul Laasner > Institute of Physics > University of Tartu > Ravila 14c, 50411, Estonia > e-mail: raullaasner at gmail.com > cell: (+372)5182268 > > > _______________________________________________ > Wannier mailing list > Wannier at quantum-espresso.org > http://mailman.qe-forge.org/cgi-bin/mailman/listinfo/wannier -- Giovanni Pizzi Post-doctoral Research Scientist EPFL STI IMX THEOS MXC 340 (B?timent MXC) Station 12 CH-1015 Lausanne (Switzerland) Phone: +41 21 69 31124 -------------- next part -------------- An HTML attachment was scrubbed... URL: From giovanni.pizzi at epfl.ch Fri Dec 12 16:43:55 2014 From: giovanni.pizzi at epfl.ch (Giovanni Pizzi) Date: Fri, 12 Dec 2014 16:43:55 +0100 Subject: [Wannier] Restarting the calculation with increased dis_num_iter In-Reply-To: References: Message-ID: <548B0D3B.4040809@epfl.ch> Dear Sharma, if I remember correctly (if I am wrong, please correct me): if, say, you run 100 disentanglement iterations, there is currently no option to restart from iteration 101 for the disentanglement; this option only exists for wannierisation. Anyway, since disentaglement is the first operation executed by the code, and it is (typically) fast, you can just change the maximum number of disentanglement steps, and restart the calculation from scratch. Best, Giovanni On 12/12/2014 10:51 AM, SRKC Sharma Yamijala wrote: > Dear Wannier member, > > I would like to restart the calculation with increased disentaglement > interations. Could you tell me which restart flag I need to consider? > I tried with restart=default, but it didn't work. > > Thanking you, > Sincerely, > Sharma. > > > > > > > > ******************************************************** > *Chaitanya Sharma,* > *Prof. Pati'*s group, > Chemistry and Physics Materials unit, > JNCASR, BANGLORE, > Lab:: (080-2208) 2581, 2809 > https://sites.google.com/site/sharmasrkcyamijala/ > ********************************************************* > > > _______________________________________________ > Wannier mailing list > Wannier at quantum-espresso.org > http://mailman.qe-forge.org/cgi-bin/mailman/listinfo/wannier -- Giovanni Pizzi Post-doctoral Research Scientist EPFL STI IMX THEOS MXC 340 (B?timent MXC) Station 12 CH-1015 Lausanne (Switzerland) Phone: +41 21 69 31124 -------------- next part -------------- An HTML attachment was scrubbed... URL: From zaldolam at email.uark.edu Fri Dec 12 20:22:18 2014 From: zaldolam at email.uark.edu (Zeina Al-Dolami) Date: Fri, 12 Dec 2014 13:22:18 -0600 Subject: [Wannier] Error in routine card_kpoints (1) Message-ID: To wannier's owners and developers, Thanks to everyone for helping us. I have a problem when running nscf calculations. I have generated the k ponits for my system using wannier utility kmesh.pl. I copied and pasted them to my nscf input file. However, it crashed and I got the below error message: Error in routine card_kpoints (1) In order to fix it, I have modified the way that these kpoints were written by including one digit after the zero. Despite the fact that I have tried different ways of writing these kpoints by including two or not any, I have gotten the same error. Would you please help me with it? I might have misunderstood the error message. Please let me know what you think. Looking forward to hearing from you and many thanks in advance I appreciate your time Zeina -------------- next part -------------- An HTML attachment was scrubbed... URL: From zaldolam at email.uark.edu Fri Dec 12 23:28:17 2014 From: zaldolam at email.uark.edu (Zeina Al-Dolami) Date: Fri, 12 Dec 2014 16:28:17 -0600 Subject: [Wannier] Error in routine card_kpoints (1) In-Reply-To: References: Message-ID: I think I know what the problem was. Many thanks !! On Fri, Dec 12, 2014 at 1:22 PM, Zeina Al-Dolami wrote: > > To wannier's owners and developers, > Thanks to everyone for helping us. I have a problem when running nscf > calculations. I have generated the k ponits for my system using wannier > utility kmesh.pl. I copied and pasted them to my nscf input file. > However, it crashed and I got the below error message: > Error in routine card_kpoints (1) > In order to fix it, I have modified the way that these kpoints were > written by including one digit after the zero. Despite the fact that I have > tried different ways of writing these kpoints by including two or not any, > I have gotten the same error. Would you please help me with it? I might > have misunderstood the error message. Please let me know what you think. > Looking forward to hearing from you and many thanks in advance > > I appreciate your time > Zeina > -------------- next part -------------- An HTML attachment was scrubbed... URL: From raullaasner at gmail.com Sat Dec 13 00:25:16 2014 From: raullaasner at gmail.com (Raul Laasner) Date: Sat, 13 Dec 2014 01:25:16 +0200 Subject: [Wannier] DOS calculation with full and IBZ giving different results In-Reply-To: <548B0BF4.5020107@epfl.ch> References: <548B0BF4.5020107@epfl.ch> Message-ID: Thanks for responding. Yes, also without adaptive smearing the results differ a little bit. However, the difference decreases with k-mesh size. With dos_kmesh 10 the difference is very small and with lower values the results are identical. For debugging purposes, I tried dos_kmesh 2 with adaptive smearing. If I put 8 0.00000000E+00 0.00000000E+00 0.00000000E+00 0.12500 5.00000000E-01 0.00000000E+00 0.00000000E+00 0.12500 0.00000000E+00 5.00000000E-01 0.00000000E+00 0.12500 5.00000000E-01 5.00000000E-01 0.00000000E+00 0.12500 0.00000000E+00 0.00000000E+00 5.00000000E-01 0.12500 5.00000000E-01 0.00000000E+00 5.00000000E-01 0.12500 0.00000000E+00 5.00000000E-01 5.00000000E-01 0.12500 5.00000000E-01 5.00000000E-01 5.00000000E-01 0.12500 into my kpoint.dat, then I get the correct result. However, with 3 0.00000000E+00 0.00000000E+00 0.00000000E+00 0.12500 5.00000000E-01 0.00000000E+00 0.00000000E+00 0.50000 5.00000000E-01 5.00000000E-01 0.00000000E+00 0.37500 the results again differ. (I forgot to say that NaI has the rock-salt structure.) I had a look at the loop that performs the main calculation in dos_main and inserted write(*,'(*(f7.5,1x))') kpt, dos_k(452,1)*kweight after the 'dos_all=dos_all+dos_k*kweight' line to see how each k-point contributes to the sum. Here the index 452 refers to some energy level that I randomly picked. The result is 0.00000 0.00000 0.00000 0.22149 0.00000 0.00000 0.50000 4.22194 0.00000 0.50000 0.00000 3.32614 0.00000 0.50000 0.50000 0.00000 0.50000 0.00000 0.00000 1.11124 0.50000 0.00000 0.50000 0.00000 0.50000 0.50000 0.00000 0.00000 0.50000 0.50000 0.50000 0.45465 where the last column is the corresponding density. By symmetry, I would expect only 3 numbers to differ in this column, but this is not the case. Have I misunderstood something? As another check, before the main loop, I put kpt = [0.5,0.0,0.0] call get_eig_deleig(kpt, eig, del_eig, HH, delHH, UU) print*, norm2(del_eig(1,:)) kpt = [0.0,0.5,0.0] call get_eig_deleig(kpt, eig, del_eig, HH, delHH, UU) print*, norm2(del_eig(1,:)) which prints the magnitude of the band derivative of the first band at these two k-points, with the result 0.44616527636129560 3.1348138571982227E-003 Shouldn't these numbers be the same by symmetry? Finally, I'm not sure what you mean by 'units for the kpoints' as I'm only entering the reduced coordinates. Raul On Fri, Dec 12, 2014 at 5:38 PM, Giovanni Pizzi wrote: > > Dear Raul, > in order to understand if the problem is in the dos routine, or in the > routine that generated the IBZ points, could you run the same thing (i.e. > DOS, with and without wanint_kpoint_file), but using dos_adpt_smr=False, > and instead a fixed-width smearing? (e.g. a gaussian smearing) > And then compare the results, and report them here? > > As a further detail, could you also check if the units for the kpoints > that you are passing in the wanint file are the one expected by the code? > > Thanks, > Giovanni > > > > On 12/12/2014 11:09 AM, Raul Laasner wrote: > > Dear all, > > When I calculate the density of the lowest conduction states of NaI (see > attachment), I get different results for using k-points from the full and > irreducible Brillouin zones. The difference is smaller when the k-mesh is > allowed to use less symmetries, e.g. only the time reversal symmetry. There > is no difference if the 'kpoint.dat' file contains the full BZ. This > suggests the code I use for generating IBZ points might be in error, but I > get the same results with both abinit and elk (they deliver different, but > equivalent IBZ points). Could it be that the DOS calculation is very > sensitive to small numerical inaccuracies and this leads to slightly > different results for full and irreducible BZs? The DOS related part of my > input file is the following: > > dos true > dos_kmesh 20 > dos_adpt_smr true > wanint_kpoint_file false # true for the second run > > The difference is also present with dos_kmesh 50. Please ask for other > details I'm not showing. Any suggestions are welcome. > > Thanks, > Raul Laasner > > > -- > Raul Laasner > Institute of Physics > University of Tartu > Ravila 14c, 50411, Estonia > e-mail: raullaasner at gmail.com > cell: (+372)5182268 > > > _______________________________________________ > Wannier mailing listWannier at quantum-espresso.orghttp://mailman.qe-forge.org/cgi-bin/mailman/listinfo/wannier > > > > -- > Giovanni Pizzi > Post-doctoral Research Scientist > EPFL STI IMX THEOS > MXC 340 (B?timent MXC) > Station 12 > CH-1015 Lausanne (Switzerland) > Phone: +41 21 69 31124 > > > _______________________________________________ > Wannier mailing list > Wannier at quantum-espresso.org > http://mailman.qe-forge.org/cgi-bin/mailman/listinfo/wannier > > -- Raul Laasner Institute of Physics University of Tartu Ravila 14c, 50411, Estonia e-mail: raullaasner at gmail.com cell: (+372)5182268 -------------- next part -------------- An HTML attachment was scrubbed... URL: From giovanni.pizzi at epfl.ch Sat Dec 13 09:40:21 2014 From: giovanni.pizzi at epfl.ch (Giovanni Pizzi) Date: Sat, 13 Dec 2014 08:40:21 +0000 Subject: [Wannier] DOS calculation with full and IBZ giving different results In-Reply-To: References: <548B0BF4.5020107@epfl.ch> Message-ID: <282F0F46-74C3-48AE-A3C0-E9C971D70323@epfl.ch> Hi Raul, thank you for your detailed answer. It seems to me that even the energies may not be the same in the points that you expect to be equivalent. A couple of further questions then, sorry if they may seem trivial? 1. Did you check that the structure has exactly the exact symmetry that you expect? 1bis. Can you check with the ab-initio code to check the eigenenergies at the points that should be degenerate to see if the energies are the same? 2. Did you check that the Wannier functions are well converged? 2bis. Can you check that the interpolated bandstructure with Wannier functions satisfy the symmetry that you expect, e.g. doing a band plot along two equivalent bands? Thanks, Giovanni -- Giovanni Pizzi Post-doctoral Research Scientist EPFL STI IMX THEOS MXC 340 (B?timent MXC) Station 12 CH-1015 Lausanne (Switzerland) Phone: +41 21 69 31124 On 13 Dec 2014, at 00:25, Raul Laasner wrote: Thanks for responding. Yes, also without adaptive smearing the results differ a little bit. However, the difference decreases with k-mesh size. With dos_kmesh 10 the difference is very small and with lower values the results are identical. For debugging purposes, I tried dos_kmesh 2 with adaptive smearing. If I put 8 0.00000000E+00 0.00000000E+00 0.00000000E+00 0.12500 5.00000000E-01 0.00000000E+00 0.00000000E+00 0.12500 0.00000000E+00 5.00000000E-01 0.00000000E+00 0.12500 5.00000000E-01 5.00000000E-01 0.00000000E+00 0.12500 0.00000000E+00 0.00000000E+00 5.00000000E-01 0.12500 5.00000000E-01 0.00000000E+00 5.00000000E-01 0.12500 0.00000000E+00 5.00000000E-01 5.00000000E-01 0.12500 5.00000000E-01 5.00000000E-01 5.00000000E-01 0.12500 into my kpoint.dat, then I get the correct result. However, with 3 0.00000000E+00 0.00000000E+00 0.00000000E+00 0.12500 5.00000000E-01 0.00000000E+00 0.00000000E+00 0.50000 5.00000000E-01 5.00000000E-01 0.00000000E+00 0.37500 the results again differ. (I forgot to say that NaI has the rock-salt structure.) I had a look at the loop that performs the main calculation in dos_main and inserted write(*,'(*(f7.5,1x))') kpt, dos_k(452,1)*kweight after the 'dos_all=dos_all+dos_k*kweight' line to see how each k-point contributes to the sum. Here the index 452 refers to some energy level that I randomly picked. The result is 0.00000 0.00000 0.00000 0.22149 0.00000 0.00000 0.50000 4.22194 0.00000 0.50000 0.00000 3.32614 0.00000 0.50000 0.50000 0.00000 0.50000 0.00000 0.00000 1.11124 0.50000 0.00000 0.50000 0.00000 0.50000 0.50000 0.00000 0.00000 0.50000 0.50000 0.50000 0.45465 where the last column is the corresponding density. By symmetry, I would expect only 3 numbers to differ in this column, but this is not the case. Have I misunderstood something? As another check, before the main loop, I put kpt = [0.5,0.0,0.0] call get_eig_deleig(kpt, eig, del_eig, HH, delHH, UU) print*, norm2(del_eig(1,:)) kpt = [0.0,0.5,0.0] call get_eig_deleig(kpt, eig, del_eig, HH, delHH, UU) print*, norm2(del_eig(1,:)) which prints the magnitude of the band derivative of the first band at these two k-points, with the result 0.44616527636129560 3.1348138571982227E-003 Shouldn't these numbers be the same by symmetry? Finally, I'm not sure what you mean by 'units for the kpoints' as I'm only entering the reduced coordinates. Raul On Fri, Dec 12, 2014 at 5:38 PM, Giovanni Pizzi > wrote: Dear Raul, in order to understand if the problem is in the dos routine, or in the routine that generated the IBZ points, could you run the same thing (i.e. DOS, with and without wanint_kpoint_file), but using dos_adpt_smr=False, and instead a fixed-width smearing? (e.g. a gaussian smearing) And then compare the results, and report them here? As a further detail, could you also check if the units for the kpoints that you are passing in the wanint file are the one expected by the code? Thanks, Giovanni On 12/12/2014 11:09 AM, Raul Laasner wrote: Dear all, When I calculate the density of the lowest conduction states of NaI (see attachment), I get different results for using k-points from the full and irreducible Brillouin zones. The difference is smaller when the k-mesh is allowed to use less symmetries, e.g. only the time reversal symmetry. There is no difference if the 'kpoint.dat' file contains the full BZ. This suggests the code I use for generating IBZ points might be in error, but I get the same results with both abinit and elk (they deliver different, but equivalent IBZ points). Could it be that the DOS calculation is very sensitive to small numerical inaccuracies and this leads to slightly different results for full and irreducible BZs? The DOS related part of my input file is the following: dos true dos_kmesh 20 dos_adpt_smr true wanint_kpoint_file false # true for the second run The difference is also present with dos_kmesh 50. Please ask for other details I'm not showing. Any suggestions are welcome. Thanks, Raul Laasner -- Raul Laasner Institute of Physics University of Tartu Ravila 14c, 50411, Estonia e-mail: raullaasner at gmail.com cell: (+372)5182268 _______________________________________________ Wannier mailing list Wannier at quantum-espresso.org http://mailman.qe-forge.org/cgi-bin/mailman/listinfo/wannier -- Giovanni Pizzi Post-doctoral Research Scientist EPFL STI IMX THEOS MXC 340 (B?timent MXC) Station 12 CH-1015 Lausanne (Switzerland) Phone: +41 21 69 31124 _______________________________________________ Wannier mailing list Wannier at quantum-espresso.org http://mailman.qe-forge.org/cgi-bin/mailman/listinfo/wannier -- Raul Laasner Institute of Physics University of Tartu Ravila 14c, 50411, Estonia e-mail: raullaasner at gmail.com cell: (+372)5182268 -------------- next part -------------- An HTML attachment was scrubbed... URL: From raullaasner at gmail.com Sat Dec 13 13:36:07 2014 From: raullaasner at gmail.com (Raul Laasner) Date: Sat, 13 Dec 2014 14:36:07 +0200 Subject: [Wannier] DOS calculation with full and IBZ giving different results In-Reply-To: <282F0F46-74C3-48AE-A3C0-E9C971D70323@epfl.ch> References: <548B0BF4.5020107@epfl.ch> <282F0F46-74C3-48AE-A3C0-E9C971D70323@epfl.ch> Message-ID: Hi Your suspicion was well-founded. The ab-initio eigenvalues are correct, but the Wannier functions are actually not entirely converged. In fact, the difference in results seems to be greater in regions of poorer convergence. I somehow assumed the Wannier interpolated quantities always have the correct symmetries, even if WFs themselves are not fully converged. I should carefully reread the original papers ... Thanks for the help. Raul On Sat, Dec 13, 2014 at 10:40 AM, Giovanni Pizzi wrote: > > Hi Raul, > thank you for your detailed answer. > It seems to me that even the energies may not be the same in the points > that you expect to be equivalent. A couple of further questions then, sorry > if they may seem trivial? > > 1. Did you check that the structure has exactly the exact symmetry that > you expect? > 1bis. Can you check with the ab-initio code to check the eigenenergies at > the points that should be degenerate to see if the energies are the same? > 2. Did you check that the Wannier functions are well converged? > 2bis. Can you check that the interpolated bandstructure with Wannier > functions satisfy the symmetry that you expect, e.g. doing a band plot > along two equivalent bands? > > Thanks, > Giovanni > > > -- > Giovanni Pizzi > Post-doctoral Research Scientist > EPFL STI IMX THEOS > MXC 340 (B?timent MXC) > Station 12 > CH-1015 Lausanne (Switzerland) > Phone: +41 21 69 31124 > > > > > On 13 Dec 2014, at 00:25, Raul Laasner wrote: > > Thanks for responding. Yes, also without adaptive smearing the results > differ a little bit. However, the difference decreases with k-mesh size. > With dos_kmesh 10 the difference is very small and with lower values the > results are identical. > > For debugging purposes, I tried dos_kmesh 2 with adaptive smearing. If I > put > > 8 > 0.00000000E+00 0.00000000E+00 0.00000000E+00 0.12500 > 5.00000000E-01 0.00000000E+00 0.00000000E+00 0.12500 > 0.00000000E+00 5.00000000E-01 0.00000000E+00 0.12500 > 5.00000000E-01 5.00000000E-01 0.00000000E+00 0.12500 > 0.00000000E+00 0.00000000E+00 5.00000000E-01 0.12500 > 5.00000000E-01 0.00000000E+00 5.00000000E-01 0.12500 > 0.00000000E+00 5.00000000E-01 5.00000000E-01 0.12500 > 5.00000000E-01 5.00000000E-01 5.00000000E-01 0.12500 > > into my kpoint.dat, then I get the correct result. However, with > > 3 > 0.00000000E+00 0.00000000E+00 0.00000000E+00 0.12500 > 5.00000000E-01 0.00000000E+00 0.00000000E+00 0.50000 > 5.00000000E-01 5.00000000E-01 0.00000000E+00 0.37500 > > the results again differ. (I forgot to say that NaI has the rock-salt > structure.) > > I had a look at the loop that performs the main calculation in dos_main > and inserted > > write(*,'(*(f7.5,1x))') kpt, dos_k(452,1)*kweight > > after the 'dos_all=dos_all+dos_k*kweight' line to see how each k-point > contributes to the sum. Here the index 452 refers to some energy level that > I randomly picked. The result is > > 0.00000 0.00000 0.00000 0.22149 > 0.00000 0.00000 0.50000 4.22194 > 0.00000 0.50000 0.00000 3.32614 > 0.00000 0.50000 0.50000 0.00000 > 0.50000 0.00000 0.00000 1.11124 > 0.50000 0.00000 0.50000 0.00000 > 0.50000 0.50000 0.00000 0.00000 > 0.50000 0.50000 0.50000 0.45465 > > where the last column is the corresponding density. By symmetry, I would > expect only 3 numbers to differ in this column, but this is not the case. > Have I misunderstood something? > > As another check, before the main loop, I put > > kpt = [0.5,0.0,0.0] > call get_eig_deleig(kpt, eig, del_eig, HH, delHH, UU) > print*, norm2(del_eig(1,:)) > kpt = [0.0,0.5,0.0] > call get_eig_deleig(kpt, eig, del_eig, HH, delHH, UU) > print*, norm2(del_eig(1,:)) > > which prints the magnitude of the band derivative of the first band at > these two k-points, with the result > > 0.44616527636129560 > 3.1348138571982227E-003 > > Shouldn't these numbers be the same by symmetry? > > Finally, I'm not sure what you mean by 'units for the kpoints' as I'm > only entering the reduced coordinates. > > Raul > > On Fri, Dec 12, 2014 at 5:38 PM, Giovanni Pizzi > wrote: >> >> Dear Raul, >> in order to understand if the problem is in the dos routine, or in the >> routine that generated the IBZ points, could you run the same thing (i.e. >> DOS, with and without wanint_kpoint_file), but using dos_adpt_smr=False, >> and instead a fixed-width smearing? (e.g. a gaussian smearing) >> And then compare the results, and report them here? >> >> As a further detail, could you also check if the units for the kpoints >> that you are passing in the wanint file are the one expected by the code? >> >> Thanks, >> Giovanni >> >> >> >> On 12/12/2014 11:09 AM, Raul Laasner wrote: >> >> Dear all, >> >> When I calculate the density of the lowest conduction states of NaI >> (see attachment), I get different results for using k-points from the full >> and irreducible Brillouin zones. The difference is smaller when the k-mesh >> is allowed to use less symmetries, e.g. only the time reversal symmetry. >> There is no difference if the 'kpoint.dat' file contains the full BZ. This >> suggests the code I use for generating IBZ points might be in error, but I >> get the same results with both abinit and elk (they deliver different, but >> equivalent IBZ points). Could it be that the DOS calculation is very >> sensitive to small numerical inaccuracies and this leads to slightly >> different results for full and irreducible BZs? The DOS related part of my >> input file is the following: >> >> dos true >> dos_kmesh 20 >> dos_adpt_smr true >> wanint_kpoint_file false # true for the second run >> >> The difference is also present with dos_kmesh 50. Please ask for other >> details I'm not showing. Any suggestions are welcome. >> >> Thanks, >> Raul Laasner >> >> >> -- >> Raul Laasner >> Institute of Physics >> University of Tartu >> Ravila 14c, 50411, Estonia >> e-mail: raullaasner at gmail.com >> cell: (+372)5182268 >> >> >> _______________________________________________ >> Wannier mailing listWannier at quantum-espresso.orghttp://mailman.qe-forge.org/cgi-bin/mailman/listinfo/wannier >> >> >> >> -- >> Giovanni Pizzi >> Post-doctoral Research Scientist >> EPFL STI IMX THEOS >> MXC 340 (B?timent MXC) >> Station 12 >> CH-1015 Lausanne (Switzerland) >> Phone: +41 21 69 31124 >> >> >> _______________________________________________ >> Wannier mailing list >> Wannier at quantum-espresso.org >> http://mailman.qe-forge.org/cgi-bin/mailman/listinfo/wannier >> >> > > -- > Raul Laasner > Institute of Physics > University of Tartu > Ravila 14c, 50411, Estonia > e-mail: raullaasner at gmail.com > cell: (+372)5182268 > > > -- Raul Laasner Institute of Physics University of Tartu Ravila 14c, 50411, Estonia e-mail: raullaasner at gmail.com cell: (+372)5182268 -------------- next part -------------- An HTML attachment was scrubbed... URL: From zaldolam at email.uark.edu Sun Dec 14 06:20:49 2014 From: zaldolam at email.uark.edu (Zeina Al-Dolami) Date: Sat, 13 Dec 2014 23:20:49 -0600 Subject: [Wannier] how to find projections in seedname.win? Message-ID: To wannier's owners and developers, Thanks to everyone for helping us. I have a question related to the projections in the input seedname.win. I am aware that there are different types of projections. I am confused about how to find these projections. Is it by using projwfc.x in PP? If so, is there an example of the input file or standard input file that you can inform me of? The user's manual for PP does not have much details and I am confused about it. Would you please help me with it? Looking forward to hearing from you and many thanks in advance I appreciate your time Zeina -------------- next part -------------- An HTML attachment was scrubbed... URL: From hat343 at gmail.com Sun Dec 14 07:32:00 2014 From: hat343 at gmail.com (Hassan Tahini) Date: Sun, 14 Dec 2014 09:32:00 +0300 Subject: [Wannier] The meaning of wannier_hr.dat Message-ID: Dear All, We are having a problem interpreting the output of wannier_hr.dat. This file is supposed to contain the on-site energies and hopping elements from one orbital on one site to another. We have a perovskite system (space group R-3c) with octahedral tilting and we are interested in the eg bands, we define our projections as: num_wann = 4 num_bands = 144 begin projections Mn:l=2,mr=1,4 end projections Part of the wannier90.up_hr.dat looks like this: 0 0 0 1 1 11.382484 0.000000 0 0 0 2 1 -0.435842 0.000000 0 0 0 3 1 0.017151 0.000000 0 0 0 4 1 0.170537 0.000000 0 0 0 1 2 -0.435842 0.000000 0 0 0 2 2 11.966686 0.000000 0 0 0 3 2 -0.067861 0.000000 0 0 0 4 2 -0.613858 0.000000 We are finding it difficult to interpret the above. Can we say for instance that there is ?hopping? between the dz2 orbital on atom one to a dx2-y2 on the same atom (=-0.435 eV)? Or can we say that the hopping between dz2 on atom 1 to dx2-y2 on atom 2 is 0.17 eV? Shouldn't the hopping between orthogonal orbitals be equal to zero? Should we use different projection settings? Your help is highly appreciated. Hassan p.s. The band structure obtained with wannier90 looks just like the one we obtain from ab-initio calculations. -- *Dr Hassan A. Tahini* *PhD, DIC* *Physical Sciences and Engineering,* *Computational Physics & Materials Science Group,* *KAUST* -------------- next part -------------- An HTML attachment was scrubbed... URL: From sharmajncasr at gmail.com Sun Dec 14 07:36:03 2014 From: sharmajncasr at gmail.com (SRKC Sharma Yamijala) Date: Sun, 14 Dec 2014 12:06:03 +0530 Subject: [Wannier] Restarting the calculation with increased dis_num_iter In-Reply-To: References: Message-ID: baruo3.wout baruo3.win Dear Giovanni, Thank you for your prompt reply. Yes. That's my question. For my problem, BaRuO3, the disentaglement routine is not getting converged (to the default 10^-10 value) even after 20,000 iterations (It reached only till 10^-8). Its taking ~ 1 day for running 20,000 steps. So, I need to increase the steps now. Any suggestions for quicker convergence? Can I use the wannier90.x parallely? Thanking you, Sincerely, Sharma. ******************************************************** *Chaitanya Sharma,* *Prof. Pati'*s group, Chemistry and Physics Materials unit, JNCASR, BANGLORE, Lab:: (080-2208) 2581, 2809 https://sites.google.com/site/sharmasrkcyamijala/ ********************************************************* On Fri, Dec 12, 2014 at 10:36 PM, SRKC Sharma Yamijala < sharmajncasr at gmail.com> wrote: > > Dear Giovanni, > > Thank you for your prompt reply. > > Yes. That's my question. For my problem, BaRuO3, the disentaglement > routine is not getting converged (to the default 10^-10 value) even after > 20,000 iterations (It reached only till 10^-8). Its taking ~ 1 day for > running 20,000 steps. So, I need to increase the steps now. > > Any suggestions for quicker convergence? Can I use the wannier90.x > parallely? > > Thanking you, > Sincerely, > Sharma. > > > > > > > > > ******************************************************** > *Chaitanya Sharma,* > *Prof. Pati'*s group, > Chemistry and Physics Materials unit, > JNCASR, BANGLORE, > Lab:: (080-2208) 2581, 2809 > https://sites.google.com/site/sharmasrkcyamijala/ > ********************************************************* > > On Fri, Dec 12, 2014 at 9:14 PM, > wrote: >> >> Send Wannier mailing list submissions to >> wannier at quantum-espresso.org >> >> To subscribe or unsubscribe via the World Wide Web, visit >> http://mailman.qe-forge.org/cgi-bin/mailman/listinfo/wannier >> or, via email, send a message with subject or body 'help' to >> wannier-request at quantum-espresso.org >> >> You can reach the person managing the list at >> wannier-owner at quantum-espresso.org >> >> When replying, please edit your Subject line so it is more specific >> than "Re: Contents of Wannier digest..." >> >> >> Today's Topics: >> >> 1. where is libwannier.a (liujian) >> 2. Re: where is libwannier.a (liujian) >> 3. Re: DOS calculation with full and IBZ giving different >> results (Giovanni Pizzi) >> 4. Re: Restarting the calculation with increased dis_num_iter >> (Giovanni Pizzi) >> >> >> ---------------------------------------------------------------------- >> >> Message: 1 >> Date: Fri, 12 Dec 2014 23:00:28 +0800 >> From: liujian >> To: wannier at quantum-espresso.org >> Subject: [Wannier] where is libwannier.a >> Message-ID: <548B030C.4060804 at gmail.com> >> Content-Type: text/plain; charset="utf-8"; Format="flowed" >> >> Dear all, >> >> According to this direction: >> http://cms.mpi.univie.ac.at/wiki/index.php/LWANNIER90 >> >> LIB = -L../vasp.5.lib -ldmy \ >> ../vasp.5.lib/linpack_double.o ../wannier90-1.2/libwannier.a $(SCA) >> $(LAPACK) $(BLAS) >> >> >> There should be a libwannier.a where the wannier90-1.2 installed. >> >> But I can't find it. >> >> I used ifort and mkl library. >> There does have a warning: >> >> >> ifort wannier_prog.F90 -O2 -Vaxlib constants.o io.o utility.o >> parameters.o hamiltonian.o overlap.o kmesh.o disentangle.o wannierise.o >> plot.o transport.o -L/home/liu/intel/mkl/lib/intel64 -lmkl_core >> -lmkl_intel_lp64 -lmkl_sequential -lpthread -o ../wannier90.x >> ifort: command line remark #10148: option '-Vaxlib' not supported >> >> >> Thanks, >> Jian Liu >> >> >> -- >> Jain Liu >> College of Materials Science and Engineering >> Hunan University >> Changsha, 434100, China >> e-mail: whuliujian at gmail.com >> >> >> -------------- next part -------------- >> An HTML attachment was scrubbed... >> URL: < >> http://mailman.qe-forge.org/pipermail/wannier/attachments/20141212/9fcc9161/attachment-0001.html >> > >> >> ------------------------------ >> >> Message: 2 >> Date: Fri, 12 Dec 2014 23:09:13 +0800 >> From: liujian >> To: wannier at quantum-espresso.org >> Subject: Re: [Wannier] where is libwannier.a >> Message-ID: <548B0519.1030202 at gmail.com> >> Content-Type: text/plain; charset="utf-8"; Format="flowed" >> >> Problem solved >> Sorry >> -- >> Jain Liu >> College of Materials Science and Engineering >> Hunan University >> Changsha, 434100, China >> e-mail: whuliujian at gmail.com >> >> >> On 12/12/2014 11:00 PM, liujian wrote: >> > Dear all, >> > >> > According to this direction: >> > http://cms.mpi.univie.ac.at/wiki/index.php/LWANNIER90 >> > >> > LIB = -L../vasp.5.lib -ldmy \ >> > ../vasp.5.lib/linpack_double.o ../wannier90-1.2/libwannier.a >> $(SCA) $(LAPACK) $(BLAS) >> > >> > There should be a libwannier.a where the wannier90-1.2 installed. >> > >> > But I can't find it. >> > >> > I used ifort and mkl library. >> > There does have a warning: >> > >> > >> > ifort wannier_prog.F90 -O2 -Vaxlib constants.o io.o utility.o >> > parameters.o hamiltonian.o overlap.o kmesh.o disentangle.o >> > wannierise.o plot.o transport.o -L/home/liu/intel/mkl/lib/intel64 >> > -lmkl_core -lmkl_intel_lp64 -lmkl_sequential -lpthread -o ../wannier90.x >> > ifort: command line remark #10148: option '-Vaxlib' not supported >> > >> > >> > Thanks, >> > Jian Liu >> > >> > >> > -- >> > Jain Liu >> > College of Materials Science and Engineering >> > Hunan University >> > Changsha, 434100, China >> > e-mail: whuliujian at gmail.com >> > >> >> -------------- next part -------------- >> An HTML attachment was scrubbed... >> URL: < >> http://mailman.qe-forge.org/pipermail/wannier/attachments/20141212/4a1ca6f0/attachment-0001.html >> > >> >> ------------------------------ >> >> Message: 3 >> Date: Fri, 12 Dec 2014 16:38:28 +0100 >> From: Giovanni Pizzi >> To: wannier at quantum-espresso.org >> Subject: Re: [Wannier] DOS calculation with full and IBZ giving >> different results >> Message-ID: <548B0BF4.5020107 at epfl.ch> >> Content-Type: text/plain; charset="windows-1252"; Format="flowed" >> >> Dear Raul, >> in order to understand if the problem is in the dos routine, or in the >> routine that generated the IBZ points, could you run the same thing >> (i.e. DOS, with and without wanint_kpoint_file), but using >> dos_adpt_smr=False, and instead a fixed-width smearing? (e.g. a gaussian >> smearing) >> And then compare the results, and report them here? >> >> As a further detail, could you also check if the units for the kpoints >> that you are passing in the wanint file are the one expected by the code? >> >> Thanks, >> Giovanni >> >> >> On 12/12/2014 11:09 AM, Raul Laasner wrote: >> > Dear all, >> > >> > When I calculate the density of the lowest conduction states of NaI >> > (see attachment), I get different results for using k-points from the >> > full and irreducible Brillouin zones. The difference is smaller when >> > the k-mesh is allowed to use less symmetries, e.g. only the time >> > reversal symmetry. There is no difference if the 'kpoint.dat' file >> > contains the full BZ. This suggests the code I use for generating IBZ >> > points might be in error, but I get the same results with both abinit >> > and elk (they deliver different, but equivalent IBZ points). Could it >> > be that the DOS calculation is very sensitive to small numerical >> > inaccuracies and this leads to slightly different results for full and >> > irreducible BZs? The DOS related part of my input file is the following: >> > >> > dos true >> > dos_kmesh 20 >> > dos_adpt_smr true >> > wanint_kpoint_file false # true for the second run >> > >> > The difference is also present with dos_kmesh 50. Please ask for other >> > details I'm not showing. Any suggestions are welcome. >> > >> > Thanks, >> > Raul Laasner >> > >> > >> > -- >> > Raul Laasner >> > Institute of Physics >> > University of Tartu >> > Ravila 14c, 50411, Estonia >> > e-mail: raullaasner at gmail.com >> > cell: (+372)5182268 >> > >> > >> > _______________________________________________ >> > Wannier mailing list >> > Wannier at quantum-espresso.org >> > http://mailman.qe-forge.org/cgi-bin/mailman/listinfo/wannier >> >> >> -- >> Giovanni Pizzi >> Post-doctoral Research Scientist >> EPFL STI IMX THEOS >> MXC 340 (B?timent MXC) >> Station 12 >> CH-1015 Lausanne (Switzerland) >> Phone: +41 21 69 31124 >> >> -------------- next part -------------- >> An HTML attachment was scrubbed... >> URL: < >> http://mailman.qe-forge.org/pipermail/wannier/attachments/20141212/5888f922/attachment-0001.html >> > >> >> ------------------------------ >> >> Message: 4 >> Date: Fri, 12 Dec 2014 16:43:55 +0100 >> From: Giovanni Pizzi >> To: wannier at quantum-espresso.org >> Subject: Re: [Wannier] Restarting the calculation with increased >> dis_num_iter >> Message-ID: <548B0D3B.4040809 at epfl.ch> >> Content-Type: text/plain; charset="windows-1252"; Format="flowed" >> >> Dear Sharma, >> >> if I remember correctly (if I am wrong, please correct me): >> >> if, say, you run 100 disentanglement iterations, there is currently no >> option to restart from iteration 101 for the disentanglement; this >> option only exists for wannierisation. >> Anyway, since disentaglement is the first operation executed by the >> code, and it is (typically) fast, you can just change the maximum number >> of disentanglement steps, and restart the calculation from scratch. >> >> Best, >> Giovanni >> >> >> On 12/12/2014 10:51 AM, SRKC Sharma Yamijala wrote: >> > Dear Wannier member, >> > >> > I would like to restart the calculation with increased disentaglement >> > interations. Could you tell me which restart flag I need to consider? >> > I tried with restart=default, but it didn't work. >> > >> > Thanking you, >> > Sincerely, >> > Sharma. >> > >> > >> > >> > >> > >> > >> > >> > ******************************************************** >> > *Chaitanya Sharma,* >> > *Prof. Pati'*s group, >> > Chemistry and Physics Materials unit, >> > JNCASR, BANGLORE, >> > Lab:: (080-2208) 2581, 2809 >> > https://sites.google.com/site/sharmasrkcyamijala/ >> > ********************************************************* >> > >> > >> > _______________________________________________ >> > Wannier mailing list >> > Wannier at quantum-espresso.org >> > http://mailman.qe-forge.org/cgi-bin/mailman/listinfo/wannier >> >> >> -- >> Giovanni Pizzi >> Post-doctoral Research Scientist >> EPFL STI IMX THEOS >> MXC 340 (B?timent MXC) >> Station 12 >> CH-1015 Lausanne (Switzerland) >> Phone: +41 21 69 31124 >> >> -------------- next part -------------- >> An HTML attachment was scrubbed... >> URL: < >> http://mailman.qe-forge.org/pipermail/wannier/attachments/20141212/b1d92384/attachment.html >> > >> >> ------------------------------ >> >> Subject: Digest Footer >> >> _______________________________________________ >> Wannier mailing list >> Wannier at quantum-espresso.org >> http://mailman.qe-forge.org/cgi-bin/mailman/listinfo/wannier >> >> >> ------------------------------ >> >> End of Wannier Digest, Vol 83, Issue 7 >> ************************************** >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From a.mostofi at imperial.ac.uk Sun Dec 14 12:28:55 2014 From: a.mostofi at imperial.ac.uk (Mostofi, Arash) Date: Sun, 14 Dec 2014 11:28:55 +0000 Subject: [Wannier] The meaning of wannier_hr.dat In-Reply-To: References: Message-ID: <811EB98E-3470-4460-B3CF-3052470F0482@imperial.ac.uk> Dear Hassan, Each line in hr.dat refers to an element of H_{mn}(R) = . The first three entries in each line give the translation vector R, the next two give the WF indices m and n, and the last two are the real and imaginary parts of the matrix element itself. See the User Guide Sec. 8.18, for example. The order of the indices m and n are the same order in which the WFs appear at the end of the wannier90 output file (*.wout), so which atoms are referred to by a particular hopping matrix element with indices m and n depends on where the wannier functions w_m and w_n are centred in the cell. Whilst the WFs themselves are orthogonal, you would not expect the matrix representation of the Hamiltonian in the WF basis to be diagonal in the m and n indices because the WFs are not eigenstates of H. The WFs are, however, localised, so you would expect the matrix elements of H to reflect this. Hope this helps, Arash ? Dr Arash Mostofi ? www.mostofigroup.org Imperial College London Director, Thomas Young Centre @Imperial Assistant Director, CDT in Theory & Simulation of Materials Warden, Wilkinson & Weeks Hall On 14 Dec 2014, at 06:32, Hassan Tahini > wrote: Dear All, We are having a problem interpreting the output of wannier_hr.dat. This file is supposed to contain the on-site energies and hopping elements from one orbital on one site to another. We have a perovskite system (space group R-3c) with octahedral tilting and we are interested in the eg bands, we define our projections as: num_wann = 4 num_bands = 144 begin projections Mn:l=2,mr=1,4 end projections Part of the wannier90.up_hr.dat looks like this: 0 0 0 1 1 11.382484 0.000000 0 0 0 2 1 -0.435842 0.000000 0 0 0 3 1 0.017151 0.000000 0 0 0 4 1 0.170537 0.000000 0 0 0 1 2 -0.435842 0.000000 0 0 0 2 2 11.966686 0.000000 0 0 0 3 2 -0.067861 0.000000 0 0 0 4 2 -0.613858 0.000000 We are finding it difficult to interpret the above. Can we say for instance that there is ?hopping? between the dz2 orbital on atom one to a dx2-y2 on the same atom (=-0.435 eV)? Or can we say that the hopping between dz2 on atom 1 to dx2-y2 on atom 2 is 0.17 eV? Shouldn't the hopping between orthogonal orbitals be equal to zero? Should we use different projection settings? Your help is highly appreciated. Hassan p.s. The band structure obtained with wannier90 looks just like the one we obtain from ab-initio calculations. -- Dr Hassan A. Tahini PhD, DIC Physical Sciences and Engineering, Computational Physics & Materials Science Group, KAUST _______________________________________________ Wannier mailing list Wannier at quantum-espresso.org http://mailman.qe-forge.org/cgi-bin/mailman/listinfo/wannier -------------- next part -------------- An HTML attachment was scrubbed... URL: From a.mostofi at imperial.ac.uk Sun Dec 14 13:53:41 2014 From: a.mostofi at imperial.ac.uk (Mostofi, Arash) Date: Sun, 14 Dec 2014 12:53:41 +0000 Subject: [Wannier] how to find projections in seedname.win? In-Reply-To: References: Message-ID: Dear Zeina, Within the Quantum-Espresso suite the projections for Wannier90 are calculated (among other things) by the post-processing code pw2wannier90 (in the PP directory of the QE distribution). It would probably be very helpful for you to go through the Wannier90 tutorials if you have not already done so. These take you step-by-step through the process of setting up certain calculations, including the use of projections and pw2wannier90. The document describing the tutorials can be found in the Wannier90 source under /doc/tutorial.pdf and the input files under /examples. Best wishes, Arash ? Dr Arash Mostofi ? www.mostofigroup.org Imperial College London Director, Thomas Young Centre @Imperial Assistant Director, CDT in Theory & Simulation of Materials Warden, Wilkinson & Weeks Hall On 14 Dec 2014, at 05:20, Zeina Al-Dolami > wrote: To wannier's owners and developers, Thanks to everyone for helping us. I have a question related to the projections in the input seedname.win. I am aware that there are different types of projections. I am confused about how to find these projections. Is it by using projwfc.x in PP? If so, is there an example of the input file or standard input file that you can inform me of? The user's manual for PP does not have much details and I am confused about it. Would you please help me with it? Looking forward to hearing from you and many thanks in advance I appreciate your time Zeina [https://ssl.gstatic.com/ui/v1/icons/mail/images/cleardot.gif] _______________________________________________ Wannier mailing list Wannier at quantum-espresso.org http://mailman.qe-forge.org/cgi-bin/mailman/listinfo/wannier -------------- next part -------------- An HTML attachment was scrubbed... URL: From brehmj at sas.upenn.edu Sun Dec 14 14:56:01 2014 From: brehmj at sas.upenn.edu (JOHN BREHM) Date: Sun, 14 Dec 2014 08:56:01 -0500 Subject: [Wannier] please remove me from this list Message-ID: please remove me from this list -------------- next part -------------- An HTML attachment was scrubbed... URL: From giovanni.pizzi at epfl.ch Mon Dec 15 12:44:13 2014 From: giovanni.pizzi at epfl.ch (Giovanni Pizzi) Date: Mon, 15 Dec 2014 12:44:13 +0100 Subject: [Wannier] Restarting the calculation with increased dis_num_iter In-Reply-To: References: Message-ID: <548EC98D.5010804@epfl.ch> Dear Sharma, if you need to run thousands of iterations for the disentanglement part, probably you have either chosen the incorrect initial projections, or the energy windows are not large enough (for instance, you are cutting a part of a band of the symmetry you want out of the window). In my experience, you should be able to converge the disentanglement in, say, ~100 iterations (of course, the actual number can strongly depend on the system!), otherwise even if you manage the final Wannier functions, they will not be a true minimum (they could have complex components, etc.) So my suggestion would be to try to check better the input parameters before investing time in running more disentanglement steps. Hope this helps, Giovanni PS: At the moment, the wannier90.x executable runs only in serial. On 12/14/2014 07:36 AM, SRKC Sharma Yamijala wrote: > > baruo3.wout > > > baruo3.win > > Dear Giovanni, > > Thank you for your prompt reply. > > Yes. That's my question. For my problem, BaRuO3, the disentaglement > routine is not getting converged (to the default 10^-10 value) even > after 20,000 iterations (It reached only till 10^-8). Its taking ~ 1 > day for running 20,000 steps. So, I need to increase the steps now. > > Any suggestions for quicker convergence? Can I use the wannier90.x > parallely? > > Thanking you, > Sincerely, > Sharma. > > > > > > > > > ******************************************************** > *Chaitanya Sharma,* > *Prof. Pati'*s group, > Chemistry and Physics Materials unit, > JNCASR, BANGLORE, > Lab:: (080-2208) 2581, 2809 > https://sites.google.com/site/sharmasrkcyamijala/ > ********************************************************* > > On Fri, Dec 12, 2014 at 10:36 PM, SRKC Sharma Yamijala > > wrote: > > Dear Giovanni, > > Thank you for your prompt reply. > > Yes. That's my question. For my problem, BaRuO3, the > disentaglement routine is not getting converged (to the default > 10^-10 value) even after 20,000 iterations (It reached only till > 10^-8). Its taking ~ 1 day for running 20,000 steps. So, I need to > increase the steps now. > > Any suggestions for quicker convergence? Can I use the wannier90.x > parallely? > > Thanking you, > Sincerely, > Sharma. > > > > > > > > > ******************************************************** > *Chaitanya Sharma,* > *Prof. Pati'*s group, > Chemistry and Physics Materials unit, > JNCASR, BANGLORE, > Lab:: (080-2208) 2581, 2809 > https://sites.google.com/site/sharmasrkcyamijala/ > ********************************************************* > > On Fri, Dec 12, 2014 at 9:14 PM, > > wrote: > > Send Wannier mailing list submissions to > wannier at quantum-espresso.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://mailman.qe-forge.org/cgi-bin/mailman/listinfo/wannier > or, via email, send a message with subject or body 'help' to > wannier-request at quantum-espresso.org > > > You can reach the person managing the list at > wannier-owner at quantum-espresso.org > > > When replying, please edit your Subject line so it is more > specific > than "Re: Contents of Wannier digest..." > > > Today's Topics: > > 1. where is libwannier.a (liujian) > 2. Re: where is libwannier.a (liujian) > 3. Re: DOS calculation with full and IBZ giving different > results (Giovanni Pizzi) > 4. Re: Restarting the calculation with increased dis_num_iter > (Giovanni Pizzi) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 12 Dec 2014 23:00:28 +0800 > From: liujian > > To: wannier at quantum-espresso.org > > Subject: [Wannier] where is libwannier.a > Message-ID: <548B030C.4060804 at gmail.com > > > Content-Type: text/plain; charset="utf-8"; Format="flowed" > > Dear all, > > According to this direction: > http://cms.mpi.univie.ac.at/wiki/index.php/LWANNIER90 > > LIB = -L../vasp.5.lib -ldmy \ > ../vasp.5.lib/linpack_double.o > ../wannier90-1.2/libwannier.a $(SCA) $(LAPACK) $(BLAS) > > > There should be a libwannier.a where the wannier90-1.2 installed. > > But I can't find it. > > I used ifort and mkl library. > There does have a warning: > > > ifort wannier_prog.F90 -O2 -Vaxlib constants.o io.o utility.o > parameters.o hamiltonian.o overlap.o kmesh.o disentangle.o > wannierise.o > plot.o transport.o -L/home/liu/intel/mkl/lib/intel64 -lmkl_core > -lmkl_intel_lp64 -lmkl_sequential -lpthread -o ../wannier90.x > ifort: command line remark #10148: option '-Vaxlib' not supported > > > Thanks, > Jian Liu > > > -- > Jain Liu > College of Materials Science and Engineering > Hunan University > Changsha, 434100, China > e-mail: whuliujian at gmail.com > > > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > > > ------------------------------ > > Message: 2 > Date: Fri, 12 Dec 2014 23:09:13 +0800 > From: liujian > > To: wannier at quantum-espresso.org > > Subject: Re: [Wannier] where is libwannier.a > Message-ID: <548B0519.1030202 at gmail.com > > > Content-Type: text/plain; charset="utf-8"; Format="flowed" > > Problem solved > Sorry > -- > Jain Liu > College of Materials Science and Engineering > Hunan University > Changsha, 434100, China > e-mail: whuliujian at gmail.com > > > > > On 12/12/2014 11:00 PM, liujian wrote: > > Dear all, > > > > According to this direction: > > http://cms.mpi.univie.ac.at/wiki/index.php/LWANNIER90 > > > > LIB = -L../vasp.5.lib -ldmy \ > > ../vasp.5.lib/linpack_double.o > ../wannier90-1.2/libwannier.a $(SCA) $(LAPACK) $(BLAS) > > > > There should be a libwannier.a where the wannier90-1.2 > installed. > > > > But I can't find it. > > > > I used ifort and mkl library. > > There does have a warning: > > > > > > ifort wannier_prog.F90 -O2 -Vaxlib constants.o io.o utility.o > > parameters.o hamiltonian.o overlap.o kmesh.o disentangle.o > > wannierise.o plot.o transport.o > -L/home/liu/intel/mkl/lib/intel64 > > -lmkl_core -lmkl_intel_lp64 -lmkl_sequential -lpthread -o > ../wannier90.x > > ifort: command line remark #10148: option '-Vaxlib' not > supported > > > > > > Thanks, > > Jian Liu > > > > > > -- > > Jain Liu > > College of Materials Science and Engineering > > Hunan University > > Changsha, 434100, China > > e-mail: whuliujian at gmail.com > > > > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > > > ------------------------------ > > Message: 3 > Date: Fri, 12 Dec 2014 16:38:28 +0100 > From: Giovanni Pizzi > > To: wannier at quantum-espresso.org > > Subject: Re: [Wannier] DOS calculation with full and IBZ giving > different results > Message-ID: <548B0BF4.5020107 at epfl.ch > > > Content-Type: text/plain; charset="windows-1252"; Format="flowed" > > Dear Raul, > in order to understand if the problem is in the dos routine, > or in the > routine that generated the IBZ points, could you run the same > thing > (i.e. DOS, with and without wanint_kpoint_file), but using > dos_adpt_smr=False, and instead a fixed-width smearing? (e.g. > a gaussian > smearing) > And then compare the results, and report them here? > > As a further detail, could you also check if the units for the > kpoints > that you are passing in the wanint file are the one expected > by the code? > > Thanks, > Giovanni > > > On 12/12/2014 11:09 AM, Raul Laasner wrote: > > Dear all, > > > > When I calculate the density of the lowest conduction states > of NaI > > (see attachment), I get different results for using k-points > from the > > full and irreducible Brillouin zones. The difference is > smaller when > > the k-mesh is allowed to use less symmetries, e.g. only the time > > reversal symmetry. There is no difference if the > 'kpoint.dat' file > > contains the full BZ. This suggests the code I use for > generating IBZ > > points might be in error, but I get the same results with > both abinit > > and elk (they deliver different, but equivalent IBZ points). > Could it > > be that the DOS calculation is very sensitive to small numerical > > inaccuracies and this leads to slightly different results > for full and > > irreducible BZs? The DOS related part of my input file is > the following: > > > > dos true > > dos_kmesh 20 > > dos_adpt_smr true > > wanint_kpoint_file false # true for the second run > > > > The difference is also present with dos_kmesh 50. Please ask > for other > > details I'm not showing. Any suggestions are welcome. > > > > Thanks, > > Raul Laasner > > > > > > -- > > Raul Laasner > > Institute of Physics > > University of Tartu > > Ravila 14c, 50411, Estonia > > e-mail: raullaasner at gmail.com > > > > cell: (+372)5182268 > > > > > > _______________________________________________ > > Wannier mailing list > > Wannier at quantum-espresso.org > > > http://mailman.qe-forge.org/cgi-bin/mailman/listinfo/wannier > > > -- > Giovanni Pizzi > Post-doctoral Research Scientist > EPFL STI IMX THEOS > MXC 340 (B?timent MXC) > Station 12 > CH-1015 Lausanne (Switzerland) > Phone: +41 21 69 31124 > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > > > ------------------------------ > > Message: 4 > Date: Fri, 12 Dec 2014 16:43:55 +0100 > From: Giovanni Pizzi > > To: wannier at quantum-espresso.org > > Subject: Re: [Wannier] Restarting the calculation with increased > dis_num_iter > Message-ID: <548B0D3B.4040809 at epfl.ch > > > Content-Type: text/plain; charset="windows-1252"; Format="flowed" > > Dear Sharma, > > if I remember correctly (if I am wrong, please correct me): > > if, say, you run 100 disentanglement iterations, there is > currently no > option to restart from iteration 101 for the disentanglement; this > option only exists for wannierisation. > Anyway, since disentaglement is the first operation executed > by the > code, and it is (typically) fast, you can just change the > maximum number > of disentanglement steps, and restart the calculation from > scratch. > > Best, > Giovanni > > > On 12/12/2014 10:51 AM, SRKC Sharma Yamijala wrote: > > Dear Wannier member, > > > > I would like to restart the calculation with increased > disentaglement > > interations. Could you tell me which restart flag I need to > consider? > > I tried with restart=default, but it didn't work. > > > > Thanking you, > > Sincerely, > > Sharma. > > > > > > > > > > > > > > > > ******************************************************** > > *Chaitanya Sharma,* > > *Prof. Pati'*s group, > > Chemistry and Physics Materials unit, > > JNCASR, BANGLORE, > > Lab:: (080-2208) 2581, 2809 > > https://sites.google.com/site/sharmasrkcyamijala/ > > ********************************************************* > > > > > > _______________________________________________ > > Wannier mailing list > > Wannier at quantum-espresso.org > > > http://mailman.qe-forge.org/cgi-bin/mailman/listinfo/wannier > > > -- > Giovanni Pizzi > Post-doctoral Research Scientist > EPFL STI IMX THEOS > MXC 340 (B?timent MXC) > Station 12 > CH-1015 Lausanne (Switzerland) > Phone: +41 21 69 31124 > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > Wannier mailing list > Wannier at quantum-espresso.org > http://mailman.qe-forge.org/cgi-bin/mailman/listinfo/wannier > > > ------------------------------ > > End of Wannier Digest, Vol 83, Issue 7 > ************************************** > > > > _______________________________________________ > Wannier mailing list > Wannier at quantum-espresso.org > http://mailman.qe-forge.org/cgi-bin/mailman/listinfo/wannier -- Giovanni Pizzi Post-doctoral Research Scientist EPFL STI IMX THEOS MXC 340 (B?timent MXC) Station 12 CH-1015 Lausanne (Switzerland) Phone: +41 21 69 31124 -------------- next part -------------- An HTML attachment was scrubbed... URL: From guzmanar at cab.cnea.gov.ar Mon Dec 15 19:24:49 2014 From: guzmanar at cab.cnea.gov.ar (robert.guzman) Date: Mon, 15 Dec 2014 15:24:49 -0300 Subject: [Wannier] Phase of plot of wannier functions Message-ID: Dear wannier users I have the same problem that is written below. !***************************************************************************************************** Dear all, I used wannier90 to calculate hopping parameters for my solid bulk and all is fine. I used wannier90 to plot wannier functions and I visualized using xcrysden. My problem is that phase of the wannier functions in the plot are not in agreement with the sign of hopping parameters. I observed that the 'Maximum grid value' is always bigger than the module of the 'Minimum grid value' when I use the plot generated from wannier90. I thought that, to impose this condition, the phase of some wannier functions in the plot are changed. Somebody found similar problem? Best Thanks Carmine !***************************************************************************************************** Do the wannier functions have the correct phase when are plotted with xcrysden? Mgter. R. M. Guzm?n A. Insituto Balseiro. Argentina. From elias.assmann at gmail.com Tue Dec 16 09:54:38 2014 From: elias.assmann at gmail.com (Elias Assmann) Date: Tue, 16 Dec 2014 09:54:38 +0100 Subject: [Wannier] Phase of plot of wannier functions In-Reply-To: References: Message-ID: <548FF34E.70209@gmail.com> On 12/15/2014 07:24 PM, robert.guzman wrote: > Do the wannier functions have the correct phase when are plotted with > xcrysden? As far as I know, xcrysden cannot handle complex phases, only positive / negative. So if your WFs have a true nontrivial phase, xcrysden will not be able to show that. If it is a ?trivial? phase (i.e. they could be made real by a global phase factor), I guess what you will see depends on which interface / plotting program you are using. Here, I can only speak for wien2wannier: the ?wplot2xsf? program uses the sign of the real part [i.e. |w(r)|? * sgn(Re w(r))], which normally works fine. HTH, Elias From giovanni.pizzi at epfl.ch Tue Dec 16 10:31:37 2014 From: giovanni.pizzi at epfl.ch (Giovanni Pizzi) Date: Tue, 16 Dec 2014 10:31:37 +0100 Subject: [Wannier] Phase of plot of wannier functions In-Reply-To: <548FF34E.70209@gmail.com> References: <548FF34E.70209@gmail.com> Message-ID: <548FFBF9.80103@epfl.ch> Dear all, indeed, as Elias says, one has to store a real-valued function in the XSF file. From plot.F90 in the Wannier distribution: ! fix the global phase by setting the wannier to ! be real at the point where it has max. modulus (the lines below this comment have the implementation). Then, in the function internal_xsf_format (in the same plot.F90 file), only the real part of the functions you get with the 'phase fixing' mentioned above are printed to the XSF file. This should explain the behavior you notice. Best, Giovanni On 12/16/2014 09:54 AM, Elias Assmann wrote: > On 12/15/2014 07:24 PM, robert.guzman wrote: >> Do the wannier functions have the correct phase when are plotted with >> xcrysden? > > As far as I know, xcrysden cannot handle complex phases, only positive > / negative. So if your WFs have a true nontrivial phase, xcrysden > will not be able to show that. > > If it is a ?trivial? phase (i.e. they could be made real by a global > phase factor), I guess what you will see depends on which interface / > plotting program you are using. Here, I can only speak for > wien2wannier: the ?wplot2xsf? program uses the sign of the real part > [i.e. |w(r)|? * sgn(Re w(r))], which normally works fine. > > > HTH, > > Elias > > > _______________________________________________ > Wannier mailing list > Wannier at quantum-espresso.org > http://mailman.qe-forge.org/cgi-bin/mailman/listinfo/wannier -- Giovanni Pizzi Post-doctoral Research Scientist EPFL STI IMX THEOS MXC 340 (B?timent MXC) Station 12 CH-1015 Lausanne (Switzerland) Phone: +41 21 69 31124 From tberlijn at gmail.com Sun Dec 21 21:44:13 2014 From: tberlijn at gmail.com (Tom Berlijn) Date: Sun, 21 Dec 2014 15:44:13 -0500 Subject: [Wannier] Wannier functions on arbitrary grid? Message-ID: <5497311D.40600@gmail.com> Dear developers of Wannier90, I would like to plot Wannier functions on an arbitrary grid defined in terms of number of grid points, origin, and 3 vectors. If I understood correctly this is not possible in the current version of wannier90. Would anyone be able to give advice on how the source code(s) would need to be modified for this purpose? Thanks, Tom From a.mostofi at imperial.ac.uk Tue Dec 30 13:52:37 2014 From: a.mostofi at imperial.ac.uk (Mostofi, Arash) Date: Tue, 30 Dec 2014 12:52:37 +0000 Subject: [Wannier] Wannier functions on arbitrary grid? In-Reply-To: <5497311D.40600@gmail.com> References: <5497311D.40600@gmail.com> Message-ID: Dear Tom, When it comes to plotting the WFs, Wannier90 reads the periodic parts of the Bloch states, u_{nk}(r), on whatever grid (lattice vectors and number of grid points) that was used by underlying electronic structure code (see User Guide Sec 8.16 for the format of these ?unk" files). It then uses this information together with the optimal U-matrix that was determined by the earlier disentanglement/wannierisation procedure, to calculate the WFs on the grid via the expression for the Wannier transformation (User Guide Eq (1.1)). Because the periodicity of the WFs is not the same as that of the u_{nk}(r), the grid on which the WFs are computed is by default larger in each lattice vector dimension by a factor of two, though this can be increased by setting wannier_plot_supercell in the *.win file. The code that deals with plotting is all in /src/plot.F90 in the main W90 distribution, specifically in the subroutine plot_wannier. Modifying the code to change the origin of the WF plot data would be relatively straightforward. To use an arbitrary number of grid-points and arbitrary lattice vectors would require some form of interpolation of the u_nk(r) data, e.g., directly in the underlying electronic structure code before the data are written or as a post-processing after they are written, and this would be somewhat less straightforward. Note that an undocumented feature of the PWscf interface (pw2wannier90) is the logical input parameter reduce_unk. When set to true, it results in the u_{nk}(r) being written to disk on a grid that is only half as dense in each lattice vector direction than the wavefunction grid determined by the plane-wave energy cut-off. This is often good enough for smooth visualisation of WFs, but saves a lot of disk space for large calculations. Hope this helps ? and please sign off with your affiliation when posting to this list. Arash ? Dr Arash Mostofi ? www.mostofigroup.org Imperial College London Director, Thomas Young Centre @Imperial Assistant Director, CDT in Theory & Simulation of Materials Warden, Wilkinson & Weeks Hall On 21 Dec 2014, at 20:44, Tom Berlijn > wrote: Dear developers of Wannier90, I would like to plot Wannier functions on an arbitrary grid defined in terms of number of grid points, origin, and 3 vectors. If I understood correctly this is not possible in the current version of wannier90. Would anyone be able to give advice on how the source code(s) would need to be modified for this purpose? Thanks, Tom _______________________________________________ Wannier mailing list Wannier at quantum-espresso.org http://mailman.qe-forge.org/cgi-bin/mailman/listinfo/wannier -------------- next part -------------- An HTML attachment was scrubbed... URL: From ustc.scgyer at gmail.com Tue Dec 30 21:11:37 2014 From: ustc.scgyer at gmail.com (xiaochuan Ge) Date: Tue, 30 Dec 2014 15:11:37 -0500 Subject: [Wannier] How wannier functions are stored Message-ID: Dear all, I kindly ask someone to explain me how indeed wannier functions (WFs) are stored in wannier90. First please let me elaborate my own understanding. Though WFs are not periodical, in practice using finite number of k-points (say nk) to generate the WFs leads to a periodic length of nk*cell. So in order to represent WFs with plane waves, the G-mesh must be nk times finer than the one for bloch wavefunction. Is this really how WFs are represented in wannier90? In addition, if one has to do some calculation with WFs, does he has to deal with a vector nk times larger than the wavefunction? It would be very appreciated if someone could summarize different strategies to represent and manipulate WFs in the code and give me some reference for understanding the details. Thank you very much in advance. =================== Dr. Xiaochuan Ge (Giovanni) Center for Functional Nanomaterials Brookhaven national laboratory =================== -------------- next part -------------- An HTML attachment was scrubbed... URL: