Re: [Pw_forum] insufficient virtual memory - hyb_func calculation

2016-01-19 Thread Mohamad Moadeli
Dear Paolo,

Many thanks for your reply,

The system under study is graphene/Ag(111)/Ni(111). so there are two
interfaces and I expect it to be converged in too much iterations at the
first step (from experience).
I tried to do it with 50 and 400 cutoffs and also 12 12 1 kpoints but the
system was not converged after 400 iterations.
The investigations were done using LDA, but we needed the results to be
evaluated by HYB_FUNCs.
what are your recommendations for dealing with this problem?

Thanks,

Mohammad

On Tue, Jan 19, 2016 at 10:38 PM, Paolo Giannozzi 
wrote:

> On Mon, Jan 18, 2016 at 8:09 AM, Mohamad Moadeli <
> mohammad.moadd...@gmail.com> wrote:
>
>
>>  EXX: setup a grid of 576 q-points centered on each k-point
>>
>
> note that all these wavefunctions have to be stored in memory ...
>
>  kinetic-energy cutoff =  70.  Ry
>  charge density cutoff = 500.  Ry
>  cutoff for Fock operator  = 280.  Ry
>
> ... and that you have a rather big cutoff
>
>  convergence has been achieved in 222 iterations
>
> 222 iterations is definitely too much
>
> Paolo
>
> --
> Paolo Giannozzi, Dip. Scienze Matematiche Informatiche e Fisiche,
> Univ. Udine, via delle Scienze 208, 33100 Udine, Italy
> Phone +39-0432-558216, fax +39-0432-558222
>
>
> ___
> Pw_forum mailing list
> Pw_forum@pwscf.org
> http://pwscf.org/mailman/listinfo/pw_forum
>
___
Pw_forum mailing list
Pw_forum@pwscf.org
http://pwscf.org/mailman/listinfo/pw_forum

[Pw_forum] R: Re: Oxidation state for dopants in TiO2

2016-01-19 Thread Giacomo Rossi
Dear Mostafa,
Thank you for your help. You gave me a lot of wonderful ideas to solve the 
problem.
Best regards,
Giacomo Rossi,Bologna University


Inviato da smartphone Samsung Galaxy. Messaggio originale Da: 
Mostafa Youssef  Data: 20/01/2016  05:03  (GMT+01:00) A: 
pw_forum@pwscf.org Oggetto: Re: [Pw_forum] Oxidation state for dopants in TiO2 

Dear Giacomo,



If the supercell is charge neutral which is the default, then one aims at 
simulating a neutral substitutional defect with respect to Ti. In this case V 
in 4+ oxidation state which corresponds in the naive fully ionic picture to V 
losing 4 of its valence electrons
 to oxygen and retaining the last one as you said.  The question arises whether 
this  electron is localized on the V site and it is really in 4+ oxidation 
state. The other alternative is that the electron delocalizes and the supercell 
contains V in 5+ oxidation
 state and an extra "free" electron. In my opinion the best  way to analyze 
this problem is to  start from the most positive oxidation state and 
systematically reduce it. In the case of V you can do 6 separate relaxation 
simulations starting from
tot_charge=+1 which corresponds to V on 5+ oxidation state, all the way to
tot_charge=-4 which corresponds to V in 0 oxidation state. After these 6 
simulations are done you can track the changes in the charge density and spin 
density when you go from the oxidation state q to the oxidation
 state q-1. In my experience V in oxides such as TiO2 can take oxidation states 
from 5+ to 2+.  If you compare 1+ and 2+ you will notice that the extra 
electron you add to 2+ to achieve 1+ never localizes on V and as such 2+ is 
likely the lowest oxidation state
 for V in these oxides. 





If you do not want to do this lengthy analysis and you just want to check 
whether you have 4+ or not , check the spin density. V4+ will likely have a net 
magnetic moment close to 1 Bohr Mag.





Also there are many cases in literature where achieving certain oxidation state 
never happens because of electron (hole) delocalization. For example, if you 
try to model neutral hydrogen interstitial in ZnO or ZrO2, you will get 
interstitial proton and a free
 delocalized electron. See for example:

http://journals.aps.org/prl/abstract/10.1103/PhysRevLett.85.1012





A final word of caution, analyzing the oxidation states of transition metal 
dopants and their changes by adding or removing electrons requires very dense 
and accurate grids for representing the charge (and spin) density. The reason 
is that the change of the
 localized charge (if any) on the transition metal defect while going from 
formal oxidation state q to q-1 is usually very low (in my experience in the 
order of 0.1 e). This observation was discussed in this
 article: http://www.nature.com/nature/journal/v453/n7196/full/nature07009.html

 

(It is also fun and instructive to follow the debate that this paper raised in 
literature!)



Best Regards,

Mostafa Youssef

MIT


___
Pw_forum mailing list
Pw_forum@pwscf.org
http://pwscf.org/mailman/listinfo/pw_forum

[Pw_forum] About Surface energy convergence

2016-01-19 Thread Bipul Rakshit
Dear PWscf Users,
In surface studies,for the slab calculations, the number of slabs is chosen
with the convergence of Surface energies. So what is the typical
convergence value I have to choose. I find some papers where the authors
choose upto 5 milli-J/m^2 (PRB 86, 075460 (2012). They  take the case of
Fe(001)/Au(001). These are basically the cubic structure.

What about the bit more complex structure like Zn(0001)/Au(111), where the
lattice mismatch is considerable and the structures also. Is the ~5
milli-J/m^2 accuracy essential, or we can set some upper limit of this
convergence value.

-- 
Dr. Bipul Rakshit
Research Associate,
Institute of Physics (IOP),
Bhubaneswar- 751 005
Orissa
India
___
Pw_forum mailing list
Pw_forum@pwscf.org
http://pwscf.org/mailman/listinfo/pw_forum

[Pw_forum] Problem with vc-relaxation with SOC+GGA

2016-01-19 Thread Debnath Talukdar
I was trying to do vc relaxation of orthrhombic CsPbBr3 with spin-orbit
coupling(SOC) and GGA (PBE) exchange-correlation. But  it shows
noncollinear stress + GGA not implemented. So how can I do vc-relaxation
with SOC with GGA exchange-correlation.


Thanks
___
Pw_forum mailing list
Pw_forum@pwscf.org
http://pwscf.org/mailman/listinfo/pw_forum

Re: [Pw_forum] Oxidation state for dopants in TiO2

2016-01-19 Thread Mostafa Youssef
Dear Giacomo,

If the supercell is charge neutral which is the default, then one aims at 
simulating a neutral substitutional defect with respect to Ti. In this case V 
in 4+ oxidation state which corresponds in the naive fully ionic picture to V 
losing 4 of its valence electrons to oxygen and retaining the last one as you 
said.  The question arises whether this  electron is localized on the V site 
and it is really in 4+ oxidation state. The other alternative is that the 
electron delocalizes and the supercell contains V in 5+ oxidation state and an 
extra "free" electron. In my opinion the best  way to analyze this problem is 
to  start from the most positive oxidation state and systematically reduce it. 
In the case of V you can do 6 separate relaxation simulations starting from 
tot_charge=+1 which corresponds to V on 5+ oxidation state, all the way to 
tot_charge=-4 which corresponds to V in 0 oxidation state. After these 6 
simulations are done you can track the changes in the charge density and spin 
density when you go from the oxidation state q to the oxidation state q-1. In 
my experience V in oxides such as TiO2 can take oxidation states from 5+ to 2+. 
 If you compare 1+ and 2+ you will notice that the extra electron you add to 2+ 
to achieve 1+ never localizes on V and as such 2+ is likely the lowest 
oxidation state for V in these oxides.


If you do not want to do this lengthy analysis and you just want to check 
whether you have 4+ or not , check the spin density. V4+ will likely have a net 
magnetic moment close to 1 Bohr Mag.


Also there are many cases in literature where achieving certain oxidation state 
never happens because of electron (hole) delocalization. For example, if you 
try to model neutral hydrogen interstitial in ZnO or ZrO2, you will get 
interstitial proton and a free delocalized electron. See for example:
http://journals.aps.org/prl/abstract/10.1103/PhysRevLett.85.1012


A final word of caution, analyzing the oxidation states of transition metal 
dopants and their changes by adding or removing electrons requires very dense 
and accurate grids for representing the charge (and spin) density. The reason 
is that the change of the localized charge (if any) on the transition metal 
defect while going from formal oxidation state q to q-1 is usually very low (in 
my experience in the order of 0.1 e). This observation was discussed in this 
article: http://www.nature.com/nature/journal/v453/n7196/full/nature07009.html

(It is also fun and instructive to follow the debate that this paper raised in 
literature!)

Best Regards,
Mostafa Youssef
MIT
___
Pw_forum mailing list
Pw_forum@pwscf.org
http://pwscf.org/mailman/listinfo/pw_forum

Re: [Pw_forum] insufficient virtual memory - hyb_func calculation

2016-01-19 Thread Paolo Giannozzi
On Mon, Jan 18, 2016 at 8:09 AM, Mohamad Moadeli <
mohammad.moadd...@gmail.com> wrote:


>  EXX: setup a grid of 576 q-points centered on each k-point
>

note that all these wavefunctions have to be stored in memory ...

 kinetic-energy cutoff =  70.  Ry
 charge density cutoff = 500.  Ry
 cutoff for Fock operator  = 280.  Ry

... and that you have a rather big cutoff

 convergence has been achieved in 222 iterations

222 iterations is definitely too much

Paolo

-- 
Paolo Giannozzi, Dip. Scienze Matematiche Informatiche e Fisiche,
Univ. Udine, via delle Scienze 208, 33100 Udine, Italy
Phone +39-0432-558216, fax +39-0432-558222
___
Pw_forum mailing list
Pw_forum@pwscf.org
http://pwscf.org/mailman/listinfo/pw_forum

Re: [Pw_forum] compiling QE: fftw problems

2016-01-19 Thread Paolo Giannozzi
As far as I know, QE uses quite standard MPI calls that work on any
reasonable version of MPI. The MPI release you have dates back to 2010.
Maybe you should inquire with your system administrator.

Paolo

On Tue, Jan 19, 2016 at 6:03 PM, Denis E. Zavelev  wrote:

> Hello Filippo!
>
> Thanks for your quick response.
> I use MVAPICH-1.2rc1, it's the only available MPI on JSC cluster and I am
> not allowed to use any other MPI implementations.
> I've sent you the files you asked.
>
>
> Среда, 20 января 2016, 0:45 +08:00 от Filippo SPIGA <
> filippo.sp...@quantum-espresso.org>:
>
>
> Dear Denis,
>
> are you using OpenMPI or Intel MPI?
>
> If Open MPI, try also
>
> ./configure MPIF90=mpiifort ...
>
>
> If Intel MPI (I assume this is your case), try instead
>
> ./configure MPIF90=mpiifort ... --with-scalapack=intel
>
>
> In the meanwhile please send me personally (not to the mailing-list!) to
> my email the "install/config.log" file and your make.sys.
>
> Regards
>
> --
> Mr. Filippo SPIGA, M.Sc.
> Quantum ESPRESSO Foundation
> http://www.quantum-espresso.org ~ skype: filippo.spiga
>
> *
> Disclaimer: "Please note this message and any attachments are CONFIDENTIAL
> and may be privileged or otherwise protected from disclosure. The contents
> are not to be disclosed to anyone other than the addressee. Unauthorized
> recipients are requested to preserve this confidentiality and to advise the
> sender immediately of any error in transmission."
>
> On Jan 20, 2016, at 12:20 AM, Denis E. Zavelev  > wrote:
> > Hello!
> >
> > I am trying to compile QE on JSC RAS cluster. As I have user
> permissions, I can install any programs only locally.
> > Cluster works under Linux. We have intel compilers (mpif90, icc, ifort)
> and MKL installed on cluster. No FFTW libraries are installed though even
> MKL ones (I have to build them locally).
> >
> > I've downloaded espresso 5.3.0 from the site.
> > Configure script finished successfully. But then I got 2 warnings and
> subsequent error message when compiling internal FFT.
> >
> > I decided to use some other FFT libs.
> > So I've downloaded FFTW3 from its site, successfully built, tested and
> installed it. But the same error message.
> >
> > Libraries found by configure script:
> > BLAS_LIBS= -lmkl_intel_lp64 -lmkl_sequential -lmkl_core
> > LAPACK_LIBS=
> > SCALAPACK_LIBS=-lmkl_scalapack_lp64 -lmkl_blacs_openmpi_lp64
> > FFT_LIBS= -lfftw3
> >
> > Here's the output:
> >
> > 
> > bash-3.2$ make pw
> > make: Warning: File `make.sys' has modification time 0.47 s in the future
> > test -d bin || mkdir bin
> > ( cd FFTXlib ; make TLDEPS= all || exit 1 )
> > make[1]: Entering directory
> `/nethome/metalian/espresso/espresso-5.3.0/FFTXlib'
> > make[1]: Warning: File `../make.sys' has modification time 0.46 s in the
> future
> > mpif90 -O2 -assume byterecl -g -traceback -par-report0 -vec-report0
> -nomodule -fpp -D__INTEL -D__FFTW3 -D__MPI -D__PARA -D__SCALAPACK
> -I../include -I../iotk/src -I. -c fft_types.f90
> > mpif90 -O2 -assume byterecl -g -traceback -par-report0 -vec-report0
> -nomodule -fpp -D__INTEL -D__FFTW3 -D__MPI -D__PARA -D__SCALAPACK
> -I../include -I../iotk/src -I. -c scatter_mod.f90
> > icc -O3 -D__INTEL -D__FFTW3 -D__MPI -D__PARA -D__SCALAPACK -I../include
> -c fftw.c
> > fftw.c(27449): warning #188: enumerated type mixed with another type
> > EXPECT_INT(dir);
> > ^
> >
> > fftw.c(27450): warning #188: enumerated type mixed with another type
> > EXPECT_INT(type);
> > ^
> >
> > mpif90 -O2 -assume byterecl -g -traceback -par-report0 -vec-report0
> -nomodule -fpp -D__INTEL -D__FFTW3 -D__MPI -D__PARA -D__SCALAPACK
> -I../include -I../iotk/src -I. -c fft_scalar.f90
> > mpif90 -O2 -assume byterecl -g -traceback -par-report0 -vec-report0
> -nomodule -fpp -D__INTEL -D__FFTW3 -D__MPI -D__PARA -D__SCALAPACK
> -I../include -I../iotk/src -I. -c fft_parallel.f90
> > mpif90 -O2 -assume byterecl -g -traceback -par-report0 -vec-report0
> -nomodule -fpp -D__INTEL -D__FFTW3 -D__MPI -D__PARA -D__SCALAPACK
> -I../include -I../iotk/src -I. -c fft_smallbox.f90
> > mpif90 -O2 -assume byterecl -g -traceback -par-report0 -vec-report0
> -nomodule -fpp -D__INTEL -D__FFTW3 -D__MPI -D__PARA -D__SCALAPACK
> -I../include -I../iotk/src -I. -c fft_interfaces.f90
> > mpif90 -O2 -assume byterecl -g -traceback -par-report0 -vec-report0
> -nomodule -fpp -D__INTEL -D__FFTW3 -D__MPI -D__PARA -D__SCALAPACK
> -I../include -I../iotk/src -I. -c stick_base.f90
> > stick_base.f90(169): error #6404: This name does not have a type, and
> must have an explicit type. [MPI_IN_PLACE]
> > CALL MPI_ALLREDUCE(MPI_IN_PLACE, st, SIZE(st), MPI_INTEGER, MPI_SUM,
> comm, ierr)
> > -^
> > compilation aborted for stick_base.f90 (code 1)
> > make[1]: *** [stick_base.o] Error 1
> > make[1]: Leaving directory
> `/nethome/metalian/espresso/espresso-5.3.0/FFTXlib'
> > make: *** [libfft] Error 1
> > 
> >

Re: [Pw_forum] compiling QE: fftw problems

2016-01-19 Thread Denis E . Zavelev
 Hello Filippo!

Thanks for your quick response.
I use MVAPICH-1.2rc1, it's the only available MPI on JSC cluster and I am not 
allowed to use any other MPI implementations.
I've sent you the files you asked.


>Среда, 20 января 2016, 0:45 +08:00 от Filippo SPIGA 
>:
>
>Dear Denis,
>
>are you using OpenMPI or Intel MPI?
>
>If Open MPI, try also 
>
>./configure MPIF90=mpiifort ...
>
>
>If Intel MPI (I assume this is your case), try instead 
>
>./configure MPIF90=mpiifort ... --with-scalapack=intel
>
>
>In the meanwhile please send me personally (not to the mailing-list!)  to my 
>email the "install/config.log" file and your make.sys.
>
>Regards
>
>--
>Mr. Filippo SPIGA, M.Sc.
>Quantum ESPRESSO Foundation
>http://www.quantum-espresso.org ~ skype: filippo.spiga
>
>*
>Disclaimer: "Please note this message and any attachments are CONFIDENTIAL and 
>may be privileged or otherwise protected from disclosure. The contents are not 
>to be disclosed to anyone other than the addressee. Unauthorized recipients 
>are requested to preserve this confidentiality and to advise the sender 
>immediately of any error in transmission."
>
>On Jan 20, 2016, at 12:20 AM, Denis E. Zavelev < metal...@mail.ru > wrote:
>> Hello!
>> 
>> I am trying to compile QE on JSC RAS cluster. As I have user permissions, I 
>> can install any programs only locally.
>> Cluster works under Linux. We have intel compilers (mpif90, icc, ifort) and 
>> MKL installed on cluster. No FFTW libraries are installed though even MKL 
>> ones (I have to build them locally). 
>> 
>> I've downloaded espresso 5.3.0 from the site. 
>> Configure script finished successfully. But then I got 2 warnings and 
>> subsequent error message when compiling internal FFT.
>> 
>> I decided to use some other FFT libs.
>> So I've downloaded FFTW3 from its site, successfully built, tested and 
>> installed it. But the same error message. 
>> 
>> Libraries found by configure script:
>>  BLAS_LIBS=  -lmkl_intel_lp64  -lmkl_sequential -lmkl_core
>>  LAPACK_LIBS=
>>  SCALAPACK_LIBS=-lmkl_scalapack_lp64 -lmkl_blacs_openmpi_lp64
>>  FFT_LIBS= -lfftw3 
>> 
>> Here's the output:
>> 
>> 
>> bash-3.2$ make pw
>> make: Warning: File `make.sys' has modification time 0.47 s in the future
>> test -d bin || mkdir bin
>> ( cd FFTXlib ; make TLDEPS= all || exit 1 )
>> make[1]: Entering directory 
>> `/nethome/metalian/espresso/espresso-5.3.0/FFTXlib'
>> make[1]: Warning: File `../make.sys' has modification time 0.46 s in the 
>> future
>> mpif90 -O2 -assume byterecl -g -traceback -par-report0 -vec-report0 
>> -nomodule -fpp -D__INTEL -D__FFTW3 -D__MPI -D__PARA -D__SCALAPACK   
>> -I../include -I../iotk/src -I. -c fft_types.f90
>> mpif90 -O2 -assume byterecl -g -traceback -par-report0 -vec-report0 
>> -nomodule -fpp -D__INTEL -D__FFTW3 -D__MPI -D__PARA -D__SCALAPACK   
>> -I../include -I../iotk/src -I. -c scatter_mod.f90
>> icc -O3 -D__INTEL -D__FFTW3 -D__MPI -D__PARA -D__SCALAPACK  -I../include  -c 
>> fftw.c
>> fftw.c(27449): warning #188: enumerated type mixed with another type
>>  EXPECT_INT(dir);
>>  ^
>> 
>> fftw.c(27450): warning #188: enumerated type mixed with another type
>>  EXPECT_INT(type);
>>  ^
>> 
>> mpif90 -O2 -assume byterecl -g -traceback -par-report0 -vec-report0 
>> -nomodule -fpp -D__INTEL -D__FFTW3 -D__MPI -D__PARA -D__SCALAPACK   
>> -I../include -I../iotk/src -I. -c fft_scalar.f90
>> mpif90 -O2 -assume byterecl -g -traceback -par-report0 -vec-report0 
>> -nomodule -fpp -D__INTEL -D__FFTW3 -D__MPI -D__PARA -D__SCALAPACK   
>> -I../include -I../iotk/src -I. -c fft_parallel.f90
>> mpif90 -O2 -assume byterecl -g -traceback -par-report0 -vec-report0 
>> -nomodule -fpp -D__INTEL -D__FFTW3 -D__MPI -D__PARA -D__SCALAPACK   
>> -I../include -I../iotk/src -I. -c fft_smallbox.f90
>> mpif90 -O2 -assume byterecl -g -traceback -par-report0 -vec-report0 
>> -nomodule -fpp -D__INTEL -D__FFTW3 -D__MPI -D__PARA -D__SCALAPACK   
>> -I../include -I../iotk/src -I. -c fft_interfaces.f90
>> mpif90 -O2 -assume byterecl -g -traceback -par-report0 -vec-report0 
>> -nomodule -fpp -D__INTEL -D__FFTW3 -D__MPI -D__PARA -D__SCALAPACK   
>> -I../include -I../iotk/src -I. -c stick_base.f90
>> stick_base.f90(169): error #6404: This name does not have a type, and must 
>> have an explicit type.   [MPI_IN_PLACE]
>>  CALL MPI_ALLREDUCE(MPI_IN_PLACE, st, SIZE(st), MPI_INTEGER, 
>> MPI_SUM, comm, ierr)
>> -^
>> compilation aborted for stick_base.f90 (code 1)
>> make[1]: *** [stick_base.o] Error 1
>> make[1]: Leaving directory 
>> `/nethome/metalian/espresso/espresso-5.3.0/FFTXlib'
>> make: *** [libfft] Error 1
>> 
>> 
>> I've also tries espresso 5.2.1. Configure works the same way, but 
>> compilation also fails though not so fast, it ends on the following:
>> 
>> fft_scalar.f90(69): #error: can't find include file: fftw3.f
>> make[1]: *** [fft_scalar.o] Error 1
>> make[1]: Leaving direc

Re: [Pw_forum] compiling QE: fftw problems

2016-01-19 Thread Filippo SPIGA
Dear Denis,

are you using OpenMPI or Intel MPI?

If Open MPI, try also 

./configure MPIF90=mpiifort ...


If Intel MPI (I assume this is your case), try instead 

./configure MPIF90=mpiifort ... --with-scalapack=intel


In the meanwhile please send me personally (not to the mailing-list!)  to my 
email the "install/config.log" file and your make.sys.

Regards

--
Mr. Filippo SPIGA, M.Sc.
Quantum ESPRESSO Foundation
http://www.quantum-espresso.org ~ skype: filippo.spiga

*
Disclaimer: "Please note this message and any attachments are CONFIDENTIAL and 
may be privileged or otherwise protected from disclosure. The contents are not 
to be disclosed to anyone other than the addressee. Unauthorized recipients are 
requested to preserve this confidentiality and to advise the sender immediately 
of any error in transmission."

On Jan 20, 2016, at 12:20 AM, Denis E. Zavelev  wrote:
> Hello!
> 
> I am trying to compile QE on JSC RAS cluster. As I have user permissions, I 
> can install any programs only locally.
> Cluster works under Linux. We have intel compilers (mpif90, icc, ifort) and 
> MKL installed on cluster. No FFTW libraries are installed though even MKL 
> ones (I have to build them locally). 
> 
> I've downloaded espresso 5.3.0 from the site. 
> Configure script finished successfully. But then I got 2 warnings and 
> subsequent error message when compiling internal FFT.
> 
> I decided to use some other FFT libs.
> So I've downloaded FFTW3 from its site, successfully built, tested and 
> installed it. But the same error message. 
> 
> Libraries found by configure script:
>  BLAS_LIBS=  -lmkl_intel_lp64  -lmkl_sequential -lmkl_core
>  LAPACK_LIBS=
>  SCALAPACK_LIBS=-lmkl_scalapack_lp64 -lmkl_blacs_openmpi_lp64
>  FFT_LIBS= -lfftw3 
> 
> Here's the output:
> 
> 
> bash-3.2$ make pw
> make: Warning: File `make.sys' has modification time 0.47 s in the future
> test -d bin || mkdir bin
> ( cd FFTXlib ; make TLDEPS= all || exit 1 )
> make[1]: Entering directory 
> `/nethome/metalian/espresso/espresso-5.3.0/FFTXlib'
> make[1]: Warning: File `../make.sys' has modification time 0.46 s in the 
> future
> mpif90 -O2 -assume byterecl -g -traceback -par-report0 -vec-report0 -nomodule 
> -fpp -D__INTEL -D__FFTW3 -D__MPI -D__PARA -D__SCALAPACK   -I../include 
> -I../iotk/src -I. -c fft_types.f90
> mpif90 -O2 -assume byterecl -g -traceback -par-report0 -vec-report0 -nomodule 
> -fpp -D__INTEL -D__FFTW3 -D__MPI -D__PARA -D__SCALAPACK   -I../include 
> -I../iotk/src -I. -c scatter_mod.f90
> icc -O3 -D__INTEL -D__FFTW3 -D__MPI -D__PARA -D__SCALAPACK  -I../include  -c 
> fftw.c
> fftw.c(27449): warning #188: enumerated type mixed with another type
>  EXPECT_INT(dir);
>  ^
> 
> fftw.c(27450): warning #188: enumerated type mixed with another type
>  EXPECT_INT(type);
>  ^
> 
> mpif90 -O2 -assume byterecl -g -traceback -par-report0 -vec-report0 -nomodule 
> -fpp -D__INTEL -D__FFTW3 -D__MPI -D__PARA -D__SCALAPACK   -I../include 
> -I../iotk/src -I. -c fft_scalar.f90
> mpif90 -O2 -assume byterecl -g -traceback -par-report0 -vec-report0 -nomodule 
> -fpp -D__INTEL -D__FFTW3 -D__MPI -D__PARA -D__SCALAPACK   -I../include 
> -I../iotk/src -I. -c fft_parallel.f90
> mpif90 -O2 -assume byterecl -g -traceback -par-report0 -vec-report0 -nomodule 
> -fpp -D__INTEL -D__FFTW3 -D__MPI -D__PARA -D__SCALAPACK   -I../include 
> -I../iotk/src -I. -c fft_smallbox.f90
> mpif90 -O2 -assume byterecl -g -traceback -par-report0 -vec-report0 -nomodule 
> -fpp -D__INTEL -D__FFTW3 -D__MPI -D__PARA -D__SCALAPACK   -I../include 
> -I../iotk/src -I. -c fft_interfaces.f90
> mpif90 -O2 -assume byterecl -g -traceback -par-report0 -vec-report0 -nomodule 
> -fpp -D__INTEL -D__FFTW3 -D__MPI -D__PARA -D__SCALAPACK   -I../include 
> -I../iotk/src -I. -c stick_base.f90
> stick_base.f90(169): error #6404: This name does not have a type, and must 
> have an explicit type.   [MPI_IN_PLACE]
>  CALL MPI_ALLREDUCE(MPI_IN_PLACE, st, SIZE(st), MPI_INTEGER, MPI_SUM, 
> comm, ierr)
> -^
> compilation aborted for stick_base.f90 (code 1)
> make[1]: *** [stick_base.o] Error 1
> make[1]: Leaving directory `/nethome/metalian/espresso/espresso-5.3.0/FFTXlib'
> make: *** [libfft] Error 1
> 
> 
> I've also tries espresso 5.2.1. Configure works the same way, but compilation 
> also fails though not so fast, it ends on the following:
> 
> fft_scalar.f90(69): #error: can't find include file: fftw3.f
> make[1]: *** [fft_scalar.o] Error 1
> make[1]: Leaving directory `/nethome/metalian/espresso/espresso-5.2.1/Modules'
> make: *** [mods] Error 1
> 
> This is strange because
> -sh-3.2$ ls /nethome/metalian/soft/include/
> fftw3.f  fftw3.f03  fftw3.h  fftw3l.f03  fftw3q.f03
> 
> -sh-3.2$ export
> export C_INCLUDE_PATH="/nethome/metalian/soft/include"
> export 
> INCLUDE="/nethome/metalian/soft/include:/opt/intel/composerxe-2011.3.174/mkl/include:/opt/intel/composer

[Pw_forum] compiling QE: fftw problems

2016-01-19 Thread Denis E . Zavelev
Hello!

I am trying to compile QE on JSC RAS cluster. As I have user permissions, I can 
install any programs only locally.
Cluster works under Linux. We have intel compilers (mpif90, icc, ifort) and MKL 
installed on cluster. No FFTW libraries are installed though even MKL ones (I 
have to build them locally). 

I've downloaded espresso 5.3.0 from the site. 
Configure script finished successfully. But then I got 2 warnings and 
subsequent error message when compiling internal FFT.

I decided to use some other FFT libs.
So I've downloaded FFTW3 from its site, successfully built, tested and 
installed it. But the same error message. 

Libraries found by configure script:
  BLAS_LIBS=  -lmkl_intel_lp64  -lmkl_sequential -lmkl_core
  LAPACK_LIBS=
  SCALAPACK_LIBS=-lmkl_scalapack_lp64 -lmkl_blacs_openmpi_lp64
  FFT_LIBS= -lfftw3 

Here's the output:


bash-3.2$ make pw
make: Warning: File `make.sys' has modification time 0.47 s in the future
test -d bin || mkdir bin
( cd FFTXlib ; make TLDEPS= all || exit 1 )
make[1]: Entering directory `/nethome/metalian/espresso/espresso-5.3.0/FFTXlib'
make[1]: Warning: File `../make.sys' has modification time 0.46 s in the future
mpif90 -O2 -assume byterecl -g -traceback -par-report0 -vec-report0 -nomodule 
-fpp -D__INTEL -D__FFTW3 -D__MPI -D__PARA -D__SCALAPACK   -I../include 
-I../iotk/src -I. -c fft_types.f90
mpif90 -O2 -assume byterecl -g -traceback -par-report0 -vec-report0 -nomodule 
-fpp -D__INTEL -D__FFTW3 -D__MPI -D__PARA -D__SCALAPACK   -I../include 
-I../iotk/src -I. -c scatter_mod.f90
icc -O3 -D__INTEL -D__FFTW3 -D__MPI -D__PARA -D__SCALAPACK  -I../include  -c 
fftw.c
fftw.c(27449): warning #188: enumerated type mixed with another type
  EXPECT_INT(dir);
  ^

fftw.c(27450): warning #188: enumerated type mixed with another type
  EXPECT_INT(type);
  ^

mpif90 -O2 -assume byterecl -g -traceback -par-report0 -vec-report0 -nomodule 
-fpp -D__INTEL -D__FFTW3 -D__MPI -D__PARA -D__SCALAPACK   -I../include 
-I../iotk/src -I. -c fft_scalar.f90
mpif90 -O2 -assume byterecl -g -traceback -par-report0 -vec-report0 -nomodule 
-fpp -D__INTEL -D__FFTW3 -D__MPI -D__PARA -D__SCALAPACK   -I../include 
-I../iotk/src -I. -c fft_parallel.f90
mpif90 -O2 -assume byterecl -g -traceback -par-report0 -vec-report0 -nomodule 
-fpp -D__INTEL -D__FFTW3 -D__MPI -D__PARA -D__SCALAPACK   -I../include 
-I../iotk/src -I. -c fft_smallbox.f90
mpif90 -O2 -assume byterecl -g -traceback -par-report0 -vec-report0 -nomodule 
-fpp -D__INTEL -D__FFTW3 -D__MPI -D__PARA -D__SCALAPACK   -I../include 
-I../iotk/src -I. -c fft_interfaces.f90
mpif90 -O2 -assume byterecl -g -traceback -par-report0 -vec-report0 -nomodule 
-fpp -D__INTEL -D__FFTW3 -D__MPI -D__PARA -D__SCALAPACK   -I../include 
-I../iotk/src -I. -c stick_base.f90
stick_base.f90(169): error #6404: This name does not have a type, and must have 
an explicit type.   [MPI_IN_PLACE]
  CALL MPI_ALLREDUCE(MPI_IN_PLACE, st, SIZE(st), MPI_INTEGER, MPI_SUM, 
comm, ierr)
-^
compilation aborted for stick_base.f90 (code 1)
make[1]: *** [stick_base.o] Error 1
make[1]: Leaving directory `/nethome/metalian/espresso/espresso-5.3.0/FFTXlib'
make: *** [libfft] Error 1


I've also tries espresso 5.2.1. Configure works the same way, but compilation 
also fails though not so fast, it ends on the following:

fft_scalar.f90(69): #error: can't find include file: fftw3.f
make[1]: *** [fft_scalar.o] Error 1
make[1]: Leaving directory `/nethome/metalian/espresso/espresso-5.2.1/Modules'
make: *** [mods] Error 1

This is strange because
-sh-3.2$ ls /nethome/metalian/soft/include/
fftw3.f  fftw3.f03  fftw3.h  fftw3l.f03  fftw3q.f03

-sh-3.2$ export
export C_INCLUDE_PATH="/nethome/metalian/soft/include"
export 
INCLUDE="/nethome/metalian/soft/include:/opt/intel/composerxe-2011.3.174/mkl/include:/opt/intel/composerxe-2011.3.174/mkl/include"

[I've mentioned only environment variables dealing with including]


So what am I doing wrong?
Are there any experienced users of Quantum Expresso on JSC cluster?



Best regards,
Denis E. Zavelev

___
Pw_forum mailing list
Pw_forum@pwscf.org
http://pwscf.org/mailman/listinfo/pw_forum


Re: [Pw_forum] gipaw impossible value for nrc [SOLVED]

2016-01-19 Thread Tiana Davide
Dear Ari 
Thanks for helping, The pseudo contained the GIPAW reconstruction data

After some research I found an that the problem was related to how they've been 
created. 
the &test namelist has to be added as explained in an old post here on PW FORUM 


Wed Apr 22 14:37:37 CEST 2009

The problem is quite complicated, but the resolution is simple: you have  
to explicitly specify the &test namelist when generating a pseudopotential  
with GIPAW data, otherwise if you have a "local" channel it won't be  
stored correctly in the GIPAW section of the UPF file.


Best
Davide 

--

Message: 9
Date: Mon, 18 Jan 2016 14:19:26 +
From: Tiana Davide 
Subject: [Pw_forum] gipaw impossible value for nrc
To: "pw_forum@pwscf.org" 
Message-ID: <1453126759581.28...@epfl.ch>
Content-Type: text/plain; charset="iso-8859-1"

Dear all

Running gipaw  I obtained this error:


 Error in routine init_gipaw_1 (1):
 impossible value for nrc


I tried having a look at the source finding it is related to this part of the 
code

! Rescale the wavefunctions so that int_0^rc f|psi|^2=1

but unfortunately I can't understand why my wavefunction is not good.

This was my scf input (the reason why KPOINT is 1 1 1 instead of gamma is 
because gipaw can't run at gamma point only)

 &control
calculation='scf',
title='test',
prefix='test'
wf_collect=.true.
 /
 &system
   ibrav=0,
   nat=108,
   ntyp=4,
   ecutwfc=90.0,
   vdw_corr='grimme-d2'
   london_s6=0.75,
   london_rcut=200,
   occupations='smearing',
   nbnd=360
   smearing='mv',
   degauss=0.05,
   nosym = .true.
 /
 &electrons
   conv_thr=1.0d-9,
   mixing_mode='local-TF',
   mixing_beta=0.6,
   mixing_ndim=18,
   mixing_fixed_ns=0,
   diagonalization='david',
 /
ATOMIC_SPECIES
Zn 65.39 Zn.pbesol-nc.UPF
C 12.01  C.pbesol-nc.UPF
O 15.999 O.pbesol-nc.UPF
H  1.0   H.pbesol-n-nc.UPF
CELL_PARAMETERS (angstrom)
  12.864276970   0.001769566  -0.78626
  -2.150683724  13.146919645   0.003767210
  -2.138950926  -6.566647256  11.386346215
ATOMIC_POSITIONS()


KPOINTS(automatic)
1 1 1 0 0 0

Message: 11
Date: Mon, 18 Jan 2016 15:26:17 +0100 (CET)
From: Ari P Seitsonen 
Subject: Re: [Pw_forum] gipaw impossible value for nrc
To: PWSCF Forum 
Message-ID: 
Content-Type: text/plain; charset="iso-8859-15"


Dear Tiana, [Please add your name & affiliation in your next mail]

   Are you sure that your UPF pseudo potentials include the GIPAW
reconstruction data? The error message sounds like if this is not the
case, but I might be wrong. [ Davide...? ;) ]

 Greetings,

apsi

-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-
   Ari Paavo Seitsonen / ari.p.seitso...@iki.fi / http://www.iki.fi/~apsi/
 Ecole Normale Sup?rieure (ENS), D?partement de Chimie, Paris
 Mobile (F) : +33 789 37 24 25(CH) : +41 79 71 90 935



___
Pw_forum mailing list
Pw_forum@pwscf.org
http://pwscf.org/mailman/listinfo/pw_forum


[Pw_forum] Oxidation state for dopants in TiO2

2016-01-19 Thread Giacomo Rossi
Dear QE users,

Studyng some Vanadium substitutional defects in a TiO2 matrix I have obtained 
the cluster configuration using the vc-relax procedure. After that, I plotted 
the charge density around the defect. I found that charge density around 
Vanadium is higher than the one near Ti in non doped cluster. Considering that 
V has one electron more than Ti, can I say that that the oxidation state of 
vanadium is the same of Ti (4+) and that the V electron is confined near its 
nucleus? Are there examples where the excess electron of a dopant are yeld to 
the TiO2 matrix instead of being confined around the dopant?


Best regards,

Giacomo Rossi,
P.h.d student from
Department of Physics and Astronomy, Bologna University,
Bologna, Italy.

___
Pw_forum mailing list
Pw_forum@pwscf.org
http://pwscf.org/mailman/listinfo/pw_forum


[Pw_forum] Error in routine punch_band_2d (1): Problems with k points

2016-01-19 Thread Youssef Aharbil
Dear all,

I am studying a double perovskite band structure under a trigonal crystal
system (ibrav = 5), the Brillouin zone sampling has been performed using
this path:

K_POINTS tpiba_b
11
gG 25
L  25
B1 1
B  25
Z  25
gG 25
X  1
Q 25
F 25
P1 25
Z  1
L  25
P 1

all calculations run well, till the stage of the extraction of bands using
bands.x, I got this error while plot_2D = .true.

 %%
 Error in routine punch_band_2d (1):
 Problems with k points
 %%

 stopping ...

The problem disappear when plot_2D = .false..

This error has been already posted in a previous thread, Prof Paolo
suggested to check these conditions (from bands.f90) :

!  This routine opens a file for each band and writes on output
!  kx, ky, energy,
!  kx, ky, energy
!  .., .., ..
!  where kx and ky are proportional to the length
!  of the vectors k_1 and k_2 specified in the input of the 2d plot.
!
!  The k points are supposed to be in the form
!  xk(i,j) = xk_0 + dkx *(i-1) + dky * (j-1)  1___
Pw_forum mailing list
Pw_forum@pwscf.org
http://pwscf.org/mailman/listinfo/pw_forum

[Pw_forum] Reg: How to get mode dependent lamda and phonon line width (gamma)

2016-01-19 Thread Peram sreenivasa reddy
Dear Forum,


I can able to calculate the lamda value for total dispersion using
lambda.x. But i need to calculate mode dependent lambda value and mode
dependent phonon line width.
I have small confusion, In elph file i can find lambda value and gamma
value. Can i separate these values manually and plot like as phonon
dispersion. Is this way will give fine result or not. Or is there any other
way?

Any suggestion can be acceptable ...


Thanking you ...



-- 
*P.V.SREENIVASA REDDY*

*Research ScholarDepartment of Physics *
*Indian Institute of Technology*
*Hyderabad*
___
Pw_forum mailing list
Pw_forum@pwscf.org
http://pwscf.org/mailman/listinfo/pw_forum

Re: [Pw_forum] ISSUES WITH BANDS CALCULATION

2016-01-19 Thread omamuyovwiak...@yahoo.com
The challenge has been  resolved just by increasing  nbnd from 4 to 8 as 
directed.
Thank you very much Sir. I appreciate all your responses.

Rita
University of Benin

Sent from Yahoo Mail on Android

___
Pw_forum mailing list
Pw_forum@pwscf.org
http://pwscf.org/mailman/listinfo/pw_forum

Re: [Pw_forum] ISSUES WITH BANDS CALCULATION

2016-01-19 Thread Giovanni Cantele
There are seven electrons in your unit cell (1 for Cs, 7 for Se), so by setting 
nbnd=4 you can just reproduce the three fully occupied bands and the one that 
is half-filled. If you need more bands, just increase nbnd in CsSe.nscf.*.in

Giovanni

> On 18 Jan 2016, at 21:48, Omamuyovwi Akemu  wrote:
> 
> Many many thanks Sir. I sincerely appreciate your comments.
> Attached to this mail are my inputs.
> Thank you again Sir.
> 
> Rita.
> University of Benin
> 
> 
> 
> From: "omamuyovwiak...@yahoo.com " 
> mailto:omamuyovwiak...@yahoo.com>>
> To: "pw_forum@pwscf.org "  > 
> Sent: Monday, January 18, 2016 1:28 PM
> Subject: Re: ISSUES WITH BANDS CALCULATION
> 
> I really appreciate your prompt reply Sir.
> The alloy actually displays half-metallic properties.
> I did not indicate nbnd in the 'scf' calculation but it was indicated in the 
> 'nscf' calculation.
> Rita.
> University of Benin
> Sent from Yahoo Mail on Android 
> 
> 
> From: omamuyovwiak...@yahoo.com ;  
> To: pw_forum@pwscf.org ;  
> Subject: ISSUES WITH BANDS CALCULATION  
> Sent: Mon, Jan 18, 2016 11:19:30 AM  
> 
> Dear QE users,
> Pls I encountered a challenge while trying to plot the band structure for a 
> binary alloy.
> I realize after using plotband.x interactively that the conduction bands(top 
> bands) were not present on the 
> plot. I increased the range but all no avail. I also discovered that 
> conduction bands isn't available on the band file as expected. It's been 
> impossible to get the band gap ( the difference between the valence and 
> conduction bands). 
> Pls I will sincerely appreciate any comment on what to do to fix this problem.
> Thank you.
> Jolayemi Omamuyovwi Rita(Mrs)
> Research Student
> Department of Physics
> University of Benin
> Nigeria.
> Sent from Yahoo Mail on Android 
> 
> 
> ___
> Pw_forum mailing list
> Pw_forum@pwscf.org 
> http://pwscf.org/mailman/listinfo/pw_forum 
> 
-- 

Giovanni Cantele, PhD
CNR-SPIN
c/o Dipartimento di Fisica
Universita' di Napoli "Federico II"
Complesso Universitario M. S. Angelo - Ed. 6
Via Cintia, I-80126, Napoli, Italy
e-mail: giovanni.cant...@spin.cnr.it
Phone: +39 081 676910
Skype contact: giocan74

ResearcherID: http://www.researcherid.com/rid/A-1951-2009
Web page: http://people.na.infn.it/~cantele

___
Pw_forum mailing list
Pw_forum@pwscf.org
http://pwscf.org/mailman/listinfo/pw_forum

Re: [Pw_forum] XCRYSDEN Primitive cell: Reg

2016-01-19 Thread Tone Kokalj
On Tue, 2016-01-19 at 13:48 +0530, Suresh A wrote:
> Dear All,
>     Herewith I have included two primitive cell input filefor anatase 
> strucutre. Between them XCRYSDEN shows correct structure for file one where 
> atomic positions are in angstrom unit and for another structure it shows 
> wrong strucutre where atomic positions are  in relative crystal coordinate. 
> Will you please point out where the problem is? And I am using 
> xcrysden-1.5.60-semishared linux 


Typically such problems stem from the following reason: the user and
the program have a different idea of the unit-cell. In particular,
there are two flavors of these problems:

(i) the crystallographic vectors are chosen differently between the
user and the program (in such cases specified Cartesian coordinates do
not give correct structure)

(ii) the crystallographic coordinates refers to different set of
vectors, e.g, primitive vs. conventional (in such cases the specified
crystal coordinates do not give the correct structure)

In your case it is the second problem. You have specified the crystal
coordinates with respect to conventional vectors, but the pw.x expects
the coordinates wrt primitive vectors (and consequently also xcrysden
interprets the QE input this way).

--
Excerpt from the pw.x documentation:
--
crystal : atomic positions are in crystal coordinates, i.e.
  in relative coordinates of the primitive lattice
  vectors as defined either in card CELL_PARAMETERS
  or via the ibrav + celldm / a,b,c... variables



Best regards, Tone

-- 
Anton Kokalj
J. Stefan Institute, Jamova 39, 1000 Ljubljana, Slovenia 
(tel: +386-1-477-3523 // fax:+386-1-477-3822)

Please, if possible, avoid sending me Word or PowerPoint attachments.
See:  http://www.gnu.org/philosophy/no-word-attachments.html


___
Pw_forum mailing list
Pw_forum@pwscf.org
http://pwscf.org/mailman/listinfo/pw_forum

[Pw_forum] XCRYSDEN Primitive cell: Reg

2016-01-19 Thread Suresh A
Dear All,
Herewith I have included two primitive cell input file for
anatase strucutre. Between them XCRYSDEN shows correct structure for file
one where atomic positions are in angstrom unit and for another structure
it shows wrong strucutre where atomic positions are  in relative crystal
coordinate. Will you please point out where the problem is? And I am using
xcrysden-1.5.60-semishared linux version.

input file1:

 &CONTROL
  title = 'TiO2' ,
calculation = 'scf',
 outdir ='$TMP_DIR/'
 prefix = 'anatase',
 pseudo_dir = '$PSEUDO_DIR/',
 /

 &SYSTEM
  ibrav = 7,
  celldm(1) = 7.1356,
  celldm(3) = 2.51218,
nat = 6 ,
   ntyp = 2 ,
ecutwfc = 30.00 ,
ecutrho = 300,


 /

 &ELECTRONS

   conv_thr = 1.0d-09,

 /
ATOMIC_SPECIES
 O  15.999  O.pw91-van_ak.UPF
 Ti 47.867  Ti.pw91-nsp-van.UPF
 ATOMIC_POSITIONS angstrom
 Ti   0.0   0.0   0.0
 Ti   0.0   1.88800   2.37150
 O0.0   0.0  -1.983097630
 O0.0   0.0   1.983097630
 O0.0   1.88800   0.387796645
 O0.0   1.88800   4.355203355
 K_POINTS   automatic
 4 4 4  0 0 0

INPUTFILE 2

 &CONTROL
   title = 'anatase' ,
 calculation = 'scf' ,
restart_mode = 'from_scratch' ,
  pseudo_dir = '/home/suresh/GN2/',
  outdir ='/home/suresh/Desktop/primitivecell/tmp/',
  prefix = 'anatase' ,
 tstress = .true. ,
 tprnfor = .true. ,



 /
 &SYSTEM
   ibrav = 7,
   celldm(1) = 7.153,
   celldm(3) = 2.513,
 nat = 6,
ntyp = 2,
 ecutwfc = 60 ,
exxdiv_treatment = 'none' ,



 /
 &ELECTRONS


 /
 &IONS


 /
 &CELL



 /
ATOMIC_SPECIES
   Ti   47.86700  Ti.pz-mt_fhi.UPF
O   15.99940  O.pz-mt_fhi.UPF
ATOMIC_POSITIONS (crystal)
Ti  0.000   0.000   0.000
Ti  0.000   0.500   0.250
O   0.000   0.000   0.208
O   0.000   0.000  -0.208000
O   0.000   0.500   0.458
O   0.000   0.500  -0.042000
K_POINTS automatic
4 4 2 1 1 1


  With Regards,
A.Suresh,
Research Scholar,
Madurai Kamaraj University,
Madurai.
___
Pw_forum mailing list
Pw_forum@pwscf.org
http://pwscf.org/mailman/listinfo/pw_forum