[Pw_forum] reusing wfc/charge density for nscf calculation with different total charge

[Alexey Akimov]

Dear Giuseppe,

Thank you for your suggestion. It is really helpful, indeed. I use the 
calculation = 'scf' as in your example (along with other options). But since i 
do not want to reoptimize the wavefunction again- i restrict the electronic scf 
cycle to only 1 iteration (with electron_maxstep = 1). I guess this is what the 
'nscf' type of calculation would do. Since the scf can not converge for one 
iteration it doesn't print the eigenvalues. To print them, even if the 
convergence is not achieved, i use iprint = 1. With these corrections it seems 
to fit my needs. 


Thank you,
Alexey



- Original Message -
From: "Giuseppe Mattioli" <giuseppe.matti...@ism.cnr.it>
To: "PWSCF Forum" 
Sent: Saturday, June 1, 2013 7:19:58 AM
Subject: Re: [Pw_forum] reusing wfc/charge density for nscf calculation with 
different total charge


Dear Alexey
I did not follow the whole thread, but I was looking at your latest  
input files, and I was wondering whether the options below might do  
the trick...

  
 calculation = 'scf'
 restart_mode='from_scratch'
 ...
  /

  
 ...
 startingpot = 'file'
 startingwfc = 'file'
  /

They should allow you for restarting from wfc and potential calculated  
at the end of the scf. I always used them to perform a scf run (with  
Hubbard alpha, you know...) after a previous scf run. I do not know if  
you can start a nscf calculation from scratch, but a scf calculation  
with the above constraint may be useful to your purpose...
HTH
Giuseppe

Giuseppe Mattioli
ISM-CNR
Italy

Quoting Alexey Akimov :

> Dear Paolo,
>
> First of all, thank you for your reply - i though that my message  
> haven't got to the forum.  Yes, you are right - if i set the same  
> tot_charge for nscf calculation as that for scf - everything works  
> fine. But the idea is to use different charges for nscf (+0.25) and  
> scf (0.0) calculations, and at the same time use the same  
> wavefunction (obtained from the scf calculation). So when i try to  
> do that, i get the errors below. I think this is because one is not  
> supposed to do this kind of trick, normally. So would it be possible  
> to do this without digging much into the code and rather using more  
> standard options?
>
> CRASH:
>   
> %%
>
> %%
>  task # 0
>  from potinit : error # 1
>  starting and expected charges differ
>   
> %%
>
>
> portion of the nscf output (i run on several CPUs):
>
>  The potential is recalculated from file :
>  ./x.save/charge-density.dat
>
>
>   
> %%
>
>   
> %%
>  Error in routine potinit (1):
>  starting and expected charges differ
>  Error in routine potinit (1):
>  starting and expected charges differ
>   
> %%
>
>  stopping ...
>
>   
> %%
>  Error in routine potinit (1):
>   
> %%
>
>  stopping ...
>
>
>
>
> Below are the relevant portions of the scf and nscf input files:
>
> SCF input:
>
> 
>   calculation = 'scf',
>   pseudo_dir = 
>   outdir = './',
>   prefix = 'x',
> /
>
> 
>   ibrav = 0,
>   celldm(1) = 1.89,
>   nat = 6,
>   ntyp = 1,
>   nbnd = 50,
>   tot_charge = 0.25,
>   occupations = 'smearing',
>   starting_magnetization(1) = 0.0,
>   smearing = 'gaussian',
>   degauss = 0.005,
>   ecutwfc = 40,
>   ecutrho = 400,
>   nspin = 2,
>   nosym = .true.,
> /
>
>
> NSCF input:
>
> 
>   calculation = 'nscf',
>   pseudo_dir = 
>   outdir = './',
>   prefix = 'x',
> /
>
> 
>   ibrav = 0,
>   celldm(1) = 1.89,
>   nat = 6,
>   ntyp = 1,
>   nbnd = 50,
>   tot_charge = 0.0,
>   starting_magnetization(1) = 0.0,
>   occupations = 'smearing',
>   smearing = 'gaussian',
>   degauss = 0.005,
>   ecutwfc = 40,
>   ecutrho = 400,
>   nspin = 2,
>   nosym = .true.,
> /
>
>
>
>
>
> - Original Message -
> From: "Paolo Giannozzi" 
> To: "PWSCF Forum" 
> Sent: Thursday, May 30, 2013 4:59:18 AM
> Subject: Re: [Pw_forum] reusing wfc/charge density for nscf  
> calculation with different total charge
>
> On Tue, 201

[Pw_forum] reusing wfc/charge density for nscf calculation with different total charge

[Alexey Akimov]

Dear Paolo,

First of all, thank you for your reply - i though that my message haven't got 
to the forum.  Yes, you are right - if i set the same tot_charge for nscf 
calculation as that for scf - everything works fine. But the idea is to use 
different charges for nscf (+0.25) and scf (0.0) calculations, and at the same 
time use the same wavefunction (obtained from the scf calculation). So when i 
try to do that, i get the errors below. I think this is because one is not 
supposed to do this kind of trick, normally. So would it be possible to do this 
without digging much into the code and rather using more standard options?

CRASH:
 %%
  %%
 task # 0
 from potinit : error # 1
 starting and expected charges differ
 %%


portion of the nscf output (i run on several CPUs):

 The potential is recalculated from file :
 ./x.save/charge-density.dat


 %%

 %%
 Error in routine potinit (1):
 starting and expected charges differ
 Error in routine potinit (1):
 starting and expected charges differ
 %%

 stopping ...

 %%
 Error in routine potinit (1):
 %%

 stopping ...




Below are the relevant portions of the scf and nscf input files:

SCF input:


  calculation = 'scf',
  pseudo_dir = 
  outdir = './',
  prefix = 'x',
/


  ibrav = 0,
  celldm(1) = 1.89,
  nat = 6,
  ntyp = 1,
  nbnd = 50,
  tot_charge = 0.25,
  occupations = 'smearing',
  starting_magnetization(1) = 0.0,
  smearing = 'gaussian',
  degauss = 0.005,
  ecutwfc = 40,
  ecutrho = 400,
  nspin = 2,
  nosym = .true.,
/


NSCF input:


  calculation = 'nscf',
  pseudo_dir = 
  outdir = './',
  prefix = 'x',
/


  ibrav = 0,
  celldm(1) = 1.89,
  nat = 6,
  ntyp = 1,
  nbnd = 50,
  tot_charge = 0.0,
  starting_magnetization(1) = 0.0,
  occupations = 'smearing',
  smearing = 'gaussian',
  degauss = 0.005,
  ecutwfc = 40,
  ecutrho = 400,
  nspin = 2,
  nosym = .true.,
/





- Original Message -
From: "Paolo Giannozzi" <paolo.gianno...@uniud.it>
To: "PWSCF Forum" 
Sent: Thursday, May 30, 2013 4:59:18 AM
Subject: Re: [Pw_forum] reusing wfc/charge density for nscf calculation with 
different total charge

On Tue, 2013-05-21 at 21:34 -0400, Alexey Akimov wrote:

> when PW (with the input for nscf calculations for neutral system)
> tries to read the wavefunction/charge density for the charged system
> it crashes, because the expected charge is different from the one
> deduced from the wfc files

I am not sure but if you set a charge (tot_charge) for the nscf as well,
the calculation should succeed. Note that nothing changes in the nscf
if you set a nonzero charge: only occupancies should change, not
eigenvalues, since these depend only upon the potential

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 at pwscf.org
http://pwscf.org/mailman/listinfo/pw_forum

-- 
Dr. Alexey V. Akimov

Postdoctoral Research Associate
Department of Chemistry
University of Rochester

aakimov_guest at z.rochester.edu 

[Pw_forum] reusing wfc/charge density for nscf calculation with different total charge

[Alexey Akimov]

Dear all,

I'm trying to use one of the methods to improve the band gaps (e.g. see Gaiduk, 
Firaha, Staroverov, PRL 108, 253005). The method requires the scf calculation 
for the charged system followed by the nscf calculations for the neutral 
system, but starting with the wavefunction/charge density obtained for the 
charged system. However, when PW (with the input for nscf calculations for 
neutral system) tries to read the wavefunction/charge density for the charged 
system it crashes, because the expected charge is different from the one 
deduced from the wfc files. So my question is: is it possible to do this trick 
in QE at all - to use the wfc/density converged for the charged system for the 
nscf calculations with the neutral system?

Thank you in advance,
Alexey

-- 
Dr. Alexey V. Akimov

Postdoctoral Research Associate
Department of Chemistry
University of Rochester

aakimov_guest at z.rochester.edu 

[Pw_forum] Fail to predict semiconductor

[Alexey Akimov]

Dear Giuseppe,

Thank you very much for sharing your experience. That is very deep analysis, 
indeed. It is definitely a good suggestion (i find it useful for myself, too :) 
) I just wanted to point out that in general the DFT results should be 
interpreted with care, especially in such a pathological case when 
semiconductor is a metal computationally. It is good that +U correction can 
help for this system, although it is somewhat empirical approach. Perhaps, 
doing PBE0 calculations would be more straightforward to apply and closer in 
spirit to the first-principles philosophy, although more expensive. 


- Original Message -
From: "Giuseppe Mattioli" <giuseppe.matti...@ism.cnr.it>
To: "PWSCF Forum" 
Sent: Thursday, January 24, 2013 6:40:28 AM
Subject: Re: [Pw_forum] Fail to predict semiconductor


Dear Alexey
I do not agree with your analysis. GGA is indeed affected by the well known, 
bloody delocalisation 
error, which leads (among other, several, painful problems) to an 
underestimation of the band gap of 
insulators and semiconductors. This said, the Ti-->Zn substitution in the ZnO 
lattice seems to be 
characterized by a quite peculiar behaviour that, in my opinion, may be only 
partly accountable for 
the above delocalisation (or double counting, self interaction, call it as you 
like...:-)) error. A 
DFT+U correction, by the way, is often able to cure a vast majority of the 
symptoms of 
delocalisation errors, but, like all drugs, must be carefully used in the best 
way. A substitutional 
Ti atom has two excess electrons with respect to the Zn one. In Iwan's 
calculation they are 
accommodated in a hugely k-dispersed (i.e., highly delocalized) band which 
falls about 1.2 eV above 
the valence band maximum at Gamma, and cross the conduction band minimum in 
some regions of the 
Brillouin zone. A gap of about 3.0 eV, obtained by "pushing down" the Zn 3d 
orbitals with a 7.0 eV U 
correction and, therefore, by disentangling the narrow 3d band from the broader 
O 2p band is quite 
similar to the optical 3.2~3.4 gap of ZnO, even if the Zn 4s nature (and 
potential energy) of the 
conduction band minimum is nearly unaffected by the correction. In my 
experience, a "conventional" 
behaviour of a GGA calculation of Ti doped ZnO would be represented by one of 
the following 
occurences

a) the two excess electron populate the conduction band minimum of ZnO

b) the two excess electrons are localized on atomic-like d orbitals of Ti

The 5.5 eV correction applied to the Ti 3d shell should favour b), but the 
actual results seem to be 
a curious mixing of a) and b). On the ground of such an analysis, I would 
suggest to perform an 
nspin=2 calculation because:

a) Ti(3+) ions are often reported in the case of n-type doping of TiO2, at 
variance with Ti(2+). I 
suspect that Ti cannot accommodate more than 1 excess electron in a 3d-like 
small polaron.

b) Iwan's results seems to suggest that the first excess electron could be 
accommodated in a single-
occupied, k-narrow, deep in the band gap Ti 3d orbital, while the second one 
could be accommodated 
in the k-dispersed conduction band minimum.

c) If I'm right, I expect to be mentioned in the acknowledgment section of 
Iwan's thesis...:-)

Yours

Giuseppe

P.S. It is not really polite to mention it, but it may be useful to Iwan to 
grab my recent 
publications on DFT+U calculations applied to TiO2 and ZnO...
  

On Wednesday 23 January 2013 21:53:37 Alexey Akimov wrote:
> Dear Iwan,
> 
> The pure DFT is known to underestimate the band gaps, eventually making
> semiconductor material to appear as a metal in your calculations. This
> problem arises because of the double-counting in exchange terms. The
> problem solved with the hybrid functionals, such as PBE0. The GGA
> approximation and even +U correction terms provide only small improvement
> over LDA. So this may not be enough to make your system to be
> semiconductor (computationally). To summarize,the problem is inherently
> with the DFT methododology.
> 
> Good luck,
> Alexey
> 
> - Original Message -
> From: "Iwan Darmadi" 
> To: "pw forum" 
> Sent: Wednesday, January 23, 2013 12:50:35 AM
> Subject: [Pw_forum] Fail to predict semiconductor
> 
> 
> 
> 
> 
> 
> 
> Dear all,
> 
> 
> 
> I have calculated electronic structure of Ti doped ZnO in both GGA and
> GGA+U scheme. Both scheme predicts Ti doped ZnO is metallic. In contrary,
> Ti doped ZnO is well known as semiconductor experimentally. At first
> glance, I thought it was local minimum problem of DFT+U (like FeO problem
> in Mr. Himmetoglu's tutorial). Then I try to copy Mr. Himmetoglu's trick
> to override a "suspected" fully occupied orbitals of Ti. Sadly, nothing
> change, it's still a metallic.
> 
> 
> 
> Now, I am confused whethe

[Pw_forum] Fail to predict semiconductor

[Alexey Akimov]

Dear Iwan,

The pure DFT is known to underestimate the band gaps, eventually making 
semiconductor material to appear as a metal in your calculations. This problem 
arises because of the double-counting in exchange terms. The problem solved 
with the hybrid functionals, such as PBE0. The GGA approximation and even +U 
correction terms provide only small improvement over LDA. So this may not be 
enough to make your system to be semiconductor (computationally). To 
summarize,the problem is inherently with the DFT methododology.

Good luck,
Alexey

- Original Message -
From: "Iwan Darmadi" 
To: "pw forum" 
Sent: Wednesday, January 23, 2013 12:50:35 AM
Subject: [Pw_forum] Fail to predict semiconductor







Dear all, 



I have calculated electronic structure of Ti doped ZnO in both GGA and GGA+U 
scheme. Both scheme predicts Ti doped ZnO is metallic. In contrary, Ti doped 
ZnO is well known as semiconductor experimentally. At first glance, I thought 
it was local minimum problem of DFT+U (like FeO problem in Mr. Himmetoglu's 
tutorial). Then I try to copy Mr. Himmetoglu's trick to override a "suspected" 
fully occupied orbitals of Ti. Sadly, nothing change, it's still a metallic. 



Now, I am confused whether this is a really local minimum problem or intrinsic 
limitation of DFT it self. 



Do anyone here have suggestions so I can get semiconductor Ti doped ZnO in the 
calculation ? 



Ps. 

I have also attached my input and output file. 

*** 

Iwan Darmadi 
Undergrad.Student - Department of Physics 

Universitas Indonesia 

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

-- 
Dr. Alexey V. Akimov

Postdoctoral Research Associate
Department of Chemistry
University of Rochester

aakimov at z.rochester.edu 

[Pw_forum] visualization of the orbitals produced with the hybrid functional

[Alexey Akimov]

Dear Layla and Giuseppe,

Thank you for your great comments and explanations. That clarifies the thing. 

Alexey

- Original Message -
From: "Layla Martin-Samos" <lmartinsa...@gmail.com>
To: "PWSCF Forum" 
Sent: Wednesday, November 7, 2012 3:19:54 AM
Subject: Re: [Pw_forum] visualization of the orbitals produced with the hybrid 
functional


Dear Alexey, even in the case of Hartree-fock and occupied states is difficult 
to notice with the eyes a big difference. Indeed, nature is mainly mean-field 
and the biggest differences between standard DFT and hybrid DFT schemes are in 
the tail of the wave functions. 


cheers 


Layla 


2012/11/7 Giuseppe Mattioli < giuseppe.mattioli at ism.cnr.it > 



Dear Alexey 

I've plotted many HOMO and LUMO orbitals of small and large molecules by using 
the HSE or the B3LYP 
functional. They are often very similar to their PBE or BLYP counterparts. This 
is not accountable 
for an incorrect behaviour of the pp.x code. It is only the fact that, apart 
from some particular 
cases like those involving atomic-like d orbitals of transition metals 
contained in a C-N-O-H 
molecular environment, the pure DFT density is not so different from the hybrid 
density. After all, 
when you perform a B3LYP calculation you are only substituting about 20% of 
BLYP exchange with 
Hartree-Fock exact exchange... Not a great difference ;-) 

HTH 

Giuseppe 



On Tuesday 06 November 2012 18:54:00 Alexey Akimov wrote: 
> Dear all, 
> 
> I calculated the charge density for some KS orbitals(lets say HOMO and 
> LUMO) - using the pp.x program and the converged scf reslts for PBE and 
> PBE0 functionals. The orbital energies obtained with the PBE0 give much 
> better estimate for the band gap than those obtained with the PBE, what is 
> expected. However I also expected to see some (substantial or at least 
> minor) difference of the orbitals (the spatial localization of the 
> corresponding charge densities), produced by PBE vs. PBE0 functionals. Yet 
> when visualizing they look quite the same. So is this a problem of the 
> pp.x (which probably only accounts for the part of the density produced 
> with the "pure" part of the PBE0 functional), is this something more 
> fundamental what leads to similar orbital-projected charge densities of 
> the pure and hybrid functionals or is this something I missing in the 
> input files? I copy my input for pp.x below. 
> 
>  
> prefix = 'x' 
> outdir = './' 
> filplot = 'tmp.dat' 
> plot_num= 7 
> kpoint=1 
> kband=222 
> / 
> 
>  
> nfile = 1 
> filepp(1) = 'tmp.dat' 
> weight(1) = 1.0 
> iflag = 3 
> output_format = 6 
> fileout = 'x-KS_222.cube' 
> / 
> 
> 
> 
> Thank you, 
> Alexey 

-- 
 
- Article premier - Les hommes naissent et demeurent 
libres et ?gaux en droits. Les distinctions sociales 
ne peuvent ?tre fond?es que sur l'utilit? commune 
- Article 2 - Le but de toute association politique 
est la conservation des droits naturels et 
imprescriptibles de l'homme. Ces droits sont la libert?, 
la propri?t?, la s?ret? et la r?sistance ? l'oppression. 
 

Giuseppe Mattioli 
CNR - ISTITUTO DI STRUTTURA DELLA MATERIA 
v. Salaria Km 29,300 - C.P. 10 
I 00015 - Monterotondo Stazione (RM) 
Tel + 39 06 90672836 - Fax +39 06 90672316 
E-mail: < giuseppe.mattioli at ism.cnr.it > 



___ 
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

-- 
Dr. Alexey V. Akimov

Postdoctoral Research Associate
Department of Chemistry
University of Rochester

aakimov at z.rochester.edu 

[Pw_forum] visualization of the orbitals produced with the hybrid functional

[Alexey Akimov]

Dear all,

I calculated the charge density for some KS orbitals(lets say HOMO and LUMO) - 
using the pp.x program and the converged scf reslts for PBE and PBE0 
functionals. The orbital energies obtained with the PBE0 give much better 
estimate for the band gap than those obtained with the PBE, what is expected. 
However I also expected to see some (substantial or at least minor) difference 
of the orbitals (the spatial localization of the corresponding charge 
densities), produced by PBE vs. PBE0 functionals. Yet when visualizing they 
look quite the same. So is this a problem of the pp.x (which probably only 
accounts for the part of the density produced with the "pure" part of the PBE0 
functional), is this something more fundamental what leads to similar 
orbital-projected charge densities of the pure and hybrid functionals or is 
this something I missing in the input files? I copy my input for pp.x below.

 
prefix  = 'x'
outdir = './'
filplot = 'tmp.dat'
plot_num= 7
kpoint=1
kband=222
 /

 
nfile = 1
filepp(1) = 'tmp.dat'
weight(1) = 1.0
iflag = 3
output_format = 6
fileout = 'x-KS_222.cube'
 /



Thank you,
Alexey






-- 
Dr. Alexey V. Akimov

Postdoctoral Research Associate
Department of Chemistry
University of Rochester

aakimov at z.rochester.edu 

[Pw_forum] How to get optimized celldm parameters?

[Alexey Akimov]

p.s. haven't seen this reply

- Original Message -
From: "Stefano de Gironcoli" 
To: "PWSCF Forum" 
Sent: Saturday, October 13, 2012 2:03:22 AM
Subject: Re: [Pw_forum] How to get optimized celldm parameters?

use ibrav=0 and specify the v1,v2,v3 in the CELL_PARAMETER card
stefano

On 10/13/2012 05:29 PM, Yura Vishnevskiy wrote:
> Hi all,
> I have a general question. Let's suppose I've done cell optimization and
> would like to restart calculation using optimized celldm parameters.
> What is the simplest way to extract them from pw.x log file? In case of
> a triclinic (ibrav=14) cell it does not look simple to convert printed
> in output components of v1, v2 and v3 to celldm parameters.
>
> Sincerely,
> Yura V. Vishnevskiy
> ___
> 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

-- 
Dr. Alexey V. Akimov

Postdoctoral Research Associate
Department of Chemistry
University of Rochester

aakimov at z.rochester.edu 

[Pw_forum] How to get optimized celldm parameters?

[Alexey Akimov]

Dear Yura,

I always use ibrav = 0 in combination with the CELL_PARAMETERS card. When you 
doing a variable-cell optimization, the CELL_PARAMETERS is always printed as 
well as atomic coordinates at each optimization iteration. So you can copy 
these data to you new input file with ibrav = 0 (although the first round of 
optimization could be done with your current input file with ibrav=14)

Good luck,
Alexey

- Original Message -
From: "Yura Vishnevskiy" 
To: "pw forum" 
Sent: Saturday, October 13, 2012 8:29:40 AM
Subject: [Pw_forum] How to get optimized celldm parameters?

Hi all,
I have a general question. Let's suppose I've done cell optimization and 
would like to restart calculation using optimized celldm parameters. 
What is the simplest way to extract them from pw.x log file? In case of 
a triclinic (ibrav=14) cell it does not look simple to convert printed 
in output components of v1, v2 and v3 to celldm parameters.

Sincerely,
Yura V. Vishnevskiy
___
Pw_forum mailing list
Pw_forum at pwscf.org
http://pwscf.org/mailman/listinfo/pw_forum

-- 
Dr. Alexey V. Akimov

Postdoctoral Research Associate
Department of Chemistry
University of Rochester

aakimov at z.rochester.edu 

[Pw_forum] Error in routine scale_h (1)

[Alexey Akimov]

Good point, thank you! 

Alexey

- Original Message -
From: "Axel Kohlmeyer" <akohl...@gmail.com>
To: "PWSCF Forum" 
Sent: Monday, September 24, 2012 2:32:28 AM
Subject: Re: [Pw_forum] Error in routine scale_h (1)

And I venture an educated guess here, but looks toMe that you could save 
yourself a lot of time and effort with a small number of well picked single 
point calculations and thus obtained a much better initialnguess. For your 
system it should be easy enough to pick a cell that is a bit too large and a 
bit too small and a few in between. 

Variable cell calculation far from equilibrium always converge very slow. 

Axel
--
Dr. Axel Kohlmeyer  akohlmey at gmail.com  http://goo.gl/1wk0
International Centre for Theoretical Physics, Trieste. Italy.

-Original Message-
From: Alexey Akimov <aaki...@z.rochester.edu>
Sender: pw_forum-bounces at pwscf.org
Date: Sun, 23 Sep 2012 22:14:14 
To: PWSCF Forum
Reply-To: PWSCF Forum 
Subject: Re: [Pw_forum] Error in routine scale_h (1)

I see. Thank you for the explanation!

Alexey

- Original Message -
From: "Stefano de Gironcoli" <degir...@sissa.it>
To: "pw forum" 
Sent: Sunday, September 23, 2012 2:58:47 PM
Subject: Re: [Pw_forum] Error in routine scale_h (1)

as your cell shrinks the energy cutoff corresponding to your set of 
plane wave increases and it this exceeds a the maximum values in the 
precalculated psedopotential table (some 20% higher than the specified 
ecut by default if i remember correctly) the code stops. You can 
increase this limit with the cell_factor variable.

However if this keeps happening it means that your cell  was way too large !

stefano



On 09/23/2012 11:42 PM, Alexey Akimov wrote:
> my unit cell is not oscillating, but rather shrinking. shouldn't the basis 
> size (number of plane waves) be bigger for larger cell, so the bigger cell 
> would determine the maximal amount of memory for simulation even if the cell 
> contracts?
>
> - Original Message -
> From: "Paolo Giannozzi" 
> To: "PWSCF Forum" 
> Sent: Sunday, September 23, 2012 1:19:05 PM
> Subject: Re: [Pw_forum] Error in routine scale_h (1)
>
>
> On Sep 23, 2012, at 16:43 , Alexey Akimov wrote:
>
>> If i restart the calculations with the latest (most optimal)
>> configuration of the system and the same amount of memory
>> allocated, the further optimization can proceed some more time
>> (also ~50 - 70 steps) before next crash.
> this should not happen, unless your optimization procedure keeps
> oscillating between large and
> small volumes.
>
> 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

-- 
Dr. Alexey V. Akimov

Postdoctoral Research Associate
Department of Chemistry
University of Rochester

aakimov at z.rochester.edu 
___
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

-- 
Dr. Alexey V. Akimov

Postdoctoral Research Associate
Department of Chemistry
University of Rochester

aakimov at z.rochester.edu 

[Pw_forum] Error in routine scale_h (1)

[Alexey Akimov]

I see. Thank you for the explanation!

Alexey

- Original Message -
From: "Stefano de Gironcoli" <degir...@sissa.it>
To: "pw forum" 
Sent: Sunday, September 23, 2012 2:58:47 PM
Subject: Re: [Pw_forum] Error in routine scale_h (1)

as your cell shrinks the energy cutoff corresponding to your set of 
plane wave increases and it this exceeds a the maximum values in the 
precalculated psedopotential table (some 20% higher than the specified 
ecut by default if i remember correctly) the code stops. You can 
increase this limit with the cell_factor variable.

However if this keeps happening it means that your cell  was way too large !

stefano



On 09/23/2012 11:42 PM, Alexey Akimov wrote:
> my unit cell is not oscillating, but rather shrinking. shouldn't the basis 
> size (number of plane waves) be bigger for larger cell, so the bigger cell 
> would determine the maximal amount of memory for simulation even if the cell 
> contracts?
>
> - Original Message -
> From: "Paolo Giannozzi" 
> To: "PWSCF Forum" 
> Sent: Sunday, September 23, 2012 1:19:05 PM
> Subject: Re: [Pw_forum] Error in routine scale_h (1)
>
>
> On Sep 23, 2012, at 16:43 , Alexey Akimov wrote:
>
>> If i restart the calculations with the latest (most optimal)
>> configuration of the system and the same amount of memory
>> allocated, the further optimization can proceed some more time
>> (also ~50 - 70 steps) before next crash.
> this should not happen, unless your optimization procedure keeps
> oscillating between large and
> small volumes.
>
> 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

-- 
Dr. Alexey V. Akimov

Postdoctoral Research Associate
Department of Chemistry
University of Rochester

aakimov at z.rochester.edu 

[Pw_forum] Error in routine scale_h (1)

[Alexey Akimov]

Ok. I'll try this option, thank you for suggestion. In conjunction to this 
feature, will the memory required for calculation increase with increased 
cell_factor? how fast?

- Original Message -
From: "Martin Andersson" <m...@nano.ku.dk>
To: "PWSCF Forum" 
Sent: Sunday, September 23, 2012 12:33:15 PM
Subject: Re: [Pw_forum] Error in routine scale_h (1)

Set cell_factor (in ) to a number higher than the default like 
suggested... That should work.

Cheers,
Martin Andersson
University of Copenhagen


Den 2012-09-23 4:43 PM, Alexey Akimov skrev:
> Dear all,
>
> I'm trying to optimize a relatively large system such as 2 C60 / unit cell. 
> So i start with relatively large cell dimensions. I'm doing vc-relax 
> calculations with either 'damp'&'damp-pr' or 'bfgs'&'bfgs' for ionic and cell 
> dynamics options. However, after some number (~50-70) of successful  
> (ionic/cell) steps the calculations crash with the error:
>
>   Error in routine scale_h (1):
>   Not enough space allocated for radial FFT: try restarting with a larger 
> cell_factor.
>
> It seems like this happens when the size of the simulation cell changes by 
> some notable amount with respect to the starting one. Perhaps, the program 
> automatically changes the plane wave basis set (increases). If i restart the 
> calculations with the latest (most optimal) configuration of the system and 
> the same amount of memory allocated, the further optimization can proceed 
> some more time (also ~50 - 70 steps) before next crash. So in principle it is 
> still possible to achieve the convergence with this sequence of operations, 
> but it is quite inconvenient to reset the calculations every 50-70 steps.
>
> So my question: is there any way to avoid this and get optimized results 
> without intermediate crashes (apart from increasing the amount of memory 
> reserved in the beginning)?
>
> Thank you,
> Alexey
>
>

___
Pw_forum mailing list
Pw_forum at pwscf.org
http://www.democritos.it/mailman/listinfo/pw_forum

-- 
Dr. Alexey V. Akimov

Postdoctoral Research Associate
Department of Chemistry
University of Rochester

aakimov at z.rochester.edu 

[Pw_forum] Error in routine scale_h (1)

[Alexey Akimov]

my unit cell is not oscillating, but rather shrinking. shouldn't the basis size 
(number of plane waves) be bigger for larger cell, so the bigger cell would 
determine the maximal amount of memory for simulation even if the cell 
contracts?

- Original Message -
From: "Paolo Giannozzi" <giann...@democritos.it>
To: "PWSCF Forum" 
Sent: Sunday, September 23, 2012 1:19:05 PM
Subject: Re: [Pw_forum] Error in routine scale_h (1)


On Sep 23, 2012, at 16:43 , Alexey Akimov wrote:

> If i restart the calculations with the latest (most optimal)  
> configuration of the system and the same amount of memory  
> allocated, the further optimization can proceed some more time  
> (also ~50 - 70 steps) before next crash.

this should not happen, unless your optimization procedure keeps  
oscillating between large and
small volumes.

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

-- 
Dr. Alexey V. Akimov

Postdoctoral Research Associate
Department of Chemistry
University of Rochester

aakimov at z.rochester.edu 

[Pw_forum] Error in routine scale_h (1)

[Alexey Akimov]

Dear all,

I'm trying to optimize a relatively large system such as 2 C60 / unit cell. So 
i start with relatively large cell dimensions. I'm doing vc-relax calculations 
with either 'damp'&'damp-pr' or 'bfgs'&'bfgs' for ionic and cell dynamics 
options. However, after some number (~50-70) of successful  (ionic/cell) steps 
the calculations crash with the error: 

 Error in routine scale_h (1):
 Not enough space allocated for radial FFT: try restarting with a larger 
cell_factor.

It seems like this happens when the size of the simulation cell changes by some 
notable amount with respect to the starting one. Perhaps, the program 
automatically changes the plane wave basis set (increases). If i restart the 
calculations with the latest (most optimal) configuration of the system and the 
same amount of memory allocated, the further optimization can proceed some more 
time (also ~50 - 70 steps) before next crash. So in principle it is still 
possible to achieve the convergence with this sequence of operations, but it is 
quite inconvenient to reset the calculations every 50-70 steps. 

So my question: is there any way to avoid this and get optimized results 
without intermediate crashes (apart from increasing the amount of memory 
reserved in the beginning)? 

Thank you,
Alexey


-- 
Dr. Alexey V. Akimov

Postdoctoral Research Associate
Department of Chemistry
University of Rochester

aakimov at z.rochester.edu 

[Pw_forum] kohn -sham orbitals ortogonality and ortonormality

[Alexey Akimov]

Dear Fariba,

I think pp.x outputs give you just another representation of the orbitals in 
terms of the charge density. The plane wave expansion coefficients given by 
pw_export.x is one way to think of the orbitals, the charge density (e.g. cube 
files) produced by pp.x - is another. The orbitals are still orthogonal to each 
other (this is by construction, you have checked this with the plane wave 
expansion). Such orthogonality is of course not rigorous, as i pointed out in 
earlier messages (psi vs. Spsi), but the deviation is not very big. It is hard 
to say more without knowing the final goal. Hopefully this can be helpful.

Best regards,
Alexey

- Original Message -
From: naz...@iasbs.ac.ir
To: "PWSCF Forum" 
Sent: Thursday, August 30, 2012 7:10:00 AM
Subject: Re: [Pw_forum] kohn -sham orbitals ortogonality and ortonormality


Dear Alexey, 

I understand that the input is for pw_export.x and run with it. 
I also need the kohn-Sham orbitals whichare produced by pp.x. but in 
ortogonalized form. is it possible? 
Regards 
Fariba Nazari 
IASBS 


> Dear Fariba, 
> 
> That is nice to know. Also i just found, that the example of the input i 
> sent in the previous letter is not for pp.x, but rather for 
> pw_export.x - that is for producing |psi> and S|psi>. For printing 
> orbitals you of course need pp.x. 
> Also i'm not sure what output files you mean - those with psi and Spsi 
> (pw_export.x) can be produced in either binary or text format - that is 
> it. If you imply orbitals (the charge density for given band) - i think 
> they may be written in cube format (output_format = 6, just look in 
> Doc/INPUT_PP.txt in you QE distribution for more details) 
> 
> Best regards, 
> Alexey 
> 
> 
> - Original Message - 
> 
From: naz...@iasbs.ac.ir 
> To: "PWSCF Forum"  
> Sent: Thursday, August 30, 2012 1:09:20 AM 
> Subject: Re: [Pw_forum] kohn -sham orbitals ortogonality and ortonormality 
> 
> 
> Dear Alexey 
> 
> Thank you . I have cheked your suggestion and it works. 
> One more question : IS it possible that the obtanied files have cube 
> format.? 
> 
> Best Regards 
> Fariba Nazari 
> IASBS 
> 
> 
> 
> 
>> Dear Fariba, 
>> 
>> I think you can get S|psi> without modifying the code. Here is an input 
>> for pp.x: 
>> 
>>  
>> prefix = 'x', 
>> outdir = './', 
>> pseudo_dir = 'path-to-your-PP-directory', 
>> psfile(1) = 'C.pbe-van_bm.UPF', 
>> psfile(2) = 'H.pbe-van_bm.UPF', 
>> single_file = .FALSE., 
>> ascii = .TRUE., 
>> uspp_spsi = .TRUE., <--- this produces S|psi> along with the |psi>, as 
>> long as i understand this should work at least for US-PPs 
>> / 
>> 
>> In addition, if you need localized orbitals, you might look in the 
>> direction of maximally localized wannier functions, ELF, or, if you want 
>> to plot MOs, you can use the pp.x to make .xsf files with the charge 
>> density corresponding to necessary KS orbitals. 
>> 
>> 
>> Best regards, 
>> Alexey 
>> 
>> 
>> - Original Message - 
>> 
> 
From: naz...@iasbs.ac.ir 
>> To: "PWSCF Forum"  
>> Sent: Tuesday, August 28, 2012 10:43:52 PM 
>> Subject: Re: [Pw_forum] kohn -sham orbitals ortogonality and 
>> ortonormality 
>> 
>> 
>> 
>> Dear Alexey 
>> 
>> Would you please let me know how the S|psi> is obtained with pp.x . I 
>> need 
>> orthonormal kohn-sham orbitals. 
>> Regards 
>> Fariba Nazari 
>> IASBS 
>> 
>> 
>> 
>> 
>>> Dear Fariba, 
>>> 
>>> The Kohn-Sham (please, not kohen) orbitals produced by pp.x are not 
>>> orthonormalized in general, because of the pseudo-potentials and 
>>> projection techniques (PAW). However, practically, you may safely 
>>> assume 
>>> they are orthogonal and almost normalized (self-overlaps are not far 
>>> from 
>>> 1.0). This is especially true for norm-conserving PP (by construction, 
>>> the 
>>> wavefunctions supposed to preserve norm), and, in slightly smaller 
>>> extent, 
>>> for ultra-soft pseudopotentials. For PAW wavefunctions the trick is to 
>>> reconstruct full wavefunction from the projection, so it is S|psi>. If 
>>> i 
>>> remember it correctly, the ortogonality will then be for 
>>>  
>>> = 
>>> delta_ij. However you can obtain S|psi> with pp.x as well as |psi>. 
>>> Please anyone correct me if i'm wrong at some point. 
>>> 
>>> Thank you, 
>>> Alexey 
>>> 
>>> - Original Message - 
>>> 
>> 
> 
From: naz...@iasbs.ac.ir 
>>> To: "PWSCF Forum"  
>>> Sent: Tuesday, August 28, 2012 6:23:31 AM 
>>> Subject: [Pw_forum] kohen -sham orbitals ortogonality and ortonormality 
>>> 
>>> 
>>> 
>>> 
>>> Dear All, 
>>> 
>>> Would you please let me know if the kohen -sham orbitals ,which are 
>>> obtained by pp.x, are normalized, orthogonalized or orthonormalized? 
>>> 
>>> Regards 
>>> Fariba Nazari 
>>> IASBS 
>>> -- 
>>> This message has been scanned for viruses and 
>>> dangerous content by MailScanner , and is 
>>> believed to be clean. 
>>> ___ 
>>> Pw_forum mailing list 
>>> Pw_forum at pwscf.org 
>>> 

[Pw_forum] kohn -sham orbitals ortogonality and ortonormality

[Alexey Akimov]

Dear Fariba,

That is nice to know. Also i just found, that the example of the input i sent 
in the previous letter is not for pp.x, but rather for
pw_export.x - that is for producing |psi> and S|psi>. For printing orbitals you 
of course need pp.x.
Also i'm not sure what output files you mean - those with psi and Spsi 
(pw_export.x) can be produced in either binary or text format - that is it. If 
you imply orbitals (the charge density for given band) - i think they may be 
written in cube format (output_format = 6, just look in Doc/INPUT_PP.txt in you 
QE distribution for more details)

Best regards,
Alexey


- Original Message -
From: naz...@iasbs.ac.ir
To: "PWSCF Forum" 
Sent: Thursday, August 30, 2012 1:09:20 AM
Subject: Re: [Pw_forum] kohn -sham orbitals ortogonality and ortonormality


Dear Alexey 

Thank you . I have cheked your suggestion and it works. 
One more question : IS it possible that the obtanied files have cube format.? 

Best Regards 
Fariba Nazari 
IASBS 




> Dear Fariba, 
> 
> I think you can get S|psi> without modifying the code. Here is an input 
> for pp.x: 
> 
>  
> prefix = 'x', 
> outdir = './', 
> pseudo_dir = 'path-to-your-PP-directory', 
> psfile(1) = 'C.pbe-van_bm.UPF', 
> psfile(2) = 'H.pbe-van_bm.UPF', 
> single_file = .FALSE., 
> ascii = .TRUE., 
> uspp_spsi = .TRUE., <--- this produces S|psi> along with the |psi>, as 
> long as i understand this should work at least for US-PPs 
> / 
> 
> In addition, if you need localized orbitals, you might look in the 
> direction of maximally localized wannier functions, ELF, or, if you want 
> to plot MOs, you can use the pp.x to make .xsf files with the charge 
> density corresponding to necessary KS orbitals. 
> 
> 
> Best regards, 
> Alexey 
> 
> 
> - Original Message - 
> 
From: naz...@iasbs.ac.ir 
> To: "PWSCF Forum"  
> Sent: Tuesday, August 28, 2012 10:43:52 PM 
> Subject: Re: [Pw_forum] kohn -sham orbitals ortogonality and ortonormality 
> 
> 
> 
> Dear Alexey 
> 
> Would you please let me know how the S|psi> is obtained with pp.x . I need 
> orthonormal kohn-sham orbitals. 
> Regards 
> Fariba Nazari 
> IASBS 
> 
> 
> 
> 
>> Dear Fariba, 
>> 
>> The Kohn-Sham (please, not kohen) orbitals produced by pp.x are not 
>> orthonormalized in general, because of the pseudo-potentials and 
>> projection techniques (PAW). However, practically, you may safely assume 
>> they are orthogonal and almost normalized (self-overlaps are not far 
>> from 
>> 1.0). This is especially true for norm-conserving PP (by construction, 
>> the 
>> wavefunctions supposed to preserve norm), and, in slightly smaller 
>> extent, 
>> for ultra-soft pseudopotentials. For PAW wavefunctions the trick is to 
>> reconstruct full wavefunction from the projection, so it is S|psi>. If i 
>> remember it correctly, the ortogonality will then be for  
>> = 
>> delta_ij. However you can obtain S|psi> with pp.x as well as |psi>. 
>> Please anyone correct me if i'm wrong at some point. 
>> 
>> Thank you, 
>> Alexey 
>> 
>> - Original Message - 
>> 
> 
From: naz...@iasbs.ac.ir 
>> To: "PWSCF Forum"  
>> Sent: Tuesday, August 28, 2012 6:23:31 AM 
>> Subject: [Pw_forum] kohen -sham orbitals ortogonality and ortonormality 
>> 
>> 
>> 
>> 
>> Dear All, 
>> 
>> Would you please let me know if the kohen -sham orbitals ,which are 
>> obtained by pp.x, are normalized, orthogonalized or orthonormalized? 
>> 
>> Regards 
>> Fariba Nazari 
>> IASBS 
>> -- 
>> This message has been scanned for viruses and 
>> dangerous content by MailScanner , and is 
>> believed to be clean. 
>> ___ 
>> Pw_forum mailing list 
>> Pw_forum at pwscf.org 
>> http://www.democritos.it/mailman/listinfo/pw_forum 
>> 
>> -- 
>> Dr. Alexey V. Akimov 
>> 
>> Postdoctoral Research Associate 
>> Department of Chemistry 
>> University of Rochester 
>> 
>> aakimov at z.rochester.edu 
>> ___ 
>> Pw_forum mailing list 
>> Pw_forum at pwscf.org 
>> http://www.democritos.it/mailman/listinfo/pw_forum 
>> 
>> -- 
>> This message has been scanned for viruses and 
>> dangerous content by MailScanner, and is 
>> believed to be clean. 
>> 
>> 
> 
> -- 
> This message has been scanned for viruses and 
> dangerous content by MailScanner , and is 
> believed to be clean. 
> ___ 
> Pw_forum mailing list 
> Pw_forum at pwscf.org 
> http://www.democritos.it/mailman/listinfo/pw_forum 
> 
> -- 
> Dr. Alexey V. Akimov 
> 
> Postdoctoral Research Associate 
> Department of Chemistry 
> University of Rochester 
> 
> aakimov at z.rochester.edu 
> ___ 
> Pw_forum mailing list 
> Pw_forum at pwscf.org 
> http://www.democritos.it/mailman/listinfo/pw_forum 
> 
> -- 
> This message has been scanned for viruses and 
> dangerous content by MailScanner, and is 
> believed to be clean. 
> 
> 

-- 
This message has been scanned 

[Pw_forum] kohn -sham orbitals ortogonality and ortonormality

[Alexey Akimov]

Dear Fariba,

I think you can get S|psi> without modifying the code. Here is an input for 
pp.x:


  prefix = 'x',
  outdir = './',
  pseudo_dir = 'path-to-your-PP-directory',
  psfile(1) = 'C.pbe-van_bm.UPF',  
  psfile(2) = 'H.pbe-van_bm.UPF',
  single_file = .FALSE.,
  ascii = .TRUE.,
  uspp_spsi = .TRUE.,  <--- this produces S|psi> along with the |psi>, as long 
as i understand this should work at least for US-PPs
/

In addition, if you need localized orbitals, you might look in the direction of 
maximally localized wannier functions, ELF, or, if you want to plot MOs, you 
can use the pp.x to make .xsf files with the charge density corresponding to 
necessary KS orbitals. 


Best regards,
Alexey


- Original Message -
From: naz...@iasbs.ac.ir
To: "PWSCF Forum" 
Sent: Tuesday, August 28, 2012 10:43:52 PM
Subject: Re: [Pw_forum] kohn -sham orbitals ortogonality and ortonormality



Dear Alexey 

Would you please let me know how the S|psi> is obtained with pp.x . I need 
orthonormal kohn-sham orbitals. 
Regards 
Fariba Nazari 
IASBS 




> Dear Fariba, 
> 
> The Kohn-Sham (please, not kohen) orbitals produced by pp.x are not 
> orthonormalized in general, because of the pseudo-potentials and 
> projection techniques (PAW). However, practically, you may safely assume 
> they are orthogonal and almost normalized (self-overlaps are not far from 
> 1.0). This is especially true for norm-conserving PP (by construction, the 
> wavefunctions supposed to preserve norm), and, in slightly smaller extent, 
> for ultra-soft pseudopotentials. For PAW wavefunctions the trick is to 
> reconstruct full wavefunction from the projection, so it is S|psi>. If i 
> remember it correctly, the ortogonality will then be for  = 
> delta_ij. However you can obtain S|psi> with pp.x as well as |psi>. 
> Please anyone correct me if i'm wrong at some point. 
> 
> Thank you, 
> Alexey 
> 
> - Original Message - 
> 
From: naz...@iasbs.ac.ir 
> To: "PWSCF Forum"  
> Sent: Tuesday, August 28, 2012 6:23:31 AM 
> Subject: [Pw_forum] kohen -sham orbitals ortogonality and ortonormality 
> 
> 
> 
> 
> Dear All, 
> 
> Would you please let me know if the kohen -sham orbitals ,which are 
> obtained by pp.x, are normalized, orthogonalized or orthonormalized? 
> 
> Regards 
> Fariba Nazari 
> IASBS 
> -- 
> This message has been scanned for viruses and 
> dangerous content by MailScanner , and is 
> believed to be clean. 
> ___ 
> Pw_forum mailing list 
> Pw_forum at pwscf.org 
> http://www.democritos.it/mailman/listinfo/pw_forum 
> 
> -- 
> Dr. Alexey V. Akimov 
> 
> Postdoctoral Research Associate 
> Department of Chemistry 
> University of Rochester 
> 
> aakimov at z.rochester.edu 
> ___ 
> Pw_forum mailing list 
> Pw_forum at pwscf.org 
> http://www.democritos.it/mailman/listinfo/pw_forum 
> 
> -- 
> This message has been scanned for viruses and 
> dangerous content by MailScanner, and is 
> believed to be clean. 
> 
> 

-- 
This message has been scanned for viruses and 
dangerous content by MailScanner , and is 
believed to be clean. 
___
Pw_forum mailing list
Pw_forum at pwscf.org
http://www.democritos.it/mailman/listinfo/pw_forum

-- 
Dr. Alexey V. Akimov

Postdoctoral Research Associate
Department of Chemistry
University of Rochester

aakimov at z.rochester.edu 

[Pw_forum] kohen -sham orbitals ortogonality and ortonormality

[Alexey Akimov]

Dear Fariba,

The Kohn-Sham (please, not kohen) orbitals produced by pp.x are not 
orthonormalized in general, because of the pseudo-potentials and projection 
techniques (PAW). However, practically,  you may safely assume they are 
orthogonal and almost normalized (self-overlaps are not far from 1.0). This is 
especially true for norm-conserving PP (by construction, the wavefunctions 
supposed to preserve norm), and, in slightly smaller extent, for ultra-soft 
pseudopotentials. For PAW wavefunctions the trick is to reconstruct full 
wavefunction from the projection, so it is S|psi>. If i remember it correctly, 
the ortogonality will then be for  = delta_ij. However you can 
obtain S|psi> with pp.x as well as |psi>. 
Please anyone correct me if i'm wrong at some point.

Thank you,
Alexey

- Original Message -
From: naz...@iasbs.ac.ir
To: "PWSCF Forum" 
Sent: Tuesday, August 28, 2012 6:23:31 AM
Subject: [Pw_forum] kohen -sham orbitals ortogonality and ortonormality




Dear All, 

Would you please let me know if the kohen -sham orbitals ,which are obtained by 
pp.x, are normalized, orthogonalized or orthonormalized? 

Regards 
Fariba Nazari 
IASBS 
-- 
This message has been scanned for viruses and 
dangerous content by MailScanner , and is 
believed to be clean. 
___
Pw_forum mailing list
Pw_forum at pwscf.org
http://www.democritos.it/mailman/listinfo/pw_forum

-- 
Dr. Alexey V. Akimov

Postdoctoral Research Associate
Department of Chemistry
University of Rochester

aakimov at z.rochester.edu 

[Pw_forum] question about spinors

[Alexey Akimov]

Dear Gabriele,

Thank you for additional clarifications.

Best,
Alexey 

- Original Message -
From: "Gabriele Sclauzero" <gabriele.sclauz...@epfl.ch>
To: "PWSCF Forum" 
Sent: Monday, August 27, 2012 1:04:17 AM
Subject: Re: [Pw_forum] question about spinors


Hello, 



Il giorno 25/ago/2012, alle ore 04.06, Alexey Akimov ha scritto: 


Dear Gabriele, 

Thank you for your great comments! So as i understand the key for orbital 
overlap is additional summation over spin components. 


Just to be a bit more pedantic... I would not call them as that, but rather 
"spinor components", to avoid confusion. In general, when magnetization is non 
collinear you cannot identify the first component with "spin-up" and the second 
with "spin-down", unless the magnetization is collinear and oriented along z. 

>>> ok. thank you for pointing this out

This makes a lot sense to what i see - the odd-even alteration of 1 or 0 
overlaps. In other words Psi_1 = psi_1,1 , Psi_2 = psi_1,2, ... Psi_2n+1 = 
psi_n,1, Psi_2n+2 = psi_n,2 and then <Psi_1|Psi_1> = <psi_1,1|psi_1,1> = 1, 
<Psi_2|Psi_2> = <psi_1,2|psi_1,2> = 0 (alteration), but <Psi_1|Psi_1> + 
<Psi_2|Psi_2> = <psi_1,1|psi_1,1> + <psi_1,2|psi_1,2> = 1, ... (no alteration). 


I've got a bit lost here with your notation, but it seems that you got the 
point. I think you meant "alternation" here, am I correct? 

>>> right, alternation


That is the orbitals written in the output are actually not 1, 2, 3, ... etc, 
but rather 1,1, 1,2, 2,1, 2,2, ... etc. (here the second index is the 
spin-state or more precisely the spinor component). 

>>> i see. this is the point from the previous sentence. 


I don't know of which output you are talking about here (pp.x?). Anyway, I 
think that the wave function coefficients for the first and the second 
component are stored consecutively in the same array (as said by Paolo in the 
first reply). 

>>> yes, i meant the output produced by pp.x. So, as you say the orbitals are 
>>> written as 1,1, 1,2, 2,1, 2,2, ... etc. Do you mean the first band (and 
>>> hence its planewave expansion) is 1,1 ("spin-up"), the second band (and its 
>>> coefficients in output) is 1,2, etc. ? 


Also if i understand it correctly we should not consider spin-up and spin-down 
functions separately. Is this right? 


I'm not sure I understand this point correctly, maybe it is related to what 
I've written above? 

>>> yes, you already answered this in the first part.


I would appreciate if someone could give some reference (apart from wikipedia 
and QE tutorials/presentations) for the spinor algebra. 



I do not have any references at hand, but I'm pretty sure that if you look up 
at "Pauli equation" in any good quantum mechanics book (maybe advanced ones) 
you'll find what you need. Indeed, the fully-relativistic non collinear KS 
equation is pretty similar to that one. 


Ok. I see the point with the npwx vs. npw. However i was using a single k-point 
(gamma), so one would expect that this should not introduce additional 
complications. You also mentioned that the parallelization can effect this - 
would storing the entire wavefunction in one file solve such issue (wf_collect 
= .true.) instead of storing it in different files - one per process? 



It should, but I'm not sure... you can make a small test. 




GS 




Thank you, 
Alexey 

- Original Message - 
From: "Gabriele Sclauzero" < gabriele.sclauz...@epfl.ch > 
To: "PWSCF Forum" < pw_forum at pwscf.org > 
Sent: Friday, August 24, 2012 3:57:54 AM 
Subject: Re: [Pw_forum] question about spinors 







Dear Paolo, 

I'm not sure that i completely understand what you mean by empty coefficients. 
Also what is npwx, how is it different from npw? 


I think this is due to the fact that wave functions at different k-points can 
have different number of plane waves if the basis set cut-off is expressed in 
terms of the kinetic energy of the plane wave ~ |k+G|^2. Still, it's more 
practical to use the same array (of size npwx>npw) for storing the wave 
function (one k-point at a time). Also G-vector parallelization might introduce 
this kind of issue. 




Also am i correct that the spin-up and spin-down orbitals are orthogonal not 
because of the artificial convention <alpha|beta> = 0, but rather by 
construction of the corresponding plane wave expansions (given by coefficients 
c_gi )? 


I would not call this is an artificial convention... it's the way you write the 
wavefunction (space+spin components) that allows you to do this, which is turn 
depends on the Hamiltonian that you consider. 
Anyway I think this is correct, although you should be aware that when you take 
the norm of a two-component spinor you need to sum over the two components, 
i

[Pw_forum] question about spinors

[Alexey Akimov]

Dear Gabriele,

Thank you for your great comments! So as i understand the key for orbital 
overlap is additional summation over spin components. This makes a lot sense to 
what i see - the odd-even alteration of 1 or 0 overlaps. In other words Psi_1 = 
psi_1,1 , Psi_2 = psi_1,2, ... Psi_2n+1 = psi_n,1, Psi_2n+2 = psi_n,2 and then 
<Psi_1|Psi_1> = <psi_1,1|psi_1,1> = 1, <Psi_2|Psi_2> = <psi_1,2|psi_1,2> = 0 
(alteration), but <Psi_1|Psi_1> + <Psi_2|Psi_2> = <psi_1,1|psi_1,1> + 
<psi_1,2|psi_1,2> = 1, ... (no alteration). That is the orbitals written in the 
output are actually not 1, 2, 3, ... etc, but rather 1,1,  1,2,  2,1,  2,2, ... 
etc. (here the second index is the spin-state or more precisely the spinor 
component). Also if i understand it correctly we should not consider spin-up 
and spin-down functions separately. Is this right? I would appreciate if 
someone could give some reference (apart from wikipedia and QE 
tutorials/presentations) for the spinor algebra.  

Ok. I see the point with the npwx vs. npw. However i was using a single k-point 
(gamma), so one would expect that this should not introduce additional 
complications. You also mentioned that the parallelization can effect this - 
would storing the entire wavefunction in one file solve such issue (wf_collect 
= .true.) instead of storing it in different files - one per process?


Thank you,
Alexey

- Original Message -
From: "Gabriele Sclauzero" <gabriele.sclauz...@epfl.ch>
To: "PWSCF Forum" 
Sent: Friday, August 24, 2012 3:57:54 AM
Subject: Re: [Pw_forum] question about spinors







Dear Paolo, 

I'm not sure that i completely understand what you mean by empty coefficients. 
Also what is npwx, how is it different from npw? 


I think this is due to the fact that wave functions at different k-points can 
have different number of plane waves if the basis set cut-off is expressed in 
terms of the kinetic energy of the plane wave ~ |k+G|^2. Still, it's more 
practical to use the same array (of size npwx>npw) for storing the wave 
function (one k-point at a time). Also G-vector parallelization might introduce 
this kind of issue. 




Also am i correct that the spin-up and spin-down orbitals are orthogonal not 
because of the artificial convention <alpha|beta> = 0, but rather by 
construction of the corresponding plane wave expansions (given by coefficients 
c_gi )? 


I would not call this is an artificial convention... it's the way you write the 
wavefunction (space+spin components) that allows you to do this, which is turn 
depends on the Hamiltonian that you consider. 
Anyway I think this is correct, although you should be aware that when you take 
the norm of a two-component spinor you need to sum over the two components, 
i.e. 
< Psi_i | Psi_j > = < Psi_i,1 | Psi_j,1 > + < Psi_i,2 | Psi_j,2 >, where 1 and 
2 denote first and second component, resp. 




or the orthogonality is already included in "spatial" part (so <phi_i|phi_j> = 
0 for alpha and beta spin-orbitals)? 



Not really in the 3D spatial part, but rather in the "relations" between the 
first and second component. I mean, the overlap between first components and 
that between the second components can both be nonzero, but the sum might be 
zero. This is the most general case, when you have spin-orbit and/or 
non-collinear magnetization. If the ground state has collinear magnetization 
you can always rotate the magnetic axis such that each wave function has Psi_1 
or Psi_2 which is zero everywhere (and you get the same result, which should be 
the same as in LSDA). 


HTH 




GS 





Thank you, 
Alexey 


- Original Message - 
From: "Paolo Giannozzi" < giann...@democritos.it > 
To: "PWSCF Forum" < pw_forum at pwscf.org > 
Sent: Wednesday, August 22, 2012 8:27:59 AM 
Subject: Re: [Pw_forum] question about spinors 


On Aug 21, 2012, at 23:55 , Alexey Akimov wrote: 



I try to understand the format of the wavefunction in case of spin- 


polarization 


(nspin=4, spinorb=.true. (or something similar)) 

KS orbitals for the spin-orbit case have coefficient on a basis of 
NPW plane 
waves with spin up, NPW plane waves with spin down. The dimension of the 
orbitals is 2*NPWX >= 2*NPW, so there can be empty coefficients in the 
middle. 

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 

-- 
Dr. Alexey V. Akimov 

Postdoctoral Research Associate 
Department of Chemistry 
University of Rochester 

aakimov at z.rochester.edu 
___ 
Pw_forum mailing list 

[Pw_forum] How I can simulate charged slab with surface charge by QE

[Alexey Akimov]

i would also suggest not to forget about spin-polarization, that is if you 
simulated neutral system with nspin = 1 (no spin-polarization), in the case of 
+1 or -1 charge you will have one electron less or more so now should not 
forget to turn on the spin polarization nspin=2, starting_magnetization(1) = 
0.7 (for example) and choose the smearing options.


- Original Message -
From: "Paolo Giannozzi" 
To: "PWSCF Forum" 
Sent: Friday, August 24, 2012 3:12:48 AM
Subject: Re: [Pw_forum] How I can simulate charged slab with surface charge 
by QE


On Aug 22, 2012, at 16:06 , yavar pour azar wrote:

> I think  if we introduce excess charges by "tot_charge" utility in  
> slab ,
> after scf they should be localize on the surface, as the "surface  
> charge"
>   is this true?

maybe, Or maybe not: all you can do is to add charge to the system,
but you cannot force the charge to go where you like it to go

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

-- 
Dr. Alexey V. Akimov

Postdoctoral Research Associate
Department of Chemistry
University of Rochester

aakimov at z.rochester.edu 

[Pw_forum] question about spinors

[Alexey Akimov]

Dear Paolo,

I'm not sure that i completely understand what you mean by empty coefficients. 
Also what is npwx, how is it different from npw? Let say npw = 3 and npwx = 4 
(very small basis :)) then the overlap of orbital i and orbital j will be:
c_i0^* * c_j0 + c_i1^* * c_j1 + c_i2^* * c_j2 + c_i3^* * c_j3 (four terms as 
npwx). If, as you say, some coefficients are empty (lets say c_i3 and c_j3) we 
still have some non-zero terms. I'm not sure if the previous sentence have any 
sense at all, so sorry if this is something terribly wrong :) - that is why i'm 
asking. 
(^* - means complex conjugate)

Also am i correct that the spin-up and spin-down orbitals are orthogonal not 
because of the artificial convention <alpha|beta> = 0, but rather by 
construction of the corresponding plane wave expansions (given by coefficients 
c_gi )? What i mean is that in localized orbitals e.g. Gaussians the spatial 
parts of the alpha and beta orbitals are practically the same (exactly in 
restricted HF or KS approaches), but the orthogonality is then introduced by 
convention: psi_i_alpa = phi_i * sigma_alpha, psi_j_beta = phi_j * sigma_beta 
=> <psi_i_alpha|psi_j_beta> = <phi_i|phi_j> * <sigma_alpha|sigma_beta>, so even 
if <phi_i|phi_j> != 0 the orbitals are still orthogonal because 
<sigma_alpha|sigma_beta> = 0 by convention. So in spin-orbital case do we still 
need to consider these artificial sigma_alpha, sigma_beta spin-functions or the 
orthogonality is already included in "spatial" part (so <phi_i|phi_j> = 0 for 
alpha and beta spin-orbitals)?

Thank you,
Alexey


- Original Message -
From: "Paolo Giannozzi" <giann...@democritos.it>
To: "PWSCF Forum" 
Sent: Wednesday, August 22, 2012 8:27:59 AM
Subject: Re: [Pw_forum] question about spinors


On Aug 21, 2012, at 23:55 , Alexey Akimov wrote:

> I try to understand the format of the wavefunction in case of spin- 
> polarization
> (nspin=4, spinorb=.true. (or something similar))

KS orbitals  for the spin-orbit case have coefficient on a basis of  
NPW plane
waves with spin up, NPW plane waves with spin down. The dimension of the
orbitals is 2*NPWX >= 2*NPW, so there can be empty coefficients in the
middle.

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

-- 
Dr. Alexey V. Akimov

Postdoctoral Research Associate
Department of Chemistry
University of Rochester

aakimov at z.rochester.edu 

[Pw_forum] question about spinors

[Alexey Akimov]

Dear all,

I try to understand the format of the wavefunction in case of spin-polarization 
(nspin=4, spinorb=.true. (or something similar)) without digging into code 
(what may take some longer time). First of all I print the wavefunction in the 
ascii format (text) using the post-processing utilities, that is the 
coefficients c_ig in expansion: psi_i = sum_over_g {c_ig * exp(u*g*r)}  
(assuming Gamma-point case, so k=0). So when i compute overlap of 2 orbitals 
 it is delta_ij (Kronecker) (almost) for non-spin polarized case 
or with spin-polarized case but without spin-orbit. However, in spin-orbit case 
i have something like:  = 1,  = 0,  = 1, 
etc. Also the eigenvalues of the even orbitals look the same as those of odd 
orbitals (e.g. e_1 = e2, e3 = e4, etc.) 

So my question is what are the even wavefunctions, why their overlap is not 1, 
but is 0 while for odd orbitals the normal expectation of overlap being close 
to 1 is satisfied? More specifically, what is the interpretation of the output 
wavefunctions (bands) in such calculations? I tried to look tutorial and 
presentations about spin-orbit coupling calculations in QE. They say about 
spinors, but what is what in the output and how the (ortho)normalization is 
expressed in term of the outputs? 


Thank you,
Alexey



-- 
Dr. Alexey V. Akimov

Postdoctoral Research Associate
Department of Chemistry
University of Rochester

aakimov at z.rochester.edu 

[Pw_forum] MD restart algorithm in Quantum Espresso

[Alexey Akimov]

Dear Axel,

Thanks you for clarifying the issues. So if i understand your point correctly, 
the divergence is because of the roundup errors (floating point operation) and 
not because of the algorithmistic problems - that is good to know. Yes, i see 
you point about the statistical meaning of the md trajectories - so as long as 
the divergence is not an artefact of the integration scheme (e.g. because of 
the lack of time-reversibility or symplecticity) that should not be a problem 
then for my purposes.   

Also thank you for clarifying the meaning of the extra step - so it is one 
extra step in the beginning (perhaps to restart the algorithm), not at the end 
of the restarted trajectory as i initially though. I think storing the current 
(and perhaps previous) forces along with the other information needed for 
restart would help to solve this problem and avoid doing this extra step at 
restart. W


Thank you,
Alexey

- Original Message -
From: "Axel Kohlmeyer" <akohl...@gmail.com>
To: "PWSCF Forum" 
Sent: Saturday, August 18, 2012 10:10:51 PM
Subject: Re: [Pw_forum] MD restart algorithm in Quantum Espresso

On Sun, Aug 19, 2012 at 12:09 AM, Alexey Akimov  
wrote:
> Dear Paolo,
>
> Thank you for your kind reply (I already though that nobody will ever answer 
> this :) ).
> 1) about first part - yes, i meant BOMD calculations. So are you saying that 
> the difference arises because of the convergence criteria for the  electronic 
> problem at restart and during continuous MD run are different? In that case 
> will setting the threshold for this problem to very small value help to 
> prevent such divergence (perhaps for the cost of extra iterations)? Also I 
> tried used the potential and wavefunction interpolation during MD simulation 
> (i hope to accelerate calculations) in MD simulations. Do you think this can 
> interfere with the MD restart algorithm?



convergence criteria are the same , but only the wavefunction, not the
potential is saved, since the latter can be constructed from the
former. the issue is a principal one. there will *always* be
differences and the trajectories will diverge (usually exponentialls),
since you are using floating point math, which is not like real math.
floating point math does not commute, i.e. the result depends on the
order of operations and floating point math does not have infinite
accuracy.

this is already a problem in classical MD, but in BOMD it is worse,
since one typically does not save the forces to a restart, but
recomputes them, which explains the additional SCF step at the
beginning of a run.

add to this the fact that MD is a chaotic process (coupled
differential equation), the divergence is inevitable unless you use
fixed point math and only use NVE dynamics (no thermostat). tightening
the convergence will reduce the divergence initially, but since it is
an exponential process, it is a useless enterprise.

when using extrapolation, divergence will be larger, since the amount
of history will determine your initial guess and there will some
little "memory" of the initial guess (which is why extrapolation is a
good thing, as it improves energy conservation and allows using a less
tight convergence). but the not fully deterministic nature of
restarting an MD is really not a problem, since the trajectory after
the restart is statistically mechanically equivalent to the one from
the uninterrupted run. for *proper* analysis you would actually need
both and the huge number of other equivalent runs to average over and
have a good sample of the ensemble.

> 2) about nstep - do you suggest to look into code?  i just though this might 
> have some faster explanation without digging into code. I think it might be 
> good if someone could make it in accord with the naive expectation that nstep 
> = 1 will make only one MD step, not 2. I suspect that the code performs 1 
> extra step at the end of simulation. In case of long trajectory e.g. 
> nstep=100 this will not make a difference, but if i want to do the sequence : 
> 1 MD step - (do something) - restart and do one more step - etc..., then 1 
> extra MD step at each calculation will double the computational expenses. So 
> is it possible to change such behavior e.g. in next versions?

no. restarting is a bad idea in this case as you'd double the number
of SCF calculations.
you better integrate your "do something" into the QE-code.

axel.

>
> Thank you,
> Alexey
>
> - Original Message -
> From: "Paolo Giannozzi" 
> To: "PWSCF Forum" 
> Sent: Friday, August 17, 2012 1:25:40 PM
> Subject: Re: [Pw_forum] MD restart algorithm in Quantum Espresso
>
> About the first point: are you referring to MD on the ground state
> ("Born-Oppenheimer" MD), done with PWscf (not Car-Parrinello)?
> I think that the restart does the c

[Pw_forum] MD restart algorithm in Quantum Espresso

[Alexey Akimov]

Dear Paolo,

Thank you for your kind reply (I already though that nobody will ever answer 
this :) ). 
1) about first part - yes, i meant BOMD calculations. So are you saying that 
the difference arises because of the convergence criteria for the  electronic 
problem at restart and during continuous MD run are different? In that case 
will setting the threshold for this problem to very small value help to prevent 
such divergence (perhaps for the cost of extra iterations)? Also I tried used 
the potential and wavefunction interpolation during MD simulation (i hope to 
accelerate calculations) in MD simulations. Do you think this can interfere 
with the MD restart algorithm?
2) about nstep - do you suggest to look into code?  i just though this might 
have some faster explanation without digging into code. I think it might be 
good if someone could make it in accord with the naive expectation that nstep = 
1 will make only one MD step, not 2. I suspect that the code performs 1 extra 
step at the end of simulation. In case of long trajectory e.g. nstep=100 this 
will not make a difference, but if i want to do the sequence : 1 MD step - (do 
something) - restart and do one more step - etc..., then 1 extra MD step at 
each calculation will double the computational expenses. So is it possible to 
change such behavior e.g. in next versions?

Thank you,
Alexey

- Original Message -
From: "Paolo Giannozzi" <giann...@democritos.it>
To: "PWSCF Forum" 
Sent: Friday, August 17, 2012 1:25:40 PM
Subject: Re: [Pw_forum] MD restart algorithm in Quantum Espresso

About the first point: are you referring to MD on the ground state
("Born-Oppenheimer" MD), done with PWscf (not Car-Parrinello)?
I think that the restart does the correct thing, i.e. use the Verlet
algorithm as if the run was not interrupted, but there might be
some subtle differences in how the threshold for convergence is
calculated, that are more than sufficient to have the two MD
simulations diverge.

About the difference between nstep and the number of steps actually
performed: it shouldn't be difficult to follow variable "nstep" and  
see why
this happen

P.
On Aug 1, 2012, at 24:51 , Alexey Akimov wrote:

> I tried to perform md simulations in Quantum Espresso in 2  
> different ways:
> 1) simply run a single continuous trajectory (e.g. 10 steps)
> 2) run first step of MD as a new calculation (restart_mode =  
> from_scratch, default)
>   and run all other (remaining 9) steps as restarts (restart_mode =  
> restart), doing this for every step
>
> As a result after a few steps the total energies, atomic forces and  
> position started to deviate between two approaches.
>
> I suspect that some information from the previous step may be  
> dropped during the restart (e.g. by using the first-order Euler  
> scheme instead of the Verlet algorithm), eventually leading to such  
> divergence. So my question is: what is restart algorithm for MD in  
> quantum espresso and is there any possibility to use method 2 (see  
> above) without accumulation of the integration errors?
>
> Also can someone clarify why if i specify nstep = 1 in my input  
> file (request to perform a single MD step), the program actually  
> makes 2 MD steps?
>
>
> Thank you,
> Alexey
>
>
>
>
> -- 
> Dr. Alexey V. Akimov
>
> Postdoctoral Research Associate
> Department of Chemistry
> University of Rochester
>
> aakimov at z.rochester.edu
> ___
> Pw_forum mailing list
> Pw_forum at pwscf.org
> http://www.democritos.it/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://www.democritos.it/mailman/listinfo/pw_forum

-- 
Dr. Alexey V. Akimov

Postdoctoral Research Associate
Department of Chemistry
University of Rochester

aakimov at z.rochester.edu 

[Pw_forum] zns/zno surface

[Alexey Akimov]

Dear Amin,
Sure it is better to saturate both surfaces - that is why i suggested to put 
the hydrogens on the dangling bond on each surface. In my understanding it is 
not realistic to have some unsaturated (dangling) bonds, especially on the 
surface (which is exposed lets say to the air). The bulk surface (in your case 
bottom) is not exposed to reactive components, so it maybe ok from the chemical 
point of view not to saturate them. However, from the computational point of 
view, that may(and will) lead to different charge density. To cure this you can 
put hydrogens on all unsaturated surface atoms.  

Best regards,
Alexey  


- Original Message -
From: "Amin Torabi" <mtor...@uwo.ca>
To: "PWSCF Forum" 
Sent: Monday, August 13, 2012 7:27:35 AM
Subject: Re: [Pw_forum] zns/zno surface



Dear Alexey, 
How could a calculation without saturation be fine? My understanding is that an 
unsaturated bottom layer will produce a spurious dipole moment which can be 
large, and can interact with the corresponding dipole moment in other unit 
cells. 





On Sat, Aug 11, 2012 at 1:12 PM, Alexey Akimov < aakimov at z.rochester.edu > 
wrote: 


Dear Amin, 

If you want to saturate bottom (and maybe even top) sulfur/oxygen atoms I would 
try to put hydrogens on them. This way you can localize electron density on the 
sulfur/oxigen atoms and avoid dangling bonds. In reality you of course will not 
see unsaturated O/S atoms on the surface - they will be protonated anyway or 
carry some other groups on them. However it may be fine to do calculations even 
without such saturation (especially for the bottom layer). 





- Original Message - 
From: "Amin Torabi" < mtor...@uwo.ca > 
To: "PWSCF Forum" < pw_forum at pwscf.org > 
Sent: Friday, August 10, 2012 9:22:55 AM 
Subject: [Pw_forum] zns/zno surface 




Dear PWSCF experts, 


I am willing to find out how doping of oxygen in a surface of ZnS (wurtzite) 
changes its band structure. I have a slab model composed of 8 layers of ZnS, in 
which 2 sulfur atoms are replace with oxygen, and a 15 Angstrom vacuum on top 
of the surface. I am relaxing only the first two layers. 
Now, my question is the sulfur or oxygen atoms on the top level resembles the 
surface that I am interested in; however, the sulfur (or zinc) atoms at the 
bottom are artifact of the model. How should I saturate them? 


Can you please take a look on my input file and let me know if you have any 
suggestion? Thanks 



 
calculation = 'relax' 
prefix = 'orig' 
pseudo_dir = '/home/p/' 
outdir = './tmp' 
tstress = .true 
tprnfor = .true 
/ 
 
ibrav = 12 
A = 11.3772 
B = 11.3772 
C = 40.0 
cosAB = -0.5 
nat = 153 
ntyp = 3 
ecutwfc = 30 
ecutrho = 300 
occupations = 'smearing' 
degauss = 0.01 
smearing = 'gauss' 
/ 
 
mixing_mode = 'local-TF' 
mixing_beta = 0.3 
/ 
 
/ 
ATOMIC_SPECIES 
Zn 65.409 Zn.pbe-van.UPF 
S 32.066 S.pbe-van_bm.UPF 
O 15.9994 O.pbe-van_ak.UPF 
ATOMIC_POSITIONS angstrom 
Zn 1.896209796 1.094779514 3.1132225450 0 0 0 
S 0.02678 2.189555203 2.3306235650 0 0 0 
S 1.896209090 1.094779922 5.4413927710 0 0 0 
Zn 0.01973 2.189555611 6.2239919760 0 0 0 
Zn 1.896209796 1.094779514 9.3347611820 0 0 0 
S 0.02678 2.189555203 8.5521622020 0 0 0 
S 1.896209090 1.094779922 11.662931408 0 0 0 
Zn 0.01973 2.189555611 12.445530613 0 0 0 
Zn 1.896209796 1.094779514 15.556299819 0 0 0 
S 0.02678 2.189555203 14.773700839 0 0 0 
S 1.896209090 1.094779922 17.884470045 0 0 0 
Zn 0.01973 2.189555611 18.667069250 0 0 0 
Zn 1.896209796 1.094779514 21.777838456 
S 0.02678 2.189555203 20.995239476 
S 1.896209090 1.094779922 24.106008682 
Zn 0.01973 2.189555611 24.888607887 
S 0.02678 2.189555203 27.216778113 
Zn 0.05649 4.379109319 3.1132225450 0 0 0 
S -1.896201469 5.473885008 2.3306235650 0 0 0 
S 0.04943 4.379109727 5.4413927710 0 0 0 
Zn -1.896202174 5.473885416 6.2239919760 0 0 0 
Zn 0.05649 4.379109319 9.3347611820 0 0 0 
S -1.896201469 5.473885008 8.5521622020 0 0 0 
S 0.04943 4.379109727 11.662931408 0 0 0 
Zn -1.896202174 5.473885416 12.445530613 0 0 0 
Zn 0.05649 4.379109319 15.556299819 0 0 0 
S -1.896201469 5.473885008 14.773700839 0 0 0 
S 0.04943 4.379109727 17.884470045 0 0 0 
Zn -1.896202174 5.473885416 18.667069250 0 0 0 
Zn 0.05649 4.379109319 21.777838456 
S -1.896201469 5.473885008 20.995239476 
S 0.04943 4.379109727 24.106008682 
Zn -1.896202174 5.473885416 24.888607887 
S -1.896201469 5.473885008 27.216778113 
Zn -1.896198498 7.663439124 3.1132225450 0 0 0 
S -3.792405616 8.758214813 2.3306235650 0 0 0 
S -1.896199204 7.663439532 5.4413927710 0 0 0 
Zn -3.792406321 8.758215221 6.2239919760 0 0 0 
Zn -1.896198498 7.663439124 9.3347611820 0 0 0 
S -3.792405616 8.758214813 8.5521622020 0 0 0 
S -1.896199204 7.663439532 11.662931408 0 0 0 
Zn -3.792406321 8.758215221 12.445530613 0 0 0 
Zn -1.896198498 7.663439124 15.556299819 0 0 0 
S -3.7924

[Pw_forum] zns/zno surface

[Alexey Akimov]

Dear Amin,

If you want to saturate bottom (and maybe even top) sulfur/oxygen atoms I would 
try to put hydrogens on them. This way you can localize electron density on the 
sulfur/oxigen atoms and avoid dangling bonds. In reality you of course will not 
see unsaturated O/S atoms on the surface - they will be protonated anyway or 
carry some other groups on them. However it may be fine to do calculations even 
without such saturation (especially for the bottom layer).

  

- Original Message -
From: "Amin Torabi" 
To: "PWSCF Forum" 
Sent: Friday, August 10, 2012 9:22:55 AM
Subject: [Pw_forum] zns/zno surface




Dear PWSCF experts, 


I am willing to find out how doping of oxygen in a surface of ZnS (wurtzite) 
changes its band structure. I have a slab model composed of 8 layers of ZnS, in 
which 2 sulfur atoms are replace with oxygen, and a 15 Angstrom vacuum on top 
of the surface. I am relaxing only the first two layers. 
Now, my question is the sulfur or oxygen atoms on the top level resembles the 
surface that I am interested in; however, the sulfur (or zinc) atoms at the 
bottom are artifact of the model. How should I saturate them? 


Can you please take a look on my input file and let me know if you have any 
suggestion? Thanks 



 
calculation = 'relax' 
prefix = 'orig' 
pseudo_dir = '/home/p/' 
outdir = './tmp' 
tstress = .true 
tprnfor = .true 
/ 
 
ibrav = 12 
A = 11.3772 
B = 11.3772 
C = 40.0 
cosAB = -0.5 
nat = 153 
ntyp = 3 
ecutwfc = 30 
ecutrho = 300 
occupations = 'smearing' 
degauss = 0.01 
smearing = 'gauss' 
/ 
 
mixing_mode = 'local-TF' 
mixing_beta = 0.3 
/ 
 
/ 
ATOMIC_SPECIES 
Zn 65.409 Zn.pbe-van.UPF 
S 32.066 S.pbe-van_bm.UPF 
O 15.9994 O.pbe-van_ak.UPF 
ATOMIC_POSITIONS angstrom 
Zn 1.896209796 1.094779514 3.1132225450 0 0 0 
S 0.02678 2.189555203 2.3306235650 0 0 0 
S 1.896209090 1.094779922 5.4413927710 0 0 0 
Zn 0.01973 2.189555611 6.2239919760 0 0 0 
Zn 1.896209796 1.094779514 9.3347611820 0 0 0 
S 0.02678 2.189555203 8.5521622020 0 0 0 
S 1.896209090 1.094779922 11.662931408 0 0 0 
Zn 0.01973 2.189555611 12.445530613 0 0 0 
Zn 1.896209796 1.094779514 15.556299819 0 0 0 
S 0.02678 2.189555203 14.773700839 0 0 0 
S 1.896209090 1.094779922 17.884470045 0 0 0 
Zn 0.01973 2.189555611 18.667069250 0 0 0 
Zn 1.896209796 1.094779514 21.777838456 
S 0.02678 2.189555203 20.995239476 
S 1.896209090 1.094779922 24.106008682 
Zn 0.01973 2.189555611 24.888607887 
S 0.02678 2.189555203 27.216778113 
Zn 0.05649 4.379109319 3.1132225450 0 0 0 
S -1.896201469 5.473885008 2.3306235650 0 0 0 
S 0.04943 4.379109727 5.4413927710 0 0 0 
Zn -1.896202174 5.473885416 6.2239919760 0 0 0 
Zn 0.05649 4.379109319 9.3347611820 0 0 0 
S -1.896201469 5.473885008 8.5521622020 0 0 0 
S 0.04943 4.379109727 11.662931408 0 0 0 
Zn -1.896202174 5.473885416 12.445530613 0 0 0 
Zn 0.05649 4.379109319 15.556299819 0 0 0 
S -1.896201469 5.473885008 14.773700839 0 0 0 
S 0.04943 4.379109727 17.884470045 0 0 0 
Zn -1.896202174 5.473885416 18.667069250 0 0 0 
Zn 0.05649 4.379109319 21.777838456 
S -1.896201469 5.473885008 20.995239476 
S 0.04943 4.379109727 24.106008682 
Zn -1.896202174 5.473885416 24.888607887 
S -1.896201469 5.473885008 27.216778113 
Zn -1.896198498 7.663439124 3.1132225450 0 0 0 
S -3.792405616 8.758214813 2.3306235650 0 0 0 
S -1.896199204 7.663439532 5.4413927710 0 0 0 
Zn -3.792406321 8.758215221 6.2239919760 0 0 0 
Zn -1.896198498 7.663439124 9.3347611820 0 0 0 
S -3.792405616 8.758214813 8.5521622020 0 0 0 
S -1.896199204 7.663439532 11.662931408 0 0 0 
Zn -3.792406321 8.758215221 12.445530613 0 0 0 
Zn -1.896198498 7.663439124 15.556299819 0 0 0 
S -3.792405616 8.758214813 14.773700839 0 0 0 
S -1.896199204 7.663439532 17.884470045 0 0 0 
Zn -3.792406321 8.758215221 18.667069250 0 0 0 
Zn -1.896198498 7.663439124 21.777838456 
S -3.792405616 8.758214813 20.995239476 
S -1.896199204 7.663439532 24.106008682 
Zn -3.792406321 8.758215221 24.888607887 
S -3.792405616 8.758214813 27.216778113 
Zn 5.688625711 1.094783325 3.1132225450 0 0 0 
S 3.792418593 2.189559014 2.3306235650 0 0 0 
S 5.688625005 1.094783733 5.4413927710 0 0 0 
Zn 3.792417888 2.189559422 6.2239919760 0 0 0 
Zn 5.688625711 1.094783325 9.3347611820 0 0 0 
S 3.792418593 2.189559014 8.5521622020 0 0 0 
S 5.688625005 1.094783733 11.662931408 0 0 0 
Zn 3.792417888 2.189559422 12.445530613 0 0 0 
Zn 5.688625711 1.094783325 15.556299819 0 0 0 
S 3.792418593 2.189559014 14.773700839 0 0 0 
S 5.688625005 1.094783733 17.884470045 0 0 0 
Zn 3.792417888 2.189559422 18.667069250 0 0 0 
Zn 5.688625711 1.094783325 21.777838456 
S 3.792418593 2.189559014 20.995239476 
S 5.688625005 1.094783733 24.106008682 
Zn 3.792417888 2.189559422 24.888607887 
S 3.792418593 2.189559014 27.216778113 
Zn 3.792421564 4.379113130 3.1132225450 0 0 0 
S 1.896214446 5.47319 2.3306235650 0 0 0 
S 3.792420858 4.379113538 5.4413927710 0 0 0 
Zn 1.896213741 5.473889227 

[Pw_forum] MD restart algorithm in Quantum Espresso

[Alexey Akimov]

Dear all,

I tried to perform md simulations in Quantum Espresso in 2 different ways:
1) simply run a single continuous trajectory (e.g. 10 steps)
2) run first step of MD as a new calculation (restart_mode = from_scratch, 
default)
  and run all other (remaining 9) steps as restarts (restart_mode = restart), 
doing this for every step

As a result after a few steps the total energies, atomic forces and position 
started to deviate between two approaches.

I suspect that some information from the previous step may be dropped during 
the restart (e.g. by using the first-order Euler scheme instead of the Verlet 
algorithm), eventually leading to such divergence. So my question is: what is 
restart algorithm for MD in quantum espresso and is there any possibility to 
use method 2 (see above) without accumulation of the integration errors? 

Also can someone clarify why if i specify nstep = 1 in my input file (request 
to perform a single MD step), the program actually makes 2 MD steps?


Thank you,
Alexey




-- 
Dr. Alexey V. Akimov

Postdoctoral Research Associate
Department of Chemistry
University of Rochester

aakimov at z.rochester.edu 

[Pw_forum] convergence problem for charged simulation cell

[Alexey Akimov]

Dear all,

I'm trying to calculate md of a system with the positive charge (+1) of the 
simulation cell. However it seems like a hard task,
because even the first step is not converging (electronic iteration). I used 
setup to allow up to 100 electronic iterations, but
this is not enough to achieve the convergence. I also tried to decrease the 
mixing parameter to 0.4, as was suggested in some of the
previous posts. I tried to increase charge density cutoff to 10*ecutwfc.

Also the program warns me that:
 (first iteration)
 WARNING: integrated charge=  2046.6000, expected=  2047.

 (10-th iteration)
 WARNING: integrated charge=  2046.01617514, expected=  2047.

I do not know why program expects the charge corresponding to neutral system, 
while i ask for the positively charged one (tot_charge = 1.0)
I'm using version PWSCF v.4.3.2  with 4 processors. By the way, for neutral 
system the convergence does not give any problem.

Is there any ideas how to achieve the convergence for the charged simulation 
cell? Also i'm curious about those warning messages - can they be disregarded 
or it is me, who is missing something? May it be some bug of PWScf?

Thank you,
Alexey

-- 
Dr. Alexey V. Akimov

Postdoctoral Research Associate
Department of Chemistry
University of Rochester

aakimov at z.rochester.edu