[QE-users] computational efficiency with CPMD

[Lu Hailin]

Dear all,



the cpmd calculation costs too much time .The model contains 112 atoms,72 of 
them are Fe atoms .
If the model runs 10ps of md with 12 CPU,it may need 1600h,it's amazing and not 
realistic.so,I doubt that if some parameters are not reasonable .follwing is my 
input file,any suggestions would appreciate.
 calculation  = 'cp', title = ' MD Simulation' , 
restart_mode = 'reset_counters', ndr =93,ndw =94, nstep  = 2,iprint 
= 50,isave  = 50,  dt = 5.D0, tstress = .TRUE., tprnfor = .TRUE.,   
  prefix = 'FeGrFe', pseudo_dir = '/public/--/pseudo/ ',  outdir = 
'/public/--/tmp/' etot_conv_thr = 1.d-3, ekin_conv_thr = 1.d-3, 
forc_conv_thr = 1.d-2 /   ibrav = 0,  nat = 112, ntyp = 2,nspin=2,  nr1b 
= 24,nr2b = 24,nr3b = 24,  ecutwfc = 40.0, ecutrho = 235.0,  vdw_corr='DFT-D',  
 london_s6 = 0.75 /   electron_dynamics = 'verlet',  emass = 300, 
emass_cutoff = 2.5,  ortho_max=500, /ion_dynamics='verlet',   
ion_velocities = 'from_input',   ion_temperature='nose',   tempw=300, 
fnosep=4.,   ion_radius(1) = 0.7,   ion_radius(2) = 0.4, / CELL_PARAMETERS  
angstrom8.5992000   0.001   
0.0010.000  12.161105265558700   
0.0010.000   0.000  
20.000 ATOMIC_SPECIES   Fe  55.847  
Fe.rel-pbe-spn-rrkjus_psl.0.2.1.UPF   C   12.0107 C.pbe-n-rrkjus_psl.0.1.UPF 
ATOMIC_POSITIONS  crystal Fe   0.0.1660
0.062995231628  0  0  0  Fe   0.0.4990
0.062995231628  0  0  0  Fe   0.0.8330
0.062995231628  0  0  0  Fe   0.16600.0004
0.062995231628  0  0  0  Fe   0.16600.3330
0.062995231628  0  0  0  Fe   0.16600.6660
0.062995231628  0  0  0  Fe   0.33400.1660
0.062995231628  0  0  0  Fe   0.33400.4990
0.062995231628  0  0  0  Fe   0.33400.8330
0.062995231628  0  0  0  Fe   0.50000.0004
0.062995231628  0  0  0  Fe   0.50000.3330
0.062995231628  0  0  0  Fe   0.50000.6660
0.062995231628  0  0  0  Fe   0.66700.1660
0.062995231628  0  0  0  Fe   0.66700.4990
0.062995231628  0  0  0  Fe   0.66700.8330
0.062995231628  0  0  0  Fe   0.83300.0004
0.062995231628  0  0  0  Fe   0.83300.3330
0.062995231628  0  0  0  Fe   0.83300.6660
0.062995231628  0  0  0  Fe   0.0.
0.1643425434028180  Fe   0.0.3320
0.1643425434028180  Fe   0.0.6660
0.1643425434028180  Fe   0.16600.1660
0.1643425434028180  Fe   0.16600.4990
0.1643425434028180  Fe   0.16600.8330
0.1643425434028180  Fe   0.33400.
0.1643425434028180  Fe   0.33400.3320
0.1643425434028180  Fe   0.33400.6660
0.1643425434028180  Fe   0.50000.1660
0.1643425434028180  Fe   0.50000.4990
0.1643425434028180  Fe   0.50000.8330
0.1643425434028180  Fe   0.66700.
0.1643425434028180  Fe   0.66700.3320
0.1643425434028180  Fe   0.66700.6660
0.1643425434028180  Fe   0.83300.1660
0.1643425434028180  Fe   0.83300.4990
0.1643425434028180  Fe   0.83300.8330
0.1643425434028180  Fe   0.0.8330
0.395342546990  Fe   0.16600.6660
0.395342546990  Fe   0.33300.8330
0.395342546990  Fe   0.49900.6660
0.395342546990  Fe   0.66700.4990
0.395342546990  Fe   0.66700.8330
0.395342546990  Fe   0.83300.3330
0.395342546990  Fe   0.83300.6660
0.395342546990  Fe   0.0.1670
0.395342547000  Fe   0.0.4990
0.395342547000  Fe   0.16600.0003
0.395342547000  Fe   0.16600.3330 

Re: [QE-users] (no subject)

[Paolo Giannozzi]

On Mon, Apr 8, 2019 at 9:40 AM as gj  wrote:

>
> So i have a question : GWL treats only gamma point
>

yes

or it could done calculation for various kpoints ?
>

no, without major work on the code

Paolo
-- 
Paolo Giannozzi, Dip. Scienze Matematiche Informatiche e Fisiche,
Univ. Udine, via delle Scienze 208, 33100 Udine, Italy
Phone +39-0432-558216, fax +39-0432-558222
___
users mailing list
users@lists.quantum-espresso.org
https://lists.quantum-espresso.org/mailman/listinfo/users

Re: [QE-users] ?==?utf-8?q? vc-relax fixing ibrav

[Joaquim Jornet Somoza]

Thank you so much Lorenzo and Martin.
I didn't find it before !

Best
quim

Missatge de Lorenzo Paulatto  del dia dt., 2 d’abr. 2019
a les 8:59:

> Just to be clear: only available in qe 6.4  and later.
>
> --
> Lorenzo Paulatto
> Written on a virtual keyboard with real fingers
>
> On Tue, 2 Apr 2019, 08:47 Ing. Martin Matas,  wrote:
>
>> Dear Joaquim,
>>
>> I believe cell_dofree='ibrav' should do the work. The ibrav choice is
>> preserved in that case.
>>
>> Hope that helps.
>>
>> Martin Matas
>> University of West Bohemia
>> Pilsen, Czech Republic
>>
>>
>>
>>  Pondělí, 1 Duben, 2019 17:27 CEST, Joaquim Jornet Somoza <
>> j.jornet.som...@gmail.com> napsal:
>>
>> > Dear QuantumEspresso user,
>> >
>> > I would like to optimize the cell parameters of a molecular crystal by
>> > keeping the bravais lattice as ibrav=6 (i.e. dim(1)=a=b dim(3) = c/a
>> and
>> > all angles are 90º)
>> >
>> > However I could not find a keyword that preserves the a = b relation.
>> >
>> > Is any option to keep the cell optimization in the same point group ?
>> >
>> > Thanks in advance !
>> > quim
>> >
>> > --
>> >
>> 
>> > Dr. Joaquim Jornet Somoza
>> > Marie Skladowska-Curie IF Fellow  -  Postdoctoral Researcher
>> > email: j.jornet.som...@gmail.com   tel: 0034 650 73 48 91
>> > Theory Department
>> > The Max Planck Institute for the Structure and Dynamics of Matter (MPSD)
>> > Bldg. 99 (CFEL)
>> > Luruper Chaussee 149
>> > 22761 Hamburg
>> >
>> > Visiting Researcher
>> > Nano-Bio Spectroscopy group
>> > Departamento de Física de Materiales
>> > Universidad del País Vasco (UPV/EHU)
>> > Donostia-San Sebastián, Gipuzkoa, Spain
>>
>> ___
>> users mailing list
>> users@lists.quantum-espresso.org
>> https://lists.quantum-espresso.org/mailman/listinfo/users
>
> ___
> users mailing list
> users@lists.quantum-espresso.org
> https://lists.quantum-espresso.org/mailman/listinfo/users



-- 

Dr. Joaquim Jornet Somoza
Marie Skladowska-Curie IF Fellow  -  Postdoctoral Researcher
email: j.jornet.som...@gmail.com   tel: 0034 650 73 48 91
Theory Department
The Max Planck Institute for the Structure and Dynamics of Matter (MPSD)
Bldg. 99 (CFEL)
Luruper Chaussee 149
22761 Hamburg

Visiting Researcher
Nano-Bio Spectroscopy group
Departamento de Física de Materiales
Universidad del País Vasco (UPV/EHU)
Donostia-San Sebastián, Gipuzkoa, Spain
___
users mailing list
users@lists.quantum-espresso.org
https://lists.quantum-espresso.org/mailman/listinfo/users

Re: [QE-users] vc-relax for orthorhombic systems

[Lorenzo Paulatto]

Could you please rewrite the last sentence?


During the vc-relax procedure, the Fourier transform grid is kept fixed 
to avoid Pulay stress. The condition to incldue a certain plane wave in 
the basis set is hbar |G|^2 < Ecutwfc, and G is an integer linear 
combination of the reciprocal basis vectors b1, b2, b3. These b_i 
vectors change when the volume changes, which means that at the end of 
the relax, the basis set is not consistent with the cutoff and may be 
anisotropic. If you repeat the relax from scratch using the previous 
final configuration as the initial one, you may get different results. 
Rinse and repeat until you don't.


cheers



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

Re: [QE-users] query on number of k points in nscf

[Giovanni Cantele]

Dear Lorenzo,
thanks you for your prompt response. This is actually the case:
 Parallel version (MPI & OpenMP), running on2400 processor cores
 Number of MPI processes:  2400
 Threads/MPI process: 1

 MPI processes distributed on   100 nodes
 K-points division: npool =   2
 R & G space division:  proc/nbgrp/npool/nimage =1200
 wavefunctions fft division:  Y-proc x Z-proc =   2600
 wavefunctions fft division:  task group distribution
  #TGx Z-proc =   2600


So, it is explained also why the time used to compute 10 k-points coincides 
with the whole calculation
computational time.

Maybe, for the sake of clarity, it could be really explanatory if in the output 
in would be explicitly 
mentioned that only the output from pool #1 is give.

Thank you again,

Giovanni



> On 8 Apr 2019, at 12:37, Lorenzo Paulatto  wrote:
> 
> Dear Giovanni,
> if you are using pools, only a fraction of the k-points will be enumerated in 
> the NSCF calculation.
> kind regards
> 
> On 08/04/2019 12:07, Giovanni Cantele wrote:
>> Dear all,
>> I’ve experienced a “strange” (?) behaviour in an NSCF calculation. I’m using 
>> Quantum-ESPRESSO v. 6.4 on CINECA-Marconi.
>> The calculation is with no symmetry ("No symmetry found”) and lists 19 
>> k-points at the beginning of the calculation.
>> In the input the k-point specification is obtained through
>> K_POINTS { automatic }
>> 36  1  1   0 0 0
>> If I
>> grep "k =.*bands " NSCF.out | wc
>> 19 lines are correctly found in the output.
>> However
>> grep "Computing" NSCF.out
>> returns
>>  Computing kpt #: 1
>>  Computing kpt #: 2
>>  Computing kpt #: 3
>>  Computing kpt #: 4
>>  Computing kpt #: 5
>>  Computing kpt #: 6
>>  Computing kpt #: 7
>>  Computing kpt #: 8
>>  Computing kpt #:
>>  Computing kpt #:10
>> as if only 10 k-points were considered in the calculation. Even more 
>> strangely, by analizing the cpu-time information, I get
>>  Computing kpt #: 1
>>  c_bands: 56 eigenvalues not converged
>>  total cpu time spent up to now is13728.9 secs
>> [….]
>>  Computing kpt #:10
>>  c_bands: 48 eigenvalues not converged
>>  total cpu time spent up to now is   133710.2 secs
>> that is, the time for 10 k-points, is about 10 times that for a single 
>> k-point. However, the full calculation takes
>>  PWSCF:   1d13h59m CPU   1d15h18m WALL
>> about 1d and 13 hours, that is 37 hours that correspond to about 133000 
>> seconds. So it seems that the whole calculation
>> takes the same time as taken for the first 10 k-points.
>> So, the questions are:
>> 1) why only 10 “Computing ….” lines are printed in output?
>> 2) How can I be sure that the code effectively computed the k-points from 11 
>> to 19 (and if it did not do it, what are
>> the eigenvalues printed at the and of the output for those k-points)?
>> Maybe I’m missing something very trivial (in the case I apologise for 
>> that!), but I cannot figure out what!
>> I also checked PW/src/c_bands.f90 and it seems that the line
>>  IF ( iverbosity > 0 ) WRITE( stdout, 9001 ) ik
>> is within the loop
>> k_loop: DO ik = ik_+1, nks
>> so the printing of the message with format
>> 9001 FORMAT(/' Computing kpt #: ',I5 )
>> should occur for either all k-points or none of them.
>> I thank you in advance for any suggestion.
>> 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  
>> >
>> gcant...@gmail.com  > >
>> Phone: +39 081 676910
>> Skype contact: giocan74
>> Web page:https://sites.google.com/view/giovanni-cantele 
>> 
>> ___
>> users mailing list
>> users@lists.quantum-espresso.org 
>> https://lists.quantum-espresso.org/mailman/listinfo/users 
>> 
> 
> -- 
> Lorenzo Paulatto - Paris
> ___
> users mailing list
> users@lists.quantum-espresso.org 
> https://lists.quantum-espresso.org/mailman/listinfo/users 
> 
-- 

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
gcant...@gmail.com
Phone: +39 

[QE-users] vc-relax for orthorhombic systems

[Aleksandra Oranskaia]

d C. I learned the naming scheme and found some mismatch
> 
> For example: For Cu, the first entry in the PS library list is in the website 
> shows the following information
> Cu.pbe-dn-kjpaw_psl.1.0.0.UPF<https://www.quantum-espresso.org/upf_files/Cu.pbe-dn-kjpaw_psl.1.0.0.UPF>
> 
> Origin: PS Library
> Author: ADC
> Generated using "atomic" code by A. Dal Corso  v.6.3
> 
> Pseudopotential type: USPP
> Functional type: PBE
> Non Linear Core Correction
> Scalar relativistic
> 
> 
> When I opened the file, it shows Pseudopotential type as PAW.
> 
> 
>  
> Generated using "atomic" code by A. Dal Corso  v.6.3
> Author: ADC
> Generation date:  6Sep2018
> Pseudopotential type: PAW
> Element: Cu
> 
> Another entry in the PSLibrary 
> Cu.pbe-dn-kjpaw_psl.0.2.UPF<https://www.quantum-espresso.org/upf_files/Cu.pbe-dn-kjpaw_psl.0.2.UPF>
>  mention Pseudopotentail type PAW in the website and in the file.
> 
> Cu.pbe-dn-kjpaw_psl.0.2.UPF<https://www.quantum-espresso.org/upf_files/Cu.pbe-dn-kjpaw_psl.0.2.UPF>
> 
> Origin: PS Library
> Author: ADC
> Generated using "atomic" code by A. Dal Corso  v.5.0.2 svn rev. 9415
> 
> Pseudopotential type: PAW
> Functional type: PBE
> Non Linear Core Correction
> Scalar relativistic
> 
> Similarly for other elements such as C and O.
> 
> Is it just an error in the website ?? Or is there any physical meaning in 
> these changes??
> 
> Thanks
> 
> Rajesh
> -- next part --
> An HTML attachment was scrubbed...
> URL: 
> <http://lists.quantum-espresso.org/pipermail/users/attachments/20190408/8d9b6d59/attachment-0001.html>
> 
> --
> 
> Message: 3
> Date: Mon, 8 Apr 2019 09:17:00 +0200
> From: Pietro Davide Delugas 
> To: users@lists.quantum-espresso.org
> Subject: Re: [QE-users] Compilation on a server ends with error 1
> Message-ID: <3f1fd403-cee6-2b21-4e8a-c8fbabaa9...@sissa.it>
> Content-Type: text/plain; charset="windows-1252"; Format="flowed"
> 
> Dear Paolo
> 
> :) many compliments to your system administrator ...
> 
> this is yet an other issue with a too compiler version. It is very 
> likely the case that your mpif90 is still using fortran 4.4.6 just check 
> with mpif90 --version? and see what it prints out.
> If mpif90 is using 5.4 the simpler thing to do is to oblige the 
> compiler, and change line 58 of PP/src/plotband.f90 from
> 
> CHARACTER(len=:), ALLOCATABLE :: line
> 
> to
> 
> CHARACTER(len=2048), ALLOCATABLE :: line
> 
> and anything should be working. You can meet other errors of this kind, 
> read carefully the error messages and try to fix them.
> 
> In the case ( I am afraid it is actually the case) that mpif90 is using 
> the old fortran version, you need to install an? mpi library that uses 
> your desired gfortran version.
> 
> It is a little bit complicated but not very difficult, just takes a bit 
> of time and patience,? you have just to download the source, better a 
> not too old or not too new one , for example this one should work:
> 
> https://download.open-mpi.org/release/open-mpi/v2.0/openmpi-2.0.4.tar.gz
> 
> follow configure instructions taking care to enable f90 API and to?? 
> point? to the right fortran compiler.
> It's up to you to decide whether it takes less time doing this? by 
> yourself,? or convince the system administrator to help you ...
> best wishes
> Pietro
> 
> 
> 
> 
> 
> On 04/08/2019 01:53 AM, Fabio Costa wrote:
>> Dear Paolo and Pietro
>> 
>> Thanks for the assistance, and sorry for the late reply on your advice.
>> 
>> I contacted the system administrator, and he explained to me that as 
>> there are several other applications running under this old gfortran 
>> version, and because of that he could not just issue "sudo apt update 
>> gfortran", on the risk of messing up with all the other stuff 
>> currently running on the system. His advice to me was to manually 
>> install a newer version inside my workspace.
>> 
>> I did that, and now I have both the native 4.4.6 and the 5.4.0 
>> gfortran compilers. I also added to my bashrc the line "export 
>> F90=/path/to/gfortran5.4.0/". When i run configure, it detects the 
>> gfortran v5.4.0, so I think that I did this right. At first, make all 
>> still crashes at phcg.x. I proceeded changing the lines in Makefile as 
>> Pietro sugested, and when compiling again it goes a bit further, but 
>> still crashes. To avoid these crashes, I tryed to compile just the 
>> packages I'm intending to use (pw, ph, w90 and epw). By i

Re: [QE-users] query on number of k points in nscf

[Lorenzo Paulatto]

Dear Giovanni,
if you are using pools, only a fraction of the k-points will be 
enumerated in the NSCF calculation.

kind regards

On 08/04/2019 12:07, Giovanni Cantele wrote:

Dear all,

I’ve experienced a “strange” (?) behaviour in an NSCF calculation. I’m 
using Quantum-ESPRESSO v. 6.4 on CINECA-Marconi.


The calculation is with no symmetry ("No symmetry found”) and lists 19 
k-points at the beginning of the calculation.

In the input the k-point specification is obtained through
K_POINTS { automatic }
36  1  1   0 0 0

If I
grep "k =.*bands " NSCF.out | wc
19 lines are correctly found in the output.
However
grep "Computing" NSCF.out
returns
      Computing kpt #:     1
      Computing kpt #:     2
      Computing kpt #:     3
      Computing kpt #:     4
      Computing kpt #:     5
      Computing kpt #:     6
      Computing kpt #:     7
      Computing kpt #:     8
      Computing kpt #:
      Computing kpt #:    10
as if only 10 k-points were considered in the calculation. Even more 
strangely, by analizing the cpu-time information, I get

      Computing kpt #:     1
      c_bands: 56 eigenvalues not converged
      total cpu time spent up to now is    13728.9 secs
[….]
      Computing kpt #:    10
      c_bands: 48 eigenvalues not converged
      total cpu time spent up to now is   133710.2 secs

that is, the time for 10 k-points, is about 10 times that for a single 
k-point. However, the full calculation takes

      PWSCF        :   1d13h59m CPU   1d15h18m WALL
about 1d and 13 hours, that is 37 hours that correspond to about 133000 
seconds. So it seems that the whole calculation

takes the same time as taken for the first 10 k-points.

So, the questions are:

1) why only 10 “Computing ….” lines are printed in output?
2) How can I be sure that the code effectively computed the k-points 
from 11 to 19 (and if it did not do it, what are

the eigenvalues printed at the and of the output for those k-points)?


Maybe I’m missing something very trivial (in the case I apologise for 
that!), but I cannot figure out what!


I also checked PW/src/c_bands.f90 and it seems that the line
  IF ( iverbosity > 0 ) WRITE( stdout, 9001 ) ik
is within the loop
k_loop: DO ik = ik_+1, nks
so the printing of the message with format
9001 FORMAT(/'     Computing kpt #: ',I5 )
should occur for either all k-points or none of them.

I thank you in advance for any suggestion.

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 
gcant...@gmail.com 
Phone: +39 081 676910
Skype contact: giocan74
Web page:https://sites.google.com/view/giovanni-cantele


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



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

[QE-users] query on number of k points in nscf

[Giovanni Cantele]

Dear all,

I’ve experienced a “strange” (?) behaviour in an NSCF calculation. I’m using 
Quantum-ESPRESSO v. 6.4 on CINECA-Marconi.

The calculation is with no symmetry ("No symmetry found”) and lists 19 k-points 
at the beginning of the calculation.
In the input the k-point specification is obtained through
K_POINTS { automatic }
36  1  1   0 0 0 

If I
grep "k =.*bands " NSCF.out | wc
19 lines are correctly found in the output.
However
grep "Computing" NSCF.out 
returns
 Computing kpt #: 1
 Computing kpt #: 2
 Computing kpt #: 3
 Computing kpt #: 4
 Computing kpt #: 5
 Computing kpt #: 6
 Computing kpt #: 7
 Computing kpt #: 8
 Computing kpt #: 
 Computing kpt #:10
as if only 10 k-points were considered in the calculation. Even more strangely, 
by analizing the cpu-time information, I get
 Computing kpt #: 1
 c_bands: 56 eigenvalues not converged
 total cpu time spent up to now is13728.9 secs
[….]
 Computing kpt #:10
 c_bands: 48 eigenvalues not converged
 total cpu time spent up to now is   133710.2 secs

that is, the time for 10 k-points, is about 10 times that for a single k-point. 
However, the full calculation takes
 PWSCF:   1d13h59m CPU   1d15h18m WALL
about 1d and 13 hours, that is 37 hours that correspond to about 133000 
seconds. So it seems that the whole calculation
takes the same time as taken for the first 10 k-points.

So, the questions are:

1) why only 10 “Computing ….” lines are printed in output?
2) How can I be sure that the code effectively computed the k-points from 11 to 
19 (and if it did not do it, what are
the eigenvalues printed at the and of the output for those k-points)?


Maybe I’m missing something very trivial (in the case I apologise for that!), 
but I cannot figure out what!

I also checked PW/src/c_bands.f90 and it seems that the line 
 IF ( iverbosity > 0 ) WRITE( stdout, 9001 ) ik
is within the loop
k_loop: DO ik = ik_+1, nks
so the printing of the message with format
9001 FORMAT(/' Computing kpt #: ',I5 )
should occur for either all k-points or none of them.

I thank you in advance for any suggestion.

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
gcant...@gmail.com
Phone: +39 081 676910
Skype contact: giocan74
Web page: https://sites.google.com/view/giovanni-cantele

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

Re: [QE-users] vc-relax for orthorhombic systems

[Giuseppe Mattioli]

Dear Alex
Only a comment: Why do you need to be so tightly close to experimental  
lattice parameters? They are generally not the final output of a bunch  
of simulations. As you are not trying to validate a new functional or  
some new correction, your results seem to be close enough to  
experimental data to ensure the calculation of further parameters  
(DOS, band structure, absorption spectroscopy, conductivity, ...). If  
you need *exactly* to work with experimental lattice parameters for  
some reason instead, then use experimental values and do not perform  
vc-relax but relax calculations. Otherwise, I would start asking which  
experimental parameters are you trying to reproduce, e.g., at which  
temperature, how many defects were present in the experimental sample,  
... And I would answer that a "true experimental value" probably does  
not exist...


As you need practical answers and not philosophical ones, I would be  
satisfied of a result within 1% from "some measurements"


HTH
Giuseppe


Aleksandra Oranskaia  ha scritto:

Right now I am testing some desperate approaches like increasing  
k-points, decreasing mixing_beta together with trust_radii to force  
systems to change sightly fro step to step in vc-relax, etc.


I also thought that more precise calculation of stresses (in vc-relx  
routine) might help, does anyone have experience with parameters  
involved in stress calculations like ecfixed, qcutz, q2sigma?




Best,
Alex.
___
Aleksandra Oranskaia (M.Sc.)
ChemS PhD student, KAUST
Phone: +966 50 1335254







On Apr 6, 2019, at 1:00 PM, users-requ...@lists.quantum-espresso.org wrote:

Send users mailing list submissions to
users@lists.quantum-espresso.org

To subscribe or unsubscribe via the World Wide Web, visit
https://lists.quantum-espresso.org/mailman/listinfo/users
or, via email, send a message with subject or body 'help' to
users-requ...@lists.quantum-espresso.org

You can reach the person managing the list at
users-ow...@lists.quantum-espresso.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of users digest..."


Today's Topics:

  1. vc-relax for orthorhombic systems (Aleksandra Oranskaia)


--

Message: 1
Date: Fri, 5 Apr 2019 19:39:39 +0300
From: Aleksandra Oranskaia 
To: Quantum Espresso users Forum 
Subject: [QE-users] vc-relax for orthorhombic systems
Message-ID: <8fca3967-9817-4748-b8d3-34ec6f029...@kaust.edu.sa>
Content-Type: text/plain; charset="iso-8859-1"

Dear QE users and developers,

1 When dealing with orthorhombic systems, I start with space_group  
super-tight relaxation of the atomic positions (keeping right  
balance in force and scf accuracy, increasing ecutrho plus 100 Ry  
than my system actually requires, etc), continue with vc-relax  
using dofree = ibrav (and press_thr = 0.0), and Always obtain at  
least one lattice constant screwed up (with an error like +/- 0.1 A  
as compared to the experimental constant).
I tried 1000 setups for a few systems (varying functionals, vdw  
corrections, different pseudo libraries, etc) and have a feeling  
that sth is not right with vc-relax: for other than orthorhombic  
systems the results match the experimental lattice constants with  
an acceptable error.


2 I was wondering how vc-relax work for big orthorhombic unit  
cells. I took alpha-S8 (space group 70, so 128 atoms turn into 32  
within ibrav = 10 with 8 symmetry elements) and am not satisfied  
with any lattice constants: on PBEsol level, error in volume is <1%  
as compared to the experimental unit cell, but lattice constants  
are like 10.602 (exp: 10.465), 12.937 (exp: 12.866), 24.286 (exp:  
24.486) A that do not look acceptable at all :-(


I would hugely appreciate any comments,


Thanks,
Alex.
___
Aleksandra Oranskaia (M.Sc.)
ChemS PhD student, KAUST
Phone: +966 50 1335254







--

This message and its contents, including attachments are intended solely
for the original recipient. If you are not the intended recipient or have
received this message in error, please notify me immediately and delete
this message from your computer system. Any unauthorized use or
distribution is prohibited. Please consider the environment before printing
this email.
-- next part --
An HTML attachment was scrubbed...
URL:  



--

Subject: Digest Footer

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

--

End of users Digest, Vol 141, Issue 6
*



--

This message and its contents, including attachments are intended solely
for the original recipient. If you are not the intended recipient or have

Re: [QE-users] vc-relax for orthorhombic systems

[Lorenzo Paulatto]

actually requires, etc), continue with vc-relax using dofree = ibrav 


Hello Aleksandra, I've implemented that constraint in a very simple way, 
as long as the final pressure/strain is zero, there should be no 
problem, but better use it with a grain of salt.


Also, keep in mind that vc-relax is done at fixed number of plane-waves, 
not constant cutoff. You should always repeat it starting from the final 
configuration and



2 I was wondering how vc-relax work for big orthorhombic unit cells. I 
took alpha-S8 (space group 70, so 128 atoms turn into 32 within ibrav = 
10 with 8 symmetry elements) and am not satisfied with any lattice 
constants: on PBEsol level, error in volume is <1% as compared to the 
experimental unit cell, but lattice constants are like 10.602 (exp: 
10.465), 12.937 (exp: 12.866), 24.286 (exp: 24.486) A that do not look 
acceptable at all :-(


Do you have any reason to expect that DFT should perform better than 
this? It does not look like a very big discrepancy. 0.1 A is the order 
of the difference between PBE GGA and PZ LDA for very simple materials. 
Correcting for the lack of VdW interaction with a simple Grimme-D2 
method could be enough to get a better agreement.


I did some calculations in orthorhombic cells myself, and found it very 
difficult to be completely sure about the final relaxation. Because the 
material can be sort of soft, it is possible that a deformation that 
changes the angles and the cell sides while keeping the volume about 
constants has a very small energy gradient.


I would also guess that thermal effects could be important, hence 
considering the Free Energy (Enthalpy - TS) could be necessary. 
Unfortunately, this is quite expensive and complicated, even at the 
Quasi-Harmonic level.





I would hugely appreciate any comments,


Thanks,
Alex.
___
Aleksandra Oranskaia (M.Sc.)
ChemS PhD student, KAUST
Phone: +966 50 1335254








This message and its contents, including attachments are intended solely 
for the original recipient. If you are not the intended recipient or 
have received this message in error, please notify me immediately and 
delete this message from your computer system. Any unauthorized use or 
distribution is prohibited. Please consider the environment before 
printing this email.


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



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

Re: [QE-users] vc-relax for orthorhombic systems

[Aleksandra Oranskaia]

Right now I am testing some desperate approaches like increasing k-points, 
decreasing mixing_beta together with trust_radii to force systems to change 
sightly fro step to step in vc-relax, etc.

I also thought that more precise calculation of stresses (in vc-relx routine) 
might help, does anyone have experience with parameters involved in stress 
calculations like ecfixed, qcutz, q2sigma?



Best,
Alex.
___
Aleksandra Oranskaia (M.Sc.)
ChemS PhD student, KAUST
Phone: +966 50 1335254






> On Apr 6, 2019, at 1:00 PM, users-requ...@lists.quantum-espresso.org wrote:
> 
> Send users mailing list submissions to
>   users@lists.quantum-espresso.org
> 
> To subscribe or unsubscribe via the World Wide Web, visit
>   https://lists.quantum-espresso.org/mailman/listinfo/users
> or, via email, send a message with subject or body 'help' to
>   users-requ...@lists.quantum-espresso.org
> 
> You can reach the person managing the list at
>   users-ow...@lists.quantum-espresso.org
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of users digest..."
> 
> 
> Today's Topics:
> 
>   1. vc-relax for orthorhombic systems (Aleksandra Oranskaia)
> 
> 
> --
> 
> Message: 1
> Date: Fri, 5 Apr 2019 19:39:39 +0300
> From: Aleksandra Oranskaia 
> To: Quantum Espresso users Forum 
> Subject: [QE-users] vc-relax for orthorhombic systems
> Message-ID: <8fca3967-9817-4748-b8d3-34ec6f029...@kaust.edu.sa>
> Content-Type: text/plain; charset="iso-8859-1"
> 
> Dear QE users and developers,
> 
> 1 When dealing with orthorhombic systems, I start with space_group 
> super-tight relaxation of the atomic positions (keeping right balance in 
> force and scf accuracy, increasing ecutrho plus 100 Ry than my system 
> actually requires, etc), continue with vc-relax using dofree = ibrav (and 
> press_thr = 0.0), and Always obtain at least one lattice constant screwed up 
> (with an error like +/- 0.1 A as compared to the experimental constant).
> I tried 1000 setups for a few systems (varying functionals, vdw corrections, 
> different pseudo libraries, etc) and have a feeling that sth is not right 
> with vc-relax: for other than orthorhombic systems the results match the 
> experimental lattice constants with an acceptable error.
> 
> 2 I was wondering how vc-relax work for big orthorhombic unit cells. I took 
> alpha-S8 (space group 70, so 128 atoms turn into 32 within ibrav = 10 with 8 
> symmetry elements) and am not satisfied with any lattice constants: on PBEsol 
> level, error in volume is <1% as compared to the experimental unit cell, but 
> lattice constants are like 10.602 (exp: 10.465), 12.937 (exp: 12.866), 24.286 
> (exp: 24.486) A that do not look acceptable at all :-(
> 
> I would hugely appreciate any comments,
> 
> 
> Thanks,
> Alex.
> ___
> Aleksandra Oranskaia (M.Sc.)
> ChemS PhD student, KAUST
> Phone: +966 50 1335254
> 
> 
> 
> 
> 
> 
> 
> -- 
> 
> This message and its contents, including attachments are intended solely 
> for the original recipient. If you are not the intended recipient or have 
> received this message in error, please notify me immediately and delete 
> this message from your computer system. Any unauthorized use or 
> distribution is prohibited. Please consider the environment before printing 
> this email.
> -- next part --
> An HTML attachment was scrubbed...
> URL: 
> 
> 
> --
> 
> Subject: Digest Footer
> 
> ___
> users mailing list
> users@lists.quantum-espresso.org
> https://lists.quantum-espresso.org/mailman/listinfo/users
> 
> --
> 
> End of users Digest, Vol 141, Issue 6
> *


-- 

This message and its contents, including attachments are intended solely 
for the original recipient. If you are not the intended recipient or have 
received this message in error, please notify me immediately and delete 
this message from your computer system. Any unauthorized use or 
distribution is prohibited. Please consider the environment before printing 
this email.
___
users mailing list
users@lists.quantum-espresso.org
https://lists.quantum-espresso.org/mailman/listinfo/users

Re: [QE-users] Re-use of charge density don't give exactely the same result in scf

[Paolo Giannozzi]

On Mon, Apr 8, 2019 at 9:41 AM JAY Antoine 
wrote:

I suppose that this phenomenon is due to the accuracy (number of digits and
> number of points) used to saved the electronic density and the wfcs.
>

no, it's not: the charge density and Kohn-Sham orbitals are saved to file
with full precision

Paolo
-
Paolo Giannozzi, Dip. Scienze Matematiche Informatiche e Fisiche,
Univ. Udine, via delle Scienze 208, 33100 Udine, Italy
Phone +39-0432-558216, fax +39-0432-558222
___
users mailing list
users@lists.quantum-espresso.org
https://lists.quantum-espresso.org/mailman/listinfo/users

Re: [QE-users] Re-use of charge density don't give exactely the same result in scf

[Pietro Delugas]

ops sorry, I sent the message without checking the link ...

the parameter to  set the threshod of the diagonilization is

diago_thr_init

and the right link to the manual for it is:

https://www.quantum-espresso.org/Doc/INPUT_PW.html#idm783

Pietro

On 08/04/19 09:48, Pietro Delugas wrote:


Hello

just a plain   parameter from the boring manual, but it should work

https://www.quantum-espresso.org/Doc/INPUT_PW.html#idm735

Pietro

On 08/04/19 09:41, JAY Antoine wrote:

Dear all,
After a first scf calculation and saving charge density and wave 
functions,
I launch the same scf with these wave functions and charge density as 
an initialization (using startingpot and startingwfc).

I go from 27 scf cycles in the first run to only 4 at in the second run.
However, I was expecting that after the 2 first scf cycles, the 
energy difference is smaller than the conv_thr because it has already 
been converged during the first run.
I suppose that this phenomenon is due to the accuracy (number of 
digits and number of points) used to saved the electronic density and 
the wfcs.
Is it possible to confirm my assumption and to change this accuracy 
with a magic parameter?


Best regards,

Antoine Jay
ISAE-SUPAERO
Toulouse, France

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


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

Re: [QE-users] Re-use of charge density don't give exactely the same result in scf

[Pietro Delugas]

Hello

just a plain   parameter from the boring manual, but it should work

  https://www.quantum-espresso.org/Doc/INPUT_PW.html#idm735

Pietro

On 08/04/19 09:41, JAY Antoine wrote:

Dear all,
After a first scf calculation and saving charge density and wave 
functions,
I launch the same scf with these wave functions and charge density as 
an initialization (using startingpot and startingwfc).

I go from 27 scf cycles in the first run to only 4 at in the second run.
However, I was expecting that after the 2 first scf cycles, the energy 
difference is smaller than the conv_thr because it has already been 
converged during the first run.
I suppose that this phenomenon is due to the accuracy (number of 
digits and number of points) used to saved the electronic density and 
the wfcs.
Is it possible to confirm my assumption and to change this accuracy 
with a magic parameter?


Best regards,

Antoine Jay
ISAE-SUPAERO
Toulouse, France

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

[QE-users] Re-use of charge density don't give exactely the same result in scf

[JAY Antoine]

Dear all,
After a first scf calculation and saving charge density and wave functions,
I launch the same scf with these wave functions and charge density as an 
initialization (using startingpot and startingwfc).
I go from 27 scf cycles in the first run to only 4 at in the second run.
However, I was expecting that after the 2 first scf cycles, the energy 
difference is smaller than the conv_thr because it has already been converged 
during the first run.
I suppose that this phenomenon is due to the accuracy (number of digits and 
number of points) used to saved the electronic density and the wfcs.
Is it possible to confirm my assumption and to change this accuracy with a 
magic parameter?

Best regards,

Antoine Jay
ISAE-SUPAERO
Toulouse, France
___
users mailing list
users@lists.quantum-espresso.org
https://lists.quantum-espresso.org/mailman/listinfo/users

[QE-users] (no subject)

[as gj]

 Dear all QE users,
i am new user;
i would like to calculate InSb band structure by GW PBE. i tried it with
GWL and i have a result on gamma point only and i would all the band
structure.
So i have a question : GWL treats only gamma point or it could done
calculation for various kpoints ? If yes how it does ?

in another part,i am trying SternheimerGW application linked with QE.
currently, i work with QE6.2.0. And when i launch gw.x after scf
calculation (which runs and converges well)  from tutorial for Si, i have
the following error (in attached fil i put the gw.out):

 evaluate self energy for k = (  0.  0.  0. )

 Error in routine sigma.f90 (2):
 error opening ./tmp/_gw0/si.coul1
 stopping ...
i obtained the same for the second Li example and the another found in
examples folder.

I tried also on QE6.3 with the same Si tutorial abd i have the following
error which is different and i don't know why ?

 T E R N H E I M E R
http://www.sternheimergw.org/
   ### ###
  ###   ##  ###
#  #
  ### ##   ### #
##  #
   ###  ### #
## #
#  # #   #  #
#
   /// #  \\\ #  #   #  #
#
  ///  \\\#   # ## #
 ///### \\\   # # # ## #
(((  ### )))  # #  #   #  #   #
 \\\###  ###///##  #   #  #   #
  \\\######///  #  ## ## #
   \\\###  ###///#   ## ######
   ## ####  #


 Program SternheimerGW v.0.15 starts on  5Apr2019 at 10:52:17

 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);
 "P. Giannozzi et al., J. Phys.:Condens. Matter 29 465901 (2017);
  URL http://www.quantum-espresso.org;,
 in publications or presentations arising from this work. More details
at
 http://www.quantum-espresso.org/quote

 Serial version

 Please cite SternheimerGW as:
 M. Schlipf, H. Lambert, N. Zibouche, and F. Giustino,
SternheimerGW,
 paper in preparation, URL http://www.sternheimergw.org

 To increase the reproducibility of your results you can mention the
 git description of this version: unknown

 other relevant papers:
 H. Lambert and F. Giustino, Phys. Rev. B 88, 075117 (2013)
 F. Giustino, M. L. Cohen, and S. G. Louie, Phys. Rev. B 81, 115105
(201
0)

 Reading data from directory:
 ./tmp/si.save/

 IMPORTANT: XC functional enforced from input :
 Exchange-correlation  = PZ ( 1  1  0  0 0 0)
 Any further DFT definition will be discarded
 Please, verify this is what you really want


 G-vector sticks info
 
 sticks:   dense  smooth PW G-vecs:dense   smooth  PW
 Sum 235 235 85 2277 2277 531



 Coulomb Perturbations for ( 4, 4, 4,)  uniform grid of q-points
 (   8q-points):
   N xq(1) xq(2) xq(3)
   1   0.0   0.0   0.0
   2  -0.25000   0.25000  -0.25000
   3   0.5  -0.5   0.5
   4   0.0   0.5   0.0
   5   0.75000  -0.25000   0.75000
   6   0.5   0.0   0.5
   7   0.0  -1.0   0.0
   8  -0.5  -1.0   0.0

 %%
 Error in routine ggens (2):
 mismatch in number of G-vectors
 %%


someone can explain at what these errors are due to ?

thanks in advance for your answer,
Anne-Sophie
___
users mailing list
users@lists.quantum-espresso.org
https://lists.quantum-espresso.org/mailman/listinfo/users

[QE-users] Ab-Initio Thermal Transport

[Arihant Bhandari]

Respected QE users and developers,

I read the paper on calculating the thermal conductivity from the Density
Functional Theory (https://www.nature.com/articles/nphys3509). I am trying
to calculate the thermal conductivity for different systems using this
method. I do not have knowledge of how to do it with QE codes. I am unable
to find a detailed description of the thermal conductivity calculation in
the QE documentation.

The paper states that
"The methodology presented above has been implemented in the Quantum
ESPRESSO suite of computer codes: a Car–Parrinello (CP) AIMD trajectory is
first generated using the cp.x code; the energy flux is then evaluated
along this trajectory by an add-on to the pw.x code implemented using
several density-functional perturbation theory routines borrowed from the
ph.x code; the thermal conductivity is finally computed from the GK
relation, or the equivalent Einstein relation."

I am unable to follow this and do the computation. I will be very
grateful if someone can guide (for an amateur) to how to go about doing the
calculation or can provide a detailed documentation on how to do
the calculation (hands-on).

Thanks and regards
Arihant Bhandari
PhD student
Indian Institute of Technology Kanpur
___
users mailing list
users@lists.quantum-espresso.org
https://lists.quantum-espresso.org/mailman/listinfo/users

Re: [QE-users] Compilation on a server ends with error 1

[Pietro Davide Delugas]

Dear Paolo

:) many compliments to your system administrator ...

this is yet an other issue with a too compiler version. It is very 
likely the case that your mpif90 is still using fortran 4.4.6 just check 
with mpif90 --version  and see what it prints out.
If mpif90 is using 5.4 the simpler thing to do is to oblige the 
compiler, and change line 58 of PP/src/plotband.f90 from


CHARACTER(len=:), ALLOCATABLE :: line

to

CHARACTER(len=2048), ALLOCATABLE :: line

and anything should be working. You can meet other errors of this kind, 
read carefully the error messages and try to fix them.


In the case ( I am afraid it is actually the case) that mpif90 is using 
the old fortran version, you need to install an  mpi library that uses 
your desired gfortran version.


It is a little bit complicated but not very difficult, just takes a bit 
of time and patience,  you have just to download the source, better a 
not too old or not too new one , for example this one should work:


https://download.open-mpi.org/release/open-mpi/v2.0/openmpi-2.0.4.tar.gz

follow configure instructions taking care to enable f90 API and to   
point  to the right fortran compiler.
It's up to you to decide whether it takes less time doing this  by 
yourself,  or convince the system administrator to help you ...

best wishes
Pietro





On 04/08/2019 01:53 AM, Fabio Costa wrote:

Dear Paolo and Pietro

Thanks for the assistance, and sorry for the late reply on your advice.

I contacted the system administrator, and he explained to me that as 
there are several other applications running under this old gfortran 
version, and because of that he could not just issue "sudo apt update 
gfortran", on the risk of messing up with all the other stuff 
currently running on the system. His advice to me was to manually 
install a newer version inside my workspace.


I did that, and now I have both the native 4.4.6 and the 5.4.0 
gfortran compilers. I also added to my bashrc the line "export 
F90=/path/to/gfortran5.4.0/". When i run configure, it detects the 
gfortran v5.4.0, so I think that I did this right. At first, make all 
still crashes at phcg.x. I proceeded changing the lines in Makefile as 
Pietro sugested, and when compiling again it goes a bit further, but 
still crashes. To avoid these crashes, I tryed to compile just the 
packages I'm intending to use (pw, ph, w90 and epw). By issuing make 
pw, followed by make ph, make w90, the task is succesful, but It 
craches again when I issue make epw. The print screen of the error 
message is in the link: https://imgur.com/CerJStE .


Also, I'm still getting the same errors with the compiled executables. 
About Paolo's advice, in my current situation, where I cant just 
update the whole thing, and kinda have two version of gfortran. I'm 
not sure if the crashes are because when  the executables run, they 
are still linking to the gfortran 4.4.6. What course of action would 
you sugest?


Thank you for the assistance

Fábio Costa
MSc student in physics
Federal University of Bahia, Brazil


*De:* users  em nome de 
Paolo Giannozzi 

*Enviado:* quinta-feira, 28 de março de 2019 11:40
*Para:* Quantum Espresso users Forum
*Assunto:* Re: [QE-users] Compilation on a server ends with error 1
There are two unrelated problems:
- the linker is unable to find the main program in PHonon/Gamma. I 
have never seen this happen before, but the link is done in a slightly 
different way from all other cases and this will be fixed
- the executable doesn't work likely due to a known problem of many 
old compilers with unallocated optional variables


Paolo


On Thu, Mar 28, 2019 at 3:47 AM Fabio Costa > wrote:


Dear all

I'm trying to install QE-6.4 on a server, by doing the usual
procedure, ./configure and make all commands.

The configure step seems to be successful, but the compilation
fails after a couple minutes, with a message "make: *** [ph] Error
1". Even with this interruption, a few .x files are compiled, such
as pw.x, ph.x, etc., but when I try to run a calculation, It also
results in an error message.

Appologies for my not-so-much enlightening description, as I
myself could not extract many info from the error messages, so I
hope the print screens will be more helpfull than I could.

https://imgur.com/HeT8JMM
https://imgur.com/ZyyVGt3
https://imgur.com/DyYlO4R

Thanks in advance for any assistance

Fábio Costa
MSc student in physics
Federal University of Bahia, Brazil


Imgur 
Compilation error
imgur.com 




Imgur 
configure output
imgur.com 




Imgur 
pw.x error
   

[QE-users] Pseudopotential type is different in the website description and in the file

[Rajesh Raju]

Hi users,

I am new to QE and searching pseudopotential for my system which contains Cu 
and C. I learned the naming scheme and found some mismatch

For example: For Cu, the first entry in the PS library list is in the website 
shows the following information
Cu.pbe-dn-kjpaw_psl.1.0.0.UPF

Origin: PS Library
Author: ADC
Generated using "atomic" code by A. Dal Corso  v.6.3

Pseudopotential type: USPP
Functional type: PBE
Non Linear Core Correction
Scalar relativistic


When I opened the file, it shows Pseudopotential type as PAW.


  
Generated using "atomic" code by A. Dal Corso  v.6.3
Author: ADC
Generation date:  6Sep2018
Pseudopotential type: PAW
Element: Cu

Another entry in the PSLibrary 
Cu.pbe-dn-kjpaw_psl.0.2.UPF
 mention Pseudopotentail type PAW in the website and in the file.

Cu.pbe-dn-kjpaw_psl.0.2.UPF

Origin: PS Library
Author: ADC
Generated using "atomic" code by A. Dal Corso  v.5.0.2 svn rev. 9415

Pseudopotential type: PAW
Functional type: PBE
Non Linear Core Correction
Scalar relativistic

Similarly for other elements such as C and O.

Is it just an error in the website ?? Or is there any physical meaning in these 
changes??

Thanks

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