Re: [QE-users] Naming convention of PSlibrary pseudopotentials

[Andrea Dal Corso]

l is used in pslibrary to distinguish the PP with larger core radii.
It means lower accuracy.

Andrea




On Wed, 2020-10-07 at 13:45 +, 박민규 wrote:
> Dear all,
> 
> I have a small question.
> 
> For example Ga in PSlibrary table, there are two pseudopotentials
> that share almost identical name:
> Ga.rel-pbe-dn-kjpaw_psl.1.0.0.UPF
> Ga.rel-pbe-dnl-kjpaw_psl.1.0.0.UPF
> 
> I understand the meaning of “d" and “n” based on the explanation of
> QE website.
> https://www.quantum-espresso.org/pseudopotentials/naming-convention
> But there is no explanation about “l”.
> So can anyone explain the meaning of “l” in the second
> pseudopotential?
> 
> Best regards,
> 
> Minkyu Park
> Research Institute of Basic Sciences, University of Ulsan,
> 93, Daehak-ro, Nam-gu, Ulsan, 44610 Republic of Korea
> minkyup...@ulsan.ac.kr<mailto:minkyup...@ulsan.ac.kr>
> +82-52-259-1473
> 
> 
> ___
> Quantum ESPRESSO is supported by MaX (www.max-centre.eu)
> users mailing list users@lists.quantum-espresso.org
> https://lists.quantum-espresso.org/mailman/listinfo/users
-- 
Andrea Dal CorsoTel. 0039-040-3787428
SISSA, Via Bonomea 265  Fax. 0039-040-3787249
I-34136 Trieste (Italy) e-mail: dalco...@sissa.it

___
Quantum ESPRESSO is supported by MaX (www.max-centre.eu)
users mailing list users@lists.quantum-espresso.org
https://lists.quantum-espresso.org/mailman/listinfo/users

Re: [QE-users] Elastic properties using thermo_pw

[Andrea Dal Corso]

There are tutorial, examples and the user's guide with these
information.
Please read these before starting big calculations.
Note that the computation of temperature dependent elastic constant
requires a lot of computational resources and its implementation is
still work in progress.

Andrea


On Fri, 2020-08-21 at 21:38 +0530, Pooja Vyas wrote:
> Dear user,
> I want to compute elastic constants at various temperatures using
> thermo_pw. According to the user guide, I made three input files i.e
> one
> for pw.x (named it scf.in), second file named phonon_control and
> third file
> named thermo_control.
> 
> I first made a run using the following command,
> 
> mpirun -n np thermo_pw.x -ni ni ... < scf.in > scf.out
> 
> My query is, what is the next step or the next command that I should
> give/follow to compute elastic constants at various temperatures.
> 
> What about the use of phonon_control and thermo_control files? should
> I run the same command that is stated above again but this time with
> these two as input files?
> 
> Is the same command to be used for running all three files one by
> one?
> Any kind of help is appreciated.
> 
> Thanks and regards.
> ___
> Quantum ESPRESSO is supported by MaX (
> www.max-centre.eu/quantum-espresso)
> users mailing list users@lists.quantum-espresso.org
> https://lists.quantum-espresso.org/mailman/listinfo/users
-- 
Andrea Dal CorsoTel. 0039-040-3787428
SISSA, Via Bonomea 265  Fax. 0039-040-3787249
I-34136 Trieste (Italy) e-mail: dalco...@sissa.it

___
Quantum ESPRESSO is supported by MaX (www.max-centre.eu/quantum-espresso)
users mailing list users@lists.quantum-espresso.org
https://lists.quantum-espresso.org/mailman/listinfo/users

Re: [QE-users] Error in installing thermo_pw 1.2.1 with QE-6.5

[Andrea Dal Corso]

igt.f90
> voigt.f90:143:27:
> 
>   142 |DO ij=1,6
>   |2
>   143 |   CALL voigt_index(i,j,ij,.FALSE.)
>   |   1
> Error: Variable ‘ij’ at (1) not definable inside loop beginning at
> (2) as
> INTENT(INOUT) argument to subroutine ‘voigt_index’
> voigt.f90:145:30:
> 
>   144 |   DO mn=1,6
>   |   2
>   145 |  CALL voigt_index(m,n,mn,.FALSE.)
>   |  1
> Error: Variable ‘mn’ at (1) not definable inside loop beginning at
> (2) as
> INTENT(INOUT) argument to subroutine ‘voigt_index’
> voigt.f90:153:26:
> 
>   151 |DO i=1,3
>   |   2
>   152 |   DO j=1,3
>   153 |  CALL voigt_index(i,j,ij,.TRUE.)
>   |  1
> Error: Variable ‘i’ at (1) not definable inside loop beginning at (2)
> as
> INTENT(INOUT) argument to subroutine ‘voigt_index’
> voigt.f90:153:28:
> 
>   152 |   DO j=1,3
>   |  2
>   153 |  CALL voigt_index(i,j,ij,.TRUE.)
>   |1
> Error: Variable ‘j’ at (1) not definable inside loop beginning at (2)
> as
> INTENT(INOUT) argument to subroutine ‘voigt_index’
> voigt.f90:156:32:
> 
>   154 |  DO m=1,3
>   | 2
>   155 | DO n=1,3
>   156 |CALL voigt_index(m,n,mn,.TRUE.)
>   |1
> Error: Variable ‘m’ at (1) not definable inside loop beginning at (2)
> as
> INTENT(INOUT) argument to subroutine ‘voigt_index’
> voigt.f90:156:34:
> 
>   155 | DO n=1,3
>   |2
>   156 |CALL voigt_index(m,n,mn,.TRUE.)
>   |  1
> Error: Variable ‘n’ at (1) not definable inside loop beginning at (2)
> as
> INTENT(INOUT) argument to subroutine ‘voigt_index’
> voigt.f90:110:27:
> 
>   109 |DO ij=1,6
>   |2
>   110 |   CALL voigt_index(i,j,ij,.FALSE.)
>   |   1
> Error: Variable ‘ij’ at (1) not definable inside loop beginning at
> (2) as
> INTENT(INOUT) argument to subroutine ‘voigt_index’
> voigt.f90:117:26:
> 
>   115 |DO i=1,3
>   |   2
>   116 |   DO j=1,3
>   117 |  CALL voigt_index(i,j,ij,.TRUE.)
>   |  1
> Error: Variable ‘i’ at (1) not definable inside loop beginning at (2)
> as
> INTENT(INOUT) argument to subroutine ‘voigt_index’
> voigt.f90:117:28:
> 
>   116 |   DO j=1,3
>   |  2
>   117 |  CALL voigt_index(i,j,ij,.TRUE.)
>   |1
> Error: Variable ‘j’ at (1) not definable inside loop beginning at (2)
> as
> INTENT(INOUT) argument to subroutine ‘voigt_index’
> voigt.f90:77:27:
> 
>76 |DO ij=1,6
>   |2
>77 |   CALL voigt_index(i,j,ij,.FALSE.)
>   |   1
> Error: Variable ‘ij’ at (1) not definable inside loop beginning at
> (2) as
> INTENT(INOUT) argument to subroutine ‘voigt_index’
> voigt.f90:84:26:
> 
>82 |DO i=1,3
>   |   2
>83 |   DO j=1,3
>84 |  CALL voigt_index(i,j,ij,.TRUE.)
>   |  1
> Error: Variable ‘i’ at (1) not definable inside loop beginning at (2)
> as
> INTENT(INOUT) argument to subroutine ‘voigt_index’
> voigt.f90:84:28:
> 
>83 |   DO j=1,3
>   |  2
>84 |  CALL voigt_index(i,j,ij,.TRUE.)
>   |1
> Error: Variable ‘j’ at (1) not definable inside loop beginning at (2)
> as
> INTENT(INOUT) argument to subroutine ‘voigt_index’
> make[2]: *** [../../make.inc:16: voigt.o] Error 1
> make[2]: Leaving directory '/home/pooja/q-e-qe-6.5/thermo_pw/lib'
> make[1]: *** [Makefile:15: thermo_lib] Error 1
> make[1]: Leaving directory '/home/pooja/q-e-qe-6.5/thermo_pw'
> make: *** [Makefile:91: thermo_pw] Error 1
> 
> 
> Due to this error, thermo_pw.x executable is not created in bin
> folder. Can
> anyone let me know the reason of the error and a way to solve it?
> Thanks
> ___
> Quantum ESPRESSO is supported by MaX (
> www.max-centre.eu/quantum-espresso)
> users mailing list users@lists.quantum-espresso.org
> https://lists.quantum-espresso.org/mailman/listinfo/users
-- 
Andrea Dal CorsoTel. 0039-040-3787428
SISSA, Via Bonomea 265  Fax. 0039-040-3787249
I-34136 Trieste (Italy) e-mail: dalco...@sissa.it

___
Quantum ESPRESSO is supported by MaX (www.max-centre.eu/quantum-espresso)
users mailing list users@lists.quantum-espresso.org
https://lists.quantum-espresso.org/mailman/listinfo/users

Re: [QE-users] thermo_pw

[Andrea Dal Corso]

Please read the user's guide in thermo_pw/Doc. You can modify every 
quantity
that controls the temperature range: see tmin, tmax, deltat, ntemp in 
thermo_control.


Andrea



On 2020-03-03 07:12, Shiferaw Gadisa wrote:

Dear,

In themo_pw.x input

the range of temp tmin=1 tmax=800 , works by default.

but, if you want to add temp. in the input file use

NTEMP =  (by changing its number)

Shiferaw,

On Wed, Feb 19, 2020 at 7:53 AM Pooja Vyas
 wrote:


Dear users,
I want to calculate phonon dos for different lattice constants at
different temperatures using thermo_pw module of QE. Following is my
input:

_thermo
what='mur_lc_t',
lmurn=TRUE
nq1_d=128, nq2_d=128, nq3_d=128
ngeo=7
step_ngeo=0.5
tmin=1
tmax=800
deltat=3.
/

calculation = 'scf',
prefix = '${a}'
verbosity= 'high'
tstress= .true.
tprnfor= .true.
outdir = '/home/user/thermo/'
pseudo_dir = '/home/user/thermo/pseudo/'
/

ibrav =  2,
celldm(1) = $a,
nat =  2,
ntyp = 2,
ecutwfc = 100,
/

mixing_beta = 0.7
/

ATOMIC_SPECIES

Ca 40.078  Ca.pbe-nsp-van.UPF
O 15.999 O.pbe-van_ak.UPF

ATOMIC_POSITIONS
Ca 0.0 0.0 0.0
O 0.50 0.50 0.50

K_POINTS (automatic)
$NK $NK $NK 1 1 1
---
ciao

tr2_ph=1.0d-12,
prefix='${a}',
fildyn='${a}.dyn',
ldisp=.TRUE.
fildyn='${a}.dyn',
nq1=4, nq2=4, nq3=4,
/

fildyn='${a}.dyn',
zasr='simple',
flfrc='${a}.fc'
/

All this blocks are placed in a single input file. But when I try to
run, I face the following error:
./thermo_control: line 1: syntax error near unexpected token `&'
./thermo_control: line 1: `_thermo'

Can anyone explain, what is the issue and how do I solve it.

Thanks and regards.
___
Quantum ESPRESSO is supported by MaX
(www.max-centre.eu/quantum-espresso [1])
users mailing list users@lists.quantum-espresso.org
https://lists.quantum-espresso.org/mailman/listinfo/users



Links:
--
[1] http://www.max-centre.eu/quantum-espresso
___
Quantum ESPRESSO is supported by MaX 
(www.max-centre.eu/quantum-espresso)

users mailing list users@lists.quantum-espresso.org
https://lists.quantum-espresso.org/mailman/listinfo/users


--
Andrea Dal CorsoTel. 0039-040-3787428
SISSA, Via Bonomea 265  Fax. 0039-040-3787249
I-34136 Trieste (Italy) e-mail: dalco...@sissa.it


___
Quantum ESPRESSO is supported by MaX (www.max-centre.eu/quantum-espresso)
users mailing list users@lists.quantum-espresso.org
https://lists.quantum-espresso.org/mailman/listinfo/users

Re: [QE-users] Issue on LDA+U test calculation on Gd

[Andrea Dal Corso]

On Mon, 2020-02-10 at 16:21 +, Timrov Iurii wrote:
> Dear Giovanni,
> 
> 
> > I’ve browsed the PW/src/offset_atom_wfc.f90 routine. It seems (that
> > is what I have understood) that while in Modules/set_hubbard_l.f90
> > it is set
> 
> hubbard_l = 3  for that atomic species, in the pseudo potential file
> (see e.g. 
> http://www.quantum-espresso.org/upf_files/Gd.pbe-spdn-kjpaw_psl.1.0.0.UPF
> )
> the l=3 wave function is not found.
> > The atomic configuration of Gd is Xe 4f7 5d1 6s2.
> 
> 
> I would try to use the recommended pseudo from the SSSP library. For
> Gd, the recommended pseudo is from the Wentzcovitch library. I do not
> know if f electrons are included, though, one has to check.
> 
> 
> > i) it is sufficient to solve the problem or wrong to set hubbard_l
> > = 2 in Modules/set_hubbard_l.f90?
> > Should the Hubbard U be more important for those l=3 electronic
> > states than for l=2 states?
> 
> 4f and 5d channels are both partially occupied, so I presume that one
> should try to put U on both channels (but this is currently not
> possible in QE). So, by default the f channel is used for Gd in QE.
> It is not obvious (at least for me) though whether putting U on 5d
> would be important for Gd. One should investigate the PDOS and see
> where the contributions from 4f and 5d are located (at the LDA or GGA
> level), and on the basis of this information decide to which channel
> U should be applied.
> 
> > ii) more importantly (sorry for the basic question, I’v never
> > considered systems with f electrons): why f electrons are not
> > considered in the pseudo file?
> 
> You have chosen the PP which indeed does not contain the f states.
> But in the PSlibrary there are pseudos of Gd containing f electrons,
> so you can try those. It is better to ask Andrea Dal Corso why f
> states were not included in some versions of pseudos.
> 
The PPs of Lanthanides with f states in the core can be useful if you
are not interested in magnetic properties and for application were the
f occupation is not changing. They have been used sometimes in the
literature and are provided for those that are interested in these
cases.

Andrea

> Best regards,
> Iurii
> 
> 
> 
> --
> Dr. Iurii Timrov
> Postdoctoral Researcher
> STI - IMX - THEOS and NCCR - MARVEL
> Swiss Federal Institute of Technology Lausanne (EPFL)
> CH-1015 Lausanne, Switzerland
> +41 21 69 34 881
> http://people.epfl.ch/265334
> 
> From: users  on behalf of
> Giovanni Cantele 
> Sent: Monday, February 10, 2020 4:51:11 PM
> To: Quantum ESPRESSO users Forum
> Subject: [QE-users] Issue on LDA+U test calculation on Gd
> 
> Dear all,
> 
> I’m trying to make a test calculation of a crystal containing the Gd
> atom. I use the DFT+U scheme.
> However, as the program starts, I’ve immediately facing the following
> error:
> 
> %
> %
>  Error in routine offset_atom_wfc (2):
>  wrong offset
>  
> %%
> 
> 
> I’ve browsed the PW/src/offset_atom_wfc.f90 routine. It seems (that
> is what I have understood) that while in Modules/set_hubbard_l.f90 it
> is set
> hubbard_l = 3  for that atomic species, in the pseudo potential file
> (see e.g. 
> http://www.quantum-espresso.org/upf_files/Gd.pbe-spdn-kjpaw_psl.1.0.0.UPF
> )
> the l=3 wave function is not found.
> The atomic configuration of Gd is Xe 4f7 5d1 6s2.
> 
> So my question is:
> 
> i) it is sufficient to solve the problem or wrong to set hubbard_l =
> 2 in Modules/set_hubbard_l.f90?
> ii) more importantly (sorry for the basic question, I’v never
> considered systems with f electrons): why f electrons are not
> considered in the pseudo file?
> Should the Hubbard U be more important for those l=3 electronic
> states than for l=2 states?
> 
> Thanks for any answer you could provide.
> 
> Giovanni
> 
> 
> 
> --
> 
> 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 giovanni.cant...@spin.cnr.it>
> gcant...@gmail.com<mailto:gcant...@gmail.com>
> Phone: +39 081 676910
> Skype contact: giocan74
> Web page: https://sites.google.com/view/giovanni-cantele
> 
> ___
> Quantum ESPRESSO is supported by MaX (
> www.max-centre.eu/quantum-espresso)
> users mailing list users@lists.quantum-espre

Re: [QE-users] Error in routine read_namelists (5010):, reading namelist system

[Andrea Dal Corso]

Actually space group 33 has only 4a position that requires
all three x,y,z coordinates, so the list of wyckoff positions
does not contain any info on it.
This creates a problem when one gives both the wyckoff
letter and the x,y,z coordinates for this group. The easiest solution  
for the moment is to remove the 4d letter from the input which is  
wrong anyway, because it should be 4a.



Andrea


Quoting Thomas Brumme :


Dear Maxim,

please answer also to the list as others also might be able to help.
Maybe even better than me. Space group 33 is not implemented.
If you check the file 'Modules/wypos.f90' you'll see that the case
33 is missing. I have no idea why, but maybe there is an equivalent
space group? Another simple solution is to use the tools of the
Bilbao side:

http://www.cryst.ehu.es/cgi-bin/cryst/programs/mcif2vesta/index.php

Upload your cif and get the VASP output which you can easily use
as an input for QE.

Thomas


On 11/01/18 18:09, Максим Арсентьев wrote:

Dear Thomas,

I tried PWSCF v.5.4.0 and now the error is:

     Error in routine wypos (1):
     group not recognized

--
Best wishes,
Maxim Arsent'ev, Ph.D. (Chemistry)
Laboratory of research of nanostructures
Institute of Silicate Chemistry of RAS



--
Dr. rer. nat. Thomas Brumme
Wilhelm-Ostwald-Institute for Physical and Theoretical Chemistry
Leipzig University
Phillipp-Rosenthal-Strasse 31
04103 Leipzig

Tel:  +49 (0)341 97 36456

email: thomas.bru...@uni-leipzig.de




___
users mailing list
users@lists.quantum-espresso.org
https://lists.quantum-espresso.org/mailman/listinfo/users

Re: [QE-users] Problem with compiling thermo_pw (with QE 6.3)

[Andrea Dal Corso]

On Tue, 2018-07-31 at 14:28 +0900, Christoph Wolf wrote:
> Dear all,
> 
> after reading up on the possibility to calculate "bulk projected bands" I
> found that thermo_pw should be able to do this. However I am unable to
> compile the latest version with qe 6.3.
> 
> My ./configure log is attached. I can build the entire QE package (except
> yambo - that one never works out of the box) using intel MKL and compilers
> by issuing
> 
> *./configure --enable-shared  --enable-parallel  --with-scalapack=intel
> CC=mpicc  F77=mpif90   FC=mpif90*
> 
> (alternative mpifort seems to be working as well)
> 
> *The following libraries have been found:*
> *  BLAS_LIBS=  -lmkl_intel_lp64  -lmkl_intel_thread -lmkl_core*
> *  LAPACK_LIBS=*
> *  SCALAPACK_LIBS=-lmkl_scalapack_lp64 -lmkl_blacs_intelmpi_lp64*
> *
> FFT_LIBS=-L/opt/intel/compilers_and_libraries_2018.0.128/linux/mkl/intel64*
> 
> *Please check if this is what you expect.*
> 
> after patching thermo_pw into QE (make join_qe) make thermo_pw fails
> initially with a truncation error
> 
> *phdos_module.f90:392:132: Error: Line truncated at (1)
> [-Werror=line-truncation]*
> *f951: some warnings being treated as errors*
> 
Thank you for reporting this. There a problem in the git version of
thermo_pw at line 392 a \ should be &.


> which can be overcome by using  -ffree-line-length-none but then make fails
> again whilst looking for a module called wavefunctions_module.mod which,
> apparently does not exist in QE/Modules

Please note that the git version of thermo_pw is aligned with quantum
espresso 6.3, the official distributed version, not the git version of
q-e.
In quantum espresso 6.3 there is a file Module/wavefunctions.f90 that
contains wavefunction_module.

Andrea




> 
> *add_zstar_ue.f90:20:6:*
> 
> *   USE wavefunctions_module,  ONLY: evc*
> *  1*
> *Fatal Error: Can't open module file ‘wavefunctions_module.mod’ for reading
> at (1): No such file or directory*
> *compilation terminated.*
> *make[2]: *** [add_zstar_ue.o] Error 1*
> *make[1]: *** [thermo_qe] Error 1*
> *make: *** [thermo_pw] Error 1*
> 
> 
> Has anyone encountered (and overcome..) this problem? Any hint is greatly
> appreciated!
> 
> Best,
> Chris
> 
> _______
> users mailing list
> users@lists.quantum-espresso.org
> https://lists.quantum-espresso.org/mailman/listinfo/users

-- 
Andrea Dal CorsoTel. 0039-040-3787428
SISSA, Via Bonomea 265  Fax. 0039-040-3787249
I-34136 Trieste (Italy) e-mail: dalco...@sissa.it

___
users mailing list
users@lists.quantum-espresso.org
https://lists.quantum-espresso.org/mailman/listinfo/users

Re: [Pw_forum] ph.x nimage parallelization gives several blank output files

[Andrea Dal Corso]

Please check the image example. You need to recollect the results at the
end.

Andrea

On Mon, 2017-09-18 at 16:47 +0800, balabi wrote:
> Could someone please help pointing out what is wrong? I really
> appreciate it.
-- 
Andrea Dal CorsoTel. 0039-040-3787428
SISSA, Via Bonomea 265  Fax. 0039-040-3787249
I-34136 Trieste (Italy) e-mail: dalco...@sissa.it

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

Re: [Pw_forum] 答复: Problem in ph.x (Wrong classes for C_3v)

[Andrea Dal Corso]

This problem is almost invariably due to the use of single precision in
the number of digits of the atomic positions (see 1/3 2/3 below).
To continue the calculation you can disable the symmetry analysis of the
modes by using
search_sym=.FALSE.
in the ph.x input, or increase the number of digits in the atomic
positions.

HTH,

Andrea


On Wed, 2017-08-30 at 09:24 +, LEUNG Clarence wrote:
>   Cu   0.666073d0   0.333142d0   0.5000204705d0
>   Br   0.333927d0   0.666858d0   0.4999795295d0
> 
> 
-- 
Andrea Dal CorsoTel. 0039-040-3787428
SISSA, Via Bonomea 265  Fax. 0039-040-3787249
I-34136 Trieste (Italy) e-mail: dalco...@sissa.it


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

Re: [Pw_forum] crystal_sg in QE input reg

[Andrea Dal Corso]

6d is the generic position. You need to give all three coordinates, so
it is not necessary to treat it in a special way. The code should read
the label and discard it. 

HTH,

Andrea

On Wed, 2017-06-14 at 11:30 +0200, Giovanni Cantele wrote:
> I’m not very sure BUT it seems that, although position 6d is available for 
> Wyckoff Positions of Group 168 (P6), this is not listed in Modules/wypos.f90,
> where I can only find
> 
>  CASE (168) !P6
> IF (TRIM(wp)=='1a') THEN
>tau(1)=0.0_DP
>tau(2)=0.0_DP
>tau(3)=inp(1)
> ELSEIF (TRIM(wp)=='2b') THEN
>tau(1)=1.0_DP/3.0_DP
>tau(2)=2.0_DP/3.0_DP
>tau(3)=inp(1)
> ELSEIF (TRIM(wp)=='3c') THEN
>tau(1)=0.5_DP
>tau(2)=0.0_DP
>tau(3)=inp(1)
> ENDIF
> 
> so, only positions 1a, 2b and 3c seem to be possible. Maybe the people who 
> implemented that part of the code might be more helpful,
> in the meanwhile I would try to use, for example 
> Si 1a 0.1 
> just to be sure that the crystal_sg works, as it should do.
> 
> Giovanni
> 
> 
> > On 14 Jun 2017, at 09:37, Marco Di Gennaro <marco.digenn...@unibas.ch> 
> > wrote:
> > 
> > Hello,
> > 
> > thanks for your answer, my bad.
> > 
> > But I am still not able to get this to work properly,
> > I have now specified ibrav and celldim, but I still have this message:
> >>Message from routine wypos:
> >>wyckoff position not found, assuming x y z
> > 
> > So I wonder, what is the exact syntax for this? 
> > the code crashes shortly after:
> > 
> >>Estimated total allocated dynamical RAM >  88.60MB
> >>Initial potential from superposition of free atoms
> >>starting charge  131.98155, renormalised to  132.0
> >>Starting wfc are  132 randomized atomic wfcs
> >>Error in routine  cdiaghg (5):
> >> problems computing cholesky
> >>stopping ...  
> > 
> > Thanks again.
> > m.
> > ___________
> > 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

-- 
Andrea Dal CorsoTel. 0039-040-3787428
SISSA, Via Bonomea 265  Fax. 0039-040-3787249
I-34136 Trieste (Italy) e-mail: dalco...@sissa.it

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

Re: [Pw_forum] problem of Bi2Se3 with spin orbit coupling parity analysis at TRIM points

[Andrea Dal Corso]

I meant that in the NOSOC case the valence bands go from 11 to 24
(14 bands) and 6 have parity g while 8 have parity u.

In the SOC case the same valence bands goes from 21 to 48
and 14 are + and 14 are - meaning that 7 couples of degenerate bands  
are +  and 7 couples are -.

HTH,

Andrea



Quoting balabi :

> Dear Andrea,
>      Thank you very much for explanation. 
>      But I don't get it. What do you mean by 6g and 8u? Which lines do
> 6g and 8u ( also 7+ 7-)correspond to?
>      And I can not see why your argument can lead to different parity
> product for nosoc and  soc case.
>      I still don't know why my counting is wrong.
>
> best regards
>     
>      



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

Re: [Pw_forum] problem of Bi2Se3 with spin orbit coupling parity analysis at TRIM points

[Andrea Dal Corso]

e( 39 - 40) =  6.19631  eV 2   --> G_5-  L_4- 
>  e( 39 - 40) =  6.19631  eV 2   --> G_6-  L_5- 
>  e( 41 - 42) =  6.51310  eV 2   --> G_5+  L_4+ 
>  e( 41 - 42) =  6.51310  eV 2   --> G_6+  L_5+ 
>  e( 43 - 44) =  6.80580  eV 2   --> G_4-  L_6- 
>  e( 45 - 46) =  7.20470  eV 2   --> G_5-  L_4- 
>  e( 45 - 46) =  7.20470  eV 2   --> G_6-  L_5- 
>  e( 47 - 48) =  7.50637  eV 2   --> G_4+  L_6+ 
>  e( 49 - 50) =  8.05825  eV 2   --> G_4-  L_6- 
>  e( 51 - 52) =  9.1  eV 2   --> G_4+  L_6+ 
>  e( 53 - 54) =  9.27043  eV 2   --> G_4-  L_6- 
>  e( 55 - 56) =  9.86223  eV 2   --> G_5+  L_4+ 
>  e( 55 - 56) =  9.86223  eV 2   --> G_6+  L_5+ 
>  e( 57 - 58) = 11.09081  eV 2   --> G_4-  L_6- 
>  e( 59 - 60) = 11.46791  eV 2   --> G_5-  L_4- 
>  e( 59 - 60) = 11.46791  eV 2   --> G_6-  L_5- 
>  e( 61 - 62) = 13.77176  eV 2   --> G_4+  L_6+ 
>  e( 63 - 64) = 14.35855  eV 2   --> G_4-  L_6-  
> ___
> Pw_forum mailing list
> Pw_forum@pwscf.org
> http://pwscf.org/mailman/listinfo/pw_forum

-- 
Andrea Dal CorsoTel. 0039-040-3787428
SISSA, Via Bonomea 265  Fax. 0039-040-3787249
I-34136 Trieste (Italy) e-mail: dalco...@sissa.it



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

Re: [Pw_forum] problem of Bi2Se3 with spin orbit coupling parity analysis at TRIM points

[Andrea Dal Corso]

On Mon, 2017-05-29 at 19:31 +0800, balabi wrote:
> Thank you so much for reply.
> 
> 
> I thought nosym is just used for preventing additional k points to be
> generated. The documentation doesn't say that  nosym will make
> symmetry analysis fail.
> 
> 
> Besides, I rerun the calculation, turning off nosym. But There comes
> another problem.
> 
> 
> A partial output of bands.x now for gamma point is below
> 
> 
> Band symmetry, D_3d (-3m)  double point group:
> 
> 
>  e(  1 -  4) =-16.63750  eV 4   --> G_5+  L_4+ 
>  e(  1 -  4) =-16.63750  eV 4   --> G_6+  L_5+ 
>  e(  1 -  4) =-16.63750  eV 4   --> G_5-  L_4- 
>  e(  1 -  4) =-16.63750  eV 4   --> G_6-  L_5- 
>  e(  5 -  6) =-16.62527  eV 2   --> G_4+  L_6+ 
>  e(  7 -  8) =-16.62265  eV 2   --> G_4-  L_6- 
>  e(  9 - 10) =-13.66107  eV 2   --> G_4-  L_6- 
>  e( 11 - 12) =-13.65905  eV 2   --> G_4+  L_6+ 
>  e( 13 - 14) =-13.64175  eV 2   --> G_4+  L_6+ 
>  e( 15 - 16) =-13.63940  eV 2   --> G_5+  L_4+
> 
> 
The number is the degeneracy of the band. In this case there are four
degenerate bands and their symmetry is G_5+ + G_6+ + G_5- + G_6-. 
Sometimes the bands are more degenerate than predicted by group theory
due to time reversal (the additional degeneracy due to time reversal is
not analyzed by the routine). In other cases there might also be some
accidental degeneracy.
In any case the reducible representation is correctly decomposed in
terms of its irreducible representations. 

HTH,

Andrea

> Previously I thought the number right before the arrow means
> duplication of the same symmetry. But the above output make this
> assumption false. What does number 4 mean in " e(  1 -  4) =
>  -16.63750  eV 4   --> G_5+  L_4+"??
> And since the e(1-4) four bands each has different symmetry, why don't
> they write like this
> 
> 
> e(  1 -  1) =-16.63750  eV 1   --> G_5+  L_4+ 
> e(  2 -  2) =-16.63750  eV 1   --> G_6+  L_5+ 
> e(  3 -  3) =-16.63750  eV 1   --> G_5-  L_4- 
> e(  4 -  4) =-16.63750  eV 1   --> G_6-  L_5-  
> 
> 
> Thank you for helping
> 
> 
> 
> 
> 
> ___
> Pw_forum mailing list
> Pw_forum@pwscf.org
> http://pwscf.org/mailman/listinfo/pw_forum

-- 
Andrea Dal CorsoTel. 0039-040-3787428
SISSA, Via Bonomea 265  Fax. 0039-040-3787249
I-34136 Trieste (Italy) e-mail: dalco...@sissa.it

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

Re: [Pw_forum] problem of Bi2Se3 with spin orbit coupling parity analysis at TRIM points

[Andrea Dal Corso]

Quoting balabi :

> Dear developers,
>     previously, I send an email about symmetry analysis in calculating
> Bi2Se3 http://www.mail-archive.com/pw_forum@pwscf.org/msg31533.html
>     But I pasted the wrong input file in that email. The symmetry info in
> that post is generated for Bi2Se3 without spin orbit coupling.
>
>     Now, I calculated Bi2Se3 with spin orbit coupling. What I got is not
> right. There is no parity information labeled u and g.
>     Below is the output of bands.x for gamma point
>
> -
> xk=(   0.0,   0.0,   0.0  )
>
>      double point group C_1 (1)    
>      there are  2 classes and  1 irreducible representations
>      the character table:
>
>        E     -E   
>                   
> G_2    1.00 -1.00
>
>      the symmetry operations in each class and the name of the first
> element:
>
>      E             1
>                                                  
>                
>      -E           -1
>                                                  
>                
>
>      Band symmetry, C_1 (1)     double point group:
>
>      e(  1 -  4) =    -16.63750  eV     4   -->   4 G_2    
>        
>      e(  5 -  6) =    -16.62527  eV     2   -->   2 G_2    
>        
>      e(  7 -  8) =    -16.62265  eV     2   -->   2 G_2    
>        
>      e(  9 - 10) =    -13.66107  eV     2   -->   2 G_2      
>      
>      e( 11 - 12) =    -13.65905  eV     2   -->   2 G_2      
>      
>      e( 13 - 14) =    -13.64175  eV     2   -->   2 G_2      
>      
>      e( 15 - 16) =    -13.63940  eV     2   -->   2 G_2      
>      
>      e( 17 - 18) =    -13.63741  eV     2   -->   2 G_2      
>      
>      e( 19 - 20) =    -13.63672  eV     2   -->   2 G_2      
>      
>      e( 21 - 22) =     -6.40199  eV     2   -->   2 G_2      
>      
>      e( 23 - 24) =     -5.17683  eV     2   -->   2 G_2      
>      
>      e( 25 - 26) =     -5.15601  eV     2   -->   2 G_2      
>      
>      e( 27 - 28) =     -1.79777  eV     2   -->   2 G_2      
>      
>      e( 29 - 30) =     -1.02045  eV     2   -->   2 G_2      
>      
>      e( 31 - 32) =      5.18513  eV     2   -->   2 G_2      
>      
>      e( 33 - 34) =      5.40747  eV     2   -->   2 G_2      
>      
>      e( 35 - 36) =      6.03590  eV     2   -->   2 G_2      
>      
>      e( 37 - 38) =      6.14972  eV     2   -->   2 G_2      
>      
>      e( 39 - 40) =      6.19631  eV     2   -->   2 G_2      
>      
>      e( 41 - 42) =      6.51310  eV     2   -->   2 G_2      
>      
>      e( 43 - 44) =      6.80580  eV     2   -->   2 G_2      
>      
>      e( 45 - 46) =      7.20470  eV     2   -->   2 G_2      
>      
>      e( 47 - 48) =      7.50637  eV     2   -->   2 G_2      
>      
>      e( 49 - 50) =      8.05825  eV     2   -->   2 G_2      
>      
>      e( 51 - 52) =      9.1  eV     2   -->   2 G_2      
>      
>      e( 53 - 54) =      9.27043  eV     2   -->   2 G_2      
>      
>      e( 55 - 56) =      9.86223  eV     2   -->   2 G_2      
>      
>      e( 57 - 58) =     11.09081  eV     2   -->   2 G_2      
>      
>      e( 59 - 60) =     11.46791  eV     2   -->   2 G_2      
>      
>      e( 61 - 62) =     13.77176  eV     2   -->   2 G_2      
>      
>      e( 63 - 64) =     14.35855  eV     2   -->   2 G_2    
>
> --
>
> Is this right? There are no u and g like Bi2Se3 without SOC. How can I tell
> the parity? And the symmetry seems too simple.
>
> --
>
> below is my Bi2Se3 with SOC bands.in
>
> 
> prefix='Bi2Se3_SOC',
> calculation='bands',
> restart_mode='from_scratch',
> wf_collect=.true.,
> verbosity='high',
> outdir='./quantum_espresso/qe_tmpdir',
> pseudo_dir='./quantum_espresso/pseudo',
> /
> 
> ibrav = -5,celldm(1) =18.5969068371645,celldm(4)=0.9115970970052608,nat =
> 5,ntyp = 3,
> ecutwfc = 40,ecutrho = 500,
> noncolin=.true.,lspinorb=.true.,starting_magnetization=0.,
> nbnd=64,
> nosym=.true.,


nosym=.TRUE. means that no symmetry is used.

HTH,

Andrea


> /
> 
> conv_thr = 1.0d-10,  !default 1d-6
> diago_full_acc=.true.,!increase empty bands accuracy
> /
> ATOMIC_SPECIES
> Bi 208.98040  Bi.rel-pbe-dn-kjpaw_psl.0.2.2.UPF
> Se178.971Se.rel-pbe-n-kjpaw_psl.0.2.UPF
> Se278.971Se.rel-pbe-n-kjpaw_psl.0.2.UPF
> ATOMIC_POSITIONS crystal
> Bi0.39900.39900.3990
> Bi0.60100.60100.6010
> Se11.1.1.
> Se20.20600.20600.2060
> Se20.79400.79400.7940
> K_POINTS crystal_b
> 5
> 0.0      0.0      0.0     1 !gG
> 0.5      0.5      0.5     1 !Z
> 0.5      0.5     -0.0     1 !F
> 0.0      0.0      0.0     1 !gG
> 0.0      0.0     -0.5     1  !L1



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

Re: [Pw_forum] symmetry analysis in output of bands.x got a question mark for some band

[Andrea Dal Corso]

This is is not a bug. The symmetry analysis cannot be done if the
last wavefunction is a partner of a couple of degenerate bands,
and one of them has not been calculated.
If you need the symmetry label for that band you have to compute more bands.

Andrea


Quoting balabi :

> Dear developers,
>     I am calculating Bi2Se3, and I want to analyze the wave function
> parity on time reversal invariant momentum.
>
>     However I got some problem on k point Z
>
> xk=(   0.29758,   0.29758,   0.29758  )
>
>      Band symmetry, D_3d (-3m)  point group:
>
>      e(  1 -  2) =    -15.33381  eV     2   --> E_u  L_3'    
>  
>      e(  3 -  4) =    -15.33248  eV     2   --> E_g  L_3    
>   
>      e(  5 -  5) =    -15.32175  eV     1   --> A_1g L_1    
>   
>      e(  6 -  6) =    -15.31913  eV     1   --> A_2u L_2'    
>  
>      e(  7 -  8) =    -15.30954  eV     2   --> E_g  L_3    
>   
>      e(  9 - 10) =    -15.30659  eV     2   --> E_u  L_3'    
>  
>      e( 11 - 11) =     -6.45440  eV     1   --> A_1g L_1    
>   
>      e( 12 - 12) =     -5.91656  eV     1   --> A_2u L_2'      
>      e( 13 - 13) =     -4.53654  eV     1   --> A_1g L_1    
>   
>      e( 14 - 14) =     -2.62652  eV     1   --> A_2u L_2'      
>      e( 15 - 15) =     -0.80142  eV     1   --> A_1g L_1    
>   
>      e( 16 - 16) =      4.86845  eV     1   --> A_2u L_2'    
>  
>      e( 17 - 18) =      5.79799  eV     2   --> E_u  L_3'    
>  
>      e( 19 - 20) =      6.41406  eV     2   --> E_u  L_3'    
>  
>      e( 21 - 21) =      6.44464  eV     1   --> A_2u L_2'    
>  
>      e( 22 - 23) =      6.75173  eV     2   --> E_g  L_3    
>   
>      e( 24 - 24) =      7.00929  eV     1   --> A_1g L_1    
>   
>      e( 25 - 25) =      9.07355  eV     1   --> A_1g L_1    
>   
>      e( 26 - 27) =      9.43673  eV     2   --> E_g  L_3    
>   
>      e( 28 - 28) =      9.88292  eV     1   --> A_2u L_2'    
>  
>      e( 29 - 30) =     10.16254  eV     2   --> E_u  L_3'    
>  
>      e( 31 - 31) =     13.27098  eV     1   --> A_1g L_1    
>   
>      e( 32 - 32) =     14.41318  eV     1   -->   ?
>
> You can see the upper most band got "?" . Though I don't need parity of
> high energy band. But is this a bug?
>
> 
> Below is my bands.in file
>
> 
> prefix='Bi2Se3_SOC',
> calculation='bands',
> restart_mode='from_scratch',
> wf_collect=.true.,
> verbosity='high',
> outdir='/fs10/home/qhw_wang/HPC-nj/quantum_espresso/qe_tmpdir',
> pseudo_dir='/fs10/home/qhw_wang/HPC-nj/quantum_espresso/pseudo',
> /
> 
> ibrav = -5,celldm(1) =18.5969068371645,celldm(4)=0.9115970970052608,nat =
> 5,ntyp = 3,
> ecutwfc = 40,ecutrho = 500,
> noncolin=.true.,lspinorb=.true.,starting_magnetization=0.,
> nbnd=64,
> nosym=.true.,
> /
> 
> conv_thr = 1.0d-10,  !default 1d-6
> diago_full_acc=.true.,!increase empty bands accuracy
> /
> ATOMIC_SPECIES
> Bi 208.98040  Bi.rel-pbe-dn-kjpaw_psl.0.2.2.UPF
> Se178.971Se.rel-pbe-n-kjpaw_psl.0.2.UPF
> Se278.971Se.rel-pbe-n-kjpaw_psl.0.2.UPF
> ATOMIC_POSITIONS crystal
> Bi0.39900.39900.3990
> Bi0.60100.60100.6010
> Se11.1.1.
> Se20.20600.20600.2060
> Se20.79400.79400.7940
> K_POINTS crystal_b
> 5
> 0.0      0.0      0.0     1 !gG
> 0.5      0.5      0.5     1 !Z
> 0.5      0.5     -0.0     1 !F
> 0.0      0.0      0.0     1 !gG
> 0.0      0.0     -0.5     1  !L1



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

Re: [Pw_forum] high symmetry point missing in output of bands.x in

[Andrea Dal Corso]

On Thu, 2017-05-18 at 20:04 +0800, balabi wrote:
> 
> 
> Dear Andrea,
> 
> 
> Thank you so much for explanation. 
> 
> 
> gS-N-gS1 is indeed on the same line. 
> 
> 
> However, I don't understand your example of fcc. gG-K-X is not on the
> same line.  And I test it as below on diamond
> 
> 
> K_POINTS tpiba_b
> 3
> gG 20
> K 20
> X 1

In my example X was (1,1,0). The X that corresponds to the label is
(0,1,0). The two points are equivalent but to go from K to (0,1,0) the
path changes direction in K so the point K is shown. Going from K to
(1,1,0) the path does not change direction and K is not shown.


Andrea

> 
> the output of bands.x has 3 high-symmetry points. What is wrong?
> 
> 
> 
> ___
> Pw_forum mailing list
> Pw_forum@pwscf.org
> http://pwscf.org/mailman/listinfo/pw_forum

-- 
Andrea Dal CorsoTel. 0039-040-3787428
SISSA, Via Bonomea 265  Fax. 0039-040-3787249
I-34136 Trieste (Italy) e-mail: dalco...@sissa.it

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

Re: [Pw_forum] high symmetry point missing in output of bands.x in case of ibrav=7

[Andrea Dal Corso]

I don't think this is an error. The routine writes the coordinates of
the points when 
a) the path changes direction or
b) the small point group of k changes

None of the above occurs at N along the path gS-N-gS1, so the code
assumes this is one line gS-gS1, not two.
It is the same thing for an fcc lattice at the K point along the path 
gG-K (3/4,3/4,0) -X (1,1,0). K is not considered a high symmetry point
and only one line from gG to X is found, not two.
In the second case for the path gG-N-gS at N there is a change of the
path direction and the point is written on output.

HTH,

Andrea

On Wed, 2017-05-17 at 09:45 +0800, balabi wrote: 
> Dear developers:
> I am using QE6.1 and calculating TaAs right now. TaAs belongs to
> ibrav 7. According to "Points inside the Brillouin zone" pdf. I
> choosed gG-gS-N-gS1 path. But I found the output of bands.x contains
> only three high-symmetry points. The N point is missing
> 
> 
> high-symmetry point:  0. 0. 0.   x coordinate   0.
> high-symmetry point:  0.5435 0. 0.   x coordinate   0.5435
> high-symmetry point:  0.4565 0. 0.2951   x coordinate   0.8512
> 
> 
> 
> 
> I tried several cases, and found as soon as I put gS right before N,
> the high-symmetry point number is wrong. For example, gG-N-gS-gS1 will
> give 4 symmetry point correctly.
> 
> 
> high-symmetry point:  0. 0. 0.   x coordinate   0.
> high-symmetry point:  0.5000 0. 0.1475   x coordinate   0.5213
> high-symmetry point:  0.5435 0. 0.   x coordinate   0.6751
> high-symmetry point:  0.4565 0. 0.2951   x coordinate   0.9828
> 
> 
> below is my scf file
> -
> 
> 
> 
> 
> prefix='TaAs',
> calculation='bands',
> restart_mode='from_scratch',
> wf_collect=.true.,
> verbosity='high',
> outdir='./qe_tmpdir',
> pseudo_dir='./pseudo',
> /
> 
> ibrav = 7,celldm(1) =
> 6.490830825570885,celldm(3)=3.389134738558286,nat = 4,ntyp = 2,
> ecutwfc = 50,ecutrho = 450,
> /
> 
> conv_thr = 1.0d-10,  
> /
> ATOMIC_SPECIES
> Ta180.94788Ta.pbe-spn-kjpaw_psl.0.2.UPF
> As 74.921595  As.pbe-n-kjpaw_psl.0.2.UPF
> ATOMIC_POSITIONS crystal
> As 0.50000.16700.6670
> As 0.0.41700.4170
> Ta0.50000.75000.2500
> Ta0.0.0.
> K_POINTS tpiba_b
> 4
> gG 6 
> gS 6 
> N 6 
> gS1 1
> ___
> Pw_forum mailing list
> Pw_forum@pwscf.org
> http://pwscf.org/mailman/listinfo/pw_forum

-- 
Andrea Dal CorsoTel. 0039-040-3787428
SISSA, Via Bonomea 265  Fax. 0039-040-3787249
I-34136 Trieste (Italy) e-mail: dalco...@sissa.it


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

Re: [Pw_forum] small compilation issues in thermo_pw

[Andrea Dal Corso]

On Wed, 2017-04-12 at 15:56 +0200, Giovanni Cantele wrote:
> Dear all,
> 
> I’ve been trying to compile thermo_pw on Marconi @ CINECA. Here, there are 
> few compilation issues likely to be fixed:
> 
> 
> 1) 
> plotband_sub.f90(839): error #6404: This name does not have a type, and must 
> have an explicit type.   [SYSTEM]
>   ierr=system(TRIM(gnuplot_command)//' '//TRIM(gnu_filename))
> 
> I just added system to the list of variables declared as INTEGER
> 
> 
> 2)
> mpiifort -O2 -assume byterecl -g -traceback -qopenmp -nomodule -qopenmp -fpp 
> -D__OPENMP -D__INTEL -D__DFTI -D__MPI -D__SCALAPACK  -D__ELPA  
> -I/marconi/home/userexternal/gcantele/CODES/Quantum-ESPRESSO/qe-6.1//include 
> -I../include/ 
> -I/cineca/prod/opt/compilers/intel/pe-xe-2017/binary/mkl/include 
> -I../../iotk/src -I../../Modules -I../../FFTXlib -I../../LAXlib 
> -I../../PW/src -I../../LR_Modules -I../../PHonon/PH -I../lib -I../qe -I. -c 
> write_elastic_t.f90
> write_elastic_t.f90(293): error #5145: Invalid blank/tab
> 9x, " C_44 ", 9x, " C_55 ", 9x, " C_66 ", 9x, " C_15 ",  &
> ^
> write_elastic_t.f90(294): error #5145: Invalid blank/tab
> 9x, " C_25 ", 9x, " C_35 ", 9x, " C_46 ", 9x, " B " )')
> ^
> write_elastic_t.f90(311): error #5145: Invalid blank/tab
> 9x, " C_44 ", 9x, " C_55 ", 9x, " C_66 ", 9x, " C_16 ",  &
> ^
> write_elastic_t.f90(312): error #5145: Invalid blank/tab
> 9x, " C_26 ", 9x, " C_36 ", 9x, " C_45 ", 9x, " B " )')
> ——^
> 
> For some reason the compiler does not like the syntax, what I did (I’m not 
> sure if it is right but it compiles!) is to add an “&” to the beginning
> of all the lines  indicated in the error
> 
> 
> 3)
> epsilon_tpw.x : epsilon_tpw.o $(PWOBJS) $(LIBOBJS)
> $(LD) $(LDFLtAGS) -o $@ epsilon_tpw.o \
>  $(LIBOBJS) $(PWOBJS) $(QEMODS) $(LRMODS) $(LIBOBJS) 
> $(PWOBJS) $(LIBS)
> - ( cd ../../bin ; ln -fs ../thermo_pw/tools/epsilon_tpw.x . )
> Lot of undefined calls found in epsilon_tpw.x simply because of a misprint in 
> thermo_pw/tools/Makefile: LDFLtAGS -> LDFLAGS
> 

Thank you. The first two problems have been already corrected in the git
version, but this one has not been found before. 

Andrea

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

-- 
Andrea Dal CorsoTel. 0039-040-3787428
SISSA, Via Bonomea 265  Fax. 0039-040-3787249
I-34136 Trieste (Italy) e-mail: dalco...@sissa.it

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

Re: [Pw_forum] i brav findinf

[Andrea Dal Corso]

Space group number 225 has fcc Bravais lattice. Therefore ibrav=2.

I usually call primitive the fcc cell, and conventional the cubic cell.
If you want to use the crystal_sg feature of QE, only the file with the
explicit space group number can be used with ibrav=2. 

HTH,

Andrea


On Mon, 2016-12-19 at 21:58 +0400, ehsan targholi wrote: 
> Dear all
> I have a question about the finding the ibrav. what the corrcet ibrav of
> primitive and conventional structures of Hexacyanofeerat.
> these structures are attached.
> 
> best regards
> E.Targholi
> ___
> Pw_forum mailing list
> Pw_forum@pwscf.org
> http://pwscf.org/mailman/listinfo/pw_forum

-- 
Andrea Dal CorsoTel. 0039-040-3787428
SISSA, Via Bonomea 265  Fax. 0039-040-3787249
I-34136 Trieste (Italy) e-mail: dalco...@sissa.it


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

Re: [Pw_forum] atomic positions by space_group (subroutine ccord in wyckoff.f90 )

[Andrea Dal Corso]

f using steps (1), (3) and (4), but not step 
> (2).
> 
> Can some one please kindly explain the functions of SUBROUTINE ccord?
> 

With crystal_sg the coordinates of the inequivalent atoms are in crystal
coordinates of the conventional cell, while QE uses crystal coordinates
of the centered cell. ccord make the coordinate transformation between
the two basis.

HTH,

Andrea



> 
> Sincerely,
> Tsung-Lung Li
> 
> 
> 
> 
> Tsung-Lung Li, Ph. D.
> Professor
> Department of Applied Physics
> National Chia-Yi University
> 300 Hsueh-Fu Road, Chiayi 60004, Taiwan
> Phone: 886-5-2717904.  FAX: 886-5-2717909.
> E-mail:quan...@mail.ncyu.edu.tw
> URL:http://web.ncyu.edu.tw/~quantum
> 
> ___
> Pw_forum mailing list
> Pw_forum@pwscf.org
> http://pwscf.org/mailman/listinfo/pw_forum

-- 
Andrea Dal CorsoTel. 0039-040-3787428
SISSA, Via Bonomea 265  Fax. 0039-040-3787249
I-34136 Trieste (Italy) e-mail: dalco...@sissa.it

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

Re: [Pw_forum] About ld1.x

[Andrea Dal Corso]

Sorry, it is PRA not PRB.

Andrea

On Thu, 2016-10-27 at 14:45 -0300, robert.guzman wrote:
> Dear users of QE.
> 
> I was reading  a web page 
> (http://phya.snu.ac.kr/~nmcuong/board/physics/INPUT_LD1.html) where 
> explain the keys of ld1.x code. In the last part of this web page, 
> appears references, but I am thinking that the last reference is 
> incorrect because I could not find it. It is PRB 55, 191 (1997). Someone 
> know which is the correct reference.
> 
> Best Regards.
> 
> R.M. Guzman Arellano.
> Instituto Balseiro - Argentina
> 
> ___
> Pw_forum mailing list
> Pw_forum@pwscf.org
> http://pwscf.org/mailman/listinfo/pw_forum

-- 
Andrea Dal CorsoTel. 0039-040-3787428
SISSA, Via Bonomea 265  Fax. 0039-040-3787249
I-34136 Trieste (Italy) e-mail: dalco...@sissa.it

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

Re: [Pw_forum] documentations or references of (UPF) PAW potentials

[Andrea Dal Corso]

It is the small component of the radial atomic wavefunction Q(r).
It is explained in appendix A of PRB 82, 075116 2010. 

HTH,

Andrea


On Mon, 2016-10-03 at 15:18 +0200, Ryky Nelson wrote:
> Thanks, Andrea, I really appreciate it. Please do let me know, by any
> chance, you know some other documentations related to this issue,
> especially the UPF format for relativistic cases.
> 
> I've been trying to understand the role of the relativistic all-electron
> partial waves (PP_AEWFC_REL) in the UPF file, but found no description
> about it in a QE webpage: http://www.quantum-es
> presso.org/pseudopotentials/unified-pseudopotential-format/
> 
> Best,
> Ryky
> 
> 
> 
> 
> 
> Ryky Nelson
> Institut für Anorganische Chemie
> RWTH Aachen University
> 
> On Mon, Oct 3, 2016 at 11:58 AM, Andrea Dal Corso <dalco...@sissa.it> wrote:
> 
> > Relativistic PAW PPs are described here:
> > Phys. Rev. B 82, 075116 (2010).
> > Some examples are in:
> > Phys. Rev. B 86, 085135 (2012)
> >
> > Relativistic US PPs are described here:
> > Phys. Rev. B 71, 115106 (2005).
> >
> > Andrea
> >
> > On Mon, 2016-10-03 at 10:41 +0200, Ryky Nelson wrote:
> > > Dear all,
> > >
> > > I was wondering if any of you could direct me to any (detailed)
> > > documentations of or references to (UPF) PAW potentials used in Quantum
> > > Espresso, especially for the relativistic (spin-orbit) cases.
> > >
> > > Thank you!
> > >
> > > Best,
> > > Ryky
> > >
> > >
> > >
> > > ----
> > > Ryky Nelson
> > > Institut für Anorganische Chemie
> > > RWTH Aachen University
> > > ___
> > > Pw_forum mailing list
> > > Pw_forum@pwscf.org
> > > http://pwscf.org/mailman/listinfo/pw_forum
> >
> > --
> > Andrea Dal CorsoTel. 0039-040-3787428
> > SISSA, Via Bonomea 265  Fax. 0039-040-3787249
> > I-34136 Trieste (Italy) e-mail: dalco...@sissa.it
> >
> > ___
> > 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

-- 
Andrea Dal CorsoTel. 0039-040-3787428
SISSA, Via Bonomea 265  Fax. 0039-040-3787249
I-34136 Trieste (Italy) e-mail: dalco...@sissa.it

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

Re: [Pw_forum] documentations or references of (UPF) PAW potentials

[Andrea Dal Corso]

Relativistic PAW PPs are described here:
Phys. Rev. B 82, 075116 (2010).
Some examples are in:
Phys. Rev. B 86, 085135 (2012)

Relativistic US PPs are described here:
Phys. Rev. B 71, 115106 (2005). 

Andrea

On Mon, 2016-10-03 at 10:41 +0200, Ryky Nelson wrote:
> Dear all,
> 
> I was wondering if any of you could direct me to any (detailed)
> documentations of or references to (UPF) PAW potentials used in Quantum
> Espresso, especially for the relativistic (spin-orbit) cases.
> 
> Thank you!
> 
> Best,
> Ryky
> 
> 
> 
> 
> Ryky Nelson
> Institut für Anorganische Chemie
> RWTH Aachen University
> ___
> Pw_forum mailing list
> Pw_forum@pwscf.org
> http://pwscf.org/mailman/listinfo/pw_forum

-- 
Andrea Dal CorsoTel. 0039-040-3787428
SISSA, Via Bonomea 265  Fax. 0039-040-3787249
I-34136 Trieste (Italy) e-mail: dalco...@sissa.it

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

Re: [Pw_forum] Unknown Symmetry Error in ph.x.

[Andrea Dal Corso]

You can use search_sym=.FALSE. in the phonon input to avoid this  
error, or provide the
input so we can see what is happening.

Andrea


Quoting Mohammed Ghadiyali :

> Dear All,
> I am getting an error as
>   
> %%
>  Error in routine find_mode_sym (1): unknown mode symmetry  
> %%
>  stopping ... unknown mode symmetry  
> %%
> I am using PHONON v.5.4.0, the structure is a fully relaxed. The  
> structure is a dumbell stanene.
> Regards,Ghadiyali Mohammed Kader



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

Re: [Pw_forum] space_group, crystal_sg, and Wyckoff position still implemented in QE?

[Andrea Dal Corso]

On Tue, 2016-04-26 at 13:05 +0200, Thomas Brumme wrote:
> Dear Paolo,
> 
> thanks to this conversation I learned that one can use Wyckoff position 
> in QE - when was it implemented?
> Anyway, I directly wanted to try it with a system I'm studying just to 
> realize that it is not working...
> 
> Space group 62 (Pnma) has only the Wyckoff position 4a, 4b, 4c 
> implemented, position 8d is missing.
> See also:
> http://www.cryst.ehu.es/cgi-bin/cryst/programs/nph-wp-list?gnum=62

Positions that require three coordinates to be specified do not require
any label. You do not need to modify the code, just omit the 8d label.

HTH,

Andrea


> 
> However, I can' implement it by just editing wypos.f90 as there are only 
> 2 possible input parameters inp1 and inp2
> and I don't want to change all other positions in the code where wypos 
> is used (it would take some time which I don't
> have) but it should be mentioned in the description explicitly that 
> positions where one needs three independent
> parameters are not supported ;) Otherwise people like me could start to 
> wonder why there is an error
> 
> "position not available"
> 
> and ask questions like "What is wrong with my input?"... Well, at least 
> I didn't ask this question...
> 
> Regards
> 
> Thomas
> 
> On 04/25/2016 09:38 PM, Paolo Giannozzi wrote:
> > I agree. It wasn't clearly explained in the documentation (or maybe it 
> > wasn't explained at all) but "nat" for Wyckoff position input is the 
> > number of independent sites, not the total number of atoms
> >
> > Paolo
> >
> > On Mon, Apr 25, 2016 at 8:23 PM, Youssef Aharbil  > > wrote:
> >
> > Dear han.
> > Because "nat" means simply the number of lines to be input not the
> > number of atoms generated via all of wyckoff sites.
> >
> > Youssef Aharbil.
> >
> >
> > ___
> > Pw_forum mailing list
> > Pw_forum@pwscf.org 
> > http://pwscf.org/mailman/listinfo/pw_forum
> >
> >
> >
> >
> > -- 
> > 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 mailing list
Pw_forum@pwscf.org
http://pwscf.org/mailman/listinfo/pw_forum

Re: [Pw_forum] Parity In presence of Spin-Orbit Coupling

[Andrea Dal Corso]

.00 -1.00  1.00 -1.00
> B_3g   1.00 -1.00 -1.00  1.00  1.00 -1.00 -1.00  1.00
> A_u1.00  1.00  1.00  1.00 -1.00 -1.00 -1.00 -1.00
> B_1u   1.00  1.00 -1.00 -1.00 -1.00 -1.00  1.00  1.00
> B_2u   1.00 -1.00  1.00 -1.00 -1.00  1.00 -1.00  1.00
> B_3u   1.00 -1.00 -1.00  1.00 -1.00  1.00  1.00 -1.00
> 
>  the symmetry operations in each class:
>  E1
>  C2_z 2
>  C2_y 3
>  C2_x 4
>  i5
>  s_xy 6
>  s_xz 7
>  s_yz 8
> 
>  Band symmetry, D_2h (mmm)  point group:
> 
>  e(  1 -  1) =-14.86312  eV 1   --> B_2u
>  e(  2 -  2) =-13.83663  eV 1   --> A_g
>  e(  3 -  3) = -7.01653  eV 1   --> B_3u
>  e(  4 -  4) = -3.02267  eV 1   --> B_3g
>  e(  5 -  5) =  1.03648  eV 1   --> B_1u
>  e(  6 -  6) =  6.84967  eV 1   --> A_g
>  e(  7 -  7) = 10.01521  eV 1   --> B_2u
>  e(  8 -  8) = 10.21035  eV 1   --> A_g
> 
>  **
> 
>  BANDS: 0.73s CPU 1.04s WALL
> 
> 
>This run was terminated on:   0:40:23  14Feb2016
> 
> =--=
>JOB DONE.
> =--=
> 
> +++
> Bands.out With Spin-Orbit
> +++
> 
>  Program BANDS v.5.1.1 starts on 14Feb2016 at  0:57:14
> 
>  This program is part of the open-source Quantum ESPRESSO suite
>  for quantum simulation of materials; please cite
>  "P. Giannozzi et al., J. Phys.:Condens. Matter 21 395502 (2009);
>   URL http://www.quantum-espresso.org;,
>  in publications or presentations arising from this work. More details
> at
>  http://www.quantum-espresso.org/quote
> 
>  Parallel version (MPI), running on 4 processors
>  R & G space division:  proc/nbgrp/npool/nimage =   4
> 
>Info: using nr1, nr2, nr3 values from input
> 
>Info: using nr1s, nr2s, nr3s values from input
> 
>  IMPORTANT: XC functional enforced from input :
>  Exchange-correlation  =  SLA  PW   PBE  PBE ( 1  4  3  4 0 0)
>  Any further DFT definition will be discarded
>  Please, verify this is what you really want
> 
>file C.pbe-rrkjus.UPF: wavefunction(s)  2S 2P renormalized
> 
>  Parallelization info
>  
>  sticks:   dense  smooth PW G-vecs:dense   smooth  PW
>  Min  90  46 14 6690 2351 432
>  Max  91  47 18 6703 2359 436
>  Sum 361 187 6126787 94211737
> 
> 
>  negative rho (up, down):  2.651E-05 0.000E+00
>  high-symmetry point:  0.5000 0.2887 0.   x coordinate   0.
> 
>  Plottable bands written to file mol.band.gnu
>  Bands written to file mol.band
> 
>  **
> 
> xk=(   0.5,   0.28868,   0.0  )
> 
>  double point group D_2h (mmm)
>  there are 10 classes and  2 irreducible representations
>  the character table:
> 
>E -E C2C2'  C2''  i -i s_v   s_v' s_v''
>-C2   -C2'  -C2'' -s_v  -s_v' -s_v'
> G_5+   2.00 -2.00  0.00  0.00  0.00  2.00 -2.00  0.00  0.00  0.00
> G_5-   2.00 -2.00  0.00  0.00  0.00 -2.00  2.00  0.00  0.00  0.00
> 
>  the symmetry operations in each class:
>  E 1
>   C2  -C2  2   -2
>   C2' -C2' 3   -3
>  C2'' -C2''4   -4
>  i 5
>   s_v -s_v 6   -6
>   s_v'-s_v'7   -7
>  s_v''-s_v'8   -8
>  -E   -1
>  -i   -5
> 
>  Band symmetry, D_2h (mmm)  double point group:
> 
>  e(  1 -  2) =-14.86296  eV 2   --> G_5-
>  e(  3 -  4) =-13.83647  eV 2   --> G_5+
>  e(  5 -  6) = -7.01634  eV     2   --> G_5-
>  e(  7 -  8) = -3.02256  eV 2   --> G_5+
>  e(  9 - 10) =  1.03660  eV 2   --> G_5-
>  e( 11 - 12) =  6.84981  eV 2   --> G_5+
>  e( 13 - 14) = 10.00945  eV 2   --> G_5-
>  e( 15 - 16) = 10.20230  eV 2   --> G_5+
> 
>  **
> 
>  BANDS: 2.20s CPU 2.59s WALL
> 
> 
>This run was terminated on:   0:57:17  14Feb2016
> 
> =--=
>JOB DONE.
> =--=
> ___
> Pw_forum mailing list
> Pw_forum@pwscf.org
> http://pwscf.org/mailman/listinfo/pw_forum

-- 
Andrea Dal CorsoTel. 0039-040-3787428
SISSA, Via Bonomea 265  Fax. 0039-040-3787249
I-34136 Trieste (Italy) e-mail: dalco...@sissa.it


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

Re: [Pw_forum] a few frequencies in PHONON calculation

[Andrea Dal Corso]

Actually the dynamical matrix is block diagonal in the basis of the  
modes chosen to compute the perturbation and the size of the blocks is  
the number of modes that transform according to the same irreducible  
representation of the small point group of the q vector.

If you look at the symmetry of the modes chosen by the ph.x code to  
compute the perturbation you will notice that they are grouped in such  
a way that there are first all the modes that transform according to  
representation 1,
then all the modes that transform according to  the representation 2,
etc. If you choose start_irr and last_irr so that all the modes of  
representation 1 are calculated and then force the diagonalization of  
the dynamical matrix, the frequencies of the modes that belong to  
representation 1 will be correct.
If your start_irr, last_irr include also some modes of representation  
2 but not all of them, the frequencies of the modes of representation  
2 will be wrong and change when you change last_irr.

Unfortunately if your system has no symmetry then all modes will  
transform according to the representation 1 and in order to have  
correct frequencies you will have to diagonalize the complete  
dynamical matrix, but if you have some symmetry it will be possible to  
select only some modes.

Moreover this trick cannot be used for q points at Brillouin zone  
border for nonsymmorphic space groups, because the code is not able to  
find the representations of these modes.

HTH,

Andrea

Quoting Lorenzo Paulatto :

> Dear Eduardo,
> The frequency are the square roots of the eigenvalues of the dynamical
> matrix, it is not possible to compute just a few eigenvalues without having
> the whole matrix.
>
> Kind regards
>
> ▼ Hide quoted text
> On 22 Dec 2015 6:55 pm, "Eduardo Menendez"  wrote:
>
>> Hi,
>> I have one doubt about the PHONON code. Is it possible to compute just a
>> few phonon frequencies using the PHONON keywords last_irr, ldiag ? For
>> example, using
>>
>> last_irr = 10,
>>   ldiag=.true.,,
>>
>> may one find the frequencies of just the first irreducible representations
>> ?
>>
>> Thank you,
>>
>> Eduardo Menendez Proupin
>> Departamento de Fisica, Facultad de Ciencias, Universidad de Chile
>> URL: http://www.gnm.cl/emenendez
>>
>>
>>
>> ___
>> 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

Re: [Pw_forum] Segmentation Fault in Subroutine divide_class.f90

[Andrea Dal Corso]

Please add more digits to 1/3 and 2/3. 

HTH,

Andrea

On Tue, 2015-12-15 at 16:34 +0530, Surender wrote:
> Dear All,
> 
> I am trying to run the following input file using QE-5.1.2 (compiled with
> Intel Compilers + Intel MKL + FFTW + OpenMPI) and running on Fedora 17
> (64-bit)
> 
> ////
> 
> 
> prefix='nias'
> calculation = 'scf'
> restart_mode='from_scratch'
> verbosity='high'
> pseudo_dir = './'
> outdir='./tmp'
> tprnfor=.true.
> tstress=.true.
> /
> 
> ibrav= 0
> celldm(1)=6.8067935
> nat= 4
> ntyp= 2
> !   nosym=.true.
> ecutwfc=50.0
> ecutrho=500.0
> occupations='smearing'
> smearing='mv'
> degauss=0.005
> /
> 
> mixing_beta = 0.5
> conv_thr = 1.0D-08
> /
> ATOMIC_SPECIES
>  Ni  10.0  Ni.pbe-n-rrkjus_psl.0.1.UPF
>  As  10.0  As.pbe-n-rrkjus_psl.0.2.UPF
> ATOMIC_POSITIONS crystal
>  Ni   0.00   0.00   0.00
>  Ni   0.00   0.00   0.50
>  As   0.33   0.67   0.25
>  As   0.67   0.33   0.75
> K_POINTS automatic
>  10 10 10 1 1 1
> CELL_PARAMETERS alat
>   1.00   0.00   0.00
>  -0.50   0.866025   0.00
>   0.00   0.00   1.390616
> 
> ////
> 
> Unfortunately, QE crashes with segmentation fault in subroutine
> divide_class.f90, for exact message see the attached scf.out file. I tried
> the same input file with QE-5.2.0 and QE-5.2.1 as well but received the
> same error. To me, it appears to be related to symmetry because if I use
> the flag nosym=true , pw.x works fine but takes too long to complete.
> Please help.
> 
> Regards,
> Surender Kumar
> IIT Bombay, India
> ___
> Pw_forum mailing list
> Pw_forum@pwscf.org
> http://pwscf.org/mailman/listinfo/pw_forum

-- 
Andrea Dal CorsoTel. 0039-040-3787428
SISSA, Via Bonomea 265  Fax. 0039-040-3787249
I-34136 Trieste (Italy) e-mail: dalco...@sissa.it


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

Re: [Pw_forum] Z-valence in pseudopotentail

[Andrea Dal Corso]

It depends on which electrons are in valence. The PP with 11 electrons
has only the 5d 6s, the PP with 19 has also the 5s and 5p, and the one
with 33 electrons has also the 4f.

You can find detailed explanations in

Computational Material Science 95, 337 (2014)


HTH,

Andrea


On Fri, 2015-12-11 at 00:57 +0500, Muhammad Adnan wrote:
> Dear Q_E users
> For Au, PBE_USPP, I have found these pseudos from PS_Library. The have
> different z-valence and different total energies. Could any explain why
> different z-valence are in these psudo files and what is the effect of
> z-valence on properties of the atom? How one can guess that which z-valence
> is better?
> Thanks
> Adnan
> UFJF Brazil
> 
> *(1)  *  author="ADC"
>  date=" 1Apr2014"
>  comment=""
>  element="Au"
>  pseudo_type="USPP"
>  relativistic="scalar"
>  is_ultrasoft="T"
>  is_paw="F"
>  is_coulomb="F"
>  has_so="F"
>  has_wfc="F"
>  has_gipaw="F"
>  paw_as_gipaw="F"
>  core_correction="T"
>  functional="PBE"
>  z_valence="3.300E+001"
>  total_psenergy="-1.114158832837015E+003"
>  wfc_cutoff="6.822127389010255E+001"
>  rho_cutoff="3.758447690193309E+002"
>  l_max="3"
>  l_max_rho="6"
>  l_local="-1"
>  mesh_size="1279"
>  number_of_wfc="6"
>  number_of_proj="8"/>
> 
> *(2) *   author="ADC"
>  date=" 1Apr2014"
>  comment=""
>  element="Au"
>  pseudo_type="USPP"
>  relativistic="scalar"
>  is_ultrasoft="T"
>  is_paw="F"
>  is_coulomb="F"
>  has_so="F"
>  has_wfc="F"
>  has_gipaw="F"
>  paw_as_gipaw="F"
>  core_correction="T"
>  functional="PBE"
>  z_valence="1.900E+001"
>  total_psenergy="-2.833692660972704E+002"
>  wfc_cutoff="5.557014998387322E+001"
>  rho_cutoff="3.978162070954610E+002"
>  l_max="2"
>  l_max_rho="4"
>  l_local="-1"
>  mesh_size="1279"
>  number_of_wfc="4"
>  number_of_proj="6"/>
> 
> *(3) *  author="ADC"
>  date=" 1Apr2014"
>  comment=""
>  element="Au"
>  pseudo_type="USPP"
>  relativistic="scalar"
>  is_ultrasoft="T"
>  is_paw="F"
>  is_coulomb="F"
>  has_so="F"
>  has_wfc="F"
>  has_gipaw="F"
>  paw_as_gipaw="F"
>  core_correction="T"
>  functional="PBE"
>  z_valence="1.100E+001"
>  total_psenergy="-8.515444684223810E+001"
>  wfc_cutoff="4.098945123907163E+001"
>  rho_cutoff="3.636947631839826E+002"
>  l_max="2"
>  l_max_rho="4"
>  l_local="-1"
>  mesh_size="1279"
>  number_of_wfc="3"
>  number_of_proj="6"/>
> ___
> Pw_forum mailing list
> Pw_forum@pwscf.org
> http://pwscf.org/mailman/listinfo/pw_forum

-- 
Andrea Dal CorsoTel. 0039-040-3787428
SISSA, Via Bonomea 265  Fax. 0039-040-3787249
I-34136 Trieste (Italy) e-mail: dalco...@sissa.it


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

Re: [Pw_forum] Error in thermo_pw.x run

[Andrea Dal Corso]

/thermo_pw.x(clean_ngeo_+0x24)
> > [0x459fe4]
> > [cluster:05522] [ 2]
> > /home/Utpal/Quantum_espresso/espresso-5.2.1/espresso-5.2.1/bin/thermo_pw.x(thermo_readin_+0x296a)
> > [0x4aa88a]
> > [cluster:05522] [ 3]
> > /home/Utpal/Quantum_espresso/espresso-5.2.1/espresso-5.2.1/bin/thermo_pw.x(MAIN__+0x65)
> > [0x44f145]
> > [cluster:05522] [ 4]
> > /home/Utpal/Quantum_espresso/espresso-5.2.1/espresso-5.2.1/bin/thermo_pw.x(main+0x2a)
> > [0xb742aa]
> > [cluster:05522] [ 5] /lib64/libc.so.6(__libc_start_main+0xfd)
> > [0x392181ecdd]
> > [cluster:05522] [ 6]
> > /home/Utpal/Quantum_espresso/espresso-5.2.1/espresso-5.2.1/bin/thermo_pw.x()
> > [0x44f019]
> > [cluster:05522] *** End of error message ***
> > [cluster:05521] [ 0] /lib64/libpthread.so.0() [0x392240f500]
> > [cluster:05521] [ 1]
> > /home/Utpal/Quantum_espresso/espresso-5.2.1/espresso-5.2.1/bin/thermo_pw.x(clean_ngeo_+0x24)
> > [0x459fe4]
> > [cluster:05521] [ 2]
> > /home/Utpal/Quantum_espresso/espresso-5.2.1/espresso-5.2.1/bin/thermo_pw.x(thermo_readin_+0x296a)
> > [0x4aa88a]
> > [cluster:05521] [ 3]
> > /home/Utpal/Quantum_espresso/espresso-5.2.1/espresso-5.2.1/bin/thermo_pw.x(MAIN__+0x65)
> > [0x44f145]
> > [cluster:05521] [ 4]
> > /home/Utpal/Quantum_espresso/espresso-5.2.1/espresso-5.2.1/bin/thermo_pw.x(main+0x2a)
> > [0xb742aa]
> > [cluster:05521] [ 5] /lib64/libc.so.6(__libc_start_main+0xfd)
> > [0x392181ecdd]
> > [cluster:05521] [ 6]
> > /home/Utpal/Quantum_espresso/espresso-5.2.1/espresso-5.2.1/bin/thermo_pw.x()
> > [0x44f019]
> > [cluster:05521] *** End of error message ***
> > [cluster:05524] *** Process received signal ***
> > [cluster:05524] Signal: Segmentation fault (11)
> > [cluster:05524] Signal code: Address not mapped (1)
> > [cluster:05524] Failing at address: 0x
> > [cluster:05523] *** Process received signal ***
> > [cluster:05523] Signal: Segmentation fault (11)
> > [cluster:05523] Signal code: Address not mapped (1)
> > [cluster:05523] Failing at address: 0x
> > [cluster:05524] [ 0] /lib64/libpthread.so.0() [0x392240f500]
> > [cluster:05524] [ 1]
> > /home/Utpal/Quantum_espresso/espresso-5.2.1/espresso-5.2.1/bin/thermo_pw.x(clean_ngeo_+0x24)
> > [0x459fe4]
> > [cluster:05524] [ 2]
> > /home/Utpal/Quantum_espresso/espresso-5.2.1/espresso-5.2.1/bin/thermo_pw.x(thermo_readin_+0x296a)
> > [0x4aa88a]
> > [cluster:05524] [ 3]
> > /home/Utpal/Quantum_espresso/espresso-5.2.1/espresso-5.2.1/bin/thermo_pw.x(MAIN__+0x65)
> > [0x44f145]
> > [cluster:05524] [ 4]
> > /home/Utpal/Quantum_espresso/espresso-5.2.1/espresso-5.2.1/bin/thermo_pw.x(main+0x2a)
> > [0xb742aa]
> > [cluster:05524] [ 5] /lib64/libc.so.6(__libc_start_main+0xfd)
> > [0x392181ecdd]
> > [cluster:05524] [ 6]
> > /home/Utpal/Quantum_espresso/espresso-5.2.1/espresso-5.2.1/bin/thermo_pw.x()
> > [0x44f019]
> > [cluster:05524] *** End of error message ***
> > [cluster:05523] [ 0] /lib64/libpthread.so.0() [0x392240f500]
> > [cluster:05523] [ 1]
> > /home/Utpal/Quantum_espresso/espresso-5.2.1/espresso-5.2.1/bin/thermo_pw.x(clean_ngeo_+0x24)
> > [0x459fe4]
> > [cluster:05523] [ 2]
> > /home/Utpal/Quantum_espresso/espresso-5.2.1/espresso-5.2.1/bin/thermo_pw.x(thermo_readin_+0x296a)
> > [0x4aa88a]
> > [cluster:05523] [ 3]
> > /home/Utpal/Quantum_espresso/espresso-5.2.1/espresso-5.2.1/bin/thermo_pw.x(MAIN__+0x65)
> > [0x44f145]
> > [cluster:05523] [ 4]
> > /home/Utpal/Quantum_espresso/espresso-5.2.1/espresso-5.2.1/bin/thermo_pw.x(main+0x2a)
> > [0xb742aa]
> > [cluster:05523] [ 5] /lib64/libc.so.6(__libc_start_main+0xfd)
> > [0x392181ecdd]
> > [cluster:05523] [ 6]
> > /home/Utpal/Quantum_espresso/espresso-5.2.1/espresso-5.2.1/bin/thermo_pw.x()
> > [0x44f019]
> > [cluster:05523] *** End of error message ***
> >
> > mpirun noticed that process rank 0 with PID 5521 on node cluster.hpc.org
> > exited on signal 11 (Segmentation fault).
> >
> > Error condition encountered during test: exit status = 139
> > Aborting
> > [Utpal@cluster example13]$
> >
> > 
> > I have checked that the libpthread.so.0 and libc.so.6 file are not in the
> > lib64 directory, it is in the lib directory.  I have checked the Makefile
> > of thermo_pw/src and make.sys of espresso-5.2.1. But could not understand
> > where  can I define  this path?
> > Could anyone please help me to solve this problem? Any sort of help will
> > be thankfully acknowledged.
> >
> > Thanking you.
> >
> > Sincerely
> > Barnali Bhattacharya
> > Ph.D student, Department of physics,
> > Assam university
> >
> >
> >
> >
> > ___
> > 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

-- 
Andrea Dal CorsoTel. 0039-040-3787428
SISSA, Via Bonomea 265  Fax. 0039-040-3787249
I-34136 Trieste (Italy) e-mail: dalco...@sissa.it


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

Re: [Pw_forum] Comparing with and without spin orbit for same pseudo-potential

[Andrea Dal Corso]

Fully relativistic calculations require fully relativistic PPs.
A calculation with fully relativistic US or PAW PP and lspinorb=.FALSE.
is not allowed. The pw.x code is not able to calculate a scalar
relativistic PP from the fully relativistic one. Instead a fully
relativistic norm conserving PP and lspinorb=.FALSE. is allowed and is
equivalent to  a scalar relativistic calculation.

HTH,

Andrea


On Sun, 2015-11-29 at 20:15 +, Niels Walet wrote:
> I am running a standard pw calculation. As it says in the title I am trying 
> to work out how to perform the same calculation with and without spin orbit 
> for same pseudo-potential--if I use a fully relativistics pseudo-potential 
> (with SO), and I also try to "switch off" the spin-orbit force 
> (lspinorb=.false.), I get the error message
> error in routine average_pp (1):
>  FR-PP please use lspinorb=.true.
> The documentation is not incredibly clear about this point. I tried various 
> combinations of the lspinorb and noncolin parameters, but have had no 
> success. This almost suggests I need to use a scalar relativistic analogue 
> rather than the same PP? Or am I just missing the point?
> 
> 
> 
> ---
> Prof. Niels R. Walet Phone:  +44(0)1613063693
> School of Physics and Astronomy Mobile: +44(0)7516622121
> The University of ManchesterRoom 7.7, Schuster Building
> Manchester, M13 9PL,  UK
> email: niels.wa...@manchester.ac.uk   twitter: @nwalet
> ___
> Pw_forum mailing list
> Pw_forum@pwscf.org
> http://pwscf.org/mailman/listinfo/pw_forum

-- 
Andrea Dal CorsoTel. 0039-040-3787428
SISSA, Via Bonomea 265  Fax. 0039-040-3787249
I-34136 Trieste (Italy) e-mail: dalco...@sissa.it


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

Re: [Pw_forum] phonon and soc

[Andrea Dal Corso]

When lspinorb is true the code produces .xml dynamical matrix files. You
have just to put the same name with .xml extension in the input of
q2r.x.

HTH,

Andrea

On Fri, 2015-10-23 at 14:40 +0200, Maedeh Zahedifar wrote:
> Dear all,
> In my calculation, which is phonon with soc, the calculation can not creat
> correct (.dyn).. it created  (.dyn1.xml)  instead of ( .dyn1).
> 
> Would you please tell me what is my problem?
> I just only add two items in my scf input :  lspinorb = .true.,
>   noncolin =
> .true.,
> 
> 
> Best,
> Maedeh Zahedifar
> ___
> Pw_forum mailing list
> Pw_forum@pwscf.org
> http://pwscf.org/mailman/listinfo/pw_forum

-- 
Andrea Dal CorsoTel. 0039-040-3787428
SISSA, Via Bonomea 265  Fax. 0039-040-3787249
I-34136 Trieste (Italy) e-mail: dalco...@sissa.it


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

Re: [Pw_forum] ibrav = 13 monoclinic-base-centered unique axis

[Andrea Dal Corso]

In recent versions of QE

ibrav=-13

is allowed for b-unique base centered monoclinic.

HTH,

Andrea

On Wed, 2015-09-23 at 11:17 +0200, Ludwig, Stephan wrote:
> Hello,
> 
> 
> 
> I want to work on a salt with space group monoclinic-base centered. This 
> means ibrav=13 in th input file.
> 
> For simple monoclinic lattices there are two distinct possibilties to choose 
> the unique axis (ibrav=12 or -12).
> 
> Ibrav=13 obviously chooses the c-axis to be the unique one.
> 
> Is there a possibility to choose the b-axis to be unique?
> 
> 
> 
> Thanks and regards
> 
> 
> 
> Stephan
> 
> 
> 
> ___
> Pw_forum mailing list
> Pw_forum@pwscf.org
> http://pwscf.org/mailman/listinfo/pw_forum

-- 
Andrea Dal CorsoTel. 0039-040-3787428
SISSA, Via Bonomea 265  Fax. 0039-040-3787249
I-34136 Trieste (Italy) e-mail: dalco...@sissa.it


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

Re: [Pw_forum] Parity wave function

[Andrea Dal Corso]

On Fri, 2015-09-11 at 11:47 +0200, Andrea Dal Corso wrote:
> The group should have inversion to check the parity with respect
> inversion symmetry. You can have all the information that are in the
> character tables when you know how a wavefunction

Sorry, I meant ... when you know according to which representation a
wavefunction transform ..,

> but which information is of interest to you depends
> on your problem, it cannot be found in a QE manual.
> 
> Andrea
> 
> On Fri, 2015-09-11 at 13:59 +0430, Mohsen Modaresi wrote:
> > Hi Andrea,
> > 
> > Thanks for your answer.
> > 
> > In the bands out put,
> > 
> >  **
> > 
> > xk=(   0.0,   0.0,   0.0  )
> > 
> >  double point group C_s (m)
> >  there are  4 classes and  2 irreducible representations
> >  the character table:
> > 
> >E -Es -s
> > 
> > G_31.00 -1.00  0.00  0.00
> > G_41.00 -1.00  0.00  0.00
> > 
> >  imaginary part
> > 
> >E -Es -s
> > 
> > G_30.00  0.00  1.00 -1.00
> > G_40.00  0.00 -1.00  1.00
> > 
> >  the symmetry operations in each class and the name of the first
> > element:
> > 
> >  E 1
> > 
> >  -E   -1
> > 
> >  s 2
> > 
> >  -s   -2
> > 
> > 
> >  Band symmetry, C_s (m) double point group:
> > 
> >  e(  1 -  2) =-27.61275  eV 2   --> G_3
> >  e(  1 -  2) =-27.61275  eV 2   --> G_4
> >  e(  3 -  4) =-27.58856  eV 2   --> G_3
> >  e(  3 -  4) =-27.58856  eV 2   --> G_4
> >  e(  5 -  6) =-26.57390  eV 2   --> G_3
> >  e(  5 -  6) =-26.57390  eV 2   --> G_4
> >  e(  7 -  8) =-26.48621  eV 2   --> G_3
> >  e(  7 -  8) =-26.48621  eV 2   --> G_4
> >  e(  9 - 10) =-26.25165  eV 2   --> G_3
> >  e(  9 - 10) =-26.25165  eV 2   --> G_4
> >  e( 11 - 12) =-26.23208  eV 2   --> G_3
> >  e( 11 - 12) =-26.23208  eV 2   --> G_4
> >  e( 13 - 14) =-25.55156  eV 2   --> G_3
> >  e( 13 - 14) =-25.55156  eV 2   --> G_4
> >  e( 15 - 16) =-25.46597  eV 2   --> G_3
> >  e( 15 - 16) =-25.46597  eV 2   --> G_4
> >  e( 17 - 18) =-25.45110  eV 2   --> G_3
> >  e( 17 - 18) =-25.45110  eV 2   --> G_4
> >  e( 19 - 20) =-25.42772  eV 2   --> G_3
> >  e( 19 - 20) =-25.42772  eV 2   --> G_4
> >  e( 21 - 22) =-25.11231  eV 2   --> G_3
> >  e( 21 - 22) =-25.11231  eV 2   --> G_4
> >  e( 23 - 24) =-25.02944  eV 2   --> G_3
> >  e( 23 - 24) =-25.02944  eV 2   --> G_4
> >  e( 25 - 26) =-13.43448  eV 2   --> G_3
> >  e( 25 - 26) =-13.43448  eV 2   --> G_4
> >  e( 27 - 28) =-10.07434  eV 2   --> G_3
> >  e( 27 - 28) =-10.07434  eV 2   --> G_4
> >  e( 29 - 30) = -8.47022  eV 2   --> G_3
> >  e( 29 - 30) = -8.47022  eV 2   --> G_4
> >  e( 31 - 32) = -8.15897  eV 2   --> G_3
> >  e( 31 - 32) = -8.15897  eV 2   --> G_4
> >  e( 33 - 34) = -8.08388  eV 2   --> G_3
> >  e( 33 - 34) = -8.08388  eV 2   --> G_4
> >  e( 35 - 36) = -7.98657  eV 2   --> G_3
> >  e( 35 - 36) = -7.98657  eV 2   --> G_4
> >  e( 37 - 38) = -7.93692  eV 2   --> G_3
> >  e( 37 - 38) = -7.93692  eV 2   --> G_4
> >  e( 39 - 40) = -5.34727  eV 2   --> G_3
> >  e( 39 - 40) = -5.34727  eV 2   --> G_4
> >  e( 41 - 42) = -4.91485  eV 2   --> G_3
> >  e( 41 - 42) = -4.91485  eV 2   --> G_4
> >  e( 43 - 44) = -4.52985  eV 2   --> G_3
> >  e( 43 - 44) = -4.52985  eV 2   --> G_4
> >  e( 45 - 46) = -3.10125  eV 2   --> G_3
> >  e( 45 - 46) = -3.10125  eV 2   --> G_4
> >  e( 47 - 48) = -1.48519  eV 2   --> G_3
> >  e( 47 - 48) = -1.48519  eV 2   --> G_4
> >  e( 49 - 50) = -1.22583  eV 2   --> G_3
> >  e( 49 - 50) = -1.22583  eV 2   --> G_4
> > 
> >  

Re: [Pw_forum] Parity wave function

[Andrea Dal Corso]

The group should have inversion to check the parity with respect
inversion symmetry. You can have all the information that are in the
character tables when you know how a wavefunction transforms for a
symmetry operation, but which information is of interest to you depends
on your problem, it cannot be found in a QE manual.

Andrea

On Fri, 2015-09-11 at 13:59 +0430, Mohsen Modaresi wrote:
> Hi Andrea,
> 
> Thanks for your answer.
> 
> In the bands out put,
> 
>  **
> 
> xk=(   0.0,   0.0,   0.0  )
> 
>  double point group C_s (m)
>  there are  4 classes and  2 irreducible representations
>  the character table:
> 
>E -Es -s
> 
> G_31.00 -1.00  0.00  0.00
> G_41.00 -1.00  0.00  0.00
> 
>  imaginary part
> 
>E -Es -s
> 
> G_30.00  0.00  1.00 -1.00
> G_40.00  0.00 -1.00  1.00
> 
>  the symmetry operations in each class and the name of the first
> element:
> 
>  E 1
> 
>  -E   -1
> 
>  s 2
> 
>  -s   -2
> 
> 
>  Band symmetry, C_s (m) double point group:
> 
>  e(  1 -  2) =-27.61275  eV 2   --> G_3
>  e(  1 -  2) =-27.61275  eV 2   --> G_4
>  e(  3 -  4) =-27.58856  eV 2   --> G_3
>  e(  3 -  4) =-27.58856  eV 2   --> G_4
>  e(  5 -  6) =-26.57390  eV 2   --> G_3
>  e(  5 -  6) =-26.57390  eV 2   --> G_4
>  e(  7 -  8) =-26.48621  eV 2   --> G_3
>  e(  7 -  8) =-26.48621  eV 2   --> G_4
>  e(  9 - 10) =-26.25165  eV 2   --> G_3
>  e(  9 - 10) =-26.25165  eV 2   --> G_4
>  e( 11 - 12) =-26.23208  eV 2   --> G_3
>  e( 11 - 12) =-26.23208  eV 2   --> G_4
>  e( 13 - 14) =-25.55156  eV 2   --> G_3
>  e( 13 - 14) =-25.55156  eV 2   --> G_4
>  e( 15 - 16) =-25.46597  eV 2   --> G_3
>  e( 15 - 16) =-25.46597  eV 2   --> G_4
>  e( 17 - 18) =-25.45110  eV 2   --> G_3
>  e( 17 - 18) =-25.45110  eV 2   --> G_4
>  e( 19 - 20) =-25.42772  eV 2   --> G_3
>  e( 19 - 20) =-25.42772  eV 2   --> G_4
>  e( 21 - 22) =-25.11231  eV 2   --> G_3
>  e( 21 - 22) =-25.11231  eV 2   --> G_4
>  e( 23 - 24) =-25.02944  eV 2   --> G_3
>  e( 23 - 24) =-25.02944  eV 2   --> G_4
>  e( 25 - 26) =-13.43448  eV 2   --> G_3
>  e( 25 - 26) =-13.43448  eV 2   --> G_4
>  e( 27 - 28) =-10.07434  eV 2   --> G_3
>  e( 27 - 28) =-10.07434  eV 2   --> G_4
>  e( 29 - 30) = -8.47022  eV 2   --> G_3
>  e( 29 - 30) = -8.47022  eV 2   --> G_4
>  e( 31 - 32) = -8.15897  eV 2   --> G_3
>  e( 31 - 32) = -8.15897  eV 2   --> G_4
>  e( 33 - 34) = -8.08388  eV 2   --> G_3
>  e( 33 - 34) = -8.08388  eV 2   --> G_4
>  e( 35 - 36) = -7.98657  eV 2   --> G_3
>  e( 35 - 36) = -7.98657  eV 2   --> G_4
>  e( 37 - 38) = -7.93692  eV 2   --> G_3
>  e( 37 - 38) = -7.93692  eV 2   --> G_4
>  e( 39 - 40) = -5.34727  eV 2   --> G_3
>  e( 39 - 40) = -5.34727  eV 2   --> G_4
>  e( 41 - 42) = -4.91485  eV 2   --> G_3
>  e( 41 - 42) = -4.91485  eV 2   --> G_4
>  e( 43 - 44) = -4.52985  eV 2   --> G_3
>  e( 43 - 44) = -4.52985  eV 2   --> G_4
>  e( 45 - 46) = -3.10125  eV 2   --> G_3
>  e( 45 - 46) = -3.10125  eV 2   --> G_4
>  e( 47 - 48) = -1.48519  eV 2   --> G_3
>  e( 47 - 48) = -1.48519  eV 2   --> G_4
>      e( 49 - 50) = -1.22583  eV 2   --> G_3
>  e( 49 - 50) = -1.22583  eV 2   --> G_4
> 
>  **
> 
> Still the Parity is missing?
> I saw some articles that report the parity interpretation with QE (Although
> most of works are with VASP).
> Thanks for your help.
> 
> Best,
> 
> On Fri, Sep 11, 2015 at 1:38 PM, Andrea Dal Corso <dalco...@sissa.it> wrote:
> 
> > The numbers indicate, for each band, the number of the representation of
> > the small group of K. The character table for the point group is written
> > in the output of the bands.x program and the number corresponds to the
> > number of the represen

Re: [Pw_forum] Parity wave function

[Andrea Dal Corso]

The numbers indicate, for each band, the number of the representation of
the small group of K. The character table for the point group is written
in the output of the bands.x program and the number corresponds to the
number of the representation in the character table. 

HTH,

Andrea

On Fri, 2015-09-11 at 13:23 +0430, Mohsen Modaresi wrote:
> Dear users,
> 
> I need parity wave of each bands of  band structure (in some specific K
> points known as TRIM points) [PRB 76, 045302] to determine the
> topological-->trivial phase transition.
> In 2013 some body ask about the parity and Prof. Giannozzi suggest to use
> bands.x. I did and get a .rap file. But I can not find any document to
> understand the out file.
> Here for example, I bring data file for one K point (Gama point).
> %%%
>0.00  0.00  0.00T
>1   2   1   2   1   2   1   2
> 1   2
>1   2   1   2   1   2   1   2
> 1   2
>1   2   1   2   1   2   1   2
> 1   2
>1   2   1   2   1   2   1   2
> 1   2
>1   2   1   2   1   2   1   2
> 1   2
> %%%
> 
> any suggestion is appreciated.
> Best,
> 
> Mohsen Modarresi,
> Department of Physics, Ferdowsi University of Mashhad, Iran.
> Phone +98-913-345-2131
> ___
> Pw_forum mailing list
> Pw_forum@pwscf.org
> http://pwscf.org/mailman/listinfo/pw_forum

-- 
Andrea Dal CorsoTel. 0039-040-3787428
SISSA, Via Bonomea 265  Fax. 0039-040-3787249
I-34136 Trieste (Italy) e-mail: dalco...@sissa.it


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

Re: [Pw_forum] Dielectric constant calculations for InAs

[Andrea Dal Corso]

The gap of InAs is not correct with PBE. Your system is probably
metallic. Please check the gap before computing the dielectric constant.

HTH,

Andrea 

On Tue, 2015-09-08 at 17:48 +0800, Zhiping Xu wrote:
> Dear all:
> 
> I am using pw.x and ph.x to calculate the dielectric constant of InAs, and 
> here are some problems with the calculations.
> 
> (1) After structural relaxation using vc-relax, the stress is now zero 
> (confirmed using scf calculations for the final structure). 
> 
>  convergence has been achieved in  10 iterations
> 
>  Forces acting on atoms (Ry/au):
> 
>  atom1 type  1   force = 0.0.0.
>  atom2 type  2   force = 0.0.0.
> 
>  Total force = 0.00 Total SCF correction = 0.00
> 
> 
>  entering subroutine stress ...
> 
>   total   stress  (Ry/bohr**3)   (kbar) P=0.00
>0.0001  -0.  -0.  0.00 -0.00 -0.00
>   -0.   0.0001   0. -0.00  0.00  0.00
>   -0.   0.   0.0001 -0.00  0.00  0.00
> 
> 
> However, the following phonon calculation predicts not only negative phonon 
> frequency at q = 0, but also very strange dielectric constant.
> 
>   Dielectric constant in cartesian axis 
> 
>   (-230.720680077  -0.0   0.0 )
>   (  -0.0-230.720680077   0.0 )
>   (   0.0   0.0-230.720680077 )
> 
>   Effective charges (d Force / dE) in cartesian axis
> 
>atom  1   In 
>   Ex  (9.550760.00.0 )
>   Ey  (0.09.550760.0 )
>   Ez  (0.00.09.55076 )
>atom  2   As 
>   Ex  (   -9.438860.00.0 )
>   Ey  (   -0.0   -9.43886   -0.0 )
>   Ez  (0.00.0   -9.43886 )
> 
>  Diagonalizing the dynamical matrix
> 
>  q = (0.0   0.0   0.0 ) 
> 
>  **
>  freq (1) =  -6.064621 [THz] =-202.293974 [cm-1]
>  freq (2) =  -6.064621 [THz] =-202.293974 [cm-1]
>  freq (3) =  -6.064621 [THz] =-202.293974 [cm-1]
>  freq (4) =   0.164141 [THz] =   5.475159 [cm-1]
>  freq (5) =   0.164141 [THz] =   5.475159 [cm-1]
>  freq (6) =   0.164141 [THz] =   5.475159 [cm-1]
>  **
> 
> The input files are attached below for your reference. 
> 
> (2) One more question, the vc-relax calculation converges at zero stress, 
> which was calculated using the cut-off set for initial cell parameters, so 
> one has to redo the calculations using the new cell parameters following the 
> suggestion at http://www.quantum-espresso.org/faq/self-consistency/#6.11 
> <http://www.quantum-espresso.org/faq/self-consistency/#6.11>. Is there any 
> better (more automatic) way to obtain a final relaxed cell/atom structures?
> 
> Could any one help me on these two questions?
> 
> Thank you,
> 
> Zhiping
> 
> input files:
> 
> —scf.in—
> 
>   calculation = 'scf',
>   restart_mode= 'from_scratch',
>   pseudo_dir  = '/home/xuzp/bin/lib/upf_files',
>   outdir  = '.',
>   prefix  = 'InAs',
>   tstress = .true.
>   tprnfor = .true.
>   wf_collect  = .true.
> /
> 
>   ibrav   = 2, 
>   celldm(1)   = 11.69675,
>   nat = 2, 
>   ntyp= 2,
>   ecutwfc = 90,   
> /
> 
>   diagonalization = 'cg'
>   conv_thr=  1.0d-10
> /
> 
> ATOMIC_SPECIES
>  In  111.818  In.pbe-dn-rrkjus_psl.0.2.2.UPF
>  As   74.920  As.pbe-n-rrkjus_psl.0.2.UPF
> 
> ATOMIC_POSITIONS crystal
>  In 0.00 0.00 0.00
>  As 0.25 0.25 0.25
> 
> K_POINTS automatic 
>  9 9 9 0 0 0 
> 
> —ph.in—
> phonons of InAs
> 
>   tr2_ph   = 1.0d-16,
>   niter_ph = 100,
>   prefix   = 'InAs',
>   epsil= .true. 
>   amass(1) = 111.818,
>   amass(2) = 74.920,
>   outdir   = '.',
>   fildyn   = 'InAs.matdyn',
> /
> 0.0 0.0 0.0
> ___ Pw_forum mailing list 
> Pw_forum@pwscf.org http://pwscf.org/mailman/listinfo/pw_forum

-- 
Andrea Dal CorsoTel. 0039-040-3787428
SISSA, Via Bonomea 265  Fax. 0039-040-3787249
I-34136 Trieste (Italy) e-mail: dalco...@sissa.it


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

Re: [Pw_forum] Bug in ph.x sometimes occur in hexagonal phases

[Andrea Dal Corso]

Are the phonon calculated with 13 dynamical matrices wrong?
It seems a problem of fractionary translations. The point group of the
hcp is D_6h, with 24 symmetry operations but with your input pw finds 12
symmetries because the FFT mesh does not allow some symmetries.
With nr1=30, nr2=30, nr3=48 all symmetries are found correctly.

HTH,

Andrea

On Wed, 2015-08-26 at 17:36 +0300, Uri Argaman wrote:
> Dear QE users and developers
> When I do phonon calculations in hexagonal phases (titanium and zirconium)
> in a 4X4X4 q-points grid, QE calculate 12 dynamical matrices. But, in a
> specific geometries QE calculate 13 dynamical matrices, two of them are the
> same. dyn0 in that case is:
>4   4   4
>   13
>0.000E+00   0.000E+00   0.000E+00
>0.000E+00   0.000E+00   0.156342786935722E+00
>0.000E+00   0.000E+00  -0.312685573871444E+00
>0.000E+00   0.288675134594792E+00   0.000E+00
>0.000E+00   0.288675134594792E+00   0.156342786935722E+00
>0.000E+00   0.288675134594792E+00  -0.312685573871444E+00
>0.000E+00   0.288675134594792E+00  -0.156342786935722E+00
>0.000E+00  -0.577350269189585E+00   0.000E+00
>0.000E+00  -0.577350269189585E+00   0.156342786935722E+00
>0.000E+00  -0.577350269189585E+00  -0.312685573871444E+00
>0.250E+00   0.433012701892189E+00   0.000E+00
>0.250E+00   0.433012701892189E+00   0.156342786935722E+00
>0.250E+00   0.433012701892189E+00  -0.312685573871444E+00
> 
> You can see that the 5'th and the 7'th dynamical matrix are the same. I
> want to emphasize that this bug is only at a certain lattice parameter. For
> example, this is the input files:
> This is the SCF input:
>  
> calculation='scf'
> restart_mode='from_scratch',
> prefix='zr',
> pseudo_dir = '/home/argaman/espresso_intel/pseudo/',
> outdir='/home/argaman/tmp/tmp5110/',
> tstress = .true. ,
> tprnfor = .true. ,
> verbosity='high',
> wf_collect=.true.
>  /
>  
> ibrav=  4, celldm(1) =5.98584, celldm(3) =1.59905042567 , nat= 2, ntyp=
> 1,
> ecutwfc =45,ecutrho=225,
> occupations='smearing', smearing="methfessel-paxton", degauss=0.01,
>  /
>  
> conv_thr =  1.0d-9,
> electron_maxstep=1000
> mixing_beta = 0.7d0,
>  /
> 
> ATOMIC_SPECIES
>Zr  91.224 zr_pbe_v1.uspp.F.UPF
> ATOMIC_POSITIONS (crystal)
>Zr  0.60.30.250000  0  0
>Zr  0.30.60.75000
> K_POINTS {automatic}
>  18 18 18 0 0 0
> 
> This is the phonon input:
> phonon  for Zr
>  
>   tr2_ph=1.0d-15,
>   prefix='zr',
>   fildvscf='aldv',
>   amass(1)=91.224,
>   outdir='/home/argaman/tmp/tmp5110/',
>   fildyn='zr.dyn',
>   trans=.true.,
>   ldisp=.true.,
>   nq1=4, nq2=4, nq3=4
>  /
> 
> I got this bug on versions:
> 5.0.3, 5.1 and 5.2.0
> Thank you
> Uri Argaman
> Ben-Gurion University
> Israel
> ___
> Pw_forum mailing list
> Pw_forum@pwscf.org
> http://pwscf.org/mailman/listinfo/pw_forum

-- 
Andrea Dal CorsoTel. 0039-040-3787428
SISSA, Via Bonomea 265  Fax. 0039-040-3787249
I-34136 Trieste (Italy) e-mail: dalco...@sissa.it


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

Re: [Pw_forum] Bug in ph.x sometimes occur in hexagonal phases

[Andrea Dal Corso]

I would start by writing atomic positions with more digits.
If the error is still there please report it.

HTH,

Andrea

On Wed, 2015-08-26 at 17:36 +0300, Uri Argaman wrote:
> Dear QE users and developers
> When I do phonon calculations in hexagonal phases (titanium and zirconium)
> in a 4X4X4 q-points grid, QE calculate 12 dynamical matrices. But, in a
> specific geometries QE calculate 13 dynamical matrices, two of them are the
> same. dyn0 in that case is:
>4   4   4
>   13
>0.000E+00   0.000E+00   0.000E+00
>0.000E+00   0.000E+00   0.156342786935722E+00
>0.000E+00   0.000E+00  -0.312685573871444E+00
>0.000E+00   0.288675134594792E+00   0.000E+00
>0.000E+00   0.288675134594792E+00   0.156342786935722E+00
>0.000E+00   0.288675134594792E+00  -0.312685573871444E+00
>0.000E+00   0.288675134594792E+00  -0.156342786935722E+00
>0.000E+00  -0.577350269189585E+00   0.000E+00
>0.000E+00  -0.577350269189585E+00   0.156342786935722E+00
>0.000E+00  -0.577350269189585E+00  -0.312685573871444E+00
>0.250E+00   0.433012701892189E+00   0.000E+00
>0.250E+00   0.433012701892189E+00   0.156342786935722E+00
>0.250E+00   0.433012701892189E+00  -0.312685573871444E+00
> 
> You can see that the 5'th and the 7'th dynamical matrix are the same. I
> want to emphasize that this bug is only at a certain lattice parameter. For
> example, this is the input files:
> This is the SCF input:
>  
> calculation='scf'
> restart_mode='from_scratch',
> prefix='zr',
> pseudo_dir = '/home/argaman/espresso_intel/pseudo/',
> outdir='/home/argaman/tmp/tmp5110/',
> tstress = .true. ,
> tprnfor = .true. ,
> verbosity='high',
> wf_collect=.true.
>  /
>  
> ibrav=  4, celldm(1) =5.98584, celldm(3) =1.59905042567 , nat= 2, ntyp=
> 1,
> ecutwfc =45,ecutrho=225,
> occupations='smearing', smearing="methfessel-paxton", degauss=0.01,
>  /
>  
> conv_thr =  1.0d-9,
> electron_maxstep=1000
> mixing_beta = 0.7d0,
>  /
> 
> ATOMIC_SPECIES
>Zr  91.224 zr_pbe_v1.uspp.F.UPF
> ATOMIC_POSITIONS (crystal)
>Zr  0.60.30.250000  0  0
>Zr  0.30.60.75000
> K_POINTS {automatic}
>  18 18 18 0 0 0
> 
> This is the phonon input:
> phonon  for Zr
>  
>   tr2_ph=1.0d-15,
>   prefix='zr',
>   fildvscf='aldv',
>   amass(1)=91.224,
>   outdir='/home/argaman/tmp/tmp5110/',
>   fildyn='zr.dyn',
>   trans=.true.,
>   ldisp=.true.,
>   nq1=4, nq2=4, nq3=4
>  /
> 
> I got this bug on versions:
> 5.0.3, 5.1 and 5.2.0
> Thank you
> Uri Argaman
> Ben-Gurion University
> Israel
> ___
> Pw_forum mailing list
> Pw_forum@pwscf.org
> http://pwscf.org/mailman/listinfo/pw_forum

-- 
Andrea Dal CorsoTel. 0039-040-3787428
SISSA, Via Bonomea 265  Fax. 0039-040-3787249
I-34136 Trieste (Italy) e-mail: dalco...@sissa.it


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

Re: [Pw_forum] Using -nimage with phonon at q=0

[Andrea Dal Corso]

On Thu, 2015-08-06 at 14:00 +0200, Merlin Meheut wrote:
> On 05/08/2015 18:50, Andrea Dal Corso wrote:
> > On Wed, 2015-08-05 at 17:18 +0200, Merlin Meheut wrote:
> >> Dear PWSCF users,
> >>
> >> I recently discovered with great interest the possibilities to
> >> parallelize phonon calculations using the -nimage option of ph.x.
> >> (example given in espresso-4.3.2/examples/GRID_examples).
> >>
> > GRID examples refer to grid splitting, meaning that you split the
> > calculation using start_irr, last_irr etc. and in principle the
> > calculation can run in different machines. Then you have to collect the
> > files  yourself to finally obtain the results.
> 
> Sorry I mixed up both. Actually, I used -nimage (as explained in 
> Doc/INPUT_PH.txt of version 4.3.2), but I would like to restart with 
> grid splitting.
> Thank you for the reference to the example.
> 
> >> However, I had a problem when performing calculations at gamma-point:
> >> for other q-points (therefore with epsil=.false. and zue=.false.)
> >> everything went as planned, but with q=0 (and epsil=.true. and
> >> zue=.true.), this just did not work. I took 80 processors divided into 4
> >> images, and instead of dividing the different representations into 4
> >> pools, the four groups of processors realized the same calculation,
> >> computing the same representations. I killed the calculation at some
> >> point (I have computed the electric fields, effective charges and 218
> >> representations out of 564). I would like now to finish the computation
> >> without redoing it, and I have several questions to achieve this goal:
> >>
> > Are you sure that all the images made the same phonon calculations, or
> > all images made the electric field calculation but the phonon modes were
> > different?
> 
> The names of the partial dynamical matrices (dynmat.1.$irr.xml) are the 
> same, the files (e.g. _ph0/LiClMag2-1.phsave/dynmat.1.100.xml and
> _ph1/LiClMag2-1.phsave/dynmat.1.100.xml) are almost identical, and the 
> calculation lasted more than it should have (each of the 4 separate 
> images has computed more than 141 representations, which is one quarter 
> of the total). So as far as I understand it, all the images made 
> electric field calculation and started making the same phonon mode 
> calculations in parallel.
> 

Thank you for reporting this. What is not supported is the option
-nimage together with gamma-gamma tricks that you are using in the gamma
calculation.
One easy solution is to set nogg=.TRUE. in the input of the phonon if
you do not need the gamma-gamma tricks to speed-up the calculation.


Andrea




> > In this case, since you stopped the calculation, you can only
> > collect the .xml files in a single _ph0 directory and restart without
> > images. The restart with images is still poorly supported.
> 
>   I would like to restart without -nimage (since it seems to fail in 
> this particular case), but with grid splitting. Do you think this is 
> presomptuous?
> By the way, I had a positive experience restarting with -nimage on 
> another run (at q neq 0) .
> 
> > In the last version of QE, the dielectric constant and effective charges
> > are saved in the tensors.xml file in the _ph0 directory.
> 
> Thank you very much for your help!
> 
> Best regards,
> 
> 
> -- 
> Merlin Méheut, Géosciences et Environnement Toulouse,
> OMP, 14 avenue Edouard Belin, 31400 Toulouse, France
> 
> phone +33 (0)5 61 33 26 17, fax +33 (0)5 61 33 25 60
> 
> ___
> Pw_forum mailing list
> Pw_forum@pwscf.org
> http://pwscf.org/mailman/listinfo/pw_forum

-- 
Andrea Dal CorsoTel. 0039-040-3787428
SISSA, Via Bonomea 265  Fax. 0039-040-3787249
I-34136 Trieste (Italy) e-mail: dalco...@sissa.it


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

Re: [Pw_forum] Using -nimage with phonon at q=0

[Andrea Dal Corso]

 0.000   0.000   0.000
> ---
> 
> It was run on 20 processors using:
> 
> srun ph.x -npool 1 -nimage 4 <  ph.${PREFIX}.inp > ph.${PREFIX}.out
> 
> 
> -- 
> Merlin Méheut, Géosciences et Environnement Toulouse,
> OMP, 14 avenue Edouard Belin, 31400 Toulouse, France
> Université Paul Sabatier - Toulouse 3
> 
>   phone +33 (0)5 61 33 26 17, fax +33 (0)5 61 33 25 60
> 
> ___
> Pw_forum mailing list
> Pw_forum@pwscf.org
> http://pwscf.org/mailman/listinfo/pw_forum

-- 
Andrea Dal CorsoTel. 0039-040-3787428
SISSA, Via Bonomea 265  Fax. 0039-040-3787249
I-34136 Trieste (Italy) e-mail: dalco...@sissa.it


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

Re: [Pw_forum] phonon calculation in Ni on 7x7x7 mesh problem.

[Andrea Dal Corso]

Open Module/parameters.f90 and increase npk. For this calculation you
need at least 27648 x 2 but maybe more for other q points.
Then recompile.

HTH,

Andrea

On Tue, 2015-07-14 at 11:24 -0400, German Samolyuk wrote:
> Dear QE developers, users,
> 
> I'm trying to calculate phonon in Ni with ultrasoft
> pspot Ni.pbe-nd-rrkjus.UPF with 7x7x7 mesh.
> It perfectly works for nxnxn with n <= 6 but fail with larger n starting
> from 7.
> for  q =0.5714286  -0.2857143   0.8571429
> 
> %%
>  Error in routine set_kup_and_kdw (27648):
>  too many k points
>  
> %%
> 
>  stopping ...
> 
> I run
> 
> mpirun ./ph.x -npool 64 < ni.ph.in > ni.ph.out
> 
> 
> with ni.ph.in
> 
> Electron-phonon coefficients for Ni
>  
>  tr2_ph=1.0d-12,
>  prefix='Ni',
>  amass(1)=58.70,
>  outdir='.',
>  fildyn='ni.dyn',
>  ldisp=.true.
>  nq1=7, nq2=7, nq3=7
> /
> 
> 
> 
> 
> 5.1 QE version
> 
> intel based cluster 16 cores per node. QE espresso compiled with intel
> compiler.
> 
> 
> 
> What can cause this problem?
> 
> 
> Thank you,
> 
> German,
> 
> German Samolyuk, ORNL, USA
> ___
> Pw_forum mailing list
> Pw_forum@pwscf.org
> http://pwscf.org/mailman/listinfo/pw_forum

-- 
Andrea Dal CorsoTel. 0039-040-3787428
SISSA, Via Bonomea 265  Fax. 0039-040-3787249
I-34136 Trieste (Italy) e-mail: dalco...@sissa.it


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

Re: [Pw_forum] Bug (or not) with epsil = .false. in PH (trunk version)

[Andrea Dal Corso]

On Sat, 2015-06-13 at 16:38 +0100, Samuel Poncé wrote:
> Dear all,
> 
> I found out that it was impossible de make a phonon calculation without
> calculating the Born effective charge in a semi-conductor even if we set
> epsil = .false.
> 
> This is due to the routine prepare_q.f90 that is called inside do_phonon.f90
> In the routine there is
>  IF ( lgamma ) THEN
> !
> IF ( .NOT. lgauss ) THEN
>!
>! ... in the case of an insulator at q=0 one has to calculate
>! ... the dielectric constant and the Born eff. charges
>! ... the other flags depend on input
>!
>epsil = .TRUE.
>zeu = .TRUE.
>zue = .TRUE.
> 
> 
> This means that if we compute q=Gamma and if we do not have
> gaussian-smearing (i.e. an semi-cond or insulator), then epsil is
> automatically set to TRUE.
> 
> I know that physically one should have such LO/TO splitting but the user
> should be able to choose.
> 
> Maybe this forcing could be reported in the input variable ? or simply put
> the default value to .TRUE. instead of false and not enforcing that rule?
> 
> What do you think?

This is true only when ldisp=.TRUE.. If you do a phonon calculation at
gamma with ldisp=.FALSE. you can set/unset the dielectric constant
calculation with the flag epsil.

It has to be like this, otherwise the dispersion would show a jump at
gamma and the interpolation would not work.

HTH,

Andrea


> 
> Best,
> 
> Samuel Ponce,
> Department of Materials, University of Oxford
> ___________
> Pw_forum mailing list
> Pw_forum@pwscf.org
> http://pwscf.org/mailman/listinfo/pw_forum

-- 
Andrea Dal CorsoTel. 0039-040-3787428
SISSA, Via Bonomea 265  Fax. 0039-040-3787249
I-34136 Trieste (Italy) e-mail: dalco...@sissa.it


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

Re: [Pw_forum] Error in running pw.x for band structure with free lattice reg.,

[Andrea Dal Corso]

You cannot use k points labels with ibrav=0. In order to plot the bands
of the 8 atoms cell, it is necessary to define the path in the cubic
Brillouin zone giving the coordinates of the k points.

HTH,

Andrea


On Sun, 2015-06-07 at 20:33 +0530, Muthu V wrote: 
> Dear All QE Users
> 
> I am trying to get band strucutre for Si crystal. i have edited the example
> input file and used free lattce option (ibrav= 0 instead of ibrav= 2) with
> no of atoms is 8 instead of 2.
> while scf runs and gives sucessful result without any error. but when
> programme enters into band calculation it shows the following error
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> *Program PWSCF v.5.1.1 starts on  7Jun2015 at 20:18:34  This program is
> part of the open-source Quantum ESPRESSO suite for quantum simulation
> of materials; please cite "P. Giannozzi et al., J. Phys.:Condens.
> Matter 21 395502 (2009);  URL http://www.quantum-espresso.org
> <http://www.quantum-espresso.org>",  in publications or presentations
> arising from this work. More details at
> http://www.quantum-espresso.org/quote
> <http://www.quantum-espresso.org/quote> Parallel version (MPI), running
> on 1 processors Waiting for input... Reading input from
> standard
> input 
> Error in routine find_bz_type (1): Wrong
> ibrav 
> stopping ...*
> 
> With this email i have enclosed the script file i have used. How to reslove
> this problem?
> 
> Thank you
> 
> 
> 
> *-*
> 
> *​Muthu V​  *
> 
> 
> 
> 
> 
> *​Madurai Kamaraj University Madurai Tamil
> Nadu​India​---------*
> ___
> Pw_forum mailing list
> Pw_forum@pwscf.org
> http://pwscf.org/mailman/listinfo/pw_forum

-- 
Andrea Dal CorsoTel. 0039-040-3787428
SISSA, Via Bonomea 265  Fax. 0039-040-3787249
I-34136 Trieste (Italy) e-mail: dalco...@sissa.it



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

Re: [Pw_forum] single atom calculations In

[Andrea Dal Corso]

The energy written in the pseudopotential file is the total energy of
the pseudo atom in the configuration used to generate the
pseudopotential not the ground state energy of the pseudo atom and
pseudopotentials are generated using nonmagnetic configurations.

HTH,

Andrea


On Thu, 2015-05-21 at 14:52 +, Gabriel Greene wrote: 
> Dear Espresso users,
> 
> I want to obtain the total energy of an indium atom. In has an electronic 
> configuration of [Kr]4d10 5s2 5p1, so the ground state should be a doublet 
> due to the 1 unpaired p electron, and thus calculation of the isolated atom 
> should yield a magnetization of 1 Bohr Magneton.
> 
> 
> After converging cutoffs and reducing smearing contribution to 0, I found 
> that using In.pbesol-dn-rrkjus_psl.0.2.2.UPF with the following input file I 
> get a total energy of -144.20595136 Ryd, whereas the value of energy 
> specified in this pseudopot file is -144.1890099935588 Ryd.
> 
> If I turn off magnetization (nspin=1), I get -144.18832193 Ryd, which is 
> closer to the value in the pseudopot file, but not realistic in terms of the 
> atomic ground state (it should not be closed shell). My 1st question is why 
> would the calc with no magnetization yield an energy closer to the energy in 
> the pseudopot file, if the ground state for this atom is 1 unpaired electron? 
> Am I misunderstanding something about how to do magnetization in QE?
> 
> I found basically the same behaviour at the suggested cutoffs for 
> In.pbesol-dn-rrkjus_psl.0.2.2.UPF (ecutwfc = 48, ecutrho = 190).
> 
> 
> If I use In.pbe-d-rrkjus.UPF (convergence has also been checked, 
> magnetization = 1 uB), I get -136.47640747 Ryd, which is ~22 Ryd lower than 
> the value specified in In.pbe-d-rrkjus.UPF (-114.86650168195 Ryd). This is 
> quite a large discrepancy - I am wondering if there is something very wrong 
> in my calculations? Apologies if I am making an obvious mistake somewhere.
> 
> 
> My goal is to get the correct ground state total energy for In.pz-n-bhs.UPF, 
> but this file does not specify the total energy, so I am first checking if I 
> can reproduce the correct energies for pseudopots that do specifiy the total 
> energy.
> 
> 
> The input and output files for each case are attached, if there is any other 
> information I can send please let me know.
> 
> 
> Thank you very much for you help,
> Gabriel Greene-Diniz,
> Electronics Theory Group,
> Tyndall National Institute,
> Cork, Ireland.
> https://www.tyndall.ie/content/electronics-theory
> 
> 
> 
> 
> 
> 
> 
> 
> ___
> Pw_forum mailing list
> Pw_forum@pwscf.org
> http://pwscf.org/mailman/listinfo/pw_forum

-- 
Andrea Dal CorsoTel. 0039-040-3787428
SISSA, Via Bonomea 265  Fax. 0039-040-3787249
I-34136 Trieste (Italy) e-mail: dalco...@sissa.it



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

Re: [Pw_forum] scaling spin-orbit coupling

[Andrea Dal Corso]

On Wed, 2015-05-20 at 12:09 -0500, J. D. Burton wrote:
> Greetings,
> 
>  
> 
> I want to artificially increase/decrease the effects of spin-orbit coupling
> for pedagogical purposes (specifically, I want to artificially
> increase/decrease magnetocrystalline anisotropy in a certain magnetic
> system).   Is it sufficient to simply alter the value of 'cau_fact'  when
> generating the fully-relativistic US-PPs using ld1.x?
> 

Presently the increase/decrease of spin-orbit coupling is not
implemented. Changing cau_fact you increase/decrease all the
relativistic effects, both spin-orbit and the scalar relativistic
effects.

HTH,

Andrea


>  
> 
> Thanks,
> 
> J. D.
> 
>  
> 
> 
> 
> 
> 
> J. D. Burton, Ph.D.
> 
>  <mailto:jdburt...@gmail.com> jdburt...@gmail.com
> 
> Research Assistant Professor
> 
> University of Nebraska Lincoln
> 
> Physics and Astronomy
> 
> Office Ph. (402) 472 2499
> 
> Mobile Ph. (402) 419 9918
> 
> 310A Jorgensen Hall
> 
> CV:  <http://tinyurl.com/2avltsc> http://tinyurl.com/2avltsc
> 
> 
> 
> "The job of a scientist is to generate wrong ideas as fast as possible."
> 
> -- Murray Gell-Mann
> 
>  
> 
> ___
> Pw_forum mailing list
> Pw_forum@pwscf.org
> http://pwscf.org/mailman/listinfo/pw_forum

-- 
Andrea Dal CorsoTel. 0039-040-3787428
SISSA, Via Bonomea 265  Fax. 0039-040-3787249
I-34136 Trieste (Italy) e-mail: dalco...@sissa.it


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

Re: [Pw_forum] Questions related to Co and Fe Pseudopotentials in pslib 1and 0.31

[Andrea Dal Corso]

On Mon, 2015-04-27 at 15:20 +, Mostafa Youssef wrote:
> Dear all,
> 
> I have few questions related to the above mentioned PP's.
> 
> (1)  After generating the PAW and USPP versions of these PP (pslib1.0.0) 
> using ld1 code provided with  q.e.5.1.2, I applied the test script.  The 
> output seems to be fine in the case of USPP but for PAW extra few lines are 
> printed. For example, in the case of LDA scalar-rel Fe, I get:
> 
> Making   Fe.pz-n-kjpaw_psl.0.2.4.test.in  ...  Done !
>  3 2 3D   1( 7.00)   -0.41920   -0.41398   -0.00522  !
> Making   Fe.pz-n-kjpaw_psl.1.0.0.test.in  ...  Done
> Making   Fe.pz-n-rrkjus_psl.0.2.4.test.in  ...  Done
> Making   Fe.pz-n-rrkjus_psl.1.0.0.test.in  ...  Done
> Making   Fe.pz-spn-kjpaw_psl.1.0.0.test.in  ...  Done
> Making   Fe.pz-spn-rrkjus_psl.1.0.0.test.in  ...  Done
> 
> And in the case of  Fe-rel I get:
> 
> Making   Fe.rel-pz-n-kjpaw_psl.0.2.4.test.in  ...  Done !
>  3 2 1.5 3D   1( 4.00)   -0.42153   -0.41623   -0.00530  !
>  3 2 2.5 3D   1( 3.00)   -0.41137   -0.40618   -0.00519  !
> Making   Fe.rel-pz-n-kjpaw_psl.1.0.0.test.in  ...  Done
> Making   Fe.rel-pz-n-rrkjus_psl.0.2.4.test.in  ...  Done
> Making   Fe.rel-pz-n-rrkjus_psl.1.0.0.test.in  ...  Done
> Making   Fe.rel-pz-spn-kjpaw_psl.1.0.0.test.in  ...  Done
> Making   Fe.rel-pz-spn-rrkjus_psl.1.0.0.test.in  ...  Done
> 
> Similar output obtained for Co PAW.  Are these extra printed lines indicative 
> of some error in the generation?
> 

The atomic code puts a ! when the difference between all-electron and
pseudo eigenvalues is larger than 5 mRy and the test script searches and
prints those lines. This indicates that the transferability errors of
the Fe pseudopotential of version 0.2.4 was slightly larger than the
threshold. 


> 
> (2) The charge density cutoff recommended (in the UPF files) for these PP is 
> about 12 *ecutwfc. This large cutoff for the charge density was also employed 
> in a recent paper using Fe (pslib0.31) (http://arxiv.org/pdf/1502.01534.pdf) 
> . However, when I did convergence test for the total energy on a unit cell of 
> SrFeO3 , and SrCO3, and it looks like 4* ecutwfc is sufficient to achieve 
> convergence. The convergence in the case of SrFeO3 (pslib0.3, USPP) can be 
> found here (http://web.mit.edu/myoussef/www/Fe_16e_pslib.pdf).  The pink 
> bound indicates that convergence was achieved within 25 mev/unit cell (5 
> meV/atom)  at ecutwfc=85 Ry and ecutrho =4 *ecutwfc. It seems to me that the 
> recommend ecutrho it too strict.  Are there other tests that one needs to 
> perform to check the convergence of charge density cutoff?
> 
The estimate of ecutrho written in the PP file is done using the largest
q vector that is used in the Bessel function expansion of the
pseudization function (ecutrho=2|q|^2). In the case of the charge it
refers to the largest q used to pseudize all the components of the
augmentation Q function. Usually it is a reasonable estimate, but it
remains an indication. The KE cut-off depends also on the quantity that
you are using to check the convergence. 


> (3) The recommended ecutwfc and ecutrho for this set of PP in Pslib do not 
> change from PAW to USPP and do not depend on the functional. I did 
> preliminary tests  and it seems so far that the values work for GGA also work 
> for LDA consistent with the recommendation. I wonder if one could test 
> convergence of ecutwfc and ecutrho for LDA only and apply the outcome to all 
> other semilocal functionals, or are there cases where one encounters 
> different convergence depending on the functional.
> 

It is usually like this (more or less independent on the functional),
but not always. In some cases the PP works for some functionals and not
for others. Maybe one can search PPs for which the KE cut-off is more or
less independent on the functional, but this has not been checked in
pslibrary and I would not be surprised if some PPs do not satisfy this
condition.

HTH,

Andrea

> 
> Thank you in advance for reading and help!
> Mostafa Youssef
> MIT
> 
> 
> ___
> Pw_forum mailing list
> Pw_forum@pwscf.org
> http://pwscf.org/mailman/listinfo/pw_forum

-- 
Andrea Dal CorsoTel. 0039-040-3787428
SISSA, Via Bonomea 265  Fax. 0039-040-3787249
I-34136 Trieste (Italy) e-mail: dalco...@sissa.it


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

Re: [Pw_forum] phonon parallel calculations

[Andrea Dal Corso]

On my PC in a small example only_init + images is working.
Please provide an example (possibly small) that is not working 
if you want more help.

Andrea

On Thu, 2015-02-26 at 00:44 +0100, Carlo Nervi wrote:
> I did some other test with the "GRID" approach above outlined, and I cannot
> understand where I'm wrong.
> I tried different libraries during the compilation process, but while the
> "normal" phonon calculations runs smoothly (but slower, about 1 hour), the
> "GRID" approach always gave me bad (negative) frequencies (but much faster,
> about 10 minutes). I'm using ecut=60 and erho=480
> 
> The phonon results from without using the "-ni 8" approach is:
>  freq (1) =  -0.219517 [THz] =  -7.322283 [cm-1]
>  freq (2) =   0.237288 [THz] =   7.915064 [cm-1]
>  freq (3) =   0.412515 [THz] =  13.760017 [cm-1]
>  freq (4) =   0.888921 [THz] =  29.651216 [cm-1]
>  freq (5) =   1.818322 [THz] =  60.652688 [cm-1]
>  freq (6) =   3.267016 [THz] = 108.975924 [cm-1]
>  freq (7) =   3.94 [THz] = 131.572497 [cm-1]
>  freq (8) =  13.702502 [THz] = 457.066270 [cm-1]
>  freq (9) =  15.98 [THz] = 533.257782 [cm-1]
>  freq (   10) =  21.306349 [THz] = 710.703307 [cm-1]
>  freq (   11) =  29.251729 [THz] = 975.732641 [cm-1]
>  freq (   12) =  31.330252 [THz] =1045.064724 [cm-1]
>  freq (   13) =  40.094614 [THz] =1337.412380 [cm-1]
>  freq (   14) =  91.247143 [THz] =3043.677078 [cm-1]
>  freq (   15) =  94.196285 [THz] =3142.049865 [cm-1]
> 
> If I use the "-ni 8" (GRID) I got:
> freq (1) = -14.549865 [THz] =-485.331266 [cm-1]
>  freq (2) = -10.853880 [THz] =-362.046453 [cm-1]
>  freq (3) =  -9.921965 [THz] =-330.961126 [cm-1]
>  freq (4) =  -9.680609 [THz] =-322.910351 [cm-1]
>  freq (5) =  -9.593462 [THz] =-320.003431 [cm-1]
>  freq (6) =  -9.461406 [THz] =-315.598531 [cm-1]
>  freq (7) =  -8.724432 [THz] =-291.015732 [cm-1]
>  freq (8) =  -4.051543 [THz] =-135.144927 [cm-1]
>  freq (9) =   8.067478 [THz] = 269.102094 [cm-1]
>  freq (   10) =  19.972800 [THz] = 666.220885 [cm-1]
>  freq (   11) =  29.137064 [THz] = 971.907843 [cm-1]
>  freq (   12) =  30.784477 [THz] =1026.859612 [cm-1]
>  freq (   13) =  39.868296 [THz] =1329.863222 [cm-1]
>  freq (   14) =  91.702737 [THz] =3058.874040 [cm-1]
>  freq (   15) =  94.287387 [THz] =3145.088688 [cm-1]
> 
> A lot of negative frequencies appear and sometimes (with a bigger system) I
> got a  in the matdyn file (in this case an error is printed).
> Any idea?
> Anybody else had this kind of problem?
> Thank you,
> 
>  Carlo
> 
> >
> > --
> 
> 
> Prof. Carlo Nervi carlo.ne...@unito.it  Tel:+39 0116707507/8
> Fax: +39 0116707855  -  Dipartimento di Chimica, via
> P. Giuria 7, 10125 Torino, Italy.http://lem.ch.unito.it/
> ___
> Pw_forum mailing list
> Pw_forum@pwscf.org
> http://pwscf.org/mailman/listinfo/pw_forum

-- 
Andrea Dal CorsoTel. 0039-040-3787428
SISSA, Via Bonomea 265  Fax. 0039-040-3787249
I-34136 Trieste (Italy) e-mail: dalco...@sissa.it


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

Re: [Pw_forum] phonon parallel calculations

[Andrea Dal Corso]

The problem is that 'image parallelization' and 'GRID approach' are two
complementary approaches. I think that the two together have not been
tested.
In any case your idea to use only_init and then images is interesting,
but probably will need some tuning.

Andrea


On Thu, 2015-02-26 at 00:44 +0100, Carlo Nervi wrote:
> I did some other test with the "GRID" approach above outlined, and I cannot
> understand where I'm wrong.
> I tried different libraries during the compilation process, but while the
> "normal" phonon calculations runs smoothly (but slower, about 1 hour), the
> "GRID" approach always gave me bad (negative) frequencies (but much faster,
> about 10 minutes). I'm using ecut=60 and erho=480
> 
> The phonon results from without using the "-ni 8" approach is:
>  freq (1) =  -0.219517 [THz] =  -7.322283 [cm-1]
>  freq (2) =   0.237288 [THz] =   7.915064 [cm-1]
>  freq (3) =   0.412515 [THz] =  13.760017 [cm-1]
>  freq (4) =   0.888921 [THz] =  29.651216 [cm-1]
>  freq (5) =   1.818322 [THz] =  60.652688 [cm-1]
>  freq (6) =   3.267016 [THz] = 108.975924 [cm-1]
>  freq (7) =   3.94 [THz] = 131.572497 [cm-1]
>  freq (8) =  13.702502 [THz] = 457.066270 [cm-1]
>  freq (9) =  15.98 [THz] = 533.257782 [cm-1]
>  freq (   10) =  21.306349 [THz] = 710.703307 [cm-1]
>  freq (   11) =  29.251729 [THz] = 975.732641 [cm-1]
>  freq (   12) =  31.330252 [THz] =1045.064724 [cm-1]
>  freq (   13) =  40.094614 [THz] =1337.412380 [cm-1]
>  freq (   14) =  91.247143 [THz] =3043.677078 [cm-1]
>  freq (   15) =  94.196285 [THz] =3142.049865 [cm-1]
> 
> If I use the "-ni 8" (GRID) I got:
> freq (1) = -14.549865 [THz] =-485.331266 [cm-1]
>  freq (2) = -10.853880 [THz] =-362.046453 [cm-1]
>  freq (3) =  -9.921965 [THz] =-330.961126 [cm-1]
>  freq (4) =  -9.680609 [THz] =-322.910351 [cm-1]
>  freq (5) =  -9.593462 [THz] =-320.003431 [cm-1]
>  freq (6) =  -9.461406 [THz] =-315.598531 [cm-1]
>  freq (7) =  -8.724432 [THz] =-291.015732 [cm-1]
>  freq (8) =  -4.051543 [THz] =-135.144927 [cm-1]
>  freq (9) =   8.067478 [THz] = 269.102094 [cm-1]
>  freq (   10) =  19.972800 [THz] = 666.220885 [cm-1]
>  freq (   11) =  29.137064 [THz] = 971.907843 [cm-1]
>  freq (   12) =  30.784477 [THz] =1026.859612 [cm-1]
>  freq (   13) =  39.868296 [THz] =1329.863222 [cm-1]
>  freq (   14) =  91.702737 [THz] =3058.874040 [cm-1]
>  freq (   15) =  94.287387 [THz] =3145.088688 [cm-1]
> 
> A lot of negative frequencies appear and sometimes (with a bigger system) I
> got a  in the matdyn file (in this case an error is printed).
> Any idea?
> Anybody else had this kind of problem?
> Thank you,
> 
>  Carlo
> 
> >
> > --
> 
> 
> Prof. Carlo Nervi carlo.ne...@unito.it  Tel:+39 0116707507/8
> Fax: +39 0116707855  -  Dipartimento di Chimica, via
> P. Giuria 7, 10125 Torino, Italy.http://lem.ch.unito.it/
> ___
> Pw_forum mailing list
> Pw_forum@pwscf.org
> http://pwscf.org/mailman/listinfo/pw_forum

-- 
Andrea Dal CorsoTel. 0039-040-3787428
SISSA, Via Bonomea 265  Fax. 0039-040-3787249
I-34136 Trieste (Italy) e-mail: dalco...@sissa.it


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

Re: [Pw_forum] Fractional translations in magnetic system

[Andrea Dal Corso]

On Sun, 2015-02-22 at 13:57 +0300, MKondrin wrote:
> Dear QE users and developers!
> 
> I want to calculate properties of FeS2 (pyrite), space group Pa-3. 
> First, I use non-relativistic pseudopotentials
> 
>  
> ATOMIC_SPECIES
> Fe 55.845 Fe.pw-mt_fhi.UPF
> S 32.066 S.pw-mt_fhi.UPF
> 
> and to make QE properly find all (24) symmetry operations I had to set 
> parameters nr1=100,nr2=100,nr3=100. In this case this trick works.
> 
> However when I try to use relativistic pseudopotentials
> 
> Fe 55.845  Fe.rel-pbe-spn-kjpaw_psl.0.2.1.UPF
> S 32.066 S.rel-pbe-n-kjpaw_psl.0.1.UPF
> 
> with the spin-orbital interaction ( lspinorb=.true., 
> starting_magnetization=0.5, noncolin=.true., however the system should 
> be diamagnetic) I always get in the output file the message

The code discards the symmetries that do not send the starting
magnetization in itself. If you are interested in the nonmagnetic case
do not set a starting_magnetization.

HTH,

Andrea


> 
>  8 Sym. Ops., with inversion, found (18 have fractional translation)
> 
> If nr* parameters weren't set in input file, then the  automatically 
> generated  FFT grid seems quite compatible with fractional translations:
> 
>  Dense  grid:   263859 G-vectors FFT dimensions: (  80,  80,  80)
> 
>  Smooth grid:84247 G-vectors FFT dimensions: (  60,  60,  60)
> 
> Also setting nr1=100,nr2=100,nr3=100 (that is to the same values as in 
> the non-relativistic case) didn't produce any effect. The program didn't 
> find missing symmetry operations.
> 
> I am in a loss. Thank you for your help in advance (input file is 
> attached to the mail).
> 
> 
> Best regards,
> 
> M. V. Kondrin (High Pressure Physics Institute RAS, Troitsk, Russia)
> plain text document attachment (vc.relax.in)
> 
> calculation = 'vc-relax',
> restart_mode='from_scratch',
> prefix='FeS2',
> etot_conv_thr=5d-4,
> forc_conv_thr=5d-3,
> tstress = .true.,
> tprnfor = .true.,
> pseudo_dir = '../pseudo',
> outdir='./tmp',
> disk_io='low'
>  /
> 
> ibrav=  1, celldm(1) =10.21, nat=  12, ntyp= 2,
> ecutwfc =70, ecutrho=600.0, occupations='smearing',
> lspinorb=.true., starting_magnetization=0.5, noncolin=.true.,
> smearing='methfessel-paxton', degauss=0.02, nr1=100, nr2=100, nr3=100
> /
> 
> mixing_beta = 0.7
> conv_thr =  1.0d-4
> /
> 
>upscale=50.0
> /
> 
> /
> ATOMIC_SPECIES
> Fe 55.845  Fe.rel-pbe-spn-kjpaw_psl.0.2.1.UPF
> S 32.066 S.rel-pbe-n-kjpaw_psl.0.1.UPF
> ATOMIC_POSITIONS crystal
> Fe 0.0 0.0 0.0
> Fe 0.5 0.5 0.0
> Fe 0.5 0.0 0.5
> Fe 0.0 0.5 0.5
> S 0.389 0.389 0.389
> S 0.889 0.111 0.611
> S 0.611 0.889 0.111
> S 0.111 0.611 0.889
> S 0.611 0.611 0.611
> S 0.111 0.889 0.389
> S 0.389 0.111 0.889
> S 0.889 0.389 0.111
> K_POINTS {automatic}
> 5 5 5 0 0 0
> 
> ___
> Pw_forum mailing list
> Pw_forum@pwscf.org
> http://pwscf.org/mailman/listinfo/pw_forum

-- 
Andrea Dal CorsoTel. 0039-040-3787428
SISSA, Via Bonomea 265  Fax. 0039-040-3787249
I-34136 Trieste (Italy) e-mail: dalco...@sissa.it


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

Re: [Pw_forum] phonon parallel calculations

[Andrea Dal Corso]

On Fri, 2015-02-20 at 09:19 +0100, Carlo Nervi wrote:
> Dear QE developers,
> I would like to have your opinion on the procedure I followed in doing
> phonon calculations.
> I found that the use of nimages on my machine (8 numa zones) greatly
> improves the speed of some calculations, but the first (initialization?)
> part of the calculation (epsil=.true., i.e. the Electric Fields
> Calculation) is much faster when performed without the use of "-ni 8"
> switch in ph.x
> 
> So, I tested the following procedure and apparently worked for a small test
> crystal:
> 
> 1) pw.x (vc-relax optimization) without using "-ni"
> 2) scf on the optimized structure containing "wf_collect=.true." and using
> "-ni 8"

pw.x has no image parallelization, so step 2 should be done without
images. The rest should be ok.

HTH,

Andrea


> 3) ph.x containing "only_init = .true." and without using "-ni"
>  This calculate the electric fields
> 4) duplicate the directory _ph0 and copied to _ph1 ... _ph7 (in output
> directory)
> 5) ph.x containing "recover = .true." and using "-ni 8"
>   This is the part where I get most of the speedup
> 6) ph.x of the input used in 5), but now without using "-ni"
>   This is to collect the partial data and produce the final .out
> 
> I would greatly appreciate any comments in understanding if this procedure
> is correct.
> On a small crystal was working, but on a bigger crystal gave error.
> Either the procedure is not completely correct or I have to start to look
> for a problem in the RAM...
> 
> Thank you,
> 
>  Carlo
> 
> ___
> Pw_forum mailing list
> Pw_forum@pwscf.org
> http://pwscf.org/mailman/listinfo/pw_forum

-- 
Andrea Dal CorsoTel. 0039-040-3787428
SISSA, Via Bonomea 265  Fax. 0039-040-3787249
I-34136 Trieste (Italy) e-mail: dalco...@sissa.it


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

Re: [Pw_forum] character-wise

[Andrea Dal Corso]

On Fri, 2015-01-30 at 16:06 +0100, Suza W wrote:
> Hi All,
> 
> Could any of you please confirm me how the colors are chosen in the
> attached figure?
> I mean, what is the real meaning (orbital ? ) of the same color, suppose,
> "blue" ?

Different colors means different representations of the small group of
k.
Different lines have different point groups so coincidence of colors on
different lines has no meaning, but bands with the same color on the
same line (for instance along delta) belong to the same representation.
So for instance along delta all the red bands belong to the delta_1
representation that means that the wavefunctions are totally symmetric,
all the blue bands belong to delta_5 so are two-fold degenerate ecc. 

HTH,

Andrea

> Delta_5 and Sigma_4 imply two different character of the bands, but still
> the same "blue" color for both has been used.
> If colors are not chosen character-wise, then based on which parameter the
> colors are chosen here?
> 
> Thanks in advance,
> 
>Suza W.
>Department of Physics,
>Kakatiya University.
> ___
> Pw_forum mailing list
> Pw_forum@pwscf.org
> http://pwscf.org/mailman/listinfo/pw_forum

-- 
Andrea Dal CorsoTel. 0039-040-3787428
SISSA, Via Bonomea 265  Fax. 0039-040-3787249
I-34136 Trieste (Italy) e-mail: dalco...@sissa.it


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

Re: [Pw_forum] Error in bands.x

[Andrea Dal Corso]

The problem is k point 89

0.300.300.001.0

It is very close to a high symmetry point, but it is not the high
symmetry point

0.3330.3330.001.0

and this confuses the routine of QE that finds the small group of k.
It finds the identity and one rotation of 120, but it misses the other
rotation.   

In your case the solution is to give the k points with more digits.


HTH,

Andrea

On Sun, 2015-01-25 at 13:17 +0600, Khalid Ibne Masood Khalid wrote:
> Dear Sir,
> I have attached my example here. I have attached only the bash script file
> and the erroneous output file. You need to edit the script file a little
> bit if you wish to run the file.
> 
> Thank you
> 
> On Sat, Jan 24, 2015 at 9:19 PM, Paolo Giannozzi <paolo.gianno...@uniud.it>
> wrote:
> 
> > On Sat, 2015-01-24 at 00:09 +0600, Khalid Ibne Masood Khalid wrote:
> > > I am using Quantum Espresso 5.1.1 in ubuntu 13.04
> >
> > then please provide an example that produces the error you mention
> > and that can be easily run
> >
> > Paolo
> > >
> > >
> > > Thank you
> > >
> > >
> > > Khalid Ibne Masood
> > > M.Sc student
> > > Bangladesh University of Engineering and Technology (BUET)
> > >
> > > On Sat, Jan 24, 2015 at 12:03 AM, Paolo Giannozzi
> > > <paolo.gianno...@uniud.it> wrote:
> > > On Fri, 2015-01-23 at 23:30 +0600, Khalid Ibne Masood Khalid
> > > wrote:
> > >
> > >
> > > >  I am having a problem with bands.x
> > >
> > > version?
> > >
> > > --
> > >  Paolo Giannozzi, Dept. Chemistry,
> > >  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 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

-- 
Andrea Dal CorsoTel. 0039-040-3787428
SISSA, Via Bonomea 265  Fax. 0039-040-3787249
I-34136 Trieste (Italy) e-mail: dalco...@sissa.it


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

Re: [Pw_forum] Thermo for ibrav=6 (tetragonal cell)

[Andrea Dal Corso]

If something is not implemented it cannot work. This is a present
limitation of the thermo_pw code. All the software needed to deal with
anharmonic properties of anisotropic systems has not been written yet.
It will require a substantial amount of work, so do not expect it soon.

Andrea



On Wed, 2015-01-07 at 13:33 +0100, Suza W wrote:
> Dear Prof. Giannozzi,
> 
> grep noncubic -B1 thermo_readin.f90
> 
> 
> gives :
> 
> IF (ibrav > 3 .AND. what=='mur_lc_t') CALL errore('thermo_pw','option not &
>   & available for noncubic systems',1)
> 
> Thanks and regards,
> Suza.
> 
> 
> On Wed, Jan 7, 2015 at 12:12 PM, Paolo Giannozzi <paolo.gianno...@uniud.it>
> wrote:
> 
> > On Wed, 2014-12-24 at 15:07 +0100, Suza W wrote:
> >
> > >  Error in routine thermo_pw (1):
> > >  option not  available for noncubic systems
> >
> > $ grep  thermo_pw */*.f90 */*/*.f90
> >
> > nothing found
> >
> > --
> >  Paolo Giannozzi, Dept. Chemistry,
> >  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

-- 
Andrea Dal CorsoTel. 0039-040-3787428
SISSA, Via Bonomea 265  Fax. 0039-040-3787249
I-34136 Trieste (Italy) e-mail: dalco...@sissa.it


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

Re: [Pw_forum] about C2/c point group symmetry of a monoclinic lattice.

[Andrea Dal Corso]

On Thu, 2014-12-18 at 19:29 +, Mutlu COLAKOGULLARI wrote:
> Dear Carlo, Andrea and Paolo;
>   The taking responds and advices from people who has experienced makes 
> me happy.
>   As Paolo and Carlo also said, cif2qe.sh is not working properly, (at 
> least for this case). Therefore, I used the other codes for double cross 
> check: pymatgen and cif2cell. The conventional cell has 64 atoms whereas its 
> primitive has 32 atoms. 
>   Pymatgen is very proper for POSCAR output because it takes symmetry 
> analysis depend on Curtarolo-Setyawan's paper 
> [http://arxiv.org/abs/1004.2974v1] (MCLC5 - it gives also gamma angle, for 
> this case)...so, it is not matching with QE's ibrav settings depend on cell 
> vectors. Cif2Cell code gives the exactly same CELL_PARAMETERS card with 
> Quantum-ESPRESSO's ibrav=-13...that is the reason why I chose Cif2Cell code.
>   Andrea, it was my fault. I had been complicated among space groups(2/m 
> for sg:12 and 2/C for sg:15) and Herman-Mauguin notations(2/m for space 
> groups 12-15). You said that ”Using ibrav=-13 it is not necessary to add 
> these atoms in the list of atoms inside the unit cell." Andrea, you mean that 
> could I decrease the number of atoms in primitive cell if they have 
> symmetrized by last 4 symmetry operations in this case? By this way, the cell 
> lost half of atoms inside which is good news for computational resources. 
>   
I think so. As far as I understand there are two possibilities:
1) You apply all the 8 symmetry operations and use ibrav=-12 (simple
monoclinic) obtaining 64 atoms.
2) You apply only the first four symmetry operations and use ibrav=-13
(one base centered monoclinic). Note however that in this case you have
to refer the positions to the base centered monoclinic axes, while the
positions that you obtain applying the symmetry are still referred to
the simple monoclinic cell. The base centered monoclinic cell has one
half the number of atoms of the simple monoclinic cell.

In no cases however QE will find 8 symmetry operations. In the first
case because fractional translations will be disabled (the cell  is
actually a supercell). In the second case because there are only 4.
It is not a question of notations, the point group for the space group
C2/c is C_2h (that has 4 operations), there is no way to obtain a larger
point group.

HTH,

Andrea



> With my best wishes,
>Mutlu.
> 
> --Dr. Mutlu COLAKOGULLARITrakya 
> Universitesi Fen FakultesiFizik Bolumu22030 Merkez-EDİRNE
> ___
> Pw_forum mailing list
> Pw_forum@pwscf.org
> http://pwscf.org/mailman/listinfo/pw_forum

-- 
Andrea Dal CorsoTel. 0039-040-3787428
SISSA, Via Bonomea 265  Fax. 0039-040-3787249
I-34136 Trieste (Italy) e-mail: dalco...@sissa.it


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

Re: [Pw_forum] about C2/c point group symmetry of a monoclinic lattice.

[Andrea Dal Corso]

 cif2cell code using the cif file as 
> following:
> _journal_issue   12
> _journal_name_full   'Chemistry of Materials'
> 
> _journal_page_first  3120
> _journal_volume  23
> _journal_year2011
> _chemical_formula_structural 'Tl Ga Se2'
> _chemical_formula_sum'Ga Se2 Tl'
> _chemical_name_systematic'Thallium Gallium Selenide'
> _space_group_IT_number   15
> _symmetry_Int_Tables_number  15
> _symmetry_space_group_name_Hall  '-C 2yc'
> _symmetry_space_group_name_H-M   'C 1 2/c 1'
> _audit_creation_date 2008/02/01
> _cell_angle_alpha90.
> _cell_angle_beta 99.993(6)
> _cell_angle_gamma90.
> _cell_formula_units_Z16
> _cell_length_a   10.779(2)
> _cell_length_b   10.776(1)
> _cell_length_c   15.663(5)
> _cell_volume 1791.7(7)
> _refine_ls_R_factor_all  0.0652
> _[local]_cod_data_source_filecm200946y_si_002.cif
> _[local]_cod_data_source_block   157752-ICSD
> _[local]_cod_chemical_formula_sum_orig 'Ga1 Se2 Tl1'
> _cod_original_cell_volume1791.73
> _cod_database_code   4000782
> loop_
> _symmetry_equiv_pos_site_id
> _symmetry_equiv_pos_as_xyz
> 1 'x, -y, z+1/2'
> 2 '-x, -y, -z'
> 3 '-x, y, -z+1/2'
> 4 'x, y, z'
> 5 'x+1/2, -y+1/2, z+1/2'
> 6 '-x+1/2, -y+1/2, -z'
> 7 '-x+1/2, y+1/2, -z+1/2'
> 8 'x+1/2, y+1/2, z'
> loop_
> _atom_site_aniso_label
> _atom_site_aniso_type_symbol
> _atom_site_aniso_U_11
> _atom_site_aniso_U_22
> _atom_site_aniso_U_33
> _atom_site_aniso_U_12
> _atom_site_aniso_U_13
> _atom_site_aniso_U_23
> Tl1 Tl1+ 0.052(6) 0.063(5) 0.06(2) -0.022(3) 0.005(8) 0.000(5)
> Tl2 Tl1+ 0.044(6) 0.044(6) 0.07(2) -0.022(3) 0.005(8) 0.002(5)
> Ga1 Ga3+ 0.015(9) 0.001(6) 0.05(3) 0.009(6) 0.01(2) -0.019(9)
> Ga2 Ga3+ 0.019(7) 0.037(9) 0.00(3) -0.008(9) -0.01(1) -0.01(1)
> Se1 Se2- 0.03(1) 0.02(1) 0.06(5) 0. 0.02(2) 0.
> Se2 Se2- 0.006(9) 0.001(7) 0.06(4) 0. -0.01(2) 0.
> Se3 Se2- 0.04(1) 0.05(1) 0.01(4) 0.01(1) -0.01(2) -0.02(1)
> Se4 Se2- 0.012(6) 0.021(7) 0.06(4) 0.01(1) -0.018(9) -0.018(5)
> Se5 Se2- 0.05(1) 0.06(1) 0.00(4) -0.053(9) -0.01(2) -0.02(1)
> loop_
> _atom_site_label
> _atom_site_type_symbol
> _atom_site_symmetry_multiplicity
> _atom_site_Wyckoff_symbol
> _atom_site_fract_x
> _atom_site_fract_y
> _atom_site_fract_z
> _atom_site_occupancy
> _atom_site_attached_hydrogens
> Tl1 Tl1+ 8 f 0.4647(6) 0.3109(5) 0.1140(9) 1. 0
> Tl2 Tl1+ 8 f 0.2844(4) 0.0623(5) 0.3864(8) 1. 0
> Ga1 Ga3+ 8 f 0.100(1) 0.191(2) 0.162(2) 1. 0
> Ga2 Ga3+ 8 f 0.145(1) 0.438(1) 0.339(2) 1. 0
> Se1 Se2- 4 e 0. 0.054(2) 0.250 1. 0
> Se2 Se2- 4 e 0. 0.574(1) 0.250 1. 0
> Se3 Se2- 8 f 0.207(1) 0.062(1) 0.071(2) 1. 0
> Se4 Se2- 8 f 0.262(1) 0.310(1) 0.252(2) 1. 0
> Se5 Se2- 8 f 0.048(2) 0.312(1) 0.438(3) 1. 0
> loop_
> _atom_type_symbol
> _atom_type_oxidation_number
> Ga3+ 3
> Se2- -2
> Tl1+ 1
> loop_
> _citation_id
> _citation_year
> _citation_page_first
> _citation_page_last
> primary 2007 663 666
> Are there something wrong in my input file or primitive cell?
> With my best wishes,
>  Mutlu.
> 
> --Dr. Mutlu COLAKOGULLARITrakya 
> Universitesi Fen FakultesiFizik Bolumu22030 Merkez-EDİRNE
> ___
> Pw_forum mailing list
> Pw_forum@pwscf.org
> http://pwscf.org/mailman/listinfo/pw_forum

-- 
Andrea Dal CorsoTel. 0039-040-3787428
SISSA, Via Bonomea 265  Fax. 0039-040-3787249
I-34136 Trieste (Italy) e-mail: dalco...@sissa.it


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

Re: [Pw_forum] About spin orbit calculation

[Andrea Dal Corso]

On Fri, 2014-12-12 at 12:03 +0100, Gabriele Sclauzero wrote:
> Dear Robert,
> 
> The most important references are:
> 
> A. Dal Corso and A. Mosca Conte, 
> Spin-orbit coupling with ultrasoft pseudopotentials: application to Au and 
> Pt, 
> Phys. Rev. B 71, 115106 (2005)
> 
> A. Dal Corso, 
> Projector augmented-wave method with spin-orbit coupling: applications to 
> simple solids and zincblende-type semiconductors, 
> Phys. Rev. B 86, 085135 (2012)

Much more details and explanations in:

A. Dal Corso, 
Projector augmented-wave method: application to relativistic
spin-density functional theory, 
Phys. Rev. B 82, 075116 (2010).

Pseudopotentials with spin-orbit and other tests:

A. Dal Corso, 
Pseudopotentials periodic table: from H to Pu,
Comp. Material Science 95, 337 (2014).

HTH,

Andrea



> and references therein. I think it is neither exact nor “pertubational”. Its 
> main approximations are related to the “pseudization” of the atomic wave 
> functions, as in the scalar relativistic case, plus the neglect of the “small 
> component” in the Dirac equation, plus other details that I don’t know 
> exactly.
> 
> Hope this helps,
> 
> Gabriele
> 
> 
> > Dear Users
> > I would like to know how the spin orbit interaction is calculated by 
> > pw.x. Is the calculation exact or approximate by perturbations ?.
> > 
> > If you know some reference please said me where I might search.
> > 
> > Thank you for you attention.
> > Robert M. Guzman A.
> > Instituto Balseiro.
> > 
> > ___
> > Pw_forum mailing list
> > Pw_forum@pwscf.org
> > http://pwscf.org/mailman/listinfo/pw_forum
> 
> 
> Dr. Gabriele Sclauzero
> Materials Theory (D_MATL)
> ETH Zurich, HIT G 43.2
> Wolfgang-Pauli-Str. 27
> 8093 Zürich, Switzerland
> 
> Phone +41 44 633 94 10
> Fax +41 44 633 14 59
> gabriele.sclauz...@mat.ethz.ch
> www.theory.mat.ethz.ch/people/postdocs/gsclauze
> 
> 
> ___
> Pw_forum mailing list
> Pw_forum@pwscf.org
> http://pwscf.org/mailman/listinfo/pw_forum

-- 
Andrea Dal CorsoTel. 0039-040-3787428
SISSA, Via Bonomea 265  Fax. 0039-040-3787249
I-34136 Trieste (Italy) e-mail: dalco...@sissa.it


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

Re: [Pw_forum] Symmetry not recognized in spin-orbit calculations

[Andrea Dal Corso]

Thank you for reporting this. There was actually a problem with rounding
errors in the search of point group symmetry. Now I corrected the bug in
the SVN version.

Andrea 


On Wed, 2014-11-26 at 17:27 -0500, Lin, Yangzheng wrote:
> Thanks Paolo, I got another solution too by modifying the lattice
> parameters a little bit to,
> 
> CELL_PARAMETERS (alat=  1.)
>0.0   5.440045000   5.440045000
>5.440045000   0.0   5.440045000
>5.440045000   5.440045000   0.0
> 
> I don't know the reason, but the symmetry problem was solved.
> 
> Yangzheng
> 
> 
> On Wed, Nov 26, 2014 at 4:26 PM, Paolo Giannozzi <paolo.gianno...@uniud.it>
> wrote:
> 
> > On Wed, 2014-11-26 at 13:09 -0500, Lin, Yangzheng wrote:
> >
> > >  Error in routine tipo_sym (1):
> > >  symmetry not recognized
> > > Does anyone know how to solve this problem?
> >
> > not really a solution but a workaround: remove the following line
> >
> > >   verbosity = 'high',
> >
> > P.
> >
> > --
> > Paolo Giannozzi, Dept. Chemistry,
> > 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

-- 
Andrea Dal CorsoTel. 0039-040-3787428
SISSA, Via Bonomea 265  Fax. 0039-040-3787249
I-34136 Trieste (Italy) e-mail: dalco...@sissa.it


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

Re: [Pw_forum] bands.x

[Andrea Dal Corso]

On Tue, 2014-11-11 at 11:40 -0500, Manu Hegde wrote:
> I am using this paper as reference for my K-points.
> http://journals.aps.org/prb/pdf/10.1103/PhysRevB.74.195123

Please note that the option tpiba_b requires the k points in cartesian
coordinates and in units of two pi over alat. Probably you need to use
the crystal_b option if the k points are in crystal coordinates.
Furthermore the weights of the k points must be the number of points in
each line.

xk1(1) xk1(2) xk1(3) nk1 (number of points of the line from xk1 to xk2)
xk2(1) xk2(2) xk2(3) number of points of the next line

HTH,

Andrea

> 
> Manu
> 
> On Tue, Nov 11, 2014 at 3:37 AM, Paolo Giannozzi <paolo.gianno...@uniud.it>
> wrote:
> 
> > On Mon, 2014-11-10 at 16:05 -0500, Manu Hegde wrote:
> >
> > > My outdir and prefix are consistent. I have double checked it. Could
> > > you please point me which file has the error?
> >
> > I don't know and cannot know what you did, but I know for sure that
> > your input files do not yield the problem you mention. Not for any
> > version different from v.5.0.2 (that had the problem you mention).
> >
> > P.
> >
> > --
> >  Paolo Giannozzi, Dept. Chemistry,
> >  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

-- 
Andrea Dal CorsoTel. 0039-040-3787428
SISSA, Via Bonomea 265  Fax. 0039-040-3787249
I-34136 Trieste (Italy) e-mail: dalco...@sissa.it


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

Re: [Pw_forum] band structure symmetry

[Andrea Dal Corso]

On Sat, 2014-10-25 at 11:50 +0900, pou...@flex.phys.tohoku.ac.jp wrote:
> Dear all
> Hi,
> When I calculate band structure in the out put file there are some
> information that I do not know what their interpretation are.
> 
> the number of band, its energy, 1-->(what does it mean 1?), symmetry of
> wavefunction, D_1 or D_2 or D_3 or D_4( I do not know what they are), S_1
> or S_2 or S_3 or S_4 (What are they?)
> 


1 -> degeneracy of the band

D_1, etc,
S_1, etc 

are alternative names of the same irreducible representation A_1. 
In the literature different names are used for the same representation, 
some of them are reported in the output.

HTH,

Andrea



>  e(  4 -  4) = -3.27325  eV 1   --> B_2  D_4  S_4
>  e(  5 -  5) = -2.47818  eV 1   --> A_2  D_2  S_2
>  e(  6 -  6) =  7.61142  eV 1   --> B_2  D_4  S_4
>  e(  7 -  7) =  9.87798  eV 1   --> A_1  D_1  S_1
>  e(  8 -  8) = 10.36830  eV 1   --> B_1  D_3  S_3
>  e(  9 -  9) = 10.67370  eV 1   --> A_1  D_1  S_1
>  e( 10 - 10) = 11.78493  eV 1   --> B_2  D_4  S_4
> 
> 
> I will appreciate you to help me to understand the meaning of them.
> 
> Thanks in advance !
> 
> P. Ayria
> PhD. student of Tohoku university
> 
> _______
> Pw_forum mailing list
> Pw_forum@pwscf.org
> http://pwscf.org/mailman/listinfo/pw_forum

-- 
Andrea Dal CorsoTel. 0039-040-3787428
SISSA, Via Bonomea 265  Fax. 0039-040-3787249
I-34136 Trieste (Italy) e-mail: dalco...@sissa.it


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

Re: [Pw_forum] dipole correction and slab phonon

[Andrea Dal Corso]

phonon + electric field is not implemented.
From the phonon.f90 file:

  ! Not implemented in ph.x:
  ! [6] [5] + constraints on the magnetization
  ! [7] [6] + Hubbard U
  ! [8] [7] + Hybrid functionals
  ! [9] ? + External Electric field
  ! [10] ? + nonperiodic boundary conditions.

HTH,

Andrea

On Tue, 2014-10-14 at 16:56 +0800, 秦新明 wrote:
> Dear all
>   I got a serious problem when using QE to apply dipole corrections in the 
> phonon calculation for a slab with a large dipole moment. I perform the 
> phonon calculations with and without the dipole correction. And I find that 
> the corresponding phonons are very different. When the dipole correction is 
> applied, two acoustic branches are imaginary at high frequencies. However, 
> without the dipole correction, all frequencies are positive and the phonon 
> dispersion is similar with the reslut form the frezon-phonon calculction.  
> Can the dipole correction be neglected ?
>   Furthermore, both pw.x and ph.x do not support the symmetry when appling 
> the dipole correction. Then a large number of k or q points are required in 
> practical calculations. Can ph.x calcuclate phonons well with the dipole 
> correction ?
>   I'm thirsty for your reply. Thanks!
>  
>   Best regards
> 
>   Xinming
> ___
> Pw_forum mailing list
> Pw_forum@pwscf.org
> http://pwscf.org/mailman/listinfo/pw_forum

-- 
Andrea Dal CorsoTel. 0039-040-3787428
SISSA, Via Bonomea 265  Fax. 0039-040-3787249
I-34136 Trieste (Italy) e-mail: dalco...@sissa.it


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

[Pw_forum] Two problems with ph.x and nimage option

[Andrea Dal Corso]

On Tue, 2014-10-07 at 15:29 -0700, Florian Altvater wrote:
> Hi,
> I am using QE 5.0.0 and am trying to do phonon calculations on the
> naphthalene crystal with the nimage option. I encounter two different
> problems:
> 
> 1) When I use a k-point grid of 2x3x2 for the scf calculation I run the
> following commands:
> 
> aprun -n 192 pw.x -nimage 1 -npool 8 < scf.in <http://scf.in> > scf.out
> aprun -n 1728 ph.x -nimage 9 -npool 8 < phG.in > phG.out
> aprun -n 192 ph.x -nimage 1 -npool 8 < phGc.in > phGc.out
> 
> phGc.in is the same file as phG.in with the additional parameter
> recover=.true.
> Looking at the output files (phG.out and out.[1-8]_0), everything seems
> fine. When I run the second phonon calculation to finish up, it ony
> recognizes that the first 11 modes have been done (they are in phG.out),
> but states for the other irreps "to be done". It then starts calculating
> the modes starting with representation 12 but then crashes with a davcio
> error. Apparently the davcio error could be related to a lot of things.
> But why doesn't ph.x recognize that all the irreps have already been
> calculated?

Please update to QE 5.1, version 5.0.0 is no more supported. As a
minimum it has to be updated to 5.0.3 to use images. The image
parallelization was very experimental in QE 5.0.0. It seems that the
files produced by the different images were not copied in the
tmp_dir/_ph0/{prefix}.phsave directory. Please also check that the
Image_example is working in your machine before running a big job.

HTH,

Andrea


> 
> 2) Using a k-point grid of 3x4x3 for the scf calculation I run the same
> commands but use -npool 19 and 456 and 4104 cores respectively. This
> time the calculation already crashes during the first phonon
> calculation, just a few seconds after the first image is done
> (representations 1-11). It spits out lots of errors like:
> 
> PGFIO-F-204/CLOSE/unit=20/illegal use of a read-only file.
>  File name = ./naph_crys.wfc6unformatted, direct access   record = 1
>  In source file close_phq.f90, at line number 38
> 
> I couldn't find anything related to this error. Any ideas? Which input
> files or other information would you need in order to debug?
> 
> On another machine, running the 2x3x2 calculation on just one image
> works just fine. I just would like to speed up the calculation using the
> image method.
> 
> Thanks for your help,
> Florian
> 
> --
> PhD candidate
> UC Berkeley/LBNL
> ___
> Pw_forum mailing list
> Pw_forum at pwscf.org
> http://pwscf.org/mailman/listinfo/pw_forum

-- 
Andrea Dal CorsoTel. 0039-040-3787428
SISSA, Via Bonomea 265  Fax. 0039-040-3787249
I-34136 Trieste (Italy) e-mail: dalcorso at sissa.it

[Pw_forum] Phonon band with spin-orbit coupling

[Andrea Dal Corso]

>From the q2r.f90 file:
 ! fildyn :  input file name (character, must be specified)
  !   "fildyn"0 contains information on the q-point grid
  !   "fildyn"1-N contain force constants C_n = C(q_n)
  !   for n=1,...N, where N is the number of q-points
  !   in the irreducible brillouin zone
  !   Normally this should be the same as specified
  !   on input to the phonon code
  !   In the non collinear/spin-orbit case the files 
  !   produced by ph.x are in .xml format. In this case 
  !   fildyn is the same as in the phonon code+the .xml 
  !   extension.

q2r reads the .xml files. You have only to add the .xml extension in the
input fildyn name.

HTH,

Andrea 


-- 
Andrea Dal CorsoTel. 0039-040-3787428
SISSA, Via Bonomea 265  Fax. 0039-040-3787249
I-34136 Trieste (Italy) e-mail: dalcorso at sissa.it



On Fri, 2014-09-26 at 08:25 +0800, Dingfu Shao wrote:
> Dear all,
> 
> Usually, the phonon band can be obtained using q2r.x and matdyn.x form
> *.dyn files.
> 
> Recently, I  did a phonon calculation with spin-orbit coupling. I found the
> obtained filedyn  was formated as " *.xml". Therefore, q2r.x can not work.
> 
> In such condition, how can I plot the phonon band?
> 
> Yours
> 
> DF Shao
> 
> 
> 
> 
> ___
> Pw_forum mailing list
> Pw_forum at pwscf.org
> http://pwscf.org/mailman/listinfo/pw_forum

[Pw_forum] Phonon calculation

[Andrea Dal Corso]

I would start checking convergence with respect to tr2_ph.

HTH,

Andrea



On Mon, 2014-08-25 at 07:25 +0200, Vincenzo Verdolino wrote:
> ___
> Pw_forum mailing list
> Pw_forum at pwscf.org
> http://pwscf.org/mailman/listinfo/pw_forum

-- 
Andrea Dal CorsoTel. 0039-040-3787428
SISSA, Via Bonomea 265  Fax. 0039-040-3787249
I-34136 Trieste (Italy) e-mail: dalcorso at sissa.it

[Pw_forum] running example si example file for band structure - reg.,

[Andrea Dal Corso]

Thank you for reporting this. There is actually a bug. a,b,c etc
parameters are not working with k-points labels, so if you switch to
a,b,c you have also to write the k points coordinates of the path to
plot the bands, substituting:

   L 20
   gG 20
X 0
   1.0 1.0 0.0 30
   gG  1

with
0.5 0.5 0.5 20
0.0 0.0 0.0 20
1.0 0.0 0.0 0
1.0 1.0 0.0 30
0.0 0.0 0.0 1

HTH,

Andrea


On Fri, 2014-07-25 at 10:26 +0530, Muthu V wrote:
> Dear QE'ians
> 
> recently i installed QE-5.1 in my PC. everything went fine. i successfully
> got o/p for si run_example file which is in espresso/PP/examples/example01/
> folder.
> 
> i changed celldm(1) for si to A,B,C and cosAB, cosAC, cosBC values.  as
> celldm(1) =10.2 so A = 5.3976=B=C and cosAB=cosBC=cosAC=0
> 
> 
> i problem is. when i try with celldm(1) the run script runs well. but if i
> chage celldm(1) to  a,b,c, cosAb,cosAC,cosBC values the i got the following
> error message.
> 
> slave2 at slave2-CN:~/espresso-5.1/PP/examples/example01$ ./si
> 
> /home/slave2/espresso-5.1/PP/examples/example01 : starting
> 
> This example shows how to use pw.x and postprocessing codes to make a
> contour plot in the [110] plane of the charge density for Si, and to
> plot the band structure of Si.
> 
>   executables directory: /home/slave2/espresso-5.1/bin
>   pseudo directory:  /home/slave2/espresso-5.1/pseudo
>   temporary directory:   /home/slave2/espresso-5.1/tempdir
>   checking that needed directories and files exist... done
> 
>   running pw.x as: /home/slave2/espresso-5.1/bin/pw.x  -nk 1 -nd 1
> -nb 1 -nt 1
>   running pp.x as: /home/slave2/espresso-5.1/bin/pp.x  -nk 1 -nd 1
> -nb 1 -nt 1
>   running plotrho.x as:  /home/slave2/espresso-5.1/bin/plotrho.x
>   running bands.x as:  /home/slave2/espresso-5.1/bin/bands.x  -nk 1 -nd
> 1 -nb 1 -nt 1
>   running plotband.x as: /home/slave2/espresso-5.1/bin/plotband.x
> 
>   running the scf calculation... done
>   running pp.x to do a 2-d plot of the charge density... done
>   running plotrho.x to generate rho.ps... done
> 
>   running pp.x to do another 2-d plot of the charge density... done
>   generating si.charge.png... done
>   generating contour plot of the charge si.contour.ps... done
> 
> 
> *  running the band-structure calculation for Si...application called
> MPI_Abort(MPI_COMM_WORLD, 1) - process 0Error condition encountered during
> test: exit status = 1*
> Aborting
> slave2 at slave2-CN:~/espresso-5.1/PP/examples/example01$
> 
> 
> ple fine the si.band.out and CRASH report i attached. in this file the
> error message printed as
>  task # 0
>  from latgen : error # 2
>  wrong celldm(1)
> 
> can any one help to resolve this problem. whether band.x accept only
> celldm(i)'s?
> 
> thank you in advance.
> 
> 
> *
> *Muthu.V  Madurai Kamaraj Universit**y*
> 
> *
> ___
> Pw_forum mailing list
> Pw_forum at pwscf.org
> http://pwscf.org/mailman/listinfo/pw_forum

-- 
Andrea Dal CorsoTel. 0039-040-3787428
SISSA, Via Bonomea 265  Fax. 0039-040-3787249
I-34136 Trieste (Italy) e-mail: dalcorso at sissa.it

[Pw_forum] about kind of ibrav, cell parameters and thermo_pw.

[Andrea Dal Corso]

On Sun, 2014-06-29 at 02:43 +0300, Mutlu COLAKOGULLARI wrote:
> Hello,
> 
> MAIN PROBLEM:
> I want to use thermo_pw code but it does not allow to use of ibrav=0.
> 

These are present limitations of thermo_pw. BZ plot and paths with
Ibrav=13, 14, 0 are not implemented. For the other properties there is
very limited support and symmetry is not used.


Andrea


> STORY:
> The conventional cell of crystalline interested  is monoclinic type with 
> Beta angle (ibrav=-12). In order to find primitive cell I used pymatgen 
> code and then aconvasp-online. The final cell is MCLC5 type with cell 
> parameters (W. Setyawan and S. Curtarolo's paper; 
> http://arxiv.org/abs/1004.2974v1)  as following:
> 
> CELL_PARAMETERS angstrom
>   5.388   5.389500241922250.00
> -5.3880005.389500241922250.00
>   0.002.71796558242205   15.42537623828894
> 
> I have tested the MCLC5 cell type with xcrysden-kpath visualization. 
> Everything is looking fine to me. In pw.x code I can use it safely with 
> ibrav=0 but thermo_pw code.  The cell vectors are different from 
> ibrav=12,-12,13. If I transform the Niggle form then I get the 
> tricilinic type which is not proper for thermo_pw code, too. Here is the 
> end of my knowledge.
> 
> QUESTION:
> How can I transform the above cell parameters to the correct kind of 
> ibrav type and celldm(1,...,6)?
> 
> with my best wishes,
> 
>   Mutlu.
> 
> -- 
> PhD. Mutlu ?OLAKO?ULLARI
> Trakya ?niversitesi
> Fen Fak?ltesi
> Fizik B?l?m?
> _______
> Pw_forum mailing list
> Pw_forum at pwscf.org
> http://pwscf.org/mailman/listinfo/pw_forum

-- 
Andrea Dal CorsoTel. 0039-040-3787428
SISSA, Via Bonomea 265  Fax. 0039-040-3787249
I-34136 Trieste (Italy) e-mail: dalcorso at sissa.it

[Pw_forum] negative phonon frequencies for 1-D polymer chain

[Andrea Dal Corso]

Did you apply the 5.0.3 patch to QE 5.0.2? Without the patch, the phonon
code gives wrong frequencies for some q points. 

HTH,

Andrea


On Mon, 2014-04-14 at 01:19 -0400, ankit jain wrote:
> Hello Sanjeev,
> 
> The pseudopotentials I am using are
> H.pz-vbc.UPF<http://www.quantum-espresso.org/wp-content/uploads/upf_files/H.pz-vbc.UPF>
>  and 
> C.pz-vbc.UPF<http://www.quantum-espresso.org/wp-content/uploads/upf_files/C.pz-vbc.UPF>
> 
> 
> Pseudopotential type: NORMCONS
> Method: Von Barth-Car (direct fit)
> Functional type: Perdew-Zunger (LDA) exch-corr
> scalar relativistic
> 
> 
> I have tried kgrid of 1*1*6 and 1*1*12, but both give negative frequencies.
> 
> 
> 
> On Mon, Apr 14, 2014 at 12:18 AM, Sanjeev Gupta
> wrote:
> 
> > what is kind of pseudopotential?
> > How much k-point?
> >
> >
> > wishes
> > sanjeev
> >
> >
> > On Sun, Apr 13, 2014 at 9:25 AM, Ankit  > gmail.com>wrote:
> >
> >> Hello QE developers and users,
> >>
> >> I am trying to calculate phonon dispersion using ph.x and matdyn.x
> >> routines of QE and I am stuck woth negative frequencies for a while now.
> >>
> >> I have a 1-D chain of polyethylene which has 6 atoms in the unit-cell.
> >> The polymer chain is aligned in z-direction and I have added vacuum on
> >> x- and y- direction. I did the structure relaxation and I am getting
> >> total force after relaxtion as 0.20, which I guess is sufficiently
> >> small.
> >>
> >> After relaxation, when I am trying to calculate phonon dispersion using
> >> ph.x and matdyn.x I am getting netting frequencies for some of the
> >> phonon modes. I  searched online and on QE mailing list and tried couple
> >> of different things:
> >>
> >> 1. The negative frequencies are appearing for non-gamma point as well,
> >> so I guess its not a ASR issue. Anyway, I am using ASR but even after
> >> this I am getting negative frequencies.
> >> 2. I reduced my tr2_ph and conv_thr to 1.0d-14 and 1.0d-15 which I guess
> >> are very small as suggested on QE FAQs.
> >> 3. I checked phonon mode shapes for modes with negative frequencies and
> >> they do not look like rotational mode.
> >> 4. I tried changing number of k points from 6 to 12 in z direction but
> >> this is also not the cause.
> >>
> >> I am really stuck here and not sure about the cause of negative
> >> frequencies. With vc-relax, my structure is getting relaxed which I
> >> guess means my structure is stable. But then I am not sure why I am
> >> getting negative frequencies.
> >>
> >> I really appreciate any help or suggestions.
> >>
> >> Thanks,
> >>
> >> Ankit Jain
> >> IIT Indore,
> >> Indore,
> >> India
> >>
> >>
> >> ___
> >> Pw_forum mailing list
> >> Pw_forum at pwscf.org
> >> http://pwscf.org/mailman/listinfo/pw_forum
> >>
> >
> >
> >
> > --
> > With Best Regards,
> >
> > 
> > Dr. Sanjeev Kumar Gupta
> > Fulbright Post-Doctoral Scholar
> > Dept. of Physics
> > Michigan Technological University
> > 1400 Townsend Drive, Houghton
> > MI 49931, USA
> > 
> >
> > ___
> > Pw_forum mailing list
> > Pw_forum at pwscf.org
> > http://pwscf.org/mailman/listinfo/pw_forum
> >
> ___
> Pw_forum mailing list
> Pw_forum at pwscf.org
> http://pwscf.org/mailman/listinfo/pw_forum

-- 
Andrea Dal CorsoTel. 0039-040-3787428
SISSA, Via Bonomea 265  Fax. 0039-040-3787249
I-34136 Trieste (Italy) e-mail: dalcorso at sissa.it

[Pw_forum] Ag.pbe-dn-rrkjus_psl.0.1.UPF

[Andrea Dal Corso]

As far as I know, this Ag PP is working, and should be fine for Ag
surfaces. 

Andrea


On Fri, 2014-04-04 at 13:15 +0300, fatih.ersan at adu.edu.tr wrote:
> Dear A. Dal Corso:
> 
> I want to use Ag atoms for my study, when i'm searching suitable 
> pseudo-potentials(pp), i met Ag.pbe-dn-rrkjus_psl.0.1.UPF which has 
> config='[Kr] 4d9.5 5s1.5 5p0.0'electronic configurations. Is your scope to 
> generate this potential to examine catalytic activities or something like 
> this? Can i use this PP to adsorb on any sheet? Could you help me for me to 
> understand?
> 
> Best wishes
> 
> Fatih
> ___
> Pw_forum mailing list
> Pw_forum at pwscf.org
> http://pwscf.org/mailman/listinfo/pw_forum

-- 
Andrea Dal CorsoTel. 0039-040-3787428
SISSA, Via Bonomea 265  Fax. 0039-040-3787249
I-34136 Trieste (Italy) e-mail: dalcorso at sissa.it

[Pw_forum] band calculation

[Andrea Dal Corso]

On Wed, 2014-02-05 at 07:18 +0530, Ajit Kumar Jena wrote:
> Ehsan,
>Lastly, i would like to suggest you one thing. You may
> follow these steps.
> 
> 
> 1)  Clean your previous compiled thing :  to do this, go to your
> espresso-5.0.2 directory. Then, run command:
> 
> 
> 
> 
> make clean
> 
> 
> 
> 2) As I told earlier , go to espresso-5.0.2/PP/src/bands.f90. There,
> you exchange the positions of these two lines : 
> IF (gamma_only) CALL errore('bands','gamma_only case not
> implemented',1)
> 
> 
> And
> 
> 
>  CALL read_file()
> 
> 3) Now reinstall your quantum espresso.
> 

Please note that this problem has been corrected in QE 5.0.3, 
together with other problems. From 5.0.3 instruction:

* You need an unmodified 5.0.2 version of Quantum ESPRESSO, that
includes PHonon as well
* Go into the root directory (e.g. "espresso-5.0.2/")
* Download the patch (e.g. as "espresso-5.0.2-5.0.3.diff")
* patch the distribution:
  patch -p1 < espresso-5.0.2-5.0.3.diff
* See file Doc/release-notes for fixed bugs


HTH,

Andrea



> Thanks and Regards,
> Ajit
> 
> 
> 
> 
> 
> On Tue, Feb 4, 2014 at 11:41 PM, ehsan targholi 
> wrote:
> Dear Masoud & Ajit
> 
> thank you for your reply.
> 
> 
> 
> i tried to do any thing that you say but this error still
> there.
> 
> what i can do to solve this problem.
> 
> 
> best regard
> 
> 
> On Tue, Feb 4, 2014 at 7:37 AM, Ajit Kumar Jena
>  wrote:
> Dear Ehsan,
>I had the same issue. You just go to 
> espresso-5.0.2/PP/src/bands.f90.There you swap the lines: 
> 
>   IF (gamma_only) CALL errore('bands','gamma_only case not
> implemented',1)
> 
> 
> And
> 
> 
>  CALL read_file()
> 
> Then, do configuration and compilation again. It worked for 
> me.  
> 
> Thanks & Regards,
> Ajit
> 
> 
> On Tue, Feb 4, 2014 at 2:20 AM, ehsan targholi
>  wrote:
> 
> hi
> 
> i want to obtain band structure. i use of this
> method:
> 
> scf->nscf->bands
> 
> is right my method?
> 
> when i do this way the bands calculation give
> this error:
> 
>  %
> %
>  Error in routine bands (1):
>  gamma_only case not implemented
>  %
> %
> 
>  stopping ...
> 
> please help me to solve this problem.
> 
> 
>  best regard
> 
> ehsan
> 
> graduate student of iust
> 
> 
> 
> 
> ___
> Pw_forum mailing list
> Pw_forum at pwscf.org
> http://pwscf.org/mailman/listinfo/pw_forum
> 
> 
> 
> 
> ___
> Pw_forum mailing list
> Pw_forum at pwscf.org
> http://pwscf.org/mailman/listinfo/pw_forum
> 
> 
> 
> ___
> Pw_forum mailing list
> Pw_forum at pwscf.org
> http://pwscf.org/mailman/listinfo/pw_forum
> 
> 
> ___
> Pw_forum mailing list
> Pw_forum at pwscf.org
> http://pwscf.org/mailman/listinfo/pw_forum
-- 
Andrea Dal CorsoTel. 0039-040-3787428
SISSA, Via Bonomea 265  Fax. 0039-040-3787249
I-34136 Trieste (Italy) e-mail: dalcorso at sissa.it

[Pw_forum] Empty .dyn file from running ph.x with images

[Andrea Dal Corso]

On Sat, 2013-11-23 at 09:52 -0600, Jiayi Yan wrote:
> Dear all,
> 
> 
> I was running ph.x with 6x6x6 q grids for bcc metal. There are 29 q
> points to calculate. After running mpirun -np 24 ph.x -nimage 4 -npool
> 2 ..., I got all .dyn files, but the .dyn8 is empty. I guess by
> dividing 29 q points to 4 images some are missed/double-counted?
> 

Dynamical matrices split among different images are not saved in the
running directory, but are saved separately in the outdir/prefix.phsave
directory. Running ph.x with recover=.true. and without images after a
run with the images, allows to collect the information already saved on
disk and should be very fast. 
There is a detailed example in PHonon/examples/Image_example.


HTH, 

Andrea


> 
> There was a hint in the developer's manual for ph.x saying "...So you
> need to collect the results running \phx\ another time without
> images". Does it mean I have to start over without images, or there's
> a way to get .dyn8 easily?
> 
> 
> Thank you in advance.
> 
> 
>   Sincerely,
> Jiayi Yan
> 
> 
> -- 
> Jiayi Yan 
> 
> Graduate student, Dept. of Materials Science & Engineering
> Northwestern University
> 2220 Campus Dr, Cook Hall 2032
> Evanston, Illinois 60208-3108, U.S.A
> Office: Cook Hall 2021
> _______
> Pw_forum mailing list
> Pw_forum at pwscf.org
> http://pwscf.org/mailman/listinfo/pw_forum
-- 
Andrea Dal CorsoTel. 0039-040-3787428
SISSA, Via Bonomea 265  Fax. 0039-040-3787249
I-34136 Trieste (Italy) e-mail: dalcorso at sissa.it

[Pw_forum] Large shift of the Fermi energy - phonons, slab

[Andrea Dal Corso]

Note also the following fix that might be relevant in your case:

http://www.qe-forge.org/gf/project/q-e/scmsvn/?action=ScmCommitDetail_commit_id=1893

HTH,

Andrea

On Sun, 2013-10-27 at 19:04 +0100, Nicki Frank Hinsche wrote: 
> Dear community, 
> 
> 
> I am puzzled with some non-converging phonon calculations and
> especially with a very large shift of the Fermi energy in the
> perturbation step. 
> I am doing some calculations on metallic slabs, comparable to Eiguren
> et al. Phys. Rev. Lett. (2002) vol. 88 (6) 066805 or 
> Hofmann et al. New Journal of Physics (2009) vol. 11 (12) 125005. It
> worked out for several systems, with various thicknesses but now I
> become 
> desperate calculating the phonons of a simple 21layer slab of Cu(111).
> The vac. is around 2.5nm. The electronic structure looks fine, the
> relaxation 
> is done - but the phonons fail for the Gamma point (only). The Fermi
> energy shift is unphysically large. The DOS has no resonance nearby. 
> 
> 
> So what could be the problem? Any hints would be helpful. 
> 
> 
> Thanks Nicki
> 
> 
> following some input/output for the phonons on (away) the Gamma point:
> 
> 
> Input:
> 
> 
> 
>   reduce_io = .false.
>   tr2_ph=1.0d-12,
>   prefix='Cu',
>   alpha_mix = 0.150
>   ldisp=.true.,
>   nq1=4, nq2=4, nq3=1
>   start_q=1
>   last_q=1
>   recover = .true.,
>   amass(1)=63.546
>   outdir="***",
>   fildyn='Cu.dyn',
>  /
> 
> 
> Output Gamma:
> 
> 
> Computing dynamical matrix for.
> q = (   0.000   0.000   0.000 )
> 
> 
>   7 Sym.Ops. (with q -> -q+G )
> //
> Atomic displacements:
>  There are  42 irreducible representations
> //
>  Representation #  1 mode #   1
> 
> 
>  Self-consistent Calculation
> 
> 
>  Pert. #  1: Fermi energy shift (Ry) =-0.1403E+01
>  -0.8470E-21
>  
>   iter #   1 total cpu time :   168.5 secs   av.it.:   6.1
>   thresh= 0.100E-01 alpha_mix =  0.150 |ddv_scf|^2 =  0.277E+00
> //
>   Pert. #  1: Fermi energy shift (Ry) = 0.1555E+08
>  -0.8882E-15
> //
>   iter # 100 total cpu time :  2038.3 secs   av.it.:  25.3
>   thresh= 0.100E-01 alpha_mix =  0.150 |ddv_scf|^2 =  0.313E+15
> 
> 
> 
> 
> And the output for a q-point away from Gamma:
> 
> 
> Computing dynamical matrix for.
> q = (   0.1443376   0.250   0.000 )
> 
> 
>   2 Sym.Ops. (no q -> -q+G )
> //
>  Atomic displacements:
>  There are  63 irreducible representations
> //
> Representation #  1 mode #   1
>  
>  Self-consistent Calculation
> 
> 
>   iter #   1 total cpu time :  1117.1 secs   av.it.:   5.8
>   thresh= 0.100E-01 alpha_mix =  0.150 |ddv_scf|^2 =  0.315E-04
> //
>   iter #  15 total cpu time :  2442.8 secs   av.it.:  10.2
>   thresh= 0.105E-06 alpha_mix =  0.150 |ddv_scf|^2 =  0.454E-12
> 
> 
> 
> 
> 
> 
> Some info on the self-consistent calculation before:
> 
> 
> occupations='smearing', smearing='methfessel-paxton', degauss=0.01
> ecutwfc = 38.0, ecutrho = 304.0,
> conv_thr =  1.0d-10
> K_POINTS {automatic}: 12 12 1 0 0 0
> nat= 21, ntyp= 1
> CELL_PARAMETERS {hexagonal}
> 0.86602540-0.500   0.00
> 0.866025400.5000   0.00
> 0.0.   25.71450
> 
> 
> 
> 
> 
> 
> -
> Nicki Frank Hinsche, Dr. rer. nat.
> Institute of physics - Theoretical physics,
> Martin-Luther-University Halle-Wittenberg,
> Von-Seckendorff-Platz 1, Room 1.07
> D-06120 Halle/Saale, Germany
> Tel.: ++49 345 5525460
> -
> 
> ___
> Pw_forum mailing list
> Pw_forum at pwscf.org
> http://pwscf.org/mailman/listinfo/pw_forum
-- 
Andrea Dal CorsoTel. 0039-040-3787428
SISSA, Via Bonomea 265  Fax. 0039-040-3787249
I-34136 Trieste (Italy) e-mail: dalcorso at sissa.it

[Pw_forum] Large shift of the Fermi energy - phonons, slab

[Andrea Dal Corso]

On Sun, 2013-10-27 at 19:04 +0100, Nicki Frank Hinsche wrote:
> Dear community, 
> 
> 
> I am puzzled with some non-converging phonon calculations and
> especially with a very large shift of the Fermi energy in the
> perturbation step. 
> I am doing some calculations on metallic slabs, comparable to Eiguren
> et al. Phys. Rev. Lett. (2002) vol. 88 (6) 066805 or 
> Hofmann et al. New Journal of Physics (2009) vol. 11 (12) 125005. It
> worked out for several systems, with various thicknesses but now I
> become 
> desperate calculating the phonons of a simple 21layer slab of Cu(111).
> The vac. is around 2.5nm. The electronic structure looks fine, the
> relaxation 
> is done - but the phonons fail for the Gamma point (only). The Fermi
> energy shift is unphysically large. The DOS has no resonance nearby. 
> 
> 
> So what could be the problem? Any hints would be helpful. 
> 
Please note that the phonon code is not working in versions 5.0 up to
5.0.2. You need to patch 5.0.2 to obtain 5.0.3.

Andrea


> 
> Thanks Nicki
> 
> 
> following some input/output for the phonons on (away) the Gamma point:
> 
> 
> Input:
> 
> 
> 
>   reduce_io = .false.
>   tr2_ph=1.0d-12,
>   prefix='Cu',
>   alpha_mix = 0.150
>   ldisp=.true.,
>   nq1=4, nq2=4, nq3=1
>   start_q=1
>   last_q=1
>   recover = .true.,
>   amass(1)=63.546
>   outdir="***",
>   fildyn='Cu.dyn',
>  /
> 
> 
> Output Gamma:
> 
> 
> Computing dynamical matrix for.
> q = (   0.000   0.000   0.000 )
> 
> 
>   7 Sym.Ops. (with q -> -q+G )
> //
> Atomic displacements:
>  There are  42 irreducible representations
> //
>  Representation #  1 mode #   1
> 
> 
>  Self-consistent Calculation
> 
> 
>  Pert. #  1: Fermi energy shift (Ry) =-0.1403E+01
>  -0.8470E-21
>  
>   iter #   1 total cpu time :   168.5 secs   av.it.:   6.1
>   thresh= 0.100E-01 alpha_mix =  0.150 |ddv_scf|^2 =  0.277E+00
> //
>   Pert. #  1: Fermi energy shift (Ry) = 0.1555E+08
>  -0.8882E-15
> //
>   iter # 100 total cpu time :  2038.3 secs   av.it.:  25.3
>   thresh= 0.100E-01 alpha_mix =  0.150 |ddv_scf|^2 =  0.313E+15
> 
> 
> 
> 
> And the output for a q-point away from Gamma:
> 
> 
> Computing dynamical matrix for.
> q = (   0.1443376   0.250   0.000 )
> 
> 
>   2 Sym.Ops. (no q -> -q+G )
> //
>  Atomic displacements:
>  There are  63 irreducible representations
> //
> Representation #  1 mode #   1
>  
>  Self-consistent Calculation
> 
> 
>   iter #   1 total cpu time :  1117.1 secs   av.it.:   5.8
>   thresh= 0.100E-01 alpha_mix =  0.150 |ddv_scf|^2 =  0.315E-04
> //
>   iter #  15 total cpu time :  2442.8 secs   av.it.:  10.2
>   thresh= 0.105E-06 alpha_mix =  0.150 |ddv_scf|^2 =  0.454E-12
> 
> 
> 
> 
> 
> 
> Some info on the self-consistent calculation before:
> 
> 
> occupations='smearing', smearing='methfessel-paxton', degauss=0.01
> ecutwfc = 38.0, ecutrho = 304.0,
> conv_thr =  1.0d-10
> K_POINTS {automatic}: 12 12 1 0 0 0
> nat= 21, ntyp= 1
> CELL_PARAMETERS {hexagonal}
> 0.86602540-0.500   0.00
> 0.866025400.5000   0.00
> 0.0.   25.71450
> 
> 
> 
> 
> 
> 
> -
> Nicki Frank Hinsche, Dr. rer. nat.
> Institute of physics - Theoretical physics,
> Martin-Luther-University Halle-Wittenberg,
> Von-Seckendorff-Platz 1, Room 1.07
> D-06120 Halle/Saale, Germany
> Tel.: ++49 345 5525460
> -
> 
> ___
> Pw_forum mailing list
> Pw_forum at pwscf.org
> http://pwscf.org/mailman/listinfo/pw_forum
-- 
Andrea Dal CorsoTel. 0039-040-3787428
SISSA, Via Bonomea 265  Fax. 0039-040-3787249
I-34136 Trieste (Italy) e-mail: dalcorso at sissa.it

[Pw_forum] spin orbit and custom occupations

[Andrea Dal Corso]

With spin-orbit coupling states are not eigenstates of S_z,
so one cannot separate spin up and spin down. 
However when spin-orbit is small and magnetization is large the states
can be mainly spin up or mainly spin down and you can see this by
calculating the expectation value of \sigma_z (if the magnetization is
along z). This can be done with the band.x program.

HTH,

Andrea 

On Thu, 2013-09-26 at 18:33 +0200, Julen Larrucea wrote:
> Thanks Andrea,
> 
> 
> but this doesn't really solve my problem...
> 
> 
> I still can't find from example06 how to check the final occupations.
> 
> If I use nspin=4, which is supposed to be spin-polarized, unlike in
> the case of nspin=2, I only get a single row of occupations, like this
> 
>  occupation numbers 
>  1.   1.   1.   1.   1.   1.   1.
> 1.
>  1.   1.   1.   1.   1.   1.0001   0.9219
> 0.1150
> -0.0167  -0.0202   0.   0.   0.   0.   0.
> 0.
> 
> 
> But which of them are up or down? or, how can I find out whether I
> have a singlet or a triplet in my single isolated atom?
> 
> 
>   Thanks in advance
> 
> 
>  Julen
> 
> 
> 
> 
> 
> On Wed, Sep 25, 2013 at 2:31 PM, Andrea Dal Corso 
> wrote:
> constrained_magnetization='total'
> 
> allows you to fix the magnetization vector. See example06 for
> more
> details.
> 
> HTH,
> 
> Andrea
> 
> 
> 
> On Wed, 2013-09-25 at 11:51 +0200, Julen Larrucea wrote:
> > Dear colleagues,
> > Does anybody know how to set precisely the occupations on a
> spin orbit
> > calculation (lspinorb=.true.)?
> >
> > I have tried to occupations='from_input' but it does not
> read the
> > minority spin line, and constrained- and tot_magnetization
> do not seem
> > to work either.
> >
> >
> >   Thanks in advance
> >
> >
> > Julen
> > --
> > Dr. Julen Larrucea
> > Postdoctoral researcher,
> > BCCMS, HMI Group, University of Bremen
> > Phone: +49 421 218 64582
> > Fax: +49 421 218 64599
> >  http://www.larrucea.eu
> 
> > ___
> > Pw_forum mailing list
> > Pw_forum at pwscf.org
> > http://pwscf.org/mailman/listinfo/pw_forum
> --
> Andrea Dal CorsoTel. 0039-040-3787428
> SISSA, Via Bonomea 265  Fax. 0039-040-3787249
> I-34136 Trieste (Italy) e-mail: dalcorso at sissa.it
> 
> 
> ___
> Pw_forum mailing list
> Pw_forum at pwscf.org
> http://pwscf.org/mailman/listinfo/pw_forum
> 
> 
> 
> -- 
> -- 
> Dr. Julen Larrucea
> Postdoctoral researcher,
> BCCMS, HMI Group, University of Bremen
> Phone: +49 421 218 64582
> Fax: +49 421 218 64599
>  http://www.larrucea.eu
> ___
> Pw_forum mailing list
> Pw_forum at pwscf.org
> http://pwscf.org/mailman/listinfo/pw_forum
-- 
Andrea Dal CorsoTel. 0039-040-3787428
SISSA, Via Bonomea 265  Fax. 0039-040-3787249
I-34136 Trieste (Italy) e-mail: dalcorso at sissa.it

[Pw_forum] spin orbit and custom occupations

[Andrea Dal Corso]

constrained_magnetization='total'

allows you to fix the magnetization vector. See example06 for more
details. 

HTH,

Andrea



On Wed, 2013-09-25 at 11:51 +0200, Julen Larrucea wrote:
> Dear colleagues,
> Does anybody know how to set precisely the occupations on a spin orbit
> calculation (lspinorb=.true.)?
> 
> I have tried to occupations='from_input' but it does not read the
> minority spin line, and constrained- and tot_magnetization do not seem
> to work either.
> 
> 
>   Thanks in advance
> 
> 
> Julen
> -- 
> Dr. Julen Larrucea
> Postdoctoral researcher,
> BCCMS, HMI Group, University of Bremen
> Phone: +49 421 218 64582
> Fax: +49 421 218 64599
>  http://www.larrucea.eu
> ___
> Pw_forum mailing list
> Pw_forum at pwscf.org
> http://pwscf.org/mailman/listinfo/pw_forum
-- 
Andrea Dal CorsoTel. 0039-040-3787428
SISSA, Via Bonomea 265  Fax. 0039-040-3787249
I-34136 Trieste (Italy) e-mail: dalcorso at sissa.it

[Pw_forum] Noncolinear calculations

[Andrea Dal Corso]

On Tue, 2013-04-16 at 16:57 +0100, Abdeslam HOUARI wrote:
> Dear Ricardo;
> 
> Sorry to reply late... I think that according to the excellent paper
> of A. Dal Corso that you mentioned, it depends on the PP that you use.
> If you use for example a Fully Relativistic PP, so its OK for
> spin-orbit and other terms !
> 
> The implementation concerns rather the ld.x code (to generate PP).
> 
> Cheers;
> 
> Abdeslam 
> 
> 
> 
> 2013/4/9 Ricardo Mendes Ribeiro 
> Hello
> 
> I would like to confirm if the noncolinear calculations that
> are implemented in
> Quantum Espresso are the ones described by Andrea Dal Corso in
> PRB 82,
> 075116 (2010),
> section II on Relativistic Spin-Density Functional Theory.
> 
> In particular, whether only the nonrelativistic limit is
> implemented
> (Pauli equations),
> or the spin-orbit , Darwin and mass-velocity terms are also
> included.

Eqs. 51-53, Pauli type KS equations described in Sec V of PRB 82 075116
are implemented. Eqs. 39-41 are not. Eqs. 51-53 include Darwin,
spin-orbit and mass velocity inside the PAW spheres but not outside.
These equations correspond to fully relativistic PPs while scalar
relativistic PPs use the equations of Sec. III. 

Andrea

> Thank you very much.
> 
> --
> ---
> Ricardo Mendes Ribeiro
> http://hawk.fisica.uminho.pt
> Universidade do Minho, Portugal
> ___
> Pw_forum mailing list
> Pw_forum at pwscf.org
> http://pwscf.org/mailman/listinfo/pw_forum
> 
> 
> 
> -- 
> ==
> Abdesalem HOUARI
> ---
> Department of physics, Theoretical Physics Laboratory
> University of Bejaia-06000. Algeria.
> E-mail: abdeslam.houari at univ-bejaia.dz & habdeslam at gmail.com
> https://sites.google.com/site/houariabdeslam/homepage
> =======
> ___
> Pw_forum mailing list
> Pw_forum at pwscf.org
> http://pwscf.org/mailman/listinfo/pw_forum
-- 
Andrea Dal CorsoTel. 0039-040-3787428
SISSA, Via Bonomea 265  Fax. 0039-040-3787249
I-34136 Trieste (Italy) e-mail: dalcorso at sissa.it

[Pw_forum] Mo pseudopotential

[Andrea Dal Corso]

)   -0.27582   -0.27582
> 0.0
>  2 1 5P   1( 0.00)   -0.07669   -0.07669
> -0.0
>  Etot =   -8097.243530 Ry,   -4048.621765 Ha, -110168.600949 eV
>  Etotps =   -32.753518 Ry, -16.376759 Ha,-445.634282 eV
> 
>  1 0 5S   1( 0.00)   -2.69065   -2.78173
> 0.09108
>  3 2 4D   1( 2.00)   -3.40343   -3.51010
> 0.10667
>  2 1 5P   1( 0.00)   -2.17762   -2.27343
> 0.09581
>  dEtot_ae =   6.511981 Ry
>  dEtot_ps =   6.625031 Ry,   Delta E=  -0.113050 Ry
> 
>  1 0 5S   1( 0.00)   -4.30796   -4.58873
> 0.28077
>  3 2 4D   1( 0.00)   -5.60739   -5.87530
> 0.26791
>  2 1 5P   1( 0.00)   -3.66423   -3.99180
> 0.32756
>  dEtot_ae =  15.474602 Ry
>  dEtot_ps =  15.954369 Ry,   Delta E=  -0.479767 Ry
> 
> My question: is my procedure described above wrong? Study and
> understand the generation of PSPs is not easy for me and I'm trying to
> learn it grounded in some textbooks as well as some documents spread
> on the internet and of course the input files provided in the
> pslibrary project. But this PBE USPP for molybdenum made me a little
> bit confused. I tested both in a MoS2 unit cell with PBE-D and the
> cell volume as well as the interatomic distances are fine if compared
> with the experiments, with differences lower than 3%... One more
> question: how can I improve the result for the Mo4+ and Mo6+ ionized
> states?
> 
> Thank you very much!
> 
> Ary Junior
> 
> Doctoral Student
> Chemistry Department
> Universidade Federal de Juiz de Fora - MG - Brasil
> 
> -- 
> http://lattes.cnpq.br/8221674673413336 
> ___
> Pw_forum mailing list
> Pw_forum at pwscf.org
> http://pwscf.org/mailman/listinfo/pw_forum
-- 
Andrea Dal CorsoTel. 0039-040-3787428
SISSA, Via Bonomea 265  Fax. 0039-040-3787249
I-34136 Trieste (Italy) e-mail: dalcorso at sissa.it

[Pw_forum] ph.x: Avoiding the recalculation of the band structure in distributed phonon dispersion jobs

[Andrea Dal Corso]

On Wed, 2013-02-27 at 11:10 +, Karttunen Antti wrote:
> Dear Andrea,
> 
> I'm glad to hear that resetting current_q is no problem. While running some 
> tests today, I realized that there is one more point I did not think about in 
> the new only_init approach. We run the individual (q,irr) grid jobs in serial 
> mode since this is simplest to achieve in a grid. However, it would be really 
> helpful to execute the only_init run locally in parallel since in serial mode 
> the epsilon + band structure calculation of the largest systems can take 
> several days. So, I tried to run only_init in parallel and (q,irr) jobs in 
> serial, but then ph.x will fail in q>1 since the only_init run writes 
> separate wfc files for all parallel processes and openfilq is looking for 
> just one wfc file. My naive first attempt was to modify run_pwscf:
>   twfcollect=.FALSE.
>   IF (only_init) twfcollect=.TRUE.
>   CALL punch( 'all' )
> but I realized that this just writes the data in the _ph0/qdir/prefix.save in 
> the wf_collect-format and does not produce the _ph0/qdir/prefix.wfc file that 
> openfilq is waiting for. 
> 
> I wonder if there would be any simple way to 
> a) make run_pwscf to write the _ph0/qdir/prefix.wfc file for a parallel 
> only_init job
> or b) make openfilq (and phq_init) to read wf_collect-style wavefunction data 
> for q>1  if there is no _ph0/qdir/prefix.wfc file (or if a keyword tells it 
> so)?
> 
> Or would this just complicate things too much? I guess the latter option 
> could be considered as an "internal" wf_collect option for ph.x, resulting in 
> maximum flexibility.
> 

I am not going to implement this in the SVN version, at least not now.
However it seems that if you reopen the wavefunctions after saving them
with twfcollect=.true.. with something like:

 CALL punch( 'all' )
 IF (only_init) THEN
CALL clean_pw( .TRUE. )
CALL close_files(.true.)
wfc_dir=tmp_dir_phq
tmp_dir=tmp_dir_phq
CALL read_file()
IF (.NOT.lgamma_iq(iq).OR.(qplot.AND.iq>1)) CALL
set_small_group_of_q(nsymq,invsymq,minus_q)
 ENDIF

you can both run the epsilon calculation and the next ph.x runs with a
different number of processors. It is really inelegant, and I think
there are better ways to do this, but it seems to work.

Best wishes,

Andrea



> Best wishes,
> Antti
> 
> -- 
> Dr. Antti Karttunen
> Department of Chemistry
> University of Jyv?skyl?, Finland
> Tel: +358-50-3473475
> WWW: http://www.iki.fi/ankarttu 
> 
> 
> -Original Message-
> From: pw_forum-bounces at pwscf.org [mailto:pw_forum-bounces at pwscf.org] On 
> Behalf Of Andrea Dal Corso
> Sent: Wednesday, February 27, 2013 12:13 PM
> To: PWSCF Forum
> Subject: Re: [Pw_forum] ph.x: Avoiding the recalculation of the band 
> structure in distributed phonon dispersion jobs
> 
> 
> On Wed, 2013-02-27 at 06:55 +, Karttunen Antti wrote:
> > Dear Andrea,
> > 
> > Thank you very much for the bug fix and introducing the low_directory_check 
> > input variable. Now the process goes very smoothly and we can avoid all the 
> > unnecessary band calculations in the future.
> > 
> > I noticed that there is still some problem with the GRID_example 
> > run_example_3: Looking at the reference output files, epsilon and bands are 
> > actually recalculated at every q. I ran the example and it seems that there 
> > is some problem with the management of the temporary directories. The 
> > example actually runs nicely, if one completely omits the creation of the 
> > separate $q.$irr directories and just runs with one single _ph0 directory 
> > with one $prefix.phsave and all the qdirs. 
> > 
> > I also noticed that the run_example_3 always tries to keep the qdir of the 
> > last q-point in the current temp directory:
> >   cp -r $TMP_DIR/_ph0/$PREFIX.q_8 $TMP_DIR/$q.$irr/_ph0/
> > I guess the reason for this is that without this, ph.x crashes for q<8 
> > because seqopn fails for $prefix.q_8/recover? I encountered this with my 
> > own tests, too. It seems that after the only_init run, CURRENT_Q in 
> > status_run.xml is set to the last q-point and ph.x would then like to have 
> > $prefix.q_8 directory around in the following (q,irr) calculations. I'm 
> > planning that I don't want to move all qdirs into every (q,irr) _ph0 
> > directory, so after the only_init run, I will reset the CURRENT_Q to 1 in 
> > my scripts. For example something like
> > 
> > sed -r -i '/ > _ph0/$prefix.phsave/status_run.xml
> > 
> > works nicely. Or maybe ph.x could reset CURRENT_Q to 1 in the end of a 
> > successful only_init-run? But this might have some side

[Pw_forum] ph.x: Avoiding the recalculation of the band structure in distributed phonon dispersion jobs

[Andrea Dal Corso]

On Wed, 2013-02-27 at 06:55 +, Karttunen Antti wrote:
> Dear Andrea,
> 
> Thank you very much for the bug fix and introducing the low_directory_check 
> input variable. Now the process goes very smoothly and we can avoid all the 
> unnecessary band calculations in the future.
> 
> I noticed that there is still some problem with the GRID_example 
> run_example_3: Looking at the reference output files, epsilon and bands are 
> actually recalculated at every q. I ran the example and it seems that there 
> is some problem with the management of the temporary directories. The example 
> actually runs nicely, if one completely omits the creation of the separate 
> $q.$irr directories and just runs with one single _ph0 directory with one 
> $prefix.phsave and all the qdirs. 
> 
> I also noticed that the run_example_3 always tries to keep the qdir of the 
> last q-point in the current temp directory:
>   cp -r $TMP_DIR/_ph0/$PREFIX.q_8 $TMP_DIR/$q.$irr/_ph0/
> I guess the reason for this is that without this, ph.x crashes for q<8 
> because seqopn fails for $prefix.q_8/recover? I encountered this with my own 
> tests, too. It seems that after the only_init run, CURRENT_Q in 
> status_run.xml is set to the last q-point and ph.x would then like to have 
> $prefix.q_8 directory around in the following (q,irr) calculations. I'm 
> planning that I don't want to move all qdirs into every (q,irr) _ph0 
> directory, so after the only_init run, I will reset the CURRENT_Q to 1 in my 
> scripts. For example something like
> 
> sed -r -i '/ _ph0/$prefix.phsave/status_run.xml
> 
> works nicely. Or maybe ph.x could reset CURRENT_Q to 1 in the end of a 
> successful only_init-run? But this might have some side effects I'm not aware 
> of, so I'm also fine with using the above script. Anyway, thanks a lot for 
> all the great work with the grid implementation, this will enormously speed 
> up our work on the phonon calculations of large systems.
> 
The script had still some problems, now it should be OK. OK also for the
reset of current_q, I have now commited the change.

The reason for having different directories $q.$irr is that the GRID
example should work also in different machines that do not share the
same disk, but it is not necessary to use them when you work with many
CPUs that share the same disk.

Andrea



> Best wishes,
> Antti
> 
> -- 
> Dr. Antti Karttunen
> Department of Chemistry
> University of Jyv?skyl?, Finland
> Tel: +358-50-3473475
> WWW: http://www.iki.fi/ankarttu 
> 
> -Original Message-
> From: pw_forum-bounces at pwscf.org [mailto:pw_forum-bounces at pwscf.org] On 
> Behalf Of Andrea Dal Corso
> Sent: Tuesday, February 26, 2013 4:19 PM
> To: PWSCF Forum
> Subject: Re: [Pw_forum] ph.x: Avoiding the recalculation of the band 
> structure in distributed phonon dispersion jobs
> 
> > Thank you for your help in identifying bugs. Now I have commited a bug
> > fix to check_directory_phsave. 
> 
> 
> ___
> Pw_forum mailing list
> Pw_forum at pwscf.org
> http://pwscf.org/mailman/listinfo/pw_forum
-- 
Andrea Dal CorsoTel. 0039-040-3787428
SISSA, Via Bonomea 265  Fax. 0039-040-3787249
I-34136 Trieste (Italy) e-mail: dalcorso at sissa.it

[Pw_forum] ph.x: Avoiding the recalculation of the band structure in distributed phonon dispersion jobs

[Andrea Dal Corso]

On Tue, 2013-02-26 at 11:00 +, Karttunen Antti wrote:
> Dear Andrea,
> 
> I tried your new only_init keyword by running the new 
> GRID_example/run_example_3 and with my own test jobs. It worked great, but 
> only after I sorted out one really strange issue. The example was crashing 
> for apparently random (q,irr) combinations right in the beginning of ph.x. 
> The error occurred at subroutine check_directory_phsave and it was coming 
> from the following call:
> 
> CALL iotk_open_read(iunout, FILE = TRIM(filename1), &
> BINARY = .FALSE., IERR = ierr )
> which leads to:
> IF (ierr /= 0) CALL errore('check_directory_phsave','opening file',1)
> 
> ierr from iotk was always 2.
> 
> I did tried to see, which file caused the problem and it was always 
> dynmat.1.0.xml (maybe because it's the first file that is read in in the 
> loop). Now, the strange thing was that this occurred randomly: for about 20% 
> of the (q,irr) combinations within the example. And the crashing combinations 
> changed between runs. Furthermore, my own tests showed that that even if some 
> (q,irr) combination crashed, ph.x would run successfully if I re-ran the same 
> input several times (something like 5 times). I'm running the tests on a 
> local filesystem, so it's not an NFS issue. I guess it could be a compiler 
> issue with iotk (I used ifort 12.1.5), but at least compiling iotk without 
> any optimization flags did not help. I'm really puzzled by the (apparently) 
> random nature of the crashes, I could not figure out what is the 
> non-deterministic factor here (I sure hope it's not my hard drive...).
> 

Thank you for your help in identifying bugs. Now I have commited a bug
fix to check_directory_phsave. 

> In any case, I could avoid the crashes by replacing the
> IF (ierr /= 0 ) GOTO 100
> with 
> IF (ierr /= 0 ) CYCLE
> in check_directory_phsave and uncommenting the CALL errore after the loop. I 
> think this is also how the things were done before code revision 9858. We 
> were previously using revision 9772 and this problem never occurred there 
> (maybe the problem is unrelated to only_init and just surfaced now when I 
> changed the revision?).
> 
> It would be interesting to know what was causing the random iotk_open_read 
> errors. Furthermore, maybe the whole loop over nqs and irr_iq in 
> check_directory_phsave could be skipped for cases where start_q=last_q and 
> start_irr=last_irr? This is the normal case for grid jobs and for large 
> systems this could help to avoid hundreds of filesystem operations for every 
> job (since we are going to do just one (q,irr), it's not that interesting 
> whether the other ones have been done or not). But maybe this would have some 
> side-effects, so at the moment I'll just use the above trick.
> 
OK, I will see if I can do something for this problem.

Andrea

> Best wishes,
> Antti
> 
> -- 
> Dr. Antti Karttunen
> Department of Chemistry
> University of Jyv?skyl?, Finland
> Tel: +358-50-3473475
> WWW: http://www.iki.fi/ankarttu 
> 
> 
> -Original Message-
> From: pw_forum-bounces at pwscf.org [mailto:pw_forum-bounces at pwscf.org] On 
> Behalf Of Andrea Dal Corso
> Sent: Monday, February 25, 2013 7:36 PM
> To: PWSCF Forum
> Subject: Re: [Pw_forum] ph.x: Avoiding the recalculation of the band 
> structure in distributed phonon dispersion jobs
> 
> 
> On Mon, 2013-02-11 at 18:30 +, Karttunen Antti wrote:
> > Dear all, 
> > 
> > We are using the start_q/last_q and start_irr/last_irr keywords to execute 
> > phonon dispersion jobs within a HPC grid service. The scheme works really 
> > nicely and we are able to run fairly large phonon dispersion calculations 
> > very efficiently. However it would be great to know if we could further 
> > increase the efficiency by avoiding the recalculation of the band structure 
> > at all irreps for every q.
> > 
> > A concrete example: We are using a 4x4x4 q-point grid to investigate the 
> > phonon dispersions of cubic silicon clathrate (FCC structure with 34 atoms 
> > in the primitive cell),requiring the calculation of 8 q-points in total. 
> > While the number of symmetry-independent q-points is rather low, the 
> > individual q-points can contain as many as 101 irreps (558 (q,irrep) 
> > calculations in total). While in "normal" phonon dispersion calculations 
> > the band structure is solved once for every q, in the distributed phonon 
> > dispersion calculations every single (q,irrep) job calculates the band 
> > structure before doing the actual phonon calculation (except q=1). So, the 
> > band structure is "re-calculated&

[Pw_forum] ph.x: Avoiding the recalculation of the band structure in distributed phonon dispersion jobs

[Andrea Dal Corso]

On Mon, 2013-02-11 at 18:30 +, Karttunen Antti wrote:
> Dear all, 
> 
> We are using the start_q/last_q and start_irr/last_irr keywords to execute 
> phonon dispersion jobs within a HPC grid service. The scheme works really 
> nicely and we are able to run fairly large phonon dispersion calculations 
> very efficiently. However it would be great to know if we could further 
> increase the efficiency by avoiding the recalculation of the band structure 
> at all irreps for every q.
> 
> A concrete example: We are using a 4x4x4 q-point grid to investigate the 
> phonon dispersions of cubic silicon clathrate (FCC structure with 34 atoms in 
> the primitive cell),requiring the calculation of 8 q-points in total. While 
> the number of symmetry-independent q-points is rather low, the individual 
> q-points can contain as many as 101 irreps (558 (q,irrep) calculations in 
> total). While in "normal" phonon dispersion calculations the band structure 
> is solved once for every q, in the distributed phonon dispersion calculations 
> every single (q,irrep) job calculates the band structure before doing the 
> actual phonon calculation (except q=1). So, the band structure is 
> "re-calculated" numerous times in the distributed scheme. The overhead is not 
> negligible: For a single (q,irrep) job at the q-points with the lowest 
> symmetry,  the band structure calculation can typically take ~10 CPU hours of 
> the total execution time of ~60 CPU hours (we are running the jobs in the 
> grid with just one
 
  CPU).
> 
> For systems like this, it would be really great if we could do something like 
> this:
> 1) Precalculate the band structure for every q (for example, for irrep=1),
> 2) Write the results of the band structure calculation to a file for every q 
> 3) For all other irreps, just read the precalculated band structure from the 
> file.
> 
> We are already using a similar scheme to avoid the re-calculation of the 
> dielectric constant for all q=1 irreps:
> 1) Precalculate the dielectric constant for (q=1,irrep=1)
> 2) Use data-file.1.xml with DIELECTRIC_CONSTANT and EFFECTIVE_CHARGES as the 
> starting point for other q=1 irreps.
> 3) With recover=.true., the re-calculation of the dielectric constant is 
> avoided
> 
> However, we have not been able to devise a similar scheme to avoid the 
> re-calculation of the band structure for q>1. I've been reading the source 
> code but at least based on check_initial_status.f90 it seems that reading the 
> bands is only possible if there is a restart file available (i.e. the 
> calculation has been interrupted).  So, while the built-in logic supports 
> restarting "normal" phonon dispersion calculations, we haven't been able to 
> find out a way to read the band structure into a single (q,irrep) job. 
> 

I thought that this procedure was already working if you copied all the
files produced by ph.x using start_irr=1 and last_irr=1 as a preparatory
run, but there were still some problems. I commited a script in the SVN
version inspired to your suggestion (see GRID_example/run_example_3).
Hopefully you can adapt it to your cases. 

HTH,

Andrea




> We would really appreciate any comments or ideas on how to avoid the overhead 
> from the band structure calculations in the above scenario.
> 
> Best wishes,
> Antti Karttunen
> 
-- 
Andrea Dal CorsoTel. 0039-040-3787428
SISSA, Via Bonomea 265  Fax. 0039-040-3787249
I-34136 Trieste (Italy) e-mail: dalcorso at sissa.it

[Pw_forum] Can we calculate the electron-phonon coupling using the PAW potential?

[Andrea Dal Corso]

On Mon, 2013-02-18 at 10:26 +0800, Wei Zhou wrote:
> is it possioble?
> 

Please read the header of the file PHonon/PH/phonon.f90.
If a feature is not listed there but the code does not stop when you
request it, it means either that we forgot to introduce the appropriate
check, or that the feature is experimental and we are testing it and
working on it.

HTH,

Andrea

> -- 
> ZhouDawei
> JiLin Universiyt ,ChangChun ,China
> zdw2000 at gmail.com 
> ___
> Pw_forum mailing list
> Pw_forum at pwscf.org
> http://pwscf.org/mailman/listinfo/pw_forum
-- 
Andrea Dal CorsoTel. 0039-040-3787428
SISSA, Via Bonomea 265  Fax. 0039-040-3787249
I-34136 Trieste (Italy) e-mail: dalcorso at sissa.it

[Pw_forum] symmetry not recognized

[Andrea Dal Corso]

This error usually indicates that ph.x has some difficulty to recognize
the symmetries in your system. You can skip this check and continue the
phonon calculation as in previous versions of the code by
using the flag search_sym=.false., but often the phonons are wrong in
these cases, so it would be better to understand if the symmetry group
found by pw.x and by ph.x is correct or not.

HTH,

Andrea

On Wed, 2013-02-13 at 13:33 -0500, Jennifer Wohlwend wrote:
> My goal is to use epw.x but when I was trying to first complete the
> ph.x calculation I kept running into this error:
>  %
> %
>  from tipo_sym : error # 1
>  symmetry not recognized
>  %
> %
>  stopping ...
> I checked the forum concerning this error but as expected the
> misplaced parenthesis had been fixed in the 4.0.3 version (only using
> such an old version b/c epw.x requires it).  After encountering this
> error while testing an epw.x example I tried a pwscf example02 that
> utilizes ph.x (from version 4.0.3; The example shows how to use pw.x
> and ph.x to calculate phonon frequencies at Gamma and X for Si and C
> in the diamond structure and for fcc-Ni.) and I received the same
> error. 
> Any help would be much appreciated!
> Thank you,
> J. Wohlwend
>  
> Universal Technology Corporation 
> 
> ___
> Pw_forum mailing list
> Pw_forum at pwscf.org
> http://pwscf.org/mailman/listinfo/pw_forum
-- 
Andrea Dal CorsoTel. 0039-040-3787428
SISSA, Via Bonomea 265  Fax. 0039-040-3787249
I-34136 Trieste (Italy) e-mail: dalcorso at sissa.it

[Pw_forum] Calculation of the dielectric tensor for PAW+Spin-Orbit (non-magnetic)

[Andrea Dal Corso]

Nobody seriously checked this case so far, and you have to consider this
option still very experimental.

Andrea

On Fri, 2013-02-08 at 20:54 +0900, H. Lee wrote:
> I have calculated the dielectric tensor using ph.x for the case of PAW
> pseudopotential with spin-orbit interaction (non-magnetic) and
> obtained the results.
> 
> 
> After calculation, I have found the comments in the header of
> phonon.f90 file as follows:
> 
> 
>   ! ... Presently implemented:
> 
>   
> ...
>
>   ! ... dielectric constant   NC [5], US [5], PAW [3]
> 
>  
>   ! ... born effective chargesNC [5], US [5], PAW [3]
> 
>  
> ...
>   
>   !
> 
>  
>   ! NC = norm conserving pseudopotentials
> 
>  
>   ! US = ultrasoft pseudopotentials
> 
>  
>   ! PAW = projector augmented-wave
> 
>   
>   ! [1] LDA,
> 
>   
>   ! [2] [1] + GGA,
> 
>   
>   ! [3] [2] + LSDA/sGGA,
> 
>   
>   ! [4] [3] + Spin-orbit/nonmagnetic,
> 
>  
>   ! [5] [4] + Spin-orbit/magnetic (experimental when available)   
> 
> 
> Do they mean that my results for dielectric tensor and born effective
> charges are not meaningful?
> ___
> Pw_forum mailing list
> Pw_forum at pwscf.org
> http://pwscf.org/mailman/listinfo/pw_forum
-- 
Andrea Dal CorsoTel. 0039-040-3787428
SISSA, Via Bonomea 265  Fax. 0039-040-3787249
I-34136 Trieste (Italy) e-mail: dalcorso at sissa.it

[Pw_forum] error in find_mode_sym.f90

[Andrea Dal Corso]

 X for Si...forrtl:
> severe
> > (174): SIGSEGV, segmentation fault occurred
> > Error condition encountered during test: exit status = 174
> > Aborting
> > I have compiled espresso-5.0.2 with Intel compiler and
> gfortran
> > both and the same error was coming.
> > Any type of help is appreciated.
> >
> > P.S. when i was tried to run with espresso-4.3.2 (with
> gfortran),
> > it was working without any error.
> > --
> > Thanks and Regards
> > Bramha Prasad Pandey
> > Indian School of Mines(ISM)
> > Dhanbad, INDIA.
> 
> > ___
> > Pw_forum mailing list
> > Pw_forum at pwscf.org
> > http://pwscf.org/mailman/listinfo/pw_forum
> 
> 
> ---
> Paolo Giannozzi, Dept of Chemistry,
> Univ. Udine, via delle Scienze 208, 33100 Udine, Italy
> Phone +39-0432-558216, fax +39-0432-558222
> 
> 
> 
> 
> ___
> Pw_forum mailing list
> Pw_forum at pwscf.org
> http://pwscf.org/mailman/listinfo/pw_forum
> 
> 
> 
> 
> -- 
> Thanks and Regards
> Bramha Prasad Pandey
> Indian School of Mines(ISM)
> Dhanbad, INDIA.
> ___
> Pw_forum mailing list
> Pw_forum at pwscf.org
> http://pwscf.org/mailman/listinfo/pw_forum
-- 
Andrea Dal CorsoTel. 0039-040-3787428
SISSA, Via Bonomea 265  Fax. 0039-040-3787249
I-34136 Trieste (Italy) e-mail: dalcorso at sissa.it

[Pw_forum] inadequate format statements in PHonon

[Andrea Dal Corso]

Ok, thank you. I have inserted your changes in the svn version.

Andrea

On Wed, 2012-12-05 at 18:42 -0500, David Strubbe wrote:
> Dear QE developers,
> 
> 
> There are a number of places in the PHonon code where "i2" is used as
> a format for writing indices of atoms or modes, which means that if
> you have more than 33 atoms you get ** instead of the actual number. I
> suggest you patch these to i6 or something, for more useful output.
> 
> 
> dyndia.f90:93:9010 format   (5x,'omega(',i2,') =',f15.6,' [THz]
> =',f15.6,' [cm-1]')
> elphon.f90:749:9010 FORMAT(5x,'lambda(',i2,')=',f8.4,'
> gamma=',f8.2,' GHz')
> elphon.f90:963:9010 FORMAT(5x,'lambda(',i2,')=',f8.4,'
> gamma=',f8.2,' GHz')
> lambda.f90:178:9010 format(12x,i2,2x,f8.4,9x,f8.2)
> phq_summary.f90:123:  WRITE( stdout, '(7x,i2,5x,a6,f8.4,"   tau(",i2,
> &
> write_eigenvectors.f90:51:9010 format(5x,'omega(',i2,')
> =',f15.6,' [THz] =',f15.6,' [cm-1]')
> write_eigenvectors.f90:101:9010 format(5x,'omega(',i2,')
> =',f15.6,' [THz] =',f15.6,' [cm-1]')
> 
> 
> David Strubbe
> MIT
> ___
> Pw_forum mailing list
> Pw_forum at pwscf.org
> http://pwscf.org/mailman/listinfo/pw_forum
-- 
Andrea Dal CorsoTel. 0039-040-3787428
SISSA, Via Bonomea 265  Fax. 0039-040-3787249
I-34136 Trieste (Italy) e-mail: dalcorso at sissa.it

[Pw_forum] Band Structure plot

[Andrea Dal Corso]

Please choose some path in reciprocal space. The plotting program gets
confused if the k points do not follow a path.
Points 9-14 are not along a line: 

0.098305  0.056756  0.00
0.491523  0.283781  0.00
0.00  0.00  0.00
0.081921  0.141891  0.00
0.054614  0.094594  0.00
0.081921  0.141891  0.00

The same for the last three points

0.300375  0.520265  0.00
0.327682  0.567562  0.00
0.393219  0.397293  0.00
0.491523  0.283781  0.00

HTH,

Andrea

On Tue, 2012-11-20 at 05:12 +, Tsogbadrakh N wrote:
> Dear All,
> 
> I have checked interactively, the problem is same. 
> Main problem is "NaN" on the output file for plotband. The postscript does 
> not understand it.
> 
> My input file for plotband is not properly ? 
> 
>  
>   
> ---
> Dr. Tsogbadrakh Namsrai
> 
> 
> From: pw_forum-bounces at pwscf.org [pw_forum-bounces at pwscf.org] on behalf 
> of Paolo Giannozzi [giannozz at democritos.it]
> Sent: Monday, November 19, 2012 6:11 PM
> To: PWSCF Forum
> Subject: Re: [Pw_forum] Band Structure plot
> 
> On Mon, 2012-11-19 at 06:07 +, Tsogbadrakh N wrote:
> 
> 
> > My input file for plotband.x is below:
> > -
> >  Bulk_MoS2_NM_BANDS.dat
> >-8.0 10.0
> >Bulk_MoS2_NM_BANDS.gnuplot
> >Bulk_MoS2_NM_BANDS.ps
> >7.7085
> >0.05  7.7085
> > -
> >
> > The output file for plotband.x looks like
> 
> 
> ... a mess. Run plotband,x interactively. It will prompt for what
> it needs
> 
> PG
> 
> --
> Paolo Giannozzi, IOM-Democritos and University of Udine, Italy
> 
> 
> ___
> Pw_forum mailing list
> Pw_forum at pwscf.org
> http://pwscf.org/mailman/listinfo/pw_forum
> ___
> Pw_forum mailing list
> Pw_forum at pwscf.org
> http://pwscf.org/mailman/listinfo/pw_forum
-- 
Andrea Dal CorsoTel. 0039-040-3787428
SISSA, Via Bonomea 265  Fax. 0039-040-3787249
I-34136 Trieste (Italy) e-mail: dalcorso at sissa.it

[Pw_forum] point double group error - rhombohedral cell

[Andrea Dal Corso]

It is a problem of your input CELL_PARAMETERS. The routine that
recognizes the point group needs a few more digits in sqrt(3)/3 and
sqrt(3)/6. The following CELL_PARAMETERS seem to work.

  0.288675134   0.50  2.3175183
  0.288675134  -0.50  2.3175183
 -0.577350268   0.00  2.3175183


HTH,

Andrea

On Fri, 2012-11-16 at 19:42 +0100, Nicki Frank Hinsche wrote:
> Dear all,
> 
> starting a scf calc. I get the error
> 
> %%%
>  point double group ?
> %%%
> 
> the symmetry operations of the system are nevertheless correct. What  
> does the
> error message tells me? Browsing the code didn't gave me a leap forward.
> Please find my inputcard attached - probably I messed something up
> there.
> 
> thanks a lot,
> 
> Nicki
> 
> inputcard->
> 
> 
>   ibrav = 0,
>   celldm(1)=8.2845,
>   nat = 5,
>   ntyp = 2,
>   ecutwfc = ECUT_xyz,
>   noncolin=.true.,
>   lspinorb=.true.,
> /
> 
>   conv_thr = 1.0e-8
>   mixing_beta = 0.20
> /
> ATOMIC_SPECIES
> Te  111  Te.rel-3down.UPF
> Bi   111  Bi.rel-3down.UPF
> ATOMIC_POSITIONS {alat}
> Te -0.2886751 -0.500 -0.8622262
> Bi  0.2886751 -0.500 -0.4653284
> Te  0.000  0.000  0.000
> Bi -0.2886751  0.500  0.4653284
> Te  0.2886751  0.500  0.8622262
> CELL_PARAMETERS {hexagonal}
>   0.2886751   0.50  2.3175183
>   0.2886751  -0.50  2.3175183
> -0.5773502   0.00  2.3175183
> 
> 
> -
> Nicki Frank Hinsche, Dipl. Phys.
> Institute of physics - Theoretical physics,
> Martin-Luther-University Halle-Wittenberg,
> Von-Seckendorff-Platz 1, Room 1.07
> D-06120 Halle/Saale, Germany
> Tel.: ++49 345 5525462
> -
> 
> 
> ___
> Pw_forum mailing list
> Pw_forum at pwscf.org
> http://pwscf.org/mailman/listinfo/pw_forum

[Pw_forum] Collect irreps on q != Gamma

[Andrea Dal Corso]

Thank you for reporting this bug. I have corrected it in the svn
version. There are two solutions:

1) use wf_collect=.false. in pw calculation.

2) use the svn version of the file PHonon/PH/openfilq.f90 file.

HTH,

Andrea

On Fri, 2012-11-02 at 11:41 +0100, Silvia Bahmann wrote:
> Dear all,
> 
> I'm doing phonon calculations and successfully used the splitting over 
> q-points and irreps so far.
> 
> But recently I tried to calculate phonons on a single q point (not Gamma) 
> splitting over irreps. The splitted calculations ran fine but the collecting 
> run produced an output like this:
> 
> [...]
> 
>  Starting wfc are   64 atomic wfcs
> 
> Possibly too few bands at point1   0.0   0.0   0.0
> 
> Possibly too few bands at point2   0.03864   0.00146   0.07634
> 
> Possibly too few bands at point3   0.0   0.0   0.01931
> [... to point 252 ...]
> 
>  
> %%
>  from openfilq : error # 1
>  file final_morek.wfc not found
>  
> %%
> 
>  stopping ...
> 
> 
> The *.wfc and save files are all where they need to be.
> 
> Since the same procedure works fine when the wanted q point is Gamma, I'm 
> quite confused about it.
> 
> Has anyone encountered the same problem yet? Is there any solution or 
> anything 
> I have overlooked?
> 
> Thanks in advance,
> Silvia
> 
> 
-- 
Andrea Dal CorsoTel. 0039-040-3787428
SISSA, Via Bonomea 265  Fax. 0039-040-3787249
I-34136 Trieste (Italy) e-mail: dalcorso at sissa.it

[Pw_forum] example problems

[Andrea Dal Corso]

Unfortunately this example has not been updated with a change in pw.x.
Please set:

startingwfc='atomic' 


The svn version is already updated.

HTH,

Andrea




On Tue, 2012-10-16 at 19:26 -0400, David Strubbe wrote:
> Dear QE developers,
> 
> I would like to point out a few problems in the examples for PW in
> espresso-5.0.1.
> 
> 
> example05 has a run_example script which is inconsistent with the
> README and reference directory, namely the script has calculations on
> Ni whereas the README and reference do not. 
> 
> 
> Moreover, running with ifort 12.1.5, default configuration returned by
> configure, using MKL, one of the Ni calculations does not converge.
>  results/Ni_gamma_d9s1.out ends with:
> 
>  iteration #100 ecut=27.00 Ry beta=0.25
>  Davidson diagonalization with overlap
>  ethr =  3.63E-10,  avg # of iterations =  2.5
> 
> 
>  negative rho (up, down):  0.000E+00 0.169E-04
> 
> 
>  total cpu time spent up to now is  236.0 secs
> 
> 
>  total energy  = -85.54366480 Ry
>  Harris-Foulkes estimate   = -85.54366495 Ry
>  estimated scf accuracy<   0.0015 Ry
> 
> 
>  total magnetization   = 2.00 Bohr mag/cell
>  absolute magnetization= 2.00 Bohr mag/cell
> 
> 
>  End of self-consistent calculation
> 
> 
>  convergence NOT achieved after 100 iterations: stopping
> 
> 
> By contrast, with openmpi 1.4, on 2 procs, it does converge.
> I have nothing to compare the run with otherwise, since it does not
> appear in the reference directory.
> 
> 
> 
> cluster_example is unable to download the pseudo (the pseudo's were
> successfully downloaded for me for all the other examples):
> 
> 
> Downloading H.pbe-kjpaw.UPF to /home/dstrubbe/espresso-5.0.1/pseudo...
> ERROR: /home/dstrubbe/espresso-5.0.1/pseudo/H.pbe-kjpaw.UPF not
> existent or not readable
> Aborting
> 
> 
> 
> 
> Sincerely,
> David Strubbe
> MIT
> ___
> Pw_forum mailing list
> Pw_forum at pwscf.org
> http://pwscf.org/mailman/listinfo/pw_forum

[Pw_forum] error : US j-average not yet implemented

[Andrea Dal Corso]

On Thu, 2012-10-11 at 22:14 +0530, Bramha Pandey wrote:
> Dear all
>  i want to use the 'Ga.rel-pbe-dn-kjpaw.UPF'  and
> 'As.rel-pbe-n-kjpaw.UPF' for the ZB-GaAs  syatem. 
> It is giving the following error:::
> I am using espresso-5.0.1 in serial version with ubuntu-12.04.
> 
> Error in routine setup (1):
>  US j-average not yet implemented
> 

These are fully relativistic PPs. You have to use them with
lspinorb=.true..


Andrea


> 
> This error is also the  same  for the full relativistic ultrasoft
> pseudopotential 'Ga.rel-pbe-dn-rrkjus.UPF' and
> 'As.rel-pbe-n-rrkjus.UPF'.
> 
> Any comment is appreciable in this regards.
> 
> -- 
> Thanks and Regards
> Bramha Prasad Pandey
> Ph.D Student Indian School of Mines(ISM)
> Dhanbad, INDIA.
> 
> ___
> Pw_forum mailing list
> Pw_forum at pwscf.org
> http://pwscf.org/mailman/listinfo/pw_forum

[Pw_forum] How to plot bands perfectly with plotband.x?

[Andrea Dal Corso]

Now use plotband.x on bands-down-lsym.dat. Plotband.x reads also
the .rap file and produces several files that you can plot with 
a graphical program.

Andrea


On Tue, 2012-09-04 at 20:12 +0800, Yue-Wen Fang wrote:
> I have use this way you said before, but  just got two files
> name bands-down-lsym.dat.rap and  bands-down-lsym.dat. 
> What's more this flag lsym=.true. costs much more time in computing
> obviously with 4 processors.
> 
>  PID USER  PR  NI  VIRT  RES  SHR S %CPU %MEMTIME+  COMMAND
>
>  2800 fyw   16   0 77416  33m 3332 R 89.9  0.2   5:53.96 bands.x
>   
>  2834 fyw   16   0 76864  33m 3092 R 89.6  0.2   5:46.15 bands.x
>   
>  2863 fyw   16   0 76344  33m 3092 R 89.6  0.2   5:48.02 bands.x
>   
>  2805 fyw   16   0 76992  33m 3092 R 86.9  0.2   5:34.04 bands.x 
> 
> 2012/9/4 Andrea Dal Corso 
> You can try the flag lsym=.true. as input of bands.x and plot
> all the
> files that are produced by plotband.x.
> 
> HTH,
> 
> Andrea
> 
> On Tue, 2012-09-04 at 18:04 +0800, Yue-Wen Fang wrote:
> > Dear all,
> >
> >
> > I plotted a bands diagram with plotband.x, but there is some
> chaos in
> > the diagram (namely the output file bands.ps).  The diagram
> was put in
> > the this website:
>  http://www.douban.com/group/topic/32502443/
> > I also tried to save the bands.xmgr as bands.dat and load it
> to
> >  origin 8.0 and Xmgrace, but all failed. The problem still
> emerged.
> > How to fix this program and curb the problem?
> >
> >
> > Best Regards!
> >
> >
> > --
> > 
> > Yue-Wen Fang
> >
> >
> >
> >
> >
>     
> > ___
> > Pw_forum mailing list
> > Pw_forum at pwscf.org
> > http://www.democritos.it/mailman/listinfo/pw_forum
> --
> Andrea Dal CorsoTel. 0039-040-3787428
> SISSA, Via Bonomea 265  Fax. 0039-040-3787249
> I-34136 Trieste (Italy) e-mail: dalcorso at sissa.it
> 
> 
> ___
> Pw_forum mailing list
> Pw_forum at pwscf.org
>     http://www.democritos.it/mailman/listinfo/pw_forum
> 
> 
> 
> 
> -- 
> 
> Yue-Wen Fang
> 
> 
> 
> 
> 
> 
> ___
> Pw_forum mailing list
> Pw_forum at pwscf.org
> http://www.democritos.it/mailman/listinfo/pw_forum
-- 
Andrea Dal CorsoTel. 0039-040-3787428
SISSA, Via Bonomea 265  Fax. 0039-040-3787249
I-34136 Trieste (Italy) e-mail: dalcorso at sissa.it

[Pw_forum] How to plot bands perfectly with plotband.x?

[Andrea Dal Corso]

You can try the flag lsym=.true. as input of bands.x and plot all the
files that are produced by plotband.x.

HTH,

Andrea

On Tue, 2012-09-04 at 18:04 +0800, Yue-Wen Fang wrote:
> Dear all,
> 
> 
> I plotted a bands diagram with plotband.x, but there is some chaos in
> the diagram (namely the output file bands.ps).  The diagram was put in
> the this website:  http://www.douban.com/group/topic/32502443/
> I also tried to save the bands.xmgr as bands.dat and load it to
>  origin 8.0 and Xmgrace, but all failed. The problem still emerged.
> How to fix this program and curb the problem?
> 
> 
> Best Regards!
> 
> 
> -- 
> 
> Yue-Wen Fang
> 
> 
> 
> 
> 
> ___
> Pw_forum mailing list
> Pw_forum at pwscf.org
> http://www.democritos.it/mailman/listinfo/pw_forum
-- 
Andrea Dal CorsoTel. 0039-040-3787428
SISSA, Via Bonomea 265  Fax. 0039-040-3787249
I-34136 Trieste (Italy) e-mail: dalcorso at sissa.it

[Pw_forum] set_irr.f90 in v5.0

[Andrea Dal Corso]

I think this is not a QE problem. In the definition of the direct
lattice vectors 

>0.86602500 1.5000 0.
>   -0.86602500 1.5000 0.
>0. 0. 8.66602500

there are too few digits in 0.86602500. This creates rotation matrices
that confuse the symmetry routines for the classification of the modes.

0.86602500 -> 0.866025403 fixes the problem.


HTH,

Andrea




On Tue, 2012-08-14 at 00:59 -0500, Jiseok Kim wrote:
> Dear, PW users
> 
> 
> I wonder if there is a progress or fix on the issue posted as below,
> 
> 
> http://www.democritos.it/pipermail/pw_forum/2012-July/024657.html
> 
> 
> I'm having the exactly same problem when I run the ph.x which did not
> happen in v4.3.
> I've tried to play around the threshold in set_irr.f90 (both line 258
> and 282 with 1.d-3, 1.d-2, 1.d-5) but it didn't help.
> What I could do was to set 'search_sym=.false.' then ph.x ran without
> error.
> But then mpi error happens when I run the matdyn.x to plot the
> dispersion..
> I have no idea if this relates with the  'search_sym=.false.'
> 
> 
> I run the working input files and parallel scheme previously used in
> v.4.3 as shown below.
> Thank you.
> 
> 
> 
> 
> pw.x
> =
> 
>   calculation = 'scf',
>   restart_mode= 'from_scratch',
>   prefix  = '$NAME',
>   pseudo_dir  = '$PSEUDO_DIR/',
>   outdir  = '$OUT_DIR/',
>   wf_collect  = .TRUE.
>   tstress = .TRUE.
>   tprnfor = .TRUE.
>   etot_conv_thr   = 1.d-5
>   forc_conv_thr   = 1.d-4
> /
> 
>   ibrav   = 0,
>   celldm(1)   = 2.687
>   nat = 2,
>   ntyp= 1,
>   ecutwfc = 45.0,
>   ecutrho = 450.0,
>   occupations = 'smearing',
>   smearing= 'mp',
>   degauss = 0.03,
> /
> 
>   diagonalization = 'cg',
>   mixing_mode = 'plain',
>   mixing_beta = 0.7,
>   conv_thr= 1.0d-8,
> /
> ATOMIC_SPECIES
> C  12.0107 C.pbe-rrkjus.UPF
> CELL_PARAMETERS
>0.86602500 1.5000 0.
>   -0.86602500 1.5000 0.
>0. 0. 8.66602500
> ATOMIC_POSITIONS (alat)
> C0.0   1.0   0.0
> C0.0   2.0   0.0
> K_POINTS automatic
> 8 8 1 0 0 0 
> ==
> 
> 
> 
> 
> ph.x
> ==
>  
>   tr2_ph= 1.d-14,
>   prefix= '$NAME',
>   outdir= '$OUT_DIR/',
>   fildyn= '$NAME.dyn',
>   ldisp = .true.,
>   nq1   = 8,
>   nq2   = 8,
>   nq3   = 1, 
>   amass(1)  = 12.0107,
> ==
> 
> 
> q2r.x
> ==
>  
>fildyn  = '$NAME.dyn' 
>flfrc   = '$NAME.881.fc'
>zasr= 'simple'
> ==
> 
> 
> 
> 
> matdyn.x
> ==
>  
>asr   = 'crystal'   
>amass(1)  = 12.0107,
>flfrc = '$NAME.881.fc'
>flfrq = '$NAME.freq'
>flvec = 'matdyn.modes'
>q_in_band_form=.TRUE.
> /
> 4
>   0.00 0.00 0.00 50 !G
>   0.288675 0.16 0.00 30 !M
>   0.192450 0.33 0.00 50 !K
>   0.00 0.00 0.00 50 !G
> ==
> 
> 
> 
> 
> 
> 
> JISEOK KIM, Ph.D.
> Postdoctoral Research Associate
> Department of Materials Science and Engineering
> University of Texas at Dallas
> 800 W. Campbell Rd. RL10
> Richardson, TX 75080
> (413)386-6285
> 
> ___
> Pw_forum mailing list
> Pw_forum at pwscf.org
> http://www.democritos.it/mailman/listinfo/pw_forum
-- 
Andrea Dal CorsoTel. 0039-040-3787428
SISSA, Via Bonomea 265  Fax. 0039-040-3787249
I-34136 Trieste (Italy) e-mail: dalcorso at sissa.it

[Pw_forum] Wrong frequencies on STO phonons

[Andrea Dal Corso]

What happens if you increase nbnd?

HTH,

Andrea

On Mon, 2012-07-23 at 13:21 -0500, "Alejandro R?bola" wrote:
> Dear Paolo,
> 
> The solution was to use the 5.0 version. I tried many times with the 4.2.1
> (default on NERSC for some reason), and also with the 4.3.2 version,
> obtaining all the time wrong frequencies and wrong dielectric constants. I
> also did the same calculations on a different cluster, where they have the
> 4.3.2 version, same result. I was using exactly the same input files in
> all cases and repeating the whole procedure -recalculating scf step. I
> have no idea what could be the problem. But when I redid everything with
> the 5.0 version instead, I got same results as you did.
> Thank you for your time and help,
> 
> Alejandro
> 
> On Sun, July 22, 2012 1:58 am, Paolo Giannozzi wrote:
> >
> > On Jul 21, 2012, at 12:55 , Alejandro R?bola wrote:
> >
> >> I'm running the very same files on NERSC, using espresso 4.3.2 and
> >> what
> >> I'm getting is:
> >
> > here is what I get (with smaller thresholds, but it makes no
> > difference):
> > http://www.fisica.uniud.it/~giannozz/public/STO.tar.gz
> >
> > P.
> > ---
> > Paolo Giannozzi, Dept of Chemistry,
> > Univ. Udine, via delle Scienze 208, 33100 Udine, Italy
> > Phone +39-0432-558216, fax +39-0432-558222
> >
> >
> >
> >
> > ___
> > Pw_forum mailing list
> > Pw_forum at pwscf.org
> > http://www.democritos.it/mailman/listinfo/pw_forum
> >
> >
> 
> 
> ___
> Pw_forum mailing list
> Pw_forum at pwscf.org
> http://www.democritos.it/mailman/listinfo/pw_forum
-- 
Andrea Dal CorsoTel. 0039-040-3787428
SISSA, Via Bonomea 265  Fax. 0039-040-3787249
I-34136 Trieste (Italy) e-mail: dalcorso at sissa.it

[Pw_forum] anomaly in phonon frequencies as obtained using DFPT (ph.x) in a spin-orbit calculation

[Andrea Dal Corso]

Can you give more information? Which system is it? Does the scalar
relativistic phonon calculation have the correct symmetry?

A.

On Tue, 2012-07-17 at 18:46 +0530, Koushik Pal wrote:
> Dear sir,
>   I calculated the phonon frequencies of a system using both the
> frozen phonon method as well as DFPT (ph.x) in fully relativistic
> regime (spin-orbit interaction) using QE verson 4.3. According to
> group theory the 12 optical modes of the system are 2A1g + 2Eg + 2A2u
> +2Eu. I got accurate results for the frequncies in the frozen phonon
> method (means, the frequencies obeyed the symmetry rule as predicted
> by the group theory. Also I visualized the eigenmodes which also agree
> well), but in the DFPT (linear response theory), the obtained
> frequencies and eigenmodes do not obey the above symmetry principles
> as predicted by group theory (though the frequencies are near the
> frequencies as obtained in frozen-phonon method) . It seems that the
> degeneracies in the frequencies are broken in DFPT. What is the reason
> behind that? Please help. Please give references with mathematical
> details (if available).
> 
> Thanks in advance.
> 
> =
> Koushik
> Grad. student
> Chemistry and Physics of Materials Unit
> JNCASR
> Bangalore , India
> ___
> Pw_forum mailing list
> Pw_forum at pwscf.org
> http://www.democritos.it/mailman/listinfo/pw_forum
-- 
Andrea Dal CorsoTel. 0039-040-3787428
SISSA, Via Bonomea 265  Fax. 0039-040-3787249
I-34136 Trieste (Italy) e-mail: dalcorso at sissa.it

[Pw_forum] Problem with visualizing wave function with appropriate sign (using "lsign") in a spin-orbit calculation

[Andrea Dal Corso]

This is a tricky question. At the moment in QE spinor wavefunctions that
are needed for spin-orbit are complex even at gamma. Therefore you
cannot extract the sign. That's the reason why this option is not
available and why there is not the gamma-only version of PW with
spinors.
Maybe somebody else has better ideas than me on how this point.

HTH,

Andrea


On Mon, 2012-07-16 at 22:00 +0530, Koushik Pal wrote:
> Dear sir,
>  I am doing a spin-orbit calculation and I want to visualize the
> wavefunction for a particular band with appropriate sign in it. I used
> the 'lisgn' variable with kpoint=1 (as in the scf.out file Gamma point
> is the first point in the kpoint list) in the input file of pp.x, .
> After running the pp.x, the program stops with an error "from
> local_dos : error #  1   not available". I searched the forum
> and got something on the same issue but it did not help me. Can
> somebody please help me how to include the sign of the wavefunction?
> Here is my pp.in file
> 
> 
> prefix  = 'abc'
> outdir = 'tmp'
> filplot = 'gamma-density.dat'
> plot_num= 7
> kpoint=1
> kband=32
> lsign=.true.
>  /
>  
> nfile = 1
> weight(1) = 1.0
> iflag = 3
> output_format = 3
> fileout = 'gamma-density1.xsf'
> nx=50,ny=50,nz=50
> 
> Thanks in advance.
> =
> Koushik
> Graduate student
> JNCASR
> Bangalore, India
> _______
> Pw_forum mailing list
> Pw_forum at pwscf.org
> http://www.democritos.it/mailman/listinfo/pw_forum
-- 
Andrea Dal CorsoTel. 0039-040-3787428
SISSA, Via Bonomea 265  Fax. 0039-040-3787249
I-34136 Trieste (Italy) e-mail: dalcorso at sissa.it

[Pw_forum] GRID example of e-ph

[Andrea Dal Corso]

On Tue, 2012-07-10 at 09:33 +0800, Peng Tao wrote:
> Dear all,
> 
> 
> As we know, the phonon calculation is quite slow and unexpected errors
> might occur at any time. 
> Thanks to the GRID example, split runs is available. However, no
> example is provided to split
> the e-ph calculation. So, dear professors, could you show me a method
> to realize it?
> 

PHonon/examples/GRID_example/run_example_2 

in QE 5.0. 

HTH

Andrea


> Sincerely yours
> Plato Tao
> 
> --
> ---
> PH.D. candidate Peng Tao 
> Magnetism and Magnetic Materials Division
> National Laboratory for Material Science
> Institute of Metal Research, Chinese Academy of Sciences
> Phone  +86-024-83978751
> ---
> 
> 
> 
> ___
> Pw_forum mailing list
> Pw_forum at pwscf.org
> http://www.democritos.it/mailman/listinfo/pw_forum
-- 
Andrea Dal CorsoTel. 0039-040-3787428
SISSA, Via Bonomea 265  Fax. 0039-040-3787249
I-34136 Trieste (Italy) e-mail: dalcorso at sissa.it

[Pw_forum] RE : error with spin polarized calculation with SOC

[Andrea Dal Corso]

You did an unsupported calculation by removing the error message.
The tefield case might work, while the lefield case is not implemented.
Please check the postprocessing tool bands.x to get the expectation
value of the spin for each band. This will tell you approximately which
bands have mainly spin up and which have mainly spin-down, but note that
with spin orbit, bands are not eigenstates of the spin.

HTH

Andrea

On Thu, 2012-07-05 at 14:59 +0300, Thaneshwor Kaloni wrote:
> Dear Andrea,
> 
> 
> >This option is not implemented. You cannot do a finite electric
> >field
> >calculation with spin-orbit coupling.
> 
> 
> I have done electric field + SOC calculation already as suggested by
> Professor Gabriele Sclauzero.
> Now the question is how to get spin up and spin down bnads?
> 
> 
> Best, Kaloni
> 
> 
> 
> 
> On Thu, Jul 5, 2012 at 2:54 PM, Andrea Dal Corso 
> wrote:
> 
> On Thu, 2012-07-05 at 14:27 +0300, Thaneshwor Kaloni wrote:
> > Dear Professor Cyrille,
> >
> >
> > Thank you very much for your prompt and kind reply.
> > But still I am getting following kind of error with
> inclusion of
> > nspin=4
> >
> >
> >  from iosys : error # 1
> >  LSDA not available with electric field
> 
> 
> This option is not implemented. You cannot do a finite
> electric field
> calculation with spin-orbit coupling.
> 
> HTH
> 
> Andrea
> 
> 
> >
> >
> >
> > On Thu, Jul 5, 2012 at 2:18 PM, BARRETEAU Cyrille
> >  wrote:
> > If you want to use SOC or do non-collinear
> caculation you
> > should take nspin=4
> > (If you do not define nspin it will be automatically
> be set to
> > 4)
> >
> >   Cyrille
> >
> >
> >
> 
> > Cyrille Barreteau
> phone :  +33 (0)1 69 08 29 51
> > CEA Saclay
> cellphone:   +33 (0)6 47 53 66 52
> > IRAMIS, SPCSI,  Bat. 462fax :
>  +33 (0)1 69 08 84 46
> > 91191 Gif sur Yvette Cedex   email:
>cyrille.barreteau at cea.fr
> > FRANCE
> > 
> > Web: http://iramis.cea.fr/Pisp/cyrille.barreteau/
> >
> ==
> >
> 
> >
> __
> > De : pw_forum-bounces at pwscf.org
> [pw_forum-bounces at pwscf.org]
> > de la part de Thaneshwor Kaloni [tkaloni at gmail.com]
> > Date d'envoi : jeudi 5 juillet 2012 12:47
> > ? : pw_forum
> > Objet : [Pw_forum] error with spin polarized
> calculation with
> > SOC
> >
> >
> >
> > Dear QE Users,
> >
> >
> > I would like to perform spin polarized calculations
> with SOC.
> > I am receiving following errors. Could anyone please
> assist
> > me?
> >
> >
> >
> >
> > **
> > INPUT
> > ***
> > 
> > calculation='scf',
> > restart_mode='from_scratch',
> > prefix='C',
> > pseudo_dir = '/home/kalonitp/code/pseudo/',
> > outdir='t/',
> > tefield = .true.
> > dipfield = .true.
> > /
> >  
> > ibrav = 4, a=3.86, b=3.86,
> > c=15,cosac=0.0, cosbc=0.0, cosab=-0.5
> > nat=2, ntyp=1, nbnd=10,
> > ecutwfc =60,
> > occupations='smearing',smearing='gaussian',
> degauss=0.05,
> > lspinorb=.true.
> > noncolin=.true.

[Pw_forum] RE : error with spin polarized calculation with SOC

[Andrea Dal Corso]

ax angular momentum in pseudopotentials (lmaxx) =  3
>  Waiting for input...
>  Presently no symmetry can be used with electric field
> 
> 
>  %
> %
>  from iosys : error # 1
>  noncolin .and. nspin==2 are conflicting flags
>  %
> %
> 
> 
>  stopping ...
> 
> 
> Best, Kaloni 
> King Abdullah University of Science and Technology
> KSA, Saudi Arabia
> 
> 
> 
> 
> -- 
> Best regards, Kaloni
> Web page:
> http://sa.linkedin.com/pub/thaneshwor-kaloni/18/955/238
> 
> 
> 
> 
> 
> 
> ___
> Pw_forum mailing list
> Pw_forum at pwscf.org
> http://www.democritos.it/mailman/listinfo/pw_forum
-- 
Andrea Dal CorsoTel. 0039-040-3787428
SISSA, Via Bonomea 265  Fax. 0039-040-3787249
I-34136 Trieste (Italy) e-mail: dalcorso at sissa.it

[Pw_forum] electron_phonon="interpolated" with trans=.false. fails

[Andrea Dal Corso]

Thank you for reporting this. Actually the problem was there since
espresso-4.2.0. I have now corrected the svn version.

Andrea


On Sun, 2012-06-17 at 17:52 +0200, Alaska Subedi wrote:
> > The program
> > crashes in the elphon subroutine while calling davcio_drho.
> 
> It seems the problem is that the arrays int3 and int3_nc (and possibly
> others) do not get allocated when trans = .false. as they have now
> been removed from allocate_phq.f90.
> 
> 
> Alaska
> ___
> Pw_forum mailing list
> Pw_forum at pwscf.org
> http://www.democritos.it/mailman/listinfo/pw_forum
-- 
Andrea Dal CorsoTel. 0039-040-3787428
SISSA, Via Bonomea 265  Fax. 0039-040-3787249
I-34136 Trieste (Italy) e-mail: dalcorso at sissa.it