From jgche at fudan.edu.cn  Sat Apr  1 05:10:49 2006
From: jgche at fudan.edu.cn (J G Che)
Date: Sat, 01 Apr 2006 11:10:49 +0800
Subject: [Pw_forum] about output wavefunction, charge density and potential
Message-ID: <000a01c65539$e046a1e0$83182d0a@jgche>

Dear All:

I find that in each iterative, wavefunction, potential and charge density will be saved on disk. Who knows how to output these once only when the self-consistent is reached. Thanks!

JG
-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/attachments/20060401/4b6b26a8/attachment.htm 

From lyw1983 at 163.com  Mon Apr  3 03:22:51 2006
From: lyw1983 at 163.com (lyw1983)
Date: Mon, 3 Apr 2006 09:22:51 +0800 (CST)
Subject: [Pw_forum] a warning occured when calculating the Ra
 man of the SnO.
Message-ID: <443078EB.000009.04974@bj163app72.163.com>

Dear all:
   when I calculate the Raman property of SnO using version3.0, a warning occured in the output file as below:
   "End of self-consistent calculation<br><br>     Convergence has been achieved<br>     warning: symmetry operation #  3 not allowed.   fractional translation:<br>       0.5000000 -0.5000000  0.0000000  in crystal coordinates<br>     warning: symmetry operation #  4 not allowed.   fractional translation:<br>       0.5000000  0.5000000  0.0000000  in crystal coordinates<br>     warning: symmetry operation #  7 not allowed.   fractional translation:<br>       0.5000000  0.5000000  0.0000000  in crystal coordinates<br>     warning: symmetry operation #  8 not allowed.   fractional translation:<br>       0.5000000 -0.5000000  0.0000000  in crystal coordinates<br>     warning: symmetry operation #  9 not allowed.   fractional translation:<br>       0.5000000  0.5000000  0.0000000  in crystal coordinates<br>     warning: symmetry operation # 10 not allowed.   fractional translation:<br>       0.5000000 -0.5000000  0.0000000  in crystal coordinates<br>     warning: symmetry operation # 13 not allowed.   fractional translation:<br>       0.5000000  0.5000000  0.0000000  in crystal coordinates<br>     warning: symmetry operation # 14 not allowed.   fractional translation:<br>       0.5000000 -0.5000000  0.0000000  in crystal coordinates"
There are results in output file, but I don't know if these warnings affect the results,and I don't know what cause these warnings. My input file as below:
  
 "&control<br>    calculation = 'scf'<br>    restart_mode='from_scratch',<br>    prefix='SnO',<br>    tstress = .true.<br>    tprnfor = .true.<br>    pseudo_dir = '/home/user56/pwwork/pseudo/',<br>    outdir='/pwscftmp/lyw/tmp/tmp1/'<br> /<br> &system<br>    ibrav=  6, celldm(1) =7.2662,celldm(3) =1.2784, nat=  4, ntyp= 2,<br>    ecutwfc =80,<br> /<br> &electrons<br>      mixing_beta = 0.7<br>    conv_thr =  1.0d-8<br> /<br>ATOMIC_SPECIES<br> Sn  118.69  Sn.cpi.UPF<br> O   15.999  O.cpi.UPF<br>ATOMIC_POSITIONS {crystal}<br> Sn 0.5 0.0 0.2345447<br> Sn 0.0 0.5 0.7654553<br> O  0.0 0.0 0.000<br> O  0.5 0.5 0.000<br>K_POINTS {automatic}phonons of SnO at Gamma<br>8 8 6 0 0 0<br> &inputph<br> tr2_ph=1.0d-15,<br>  prefix='SnO',<br>  epsil=.true.,<br>  amass(1)=118.69,<br>  amass(2)=15.999,<br>  trans=.true.,<br>  lraman=.true.,<br>  elop=.true.<br>  recover=.true.<br>  outdir='/pwscftmp/lyw/tmp/tmp1/',<br>  fildyn='SnO.dynG',<br> /<br>0.0 0.0 0.0"
Please help me! Thanks very much!

-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/attachments/20060403/e5c02820/attachment.htm 

From baroni at sissa.it  Mon Apr  3 08:21:19 2006
From: baroni at sissa.it (Stefano Baroni)
Date: Mon, 3 Apr 2006 08:21:19 +0200
Subject: [Pw_forum] a warning occured when calculating the Ra man of the SnO.
In-Reply-To: <443078EB.000009.04974@bj163app72.163.com>
References: <443078EB.000009.04974@bj163app72.163.com>
Message-ID: <090BD662-EA65-4E3E-B554-DCDBE1E145C6@sissa.it>

This issue has been discussed zillions of times in this forum and is  
well documented in the users' guide available on line.
Please, take a few minutes to take a glance at:

http://www.pwscf.org/guide/3.0/html-single/ 
manual.html#SECTION00090000000000000000

I would like to suggest that it is always a good idea to browse the  
(far from perfect) users's guide, before posting to the NG

Hope this helps - SB

On Apr 3, 2006, at 3:22 AM, lyw1983 wrote:

> Dear all:
>    when I calculate the Raman property of SnO using version3.0, a  
> warning occured in the output file as below:
>    "End of self-consistent calculation
>
>      Convergence has been achieved
>      warning: symmetry operation #  3 not allowed.   fractional  
> translation:
>        0.5000000 -0.5000000  0.0000000  in crystal coordinates
>      warning: symmetry operation #  4 not allowed.   fractional  
> translation:
>        0.5000000  0.5000000  0.0000000  in crystal coordinates
>      warning: symmetry operation #  7 not allowed.   fractional  
> translation:
>        0.5000000  0.5000000  0.0000000  in crystal coordinates
>      warning: symmetry operation #  8 not allowed.   fractional  
> translation:
>        0.5000000 -0.5000000  0.0000000  in crystal coordinates
>      warning: symmetry operation #  9 not allowed.   fractional  
> translation:
>        0.5000000  0.5000000  0.0000000  in crystal coordinates
>      warning: symmetry operation # 10 not allowed.   fractional  
> translation:
>        0.5000000 -0.5000000  0.0000000  in crystal coordinates
>      warning: symmetry operation # 13 not allowed.   fractional  
> translation:
>        0.5000000  0.5000000  0.0000000  in crystal coordinates
>      warning: symmetry operation # 14 not allowed.   fractional  
> translation:
>        0.5000000 -0.5000000  0.0000000  in crystal coordinates"
> There are results in output file, but I don't know if these  
> warnings affect the results,and I don't know what cause these  
> warnings. My input file as below:
>
>  "&control
>     calculation = 'scf'
>     restart_mode='from_scratch',
>     prefix='SnO',
>     tstress = .true.
>     tprnfor = .true.
>     pseudo_dir = '/home/user56/pwwork/pseudo/',
>     outdir='/pwscftmp/lyw/tmp/tmp1/'
>  /
>  &system
>     ibrav=  6, celldm(1) =7.2662,celldm(3) =1.2784, nat=  4, ntyp= 2,
>     ecutwfc =80,
>  /
>  &electrons
>       mixing_beta = 0.7
>     conv_thr =  1.0d-8
>  /
> ATOMIC_SPECIES
>  Sn  118.69  Sn.cpi.UPF
>  O   15.999  O.cpi.UPF
> ATOMIC_POSITIONS {crystal}
>  Sn 0.5 0.0 0.2345447
>  Sn 0.0 0.5 0.7654553
>  O  0.0 0.0 0.000
>  O  0.5 0.5 0.000
> K_POINTS {automatic}phonons of SnO at Gamma
> 8 8 6 0 0 0
>  &inputph
>  tr2_ph=1.0d-15,
>   prefix='SnO',
>   epsil=.true.,
>   amass(1)=118.69,
>   amass(2)=15.999,
>   trans=.true.,
>   lraman=.true.,
>   elop=.true.
>   recover=.true.
>   outdir='/pwscftmp/lyw/tmp/tmp1/',
>   fildyn='SnO.dynG',
>  /
> 0.0 0.0 0.0"
> Please help me! Thanks very much!
>
>
>
>
>
>
>
>
> ? ? ? 2006 ? ? ? ? ? ? ? ? ? ? ?
> ? ? 1.1 ? ? ? ? ? ? ? ? 2000 ? ? ? ?  
> ? ? ? ? ? ? 280 ? ? ? ? ?

---
Stefano Baroni - SISSA  &  DEMOCRITOS National Simulation Center -  
Trieste
[+39] 040 3787 406 (tel) -528 (fax) / stefanobaroni (skype)

Please, if possible, don't  send me MS Word or PowerPoint attachments
Why? See:  http://www.gnu.org/philosophy/no-word-attachments.html



-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/attachments/20060403/01796cd7/attachment.htm 

From sir_puding at tut.by  Mon Apr  3 14:38:31 2006
From: sir_puding at tut.by (sir_puding at tut.by)
Date: Mon, 3 Apr 2006 15:38:31 +0300
Subject: [Pw_forum] on pbe-rrkjus potentials
Message-ID: <1297286303.20060403153831@tut.by>

Hi, All.

Can anyone tell me how many k-points i should use with
pbe-rrkjus pseudopotentials (downloaded from pwscf.org) to get
reliable results for GS.
I looked into PDF which comes with potential for carbon -- it was
tested for 4x4x4 k-mesh on diamond. Does it means that such k-points division
would be sufficient to calculate "polluted" diamond, say, with nitrogen
substitute.

Sergey

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



From degironc at sissa.it  Mon Apr  3 14:53:39 2006
From: degironc at sissa.it (degironc)
Date: Mon, 03 Apr 2006 14:53:39 +0200
Subject: [Pw_forum] on pbe-rrkjus potentials
In-Reply-To: <1297286303.20060403153831@tut.by>
References: <1297286303.20060403153831@tut.by>
Message-ID: <44311AD3.1090308@sissa.it>

BZ sampling is strongly dependent on the band-structure of the system 
and not directly related to the pseudopotential used.
An insulator usually requires a modest number of k-points while metals 
instead require dense grids.
stefano

sir_puding at tut.by wrote:

>Hi, All.
>
>Can anyone tell me how many k-points i should use with
>pbe-rrkjus pseudopotentials (downloaded from pwscf.org) to get
>reliable results for GS.
>I looked into PDF which comes with potential for carbon -- it was
>tested for 4x4x4 k-mesh on diamond. Does it means that such k-points division
>would be sufficient to calculate "polluted" diamond, say, with nitrogen
>substitute.
>
>Sergey
>
>--
>Please avoid sending me Word or PowerPoint attachments.
>See http://www.gnu.org/philosophy/no-word-attachments.html
>
>_______________________________________________
>Pw_forum mailing list
>Pw_forum at pwscf.org
>http://www.democritos.it/mailman/listinfo/pw_forum
>  
>




From hsd22 at hermes.cam.ac.uk  Mon Apr  3 15:06:40 2006
From: hsd22 at hermes.cam.ac.uk (H.S.Domingos)
Date: Mon, 3 Apr 2006 14:06:40 +0100 (BST)
Subject: [Pw_forum] PBE usoft Mg ?
Message-ID: <Pine.LNX.4.64.0604031400440.28950@hermes-2.csi.cam.ac.uk>

Dear All,

I would like to ask if anyone has used a PBE usoft potential for Magnesium 
with PWSCF ?

I have tried to find one and could not. Are there any impediments in 
the generation of a potential of this type for Mg ?

Best regards,

Helder


=======================================================================
|  Dr. Helder S. Domingos                                             |
|                                                                     |
| INESC Microsyst & Nanotechnol, Lisbon, P-1000 Portugal              |
| and                                                                 |
| R&D unit for  Molecular Chemical Physics                            |
| Chemistry Department, University of Coimbra                         |
=======================================================================



From giannozz at nest.sns.it  Mon Apr  3 15:26:08 2006
From: giannozz at nest.sns.it (Paolo Giannozzi)
Date: Mon, 3 Apr 2006 15:26:08 +0200
Subject: [Pw_forum] PBE usoft Mg ?
In-Reply-To: <Pine.LNX.4.64.0604031400440.28950@hermes-2.csi.cam.ac.uk>
References: <Pine.LNX.4.64.0604031400440.28950@hermes-2.csi.cam.ac.uk>
Message-ID: <200604031526.08733.giannozz@nest.sns.it>

On Monday 03 April 2006 15:06, H.S.Domingos wrote:

> I would like to ask if anyone has used a PBE usoft potential for 
> Magnesium with PWSCF ?
>
> I have tried to find one and could not. Are there any impediments in
> the generation of a potential of this type for Mg ?

there are no impediments, but it is not a big deal, if you need a
2-electron PP: Mg is not that hard.  An ultrasoft PP may be needed
only if for some reason you need semicore electrons in Mg.

Paolo

-- 
Paolo Giannozzi             e-mail:  giannozz at nest.sns.it
Scuola Normale Superiore    Phone:   +39/050-509876, Fax:-563513 
Piazza dei Cavalieri 7      I-56126 Pisa, Italy


From proffess at yandex.ru  Mon Apr  3 16:24:41 2006
From: proffess at yandex.ru (Sergey Lisenkov)
Date: Mon, 3 Apr 2006 18:24:41 +0400 (MSD)
Subject: [Pw_forum] Reading
Message-ID: <44313029.000003.07583@webmail11.yandex.ru>



From proffess at yandex.ru  Mon Apr  3 16:30:30 2006
From: proffess at yandex.ru (Sergey Lisenkov)
Date: Mon, 3 Apr 2006 18:30:30 +0400 (MSD)
Subject: [Pw_forum] Reading "rho" file
Message-ID: <44313186.000006.01024@mfront7.yandex.ru>

 Dear all,

 I did perform vc-relax calculations using pwscf (cvs version, last week). After that I put "startingpot='file'" in my input file and started again. But I immediately got an error:


  %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
     from io_pot : error #         2
     error reading bfo-noU-pberho
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

     stopping ...

 Here in input file prefix=bfo-noU-pbe .So, you can see that code try to read file which is "prefixrho", not "prefix.rho" I tried to restart using stable 3.0 version, but the result is the same. Is it a problem of the code?

 Thanks,
   Sergey


From naromero at gmail.com  Mon Apr  3 16:46:19 2006
From: naromero at gmail.com (Nichols A. Romero)
Date: Mon, 3 Apr 2006 10:46:19 -0400
Subject: [Pw_forum] vanderwaals
Message-ID: <6ac064b60604030746s6213e3b4n8a9f41d6de2014f5@mail.gmail.com>

Hi,

In CP source, there is a file called
vanderwaals.f90

Is this the vdW functional of D. Langreth et. al?

Bests,
--
Nichols A. Romero, Ph.D.
1613 Denise Dr. Apt. D
Forest Hill, MD 21050
443-567-8328 (C)
410-306-0709 (O)


From dxl at ustc.edu.cn  Mon Apr  3 18:00:11 2006
From: dxl at ustc.edu.cn (XunLei Ding)
Date: Tue, 04 Apr 2006 00:00:11 +0800
Subject: [Pw_forum] convert pseudo format
Message-ID: <344080011.22974@ustc.edu.cn>

Dear all,

I want to do a calculation using pwscf with the same pseudopotential provided in
castep software. How can I convert the pseudo from castep format into pwscf
format? Is there any software or tools for this problem?

Thank you!

Yours,
Ding




From giannozz at nest.sns.it  Mon Apr  3 18:34:07 2006
From: giannozz at nest.sns.it (Paolo Giannozzi)
Date: Mon, 3 Apr 2006 18:34:07 +0200
Subject: [Pw_forum] convert pseudo format
In-Reply-To: <344080011.22974@ustc.edu.cn>
References: <344080011.22974@ustc.edu.cn>
Message-ID: <200604031834.07478.giannozz@nest.sns.it>

On Monday 03 April 2006 18:00, XunLei Ding wrote:

> I want to do a calculation using pwscf with the same pseudopotential
> provided in castep software. How can I convert the pseudo from castep
> format into pwscf format? Is there any software or tools for this problem?

short answer: no, unless you write a converter. See this thread:
http://www.democritos.it/pipermail/pw_forum/2005-February/002099.html

P.

-- 
Paolo Giannozzi             e-mail:  giannozz at nest.sns.it
Scuola Normale Superiore    Phone:   +39/050-509876, Fax:-563513 
Piazza dei Cavalieri 7      I-56126 Pisa, Italy


From hsd22 at hermes.cam.ac.uk  Mon Apr  3 19:06:46 2006
From: hsd22 at hermes.cam.ac.uk (H.S.Domingos)
Date: Mon, 3 Apr 2006 18:06:46 +0100 (BST)
Subject: [Pw_forum] PBE usoft Mg ?
In-Reply-To: <200604031526.08733.giannozz@nest.sns.it>
References: <Pine.LNX.4.64.0604031400440.28950@hermes-2.csi.cam.ac.uk>
 <200604031526.08733.giannozz@nest.sns.it>
Message-ID: <Pine.LNX.4.64.0604031803260.28950@hermes-2.csi.cam.ac.uk>

I have a problem that if I use

O  15.9994 O.pbe-rrkjus.UPF
Mg 24.3050 Mg.pw91-np-van.UPF

I get
     from readpp : error #         2
      inconsistent DFT read


what is it ?

Sorry !

Helder


=======================================================================
|  Dr. Helder S. Domingos                                             |
|                                                                     |
| INESC Microsyst & Nanotechnol, Lisbon, P-1000 Portugal              |
| and                                                                 |
| R&D unit for  Molecular Chemical Physics                            |
| Chemistry Department, University of Coimbra                         |
=======================================================================


On Mon, 3 Apr 2006, Paolo Giannozzi wrote:

> On Monday 03 April 2006 15:06, H.S.Domingos wrote:
>
>> I would like to ask if anyone has used a PBE usoft potential for
>> Magnesium with PWSCF ?
>>
>> I have tried to find one and could not. Are there any impediments in
>> the generation of a potential of this type for Mg ?
>
> there are no impediments, but it is not a big deal, if you need a
> 2-electron PP: Mg is not that hard.  An ultrasoft PP may be needed
> only if for some reason you need semicore electrons in Mg.
>
> Paolo
>
> -- 
> Paolo Giannozzi             e-mail:  giannozz at nest.sns.it
> Scuola Normale Superiore    Phone:   +39/050-509876, Fax:-563513
> Piazza dei Cavalieri 7      I-56126 Pisa, Italy
> _______________________________________________
> Pw_forum mailing list
> Pw_forum at pwscf.org
> http://www.democritos.it/mailman/listinfo/pw_forum
>


From baroni at sissa.it  Mon Apr  3 19:06:58 2006
From: baroni at sissa.it (Stefano Baroni)
Date: Mon, 3 Apr 2006 19:06:58 +0200
Subject: [Pw_forum] PBE usoft Mg ?
In-Reply-To: <Pine.LNX.4.64.0604031803260.28950@hermes-2.csi.cam.ac.uk>
References: <Pine.LNX.4.64.0604031400440.28950@hermes-2.csi.cam.ac.uk> <200604031526.08733.giannozz@nest.sns.it> <Pine.LNX.4.64.0604031803260.28950@hermes-2.csi.cam.ac.uk>
Message-ID: <A3BF4375-E858-4AE4-BEA2-2AA826406715@sissa.it>

just a guess: the two pp's seem to have been generated using  
different functionals (O=>pbe, Mg=>pw91), which is inconsistent.
S.

On Apr 3, 2006, at 7:06 PM, H.S.Domingos wrote:

> I have a problem that if I use
>
> O  15.9994 O.pbe-rrkjus.UPF
> Mg 24.3050 Mg.pw91-np-van.UPF
>
> I get
>     from readpp : error #         2
>      inconsistent DFT read
>
>
> what is it ?
>
> Sorry !
>
> Helder
>
>
> ====================================================================== 
> =
> |  Dr. Helder S.  
> Domingos                                             |
> |                                                                      
> |
> | INESC Microsyst & Nanotechnol, Lisbon, P-1000  
> Portugal              |
> |  
> and                                                                 |
> | R&D unit for  Molecular Chemical  
> Physics                            |
> | Chemistry Department, University of  
> Coimbra                         |
> ====================================================================== 
> =
>
>
> On Mon, 3 Apr 2006, Paolo Giannozzi wrote:
>
>> On Monday 03 April 2006 15:06, H.S.Domingos wrote:
>>
>>> I would like to ask if anyone has used a PBE usoft potential for
>>> Magnesium with PWSCF ?
>>>
>>> I have tried to find one and could not. Are there any impediments in
>>> the generation of a potential of this type for Mg ?
>>
>> there are no impediments, but it is not a big deal, if you need a
>> 2-electron PP: Mg is not that hard.  An ultrasoft PP may be needed
>> only if for some reason you need semicore electrons in Mg.
>>
>> Paolo
>>
>> -- 
>> Paolo Giannozzi             e-mail:  giannozz at nest.sns.it
>> Scuola Normale Superiore    Phone:   +39/050-509876, Fax:-563513
>> Piazza dei Cavalieri 7      I-56126 Pisa, Italy
>> _______________________________________________
>> 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

---
Stefano Baroni - SISSA  &  DEMOCRITOS National Simulation Center -  
Trieste
[+39] 040 3787 406 (tel) -528 (fax) / stefanobaroni (skype)

Please, if possible, don't  send me MS Word or PowerPoint attachments
Why? See:  http://www.gnu.org/philosophy/no-word-attachments.html



-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/attachments/20060403/30dbbd24/attachment.htm 

From hsd22 at hermes.cam.ac.uk  Mon Apr  3 19:38:28 2006
From: hsd22 at hermes.cam.ac.uk (H.S.Domingos)
Date: Mon, 3 Apr 2006 18:38:28 +0100 (BST)
Subject: [Pw_forum] PBE usoft Mg ?
In-Reply-To: <A3BF4375-E858-4AE4-BEA2-2AA826406715@sissa.it>
References: <Pine.LNX.4.64.0604031400440.28950@hermes-2.csi.cam.ac.uk>
 <200604031526.08733.giannozz@nest.sns.it> <Pine.LNX.4.64.0604031803260.28950@hermes-2.csi.cam.ac.uk>
 <A3BF4375-E858-4AE4-BEA2-2AA826406715@sissa.it>
Message-ID: <Pine.LNX.4.64.0604031833550.28950@hermes-2.csi.cam.ac.uk>

Yes, so I will have to generate an Mg USP with PBE instead of Pw91.
Does anyone have one already made and tested for MgO for example ?

Thank you again and sorry I am new to PWSCF.

Helder


=======================================================================
|  Dr. Helder S. Domingos                                             |
|                                                                     |
| INESC Microsyst & Nanotechnol, Lisbon, P-1000 Portugal              |
| and                                                                 |
| R&D unit for  Molecular Chemical Physics                            |
| Chemistry Department, University of Coimbra                         |
=======================================================================


On Mon, 3 Apr 2006, Stefano Baroni wrote:

> just a guess: the two pp's seem to have been generated using different 
> functionals (O=>pbe, Mg=>pw91), which is inconsistent.
> S.
>
> On Apr 3, 2006, at 7:06 PM, H.S.Domingos wrote:
>
>> I have a problem that if I use
>> 
>> O  15.9994 O.pbe-rrkjus.UPF
>> Mg 24.3050 Mg.pw91-np-van.UPF
>> 
>> I get
>>    from readpp : error #         2
>>     inconsistent DFT read
>> 
>> 
>> what is it ?
>> 
>> Sorry !
>> 
>> Helder
>> 
>> 
>> =======================================================================
>> |  Dr. Helder S. Domingos                                             |
>> |                                                                     |
>> | INESC Microsyst & Nanotechnol, Lisbon, P-1000 Portugal              |
>> | and                                                                 |
>> | R&D unit for  Molecular Chemical Physics                            |
>> | Chemistry Department, University of Coimbra                         |
>> =======================================================================
>> 
>> 
>> On Mon, 3 Apr 2006, Paolo Giannozzi wrote:
>> 
>>> On Monday 03 April 2006 15:06, H.S.Domingos wrote:
>>> 
>>>> I would like to ask if anyone has used a PBE usoft potential for
>>>> Magnesium with PWSCF ?
>>>> 
>>>> I have tried to find one and could not. Are there any impediments in
>>>> the generation of a potential of this type for Mg ?
>>> 
>>> there are no impediments, but it is not a big deal, if you need a
>>> 2-electron PP: Mg is not that hard.  An ultrasoft PP may be needed
>>> only if for some reason you need semicore electrons in Mg.
>>> 
>>> Paolo
>>> 
>>> -- 
>>> Paolo Giannozzi             e-mail:  giannozz at nest.sns.it
>>> Scuola Normale Superiore    Phone:   +39/050-509876, Fax:-563513
>>> Piazza dei Cavalieri 7      I-56126 Pisa, Italy
>>> _______________________________________________
>>> 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
>
> ---
> Stefano Baroni - SISSA  &  DEMOCRITOS National Simulation Center - Trieste
> [+39] 040 3787 406 (tel) -528 (fax) / stefanobaroni (skype)
>
> Please, if possible, don't  send me MS Word or PowerPoint attachments
> Why? See:  http://www.gnu.org/philosophy/no-word-attachments.html
>
>
>


From giannozz at nest.sns.it  Mon Apr  3 20:55:08 2006
From: giannozz at nest.sns.it (Paolo Giannozzi)
Date: Mon, 3 Apr 2006 20:55:08 +0200
Subject: [Pw_forum] about output wavefunction, charge density and potential
In-Reply-To: <000a01c65539$e046a1e0$83182d0a@jgche>
References: <000a01c65539$e046a1e0$83182d0a@jgche>
Message-ID: <200604032055.08768.giannozz@nest.sns.it>

On Saturday 01 April 2006 05:10, J G Che wrote:

> I find that in each iterative, wavefunction, potential and charge density
> will be saved on disk. Who knows how to output these once only when 
> the self-consistent is reached. Thanks!

- if you have more than one k-point per processor, you have to save
  wavefunctions to disk. It would be possible to store them into memory 
  but it would require extensive changes to the code (and a lot of memory)
- if you have just one k-point and do not specify disk_io='high' the
  code will write wavefunctions only at convergence
- the charge density and potential are written at each scf step.
  This is a behavior that could be changed with simple modifications
  in the code. These arrays however are usually much smaller than
  the wavefunctions.
- unless you specify disk_io='high', auxiliary arrays used for
  self-consistency are not written to disk but stored
- other files are typically small

Paolo
-- 
Paolo Giannozzi             e-mail:  giannozz at nest.sns.it
Scuola Normale Superiore    Phone:   +39/050-509876, Fax:-563513 
Piazza dei Cavalieri 7      I-56126 Pisa, Italy



From giannozz at nest.sns.it  Mon Apr  3 21:07:00 2006
From: giannozz at nest.sns.it (Paolo Giannozzi)
Date: Mon, 3 Apr 2006 21:07:00 +0200
Subject: [Pw_forum] PBE usoft Mg ?
In-Reply-To: <Pine.LNX.4.64.0604031833550.28950@hermes-2.csi.cam.ac.uk>
References: <Pine.LNX.4.64.0604031400440.28950@hermes-2.csi.cam.ac.uk> <A3BF4375-E858-4AE4-BEA2-2AA826406715@sissa.it> <Pine.LNX.4.64.0604031833550.28950@hermes-2.csi.cam.ac.uk>
Message-ID: <200604032107.00767.giannozz@nest.sns.it>

On Monday 03 April 2006 19:38, H.S.Domingos wrote:

> Yes, so I will have to generate an Mg USP with PBE instead of Pw91.
> Does anyone have one already made and tested for MgO for example ?

as a quick and dirty fix, you can modify the exchange-correlation
functional that is hardcoded in the PP file: PBE and PW91 are not
that different. A better procedure would be to take the data used 
in the generation of the PW91 PP (available together with the PP)
and try to generate a new one with PBE

Paolo
--
Paolo Giannozzi             e-mail:  giannozz at nest.sns.it
Scuola Normale Superiore    Phone:   +39/050-509876, Fax:-563513 
Piazza dei Cavalieri 7      I-56126 Pisa, Italy


From giannozz at nest.sns.it  Mon Apr  3 22:27:00 2006
From: giannozz at nest.sns.it (Paolo Giannozzi)
Date: Mon, 3 Apr 2006 22:27:00 +0200
Subject: [Pw_forum] Modification of sort.f90 in v-3.0
In-Reply-To: <442BA6DC.5070507@civet.berkeley.edu>
References: <442BA6DC.5070507@civet.berkeley.edu>
Message-ID: <200604032227.00141.giannozz@nest.sns.it>

On Thursday 30 March 2006 11:37, David Prendergast wrote:

> Please note that there is a significant change to the subroutine
> hpsort_eps in the espresso-3.0 distribution with respect to previous
> versions. (look in $ESPRESSO/flib/sort.f90)
>
> This routine is used in ordering the list of G-vectors by magnitude
> ($ESPRESSO/PW/ggen.f90) and is important for those who wish to know the
> mapping between G-vectors and wave function coefficients, as stored in
> the .save file. 
> [...] 
> Fixing this bug is a definite improvement, however, it would be good to 
> list such a major change in the log files provided in the directory
> $ESPRESSO/Doc/.  This would allow users to more effectively update their
> own tools between new releases of espresso.

the change of ordering you mention was not especially advertised 
because it was not expected to affect anybody. The safe way to 
read data produced by espresso is (or rather, was) to use the 
postprocessing codes, modifying them if necessary to perform 
the desired calculations. If you write your own tools, you are always 
exposed to the risk of unexpected changes of the file format.

[ A true story; years ago, during a period spent at IBM Zurich, I
  tried to read data that had been produced during a preceding stay.
  The executable that was reading the data was the same that had
  produced them, but I got meaningless results. Finally I found that
  the ordering of G-vectors in the data file was not the same of what
  I was obtaining. Apparently the essl library, used by that code 
  version for sorting, had been updated and didn't produce any 
  longer the same ordering of G-shells ]

You won't be pleased to learn that in the new version of espresso
the format of the output data file is completely different, but the 
new format will be much easier to parse and to read, especially 
for those who know nothing about the internals of espresso. The
goal is to make data exchange easier than it is now. 

Paolo
-- 
Paolo Giannozzi             e-mail:  giannozz at nest.sns.it
Scuola Normale Superiore    Phone:   +39/050-509876, Fax:-563513 
Piazza dei Cavalieri 7      I-56126 Pisa, Italy


From giannozz at nest.sns.it  Mon Apr  3 22:33:47 2006
From: giannozz at nest.sns.it (Paolo Giannozzi)
Date: Mon, 3 Apr 2006 22:33:47 +0200
Subject: [Pw_forum] Reading "rho" file
In-Reply-To: <44313186.000006.01024@mfront7.yandex.ru>
References: <44313186.000006.01024@mfront7.yandex.ru>
Message-ID: <200604032233.47215.giannozz@nest.sns.it>

On Monday 03 April 2006 16:30, Sergey Lisenkov wrote:

>  I did perform vc-relax calculations using pwscf (cvs version, last week).
> After that I put "startingpot='file'" in my input file and started again.
> But I immediately got an error: [..]
>      from io_pot : error #         2 
>      error reading bfo-noU-pberho
> [...] Here in input file prefix=bfo-noU-pbe .So, you can see that code 
> try to read file which is "prefixrho", not "prefix.rho"

well, actually it is the error message that is wrong! erroneous error...

> I tried to restart using stable 3.0 version, but the result is the same. 
> Is it a problem of the code?

quite possible, but why do you want to restart from the potential on file?
If you perform a dynamics run, extrapolation of the potential from preceding 
steps should be done automatically.

Paolo
-- 
Paolo Giannozzi             e-mail:  giannozz at nest.sns.it
Scuola Normale Superiore    Phone:   +39/050-509876, Fax:-563513 
Piazza dei Cavalieri 7      I-56126 Pisa, Italy


From giannozz at nest.sns.it  Mon Apr  3 23:51:14 2006
From: giannozz at nest.sns.it (Paolo Giannozzi)
Date: Mon, 3 Apr 2006 23:51:14 +0200
Subject: [Pw_forum] Question on phonons at non-Gamma points
In-Reply-To: <20060331024102.51082.qmail@web52008.mail.yahoo.com>
References: <20060331024102.51082.qmail@web52008.mail.yahoo.com>
Message-ID: <200604032351.14642.giannozz@nest.sns.it>

On Friday 31 March 2006 04:41, Konstantin Kudin wrote:

>  I am looking for an accessible reference on how non-Gamma phonons 
>  are computed analytically in PWSCF or other similar codes. 

Rev. Mod. Phys. 73, 515 (2001), and references quoted therein (a lot):
http://web1.sns.it/~giannozz/Papers/RMP_52.pdf . If you are looking for
more technical stuff, I am afraid you are out of luck: there is very little
written in transmissible format

P.
-- 
Paolo Giannozzi             e-mail:  giannozz at nest.sns.it
Scuola Normale Superiore    Phone:   +39/050-509876, Fax:-563513 
Piazza dei Cavalieri 7      I-56126 Pisa, Italy


From proffess at yandex.ru  Tue Apr  4 00:11:33 2006
From: proffess at yandex.ru (Sergey Lisenkov)
Date: Tue, 4 Apr 2006 02:11:33 +0400 (MSD)
Subject: [Pw_forum] Reading "rho" file
In-Reply-To: <200604032233.47215.giannozz@nest.sns.it>
References: <44313186.000006.01024@mfront7.yandex.ru> <200604032233.47215.giannozz@nest.sns.it>
Message-ID: <44319D95.000004.19517@colgate.yandex.ru>

 Dear Paolo,

>quite possible, but why do you want to restart from the potential on file?
>If you perform a dynamics run, extrapolation of the potential from preceding 
>steps should be done automatically.

  I wanted, but if I am not mistaken, there are two cases:

1) restart_mode='restart' , which will read .save file

2) startingpot='file', which should read rho/pot file. 

I tried both of them, but the code always try to read "rho" file, which was unsuccesfull. So, only the case is the start from the scratch...

 Sergey
  


From jgche at fudan.edu.cn  Tue Apr  4 03:02:19 2006
From: jgche at fudan.edu.cn (J G Che)
Date: Tue, 04 Apr 2006 09:02:19 +0800
Subject: [Pw_forum] about output wavefunction, charge density and potential
References: <000a01c65539$e046a1e0$83182d0a@jgche>
 <200604032055.08768.giannozz@nest.sns.it>
Message-ID: <001501c65783$6c2675f0$83182d0a@jgche>

Dear Paolo:

Thanks for you replying. 

Do you mean that pwscf uses disk to store wavefunctions? 

I think it is not necessary to store wavefunction on disk, since now the RAM is very sheap. 

Che


----- Original Message ----- 
From: "Paolo Giannozzi" <giannozz at nest.sns.it>
To: <pw_forum at pwscf.org>
Sent: Tuesday, April 04, 2006 2:55 AM
Subject: Re: [Pw_forum] about output wavefunction, charge density and potential


> On Saturday 01 April 2006 05:10, J G Che wrote:
> 
> > I find that in each iterative, wavefunction, potential and charge density
> > will be saved on disk. Who knows how to output these once only when 
> > the self-consistent is reached. Thanks!
> 
> - if you have more than one k-point per processor, you have to save
>   wavefunctions to disk. It would be possible to store them into memory 
>   but it would require extensive changes to the code (and a lot of memory)
> - if you have just one k-point and do not specify disk_io='high' the
>   code will write wavefunctions only at convergence
> - the charge density and potential are written at each scf step.
>   This is a behavior that could be changed with simple modifications
>   in the code. These arrays however are usually much smaller than
>   the wavefunctions.
> - unless you specify disk_io='high', auxiliary arrays used for
>   self-consistency are not written to disk but stored
> - other files are typically small
> 
> Paolo
> -- 
> Paolo Giannozzi             e-mail:  giannozz at nest.sns.it
> Scuola Normale Superiore    Phone:   +39/050-509876, Fax:-563513 
> Piazza dei Cavalieri 7      I-56126 Pisa, Italy
> 
> _______________________________________________
> Pw_forum mailing list
> Pw_forum at pwscf.org
> http://www.democritos.it/mailman/listinfo/pw_forum


From liyanpcl at yahoo.com.cn  Tue Apr  4 04:39:58 2006
From: liyanpcl at yahoo.com.cn (li yan)
Date: Tue, 4 Apr 2006 10:39:58 +0800 (CST)
Subject: [Pw_forum] about the Sym.Ops.
Message-ID: <20060404023958.6603.qmail@web15605.mail.cnb.yahoo.com>

Dear all,
        I have calculated the phonon frequency for a special (weight is 1) point at 0GPa. The number of Sym.Ops. in the  file scf.out_0GPa is 12. In the file ph.out_0GPa, it is 12 for this point, which means  Sq=-q+G has not been found. And in the dyn_0GPa file, the folds in this pointhe is 1. So the folds multiply the number of  Sym.Ops. for this point 1*12 is consitent with the number of Sym.Ops. in the  file scf.out_0GPa. At 3GPa, the  number Sym.Ops. in the  file scf.out_3GPa is still 12. But in the file ph.out_3GPa, for the same special point,  the number of  Sym.Ops. is 13. That is to say that there exists Sq=-q+G. And the folds for this points in file dyn_3GPa is 2. So 2*12 is greater than the number Sym.Ops. in the  file scf.out_3GPa. ( I have built the structures using Masterial Studio for 0GPa and 3GPa, respectively. The space group and Sym.Ops. are all same.)
    My questions are:
 1 Why  is there such a difference for 0GPa and 3GPa?
 2 Can I get rid of the points in dyn_3GPa which don't exist in dyn_0GPa to fit the demand of the q2r.x?
   
  best regards.
 
		
---------------------------------
 ??1G???????????
 ????-?????????  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/attachments/20060404/4706ca6d/attachment.htm 

From baroni at sissa.it  Tue Apr  4 07:39:01 2006
From: baroni at sissa.it (Stefano Baroni)
Date: Tue, 4 Apr 2006 07:39:01 +0200
Subject: [Pw_forum] PBE usoft Mg ?
In-Reply-To: <Pine.LNX.4.64.0604031833550.28950@hermes-2.csi.cam.ac.uk>
References: <Pine.LNX.4.64.0604031400440.28950@hermes-2.csi.cam.ac.uk> <200604031526.08733.giannozz@nest.sns.it> <Pine.LNX.4.64.0604031803260.28950@hermes-2.csi.cam.ac.uk> <A3BF4375-E858-4AE4-BEA2-2AA826406715@sissa.it> <Pine.LNX.4.64.0604031833550.28950@hermes-2.csi.cam.ac.uk>
Message-ID: <B4DC70BE-E7E5-4DF8-B8A4-B5F82CCC6FFD@sissa.it>

Probably I should not suggest this, but I am pretty sure that the PBE  
PP will not differ much from PW91. So, if you are in a hurry, while  
you learn how to generate a proper pw91 PP, you could just fake the  
PBE PP file, by just changing the functional label and use it as if  
it was pw91 ... Once you have generate a new PP, let us know ... Take  
care - SB

On Apr 3, 2006, at 7:38 PM, H.S.Domingos wrote:

> Yes, so I will have to generate an Mg USP with PBE instead of Pw91.
> Does anyone have one already made and tested for MgO for example ?
>
> Thank you again and sorry I am new to PWSCF.
>
> Helder
>
>
> ====================================================================== 
> =
> |  Dr. Helder S.  
> Domingos                                             |
> |                                                                      
> |
> | INESC Microsyst & Nanotechnol, Lisbon, P-1000  
> Portugal              |
> |  
> and                                                                 |
> | R&D unit for  Molecular Chemical  
> Physics                            |
> | Chemistry Department, University of  
> Coimbra                         |
> ====================================================================== 
> =
>
>
> On Mon, 3 Apr 2006, Stefano Baroni wrote:
>
>> just a guess: the two pp's seem to have been generated using  
>> different functionals (O=>pbe, Mg=>pw91), which is inconsistent.
>> S.
>>
>> On Apr 3, 2006, at 7:06 PM, H.S.Domingos wrote:
>>
>>> I have a problem that if I use
>>> O  15.9994 O.pbe-rrkjus.UPF
>>> Mg 24.3050 Mg.pw91-np-van.UPF
>>> I get
>>>    from readpp : error #         2
>>>     inconsistent DFT read
>>> what is it ?
>>> Sorry !
>>> Helder
>>> ==================================================================== 
>>> ===
>>> |  Dr. Helder S.  
>>> Domingos                                             |
>>> |                                                                    
>>>   |
>>> | INESC Microsyst & Nanotechnol, Lisbon, P-1000  
>>> Portugal              |
>>> |  
>>> and                                                                  
>>> |
>>> | R&D unit for  Molecular Chemical  
>>> Physics                            |
>>> | Chemistry Department, University of  
>>> Coimbra                         |
>>> ==================================================================== 
>>> ===
>>> On Mon, 3 Apr 2006, Paolo Giannozzi wrote:
>>>> On Monday 03 April 2006 15:06, H.S.Domingos wrote:
>>>>> I would like to ask if anyone has used a PBE usoft potential for
>>>>> Magnesium with PWSCF ?
>>>>> I have tried to find one and could not. Are there any  
>>>>> impediments in
>>>>> the generation of a potential of this type for Mg ?
>>>> there are no impediments, but it is not a big deal, if you need a
>>>> 2-electron PP: Mg is not that hard.  An ultrasoft PP may be needed
>>>> only if for some reason you need semicore electrons in Mg.
>>>> Paolo
>>>> -- 
>>>> Paolo Giannozzi             e-mail:  giannozz at nest.sns.it
>>>> Scuola Normale Superiore    Phone:   +39/050-509876, Fax:-563513
>>>> Piazza dei Cavalieri 7      I-56126 Pisa, Italy
>>>> _______________________________________________
>>>> 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
>>
>> ---
>> Stefano Baroni - SISSA  &  DEMOCRITOS National Simulation Center -  
>> Trieste
>> [+39] 040 3787 406 (tel) -528 (fax) / stefanobaroni (skype)
>>
>> Please, if possible, don't  send me MS Word or PowerPoint attachments
>> Why? See:  http://www.gnu.org/philosophy/no-word-attachments.html
>>
>>
>>
> _______________________________________________
> Pw_forum mailing list
> Pw_forum at pwscf.org
> http://www.democritos.it/mailman/listinfo/pw_forum

---
Stefano Baroni - SISSA  &  DEMOCRITOS National Simulation Center -  
Trieste
[+39] 040 3787 406 (tel) -528 (fax) / stefanobaroni (skype)

Please, if possible, don't  send me MS Word or PowerPoint attachments
Why? See:  http://www.gnu.org/philosophy/no-word-attachments.html



-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/attachments/20060404/db0ffd0e/attachment.htm 

From baroni at sissa.it  Tue Apr  4 07:43:10 2006
From: baroni at sissa.it (Stefano Baroni)
Date: Tue, 4 Apr 2006 07:43:10 +0200
Subject: [Pw_forum] about output wavefunction, charge density and potential
In-Reply-To: <001501c65783$6c2675f0$83182d0a@jgche>
References: <000a01c65539$e046a1e0$83182d0a@jgche> <200604032055.08768.giannozz@nest.sns.it> <001501c65783$6c2675f0$83182d0a@jgche>
Message-ID: <06F661C0-27A5-4925-A457-D0560775F647@sissa.it>


On Apr 4, 2006, at 3:02 AM, J G Che wrote:

> Dear Paolo:
>
> Thanks for you replying.
>
> Do you mean that pwscf uses disk to store wavefunctions?
>
> I think it is not necessary to store wavefunction on disk, since  
> now the RAM is very sheap.

well, this statement is, strictly speaking, not much meaningful until  
one specifies

1) how greedy one is and
2) how large is one's wallet ...

SB

>
> Che
>
>
> ----- Original Message -----
> From: "Paolo Giannozzi" <giannozz at nest.sns.it>
> To: <pw_forum at pwscf.org>
> Sent: Tuesday, April 04, 2006 2:55 AM
> Subject: Re: [Pw_forum] about output wavefunction, charge density  
> and potential
>
>
>> On Saturday 01 April 2006 05:10, J G Che wrote:
>>
>>> I find that in each iterative, wavefunction, potential and charge  
>>> density
>>> will be saved on disk. Who knows how to output these once only when
>>> the self-consistent is reached. Thanks!
>>
>> - if you have more than one k-point per processor, you have to save
>>   wavefunctions to disk. It would be possible to store them into  
>> memory
>>   but it would require extensive changes to the code (and a lot of  
>> memory)
>> - if you have just one k-point and do not specify disk_io='high' the
>>   code will write wavefunctions only at convergence
>> - the charge density and potential are written at each scf step.
>>   This is a behavior that could be changed with simple modifications
>>   in the code. These arrays however are usually much smaller than
>>   the wavefunctions.
>> - unless you specify disk_io='high', auxiliary arrays used for
>>   self-consistency are not written to disk but stored
>> - other files are typically small
>>
>> Paolo
>> -- 
>> Paolo Giannozzi             e-mail:  giannozz at nest.sns.it
>> Scuola Normale Superiore    Phone:   +39/050-509876, Fax:-563513
>> Piazza dei Cavalieri 7      I-56126 Pisa, Italy
>>
>> _______________________________________________
>> 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

---
Stefano Baroni - SISSA  &  DEMOCRITOS National Simulation Center -  
Trieste
[+39] 040 3787 406 (tel) -528 (fax) / stefanobaroni (skype)

Please, if possible, don't  send me MS Word or PowerPoint attachments
Why? See:  http://www.gnu.org/philosophy/no-word-attachments.html



-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/attachments/20060404/7b3daa81/attachment.htm 

From jgche at fudan.edu.cn  Tue Apr  4 09:56:00 2006
From: jgche at fudan.edu.cn (J G Che)
Date: Tue, 04 Apr 2006 15:56:00 +0800
Subject: [Pw_forum] about output wavefunction, charge density and potential
References: <000a01c65539$e046a1e0$83182d0a@jgche>
 <200604032055.08768.giannozz@nest.sns.it>
 <001501c65783$6c2675f0$83182d0a@jgche>
 <06F661C0-27A5-4925-A457-D0560775F647@sissa.it>
Message-ID: <001501c657bd$3693d010$83182d0a@jgche>

However, now there are many abinit packages based plane-waves which don't use disk but RAM to store wavefunctions, meaning it could be at least as a option. Otherwise, such an often writing on disk not only wastes too much time, but also leads to NFS crashing, even for a small system. Each wavefunction files for a job with e.g. 50 atoms for 16 nodes is not more than 200M, it could be run in a PC-Cluster with a standard configuration of 1G/CPU, no problem. However, two these jobs running leads to NFS very slow or crashing, since every ten-seconds it needs to write 6G data on disk. 

JG
  ----- Original Message ----- 
  From: Stefano Baroni 
  To: pw_forum at pwscf.org 
  Sent: Tuesday, April 04, 2006 1:43 PM
  Subject: Re: [Pw_forum] about output wavefunction, charge density and potential




  On Apr 4, 2006, at 3:02 AM, J G Che wrote:


    Dear Paolo:


    Thanks for you replying. 


    Do you mean that pwscf uses disk to store wavefunctions? 


    I think it is not necessary to store wavefunction on disk, since now the RAM is very sheap. 


  well, this statement is, strictly speaking, not much meaningful until one specifies 


  1) how greedy one is and 
  2) how large is one's wallet ...


  SB




    Che




    ----- Original Message ----- 
    From: "Paolo Giannozzi" <giannozz at nest.sns.it>
    To: <pw_forum at pwscf.org>
    Sent: Tuesday, April 04, 2006 2:55 AM
    Subject: Re: [Pw_forum] about output wavefunction, charge density and potential




      On Saturday 01 April 2006 05:10, J G Che wrote:


        I find that in each iterative, wavefunction, potential and charge density
        will be saved on disk. Who knows how to output these once only when 
        the self-consistent is reached. Thanks!


      - if you have more than one k-point per processor, you have to save
        wavefunctions to disk. It would be possible to store them into memory 
        but it would require extensive changes to the code (and a lot of memory)
      - if you have just one k-point and do not specify disk_io='high' the
        code will write wavefunctions only at convergence
      - the charge density and potential are written at each scf step.
        This is a behavior that could be changed with simple modifications
        in the code. These arrays however are usually much smaller than
        the wavefunctions.
      - unless you specify disk_io='high', auxiliary arrays used for
        self-consistency are not written to disk but stored
      - other files are typically small


      Paolo
      -- 
      Paolo Giannozzi             e-mail:  giannozz at nest.sns.it
      Scuola Normale Superiore    Phone:   +39/050-509876, Fax:-563513 
      Piazza dei Cavalieri 7      I-56126 Pisa, Italy


      _______________________________________________
      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


  ---
  Stefano Baroni - SISSA  &  DEMOCRITOS National Simulation Center - Trieste
  [+39] 040 3787 406 (tel) -528 (fax) / stefanobaroni (skype)


  Please, if possible, don't  send me MS Word or PowerPoint attachments
  Why? See:  http://www.gnu.org/philosophy/no-word-attachments.html






-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/attachments/20060404/ce399668/attachment.htm 

From giannozz at nest.sns.it  Tue Apr  4 11:00:03 2006
From: giannozz at nest.sns.it (Paolo Giannozzi)
Date: Tue, 4 Apr 2006 11:00:03 +0200
Subject: [Pw_forum] about output wavefunction, charge density and potential
In-Reply-To: <001501c657bd$3693d010$83182d0a@jgche>
References: <000a01c65539$e046a1e0$83182d0a@jgche> <06F661C0-27A5-4925-A457-D0560775F647@sissa.it> <001501c657bd$3693d010$83182d0a@jgche>
Message-ID: <200604041100.03424.giannozz@nest.sns.it>

On Tuesday 04 April 2006 09:56, J G Che wrote:

> However, now there are many abinit packages based plane-waves
> which don't use disk but RAM to store wavefunctions, meaning it
> could be at least as a option. Otherwise, such an often writing on 
> disk not only wastes too much time, but also leads to NFS crashing

one should never use NFS-mounted filesystem for I/O. Use locally
mounted scratch disks, or a parallel file system (GPFS) if you have one.

Also note that modern operating system tend to keep data in memory
as long as possible. Data to disk is actually written when no more RAM
for caching is available.

Anyway: I agree that it is useful in many cases to keep everything 
in memory, but this requires some work

Paolo
-- 
Paolo Giannozzi             e-mail:  giannozz at nest.sns.it
Scuola Normale Superiore    Phone:   +39/050-509876, Fax:-563513 
Piazza dei Cavalieri 7      I-56126 Pisa, Italy


From sir_puding at tut.by  Tue Apr  4 11:09:39 2006
From: sir_puding at tut.by (sir_puding at tut.by)
Date: Tue, 4 Apr 2006 12:09:39 +0300
Subject: [Pw_forum] Parallel version and NFS
Message-ID: <1863840659.20060404120939@tut.by>

Hi, All.

Does the calculations of SCF runs in parallel depend on type of data
storage? I'm using a Linux PIII cluster with 2 proc. per node and NFS
for data storage. and have long row of messages about unconverged
eigenvalues. In serial variant there is no such messages. I've noticed
that .wfcN files updated unsimultaneously. Or maybe i started
calculations in a wrong way?

here is my output

     Program PWSCF     v.3.1    starts ...
     Today is  4Apr2006 at 10:58:15

     Parallel version (MPI)

     Number of processors in use:      24
     K-points division:     npool     =    4
     R & G space division:  proc/pool =    6

     Ultrasoft (Vanderbilt) Pseudopotentials

     Current dimensions of program pwscf are:

     ntypx = 10   npk = 40000  lmax =  3
     nchix =  6  ndmx =  2000  nbrx = 14  nqfx =  8

     Starting configuration read from file     silicon.save

     Failed to open file     silicon.save

     Using input configuration

     looking for the optimal diagonalization algorithm ...

     dimension   time para (sec)   time serial (sec)
       300        1.11000000        3.49000000

     a parallel algorithm will be used for matrices larger than  300


     Planes per process (thick) : nr3 = 48 npp =   8 ncplane = 2304
 Proc/  planes cols    G   planes cols    G    columns  G
 Pool       (dense grid)      (smooth grid)   (wavefct grid)
  1      8    291   9118    8    291   9118   81   1351
  2      8    292   9118    8    292   9118   82   1350
  3      8    292   9118    8    292   9118   81   1349
  4      8    292   9117    8    292   9117   81   1349
  5      8    291   9117    8    291   9117   81   1349
  6      8    291   9117    8    291   9117   83   1349
  0     48   1749  54705   48   1749  54705  489   8097



     bravais-lattice index     =            0
     lattice parameter (a_0)   =      13.4834  a.u.
     unit-cell volume          =    2460.7699 (a.u.)^3
     number of atoms/cell      =           64
     number of atomic types    =            2
     kinetic-energy cutoff     =      30.0000  Ry
     charge density cutoff     =     120.0000  Ry
     convergence threshold     =      1.0E-08
     beta                      =       0.7000
     number of iterations used =            8  plain     mixing
     Exchange-correlation      =  SLA  PW   PBE  PBE (1434)
     nstep                     =           30

     celldm(1)=  13.483400  celldm(2)=   0.000000  celldm(3)=   0.000000
     celldm(4)=   0.000000  celldm(5)=   0.000000  celldm(6)=   0.000000

     crystal axes: (cart. coord. in units of a_0)
               a(1) = (  1.001285  0.002854  0.002847 )
               a(2) = (  0.002854  1.001309  0.002854 )
               a(3) = (  0.002847  0.002854  1.001285 )
     reciprocal axes: (cart. coord. in units 2 pi/a_0)
               b(1) = (  0.998733 -0.002839 -0.002831 )
               b(2) = ( -0.002839  0.998709 -0.002839 )
               b(3) = ( -0.002831 -0.002839  0.998733 )


     PSEUDO 1 is C  (US)    zval =  4.0   lmax= 2   lloc= 0
     Version   0  0  0 of US pseudo code
     Using log mesh of   627 points
     The pseudopotential has  4 beta functions with:
                l(1) =   0
                l(2) =   0
                l(3) =   1
                l(4) =   1
     Q(r) pseudized with  0 coefficients,  rinner =    0.000   0.000   0.000
                                                       0.000   0.000

     PSEUDO 2 is N  (US)    zval =  5.0   lmax= 2   lloc= 0
     Version   0  0  0 of US pseudo code
     Using log mesh of  1257 points
     The pseudopotential has  4 beta functions with:
                l(1) =   0
                l(2) =   0
                l(3) =   1
                l(4) =   1
     Q(r) pseudized with  0 coefficients,  rinner =    0.000   0.000   0.000
                                                       0.000   0.000

     atomic species   valence    mass     pseudopotential
        C              4.00    12.01078     C ( 1.00)
        N              5.00    14.00675     N ( 1.00)
      cell mass =  58.56510 AMU

     No symmetry!

   Cartesian axes

     site n.     atom                  positions (a_0 units)
         1           C   tau(  1) = (  -0.0004112  -0.0002048  -0.0004112  )
         2           C   tau(  2) = (   0.0020983   0.0022219   0.5009322  )
----
bla bla bla
----

     G cutoff =  552.6120  (  54705 G-vectors)     FFT grid: ( 48, 48, 48)

     nbndx  =  1200  nbnd   =   300  natomwfc =   256  npwx   =    1141
     nelec  = 257.00  nkb   =   512  ngl    =    9118
     
--------
bla bla bla
-------
     Cannot read rho : file not found

     Initial potential from superposition of free atoms

     starting charge  256.99668, renormalised to  257.00000
     Starting wfc from file

     total cpu time spent up to now is     12.84 secs

     Self-consistent Calculation

     iteration #  1     ecut=    30.00 ryd     beta=0.70
     Davidson diagonalization with overlap
     WARNING:    20 eigenvalues not converged
     WARNING:    18 eigenvalues not converged
     WARNING:    23 eigenvalues not converged
     WARNING:    33 eigenvalues not converged
     WARNING:    15 eigenvalues not converged
     WARNING:    19 eigenvalues not converged
     WARNING:    23 eigenvalues not converged
     WARNING:    19 eigenvalues not converged
     WARNING:    20 eigenvalues not converged
     WARNING:    26 eigenvalues not converged
     WARNING:    20 eigenvalues not converged
     WARNING:    25 eigenvalues not converged
     WARNING:    24 eigenvalues not converged
     WARNING:    21 eigenvalues not converged
     
Sergey

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



From giannozz at nest.sns.it  Tue Apr  4 12:08:54 2006
From: giannozz at nest.sns.it (Paolo Giannozzi)
Date: Tue, 4 Apr 2006 12:08:54 +0200
Subject: [Pw_forum] Reading "rho" file
In-Reply-To: <44319D95.000004.19517@colgate.yandex.ru>
References: <44313186.000006.01024@mfront7.yandex.ru> <200604032233.47215.giannozz@nest.sns.it> <44319D95.000004.19517@colgate.yandex.ru>
Message-ID: <200604041208.54871.giannozz@nest.sns.it>

On Tuesday 04 April 2006 00:11, Sergey Lisenkov wrote:

>   I wanted, but if I am not mistaken, there are two cases:
>
> 1) restart_mode='restart' , which will read .save file
>
> 2) startingpot='file', which should read rho/pot file.
>
> I tried both of them, but the code always try to read "rho" file,
> which was unsuccesful

please provide your input data (and update to the latest CVS)

P.
-- 
Paolo Giannozzi             e-mail:  giannozz at nest.sns.it
Scuola Normale Superiore    Phone:   +39/050-509876, Fax:-563513 
Piazza dei Cavalieri 7      I-56126 Pisa, Italy


From giannozz at nest.sns.it  Tue Apr  4 13:57:49 2006
From: giannozz at nest.sns.it (Paolo Giannozzi)
Date: Tue, 4 Apr 2006 13:57:49 +0200
Subject: [Pw_forum] Parallel version and NFS
In-Reply-To: <1863840659.20060404120939@tut.by>
References: <1863840659.20060404120939@tut.by>
Message-ID: <200604041357.49771.giannozz@nest.sns.it>

On Tuesday 04 April 2006 11:09, sir_puding at tut.by wrote:

> Does the calculations of SCF runs in parallel depend on type
> of data storage?

no

> I'm using a Linux PIII cluster with 2 proc. per node and NFS 

don't use NFS 

>      Starting configuration read from file     silicon.save
>
>      Failed to open file     silicon.save
>
>      Using input configuration

are you sure this is what you want? P.

-- 
Paolo Giannozzi             e-mail:  giannozz at nest.sns.it
Scuola Normale Superiore    Phone:   +39/050-509876, Fax:-563513 
Piazza dei Cavalieri 7      I-56126 Pisa, Italy


From hsd22 at hermes.cam.ac.uk  Tue Apr  4 15:04:01 2006
From: hsd22 at hermes.cam.ac.uk (H.S.Domingos)
Date: Tue, 4 Apr 2006 14:04:01 +0100 (BST)
Subject: [Pw_forum] runtime error
In-Reply-To: <200604041357.49771.giannozz@nest.sns.it>
References: <1863840659.20060404120939@tut.by> <200604041357.49771.giannozz@nest.sns.it>
Message-ID: <Pine.LNX.4.64.0604041400240.15976@hermes-2.csi.cam.ac.uk>

i have just compiled the code on a cluster LINUX i686 and I get the 
following error at runtime:

./kpoints.x: symbol lookup error: ./kpoints.x: undefined symbol: 
__intel_cpu_indicator

__intel_cpu_indicator ?

does anyone know what this is ?

Much obliged,

Helder

=======================================================================
|  Dr. Helder S. Domingos                                             |
|                                                                     |
| INESC Microsyst & Nanotechnol, Lisbon, P-1000 Portugal              |
| and                                                                 |
| R&D unit for  Molecular Chemical Physics                            |
| Chemistry Department, University of Coimbra                         |
=======================================================================




From sir_puding at tut.by  Tue Apr  4 16:26:41 2006
From: sir_puding at tut.by (sir_puding at tut.by)
Date: Tue, 4 Apr 2006 17:26:41 +0300
Subject: [Pw_forum] Parallel version and NFS
In-Reply-To: <200604041357.49771.giannozz@nest.sns.it>
References: <1863840659.20060404120939@tut.by> <200604041357.49771.giannozz@nest.sns.it>
Message-ID: <1527535003.20060404172641@tut.by>

>> I'm using a Linux PIII cluster with 2 proc. per node and NFS
> don't use NFS
I have no other possibility (I'm not a UNIX guru, and think that NFS
is used on my cluster because '/home' file-system is the same on every
node and all *.wfc are written to the very same  directory).

>>      Starting configuration read from file     silicon.save
>>
>>      Failed to open file     silicon.save
>>
>>      Using input configuration

> are you sure this is what you want? P.

I'm starting calculation and  use 'restart' in order not to forget load files at the
second run. Does it influence somehow on convergence?

Sergey

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



From pbsorokin at gmail.com  Tue Apr  4 16:30:18 2006
From: pbsorokin at gmail.com (Pavel B. Sorokin)
Date: Tue, 4 Apr 2006 16:30:18 +0200
Subject: [Pw_forum] Problem with compilation
Message-ID: <c3ed08160604040730k3d480948udd2eb4b25ca5a70c@mail.gmail.com>

Dear all,

I have a one question and one trouble, please, help me!
1) Have anybody right make.cygwin file for Espresso3.0 or executable
pw, bands, dos, projwc, plotrho, plotband files? I think that Windows
version of PWSCF is good for performing testing calculations
2)
I have tried to calculate PWSCF3.0 on IBM PowerPC under Linux.
./configure have got me following message:

==========
checking build system type... powerpc64-unknown-linux-gnu
checking architecture...
configure: WARNING: unsupported architecture
checking for f90... f90
checking for Fortran 77 compiler default output... configure: error:
Fortran 77 compiler cannot create executables
==========

Its not good message for me, because I am beginner with Linux, but I
have tried to compile PWSCF manually. I have installed FFTW2.1.5
library to directory /mydir/lib (there a five files: libfftw.(a,la);
librfftw.(a,la), fftw.h
So, at first I have tried to compile Espresso with make.alinux file.
./configure BLAS_LIBS="-lessl" LIBDIRS="/mydir/lib/" --enable-mpi

checking architecture... alinux
checking for mpif90... mpif90
checking for Fortran 77 compiler default output... a.out
checking whether the Fortran 77 compiler works... yes
checking whether we are cross compiling... yes
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU Fortran 77 compiler... no
checking whether mpif90 accepts -g... yes
checking for fort... no
checking for g95... no
checking for f90... f90
checking whether we are using the GNU Fortran 77 compiler... no
checking whether f90 accepts -g... no
setting F90... f90
setting MPIF90... mpif90
checking for mpicc... mpicc
checking whether we are using the GNU C compiler... yes
checking whether mpicc accepts -g... yes
checking for mpicc option to accept ANSI C... none needed
checking for mpif77... mpif77
checking whether we are using the GNU Fortran 77 compiler... no
checking whether mpif77 accepts -g... yes
checking for ccc... no
checking for gcc... gcc
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ANSI C... (cached) none needed
setting CC... gcc
setting MPICC... mpicc
checking for fort... no
checking for g77... g77
checking whether we are using the GNU Fortran 77 compiler... yes
checking whether g77 accepts -g... yes
setting F77... g77
setting MPIF77... mpif77
configure: WARNING: unsupported C/Fortran compilers combination <--- ???????????
setting FFLAGS... -O
setting F90FLAGS... $(FFLAGS)
....
all dependencies updated successfully
configure: creating ./config.status
config.status: creating make.sys
config.status: creating configure.msg
--------------------------------------------------------------------
ESPRESSO can take advantage of several optimized numerical libraries
(essl, fftw, mkl...).  This configure script attempts to find them,
but may fail if they have been installed in non-standard locations.

The following libraries have been found:
  BLAS_LIBS=
  LAPACK_LIBS=
  FFT_LIBS=-L/mydir/lib -lfftw  FFT_LIBS=-L/mydir/lib -lfftw
  WARNING: fftw library detected, but fftw.h not found
Please check if that is correct.

So, I think that all right with it (excluding "warning" message - why?
I don't understand - fftw.h locates in the directory mydir/lib and in
mydir/include) and I have tried to execute make command.

make pw

test -d bin || mkdir bin
if test -d iotk ; then \
( cd iotk ; if test "make" = "" ; then make  TLDEPS= libiotk.a ; \
else make  TLDEPS= libiotk.a ; fi ) ; fi
make[1]: Entering directory `/nethome/Distributives/espresso-3.0/iotk'
cd src ; make libiotk.a
make[2]: Entering directory `/nethome/Distributives/espresso-3.0/iotk/src'
cpp -P -traditional -D__ALPHA -D__LINUX64 -D__FFTW
-D__USE_INTERNAL_FFTW -D__MPI -D__PARA -I../include  iotk_base.f90 -o
iotk_base.F90
mpif90 -O -D__ALPHA -D__LINUX64 -D__FFTW -D__USE_INTERNAL_FFTW -D__MPI
-D__PARA -I../include  -I. -I../Modules -I../PW -I../PH -I../iotk/src
-c iotk_base.F90 -o iotk_base.o
xlf90_r: 1501-216 command option -__ALPHA is not recognized - passed to ld
xlf90_r: 1501-216 command option -__LINUX64 is not recognized - passed to ld
xlf90_r: 1501-216 command option -__FFTW is not recognized - passed to ld
xlf90_r: 1501-216 command option -__USE_INTERNAL_FFTW is not
recognized - passed to ld
xlf90_r: 1501-216 command option -__MPI is not recognized - passed to ld
xlf90_r: 1501-216 command option -__PARA is not recognized - passed to ld
xlf90_r: 1501-218 file iotk_base.F90 contains an incorrect file suffix
make[2]: *** [iotk_base.o] Error 1
make[2]: Leaving directory `/nethome/Distributives/espresso-3.0/iotk/src'
make[1]: *** [libiotk.a] Error 2
make[1]: Leaving directory `/nethome/Distributives/espresso-3.0/iotk'
make: *** [libiotk] Error 2

I don't know, what I must do...

And second attempt was with make.linux64 file

make pw
test -d bin || mkdir bin
if test -d iotk ; then \
( cd iotk ; if test "make" = "" ; then make  TLDEPS= libiotk.a ; \
else make  TLDEPS= libiotk.a ; fi ) ; fi
make[1]: Entering directory `/nethome/espresso-3.0/iotk'
cd src ; make libiotk.a
make[2]: Entering directory `/nethome/espresso-3.0/iotk/src'
cpp -P -traditional -D__LINUX64 -D__FFTW -D__USE_INTERNAL_FFTW -D__MPI
-D__PARA -I../include  iotk_base.f90 -o iotk_base.F90
mpif90 -O -D__LINUX64 -D__FFTW -D__USE_INTERNAL_FFTW -D__MPI -D__PARA
-I../include  -I. -I../Modules -I../PW -I../PH -I../iotk/src -c
iotk_base.F90 -o iotk_base.o
xlf90_r: 1501-216 command option -__LINUX64 is not recognized - passed to ld
xlf90_r: 1501-216 command option -__FFTW is not recognized - passed to ld
xlf90_r: 1501-216 command option -__USE_INTERNAL_FFTW is not
recognized - passed to ld
xlf90_r: 1501-216 command option -__MPI is not recognized - passed to ld
xlf90_r: 1501-216 command option -__PARA is not recognized - passed to ld
xlf90_r: 1501-218 file iotk_base.F90 contains an incorrect file suffix
make[2]: *** [iotk_base.o] Error 1
make[2]: Leaving directory `/nethome/espresso-3.0/iotk/src'
make[1]: *** [libiotk.a] Error 2
make[1]: Leaving directory `/nethome/espresso-3.0/iotk'
make: *** [libiotk] Error 2

Please, help!

Sincerely yours.
Pavel B Sorokin


From giannozz at nest.sns.it  Tue Apr  4 16:40:25 2006
From: giannozz at nest.sns.it (Paolo Giannozzi)
Date: Tue, 4 Apr 2006 16:40:25 +0200
Subject: [Pw_forum] runtime error
In-Reply-To: <Pine.LNX.4.64.0604041400240.15976@hermes-2.csi.cam.ac.uk>
References: <1863840659.20060404120939@tut.by> <200604041357.49771.giannozz@nest.sns.it> <Pine.LNX.4.64.0604041400240.15976@hermes-2.csi.cam.ac.uk>
Message-ID: <200604041640.25132.giannozz@nest.sns.it>

On Tuesday 04 April 2006 15:04, H.S.Domingos wrote:

> i have just compiled the code on a cluster LINUX i686 and I get the
> following error at runtime:
>
> ./kpoints.x: symbol lookup error: ./kpoints.x: undefined symbol:
> __intel_cpu_indicator
>
> __intel_cpu_indicator ?
>
> does anyone know what this is ?

it is a problem of your sowftare setting, not of quantum-espresso
Please look for "__intel_cpu_indicator" with google, there are
several links.

Paolo
-- 
Paolo Giannozzi             e-mail:  giannozz at nest.sns.it
Scuola Normale Superiore    Phone:   +39/050-509876, Fax:-563513 
Piazza dei Cavalieri 7      I-56126 Pisa, Italy


From proffess at yandex.ru  Tue Apr  4 16:46:59 2006
From: proffess at yandex.ru (Sergey Lisenkov)
Date: Tue, 4 Apr 2006 18:46:59 +0400 (MSD)
Subject: [Pw_forum] runtime error
In-Reply-To: <200604041640.25132.giannozz@nest.sns.it>
References: <1863840659.20060404120939@tut.by> <200604041357.49771.giannozz@nest.sns.it> <Pine.LNX.4.64.0604041400240.15976@hermes-2.csi.cam.ac.uk> <200604041640.25132.giannozz@nest.sns.it>
Message-ID: <443286E3.000007.08533@ariel.yandex.ru>

>> ./kpoints.x: symbol lookup error: ./kpoints.x: undefined symbol:
>> __intel_cpu_indicator
>>
>> __intel_cpu_indicator ?
>>
>> does anyone know what this is ?
>
>it is a problem of your sowftare setting, not of quantum-espresso
>Please look for "__intel_cpu_indicator" with google, there are
>several links.

 Add "-static" during the linking stage.

Sergey


From hsd22 at hermes.cam.ac.uk  Tue Apr  4 18:25:38 2006
From: hsd22 at hermes.cam.ac.uk (H.S.Domingos)
Date: Tue, 4 Apr 2006 17:25:38 +0100 (BST)
Subject: [Pw_forum] runtime error
In-Reply-To: <443286E3.000007.08533@ariel.yandex.ru>
References: <1863840659.20060404120939@tut.by> <200604041357.49771.giannozz@nest.sns.it>
 <Pine.LNX.4.64.0604041400240.15976@hermes-2.csi.cam.ac.uk>
 <200604041640.25132.giannozz@nest.sns.it> <443286E3.000007.08533@ariel.yandex.ru>
Message-ID: <Pine.LNX.4.64.0604041724110.15976@hermes-2.csi.cam.ac.uk>

-static at LD
Thank You very much Sergey !

You just saved my day !

Helder


=======================================================================
|  Dr. Helder S. Domingos                                             |
|                                                                     |
| INESC Microsyst & Nanotechnol, Lisbon, P-1000 Portugal              |
| and                                                                 |
| R&D unit for  Molecular Chemical Physics                            |
| Chemistry Department, University of Coimbra                         |
=======================================================================




From davegp at civet.berkeley.edu  Tue Apr  4 20:56:11 2006
From: davegp at civet.berkeley.edu (David Prendergast)
Date: Tue, 04 Apr 2006 11:56:11 -0700
Subject: [Pw_forum] Modification of sort.f90 in v-3.0
In-Reply-To: <200604032227.00141.giannozz@nest.sns.it>
References: <442BA6DC.5070507@civet.berkeley.edu> <200604032227.00141.giannozz@nest.sns.it>
Message-ID: <4432C14B.6010403@civet.berkeley.edu>

Thanks Paolo,

I am also aware of the dangers of changing libraries. I just thought I 
should mention this to save some other poor souls that might be digging 
around in the save files produced by PWSCF. The best of luck in 
developing the newer (more transparent) output format.

And, let me reiterate that this version and previous versions of the 
code produce consistent output. This posting was not a criticism, just 
an update.

However one might notice some problems exchanging wave functions between 
different versions - something to be avoided in general.

David.


Paolo Giannozzi wrote:

>On Thursday 30 March 2006 11:37, David Prendergast wrote:
>
>  
>
>>Please note that there is a significant change to the subroutine
>>hpsort_eps in the espresso-3.0 distribution with respect to previous
>>versions. (look in $ESPRESSO/flib/sort.f90)
>>
>>This routine is used in ordering the list of G-vectors by magnitude
>>($ESPRESSO/PW/ggen.f90) and is important for those who wish to know the
>>mapping between G-vectors and wave function coefficients, as stored in
>>the .save file. 
>>[...] 
>>Fixing this bug is a definite improvement, however, it would be good to 
>>list such a major change in the log files provided in the directory
>>$ESPRESSO/Doc/.  This would allow users to more effectively update their
>>own tools between new releases of espresso.
>>    
>>
>
>the change of ordering you mention was not especially advertised 
>because it was not expected to affect anybody. The safe way to 
>read data produced by espresso is (or rather, was) to use the 
>postprocessing codes, modifying them if necessary to perform 
>the desired calculations. If you write your own tools, you are always 
>exposed to the risk of unexpected changes of the file format.
>
>[ A true story; years ago, during a period spent at IBM Zurich, I
>  tried to read data that had been produced during a preceding stay.
>  The executable that was reading the data was the same that had
>  produced them, but I got meaningless results. Finally I found that
>  the ordering of G-vectors in the data file was not the same of what
>  I was obtaining. Apparently the essl library, used by that code 
>  version for sorting, had been updated and didn't produce any 
>  longer the same ordering of G-shells ]
>
>You won't be pleased to learn that in the new version of espresso
>the format of the output data file is completely different, but the 
>new format will be much easier to parse and to read, especially 
>for those who know nothing about the internals of espresso. The
>goal is to make data exchange easier than it is now. 
>
>Paolo
>  
>

-- 
OoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOo
  David Prendergast
  University of California, Berkeley             phone: (510) 642-2635
  Department of Physics                          fax:   (510) 643-9473
  366 LeConte Hall #7300              email: davegp at civet.berkeley.edu
  Berkeley, CA 94720-7300       web: http://civet.berkeley.edu/~davegp
OoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOo



From akohlmey at cmm.upenn.edu  Tue Apr  4 21:46:35 2006
From: akohlmey at cmm.upenn.edu (Axel Kohlmeyer)
Date: Tue, 4 Apr 2006 15:46:35 -0400 (EDT)
Subject: [Pw_forum] runtime error
In-Reply-To: <443286E3.000007.08533@ariel.yandex.ru>
References: <1863840659.20060404120939@tut.by> <200604041357.49771.giannozz@nest.sns.it>
 <Pine.LNX.4.64.0604041400240.15976@hermes-2.csi.cam.ac.uk>
 <200604041640.25132.giannozz@nest.sns.it> <443286E3.000007.08533@ariel.yandex.ru>
Message-ID: <Pine.LNX.4.60.0604041540580.21099@vitae.cmm.upenn.edu>

sergey,

'-static' is 'dangerous' on linux. you can run into all
kinds of troubles when you update your OS or want to
use the binary on different installations.

with recent intel compilers you should use '-i-static',
and if you are using intel MKL you should use '-openmp'
in addition and for MKL the static versions of the
respective libraries, e.g. -lmkl_lapack and -lmkl_ia32
/-lmkl_em64t ...

also if you want to use the binary on multiple machines,
you have to compile it on the 'oldest' installation.

best regards,
    axel.

=======================================================================
Axel Kohlmeyer    e-mail: akohlmey at cmm.upenn.edu, tel: ++1-215-898-1582
    Center for Molecular Modeling    --    University of Pennsylvania
Department of Chemistry, 231 S.34th Street, Philadelphia, PA 19104-6323
=======================================================================
If you make something idiot-proof, the universe creates a better idiot.

On Tue, 4 Apr 2006, Sergey Lisenkov wrote:

>>> ./kpoints.x: symbol lookup error: ./kpoints.x: undefined symbol:
>>> __intel_cpu_indicator
>>>
>>> __intel_cpu_indicator ?
>>>
>>> does anyone know what this is ?
>>
>> it is a problem of your sowftare setting, not of quantum-espresso
>> Please look for "__intel_cpu_indicator" with google, there are
>> several links.
>
> Add "-static" during the linking stage.
>
> Sergey
> _______________________________________________
> Pw_forum mailing list
> Pw_forum at pwscf.org
> http://www.democritos.it/mailman/listinfo/pw_forum
>


From giannozz at nest.sns.it  Tue Apr  4 22:44:04 2006
From: giannozz at nest.sns.it (Paolo Giannozzi)
Date: Tue, 4 Apr 2006 22:44:04 +0200
Subject: [Pw_forum] Parallel version and NFS
In-Reply-To: <1527535003.20060404172641@tut.by>
References: <1863840659.20060404120939@tut.by> <200604041357.49771.giannozz@nest.sns.it> <1527535003.20060404172641@tut.by>
Message-ID: <200604042244.04734.giannozz@nest.sns.it>

On Tuesday 04 April 2006 16:26, sir_puding at tut.by wrote:

> > don't use NFS
>
> I have no other possibility (I'm not a UNIX guru, and think that NFS
> is used on my cluster because '/home' file-system is the same on every
> node and all *.wfc are written to the very same  directory).

I cannot believe that your system has no local scratch filesystem!

> I'm starting calculation and  use 'restart' in order not to forget load
> files at the second run.

??? anyway, please provide the input that produces this problem

Paolo
-- 
Paolo Giannozzi             e-mail:  giannozz at nest.sns.it
Scuola Normale Superiore    Phone:   +39/050-509876, Fax:-563513 
Piazza dei Cavalieri 7      I-56126 Pisa, Italy


From jgche at fudan.edu.cn  Wed Apr  5 05:11:24 2006
From: jgche at fudan.edu.cn (J G Che)
Date: Wed, 05 Apr 2006 11:11:24 +0800
Subject: [Pw_forum] about output wavefunction, charge density and potential
References: <000a01c65539$e046a1e0$83182d0a@jgche>
 <06F661C0-27A5-4925-A457-D0560775F647@sissa.it>
 <001501c657bd$3693d010$83182d0a@jgche>
 <200604041100.03424.giannozz@nest.sns.it>
Message-ID: <000b01c6585e$9f106620$83182d0a@jgche>

If so, are there any options, with which all files in scratch will be saved on user's disk once before exiting calculation? Otherwise, it cannot be re-started from scratch, since PBS distributes a job into avaiable nodes, not into the defined nodes as same as the last calculation. Or it can only be run in a small cluster which is only for one person. 

JG
----- Original Message ----- 
From: "Paolo Giannozzi" <giannozz at nest.sns.it>
To: <pw_forum at pwscf.org>
Sent: Tuesday, April 04, 2006 5:00 PM
Subject: Re: [Pw_forum] about output wavefunction, charge density and potential


> On Tuesday 04 April 2006 09:56, J G Che wrote:
> 
> > However, now there are many abinit packages based plane-waves
> > which don't use disk but RAM to store wavefunctions, meaning it
> > could be at least as a option. Otherwise, such an often writing on 
> > disk not only wastes too much time, but also leads to NFS crashing
> 
> one should never use NFS-mounted filesystem for I/O. Use locally
> mounted scratch disks, or a parallel file system (GPFS) if you have one.
> 
> Also note that modern operating system tend to keep data in memory
> as long as possible. Data to disk is actually written when no more RAM
> for caching is available.
> 
> Anyway: I agree that it is useful in many cases to keep everything 
> in memory, but this requires some work
> 
> Paolo
> -- 
> Paolo Giannozzi             e-mail:  giannozz at nest.sns.it
> Scuola Normale Superiore    Phone:   +39/050-509876, Fax:-563513 
> Piazza dei Cavalieri 7      I-56126 Pisa, Italy
> _______________________________________________
> Pw_forum mailing list
> Pw_forum at pwscf.org
> http://www.democritos.it/mailman/listinfo/pw_forum


From hqzhou at nju.edu.cn  Wed Apr  5 07:39:08 2006
From: hqzhou at nju.edu.cn (Huiqun Zhou)
Date: Wed, 5 Apr 2006 13:39:08 +0800
Subject: [Pw_forum] Parallel version and NFS
References: <1863840659.20060404120939@tut.by> <200604041357.49771.giannozz@nest.sns.it> <1527535003.20060404172641@tut.by>
Message-ID: <009601c65873$42940cc0$1d00a8c0@solarflare>

Sergey,

It seems you are doing a "from scratch" SCF calculation while setting
restart_mode='restart'. If this is your case, you definitly need to set
restart_mode='from_scratch'. Using restart means you have already
a successful previous run and you want to continue the run from there
this time.

Huiqun

----- Original Message ----- 
From: <sir_puding at tut.by>
To: "Paolo Giannozzi" <pw_forum at pwscf.org>
Sent: Tuesday, April 04, 2006 10:26 PM
Subject: Re[2]: [Pw_forum] Parallel version and NFS


>>> I'm using a Linux PIII cluster with 2 proc. per node and NFS
>> don't use NFS
> I have no other possibility (I'm not a UNIX guru, and think that NFS
> is used on my cluster because '/home' file-system is the same on every
> node and all *.wfc are written to the very same  directory).
>
>>>      Starting configuration read from file     silicon.save
>>>
>>>      Failed to open file     silicon.save
>>>
>>>      Using input configuration
>
>> are you sure this is what you want? P.
>
> I'm starting calculation and  use 'restart' in order not to forget load 
> files at the
> second run. Does it influence somehow on convergence?
>
> Sergey
>
> --
> Please avoid sending me Word or PowerPoint attachments.
> See http://www.gnu.org/philosophy/no-word-attachments.html
>
> _______________________________________________
> Pw_forum mailing list
> Pw_forum at pwscf.org
> http://www.democritos.it/mailman/listinfo/pw_forum
>
> 



From hsd22 at hermes.cam.ac.uk  Wed Apr  5 10:32:05 2006
From: hsd22 at hermes.cam.ac.uk (H.S.Domingos)
Date: Wed, 5 Apr 2006 09:32:05 +0100 (BST)
Subject: [Pw_forum] Parallel version and NFS
In-Reply-To: <200604042244.04734.giannozz@nest.sns.it>
References: <1863840659.20060404120939@tut.by> <200604041357.49771.giannozz@nest.sns.it>
 <1527535003.20060404172641@tut.by> <200604042244.04734.giannozz@nest.sns.it>
Message-ID: <Pine.LNX.4.64.0604050924340.13821@hermes-2.csi.cam.ac.uk>

Dear all,

I would like to ask about a ZnO vc-relax cell that I have been doing just 
for testing. I get a cell parameter that is about 4% off the experimental 
value and the c/a is well off as well.
I do not know what is wrong with this.

I do understand that this is an odd way to do wurzite but I want to test 
the setup for something else.
Can you please help out ?  Thank you and let me just say that the 
assistance that I have got from the forum so far has been outstanding.

the file:

&control
     calculation = 'vc-relax'
     restart_mode='from_scratch',
     prefix='ZnO',
     tstress = .true.
     tprnfor = .true.
     pseudo_dir = '/home/hdomingos/espresso-3.0/pseudo//',
     outdir='/tmp/', nstep = 5000,
     dt=20.0
     etot_conv_thr=2.0d-4
     forc_conv_thr=2.0d-3
  /
  &system
     ibrav=  14, celldm(1) =6.48, celldm(2)=1, celldm(3) = 1.602, 
celldm(4)=0,celldm(5)=0 , celldm(6)=-0.5 , nat = 4,ntyp = 2
     ecutwfc =40
  /
  &electrons
     diagonalization='david'
     mixing_mode = 'plain'
     mixing_beta = 0.7
     conv_thr =  1.0d-5
     electron_maxstep=500
  /
  &ions
  ion_dynamics='damp'
  /
  &cell
     cell_dynamics='damp-w'
     press=0.
  /
ATOMIC_SPECIES
   Zn   65.39000  Zn.pw91-van_ak.UPF
    O   15.99940  O.pw91-van_ak.UPF
ATOMIC_POSITIONS {crystal}
Zn  0.333330000  0.666670000  0.000000000
Zn  0.666670000  0.333330000  0.500000000
O  0.333330000  0.666670000  0.375000000
O  0.666670000  0.333330000  0.875000000
K_POINTS  automatic
4 4 4 0 0 0


=======================================================================
|  Dr. Helder S. Domingos                                             |
|                                                                     |
| INESC Microsyst & Nanotechnol, Lisbon, P-1000 Portugal              |
| and                                                                 |
| R&D unit for  Molecular Chemical Physics                            |
| Chemistry Department, University of Coimbra                         |
=======================================================================




From sir_puding at tut.by  Wed Apr  5 13:54:41 2006
From: sir_puding at tut.by (sir_puding at tut.by)
Date: Wed, 5 Apr 2006 14:54:41 +0300
Subject: [Pw_forum] Parallel version and NFS
In-Reply-To: <200604042244.04734.giannozz@nest.sns.it>
References: <1863840659.20060404120939@tut.by> <200604041357.49771.giannozz@nest.sns.it> <1527535003.20060404172641@tut.by> <200604042244.04734.giannozz@nest.sns.it>
Message-ID: <9510607031.20060405145441@tut.by>

> I cannot believe that your system has no local scratch filesystem!
It has, But there is no guarantee that local /tmp has enough  space on
every node. So, i need to use my /home/lds HDD. (Now I'm using simple
test-cluster which is used by many people before extensive calculations
on serious machine)

> please provide the input that produces this problem
I thought that there is no any difference between 'from scratch' and
'restart' modes when there is no any files from previous calculation.
In output program writes 'save not found, using input configuration',
same for potential and wavefunctions.
For me it  means that calculation goes 'from_scratch'.

Anyway, I've started calculations right, 'from_scratch', with
potential from atoms superposition and the same for wfc, and using
local temp dir,  but problem with convergence in first iteration still  exists.

Sergey

my old input
--------
 &CONTROL
                 calculation = 'vc-relax' ,
                restart_mode = 'restart' ,
                  wf_collect = .true. ,
                      outdir = '/home/lds/tmp/' ,
                  pseudo_dir = '/home/lds/espresso/pseudo/' ,
                      prefix = 'silicon' ,
                     disk_io = 'default' ,
                   verbosity = 'default' ,
               etot_conv_thr = 1.D-6 ,
               forc_conv_thr = 1.D-6 ,
                       nstep = 30 ,
                     tstress = .true. ,
                     tprnfor = .true. ,
                          dt = 50 ,
 /
 &SYSTEM
                       ibrav = 0,
                   celldm(1) = 13.4834,
                         nat = 64,
                        ntyp = 2,
                     ecutwfc = 30 ,
                       nosym = .true. ,
                        nbnd = 300,
                       nelec = 257,
                 occupations = 'tetrahedra' ,
                       nspin = 1 ,
 /
 &ELECTRONS
                    conv_thr = 1.0d-8 ,
                 startingpot = 'file' ,
                 startingwfc = 'file' ,
                 mixing_mode = 'plain' ,
                 mixing_beta = 0.7 ,
             diagonalization = 'david' ,
 /
 &IONS
                ion_dynamics = 'damp' ,
 /
 &CELL
               cell_dynamics = 'damp-pr' ,
 /
CELL_PARAMETERS alat
     1.001284827    0.002853981    0.002846682                       
     0.002853985    1.001308791    0.002853985
     0.002846682    0.002853981    1.001284827
ATOMIC_SPECIES
    C   12.01078  C.pbe-rrkjus.UPF
    N   14.00675  N.pbe-rrkjus.UPF
ATOMIC_POSITIONS alat
    C     -0.000411174   -0.000204767   -0.000411174
    C      0.002098331    0.002221908    0.500932170
    C     -0.000045859    0.250580894    0.250457544
    C      0.002219314    0.252923640    0.750880737
    C      0.002109330    0.501077678    0.002109331
    C      0.001767192    0.501795146    0.501650854
    C      0.002186471    0.751016286    0.252798804
    C      0.005447910    0.753580185    0.753419772
    C      0.125108721    0.125251176    0.125108721
    C      0.126543635    0.126666058    0.625869486
    C      0.125324871    0.375989285    0.375861475
    C      0.128972956    0.378221350    0.876231944
    C      0.126537116    0.626028922    0.126537116
    C      0.128722812    0.627568057    0.627379082
    C      0.128970236    0.876359204    0.378078334
    C      0.130887959    0.878902709    0.878695675
    C      0.250439611    0.000061706    0.250439611
    C      0.252807018    0.002343198    0.750849658
    C      0.250457543    0.250580894   -0.000045859
    C      0.249832391    0.249950783    0.500836235
    C      0.249831988    0.500975286    0.249831988
    C      0.255023896    0.504124094    0.750606158
    C      0.252798803    0.751016286    0.002186471
    C      0.255037561    0.750757592    0.503984572
    C      0.375856435    0.125431490    0.375856435
    C      0.378088203    0.129097780    0.876235649
    C      0.375861474    0.375989285    0.125324871
    C      0.375437799    0.375557771    0.622013549
    C      0.375445558    0.622149847    0.375445558
    C      0.380886166    0.629192100    0.877632827
    C      0.378078334    0.876359204    0.128970236
    C      0.380897096    0.877778485    0.629053129
    C      0.500932169    0.002221908    0.002098332
    C      0.501653977    0.001878686    0.501653977
    C      0.500836235    0.249950783    0.249832392
    C      0.503997539    0.255156665    0.750631256
    C      0.501650854    0.501795146    0.001767192
    N      0.486107094    0.486200194    0.486107094
    C      0.503984572    0.750757592    0.255037561
    C      0.508233521    0.756508940    0.756374101
    C      0.625869485    0.126666058    0.126543636
    C      0.627425583    0.128878572    0.627425584
    C      0.622013549    0.375557771    0.375437800
    C      0.629059253    0.381018969    0.877650922
    C      0.627379082    0.627568058    0.128722812
    C      0.648656738    0.648807613    0.648656738
    C      0.629053128    0.877778485    0.380897097
    C      0.630868728    0.882939575    0.882796189
    C      0.750849657    0.002343198    0.252807018
    C      0.753422309    0.005560609    0.753422310
    C      0.750880737    0.252923640    0.002219315
    C      0.750631256    0.255156665    0.503997539
    C      0.750606157    0.504124094    0.255023897
    C      0.756381813    0.508368160    0.756381814
    C      0.753419771    0.753580185    0.005447910
    C      0.756374101    0.756508940    0.508233522
    C      0.876235649    0.129097780    0.378088203
    C      0.878717335    0.130994359    0.878717336
    C      0.876231943    0.378221351    0.128972956
    C      0.877650922    0.381018969    0.629059253
    C      0.877632827    0.629192100    0.380886166
    C      0.882799518    0.631017191    0.882799519
    C      0.878695675    0.878902709    0.130887959
    C      0.882796188    0.882939575    0.630868729
K_POINTS automatic
  4 4 4   1 1 1
---------------
--
Please avoid sending me Word or PowerPoint attachments.
See http://www.gnu.org/philosophy/no-word-attachments.html



From proffess at yandex.ru  Wed Apr  5 15:25:25 2006
From: proffess at yandex.ru (Sergey Lisenkov)
Date: Wed, 5 Apr 2006 17:25:25 +0400 (MSD)
Subject: [Pw_forum] Reading "rho" file
Message-ID: <4433C545.000008.01622@tide.yandex.ru>

Dear Paolo,

  I found, that this problem does not appear when I change ecutwfc  and use startingpot='file'. But this problem appears if I change ecutrho  and use startingpot='file'. 

Sergey

>
>>quite possible, but why do you want to restart from the potential on file?
>>If you perform a dynamics run, extrapolation of the potential from preceding 
>>steps should be done automatically.
>
>  I wanted, but if I am not mistaken, there are two cases:
>
>1) restart_mode='restart' , which will read .save file
>
>2) startingpot='file', which should read rho/pot file. 
>
>I tried both of them, but the code always try to read "rho" file, which was unsuccesfull. So, only the case is the start from the scratch...
>
> Sergey
>  





From stewart at cnf.cornell.edu  Wed Apr  5 15:40:47 2006
From: stewart at cnf.cornell.edu (stewart at cnf.cornell.edu)
Date: Wed, 05 Apr 2006 09:40:47 -0400
Subject: [Pw_forum] Re: about output wavefunction, charge density and potential
In-Reply-To: <000b01c6585e$9f106620$83182d0a@jgche>
References: <000a01c65539$e046a1e0$83182d0a@jgche>
            <06F661C0-27A5-4925-A457-D0560775F647@sissa.it>
            <001501c657bd$3693d010$83182d0a@jgche>
            <200604041100.03424.giannozz@nest.sns.it>
            <000b01c6585e$9f106620$83182d0a@jgche>
Message-ID: <20060405134047.8297.qmail@xuxa.iecc.com>

Hi J G, 

  Try setting the option wf_collect = .true. in the &control section.  This 
will collect the wave functions from all the processors and store everything 
in a save file for restarting (see INPUT_PW for details).  This will 
increase traffic on the network some but I believe the collection is only 
done at the end of the calculation. 

Best regards, 

Derek 

 

J G Che writes: 

> If so, are there any options, with which all files in scratch will be saved on user's disk once before exiting calculation? Otherwise, it cannot be re-started from scratch, since PBS distributes a job into avaiable nodes, not into the defined nodes as same as the last calculation. Or it can only be run in a small cluster which is only for one person.  
> 
> JG
> ----- Original Message ----- 
> From: "Paolo Giannozzi" <giannozz at nest.sns.it>
> To: <pw_forum at pwscf.org>
> Sent: Tuesday, April 04, 2006 5:00 PM
> Subject: Re: [Pw_forum] about output wavefunction, charge density and potential 
> 
> 
>> On Tuesday 04 April 2006 09:56, J G Che wrote: 
>> 
>> > However, now there are many abinit packages based plane-waves
>> > which don't use disk but RAM to store wavefunctions, meaning it
>> > could be at least as a option. Otherwise, such an often writing on 
>> > disk not only wastes too much time, but also leads to NFS crashing 
>> 
>> one should never use NFS-mounted filesystem for I/O. Use locally
>> mounted scratch disks, or a parallel file system (GPFS) if you have one. 
>> 
>> Also note that modern operating system tend to keep data in memory
>> as long as possible. Data to disk is actually written when no more RAM
>> for caching is available. 
>> 
>> Anyway: I agree that it is useful in many cases to keep everything 
>> in memory, but this requires some work 
>> 
>> Paolo
>> -- 
>> Paolo Giannozzi             e-mail:  giannozz at nest.sns.it
>> Scuola Normale Superiore    Phone:   +39/050-509876, Fax:-563513 
>> Piazza dei Cavalieri 7      I-56126 Pisa, Italy
>> _______________________________________________
>> 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
 


################################
Derek Stewart, Ph. D.
Scientific Computation Associate
250 Duffield Hall
Cornell Nanoscale Facility (CNF)
Ithaca, NY 14853
stewart (at) cnf.cornell.edu
(607) 255-2856 



From sodovar at gmail.com  Wed Apr  5 16:16:55 2006
From: sodovar at gmail.com (Ruslan Minibaev)
Date: Wed, 5 Apr 2006 18:16:55 +0400
Subject: [Pw_forum] How can I get the potential value in the middle of the vacuum layer?
In-Reply-To: <f530cbd10604050705s21c4a6f2h38b2147473fbd4cf@mail.gmail.com>
References: <f530cbd10604050705s21c4a6f2h38b2147473fbd4cf@mail.gmail.com>
Message-ID: <f530cbd10604050716y45607541q3d630ae4fea746f8@mail.gmail.com>

Hello, All!
I'm a new user of PWSCF and I use 2.1.5 version. To obtain
workfunction of a material i perform slab calculation. What should i
do to obtain the potential value in the middle of the vacuum layer?

Thanks


From Giovanni.Cantele at na.infn.it  Wed Apr  5 16:36:07 2006
From: Giovanni.Cantele at na.infn.it (Giovanni Cantele)
Date: Wed, 5 Apr 2006 16:36:07 +0200
Subject: [Pw_forum] How can I get the potential value in the middle of the vacuum layer?
In-Reply-To: <f530cbd10604050716y45607541q3d630ae4fea746f8@mail.gmail.com>
References: <f530cbd10604050705s21c4a6f2h38b2147473fbd4cf@mail.gmail.com> <f530cbd10604050716y45607541q3d630ae4fea746f8@mail.gmail.com>
Message-ID: <200604051636.07444.Giovanni.Cantele@na.infn.it>

On Wednesday 05 April 2006 16:16, Ruslan Minibaev wrote:
> Hello, All!
> I'm a new user of PWSCF and I use 2.1.5 version. To obtain
> workfunction of a material i perform slab calculation. What should i
> do to obtain the potential value in the middle of the vacuum layer?

One possibility is that of a planar average of the three-dimensional potential 
on planes parallel to the surface.
You should first obtain the post-processed potential using pp.x (see 
Doc/INPUT_PP)
Next, you can use PP/average.x (see the header of PP/average.f90 for a 
description of the output).
You can make both the planar average and a macroscopic average with an 
averaging window given in input.
The output is a one dimensional averaged potential.

Giovanni

-- 




Dr. Giovanni Cantele
Coherentia CNR-INFM and Dipartimento di Scienze Fisiche
Universita' di Napoli "Federico II"
Complesso Universitario di Monte S. Angelo - Ed. G
Via Cintia, I-80126, Napoli, Italy
Phone: +39 081 676910
Fax:   +39 081 676346
E-mail: Giovanni.Cantele at na.infn.it
Web: http://people.na.infn.it/~cantele


From lanhaiping at gmail.com  Wed Apr  5 17:40:33 2006
From: lanhaiping at gmail.com (lan haiping)
Date: Wed, 5 Apr 2006 23:40:33 +0800
Subject: [Pw_forum] Problem about running examples/example05
Message-ID: <c92002fa0604050840u658bd88epa32a23ef14e012a9@mail.gmail.com>

Dear All,

   I have run examples/example05 , and counld not complet successfully.
I then checked the script of run_example and results,  found that the file,
si.rho.dat , was in  the
bin/ .  Most of errors are related to the absence of this file.

     So , i would like to know  how to specify this file's location in the
PWSCF' input.
Any hint , i will appreciate !


      Best,wishes

 Hai-Ping
-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/attachments/20060405/53ad69ac/attachment.htm 

From giannozz at nest.sns.it  Wed Apr  5 17:46:26 2006
From: giannozz at nest.sns.it (Paolo Giannozzi)
Date: Wed, 5 Apr 2006 17:46:26 +0200
Subject: [Pw_forum] Problem about running examples/example05
In-Reply-To: <c92002fa0604050840u658bd88epa32a23ef14e012a9@mail.gmail.com>
References: <c92002fa0604050840u658bd88epa32a23ef14e012a9@mail.gmail.com>
Message-ID: <200604051746.26675.giannozz@nest.sns.it>

On Wednesday 05 April 2006 17:40, lan haiping wrote:

>    I have run examples/example05 , and counld not complet successfully.
> I then checked the script of run_example and results,  found that the file,
> si.rho.dat , was in  the bin/ .  Most of errors are related to the absence
> of this file. 
>
>      So , i would like to know  how to specify this file's location in the
> PWSCF' input.

is the following paragraph in the users'guide relevant to your case?
-----------------------------------------------------------
\paragraph{Why are codes in PP/ complaining that they do not
find some files?}

For Linux PC clusters in parallel execution: in at least some
versions of MPICH, the current directory is set to the directory where
the \emph{executable code} resides, instead of being set to the
directory where the code is executed.
This MPICH weirdness may cause unexpected failures in some
postprocessing codes that expect a data file in the current directory.
Workaround: use symbolic links, or copy the executable to the current
directory.
-----------------------------------------------------------
Paolo
-- 
Paolo Giannozzi             e-mail:  giannozz at nest.sns.it
Scuola Normale Superiore    Phone:   +39/050-509876, Fax:-563513 
Piazza dei Cavalieri 7      I-56126 Pisa, Italy


From giannozz at nest.sns.it  Wed Apr  5 18:00:23 2006
From: giannozz at nest.sns.it (Paolo Giannozzi)
Date: Wed, 5 Apr 2006 18:00:23 +0200
Subject: [Pw_forum] Reading "rho" file
In-Reply-To: <4433C545.000008.01622@tide.yandex.ru>
References: <4433C545.000008.01622@tide.yandex.ru>
Message-ID: <200604051800.23292.giannozz@nest.sns.it>

On Wednesday 05 April 2006 15:25, Sergey Lisenkov wrote:

> I found, that this problem does not appear when I change ecutwfc
> and use startingpot='file'. But this problem appears if I change
> ecutrho  and use startingpot='file'.
>
> Sergey
>
> >>quite possible, but why do you want to restart from the potential on
> >> file? If you perform a dynamics run, extrapolation of the potential from
> >> preceding steps should be done automatically.
> >
> >  I wanted, but if I am not mistaken, there are two cases:
> >
> >1) restart_mode='restart' , which will read .save file
> >
> >2) startingpot='file', which should read rho/pot file.
> >
> >I tried both of them, but the code always try to read "rho" file, which
> > was unsuccesfull. So, only the case is the start from the scratch...
> >
> > Sergey
>
> _______________________________________________
> Pw_forum mailing list
> Pw_forum at pwscf.org
> http://www.democritos.it/mailman/listinfo/pw_forum

-- 
Paolo Giannozzi             e-mail:  giannozz at nest.sns.it
Scuola Normale Superiore    Phone:   +39/050-509876, Fax:-563513 
Piazza dei Cavalieri 7      I-56126 Pisa, Italy


From giannozz at nest.sns.it  Wed Apr  5 18:02:59 2006
From: giannozz at nest.sns.it (Paolo Giannozzi)
Date: Wed, 5 Apr 2006 18:02:59 +0200
Subject: [Pw_forum] Reading "rho" file
In-Reply-To: <4433C545.000008.01622@tide.yandex.ru>
References: <4433C545.000008.01622@tide.yandex.ru>
Message-ID: <200604051802.59185.giannozz@nest.sns.it>

On Wednesday 05 April 2006 15:25, Sergey Lisenkov wrote:

>  found, that this problem does not appear when I change ecutwfc
>  and use startingpot='file'. But this problem appears if I change 
>  ecutrho  and use startingpot='file'.

you cannot do this: the expected size of the file will be different
from what is read

P.
-- 
Paolo Giannozzi             e-mail:  giannozz at nest.sns.it
Scuola Normale Superiore    Phone:   +39/050-509876, Fax:-563513 
Piazza dei Cavalieri 7      I-56126 Pisa, Italy


From marzari at MIT.EDU  Wed Apr  5 18:11:37 2006
From: marzari at MIT.EDU (Nicola Marzari)
Date: Wed, 05 Apr 2006 12:11:37 -0400
Subject: [Pw_forum] How can I get the potential value in the middle of
 the vacuum layer?
In-Reply-To: <200604051636.07444.Giovanni.Cantele@na.infn.it>
References: <f530cbd10604050705s21c4a6f2h38b2147473fbd4cf@mail.gmail.com> <f530cbd10604050716y45607541q3d630ae4fea746f8@mail.gmail.com> <200604051636.07444.Giovanni.Cantele@na.infn.it>
Message-ID: <4433EC39.2090607@mit.edu>

Dear Ruslan,

you might want to give a close look to the
PhD thesis of Caspar Fall (using pwscf) - all the issues
are discussed in great clarity and detail:

http://library.epfl.ch/theses/?nr=1955


				nicola



> On Wednesday 05 April 2006 16:16, Ruslan Minibaev wrote:
> 
>>Hello, All!
>>I'm a new user of PWSCF and I use 2.1.5 version. To obtain
>>workfunction of a material i perform slab calculation. What should i
>>do to obtain the potential value in the middle of the vacuum layer?
> 

-- 
---------------------------------------------------------------------
Prof Nicola Marzari   Department of Materials Science and Engineering
13-5066   MIT   77 Massachusetts Avenue   Cambridge MA 02139-4307 USA
tel 617.4522758 fax 2586534 marzari at mit.edu http://quasiamore.mit.edu


From proffess at yandex.ru  Wed Apr  5 21:50:51 2006
From: proffess at yandex.ru (Sergey Lisenkov)
Date: Wed, 5 Apr 2006 23:50:51 +0400 (MSD)
Subject: [Pw_forum] "internal error, cannot braket Ef" in cvs version
Message-ID: <44341F9B.000001.23577@pantene.yandex.ru>

 Dear authors,

 I tried to run the job using lastest CVS version of pwscf, but the execution failed with the error:

.....
atom  8  spin  2
eigenvalues:  0.2000000 0.2000000 0.2000000 0.2000000 0.2000000
 eigenvectors
 1   1.0000000  0.0000000  0.0000000  0.0000000  0.0000000
 2   0.0000000  1.0000000  0.0000000  0.0000000  0.0000000
 3   0.0000000  0.0000000  1.0000000  0.0000000  0.0000000
 4   0.0000000  0.0000000  0.0000000  1.0000000  0.0000000
 5   0.0000000  0.0000000  0.0000000  0.0000000  1.0000000
 occupations
 0.200  0.000  0.000  0.000  0.000
 0.000  0.200  0.000  0.000  0.000
 0.000  0.000  0.200  0.000  0.000
 0.000  0.000  0.000  0.200  0.000
 0.000  0.000  0.000  0.000  0.200
nsum =  48.0000000
 exit write_ns
 Atomic wfc used for LDA+U Projector are NOT orthogonalized
     Starting wfc are atomic

     total cpu time spent up to now is     23.15 secs

     Self-consistent Calculation

     iteration #  1     ecut=    40.00 ryd     beta=0.10
     CG style diagonalization
     ethr =  1.00E-05,  avg # of iterations =  2.1

 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
     from efermig : error #         1
     internal error, cannot braket Ef
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

 I've read the stuff about this error. Version 3.0 works fine for this job. Also this CVS version does not read .rho file (3.0 does). The test job is:

&control
    calculation  = 'scf'
    restart_mode='from_scratch'
    prefix='iron'
    pseudo_dir    = './'
  /
 &system
    ibrav=0, celldm(1)=5.42,
    nat=8, ntyp=3,
    ecutwfc =  40.0,
    ecutrho = 420.0,
    nspin = 2,
    starting_magnetization(1)= 0.7,
    starting_magnetization(2)= 0.7,
    starting_magnetization(3)= 0.7,
    occupations='smearing', smearing='mp', degauss=0.005,
    lda_plus_u=.true.,
    Hubbard_U(1)=1.d-40, Hubbard_alpha(1)=1.d-40,
    Hubbard_U(2)=1.d-40, Hubbard_alpha(2)=1.d-40,
    Hubbard_U(3)=1.d-40, Hubbard_alpha(3)=1.d-40,
    nbnd = 44
 /
 &electrons
    conv_thr         = 1.0d-10,
    mixing_beta      = 0.1,
    diagonalization  = 'cg'
    electron_maxstep = 1000
    diago_cg_maxiter = 200
    mixing_ndim      = 16
    startingpot      = 'file'
/
ATOMIC_SPECIES
  Fe1  55.845     Fe.pz-nd-rrkjus.UPF
  Fe2  55.845     Fe.pz-nd-rrkjus.UPF
  Fe3  55.845     Fe.pz-nd-rrkjus.UPF
ATOMIC_POSITIONS
 Fe1  0.00  0.00  0.00
 Fe2 -0.50  0.50  0.50
 Fe2  0.50 -0.50  0.50
 Fe2  0.50  0.50 -0.50
 Fe2  0.50  0.50  0.50
 Fe3  0.00  0.00  1.00
 Fe3  0.00  1.00  0.00
 Fe3  1.00  0.00  0.00
K_POINTS {automatic}
  8  8  8  1 1 1
CELL_PARAMETERS
-1.0  1.0  1.0
 1.0 -1.0  1.0
 1.0  1.0 -1.0

  Sergey


From hqzhou at nju.edu.cn  Thu Apr  6 08:12:37 2006
From: hqzhou at nju.edu.cn (Huiqun Zhou)
Date: Thu, 6 Apr 2006 14:12:37 +0800
Subject: [Pw_forum] Parallel version and NFS
References: <1863840659.20060404120939@tut.by> <200604041357.49771.giannozz@nest.sns.it> <1527535003.20060404172641@tut.by> <200604042244.04734.giannozz@nest.sns.it> <9510607031.20060405145441@tut.by>
Message-ID: <020a01c65941$1a9b75e0$1d00a8c0@solarflare>

For convergency problem, you can try to set mixing_beta to a smaller value, 
say 0.2.
Then you need check if your ecutwfc and ecutrho need to be set to higher 
values.

Huiqun Zhou

----- Original Message ----- 
From: <sir_puding at tut.by>
To: "Paolo Giannozzi" <pw_forum at pwscf.org>
Sent: Wednesday, April 05, 2006 7:54 PM
Subject: Re[2]: [Pw_forum] Parallel version and NFS


>> I cannot believe that your system has no local scratch filesystem!
> It has, But there is no guarantee that local /tmp has enough  space on
> every node. So, i need to use my /home/lds HDD. (Now I'm using simple
> test-cluster which is used by many people before extensive calculations
> on serious machine)
>
>> please provide the input that produces this problem
> I thought that there is no any difference between 'from scratch' and
> 'restart' modes when there is no any files from previous calculation.
> In output program writes 'save not found, using input configuration',
> same for potential and wavefunctions.
> For me it  means that calculation goes 'from_scratch'.
>
> Anyway, I've started calculations right, 'from_scratch', with
> potential from atoms superposition and the same for wfc, and using
> local temp dir,  but problem with convergence in first iteration still 
> exists.
>
> Sergey
>
> my old input
> --------
> &CONTROL
>                 calculation = 'vc-relax' ,
>                restart_mode = 'restart' ,
>                  wf_collect = .true. ,
>                      outdir = '/home/lds/tmp/' ,
>                  pseudo_dir = '/home/lds/espresso/pseudo/' ,
>                      prefix = 'silicon' ,
>                     disk_io = 'default' ,
>                   verbosity = 'default' ,
>               etot_conv_thr = 1.D-6 ,
>               forc_conv_thr = 1.D-6 ,
>                       nstep = 30 ,
>                     tstress = .true. ,
>                     tprnfor = .true. ,
>                          dt = 50 ,
> /
> &SYSTEM
>                       ibrav = 0,
>                   celldm(1) = 13.4834,
>                         nat = 64,
>                        ntyp = 2,
>                     ecutwfc = 30 ,
>                       nosym = .true. ,
>                        nbnd = 300,
>                       nelec = 257,
>                 occupations = 'tetrahedra' ,
>                       nspin = 1 ,
> /
> &ELECTRONS
>                    conv_thr = 1.0d-8 ,
>                 startingpot = 'file' ,
>                 startingwfc = 'file' ,
>                 mixing_mode = 'plain' ,
>                 mixing_beta = 0.7 ,
>             diagonalization = 'david' ,
> /
> &IONS
>                ion_dynamics = 'damp' ,
> /
> &CELL
>               cell_dynamics = 'damp-pr' ,
> /
> CELL_PARAMETERS alat
>     1.001284827    0.002853981    0.002846682
>     0.002853985    1.001308791    0.002853985
>     0.002846682    0.002853981    1.001284827
> ATOMIC_SPECIES
>    C   12.01078  C.pbe-rrkjus.UPF
>    N   14.00675  N.pbe-rrkjus.UPF
> ATOMIC_POSITIONS alat
>    C     -0.000411174   -0.000204767   -0.000411174
>    C      0.002098331    0.002221908    0.500932170
>    C     -0.000045859    0.250580894    0.250457544
>    C      0.002219314    0.252923640    0.750880737
>    C      0.002109330    0.501077678    0.002109331
>    C      0.001767192    0.501795146    0.501650854
>    C      0.002186471    0.751016286    0.252798804
>    C      0.005447910    0.753580185    0.753419772
>    C      0.125108721    0.125251176    0.125108721
>    C      0.126543635    0.126666058    0.625869486
>    C      0.125324871    0.375989285    0.375861475
>    C      0.128972956    0.378221350    0.876231944
>    C      0.126537116    0.626028922    0.126537116
>    C      0.128722812    0.627568057    0.627379082
>    C      0.128970236    0.876359204    0.378078334
>    C      0.130887959    0.878902709    0.878695675
>    C      0.250439611    0.000061706    0.250439611
>    C      0.252807018    0.002343198    0.750849658
>    C      0.250457543    0.250580894   -0.000045859
>    C      0.249832391    0.249950783    0.500836235
>    C      0.249831988    0.500975286    0.249831988
>    C      0.255023896    0.504124094    0.750606158
>    C      0.252798803    0.751016286    0.002186471
>    C      0.255037561    0.750757592    0.503984572
>    C      0.375856435    0.125431490    0.375856435
>    C      0.378088203    0.129097780    0.876235649
>    C      0.375861474    0.375989285    0.125324871
>    C      0.375437799    0.375557771    0.622013549
>    C      0.375445558    0.622149847    0.375445558
>    C      0.380886166    0.629192100    0.877632827
>    C      0.378078334    0.876359204    0.128970236
>    C      0.380897096    0.877778485    0.629053129
>    C      0.500932169    0.002221908    0.002098332
>    C      0.501653977    0.001878686    0.501653977
>    C      0.500836235    0.249950783    0.249832392
>    C      0.503997539    0.255156665    0.750631256
>    C      0.501650854    0.501795146    0.001767192
>    N      0.486107094    0.486200194    0.486107094
>    C      0.503984572    0.750757592    0.255037561
>    C      0.508233521    0.756508940    0.756374101
>    C      0.625869485    0.126666058    0.126543636
>    C      0.627425583    0.128878572    0.627425584
>    C      0.622013549    0.375557771    0.375437800
>    C      0.629059253    0.381018969    0.877650922
>    C      0.627379082    0.627568058    0.128722812
>    C      0.648656738    0.648807613    0.648656738
>    C      0.629053128    0.877778485    0.380897097
>    C      0.630868728    0.882939575    0.882796189
>    C      0.750849657    0.002343198    0.252807018
>    C      0.753422309    0.005560609    0.753422310
>    C      0.750880737    0.252923640    0.002219315
>    C      0.750631256    0.255156665    0.503997539
>    C      0.750606157    0.504124094    0.255023897
>    C      0.756381813    0.508368160    0.756381814
>    C      0.753419771    0.753580185    0.005447910
>    C      0.756374101    0.756508940    0.508233522
>    C      0.876235649    0.129097780    0.378088203
>    C      0.878717335    0.130994359    0.878717336
>    C      0.876231943    0.378221351    0.128972956
>    C      0.877650922    0.381018969    0.629059253
>    C      0.877632827    0.629192100    0.380886166
>    C      0.882799518    0.631017191    0.882799519
>    C      0.878695675    0.878902709    0.130887959
>    C      0.882796188    0.882939575    0.630868729
> K_POINTS automatic
>  4 4 4   1 1 1
> ---------------
> --
> Please avoid sending me Word or PowerPoint attachments.
> See http://www.gnu.org/philosophy/no-word-attachments.html
>
> _______________________________________________
> Pw_forum mailing list
> Pw_forum at pwscf.org
> http://www.democritos.it/mailman/listinfo/pw_forum
>
> 



From giannozz at nest.sns.it  Thu Apr  6 15:15:38 2006
From: giannozz at nest.sns.it (Paolo Giannozzi)
Date: Thu, 6 Apr 2006 15:15:38 +0200
Subject: [Pw_forum] Parallel version and NFS
In-Reply-To: <9510607031.20060405145441@tut.by>
References: <1863840659.20060404120939@tut.by> <200604042244.04734.giannozz@nest.sns.it> <9510607031.20060405145441@tut.by>
Message-ID: <200604061515.38669.giannozz@nest.sns.it>

On Wednesday 05 April 2006 13:54, sir_puding at tut.by wrote:

> my old input
>                         nbnd = 300,
>                        nelec = 257,

300 bands for 257 electrons in a spin-unpolarized system?
that's a lot (the code estimates 155, and it is already more 
than really needed). High-energy states are always slower 
to converge.

P.
-- 
Paolo Giannozzi             e-mail:  giannozz at nest.sns.it
Scuola Normale Superiore    Phone:   +39/050-509876, Fax:-563513 
Piazza dei Cavalieri 7      I-56126 Pisa, Italy


From reboredofa at ornl.gov  Thu Apr  6 15:57:12 2006
From: reboredofa at ornl.gov (Fernando A Reboredo)
Date: Thu, 06 Apr 2006 09:57:12 -0400
Subject: [Pw_forum] pw2casino question
Message-ID: <008b01c65982$01812820$b7305ba0@ornl.gov>

Greetings!
I would like to know if it its physically meaningful to run pw2casino with wavefunctions generated with Vanderbilt ultrasoft pseudopotentials. At first sight it seams norm conserving pseudo is the only safe option for pw2casino  However, in order to avoid contributing to global warming I would prefer to use ultrasofts. Who would be the proper person to ask?
Fernando Reboredo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/attachments/20060406/7bccd1af/attachment.htm 

From sir_puding at tut.by  Thu Apr  6 16:58:25 2006
From: sir_puding at tut.by (sir_puding at tut.by)
Date: Thu, 6 Apr 2006 17:58:25 +0300
Subject: [Pw_forum] Parallel version and NFS
In-Reply-To: <200604061515.38669.giannozz@nest.sns.it>
References: <1863840659.20060404120939@tut.by> <200604042244.04734.giannozz@nest.sns.it> <9510607031.20060405145441@tut.by> <200604061515.38669.giannozz@nest.sns.it>
Message-ID: <1681139738.20060406175825@tut.by>

> 300 bands for 257 electrons in a spin-unpolarized system?
> that's a lot (the code estimates 155, and it is already more 
> than really needed). High-energy states are always slower 
> to converge.

Thanx alot!!!
I'm sorry for disturbing the forum with RTFM questions.


Sergey

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



From hsd22 at hermes.cam.ac.uk  Thu Apr  6 17:23:07 2006
From: hsd22 at hermes.cam.ac.uk (H.S.Domingos)
Date: Thu, 6 Apr 2006 16:23:07 +0100 (BST)
Subject: [Pw_forum] (no subject)
Message-ID: <Pine.LNX.4.64.0604061617500.19522@hermes-1.csi.cam.ac.uk>

I am sorry to disturb again with something that might be too obvious to 
bother you.
I have this message at the start of the second dynamics iteration run:

     from checkallsym : error #         3
      not orthogonal operation
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

can you help me with this ?

best regards,

Helder



=======================================================================
|  Dr. Helder S. Domingos                                             |
|                                                                     |
| INESC Microsyst & Nanotechnol, Lisbon, P-1000 Portugal              |
| and                                                                 |
| R&D unit for  Molecular Chemical Physics                            |
| Chemistry Department, University of Coimbra                         |
=======================================================================



From giannozz at nest.sns.it  Thu Apr  6 17:56:14 2006
From: giannozz at nest.sns.it (Paolo Giannozzi)
Date: Thu, 6 Apr 2006 17:56:14 +0200
Subject: [Pw_forum] (no subject)
In-Reply-To: <Pine.LNX.4.64.0604061617500.19522@hermes-1.csi.cam.ac.uk>
References: <Pine.LNX.4.64.0604061617500.19522@hermes-1.csi.cam.ac.uk>
Message-ID: <200604061756.14091.giannozz@nest.sns.it>

On Thursday 06 April 2006 17:23, H.S.Domingos wrote:

> I have this message at the start of the second dynamics iteration run:
>
>      from checkallsym : error #         3
>       not orthogonal operation

see
http://www.democritos.it/pipermail/pw_forum/2006-January/003467.html

-- 
Paolo Giannozzi             e-mail:  giannozz at nest.sns.it
Scuola Normale Superiore    Phone:   +39/050-509876, Fax:-563513 
Piazza dei Cavalieri 7      I-56126 Pisa, Italy


From giannozz at nest.sns.it  Thu Apr  6 18:43:44 2006
From: giannozz at nest.sns.it (Paolo Giannozzi)
Date: Thu, 6 Apr 2006 18:43:44 +0200
Subject: [Pw_forum] "internal error, cannot braket Ef" in cvs version
In-Reply-To: <44341F9B.000001.23577@pantene.yandex.ru>
References: <44341F9B.000001.23577@pantene.yandex.ru>
Message-ID: <200604061843.44328.giannozz@nest.sns.it>

On Wednesday 05 April 2006 21:50, Sergey Lisenkov wrote:

>      from efermig : error #         1
>      internal error, cannot braket Ef

it works for me (on one processor)

> Also this CVS version does not read .rho file (3.0 does)

the  CVS version reads the charge density from a different file

Paolo
-- 
Paolo Giannozzi             e-mail:  giannozz at nest.sns.it
Scuola Normale Superiore    Phone:   +39/050-509876, Fax:-563513 
Piazza dei Cavalieri 7      I-56126 Pisa, Italy


From giannozz at nest.sns.it  Thu Apr  6 18:56:06 2006
From: giannozz at nest.sns.it (Paolo Giannozzi)
Date: Thu, 6 Apr 2006 18:56:06 +0200
Subject: [Pw_forum] Problem with compilation
In-Reply-To: <c3ed08160604040730k3d480948udd2eb4b25ca5a70c@mail.gmail.com>
References: <c3ed08160604040730k3d480948udd2eb4b25ca5a70c@mail.gmail.com>
Message-ID: <200604061856.06521.giannozz@nest.sns.it>

On Tuesday 04 April 2006 16:30, Pavel B. Sorokin wrote:

> I have tried to calculate PWSCF3.0 on IBM PowerPC under Linux.

apparently you have xlf installed. Edit you make.sys to use xlf syntax 
(see for instance Make.ibm, Make.ibmsp in install/) . Start with the 
simplest configuration you can: serial compilation, no external library,
use internal FFTW and internal blas and lapack:
CPPFLAGS     = -D__FFTW,-D__USE_INTERNAL_FFTW,...
MYLIB        = blas_and_lapack
If you have a weird machine that is not supported, you have close
to zero probability to compile quantum-espresso (or any other large 
package) by just trying at random. 

Paolo
-- 
Paolo Giannozzi             e-mail:  giannozz at nest.sns.it
Scuola Normale Superiore    Phone:   +39/050-509876, Fax:-563513 
Piazza dei Cavalieri 7      I-56126 Pisa, Italy


From proffess at yandex.ru  Thu Apr  6 19:36:26 2006
From: proffess at yandex.ru (Sergey Lisenkov)
Date: Thu, 6 Apr 2006 21:36:26 +0400 (MSD)
Subject: [Pw_forum] "internal error, cannot braket Ef" in cvs version
In-Reply-To: <200604061843.44328.giannozz@nest.sns.it>
References: <44341F9B.000001.23577@pantene.yandex.ru> <200604061843.44328.giannozz@nest.sns.it>
Message-ID: <4435519A.000004.00410@webmail9.yandex.ru>

 Dear Paolo,

>>      from efermig : error #         1
>>      internal error, cannot braket Ef
>
>it works for me (on one processor)

  I tried to run on 8 CPUs, and it was failed.

Sergey


From proffess at yandex.ru  Thu Apr  6 19:38:43 2006
From: proffess at yandex.ru (Sergey Lisenkov)
Date: Thu, 6 Apr 2006 21:38:43 +0400 (MSD)
Subject: [Pw_forum] Problem with compilation
In-Reply-To: <200604061856.06521.giannozz@nest.sns.it>
References: <c3ed08160604040730k3d480948udd2eb4b25ca5a70c@mail.gmail.com> <200604061856.06521.giannozz@nest.sns.it>
Message-ID: <44355223.000003.07712@colgate.yandex.ru>

>On Tuesday 04 April 2006 16:30, Pavel B. Sorokin wrote:
>
>> I have tried to calculate PWSCF3.0 on IBM PowerPC under Linux.
>
....

>If you have a weird machine that is not supported, you have close
>to zero probability to compile quantum-espresso (or any other large 
>package) by just trying at random. 

  On this machine (because it is IBM-based machine) q-espresso works very well.

S.


From lyu7 at ncsu.edu  Fri Apr  7 04:10:51 2006
From: lyu7 at ncsu.edu (Liping YU)
Date: Thu, 06 Apr 2006 22:10:51 -0400
Subject: [Pw_forum] error on phonon calculation  (root not converged)
Message-ID: <4435CA2B.6080505@ncsu.edu>

Dear PWSCF users,
I am performing some calculation on phonons of SrTiO3 by using PWSCF
(ver3.0).
I run SCF first and then do PH.x at gamma point. The convergence in scf
calculation
was reached. However during PH.x, I got the message like
"kpoint 1 ibnd 81 solve_linter: root not converged 0.145E+30".
pls see the detail of this in the follwed output file (the first
occurance of this message
was highlighted). Thanks for your advice.

liping

================ input file for ph.x ===================
'2*2*1 cb srtio3'
&inputph
prefix = 'cb-st'
amass(1) = 87.620
amass(2) = 47.86700
amass(3) = 16.0
tr2_ph = 1e-18
trans = .true.
zue = .true.
epsil = .true.
fildyn = 'cb-st.221.dynG'
iverbosity = 1
outdir='./tmp/'
0.0 0.0 0.0

================ input file for scf ======================
&CONTROL
title = 'scf on cubic perovskite SrTiO3' ,
calculation = 'scf' ,
restart_mode = 'from_scratch' ,
outdir = './tmp/' ,
pseudo_dir = '../../pseudo/' ,
prefix = 'cb-st' ,
tstress = .true. ,
tprnfor = .true. ,
/
&SYSTEM
ibrav = 6,
celldm(1) = 14.55327346
celldm(3) = 0.5
nat = 20,
ntyp = 3,
ecutwfc = 30 ,
ecutrho = 270 ,
/
&ELECTRONS
conv_thr = 1.D-8 ,
/
ATOMIC_SPECIES
Sr 87.62000 038-Sr-ca-sp-vgrp.uspp.UPF
Ti 47.86700 022-Ti-ca-sp-vgrp.uspp.UPF
O 16.00000 008-O-ca--vgrp.uspp.UPF
ATOMIC_POSITIONS crystal
Sr 0.00 0.00 0.00
Sr 0.50 0.00 0.00
Sr 0.00 0.50 0.00
Sr 0.50 0.50 0.00
O 0.25 0.25 0.00
O 0.25 0.75 0.00
O 0.75 0.25 0.00
O 0.75 0.75 0.00
Ti 0.25 0.25 0.5
Ti 0.25 0.75 0.5
Ti 0.75 0.25 0.5
Ti 0.75 0.75 0.5
O 0.00 0.25 0.5
O 0.00 0.75 0.5
O 0.50 0.25 0.5
O 0.50 0.75 0.5
O 0.25 0.00 0.5
O 0.75 0.00 0.5
O 0.25 0.50 0.5
O 0.75 0.50 0.5
K_POINTS automatic
4 4 8 0 0 0

===================== output file of runing ph.x
============================== Program PHONON v.3.0 starts ...
Today is 5Apr2006 at 22: 2:27

Parallel version (MPI)

Number of processors in use: 32
K-points division: npool = 4
R & G space division: proc/pool = 8

Ultrasoft (Vanderbilt) Pseudopotentials

Reading file cb-st.save ... only dimensions
read complete

Reading file cb-st.save ... all except wavefuctions
read complete

Planes per process (thick) : nr3 = 40 npp = 5 ncplane = 6400

Planes per process (smooth): nr3s= 28 npps= 4 ncplanes= 3136

Proc/ planes cols G planes cols G columns G
Pool (dense grid) (smooth grid) (wavefct grid)
1 5 567 14421 4 253 4261 74 698
2 5 567 14421 4 254 4264 75 699
3 5 567 14421 4 253 4257 76 698
4 5 569 14421 4 253 4261 76 698
5 5 569 14421 3 253 4265 75 697
6 5 569 14421 3 253 4269 75 697
7 5 569 14421 3 253 4263 75 697
8 5 568 14420 3 253 4265 75 697
0 40 4545 115367 28 2025 34105 601 5581


nbndx = 80 nbnd = 80 natomwfc = 108 npwx = 542
nelec = 160.00 nkb = 240 ngl = 1003
autoval = -.5378E+01
Real(aut_vet)= ( 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000)
Real(aut_vet)= ( 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000)
Real(aut_vet)= ( 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000)
Real(aut_vet)= ( 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000)
.......
.......
.......
Imm(aut_vet)= ( 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000)
Imm(aut_vet)= ( 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000)
Imm(aut_vet)= ( 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000)
Imm(aut_vet)= ( 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000)
Imm(aut_vet)= ( 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000)

'2*2*1 cb srtio3'

crystal is

bravais-lattice index = 6
lattice parameter (a_0) = 14.5533 a.u.
unit-cell volume = 1541.1754 (a.u.)^3
number of atoms/cell = 20
number of atomic types = 3
kinetic-energy cut-off = 30.0000 Ry
charge density cut-off = 270.0000 Ry
convergence threshold = 1.0E-18
beta = 0.7000
number of iterations used = 4

celldm(1)= 14.55327 celldm(2)= 0.00000 celldm(3)= 0.50000
celldm(4)= 0.00000 celldm(5)= 0.00000 celldm(6)= 0.00000

crystal axes: (cart. coord. in units of a_0)
a(1) = ( 1.0000 0.0000 0.0000 )
a(2) = ( 0.0000 1.0000 0.0000 )
a(3) = ( 0.0000 0.0000 0.5000 )

reciprocal axes: (cart. coord. in units 2 pi/a_0)
b(1) = ( 1.0000 0.0000 0.0000 )
b(2) = ( 0.0000 1.0000 0.0000 )
b(3) = ( 0.0000 0.0000 2.0000 )


Atoms inside the unit cell:

Cartesian axes

site n. atom mass positions (a_0 units)
1 Sr 87.6200 tau( 1) = ( 0.00000 0.00000 0.00000 )
2 Sr 87.6200 tau( 2) = ( 0.50000 0.00000 0.00000 )
3 Sr 87.6200 tau( 3) = ( 0.00000 0.50000 0.00000 )
4 Sr 87.6200 tau( 4) = ( 0.50000 0.50000 0.00000 )
5 O 16.0000 tau( 5) = ( 0.25000 0.25000 0.00000 )
6 O 16.0000 tau( 6) = ( 0.25000 0.75000 0.00000 )
7 O 16.0000 tau( 7) = ( 0.75000 0.25000 0.00000 )
8 O 16.0000 tau( 8) = ( 0.75000 0.75000 0.00000 )
9 Ti 47.8670 tau( 9) = ( 0.25000 0.25000 0.25000 )
10 Ti 47.8670 tau(10) = ( 0.25000 0.75000 0.25000 )
11 Ti 47.8670 tau(11) = ( 0.75000 0.25000 0.25000 )
12 Ti 47.8670 tau(12) = ( 0.75000 0.75000 0.25000 )
13 O 16.0000 tau(13) = ( 0.00000 0.25000 0.25000 )
14 O 16.0000 tau(14) = ( 0.00000 0.75000 0.25000 )
15 O 16.0000 tau(15) = ( 0.50000 0.25000 0.25000 )
16 O 16.0000 tau(16) = ( 0.50000 0.75000 0.25000 )
17 O 16.0000 tau(17) = ( 0.25000 0.00000 0.25000 )
18 O 16.0000 tau(18) = ( 0.75000 0.00000 0.25000 )
19 O 16.0000 tau(19) = ( 0.25000 0.50000 0.25000 )
20 O 16.0000 tau(20) = ( 0.75000 0.50000 0.25000 )

Computing dynamical matrix for
q = ( 0.00000 0.00000 0.00000 )

17 Sym.Ops. (with q -> -q+G )

s frac. trans.

isym = 1 identity

cryst. s( 1) = ( 1 0 0 )
( 0 1 0 )
( 0 0 1 )

cart. s( 1) = ( 1.0000000 0.0000000 0.0000000 )
( 0.0000000 1.0000000 0.0000000 )
( 0.0000000 0.0000000 1.0000000 )
..........
..........

isym = 16 inv. 90 deg rotation - cart. axis [0,0,1]

cryst. s(16) = ( 0 -1 0 )
( 1 0 0 )
( 0 0 -1 )

cart. s(16) = ( 0.0000000 1.0000000 0.0000000 )
( -1.0000000 0.0000000 0.0000000 )
( 0.0000000 0.0000000 -1.0000000 )


This transformation sends q -> -q+G

isym = 17 identity

cryst. s(17) = ( 1 0 0 )
( 0 1 0 )
( 0 0 1 )

cart. s(17) = ( 1.0000000 0.0000000 0.0000000 )
( 0.0000000 1.0000000 0.0000000 )
( 0.0000000 0.0000000 1.0000000 )


G cutoff = 1448.5230 ( 14421 G-vectors) FFT grid: ( 80, 80, 40)
G cutoff = 643.7880 ( 4261 G-vectors) smooth grid: ( 56, 56, 28)
number of k points= 30
cart. coord. in units 2pi/a_0
k( 1) = ( 0.0000000 0.0000000 0.0000000), wk = 0.0156250
k( 2) = ( 0.0000000 0.0000000 0.2500000), wk = 0.0312500
k( 3) = ( 0.0000000 0.0000000 0.5000000), wk = 0.0312500
.......
.......
.......
k( 29) = ( -0.5000000 -0.5000000 0.3750000), wk = 0.0312500
k( 30) = ( -0.5000000 -0.5000000 -0.5000000), wk = 0.0156250

pseudo 1 is st (US) zval = 10.0 lmax= 2 lloc= 0
Version 0 0 0 of US pseudo code

Using log mesh of 883 points

The pseudopotential has 6 beta functions with:

l(1) = 0
l(2) = 0
l(3) = 1
l(4) = 1
l(5) = 2
l(6) = 2

Q(r) pseudized with 8 coefficients, rinner = 1.000 1.000 1.000
1.000 1.000

pseudo 2 is ti (US) zval = 12.0 lmax= 2 lloc= 0
Version 0 0 0 of US pseudo code

Using log mesh of 851 points

The pseudopotential has 6 beta functions with:

l(1) = 0
l(2) = 0
l(3) = 1
l(4) = 1
l(5) = 2
l(6) = 2

Q(r) pseudized with 5 coefficients, rinner = 1.000 1.000 1.000
1.000 1.000

pseudo 3 is ox (US) zval = 6.0 lmax= 1 lloc= 0
Version 0 0 0 of US pseudo code

Using log mesh of 737 points

The pseudopotential has 4 beta functions with:

l(1) = 0
l(2) = 0
l(3) = 1
l(4) = 1

Q(r) pseudized with 8 coefficients, rinner = 0.700 0.700 0.700

Atomic displacements:
There are 44 irreducible representations

Representation 1 1 modes - To be done
Phonon polarizations are as follows:
mode # 1
( 0.00000 0.00000 )
( 0.00000 0.00000 )
( 0.00000 0.00000 )
( 0.00000 0.00000 )
( 0.00000 0.00000 )
( 0.00000 0.00000 )
( 0.00000 0.00000 )
( 0.00000 0.00000 )
( 0.00000 0.00000 )
.....
.....
.....

( 0.00000 0.00000 )
( 0.00000 0.00000 )

Representation 44 1 modes - To be done
Phonon polarizations are as follows:

mode # 60
( 0.00000 0.00000 )
( 0.00000 0.00000 )
( 0.00000 0.00000 )
( 0.00000 0.00000 )
( 0.00000 0.00000 )
( 0.00000 0.00000 )
( 0.00000 0.00000 )
( 0.00000 0.00000 )
( 0.00000 0.00000 )
( 0.00000 0.00000 )
( 0.00000 0.00000 )
( 0.00000 0.00000 )
( 0.00000 0.00000 )
( 0.00000 0.00000 )
( 0.00000 0.00000 )
( 0.00000 0.00000 )
( 0.00000 0.00000 )
( 0.00000 0.00000 )
( 0.00000 0.00000 )
( 0.00000 0.00000 )
( 0.00000 0.00000 )
( 0.00000 0.00000 )
( 0.00000 0.00000 )
( 0.00000 0.00000 )
( 0.00000 0.00000 )
( 0.00000 0.00000 )
( 0.00000 0.00000 )
( 0.00000 0.00000 )
( 0.00000 0.00000 )
( 0.00000 0.00000 )
( 0.00000 0.00000 )
( 0.00000 0.00000 )
( 0.00000 0.00000 )
( 0.00000 0.00000 )
( 0.00000 0.00000 )
( 0.00000 0.00000 )
( 0.00000 0.00000 )
( 0.00000 0.00000 )
( 0.00000 0.00000 )
( 0.00000 0.00000 )
( 0.00000 0.00000 )
( 0.00000 0.00000 )
( 0.00000 0.00000 )
( 0.00000 0.00000 )
( -0.50000 0.00000 )
( 0.00000 0.00000 )
( 0.00000 0.00000 )
( -0.50000 0.00000 )
( 0.00000 0.00000 )
( 0.00000 0.00000 )
( 0.00000 0.00000 )
( 0.00000 0.00000 )
( 0.00000 0.00000 )
( 0.00000 0.00000 )
( 0.00000 0.00000 )
( 0.00000 0.00000 )
( -0.50000 0.00000 )
( 0.00000 0.00000 )
( 0.00000 0.00000 )
( -0.50000 0.00000 )
PHONON : 5m47.70s CPU time


Alpha used in Ewald sum = 2.3000

Electric Fields Calculation

iter # 1 total cpu time : 625.1 secs av.it.: 7.6
thresh= 0.100E-01 alpha_mix = 0.700 |ddv_scf|^2 = 0.708E-08

iter # 2 total cpu time : 748.8 secs av.it.: 15.3
thresh= 0.841E-05 alpha_mix = 0.700 |ddv_scf|^2 = 0.517E-09

iter # 3 total cpu time : 869.8 secs av.it.: 15.0
thresh= 0.227E-05 alpha_mix = 0.700 |ddv_scf|^2 = 0.128E-10

iter # 4 total cpu time : 995.4 secs av.it.: 15.6
thresh= 0.358E-06 alpha_mix = 0.700 |ddv_scf|^2 = 0.890E-12

iter # 5 total cpu time : 1122.9 secs av.it.: 16.0
thresh= 0.943E-07 alpha_mix = 0.700 |ddv_scf|^2 = 0.830E-13

iter # 6 total cpu time : 1252.7 secs av.it.: 16.7
thresh= 0.288E-07 alpha_mix = 0.700 |ddv_scf|^2 = 0.874E-13

iter # 7 total cpu time : 1362.9 secs av.it.: 13.9
thresh= 0.296E-07 alpha_mix = 0.700 |ddv_scf|^2 = 0.608E-14

iter # 8 total cpu time : 1484.7 secs av.it.: 15.6
thresh= 0.780E-08 alpha_mix = 0.700 |ddv_scf|^2 = 0.204E-13

iter # 9 total cpu time : 1594.0 secs av.it.: 13.9
thresh= 0.143E-07 alpha_mix = 0.700 |ddv_scf|^2 = 0.105E-15
/ *kpoint 3 ibnd 81 solve_e: root not converged 0.807E-08*
/
iter # 10 total cpu time : 1722.1 secs av.it.: 16.5
thresh= 0.102E-08 alpha_mix = 0.700 |ddv_scf|^2 = 0.108E-17

iter # 11 total cpu time : 1854.0 secs av.it.: 17.1
thresh= 0.104E-09 alpha_mix = 0.700 |ddv_scf|^2 = 0.770E-19

End of electric fields calculation

Dielectric constant in cartesian axis

( 222.132926158 0.000000000 0.000000000 )
( 0.000000000 222.132926158 0.000000000 )
( 0.000000000 0.000000000 6.253208593 )

Effective charges E-U in cartesian axis

atom 1
( 1.79803 0.00000 0.00000 )
( 0.00000 1.79803 0.00000 )
( 0.00000 0.00000 2.54009 )
atom 2
( 1.79803 0.00000 0.00000 )
( 0.00000 1.79803 0.00000 )
( 0.00000 0.00000 2.54009 )
atom 3
( 1.79803 0.00000 0.00000 )
( 0.00000 1.79803 0.00000 )
( 0.00000 0.00000 2.54009 )
atom 4
( 1.79803 0.00000 0.00000 )
( 0.00000 1.79803 0.00000 )
( 0.00000 0.00000 2.54009 )
atom 5
( -4.77021 0.00000 0.00000 )
( 0.00000 -4.77021 0.00000 )
( 0.00000 0.00000 -5.62276 )
atom 6
( -4.77021 0.00000 0.00000 )
( 0.00000 -4.77021 0.00000 )
( 0.00000 0.00000 -5.62276 )
atom 7
( -4.77021 0.00000 0.00000 )
( 0.00000 -4.77021 0.00000 )
( 0.00000 0.00000 -5.62276 )
atom 8
( -4.77021 0.00000 0.00000 )
( 0.00000 -4.77021 0.00000 )
( 0.00000 0.00000 -5.62276 )
atom 9
( 6.39976 0.00000 0.00000 )
( 0.00000 6.39976 0.00000 )
( 0.00000 0.00000 7.08723 )
atom 10
( 6.39976 0.00000 0.00000 )
( 0.00000 6.39976 0.00000 )
( 0.00000 0.00000 7.08723 )
atom 11
( 6.39976 0.00000 0.00000 )
( 0.00000 6.39976 0.00000 )
( 0.00000 0.00000 7.08723 )
atom 12
( 6.39976 0.00000 0.00000 )
( 0.00000 6.39976 0.00000 )
( 0.00000 0.00000 7.08723 )
atom 13
( -4.18260 0.00000 0.00000 )
( 0.00000 0.68680 0.00000 )
( 0.00000 0.00000 -2.01273 )
atom 14
( -4.18260 0.00000 0.00000 )
( 0.00000 0.68680 0.00000 )
( 0.00000 0.00000 -2.01273 )
atom 15
( -4.18260 0.00000 0.00000 )
( 0.00000 0.68680 0.00000 )
( 0.00000 0.00000 -2.01273 )
atom 16
( -4.18260 0.00000 0.00000 )
( 0.00000 0.68680 0.00000 )
( 0.00000 0.00000 -2.01273 )
atom 17
( 0.68680 0.00000 0.00000 )
( 0.00000 -4.18260 0.00000 )
( 0.00000 0.00000 -2.01273 )
atom 18
( 0.68680 0.00000 0.00000 )
( 0.00000 -4.18260 0.00000 )
( 0.00000 0.00000 -2.01273 )
atom 19
( 0.68680 0.00000 0.00000 )
( 0.00000 -4.18260 0.00000 )
( 0.00000 0.00000 -2.01273 )
atom 20
( 0.68680 0.00000 0.00000 )
( 0.00000 -4.18260 0.00000 )
( 0.00000 0.00000 -2.01273 )

Representation # 1 mode # 1

Self-consistent Calculation

iter # 1 total cpu time : 2878.9 secs av.it.: 6.6
thresh= 0.100E-01 alpha_mix = 0.700 |ddv_scf|^2 = 0.245E-06

iter # 2 total cpu time : 2919.2 secs av.it.: 14.8
thresh= 0.495E-04 alpha_mix = 0.700 |ddv_scf|^2 = 0.574E-08

iter # 3 total cpu time : 2959.2 secs av.it.: 14.9
thresh= 0.758E-05 alpha_mix = 0.700 |ddv_scf|^2 = 0.116E-09

iter # 4 total cpu time : 2998.0 secs av.it.: 14.1
thresh= 0.108E-05 alpha_mix = 0.700 |ddv_scf|^2 = 0.370E-12

iter # 5 total cpu time : 3038.5 secs av.it.: 15.2
thresh= 0.608E-07 alpha_mix = 0.700 |ddv_scf|^2 = 0.389E-14

iter # 6 total cpu time : 3079.0 secs av.it.: 15.0
thresh= 0.624E-08 alpha_mix = 0.700 |ddv_scf|^2 = 0.584E-16

iter # 7 total cpu time : 3118.2 secs av.it.: 14.6
thresh= 0.764E-09 alpha_mix = 0.700 |ddv_scf|^2 = 0.780E-18

End of self-consistent calculation

Convergence has been achieved


Representation # 2 mode # 2

Self-consistent Calculation

iter # 1 total cpu time : 3152.7 secs av.it.: 5.8
thresh= 0.100E-01 alpha_mix = 0.700 |ddv_scf|^2 = 0.365E-06

iter # 2 total cpu time : 3191.0 secs av.it.: 13.9
thresh= 0.604E-04 alpha_mix = 0.700 |ddv_scf|^2 = 0.513E-07

iter # 3 total cpu time : 3229.0 secs av.it.: 13.9
thresh= 0.227E-04 alpha_mix = 0.700 |ddv_scf|^2 = 0.409E-09

iter # 4 total cpu time : 3267.5 secs av.it.: 14.2
thresh= 0.202E-05 alpha_mix = 0.700 |ddv_scf|^2 = 0.607E-11

iter # 5 total cpu time : 3305.6 secs av.it.: 14.1
thresh= 0.246E-06 alpha_mix = 0.700 |ddv_scf|^2 = 0.917E-13

iter # 6 total cpu time : 3344.4 secs av.it.: 14.4
thresh= 0.303E-07 alpha_mix = 0.700 |ddv_scf|^2 = 0.712E-15

iter # 7 total cpu time : 3384.1 secs av.it.: 14.9
thresh= 0.267E-08 alpha_mix = 0.700 |ddv_scf|^2 = 0.291E-16

iter # 8 total cpu time : 3424.8 secs av.it.: 15.1
thresh= 0.539E-09 alpha_mix = 0.700 |ddv_scf|^2 = 0.437E-18

End of self-consistent calculation

Convergence has been achieved


Representation # 3 modes # 3 4

Self-consistent Calculation

iter # 1 total cpu time : 3482.5 secs av.it.: 6.4
thresh= 0.100E-01 alpha_mix = 0.700 |ddv_scf|^2 = 0.712E-07

iter # 2 total cpu time : 3565.4 secs av.it.: 16.1
thresh= 0.267E-04 alpha_mix = 0.700 |ddv_scf|^2 = 0.222E-08

iter # 3 total cpu time : 3648.9 secs av.it.: 16.2
thresh= 0.472E-05 alpha_mix = 0.700 |ddv_scf|^2 = 0.622E-10

iter # 4 total cpu time : 3731.5 secs av.it.: 15.9
thresh= 0.789E-06 alpha_mix = 0.700 |ddv_scf|^2 = 0.409E-12

iter # 5 total cpu time : 3815.6 secs av.it.: 16.3
thresh= 0.639E-07 alpha_mix = 0.700 |ddv_scf|^2 = 0.182E-14

iter # 6 total cpu time : 3898.9 secs av.it.: 16.1
thresh= 0.426E-08 alpha_mix = 0.700 |ddv_scf|^2 = 0.557E-16

iter # 7 total cpu time : 3980.1 secs av.it.: 15.7
thresh= 0.747E-09 alpha_mix = 0.700 |ddv_scf|^2 = 0.173E-18

End of self-consistent calculation

Convergence has been achieved


Representation # 4 modes # 5 6

Self-consistent Calculation

iter # 1 total cpu time : 4049.7 secs av.it.: 6.4
thresh= 0.100E-01 alpha_mix = 0.700 |ddv_scf|^2 = 0.712E-07

iter # 2 total cpu time : 4133.1 secs av.it.: 16.2
thresh= 0.267E-04 alpha_mix = 0.700 |ddv_scf|^2 = 0.222E-08

iter # 3 total cpu time : 4217.1 secs av.it.: 16.3
thresh= 0.472E-05 alpha_mix = 0.700 |ddv_scf|^2 = 0.622E-10

iter # 4 total cpu time : 4299.8 secs av.it.: 16.0
thresh= 0.789E-06 alpha_mix = 0.700 |ddv_scf|^2 = 0.409E-12

iter # 5 total cpu time : 4384.5 secs av.it.: 16.4
thresh= 0.639E-07 alpha_mix = 0.700 |ddv_scf|^2 = 0.182E-14

iter # 6 total cpu time : 4468.5 secs av.it.: 16.1
thresh= 0.426E-08 alpha_mix = 0.700 |ddv_scf|^2 = 0.557E-16

iter # 7 total cpu time : 4550.2 secs av.it.: 15.8
thresh= 0.747E-09 alpha_mix = 0.700 |ddv_scf|^2 = 0.173E-18

End of self-consistent calculation

Convergence has been achieved


Representation # 5 mode # 7

Self-consistent Calculation

iter # 1 total cpu time : 4603.5 secs av.it.: 7.7
thresh= 0.100E-01 alpha_mix = 0.700 |ddv_scf|^2 = 0.158E-05

iter # 2 total cpu time : 4641.8 secs av.it.: 13.9
thresh= 0.126E-03 alpha_mix = 0.700 |ddv_scf|^2 = 0.423E-06

iter # 3 total cpu time : 4678.2 secs av.it.: 13.4
thresh= 0.650E-04 alpha_mix = 0.700 |ddv_scf|^2 = 0.467E-09

iter # 4 total cpu time : 4716.8 secs av.it.: 14.4
thresh= 0.216E-05 alpha_mix = 0.700 |ddv_scf|^2 = 0.128E-10

iter # 5 total cpu time : 4754.8 secs av.it.: 14.1
thresh= 0.357E-06 alpha_mix = 0.700 |ddv_scf|^2 = 0.274E-12

iter # 6 total cpu time : 4792.1 secs av.it.: 13.9
thresh= 0.524E-07 alpha_mix = 0.700 |ddv_scf|^2 = 0.241E-14

iter # 7 total cpu time : 4831.0 secs av.it.: 14.3
thresh= 0.490E-08 alpha_mix = 0.700 |ddv_scf|^2 = 0.642E-16

iter # 8 total cpu time : 4870.2 secs av.it.: 14.6
thresh= 0.801E-09 alpha_mix = 0.700 |ddv_scf|^2 = 0.442E-18

End of self-consistent calculation

Convergence has been achieved


Representation # 6 mode # 8

Self-consistent Calculation

iter # 1 total cpu time : 4911.5 secs av.it.: 7.7
thresh= 0.100E-01 alpha_mix = 0.700 |ddv_scf|^2 = 0.420E-05

iter # 2 total cpu time : 4952.0 secs av.it.: 15.0
thresh= 0.205E-03 alpha_mix = 0.700 |ddv_scf|^2 = 0.273E-04

iter # 3 total cpu time : 4986.8 secs av.it.: 12.7
thresh= 0.523E-03 alpha_mix = 0.700 |ddv_scf|^2 = 0.178E-06

iter # 4 total cpu time : 5025.4 secs av.it.: 14.2
thresh= 0.422E-04 alpha_mix = 0.700 |ddv_scf|^2 = 0.127E-07

iter # 5 total cpu time : 5062.9 secs av.it.: 13.8
thresh= 0.113E-04 alpha_mix = 0.700 |ddv_scf|^2 = 0.741E-09

iter # 6 total cpu time : 5102.0 secs av.it.: 14.6
thresh= 0.272E-05 alpha_mix = 0.700 |ddv_scf|^2 = 0.457E-10

iter # 7 total cpu time : 5139.5 secs av.it.: 13.8
thresh= 0.676E-06 alpha_mix = 0.700 |ddv_scf|^2 = 0.322E-13

iter # 8 total cpu time : 5179.9 secs av.it.: 15.2
thresh= 0.179E-07 alpha_mix = 0.700 |ddv_scf|^2 = 0.149E-10

iter # 9 total cpu time : 5204.7 secs av.it.: 7.8
thresh= 0.386E-06 alpha_mix = 0.700 |ddv_scf|^2 = 0.169E-06

iter # 10 total cpu time : 5223.4 secs av.it.: 5.0
thresh= 0.411E-04 alpha_mix = 0.700 |ddv_scf|^2 = 0.358E-03

iter # 11 total cpu time : 5239.7 secs av.it.: 4.1
thresh= 0.189E-02 alpha_mix = 0.700 |ddv_scf|^2 = 0.126E+01

iter # 12 total cpu time : 5263.1 secs av.it.: 7.3
thresh= 0.100E-01 alpha_mix = 0.700 |ddv_scf|^2 = 0.127E+03

iter # 13 total cpu time : 5292.5 secs av.it.: 10.0
thresh= 0.100E-01 alpha_mix = 0.700 |ddv_scf|^2 = 0.562E+05

iter # 14 total cpu time : 5332.4 secs av.it.: 14.6
thresh= 0.100E-01 alpha_mix = 0.700 |ddv_scf|^2 = 0.823E+08

iter # 15 total cpu time : 5381.8 secs av.it.: 18.8
thresh= 0.100E-01 alpha_mix = 0.700 |ddv_scf|^2 = 0.122E+11
* kpoint 2 ibnd 81 solve_linter: root not converged 0.770E+01*

iter # 16 total cpu time : 5441.2 secs av.it.: 23.6
thresh= 0.100E-01 alpha_mix = 0.700 |ddv_scf|^2 = 0.129E+13
* kpoint 2 ibnd 81 solve_linter: root not converged 0.136E+02
kpoint 3 ibnd 81 solve_linter: root not converged 0.202E+05*

iter # 17 total cpu time : 5509.8 secs av.it.: 27.5
thresh= 0.100E-01 alpha_mix = 0.700 |ddv_scf|^2 = 0.394E+16
* kpoint 2 ibnd 81 solve_linter: root not converged 0.124E+04
kpoint 3 ibnd 81 solve_linter: root not converged 0.261E+02
*
iter # 18 total cpu time : 5581.5 secs av.it.: 29.3
thresh= 0.100E-01 alpha_mix = 0.700 |ddv_scf|^2 = 0.249E+17
* kpoint 2 ibnd 81 solve_linter: root not converged 0.278E+06
kpoint 3 ibnd 81 solve_linter: root not converged 0.252E+08

* iter # 19 total cpu time : 5661.7 secs av.it.: 33.4
thresh= 0.100E-01 alpha_mix = 0.700 |ddv_scf|^2 = 0.241E+21
kpoint 2 ibnd 81 solve_linter: root not converged 0.438E+07
kpoint 3 ibnd 81 solve_linter: root not converged 0.637E+07

iter # 20 total cpu time : 5755.8 secs av.it.: 39.6
thresh= 0.100E-01 alpha_mix = 0.700 |ddv_scf|^2 = 0.132E+25
kpoint 2 ibnd 81 solve_linter: root not converged 0.263E+08
kpoint 3 ibnd 81 solve_linter: root not converged 0.677E+08

iter # 21 total cpu time : 5860.8 secs av.it.: 44.4
thresh= 0.100E-01 alpha_mix = 0.700 |ddv_scf|^2 = 0.754E+28
kpoint 2 ibnd 81 solve_linter: root not converged 0.107E+09
kpoint 3 ibnd 81 solve_linter: root not converged 0.101E+08

iter # 22 total cpu time : 5976.2 secs av.it.: 49.8
thresh= 0.100E-01 alpha_mix = 0.700 |ddv_scf|^2 = 0.421E+32
kpoint 2 ibnd 81 solve_linter: root not converged 0.149E+11
kpoint 3 ibnd 81 solve_linter: root not converged 0.841E+09

iter # 23 total cpu time : 6097.2 secs av.it.: 52.4
thresh= 0.100E-01 alpha_mix = 0.700 |ddv_scf|^2 = 0.215E+33
kpoint 2 ibnd 81 solve_linter: root not converged 0.340E+12
kpoint 3 ibnd 81 solve_linter: root not converged 0.347E+13

iter # 24 total cpu time : 6227.2 secs av.it.: 56.4
thresh= 0.100E-01 alpha_mix = 0.700 |ddv_scf|^2 = 0.198E+37
kpoint 2 ibnd 81 solve_linter: root not converged 0.108E+14
kpoint 3 ibnd 81 solve_linter: root not converged 0.438E+12
kpoint 6 ibnd 81 solve_linter: root not converged 0.162E+00

iter # 25 total cpu time : 6370.0 secs av.it.: 62.6
thresh= 0.100E-01 alpha_mix = 0.700 |ddv_scf|^2 = 0.176E+41
kpoint 2 ibnd 81 solve_linter: root not converged 0.262E+15
kpoint 3 ibnd 81 solve_linter: root not converged 0.134E+16
kpoint 6 ibnd 81 solve_linter: root not converged 0.118E+02

iter # 26 total cpu time : 6527.1 secs av.it.: 68.9
thresh= 0.100E-01 alpha_mix = 0.700 |ddv_scf|^2 = 0.128E+45
kpoint 2 ibnd 81 solve_linter: root not converged 0.153E+17
kpoint 3 ibnd 81 solve_linter: root not converged 0.385E+17
kpoint 6 ibnd 81 solve_linter: root not converged 0.343E+04

iter # 27 total cpu time : 6696.6 secs av.it.: 75.3
thresh= 0.100E-01 alpha_mix = 0.700 |ddv_scf|^2 = 0.914E+48
kpoint 2 ibnd 81 solve_linter: root not converged 0.219E+18
kpoint 3 ibnd 81 solve_linter: root not converged 0.125E+19
kpoint 6 ibnd 81 solve_linter: root not converged 0.330E+04

iter # 28 total cpu time : 6873.7 secs av.it.: 77.7
thresh= 0.100E-01 alpha_mix = 0.700 |ddv_scf|^2 = 0.498E+49
kpoint 2 ibnd 81 solve_linter: root not converged 0.222E+19
kpoint 3 ibnd 81 solve_linter: root not converged 0.222E+21
kpoint 6 ibnd 81 solve_linter: root not converged 0.280E+06

iter # 29 total cpu time : 7061.2 secs av.it.: 83.3
thresh= 0.100E-01 alpha_mix = 0.700 |ddv_scf|^2 = 0.470E+53
kpoint 2 ibnd 81 solve_linter: root not converged 0.423E+22
kpoint 3 ibnd 81 solve_linter: root not converged 0.662E+21
kpoint 6 ibnd 81 solve_linter: root not converged 0.558E+07

iter # 30 total cpu time : 7262.9 secs av.it.: 89.5
thresh= 0.100E-01 alpha_mix = 0.700 |ddv_scf|^2 = 0.392E+57
kpoint 2 ibnd 81 solve_linter: root not converged 0.228E+25
kpoint 3 ibnd 81 solve_linter: root not converged 0.222E+24
kpoint 6 ibnd 81 solve_linter: root not converged 0.170E+10

iter # 31 total cpu time : 7478.8 secs av.it.: 96.0
thresh= 0.100E-01 alpha_mix = 0.700 |ddv_scf|^2 = 0.264E+61
kpoint 2 ibnd 81 solve_linter: root not converged 0.865E+26
kpoint 3 ibnd 81 solve_linter: root not converged 0.993E+25
kpoint 6 ibnd 81 solve_linter: root not converged 0.108E+11

iter # 32 total cpu time : 7708.9 secs av.it.: 102.6
thresh= 0.100E-01 alpha_mix = 0.700 |ddv_scf|^2 = 0.176E+65
kpoint 2 ibnd 81 solve_linter: root not converged 0.195E+27
kpoint 3 ibnd 81 solve_linter: root not converged 0.438E+32
kpoint 6 ibnd 81 solve_linter: root not converged 0.339E+12

iter # 33 total cpu time : 7945.0 secs av.it.: 105.3
thresh= 0.100E-01 alpha_mix = 0.700 |ddv_scf|^2 = 0.894E+65
kpoint 2 ibnd 81 solve_linter: root not converged 0.553E+28
kpoint 3 ibnd 81 solve_linter: root not converged 0.708E+28
kpoint 6 ibnd 81 solve_linter: root not converged 0.795E-02

iter # 34 total cpu time : 8194.2 secs av.it.: 111.2
thresh= 0.100E-01 alpha_mix = 0.700 |ddv_scf|^2 = 0.827E+69
kpoint 2 ibnd 81 solve_linter: root not converged 0.374E-01
kpoint 3 ibnd 81 solve_linter: root not converged 0.897E+29
kpoint 6 ibnd 81 solve_linter: root not converged 0.126E-01

iter # 35 total cpu time : 8456.8 secs av.it.: 117.6
thresh= 0.100E-01 alpha_mix = 0.700 |ddv_scf|^2 = 0.736E+73
kpoint 2 ibnd 81 solve_linter: root not converged 0.386E+01
kpoint 3 ibnd 81 solve_linter: root not converged 0.999E-01
kpoint 6 ibnd 81 solve_linter: root not converged 0.753E-01
kpoint 7 ibnd 81 solve_linter: root not converged 0.636E-02
kpoint 8 ibnd 81 solve_linter: root not converged 0.101E-01

iter # 36 total cpu time : 8734.0 secs av.it.: 124.4
thresh= 0.100E-01 alpha_mix = 0.700 |ddv_scf|^2 = 0.537E+77
kpoint 2 ibnd 81 solve_linter: root not converged 0.124E-01
kpoint 3 ibnd 81 solve_linter: root not converged 0.794E+00
kpoint 6 ibnd 81 solve_linter: root not converged 0.514E-02
kpoint 7 ibnd 81 solve_linter: root not converged 0.284E-02
kpoint 8 ibnd 81 solve_linter: root not converged 0.950E-02

iter # 37 total cpu time : 9024.7 secs av.it.: 130.7
thresh= 0.100E-01 alpha_mix = 0.700 |ddv_scf|^2 = 0.387E+81
kpoint 1 ibnd 81 solve_linter: root not converged 0.207E-01
kpoint 2 ibnd 81 solve_linter: root not converged 0.704E-01
kpoint 3 ibnd 81 solve_linter: root not converged 0.691E+01
kpoint 6 ibnd 81 solve_linter: root not converged 0.335E-01
kpoint 7 ibnd 81 solve_linter: root not converged 0.107E-01
kpoint 8 ibnd 81 solve_linter: root not converged 0.150E-01

iter # 38 total cpu time : 9320.5 secs av.it.: 133.2
thresh= 0.100E-01 alpha_mix = 0.700 |ddv_scf|^2 = 0.214E+82
kpoint 1 ibnd 81 solve_linter: root not converged 0.139E+01
kpoint 2 ibnd 81 solve_linter: root not converged 0.179E+01
kpoint 3 ibnd 81 solve_linter: root not converged 0.103E-01
kpoint 4 ibnd 81 solve_linter: root not converged 0.183E-01
kpoint 6 ibnd 81 solve_linter: root not converged 0.565E-01
kpoint 7 ibnd 81 solve_linter: root not converged 0.106E+00
kpoint 8 ibnd 81 solve_linter: root not converged 0.653E-02

iter # 39 total cpu time : 9627.0 secs av.it.: 137.7
thresh= 0.100E-01 alpha_mix = 0.700 |ddv_scf|^2 = 0.203E+86
kpoint 1 ibnd 81 solve_linter: root not converged 0.108E+03
kpoint 2 ibnd 81 solve_linter: root not converged 0.186E+03
kpoint 3 ibnd 81 solve_linter: root not converged 0.388E+00
kpoint 4 ibnd 81 solve_linter: root not converged 0.206E-01
kpoint 5 ibnd 81 solve_linter: root not converged 0.568E-01
kpoint 6 ibnd 81 solve_linter: root not converged 0.967E-01
kpoint 7 ibnd 81 solve_linter: root not converged 0.367E-01
kpoint 8 ibnd 81 solve_linter: root not converged 0.690E-01

iter # 40 total cpu time : 9945.0 secs av.it.: 143.6
thresh= 0.100E-01 alpha_mix = 0.700 |ddv_scf|^2 = 0.167E+90
kpoint 1 ibnd 81 solve_linter: root not converged 0.199E-01
kpoint 2 ibnd 81 solve_linter: root not converged 0.578E-02
kpoint 3 ibnd 81 solve_linter: root not converged 0.142E-01
kpoint 4 ibnd 81 solve_linter: root not converged 0.169E+01
kpoint 5 ibnd 81 solve_linter: root not converged 0.142E+00
kpoint 6 ibnd 81 solve_linter: root not converged 0.111E-01
kpoint 7 ibnd 81 solve_linter: root not converged 0.262E-01
kpoint 8 ibnd 81 solve_linter: root not converged 0.244E-01













From giannozz at nest.sns.it  Fri Apr  7 10:59:51 2006
From: giannozz at nest.sns.it (Paolo Giannozzi)
Date: Fri, 7 Apr 2006 10:59:51 +0200
Subject: [Pw_forum] pw2casino question
In-Reply-To: <008b01c65982$01812820$b7305ba0@ornl.gov>
References: <008b01c65982$01812820$b7305ba0@ornl.gov>
Message-ID: <200604071059.51340.giannozz@nest.sns.it>

On Thursday 06 April 2006 15:57, Fernando A Reboredo wrote:

> I would like to know if it its physically meaningful to run pw2casino 
> with wavefunctions generated with Vanderbilt ultrasoft 
> pseudopotentials. At first sight it seams norm conserving pseudo 
> is the only safe option for pw2casino  However, in order to avoid
> contributing to global warming I would prefer to use ultrasofts. 
> Who would be the proper person to ask? 

the people using CASINO, I guess. Note that Kohn-Sham orbitals 
for ultrasoft PP's are not normalized, i.e. \sum_G |c(G)|^2 < 1 .
There are procedures to reconstruct  all-electron (as opposed to 
pseudo) normalized orbitals but these are no longer written in 
plane waves alone.

Paolo
-- 
Paolo Giannozzi             e-mail:  giannozz at nest.sns.it
Scuola Normale Superiore    Phone:   +39/050-509876, Fax:-563513 
Piazza dei Cavalieri 7      I-56126 Pisa, Italy


From eyvaz_isaev at yahoo.com  Fri Apr  7 12:21:10 2006
From: eyvaz_isaev at yahoo.com (Eyvaz Isaev)
Date: Fri, 7 Apr 2006 03:21:10 -0700 (PDT)
Subject: [Pw_forum] error on phonon calculation  (root not converged)
In-Reply-To: <4435CA2B.6080505@ncsu.edu>
Message-ID: <20060407102110.3142.qmail@web60317.mail.yahoo.com>

Hi,

Try small alpha_mix, say 0.1. Besides, your tr2_ph =
1e-18 seems to be extremly small. By default it is  
tr2_ph = 1e-10. Try this one and then check what
happens for reduced threshold. 

Bests,
Eyvaz.

--- Liping YU <lyu7 at ncsu.edu> wrote:

> Dear PWSCF users,
> I am performing some calculation on phonons of
> SrTiO3 by using PWSCF
> (ver3.0).
> I run SCF first and then do PH.x at gamma point. The
> convergence in scf
> calculation
> was reached. However during PH.x, I got the message
> like
> "kpoint 1 ibnd 81 solve_linter: root not converged
> 0.145E+30".
> pls see the detail of this in the follwed output
> file (the first
> occurance of this message
> was highlighted). Thanks for your advice.
> 
> liping
> 
> ================ input file for ph.x
> ===================
> '2*2*1 cb srtio3'
> &inputph
> prefix = 'cb-st'
> amass(1) = 87.620
> amass(2) = 47.86700
> amass(3) = 16.0
> tr2_ph = 1e-18
> trans = .true.
> zue = .true.
> epsil = .true.
> fildyn = 'cb-st.221.dynG'
> iverbosity = 1
> outdir='./tmp/'
> 0.0 0.0 0.0
> 
> ================ input file for scf
> ======================
> &CONTROL
> title = 'scf on cubic perovskite SrTiO3' ,
> calculation = 'scf' ,
> restart_mode = 'from_scratch' ,
> outdir = './tmp/' ,
> pseudo_dir = '../../pseudo/' ,
> prefix = 'cb-st' ,
> tstress = .true. ,
> tprnfor = .true. ,
> /
> &SYSTEM
> ibrav = 6,
> celldm(1) = 14.55327346
> celldm(3) = 0.5
> nat = 20,
> ntyp = 3,
> ecutwfc = 30 ,
> ecutrho = 270 ,
> /
> &ELECTRONS
> conv_thr = 1.D-8 ,
> /
> ATOMIC_SPECIES
> Sr 87.62000 038-Sr-ca-sp-vgrp.uspp.UPF
> Ti 47.86700 022-Ti-ca-sp-vgrp.uspp.UPF
> O 16.00000 008-O-ca--vgrp.uspp.UPF
> ATOMIC_POSITIONS crystal
> Sr 0.00 0.00 0.00
> Sr 0.50 0.00 0.00
> Sr 0.00 0.50 0.00
> Sr 0.50 0.50 0.00
> O 0.25 0.25 0.00
> O 0.25 0.75 0.00
> O 0.75 0.25 0.00
> O 0.75 0.75 0.00
> Ti 0.25 0.25 0.5
> Ti 0.25 0.75 0.5
> Ti 0.75 0.25 0.5
> Ti 0.75 0.75 0.5
> O 0.00 0.25 0.5
> O 0.00 0.75 0.5
> O 0.50 0.25 0.5
> O 0.50 0.75 0.5
> O 0.25 0.00 0.5
> O 0.75 0.00 0.5
> O 0.25 0.50 0.5
> O 0.75 0.50 0.5
> K_POINTS automatic
> 4 4 8 0 0 0
> 
> ===================== output file of runing ph.x
> ============================== Program PHONON v.3.0
> starts ...
> Today is 5Apr2006 at 22: 2:27
> 
> Parallel version (MPI)
> 
> Number of processors in use: 32
> K-points division: npool = 4
> R & G space division: proc/pool = 8
> 
> Ultrasoft (Vanderbilt) Pseudopotentials
> 
> Reading file cb-st.save ... only dimensions
> read complete
> 
> Reading file cb-st.save ... all except wavefuctions
> read complete
> 
> Planes per process (thick) : nr3 = 40 npp = 5
> ncplane = 6400
> 
> Planes per process (smooth): nr3s= 28 npps= 4
> ncplanes= 3136
> 
> Proc/ planes cols G planes cols G columns G
> Pool (dense grid) (smooth grid) (wavefct grid)
> 1 5 567 14421 4 253 4261 74 698
> 2 5 567 14421 4 254 4264 75 699
> 3 5 567 14421 4 253 4257 76 698
> 4 5 569 14421 4 253 4261 76 698
> 5 5 569 14421 3 253 4265 75 697
> 6 5 569 14421 3 253 4269 75 697
> 7 5 569 14421 3 253 4263 75 697
> 8 5 568 14420 3 253 4265 75 697
> 0 40 4545 115367 28 2025 34105 601 5581
> 
> 
> nbndx = 80 nbnd = 80 natomwfc = 108 npwx = 542
> nelec = 160.00 nkb = 240 ngl = 1003
> autoval = -.5378E+01
> Real(aut_vet)= ( 0.00000 0.00000 0.00000 0.00000
> 0.00000 0.00000)
> Real(aut_vet)= ( 0.00000 0.00000 0.00000 0.00000
> 0.00000 0.00000)
> Real(aut_vet)= ( 0.00000 0.00000 0.00000 0.00000
> 0.00000 0.00000)
> Real(aut_vet)= ( 0.00000 0.00000 0.00000 0.00000
> 0.00000 0.00000)
> .......
> .......
> .......
> Imm(aut_vet)= ( 0.00000 0.00000 0.00000 0.00000
> 0.00000 0.00000)
> Imm(aut_vet)= ( 0.00000 0.00000 0.00000 0.00000
> 0.00000 0.00000)
> Imm(aut_vet)= ( 0.00000 0.00000 0.00000 0.00000
> 0.00000 0.00000)
> Imm(aut_vet)= ( 0.00000 0.00000 0.00000 0.00000
> 0.00000 0.00000)
> Imm(aut_vet)= ( 0.00000 0.00000 0.00000 0.00000
> 0.00000 0.00000)
> 
> '2*2*1 cb srtio3'
> 
> crystal is
> 
> bravais-lattice index = 6
> lattice parameter (a_0) = 14.5533 a.u.
> unit-cell volume = 1541.1754 (a.u.)^3
> number of atoms/cell = 20
> number of atomic types = 3
> kinetic-energy cut-off = 30.0000 Ry
> charge density cut-off = 270.0000 Ry
> convergence threshold = 1.0E-18
> beta = 0.7000
> number of iterations used = 4
> 
> celldm(1)= 14.55327 celldm(2)= 0.00000 celldm(3)=
> 0.50000
> celldm(4)= 0.00000 celldm(5)= 0.00000 celldm(6)=
> 0.00000
> 
> crystal axes: (cart. coord. in units of a_0)
> a(1) = ( 1.0000 0.0000 0.0000 )
> a(2) = ( 0.0000 1.0000 0.0000 )
> a(3) = ( 0.0000 0.0000 0.5000 )
> 
> reciprocal axes: (cart. coord. in units 2 pi/a_0)
> b(1) = ( 1.0000 0.0000 0.0000 )
> b(2) = ( 0.0000 1.0000 0.0000 )
> b(3) = ( 0.0000 0.0000 2.0000 )
> 
> 
> Atoms inside the unit cell:
> 
> Cartesian axes
> 
> site n. atom mass positions (a_0 units)
> 1 Sr 87.6200 tau( 1) = ( 0.00000 0.00000 0.00000 )
> 2 Sr 87.6200 tau( 2) = ( 0.50000 0.00000 0.00000 )
> 3 Sr 87.6200 tau( 3) = ( 0.00000 0.50000 0.00000 )
> 4 Sr 87.6200 tau( 4) = ( 0.50000 0.50000 0.00000 )
> 5 O 16.0000 tau( 5) = ( 0.25000 0.25000 0.00000 )
> 6 O 16.0000 tau( 6) = ( 0.25000 0.75000 0.00000 )
> 7 O 16.0000 tau( 7) = ( 0.75000 0.25000 0.00000 )
> 8 O 16.0000 tau( 8) = ( 0.75000 0.75000 0.00000 )
> 9 Ti 47.8670 tau( 9) = ( 0.25000 0.25000 0.25000 )
> 10 Ti 47.8670 tau(10) = ( 0.25000 0.75000 0.25000 )
> 11 Ti 47.8670 tau(11) = ( 0.75000 0.25000 0.25000 )
> 12 Ti 47.8670 tau(12) = ( 0.75000 0.75000 0.25000 )
> 13 O 16.0000 tau(13) = ( 0.00000 0.25000 0.25000 )
> 14 O 16.0000 tau(14) = ( 0.00000 0.75000 0.25000 )
> 15 O 16.0000 tau(15) = ( 0.50000 0.25000 0.25000 )
> 
=== message truncated ===


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


From emenendez at macul.ciencias.uchile.cl  Fri Apr  7 14:52:52 2006
From: emenendez at macul.ciencias.uchile.cl (Eduardo Ariel Menendez P)
Date: Fri, 7 Apr 2006 08:52:52 -0400 (CLT)
Subject: [Pw_forum] CP: prefix_ndw.save files in local directory
Message-ID: <Pine.LNX.4.58.0604070847340.2144@macul.ciencias.uchile.cl>

Hello,
Is it possible to write the CP restart directory prefix_ndw.save to a
local scratch directory, when running in parallel? I always get is
saved in the execution directory, which is regretfully an NFS directory.
Thanks
Eduardo

Eduardo A. Menendez Proupin
Department of Physics
Faculty of Science
University of Chile
Las Palmeras 3425
?u?oa, Santiago
Chile
Phone: 56+2+978 74 11
http://fisica.ciencias.uchile.cl/~emenendez/



From lanhaiping at gmail.com  Fri Apr  7 15:41:09 2006
From: lanhaiping at gmail.com (lan haiping)
Date: Fri, 7 Apr 2006 21:41:09 +0800
Subject: [Pw_forum] k-points sample in BZ
Message-ID: <c92002fa0604070641m267c6e5fkb99444ead8d47258@mail.gmail.com>

Dear Pwscfers:

  I am obscure with k-points sample in BZ . Though
i read Doc/INPUT_PW,  i do not understand clearly about the k-grid offset in
automatic scheme(M-P grid).

 Would anyone give me some hints or reference related to this problem?
Thanks in advance


 Regards,
Hai-Ping
-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/attachments/20060407/522ada3c/attachment.htm 

From hsd22 at hermes.cam.ac.uk  Fri Apr  7 16:02:41 2006
From: hsd22 at hermes.cam.ac.uk (H.S.Domingos)
Date: Fri, 7 Apr 2006 15:02:41 +0100 (BST)
Subject: [Pw_forum] Another day another compilation problem
Message-ID: <Pine.LNX.4.64.0604071455050.9733@hermes-1.csi.cam.ac.uk>

Dear all,

I have compiled the pwscf code on a linux i686 cluster and strangely I do 
not get the MPI version when I run pw.x.
I have been unable to work out the problem. I assume that it is about 
make.sys and the parallel environment. Can I please ask your help on this?
You seem to have a knack for getting it right the first time.

Thank you very much in advance.

The make.sys after doctoring is :

#########################################################
# make.sys.  Generated from make.sys.in by configure.

# compilation rules

.SUFFIXES :
.SUFFIXES : .o .c .f .f90

.f90.o:
         $(MPIF90) $(F90FLAGS) -c $<

.f.o:
         $(F77) $(FFLAGS) -c $<

.c.o:
         $(CC) $(CFLAGS) -c $<


CC             = icc
MPICC          = mpicc
CFLAGS         = -O3 $(DFLAGS) $(IFLAGS)
CPP            = icc -E
CPPFLAGS       =  $(DFLAGS) $(IFLAGS)
F90            = ifort
MPIF90         = mpif90
F90FLAGS       = -zero -nbs -r8 -ip -O3 -tpp7 -axWNBP -arch pn4 -fpp 
$(FDFLAGS) $(IFLAGS) $(MODFLAGS)
F90FLAGS_NOOPT = $(FFLAGS_NOOPT) -nomodule -fpp $(FDFLAGS) $(IFLAGS) 
$(MODFLAGS)
F77            = ifort
MPIF77         = mpif77
FFLAGS         = -zero -nbs -r8 -ip -O3 -tpp7 -axWNBP -arch pn4
FFLAGS_NOOPT   = -O0 -assume byterecl
LD             = ifort
LDFLAGS        = -static -openmp
AR             = ar
ARFLAGS        = ruv
RANLIB         = echo
BLAS_LIBS      = -L/opt/intel/mkl/8.0/lib/32/ -lmkl_ia32 -lguide -lpthread
LAPACK_LIBS    = -lmkl_lapack
FFT_LIBS       = -L/home/guests/hsd22/fftw_lib/lib/ -lfftw
MPI_LIBS       =
MASS_LIBS      =

# -----------------------------
# application-specific settings

# See include/defs.h.README for a list of precompilation options
# (possible arguments to -D or -U) and their meaning
DFLAGS         = -D__LINUX -D__INTEL -D__FFTW -D__USE_INTERNAL_FFTW
FDFLAGS        = $(DFLAGS)
IFLAGS         = -I../include  -I /usr/local/include
MODFLAGS       = -I. -I../Modules -I../PW -I../PH -I../iotk/src

LIBOBJS        = ../flib/ptools.a ../flib/flib.a ../clib/clib.a 
../iotk/src/libiotk.a
# LIBS must contain the location of all needed external libraries
LIBS           = $(LAPACK_LIBS) $(BLAS_LIBS) $(FFT_LIBS) $(MPI_LIBS) 
$(MASS_LIBS)
# MYLIB can be one of the following (depending on LIBS):
# blas       : compile the local copy of blas routines
# lapack     : compile the local copy of lapack routines
# blas_and_lapack : all of the above - use this for a quick test
#              or if you don't have an optimized blas/lapack library
# lapack_ibm : compile only lapack routines not present in IBM ESSL
#              use this together with IBM ESSL
# lapack_t3e : compile only lapack routines not present in T3E scilib
#              use this together with T3E scilib
# lapack_mkl : compile only lapack routines not present in Intel MKL
#              use this together with Intel MKL
MYLIB          = lapack_mkl



=======================================================================
|  Dr. Helder S. Domingos                                             |
|                                                                     |
| INESC Microsyst & Nanotechnol, Lisbon, P-1000 Portugal              |
| and                                                                 |
| R&D unit for  Molecular Chemical Physics                            |
| Chemistry Department, University of Coimbra                         |
=======================================================================



From giannozz at nest.sns.it  Fri Apr  7 16:07:37 2006
From: giannozz at nest.sns.it (Paolo Giannozzi)
Date: Fri, 7 Apr 2006 16:07:37 +0200
Subject: [Pw_forum] Another day another compilation problem
In-Reply-To: <Pine.LNX.4.64.0604071455050.9733@hermes-1.csi.cam.ac.uk>
References: <Pine.LNX.4.64.0604071455050.9733@hermes-1.csi.cam.ac.uk>
Message-ID: <200604071607.37959.giannozz@nest.sns.it>

On Friday 07 April 2006 16:02, H.S.Domingos wrote:

> I have compiled the pwscf code on a linux i686 cluster and strangely
> I do not get the MPI version when I run pw.x.

of course you don't: you need a parallel compilation environment,
libraries, and -D__PARA in the preprocessing flags

Paolo
-- 
Paolo Giannozzi             e-mail:  giannozz at nest.sns.it
Scuola Normale Superiore    Phone:   +39/050-509876, Fax:-563513 
Piazza dei Cavalieri 7      I-56126 Pisa, Italy


From proffess at yandex.ru  Fri Apr  7 16:07:49 2006
From: proffess at yandex.ru (Sergey Lisenkov)
Date: Fri, 7 Apr 2006 18:07:49 +0400 (MSD)
Subject: [Pw_forum] Another day another compilation problem
In-Reply-To: <Pine.LNX.4.64.0604071455050.9733@hermes-1.csi.cam.ac.uk>
References: <Pine.LNX.4.64.0604071455050.9733@hermes-1.csi.cam.ac.uk>
Message-ID: <44367235.000001.20487@soapbox.yandex.ru>

>
>DFLAGS         = -D__LINUX -D__INTEL -D__FFTW -D__USE_INTERNAL_FFTW

 Must be 
 DFLAGS         = -D__LINUX -D__INTEL -D__FFTW -D__USE_INTERNAL_FFTW -D__MPI -D__PARA


From giannozz at nest.sns.it  Fri Apr  7 16:26:32 2006
From: giannozz at nest.sns.it (Paolo Giannozzi)
Date: Fri, 7 Apr 2006 16:26:32 +0200
Subject: [Pw_forum] k-points sample in BZ
In-Reply-To: <c92002fa0604070641m267c6e5fkb99444ead8d47258@mail.gmail.com>
References: <c92002fa0604070641m267c6e5fkb99444ead8d47258@mail.gmail.com>
Message-ID: <200604071626.32887.giannozz@nest.sns.it>

On Friday 07 April 2006 15:41, lan haiping wrote:

>   I do not understand clearly about the k-grid offset 
>   in automatic scheme(M-P grid). 
>
>  Would anyone give me some hints or reference related
>  to this problem? 

you may try this one: P. E. Bloechl et al, PRB49, 16223 (1994)

Paolo
-- 
Paolo Giannozzi             e-mail:  giannozz at nest.sns.it
Scuola Normale Superiore    Phone:   +39/050-509876, Fax:-563513 
Piazza dei Cavalieri 7      I-56126 Pisa, Italy


From giannozz at nest.sns.it  Fri Apr  7 16:39:36 2006
From: giannozz at nest.sns.it (Paolo Giannozzi)
Date: Fri, 7 Apr 2006 16:39:36 +0200
Subject: [Pw_forum] error on phonon calculation  (root not converged)
In-Reply-To: <20060407102110.3142.qmail@web60317.mail.yahoo.com>
References: <20060407102110.3142.qmail@web60317.mail.yahoo.com>
Message-ID: <200604071639.36703.giannozz@nest.sns.it>

On Friday 07 April 2006 12:21, Eyvaz Isaev wrote:

> Try small alpha_mix, say 0.1. Besides, your tr2_ph =
> 1e-18 seems to be extremly small. By default it is
> tr2_ph = 1e-10. Try this one and then check what
> happens for reduced threshold.

this may actually work, but the problem that shows up in
Liping's output is rather strange and nasty. The self-consistent
procedure seems to converge quite nicely: |ddv_scf|^2 goes
down towards the threshold, then it starts to go up to crazy
values. Why, I don't know, and I am afraid there is very little
one can do when this kind of behavior occurs in the middle
of a long job without any apparent reason

Paolo
-- 
Paolo Giannozzi             e-mail:  giannozz at nest.sns.it
Scuola Normale Superiore    Phone:   +39/050-509876, Fax:-563513 
Piazza dei Cavalieri 7      I-56126 Pisa, Italy


From eyvaz_isaev at yahoo.com  Fri Apr  7 17:09:23 2006
From: eyvaz_isaev at yahoo.com (Eyvaz Isaev)
Date: Fri, 7 Apr 2006 08:09:23 -0700 (PDT)
Subject: [Pw_forum] error on phonon calculation  (root not converged)
In-Reply-To: <200604071639.36703.giannozz@nest.sns.it>
Message-ID: <20060407150924.61726.qmail@web60325.mail.yahoo.com>

Dear Paolo,

--- Paolo Giannozzi <giannozz at nest.sns.it> wrote:
> 
> this may actually work, but the problem that shows
> up in  Liping's output is rather strange and nasty. 

> The self-consistent  procedure seems to converge 
> quite nicely: |ddv_scf|^2 goes  down towards the
>threshold, then it starts to go up to crazy
> values. 
Yes, I paid attention to this behaviour. Actually,
recently I had very close situation: for some modes
everything was OK, and next mode also started well,
and then turned out to be crazy. At least in my case,
using small mixing parameter fixed the problem.

I suggest, Liping should keep us informed about the
problem.

Bests,
Eyvaz.

> Why, I don't know, and I am afraid there is
> very little  one can do when this kind of behavior 
> occurs in the  middle  of a long job without any 
> apparent reason


 

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


From lyu7 at ncsu.edu  Fri Apr  7 17:22:48 2006
From: lyu7 at ncsu.edu (Liping YU)
Date: Fri, 07 Apr 2006 11:22:48 -0400
Subject: [Pw_forum] error on phonon calculation  (root not converged)
In-Reply-To: <20060407150924.61726.qmail@web60325.mail.yahoo.com>
References: <20060407150924.61726.qmail@web60325.mail.yahoo.com>
Message-ID: <443683C8.8050300@ncsu.edu>

Dear Paolo,

>--- Paolo Giannozzi <giannozz at nest.sns.it> wrote:
>  
>
>>this may actually work, but the problem that shows
>>up in  Liping's output is rather strange and nasty. 
>>    
>>
>
>  
>
>>The self-consistent  procedure seems to converge 
>>quite nicely: |ddv_scf|^2 goes  down towards the
>>threshold, then it starts to go up to crazy
>>values. 
>>    
>>
>Yes, I paid attention to this behaviour. Actually,
>recently I had very close situation: for some modes
>everything was OK, and next mode also started well,
>and then turned out to be crazy. At least in my case,
>using small mixing parameter fixed the problem.
>
>I suggest, Liping should keep us informed about the
>problem.
>  
>
Thanks for your suggestion. I am trying it with smaller alpha_mix.
I'll let you know when the results come out. Actually the first such
message occured in electric field calcualtion (see below).

Thanks!
liping
============================================

Electric Fields Calculation

iter # 1 total cpu time : 625.1 secs av.it.: 7.6
thresh= 0.100E-01 alpha_mix = 0.700 |ddv_scf|^2 = 0.708E-08

iter # 2 total cpu time : 748.8 secs av.it.: 15.3
thresh= 0.841E-05 alpha_mix = 0.700 |ddv_scf|^2 = 0.517E-09

iter # 3 total cpu time : 869.8 secs av.it.: 15.0
thresh= 0.227E-05 alpha_mix = 0.700 |ddv_scf|^2 = 0.128E-10

iter # 4 total cpu time : 995.4 secs av.it.: 15.6
thresh= 0.358E-06 alpha_mix = 0.700 |ddv_scf|^2 = 0.890E-12

iter # 5 total cpu time : 1122.9 secs av.it.: 16.0
thresh= 0.943E-07 alpha_mix = 0.700 |ddv_scf|^2 = 0.830E-13

iter # 6 total cpu time : 1252.7 secs av.it.: 16.7
thresh= 0.288E-07 alpha_mix = 0.700 |ddv_scf|^2 = 0.874E-13

iter # 7 total cpu time : 1362.9 secs av.it.: 13.9
thresh= 0.296E-07 alpha_mix = 0.700 |ddv_scf|^2 = 0.608E-14

iter # 8 total cpu time : 1484.7 secs av.it.: 15.6
thresh= 0.780E-08 alpha_mix = 0.700 |ddv_scf|^2 = 0.204E-13

iter # 9 total cpu time : 1594.0 secs av.it.: 13.9
thresh= 0.143E-07 alpha_mix = 0.700 |ddv_scf|^2 = 0.105E-15
 =-O kpoint 3 ibnd 81 solve_e: root not converged 0.807E-08 =-O 
iter # 10 total cpu time : 1722.1 secs av.it.: 16.5
thresh= 0.102E-08 alpha_mix = 0.700 |ddv_scf|^2 = 0.108E-17

iter # 11 total cpu time : 1854.0 secs av.it.: 17.1
thresh= 0.104E-09 alpha_mix = 0.700 |ddv_scf|^2 = 0.770E-19

End of electric fields calculation

......

-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/attachments/20060407/338668b5/attachment.htm 

From giannozz at nest.sns.it  Fri Apr  7 17:34:44 2006
From: giannozz at nest.sns.it (Paolo Giannozzi)
Date: Fri, 7 Apr 2006 17:34:44 +0200
Subject: [Pw_forum] error on phonon calculation  (root not converged)
In-Reply-To: <443683C8.8050300@ncsu.edu>
References: <20060407150924.61726.qmail@web60325.mail.yahoo.com> <443683C8.8050300@ncsu.edu>
Message-ID: <200604071734.44451.giannozz@nest.sns.it>

On Friday 07 April 2006 17:22, Liping YU wrote:

> Thanks for your suggestion. I am trying it with smaller alpha_mix.
> I'll let you know when the results come out. Actually the first such
> message occured in electric field calcualtion (see below).

unless you have many of them, or the number that appears at
the right of the message is large, it shouldn't matter

Paolo
-- 
Paolo Giannozzi             e-mail:  giannozz at nest.sns.it
Scuola Normale Superiore    Phone:   +39/050-509876, Fax:-563513 
Piazza dei Cavalieri 7      I-56126 Pisa, Italy


From hassaniyan at modares.ac.ir  Sat Apr  8 12:35:49 2006
From: hassaniyan at modares.ac.ir (hadi hassaniyan arefi)
Date: Sat, 08 Apr 2006 15:05:49 +0430
Subject: [Pw_forum] some problem in calculate EFG
Message-ID: <WorldClient-F200604081505.AA05490096@modares.ac.ir>

dear manageres:
i have have some fundamental problem in filling the input files for EFG like 
example 24:
1) i think that in input file for pw "ibra" must be zero all time.am i 
true?if "yes" so what about the molecules?can we define for them unit cell 
and number of atoms in unit cell?

2)next if ibra=0  "cell parameter" namelist must filled.in fact i couldnt 
understand what it means and how i can fill it for diffrent systemes.
 best regard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/attachments/20060408/ccbbc16a/attachment.htm 

From hassaniyan at modares.ac.ir  Sat Apr  8 12:35:42 2006
From: hassaniyan at modares.ac.ir (hadi hassaniyan arefi)
Date: Sat, 08 Apr 2006 15:05:42 +0430
Subject: [Pw_forum] some problem in calculate EFG
Message-ID: <WorldClient-F200604081505.AA05420095@modares.ac.ir>

dear manageres:
i have have some fundamental problem in filling the input files for EFG like 
example 24:
1) i think that in input file for pw "ibra" must be zero all time.am i 
true?if "yes" so what about the molecules?can we define for them unit cell 
and number of atoms in unit cell?

2)next if ibra=0  "cell parameter" namelist must filled.in fact i couldnt 
understand what it means and how i can fill it for diffrent systemes.
 best regard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/attachments/20060408/10afdebc/attachment.htm 

From hassaniyan at modares.ac.ir  Sat Apr  8 12:35:55 2006
From: hassaniyan at modares.ac.ir (hadi hassaniyan arefi)
Date: Sat, 08 Apr 2006 15:05:55 +0430
Subject: [Pw_forum] some problem in calculate EFG
Message-ID: <WorldClient-F200604081505.AA05550097@modares.ac.ir>

dear manageres:
i have have some fundamental problem in filling the input files for EFG like 
example 24:
1) i think that in input file for pw "ibra" must be zero all time.am i 
true?if "yes" so what about the molecules?can we define for them unit cell 
and number of atoms in unit cell?

2)next if ibra=0  "cell parameter" namelist must filled.in fact i couldnt 
understand what it means and how i can fill it for diffrent systemes.
 best regard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/attachments/20060408/8d822819/attachment.htm 

From lyu7 at ncsu.edu  Sun Apr  9 20:24:29 2006
From: lyu7 at ncsu.edu (Liping YU)
Date: Sun, 09 Apr 2006 14:24:29 -0400
Subject: [Pw_forum] error on phonon calculation  (root not converged)
In-Reply-To: <20060407150924.61726.qmail@web60325.mail.yahoo.com>
References: <20060407150924.61726.qmail@web60325.mail.yahoo.com>
Message-ID: <4439515D.2050505@ncsu.edu>

Eyvaz Isaev wrote:

>Dear Paolo,
>
>--- Paolo Giannozzi <giannozz at nest.sns.it> wrote:
>  
>
>>this may actually work, but the problem that shows
>>up in  Liping's output is rather strange and nasty. 
>>    
>>
>
>  
>
>>The self-consistent  procedure seems to converge 
>>quite nicely: |ddv_scf|^2 goes  down towards the
>>threshold, then it starts to go up to crazy
>>values. 
>>    
>>
>Yes, I paid attention to this behaviour. Actually,
>recently I had very close situation: for some modes
>everything was OK, and next mode also started well,
>and then turned out to be crazy. At least in my case,
>using small mixing parameter fixed the problem.
>
>I suggest, Liping should keep us informed about the
>problem.
>
The same phenomenon still campe up in the self consistent
calculation of representation # 6 if I only reduce aplpha_mix(1)
to 0.1 and keep tr2_ph = 1.0e-18. So only using smaller mixing
parameter doesn't work in this case.

However it works as we expected if I set alpha_mix(1) = 0.1
and tr2_ph = 1.e-10. But the results (here 20-atom 2*2*1 supercell used)
don't agree well with those of calculation where 1*1*1 cubic perovskite
unit cell (5 atoms inside) are used. For example, the dielectric
constant of
Srtio3, is for 2*2*1 supercell

( 222.139158023 0.000000000 0.000000000 )
( 0.000000000 222.139158023 0.000000000 )
( 0.000000000 0.000000000 6.262166130 )
and for 1*1*1 unit cell
( 6.296436141 0.000000000 0.000000000 )
( 0.000000000 6.296436141 0.000000000 )
( 0.000000000 0.000000000 6.296436141 ).

In direction of xx and yy, dielectric constants in two cases should be
pretty
close to each other like the one in zz direction. I am not sure if the
problem
comes from something related to the supercell I used. There is no such
problem
for 1*1*1 unit cell when setting alpha_mix(1) = 0.7 and tr2_ph = 1.e-18.
On the other hand, I am also wondering if it's also possible due to
pseudopotential. Because there is no such problem for PbTiO3 in 2*2*1
supercell.
Thanks for your comments!
liping

>Bests,
>Eyvaz.
>
>  
>
>>Why, I don't know, and I am afraid there is
>>very little  one can do when this kind of behavior 
>>occurs in the  middle  of a long job without any 
>>apparent reason
>>    
>>
>
>
> 
>
>__________________________________________________
>Do You Yahoo!?
>Tired of spam?  Yahoo! Mail has the best spam protection around 
>http://mail.yahoo.com 
>_______________________________________________
>Pw_forum mailing list
>Pw_forum at pwscf.org
>http://www.democritos.it/mailman/listinfo/pw_forum
>  
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/attachments/20060409/4a50b802/attachment.htm 

From hqzhou at nju.edu.cn  Mon Apr 10 10:37:48 2006
From: hqzhou at nju.edu.cn (Huiqun Zhou)
Date: Mon, 10 Apr 2006 16:37:48 +0800
Subject: [Pw_forum] Pseudopotential for Mn
Message-ID: <000001c65c7a$17320f40$1d00a8c0@solarflare>

dear list-users,

Could anyone contribute the pseudopotential for Mn for share?

Thanks in advance!

Huiqun Zhou


From giannozz at nest.sns.it  Mon Apr 10 14:22:15 2006
From: giannozz at nest.sns.it (Paolo Giannozzi)
Date: Mon, 10 Apr 2006 14:22:15 +0200
Subject: [Pw_forum] error on phonon calculation  (root not converged)
In-Reply-To: <4439515D.2050505@ncsu.edu>
References: <20060407150924.61726.qmail@web60325.mail.yahoo.com> <4439515D.2050505@ncsu.edu>
Message-ID: <200604101422.15850.giannozz@nest.sns.it>

On Sunday 09 April 2006 20:24, Liping YU wrote:

> The same phenomenon still campe up in the self consistent
> calculation of representation # 6 if I only reduce aplpha_mix(1)
> to 0.1 and keep tr2_ph = 1.0e-18. So only using smaller mixing
> parameter doesn't work in this case.
>
> However it works as we expected if I set alpha_mix(1) = 0.1
> and tr2_ph = 1.e-10.

there are 8 orders of magnitude between 10^{-10} (not-so-tight
convergence) and 10^{-18} (execeedingly tight convergence).
Try 10^{-12} and 10^{-14}, it shuod be more than enough for 
all porpouses.

> But the results (here 20-atom 2*2*1 supercell used) don't agree 
> well with those of calculation where 1*1*1 cubic perovskite 
> unit cell (5 atoms inside) are used. For example, the dielectric
> constant of Srtio3, is for 2*2*1 supercell
>
> ( 222.139158023 0.000000000 0.000000000 )
> ( 0.000000000 222.139158023 0.000000000 )
> ( 0.000000000 0.000000000 6.262166130 )
> and for 1*1*1 unit cell
> ( 6.296436141 0.000000000 0.000000000 )
> ( 0.000000000 6.296436141 0.000000000 )
> ( 0.000000000 0.000000000 6.296436141 ).

it seems to me VERY unlikely that such a large difference is due
to insufficient convergence.

P.
--
Paolo Giannozzi             e-mail:  giannozz at nest.sns.it
Scuola Normale Superiore    Phone:   +39/050-509876, Fax:-563513 
Piazza dei Cavalieri 7      I-56126 Pisa, Italy


From marzari at MIT.EDU  Mon Apr 10 14:30:01 2006
From: marzari at MIT.EDU (Nicola Marzari)
Date: Mon, 10 Apr 2006 14:30:01 +0200
Subject: [Pw_forum] error on phonon calculation  (root not converged)
In-Reply-To: <200604101422.15850.giannozz@nest.sns.it>
References: <20060407150924.61726.qmail@web60325.mail.yahoo.com> <4439515D.2050505@ncsu.edu> <200604101422.15850.giannozz@nest.sns.it>
Message-ID: <443A4FC9.7090608@mit.edu>


> there are 8 orders of magnitude between 10^{-10} (not-so-tight
> convergence) and 10^{-18} (execeedingly tight convergence).
> Try 10^{-12} and 10^{-14}, it shuod be more than enough for 
> all purposes.

Agreed (caveat: if you have a long or large system, e.g.
a metallic slab or a nanotube, you might need to tighten
the convergence to -16/-18 - it also depends what do you need
the phonon for, and how accurately you need them converged.)

>>But the results (here 20-atom 2*2*1 supercell used) don't agree 
>>well with those of calculation where 1*1*1 cubic perovskite 
>>unit cell (5 atoms inside) are used. For example, the dielectric
>>constant of Srtio3, is for 2*2*1 supercell
>>
>>( 222.139158023 0.000000000 0.000000000 )
>>( 0.000000000 222.139158023 0.000000000 )
>>( 0.000000000 0.000000000 6.262166130 )
>>and for 1*1*1 unit cell
>>( 6.296436141 0.000000000 0.000000000 )
>>( 0.000000000 6.296436141 0.000000000 )
>>( 0.000000000 0.000000000 6.296436141 ).


To be on the safe side, use equivalent k-point sampling
for the two calculations. This means that if in the 1x1x1 unit cell
(5 atoms) you use, say, a 8x8x8 monkhorst-pack mesh, you should use
a 4x4x8 mesh in the 2x2x1 supercell. (This is not going to be
the source of your error, unless you are using an extremely poor
sampling (e.g. Gamma only). Note that dielectric properties
require more k-points to be converged, than say total energy or
forces.)

			nicola


-- 
---------------------------------------------------------------------
Prof Nicola Marzari   Department of Materials Science and Engineering
13-5066   MIT   77 Massachusetts Avenue   Cambridge MA 02139-4307 USA
tel 617.4522758 fax 2586534 marzari at mit.edu http://quasiamore.mit.edu


From lzhuang at whu.edu.cn  Mon Apr 10 15:55:32 2006
From: lzhuang at whu.edu.cn (Lin Zhuang)
Date: Mon, 10 Apr 2006 21:55:32 +0800
Subject: [Pw_forum] about LAM/MPI
Message-ID: <2b80d0af0604100655w576a6ab8i226676fc86254e5e@mail.gmail.com>

Hi there,
I have successfully compiled and tested Quantum ESPRESSO in serial version,
but actually I have  installed and run LAM/MPI without error on my
computers, why the ./configure cannot recognize that?
Did I miss anything important?
with best regards,
Lin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/attachments/20060410/9c720895/attachment.htm 

From giannozz at nest.sns.it  Mon Apr 10 16:09:56 2006
From: giannozz at nest.sns.it (Paolo Giannozzi)
Date: Mon, 10 Apr 2006 16:09:56 +0200
Subject: [Pw_forum] about LAM/MPI
In-Reply-To: <2b80d0af0604100655w576a6ab8i226676fc86254e5e@mail.gmail.com>
References: <2b80d0af0604100655w576a6ab8i226676fc86254e5e@mail.gmail.com>
Message-ID: <200604101609.56784.giannozz@nest.sns.it>

On Monday 10 April 2006 15:55, Lin Zhuang wrote:

> I have successfully compiled and tested Quantum ESPRESSO
> in serial version, but actually I have  installed and run LAM/MPI
> without error on my computers, why the ./configure cannot 
> recognize that? 

most likely because your parallel compiler environment is not 
properly set. Either you do not have a working parallel f90 
compiler in your path, or your MPI libraries are in a strange place

Paolo
-- 
Paolo Giannozzi             e-mail:  giannozz at nest.sns.it
Scuola Normale Superiore    Phone:   +39/050-509876, Fax:-563513 
Piazza dei Cavalieri 7      I-56126 Pisa, Italy


From hsd22 at hermes.cam.ac.uk  Mon Apr 10 17:09:28 2006
From: hsd22 at hermes.cam.ac.uk (H.S.Domingos)
Date: Mon, 10 Apr 2006 16:09:28 +0100 (BST)
Subject: [Pw_forum] Non-colinear magnetism
Message-ID: <Pine.LNX.4.64.0604101605420.15921@hermes-1.csi.cam.ac.uk>

Dear all,

I would like to ask if the non-colinear magnetism part of the code is 
fairly stable. I would like to do magnetism in permalloys and I dont have 
a feel for how hard that might be with this code.
Is it advised to use the experimental features for this or is it 
half-baked and unstable ?

Thank you very much once again,

Helder


=======================================================================
|  Dr. Helder S. Domingos                                             |
|                                                                     |
| INESC Microsyst & Nanotechnol, Lisbon, P-1000 Portugal              |
| and                                                                 |
| R&D unit for  Molecular Chemical Physics                            |
| Chemistry Department, University of Coimbra                         |
=======================================================================



From lyu7 at ncsu.edu  Mon Apr 10 17:35:07 2006
From: lyu7 at ncsu.edu (Liping YU)
Date: Mon, 10 Apr 2006 11:35:07 -0400
Subject: [Pw_forum] error on phonon calculation  (root not converged)
In-Reply-To: <443A4FC9.7090608@mit.edu>
References: <20060407150924.61726.qmail@web60325.mail.yahoo.com> <4439515D.2050505@ncsu.edu> <200604101422.15850.giannozz@nest.sns.it> <443A4FC9.7090608@mit.edu>
Message-ID: <443A7B2B.4060202@ncsu.edu>

Nicola Marzari wrote:

>
>
>> there are 8 orders of magnitude between 10^{-10} (not-so-tight
>> convergence) and 10^{-18} (execeedingly tight convergence).
>> Try 10^{-12} and 10^{-14}, it shuod be more than enough for all
>> purposes.
>
Acctually, for 1e-18, though unconvergence message came up in phonon
calculation,
the dielectric constant I got (see below) was pretty close to 1.0e-10
in the same 2*2*1 supercell.

(2x2x1, tr2_ph=1.0e-18, alpha_mix=0.1)
( 222.132924025 0.000000000 0.000000000 )
( 0.000000000 222.132924025 0.000000000 )
( 0.000000000 0.000000000 6.253206744 )

(2x2x1, tr2_ph=1.0e-10, apha_mix=0.1)
( 222.139158023 0.000000000 0.000000000 )
( 0.000000000 222.139158023 0.000000000 )
( 0.000000000 0.000000000 6.262166130 )

(1x1x1, tr_ph=1.0e-18, alpha_mix=0.7)
( 6.296436141 0.000000000 0.000000000 )
( 0.000000000 6.296436141 0.000000000 )
( 0.000000000 0.000000000 6.296436141 ).

>
> Agreed (caveat: if you have a long or large system, e.g.
> a metallic slab or a nanotube, you might need to tighten
> the convergence to -16/-18 - it also depends what do you need
> the phonon for, and how accurately you need them converged.)
>
>>> But the results (here 20-atom 2*2*1 supercell used) don't agree well
>>> with those of calculation where 1*1*1 cubic perovskite unit cell (5
>>> atoms inside) are used. For example, the dielectric
>>> constant of Srtio3, is for 2*2*1 supercell
>>>
>>> ( 222.139158023 0.000000000 0.000000000 )
>>> ( 0.000000000 222.139158023 0.000000000 )
>>> ( 0.000000000 0.000000000 6.262166130 )
>>> and for 1*1*1 unit cell
>>> ( 6.296436141 0.000000000 0.000000000 )
>>> ( 0.000000000 6.296436141 0.000000000 )
>>> ( 0.000000000 0.000000000 6.296436141 ).
>>
>
>
> To be on the safe side, use equivalent k-point sampling
> for the two calculations. This means that if in the 1x1x1 unit cell
> (5 atoms) you use, say, a 8x8x8 monkhorst-pack mesh, you should use
> a 4x4x8 mesh in the 2x2x1 supercell. 

That's exactly what I have used, '8 8 8 0 0 0' for 1x1x1 unit cell
and '4 4 8 0 0 0' for 2x2x1 supercell.

I have a feeling (could be wrong) that this might be due to LDA-PP of
Strontium.
Since i did the same calculation for PbTiO3 using the same PPs of Ti and
O as
those in SrTiO3 and it worked well. So I appreciate if someone could
send me
your Sr LDA-PP (if you have one) that i could try.

Thanks again for your suggestion!

Best!
liping




From marzari at MIT.EDU  Mon Apr 10 17:49:11 2006
From: marzari at MIT.EDU (Nicola Marzari)
Date: Mon, 10 Apr 2006 17:49:11 +0200
Subject: [Pw_forum] error on phonon calculation  (root not converged)
In-Reply-To: <443A7B2B.4060202@ncsu.edu>
References: <20060407150924.61726.qmail@web60325.mail.yahoo.com> <4439515D.2050505@ncsu.edu> <200604101422.15850.giannozz@nest.sns.it> <443A4FC9.7090608@mit.edu> <443A7B2B.4060202@ncsu.edu>
Message-ID: <443A7E77.3000004@mit.edu>

> I have a feeling (could be wrong) that this might be due to LDA-PP of
> Strontium.
> Since i did the same calculation for PbTiO3 using the same PPs of Ti and
> O as
> those in SrTiO3 and it worked well. So I appreciate if someone could
> send me
> your Sr LDA-PP (if you have one) that i could try.


Hi Liping,

it's indeed baffling. Do check that your coordinates are scaled
correctly - i.e. that the atoms in cartesian coordinates are
were they should be, that the axes are what they should be.

Next, if you use the same identical input files, but you put
Pb instead of Sr, do you get identical dielectric constants
from 1x1x1 and 2x2x1 ?

If you do, I admit that one would be tempted to blame the
pseudopotential, but it is still unlikely. Have a look at the
eigenvalues in the two calculations - do they match exactly ?

Let us know what you find,

			nicola

---------------------------------------------------------------------
Prof Nicola Marzari   Department of Materials Science and Engineering
13-5066   MIT   77 Massachusetts Avenue   Cambridge MA 02139-4307 USA
tel 617.4522758 fax 2586534 marzari at mit.edu http://quasiamore.mit.edu


From giannozz at nest.sns.it  Mon Apr 10 18:19:01 2006
From: giannozz at nest.sns.it (Paolo Giannozzi)
Date: Mon, 10 Apr 2006 18:19:01 +0200
Subject: [Pw_forum] error on phonon calculation  (root not converged)
In-Reply-To: <443A7B2B.4060202@ncsu.edu>
References: <20060407150924.61726.qmail@web60325.mail.yahoo.com> <443A4FC9.7090608@mit.edu> <443A7B2B.4060202@ncsu.edu>
Message-ID: <200604101819.01557.giannozz@nest.sns.it>

On Monday 10 April 2006 17:35, Liping YU wrote:

> Actually, for 1e-18, though unconvergence message came up
> in phonon calculation, the dielectric constant I got (see below) 
> was pretty close to 1.0e-10  in the same 2*2*1 supercell.
>
> (2x2x1, tr2_ph=1.0e-18, alpha_mix=0.1)
> ( 222.132924025 0.000000000 0.000000000 )
> ( 0.000000000 222.132924025 0.000000000 )
> ( 0.000000000 0.000000000 6.253206744 )
>
> (2x2x1, tr2_ph=1.0e-10, apha_mix=0.1)
> ( 222.139158023 0.000000000 0.000000000 )
> ( 0.000000000 222.139158023 0.000000000 )
> ( 0.000000000 0.000000000 6.262166130 )

so it is not a problem of convergence. Such large values of the
dielectric constants mean that the gap is very small.

> (1x1x1, tr_ph=1.0e-18, alpha_mix=0.7)
> ( 6.296436141 0.000000000 0.000000000 )
> ( 0.000000000 6.296436141 0.000000000 )
> ( 0.000000000 0.000000000 6.296436141 ).

If you do a supercell calculation with same atomic positions and 
equivalent k-point grid as in the original cell, you should get the 
same Kohn-Sham eigenvalues (refolded into the appropriate 
k-points) and four time the energy of the original cell. If you don't, 
please check very carefully your data.

Paolo
-- 
Paolo Giannozzi             e-mail:  giannozz at nest.sns.it
Scuola Normale Superiore    Phone:   +39/050-509876, Fax:-563513 
Piazza dei Cavalieri 7      I-56126 Pisa, Italy


From lyu7 at ncsu.edu  Mon Apr 10 19:12:55 2006
From: lyu7 at ncsu.edu (Liping YU)
Date: Mon, 10 Apr 2006 13:12:55 -0400
Subject: [Pw_forum] error on phonon calculation  (root not converged)
In-Reply-To: <443A7E77.3000004@mit.edu>
References: <20060407150924.61726.qmail@web60325.mail.yahoo.com> <4439515D.2050505@ncsu.edu> <200604101422.15850.giannozz@nest.sns.it> <443A4FC9.7090608@mit.edu> <443A7B2B.4060202@ncsu.edu> <443A7E77.3000004@mit.edu>
Message-ID: <443A9217.10309@ncsu.edu>

Nicola Marzari wrote:

>>I have a feeling (could be wrong) that this might be due to LDA-PP of
>>Strontium.
>>Since i did the same calculation for PbTiO3 using the same PPs of Ti and
>>O as
>>those in SrTiO3 and it worked well. So I appreciate if someone could
>>send me
>>your Sr LDA-PP (if you have one) that i could try.
>>    
>>
>
>
>Hi Liping,
>
>it's indeed baffling. Do check that your coordinates are scaled
>correctly - i.e. that the atoms in cartesian coordinates are
>were they should be, that the axes are what they should be.
>  
>
Yes. see below:
1x1x1:
bravais-lattice index = 1
lattice parameter (a_0) = 7.2766 a.u.
unit-cell volume = 385.2939 (a.u.)^3
number of atoms/cell = 5
number of atomic types = 3
kinetic-energy cutoff = 30.0000 Ry
charge density cutoff = 270.0000 Ry
convergence threshold = 1.0E-08
beta = 0.7000
number of iterations used = 8 plain mixing
Exchange-correlation = SLA PZ NOGX NOGC (1100)
celldm(1)= 7.276637 celldm(2)= 0.000000 celldm(3)= 0.000000
celldm(4)= 0.000000 celldm(5)= 0.000000 celldm(6)= 0.000000

crystal axes: (cart. coord. in units of a_0)
a(1) = ( 1.000000 0.000000 0.000000 )
a(2) = ( 0.000000 1.000000 0.000000 )
a(3) = ( 0.000000 0.000000 1.000000 )
......

Cartesian axes

site n. atom positions (a_0 units)
1 Sr tau( 1) = ( 0.0000000 0.0000000 0.0000000 )
2 Ti tau( 2) = ( 0.5000000 0.5000000 0.5000000 )
3 O tau( 3) = ( 0.0000000 0.5000000 0.5000000 )
4 O tau( 4) = ( 0.5000000 0.0000000 0.5000000 )
5 O tau( 5) = ( 0.5000000 0.5000000 0.0000000 )

2x2x1
bravais-lattice index = 6
lattice parameter (a_0) = 14.5533 a.u.
unit-cell volume = 1541.1754 (a.u.)^3
number of atoms/cell = 20
number of atomic types = 3
kinetic-energy cutoff = 30.0000 Ry
charge density cutoff = 270.0000 Ry
convergence threshold = 1.0E-08
beta = 0.7000
number of iterations used = 8 plain mixing
Exchange-correlation = SLA PZ NOGX NOGC (1100)
celldm(1)= 14.553273 celldm(2)= 0.000000 celldm(3)= 0.500000
celldm(4)= 0.000000 celldm(5)= 0.000000 celldm(6)= 0.000000

crystal axes: (cart. coord. in units of a_0)
a(1) = ( 1.000000 0.000000 0.000000 )
a(2) = ( 0.000000 1.000000 0.000000 )
a(3) = ( 0.000000 0.000000 0.500000 )
...,,,

Cartesian axes

site n. atom positions (a_0 units)
1 Sr tau( 1) = ( 0.0000000 0.0000000 0.0000000 )
2 Sr tau( 2) = ( 0.5000000 0.0000000 0.0000000 )
3 Sr tau( 3) = ( 0.0000000 0.5000000 0.0000000 )
4 Sr tau( 4) = ( 0.5000000 0.5000000 0.0000000 )
5 O tau( 5) = ( 0.2500000 0.2500000 0.0000000 )
6 O tau( 6) = ( 0.2500000 0.7500000 0.0000000 )
7 O tau( 7) = ( 0.7500000 0.2500000 0.0000000 )
8 O tau( 8) = ( 0.7500000 0.7500000 0.0000000 )
9 Ti tau( 9) = ( 0.2500000 0.2500000 0.2500000 )
10 Ti tau( 10) = ( 0.2500000 0.7500000 0.2500000 )
11 Ti tau( 11) = ( 0.7500000 0.2500000 0.2500000 )
12 Ti tau( 12) = ( 0.7500000 0.7500000 0.2500000 )
13 O tau( 13) = ( 0.0000000 0.2500000 0.2500000 )
14 O tau( 14) = ( 0.0000000 0.7500000 0.2500000 )
15 O tau( 15) = ( 0.5000000 0.2500000 0.2500000 )
16 O tau( 16) = ( 0.5000000 0.7500000 0.2500000 )
17 O tau( 17) = ( 0.2500000 0.0000000 0.2500000 )
18 O tau( 18) = ( 0.7500000 0.0000000 0.2500000 )
19 O tau( 19) = ( 0.2500000 0.5000000 0.2500000 )
20 O tau( 20) = ( 0.7500000 0.5000000 0.2500000 )

>Next, if you use the same identical input files, but you put
>Pb instead of Sr, do you get identical dielectric constants
>from 1x1x1 and 2x2x1 ?
>  
>
No, for PbTiO3, it's tetragonal structure, not cubic one as SrTiO3. The
followings are
dielectric constants of PTO in tetragonal 1x1x1 unit cell and 2x2x1
supercell.
Note for no reason I used 4x4x4 k-point grid for both unit cell and
super cells.

1x1x1 unit cell,
( 7.981121520 0.000000000 0.000000000 )
( 0.000000000 7.981121520 0.000000000 )
( 0.000000000 0.000000000 7.542263658 )

2x2x1 supercell,
( 7.775208874 0.000000000 0.000000000 )
( 0.000000000 7.775208874 0.000000000 )
( 0.000000000 0.000000000 7.491522972 )

Maybe I should also try same k-point (4x4x4) sampling for SrTiO3 in two
different cells, although they are not equivalent, and see what will happen.

Also I'll try what you suggested. Thank you very much!

>If you do, I admit that one would be tempted to blame the
>pseudopotential, but it is still unlikely. Have a look at the
>eigenvalues in the two calculations - do they match exactly ?
>
>Let us know what you find,
>
>			nicola
>
>---------------------------------------------------------------------
>Prof Nicola Marzari   Department of Materials Science and Engineering
>13-5066   MIT   77 Massachusetts Avenue   Cambridge MA 02139-4307 USA
>tel 617.4522758 fax 2586534 marzari at mit.edu http://quasiamore.mit.edu
>_______________________________________________
>Pw_forum mailing list
>Pw_forum at pwscf.org
>http://www.democritos.it/mailman/listinfo/pw_forum
>  
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/attachments/20060410/27ba4c3d/attachment.htm 

From marzari at MIT.EDU  Mon Apr 10 19:25:27 2006
From: marzari at MIT.EDU (Nicola Marzari)
Date: Mon, 10 Apr 2006 19:25:27 +0200
Subject: [Pw_forum] error on phonon calculation  (root not converged)
In-Reply-To: <443A9217.10309@ncsu.edu>
References: <20060407150924.61726.qmail@web60325.mail.yahoo.com> <4439515D.2050505@ncsu.edu> <200604101422.15850.giannozz@nest.sns.it> <443A4FC9.7090608@mit.edu> <443A7B2B.4060202@ncsu.edu> <443A7E77.3000004@mit.edu> <443A9217.10309@ncsu.edu>
Message-ID: <443A9507.9060209@mit.edu>

>>Next, if you use the same identical input files, but you put
>>Pb instead of Sr, do you get identical dielectric constants
>>from 1x1x1 and 2x2x1 ?
>>  
>>
> No, for PbTiO3, it's tetragonal structure, not cubic one as SrTiO3. 

I know - I just wanted to make the point that if there were something
odd with the pseudopotential (although I do not know what - a ghost
state ? Even that is unlikey to appear in only one of the two
calculations) you could use the exact SrTiO3 input files, but just put
Pb instead of Sr.

> Note for no reason I used 4x4x4 k-point grid for both unit cell and 
> super cells.
> 
> 1x1x1 unit cell,
>     (       7.981121520       0.000000000       0.000000000 )
>     (       0.000000000       7.981121520       0.000000000 )
>     (       0.000000000       0.000000000       7.542263658 )
> 
> 2x2x1 supercell,
>     (       7.775208874       0.000000000       0.000000000 )
>     (       0.000000000       7.775208874       0.000000000 )
>     (       0.000000000       0.000000000       7.491522972 )
> 
> Maybe I should also try same k-point (4x4x4) sampling for SrTiO3 in two
> different cells, although they are not equivalent, and see what will happen.
> 


OK, this could show you if there were some odd problem with the
calculation with the larger number of kpoints. Also, make sure
oyu have no leftovers from previous calculations, i.e. your directories
are clean.

			nicola

---------------------------------------------------------------------
Prof Nicola Marzari   Department of Materials Science and Engineering
13-5066   MIT   77 Massachusetts Avenue   Cambridge MA 02139-4307 USA
tel 617.4522758 fax 2586534 marzari at mit.edu http://quasiamore.mit.edu


From lyu7 at ncsu.edu  Mon Apr 10 19:31:05 2006
From: lyu7 at ncsu.edu (Liping YU)
Date: Mon, 10 Apr 2006 13:31:05 -0400
Subject: [Pw_forum] error on phonon calculation  (root not converged)
In-Reply-To: <200604101819.01557.giannozz@nest.sns.it>
References: <20060407150924.61726.qmail@web60325.mail.yahoo.com> <443A4FC9.7090608@mit.edu> <443A7B2B.4060202@ncsu.edu> <200604101819.01557.giannozz@nest.sns.it>
Message-ID: <443A9659.6030207@ncsu.edu>

Paolo Giannozzi wrote:

>On Monday 10 April 2006 17:35, Liping YU wrote:
>
>  
>
>>Actually, for 1e-18, though unconvergence message came up
>>in phonon calculation, the dielectric constant I got (see below) 
>>was pretty close to 1.0e-10  in the same 2*2*1 supercell.
>>
>>(2x2x1, tr2_ph=1.0e-18, alpha_mix=0.1)
>>( 222.132924025 0.000000000 0.000000000 )
>>( 0.000000000 222.132924025 0.000000000 )
>>( 0.000000000 0.000000000 6.253206744 )
>>
>>(2x2x1, tr2_ph=1.0e-10, apha_mix=0.1)
>>( 222.139158023 0.000000000 0.000000000 )
>>( 0.000000000 222.139158023 0.000000000 )
>>( 0.000000000 0.000000000 6.262166130 )
>>    
>>
>
>so it is not a problem of convergence. Such large values of the
>dielectric constants mean that the gap is very small.
>
>  
>
>>(1x1x1, tr_ph=1.0e-18, alpha_mix=0.7)
>>( 6.296436141 0.000000000 0.000000000 )
>>( 0.000000000 6.296436141 0.000000000 )
>>( 0.000000000 0.000000000 6.296436141 ).
>>    
>>
>
>If you do a supercell calculation with same atomic positions and 
>equivalent k-point grid as in the original cell, you should get the 
>same Kohn-Sham eigenvalues (refolded into the appropriate 
>k-points) and four time the energy of the original cell. If you don't, 
>please check very carefully your data.
>  
>

1x1x1 cell
Total energy: -275.21362101 ( *4= -1100.85448404 )

k = 0.0000 0.0000 0.0000 ( 1045 PWs) bands (ev):

-45.3707 -22.1221 -21.9779 -21.9779 -21.9779 -7.0142 -5.9530 -5.9530
-4.1784 -4.1784 -4.1784 7.3984 7.3984 7.3984 9.0084 9.0084
9.0084 9.9455 9.9455 9.9455

2x2x1 super cell
Total envergy: -1100.81820918

k = 0.0000 0.0000 0.0000 ( 4189 PWs) bands (ev):

-45.2796 -45.2775 -45.2775 -45.2757 -22.1971 -22.1971 -22.1306 -22.0751
-21.9837 -21.9837 -21.8962 -21.8962 -21.8923 -21.8923 -21.8880 -21.8880
-21.8847 -21.8808 -21.8808 -21.8782 -7.3110 -7.3110 -7.0254 -6.2803
-6.1254 -6.1254 -5.9895 -5.9369 -5.9001 -5.9001 -5.5665 -5.5665
-4.1921 -4.1844 -4.1844 -4.1328 -4.1328 -4.1254 -4.1254 -4.0581
-3.6727 -3.6727 -3.4773 -3.4773 5.2683 5.5759 5.7750 5.7750
5.8965 7.1769 7.1769 7.3059 7.3059 7.3148 7.3148 7.3862
7.3862 7.4078 7.6449 7.6449 7.7312 7.7312 7.7554 7.7554
8.0881 8.0881 8.6134 8.6800 8.6800 8.9788 8.9973 8.9973
9.5426 9.5426 9.5604 9.5604 9.9266 9.9266 9.9563 10.1162

The total energies of them are very close. The largest eigenvalues at gamma
differs from each other about 10.1162- 9.9455 = 0.1707. Is this could be
reseason



From marzari at MIT.EDU  Mon Apr 10 19:45:08 2006
From: marzari at MIT.EDU (Nicola Marzari)
Date: Mon, 10 Apr 2006 19:45:08 +0200
Subject: [Pw_forum] error on phonon calculation  (root not converged)
In-Reply-To: <443A9659.6030207@ncsu.edu>
References: <20060407150924.61726.qmail@web60325.mail.yahoo.com> <443A4FC9.7090608@mit.edu> <443A7B2B.4060202@ncsu.edu> <200604101819.01557.giannozz@nest.sns.it> <443A9659.6030207@ncsu.edu>
Message-ID: <443A99A4.1000805@mit.edu>

> k = 0.0000 0.0000 0.0000 ( 1045 PWs) bands (ev):
> 
> -45.3707 -22.1221 -21.9779 -21.9779 -21.9779 -7.0142 -5.9530 -5.9530
> -4.1784 -4.1784 -4.1784 7.3984 7.3984 7.3984 9.0084 9.0084
> 9.0084 9.9455 9.9455 9.9455
> 
> 2x2x1 super cell
> Total envergy: -1100.81820918
> 
> k = 0.0000 0.0000 0.0000 ( 4189 PWs) bands (ev):
> 
> -45.2796 -45.2775 -45.2775 -45.2757 -22.1971 -22.1971 -22.1306 -22.0751
> -21.9837 -21.9837 -21.8962 -21.8962 -21.8923 -21.8923 -21.8880 -21.8880
> -21.8847 -21.8808 -21.8808 -21.8782 -7.3110 -7.3110 -7.0254 -6.2803
> -6.1254 -6.1254 -5.9895 -5.9369 -5.9001 -5.9001 -5.5665 -5.5665
> -4.1921 -4.1844 -4.1844 -4.1328 -4.1328 -4.1254 -4.1254 -4.0581
> -3.6727 -3.6727 -3.4773 -3.4773 5.2683 5.5759 5.7750 5.7750
> 5.8965 7.1769 7.1769 7.3059 7.3059 7.3148 7.3148 7.3862
> 7.3862 7.4078 7.6449 7.6449 7.7312 7.7312 7.7554 7.7554
> 8.0881 8.0881 8.6134 8.6800 8.6800 8.9788 8.9973 8.9973
> 9.5426 9.5426 9.5604 9.5604 9.9266 9.9266 9.9563 10.1162
> 
> The total energies of them are very close. The largest eigenvalues at gamma
> differs from each other about 10.1162- 9.9455 = 0.1707. Is this could be
> reseason

no, probably not. In the 1x1x1 supercell you need to collect the
4 kpoints that are equivalent to gamma in the 2x2x1 supercell, and only
then check. but the discrepnacies are likely to be smaller that
0.17 eV (I am not sure on how the ewald terms are calculated in
pw - Paolo circulated a document a few days ago. Depending on that,
you might require a shift of .1 eV in the eigenvalues, between the two
supercells, to match).

Still, no solution in sight.

			nicola

---------------------------------------------------------------------
Prof Nicola Marzari   Department of Materials Science and Engineering
13-5066   MIT   77 Massachusetts Avenue   Cambridge MA 02139-4307 USA
tel 617.4522758 fax 2586534 marzari at mit.edu http://quasiamore.mit.edu


From giannozz at nest.sns.it  Mon Apr 10 19:56:24 2006
From: giannozz at nest.sns.it (Paolo Giannozzi)
Date: Mon, 10 Apr 2006 19:56:24 +0200
Subject: [Pw_forum] error on phonon calculation  (root not converged)
In-Reply-To: <443A9659.6030207@ncsu.edu>
References: <20060407150924.61726.qmail@web60325.mail.yahoo.com> <200604101819.01557.giannozz@nest.sns.it> <443A9659.6030207@ncsu.edu>
Message-ID: <200604101956.24764.giannozz@nest.sns.it>

On Monday 10 April 2006 19:31, Liping YU wrote:

> 1x1x1 cell
> Total energy: -275.21362101 ( *4= -1100.85448404 )

> k = 0.0000 0.0000 0.0000 ( 1045 PWs) bands (ev):

> -45.3707 [...]

> 2x2x1 super cell
> Total energy: -1100.81820918

> k = 0.0000 0.0000 0.0000 ( 4189 PWs) bands (ev):

> -45.2796 -45.2775 -45.2775 -45.2757 [...]

total energies per cell are not the same. Also eigenvalues are clearly 
not the same. Your 2x2x1 supercell is not 4 times a 1x1x1 cell.

P.
-- 
Paolo Giannozzi             e-mail:  giannozz at nest.sns.it
Scuola Normale Superiore    Phone:   +39/050-509876, Fax:-563513 
Piazza dei Cavalieri 7      I-56126 Pisa, Italy


From davegp at civet.berkeley.edu  Mon Apr 10 21:34:58 2006
From: davegp at civet.berkeley.edu (David Prendergast)
Date: Mon, 10 Apr 2006 12:34:58 -0700
Subject: [Pw_forum] [Fwd: help]
Message-ID: <443AB362.3030106@civet.berkeley.edu>


-------- Original Message --------
Subject: 	help
Date: 	Tue, 11 Apr 2006 00:59:38 +0530 (IST)
From: 	Heydar Ali Shafiei Gol <shafiei at physics.unipune.ernet.in>
To: 	davegp at civet.berkeley.edu



Dear Sir

Iam Ph.D student in pune university ,India .I work with PWSCF code and
 want to use of MD (for the ground  of state  clusters) .Now, after
several months that I want to start the most important my job ,I have a
problem  ,  what are options  for :
a-Inital temperature
b-final  temperature
c-increasing temperature between  a and b

Since ,there are not anybody in here that work with it ,please help me .
I would appreciate  receiving  any information you about it .


Thank you so much for your time

shafiei




-- 
OoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOo
  David Prendergast
  University of California, Berkeley             phone: (510) 642-2635
  Department of Physics                          fax:   (510) 643-9473
  366 LeConte Hall #7300              email: davegp at civet.berkeley.edu
  Berkeley, CA 94720-7300       web: http://civet.berkeley.edu/~davegp
OoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOo



From halim_said04 at yahoo.fr  Tue Apr 11 02:11:02 2006
From: halim_said04 at yahoo.fr (halim said)
Date: Tue, 11 Apr 2006 02:11:02 +0200 (CEST)
Subject: [Pw_forum] RE: Welcome to the "Pw_forum" mailing list
In-Reply-To: <20060411000902.4247.2694.Mailman@democritos.sissa.it>
Message-ID: <20060411001102.56308.qmail@web25808.mail.ukl.yahoo.com>



pw_forum-request at pwscf.org a ?crit :  Welcome to the Pw_forum at pwscf.org mailing list!

To post to this list, send your email to:

pw_forum at pwscf.org

General information about the mailing list is at:

http://www.democritos.it/mailman/listinfo/pw_forum

If you ever want to unsubscribe or change your options (eg, switch to
or from digest mode, change your password, etc.), visit your
subscription page at:

http://www.democritos.it/mailman/options/pw_forum/halim_said04%40yahoo.fr


You can also make such adjustments via email by sending a message to:

Pw_forum-request at pwscf.org

with the word `help' in the subject or body (don't include the
quotes), and you will get back a message with instructions.

You must know your password to change your options (including changing
the password, itself) or to unsubscribe. It is:

freedom

If you forget your password, don't worry, you will receive a monthly
reminder telling you what all your pwscf.org mailing list passwords
are, and how to unsubscribe or change your options. There is also a
button on your options page that will email your current password to
you.

You may also have your password mailed to you automatically from the
Web page noted above.


		
---------------------------------
 Nouveau : t?l?phonez moins cher avec Yahoo! Messenger ! D?couvez les tarifs exceptionnels pour appeler la France et l'international.T?l?chargez la version beta.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/attachments/20060411/51c6126d/attachment.htm 

From halim_said04 at yahoo.fr  Tue Apr 11 03:24:03 2006
From: halim_said04 at yahoo.fr (halim said)
Date: Tue, 11 Apr 2006 03:24:03 +0200 (CEST)
Subject: [Pw_forum] RE: Welcome to the "Pw_forum" mailing list
In-Reply-To: <20060411001102.56308.qmail@web25808.mail.ukl.yahoo.com>
Message-ID: <20060411012403.57249.qmail@web25801.mail.ukl.yahoo.com>

Dear All,
   
   
  I would like to plot the projected density from the decomposition of 
projected density of sates  d orbitals into eg and t2g states, does some know how to do it? also which program shoud I use. 

2.Also  I want to get the projected charge density for each orbital s, p, t2g, and eg, could you tell how to do it? and which program should I use.
   
  Could some one explain me ?
   
  Your help is highly appreciate.
   
  Regards,
   
  Halim Said,
  Dept of Phys,
  Soussa, Tunisia

		
---------------------------------
 Nouveau : t?l?phonez moins cher avec Yahoo! Messenger ! D?couvez les tarifs exceptionnels pour appeler la France et l'international.T?l?chargez la version beta.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/attachments/20060411/4d7bb79d/attachment.htm 

From silviu at Princeton.EDU  Tue Apr 11 17:53:34 2006
From: silviu at Princeton.EDU (Silviu Zilberman)
Date: Tue, 11 Apr 2006 11:53:34 -0400
Subject: [Pw_forum] [Fwd: help]
In-Reply-To: <443AB362.3030106@civet.berkeley.edu>
References: <443AB362.3030106@civet.berkeley.edu>
Message-ID: <443BD0FE.6010303@Princeton.EDU>

If you just want to reach some final temperature, it's should be enough 
to specify the temperature and the Nose thermostat in the input file. If 
you wish to do gradual ramping of the temperature (say for thermodynamic 
integration), I think that the only way in PW is to specify intermediate 
temperatures, equilibrate at these temperatures and raise to the next 
temperature manually.

In the CP code you can easily do automatic temperature ramping using the 
auto pilot functionality. Read the documentation in README.AUTOPILOT.

Silviu.

David Prendergast wrote:

>
>
> -------- Original Message --------
> Subject:     help
> Date:     Tue, 11 Apr 2006 00:59:38 +0530 (IST)
> From:     Heydar Ali Shafiei Gol <shafiei at physics.unipune.ernet.in>
> To:     davegp at civet.berkeley.edu
>
>
>
> Dear Sir
>
> Iam Ph.D student in pune university ,India .I work with PWSCF code and
> want to use of MD (for the ground  of state  clusters) .Now, after
> several months that I want to start the most important my job ,I have a
> problem  ,  what are options  for :
> a-Inital temperature
> b-final  temperature
> c-increasing temperature between  a and b
>
> Since ,there are not anybody in here that work with it ,please help me .
> I would appreciate  receiving  any information you about it .
>
>
> Thank you so much for your time
>
> shafiei
>
>
>
>



From scandolo at ictp.it  Tue Apr 11 17:56:35 2006
From: scandolo at ictp.it (Sandro Scandolo)
Date: Tue, 11 Apr 2006 17:56:35 +0200
Subject: [Pw_forum] Re: vanderwaals
Message-ID: <443BD1B3.6090200@ictp.it>

Nichols,

unfortunately this is not the vdW functional of Langreth et al.

It is a much simpler procedure to correct the DFT forces and stress 
for the missing 1/R^6 tail. It consists of adding to the DFT forces 
and stress a classical interatomic force field that decays at long 
distances like 1/R^6 (with the appropriate C6 coefficients), and 
vanishes at "short" distances, i.e. at interatomic distances where 
one expects DFT to give the correct forces. This is done in a smooth 
fashion, of course. It requires a cut-off distance, a smoothing 
parameter, and the C_ij coefficients for any pair i,j of species.
The present implementation is system-specific (for a C-H saturated
system) but can trivially be extended for any system. More details 
can be found in S. Serra et al, Chem Phys Lett 331, 339 (2000)

Regards,
Sandro

*

From: Nichols A. Romero* <mailto:pw_forum%40pwscf.org>
/Mon, 3 Apr 2006 10:46:19 -0400/

Hi,

In CP source, there is a file called
vanderwaals.f90

Is this the vdW functional of D. Langreth et. al?

Bests,
--
Nichols A. Romero, Ph.D.
1613 Denise Dr. Apt. D
Forest Hill, MD 21050
443-567-8328 (C)
410-306-0709 (O)



From stewart at cnf.cornell.edu  Tue Apr 11 20:45:42 2006
From: stewart at cnf.cornell.edu (stewart at cnf.cornell.edu)
Date: Tue, 11 Apr 2006 14:45:42 -0400
Subject: [Pw_forum] Phonon frequencies different for equivalent q points
In-Reply-To: <443BD1B3.6090200@ictp.it>
References: <443BD1B3.6090200@ictp.it>
Message-ID: <20060411184542.11682.qmail@xuxa.iecc.com>

Hi everyone, 

   I have been running some phonon calculations for an hcp Pd system and I 
am running into a problem. 

I am looking at the high symmetry lines, Gamma-K-M along the [x,x,0] 
direction going from [0,0,0] to [1,1,0]*(2pi/a) and the Gamma-M line along 
the [x,0,0] going from [0,0,0] to [1/sqrt(3),0,0]*(2pi/a). 

The phonon frequencies predicted at the M point for each calculation 

[1,1,0]*(2pi/a) and [1/sqrt(3),0,0]*(2pi/a) should be equivalent. 

However, they are fairly different.
[1,1,0] 

    omega( 1) =       2.805385 [THz] =      93.578178 [cm-1]
    omega( 2) =       3.004742 [THz] =     100.228087 [cm-1]
    omega( 3) =       4.199464 [THz] =     140.079956 [cm-1]
    omega( 4) =       5.667289 [THz] =     189.041683 [cm-1]
    omega( 5) =       5.820376 [THz] =     194.148127 [cm-1]
    omega( 6) =       6.358473 [THz] =     212.097247 [cm-1] 


[1/sqrt(3),0,0] 

    omega( 1) =       3.747138 [THz] =     124.991899 [cm-1]
    omega( 2) =       4.763040 [THz] =     158.878972 [cm-1]
    omega( 3) =       4.797494 [THz] =     160.028243 [cm-1]
    omega( 4) =       5.155421 [THz] =     171.967476 [cm-1]
    omega( 5) =       5.867315 [THz] =     195.713877 [cm-1]
    omega( 6) =       6.220546 [THz] =     207.496457 [cm-1] 

Now hcp Pd only exists as small films on special substrates.  Normally, Pd 
is fcc.  However, the rest of the phonon dispersion curve looks fine (no 
imaginary data points).  I am using ecutwfc=44.0 and ecutrho=448 for my scf 
calculations with a 20x20x16 k-point grid.  The total stress on my relaxed 
system is 0.09 kbar so I don't think that is the issue. 

For the phonon calculations, my input is as follows 

phonons of pd at 1.00
&inputph
   tr2_ph=1.0d-14,
   alpha_mix(1)=0.7,
   prefix='pd',
   amass(1)=106.42,
   fildyn='pd.dyn1.00',
/
1.00 1.00 0.00 

I am using espresso-3.0.  Are there any changes in the CVS version that 
would affect this calculation? 

Any suggestions or thoughts would be greatly appreciated! 

Thanks, 

Derek 


################################
Derek Stewart, Ph. D.
Scientific Computation Associate
250 Duffield Hall
Cornell Nanoscale Facility (CNF)
Ithaca, NY 14853
stewart (at) cnf.cornell.edu
(607) 255-2856 



From eyvaz_isaev at yahoo.com  Tue Apr 11 21:24:51 2006
From: eyvaz_isaev at yahoo.com (Eyvaz Isaev)
Date: Tue, 11 Apr 2006 12:24:51 -0700 (PDT)
Subject: [Pw_forum] Phonon frequencies different for equivalent q points
In-Reply-To: <20060411184542.11682.qmail@xuxa.iecc.com>
Message-ID: <20060411192451.26641.qmail@web60319.mail.yahoo.com>

Hi Derek,

Might it be that you used k-points in direct
coordinates instead of cartesian? 

Bests,
Eyvaz.

--- stewart at cnf.cornell.edu wrote:

> Hi everyone, 
> 
>    I have been running some phonon calculations for
> an hcp Pd system and I 
> am running into a problem. 
> 
> I am looking at the high symmetry lines, Gamma-K-M
> along the [x,x,0] 
> direction going from [0,0,0] to [1,1,0]*(2pi/a) and
> the Gamma-M line along 
> the [x,0,0] going from [0,0,0] to
> [1/sqrt(3),0,0]*(2pi/a). 
> 
> The phonon frequencies predicted at the M point for
> each calculation 
> 
> [1,1,0]*(2pi/a) and [1/sqrt(3),0,0]*(2pi/a) should
> be equivalent. 
> 
> However, they are fairly different.
> [1,1,0] 
> 
>     omega( 1) =       2.805385 [THz] =     
> 93.578178 [cm-1]
>     omega( 2) =       3.004742 [THz] =    
> 100.228087 [cm-1]
>     omega( 3) =       4.199464 [THz] =    
> 140.079956 [cm-1]
>     omega( 4) =       5.667289 [THz] =    
> 189.041683 [cm-1]
>     omega( 5) =       5.820376 [THz] =    
> 194.148127 [cm-1]
>     omega( 6) =       6.358473 [THz] =    
> 212.097247 [cm-1] 
> 
> 
> [1/sqrt(3),0,0] 
> 
>     omega( 1) =       3.747138 [THz] =    
> 124.991899 [cm-1]
>     omega( 2) =       4.763040 [THz] =    
> 158.878972 [cm-1]
>     omega( 3) =       4.797494 [THz] =    
> 160.028243 [cm-1]
>     omega( 4) =       5.155421 [THz] =    
> 171.967476 [cm-1]
>     omega( 5) =       5.867315 [THz] =    
> 195.713877 [cm-1]
>     omega( 6) =       6.220546 [THz] =    
> 207.496457 [cm-1] 
> 
> Now hcp Pd only exists as small films on special
> substrates.  Normally, Pd 
> is fcc.  However, the rest of the phonon dispersion
> curve looks fine (no 
> imaginary data points).  I am using ecutwfc=44.0 and
> ecutrho=448 for my scf 
> calculations with a 20x20x16 k-point grid.  The
> total stress on my relaxed 
> system is 0.09 kbar so I don't think that is the
> issue. 
> 
> For the phonon calculations, my input is as follows 
> 
> phonons of pd at 1.00
> &inputph
>    tr2_ph=1.0d-14,
>    alpha_mix(1)=0.7,
>    prefix='pd',
>    amass(1)=106.42,
>    fildyn='pd.dyn1.00',
> /
> 1.00 1.00 0.00 
> 
> I am using espresso-3.0.  Are there any changes in
> the CVS version that 
> would affect this calculation? 
> 
> Any suggestions or thoughts would be greatly
> appreciated! 
> 
> Thanks, 
> 
> Derek 
> 
> 
> ################################
> Derek Stewart, Ph. D.
> Scientific Computation Associate
> 250 Duffield Hall
> Cornell Nanoscale Facility (CNF)
> Ithaca, NY 14853
> stewart (at) cnf.cornell.edu
> (607) 255-2856 
> 
> _______________________________________________
> Pw_forum mailing list
> Pw_forum at pwscf.org
> http://www.democritos.it/mailman/listinfo/pw_forum
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


From davegp at civet.berkeley.edu  Tue Apr 11 21:32:45 2006
From: davegp at civet.berkeley.edu (David Prendergast)
Date: Tue, 11 Apr 2006 12:32:45 -0700
Subject: [Pw_forum] Small typo in espresso-3.0 ./configure script
Message-ID: <443C045D.5080806@civet.berkeley.edu>

For those attempting to configure espresso-3.0 on AIX or IBM machines, 
you will notice an error related to linking the MASSV function vexp.
There is a typo located at line 5875 in ./configure
The option -or is not valid for test. Replace this with -o.

Details:

In the espresso directory
$grep -n '\-or' ./configure
5875:                           -or "$ac_cv_search_vexp" = "-lmassv"
$mv ./configure ./configure.bak
$sed 's/\-or/\-o/' ./configure.bak > ./configure

Done


-- 
OoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOo
  David Prendergast
  University of California, Berkeley             phone: (510) 642-2635
  Department of Physics                          fax:   (510) 643-9473
  366 LeConte Hall #7300              email: davegp at civet.berkeley.edu
  Berkeley, CA 94720-7300      web: http://civet.berkeley.edu/~davegp/
OoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOo



From stewart at cnf.cornell.edu  Tue Apr 11 21:54:29 2006
From: stewart at cnf.cornell.edu (stewart at cnf.cornell.edu)
Date: Tue, 11 Apr 2006 15:54:29 -0400
Subject: [Pw_forum] Re: Phonon frequencies different for equivalent q points
In-Reply-To: <20060411192451.26641.qmail@web60319.mail.yahoo.com>
References: <20060411192451.26641.qmail@web60319.mail.yahoo.com>
Message-ID: <20060411195429.1308.qmail@xuxa.iecc.com>

Hi Eyvaz, 

   For my calculations, I specified the phonon q-vector in the nscf 
calculation in units of (2pi/a).  For both calculations, the k-points were 
calculated using 

K_POINTS {automatic}
20 20 16 0 0 0 

I believe this is the standard way to do these calculations.  Am I missing 
something? 

Regards, 

Derek 

Eyvaz Isaev writes: 

> Hi Derek, 
> 
> Might it be that you used k-points in direct
> coordinates instead of cartesian?  
> 
> Bests,
> Eyvaz. 
> 
> --- stewart at cnf.cornell.edu wrote: 
> 
>> Hi everyone,  
>> 
>>    I have been running some phonon calculations for
>> an hcp Pd system and I 
>> am running into a problem.  
>> 
>> I am looking at the high symmetry lines, Gamma-K-M
>> along the [x,x,0] 
>> direction going from [0,0,0] to [1,1,0]*(2pi/a) and
>> the Gamma-M line along 
>> the [x,0,0] going from [0,0,0] to
>> [1/sqrt(3),0,0]*(2pi/a).  
>> 
>> The phonon frequencies predicted at the M point for
>> each calculation  
>> 
>> [1,1,0]*(2pi/a) and [1/sqrt(3),0,0]*(2pi/a) should
>> be equivalent.  
>> 
>> However, they are fairly different.
>> [1,1,0]  
>> 
>>     omega( 1) =       2.805385 [THz] =     
>> 93.578178 [cm-1]
>>     omega( 2) =       3.004742 [THz] =    
>> 100.228087 [cm-1]
>>     omega( 3) =       4.199464 [THz] =    
>> 140.079956 [cm-1]
>>     omega( 4) =       5.667289 [THz] =    
>> 189.041683 [cm-1]
>>     omega( 5) =       5.820376 [THz] =    
>> 194.148127 [cm-1]
>>     omega( 6) =       6.358473 [THz] =    
>> 212.097247 [cm-1]  
>> 
>> 
>> [1/sqrt(3),0,0]  
>> 
>>     omega( 1) =       3.747138 [THz] =    
>> 124.991899 [cm-1]
>>     omega( 2) =       4.763040 [THz] =    
>> 158.878972 [cm-1]
>>     omega( 3) =       4.797494 [THz] =    
>> 160.028243 [cm-1]
>>     omega( 4) =       5.155421 [THz] =    
>> 171.967476 [cm-1]
>>     omega( 5) =       5.867315 [THz] =    
>> 195.713877 [cm-1]
>>     omega( 6) =       6.220546 [THz] =    
>> 207.496457 [cm-1]  
>> 
>> Now hcp Pd only exists as small films on special
>> substrates.  Normally, Pd 
>> is fcc.  However, the rest of the phonon dispersion
>> curve looks fine (no 
>> imaginary data points).  I am using ecutwfc=44.0 and
>> ecutrho=448 for my scf 
>> calculations with a 20x20x16 k-point grid.  The
>> total stress on my relaxed 
>> system is 0.09 kbar so I don't think that is the
>> issue.  
>> 
>> For the phonon calculations, my input is as follows  
>> 
>> phonons of pd at 1.00
>> &inputph
>>    tr2_ph=1.0d-14,
>>    alpha_mix(1)=0.7,
>>    prefix='pd',
>>    amass(1)=106.42,
>>    fildyn='pd.dyn1.00',
>> /
>> 1.00 1.00 0.00  
>> 
>> I am using espresso-3.0.  Are there any changes in
>> the CVS version that 
>> would affect this calculation?  
>> 
>> Any suggestions or thoughts would be greatly
>> appreciated!  
>> 
>> Thanks,  
>> 
>> Derek  
>> 
>> 
>> ################################
>> Derek Stewart, Ph. D.
>> Scientific Computation Associate
>> 250 Duffield Hall
>> Cornell Nanoscale Facility (CNF)
>> Ithaca, NY 14853
>> stewart (at) cnf.cornell.edu
>> (607) 255-2856  
>> 
>> _______________________________________________
>> Pw_forum mailing list
>> Pw_forum at pwscf.org
>> http://www.democritos.it/mailman/listinfo/pw_forum 
>> 
>  
> 
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around 
> http://mail.yahoo.com 
> _______________________________________________
> Pw_forum mailing list
> Pw_forum at pwscf.org
> http://www.democritos.it/mailman/listinfo/pw_forum
 


################################
Derek Stewart, Ph. D.
Scientific Computation Associate
250 Duffield Hall
Cornell Nanoscale Facility (CNF)
Ithaca, NY 14853
stewart (at) cnf.cornell.edu
(607) 255-2856 



From eyvaz_isaev at yahoo.com  Tue Apr 11 22:52:17 2006
From: eyvaz_isaev at yahoo.com (Eyvaz Isaev)
Date: Tue, 11 Apr 2006 13:52:17 -0700 (PDT)
Subject: [Pw_forum] Re: Phonon frequencies different for equivalent q points
In-Reply-To: <20060411195429.1308.qmail@xuxa.iecc.com>
Message-ID: <20060411205217.42728.qmail@web60321.mail.yahoo.com>

Hi again,
 
> For my calculations, I specified the phonon
> q-vector in the nscf 
> calculation in units of (2pi/a).  For both
> calculations, the k-points were calculated using 
> 
> K_POINTS {automatic}
> 20 20 16 0 0 0 
> 
> I believe this is the standard way to do these
> calculations.  Am I missing  something? 

This way  should be OK. I just paid attention that in
your input file for phonons you specified 
(1.0 1.0 0.0)
If this k-point is in your list then it is OK. But I
remember M point's coordinate is (0,1/2,0), or
(1/2,0.2887,0), in units of direct or cartesian
coordinates, respectively. At least, I used this point
for HCP materials (say, Mg or MgB2, and many others)
and I have excellent agreement with experiment.

Bests,
Eyvaz.
 
> Regards, 
> 
> Derek 
> 
> Eyvaz Isaev writes: 
> 
> > Hi Derek, 
> > 
> > Might it be that you used k-points in direct
> > coordinates instead of cartesian?  
> > 
> > Bests,
> > Eyvaz. 
> > 
> > --- stewart at cnf.cornell.edu wrote: 
> > 
> >> Hi everyone,  
> >> 
> >>    I have been running some phonon calculations
> for
> >> an hcp Pd system and I 
> >> am running into a problem.  
> >> 
> >> I am looking at the high symmetry lines,
> Gamma-K-M
> >> along the [x,x,0] 
> >> direction going from [0,0,0] to [1,1,0]*(2pi/a)
> and
> >> the Gamma-M line along 
> >> the [x,0,0] going from [0,0,0] to
> >> [1/sqrt(3),0,0]*(2pi/a).  
> >> 
> >> The phonon frequencies predicted at the M point
> for
> >> each calculation  
> >> 
> >> [1,1,0]*(2pi/a) and [1/sqrt(3),0,0]*(2pi/a)
> should
> >> be equivalent.  
> >> 
> >> However, they are fairly different.
> >> [1,1,0]  
> >> 
> >>     omega( 1) =       2.805385 [THz] =     
> >> 93.578178 [cm-1]
> >>     omega( 2) =       3.004742 [THz] =    
> >> 100.228087 [cm-1]
> >>     omega( 3) =       4.199464 [THz] =    
> >> 140.079956 [cm-1]
> >>     omega( 4) =       5.667289 [THz] =    
> >> 189.041683 [cm-1]
> >>     omega( 5) =       5.820376 [THz] =    
> >> 194.148127 [cm-1]
> >>     omega( 6) =       6.358473 [THz] =    
> >> 212.097247 [cm-1]  
> >> 
> >> 
> >> [1/sqrt(3),0,0]  
> >> 
> >>     omega( 1) =       3.747138 [THz] =    
> >> 124.991899 [cm-1]
> >>     omega( 2) =       4.763040 [THz] =    
> >> 158.878972 [cm-1]
> >>     omega( 3) =       4.797494 [THz] =    
> >> 160.028243 [cm-1]
> >>     omega( 4) =       5.155421 [THz] =    
> >> 171.967476 [cm-1]
> >>     omega( 5) =       5.867315 [THz] =    
> >> 195.713877 [cm-1]
> >>     omega( 6) =       6.220546 [THz] =    
> >> 207.496457 [cm-1]  
> >> 
> >> Now hcp Pd only exists as small films on special
> >> substrates.  Normally, Pd 
> >> is fcc.  However, the rest of the phonon
> dispersion
> >> curve looks fine (no 
> >> imaginary data points).  I am using ecutwfc=44.0
> and
> >> ecutrho=448 for my scf 
> >> calculations with a 20x20x16 k-point grid.  The
> >> total stress on my relaxed 
> >> system is 0.09 kbar so I don't think that is the
> >> issue.  
> >> 
> >> For the phonon calculations, my input is as
> follows  
> >> 
> >> phonons of pd at 1.00
> >> &inputph
> >>    tr2_ph=1.0d-14,
> >>    alpha_mix(1)=0.7,
> >>    prefix='pd',
> >>    amass(1)=106.42,
> >>    fildyn='pd.dyn1.00',
> >> /
> >> 1.00 1.00 0.00  
> >> 
> >> I am using espresso-3.0.  Are there any changes
> in
> >> the CVS version that 
> >> would affect this calculation?  
> >> 
> >> Any suggestions or thoughts would be greatly
> >> appreciated!  
> >> 
> >> Thanks,  
> >> 
> >> Derek  
> >> 
> >> 
> >> ################################
> >> Derek Stewart, Ph. D.
> >> Scientific Computation Associate
> >> 250 Duffield Hall
> >> Cornell Nanoscale Facility (CNF)
> >> Ithaca, NY 14853
> >> stewart (at) cnf.cornell.edu
> >> (607) 255-2856  
> >> 
> >> _______________________________________________
> >> Pw_forum mailing list
> >> Pw_forum at pwscf.org
> >>
> http://www.democritos.it/mailman/listinfo/pw_forum 
> >> 
> >  
> > 
> > __________________________________________________
> > Do You Yahoo!?
> > Tired of spam?  Yahoo! Mail has the best spam
> protection around 
> > http://mail.yahoo.com 
> > _______________________________________________
> > Pw_forum mailing list
> > Pw_forum at pwscf.org
> > http://www.democritos.it/mailman/listinfo/pw_forum
>  
> 
> 
> ################################
> Derek Stewart, Ph. D.
> Scientific Computation Associate
> 250 Duffield Hall
> Cornell Nanoscale Facility (CNF)
> Ithaca, NY 14853
> stewart (at) cnf.cornell.edu
> (607) 255-2856 
> 
> _______________________________________________
> Pw_forum mailing list
> Pw_forum at pwscf.org
> http://www.democritos.it/mailman/listinfo/pw_forum
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


From lyu7 at ncsu.edu  Wed Apr 12 04:39:33 2006
From: lyu7 at ncsu.edu (Liping YU)
Date: Tue, 11 Apr 2006 22:39:33 -0400
Subject: [Pw_forum] error on phonon calculation  (root not converged)
In-Reply-To: <200604101956.24764.giannozz@nest.sns.it>
References: <20060407150924.61726.qmail@web60325.mail.yahoo.com> <200604101819.01557.giannozz@nest.sns.it> <443A9659.6030207@ncsu.edu> <200604101956.24764.giannozz@nest.sns.it>
Message-ID: <443C6865.8060003@ncsu.edu>

Paolo Giannozzi wrote:

>On Monday 10 April 2006 19:31, Liping YU wrote:
>
>  
>
>>1x1x1 cell
>>Total energy: -275.21362101 ( *4= -1100.85448404 )
>>    
>>
>
>  
>
>>k = 0.0000 0.0000 0.0000 ( 1045 PWs) bands (ev):
>>    
>>
>
>  
>
>>-45.3707 [...]
>>    
>>
>
>  
>
>>2x2x1 super cell
>>Total energy: -1100.81820918
>>    
>>
>
>  
>
>>k = 0.0000 0.0000 0.0000 ( 4189 PWs) bands (ev):
>>    
>>
>
>  
>
>>-45.2796 -45.2775 -45.2775 -45.2757 [...]
>>    
>>
>
>total energies per cell are not the same. Also eigenvalues are clearly 
>not the same. Your 2x2x1 supercell is not 4 times a 1x1x1 cell.
>  
>
Yes. The total energy difference between them is
-275.21362101 *4 - (-1100.81820918) = 0.03627486 ryd
What's the reason for this difference? Is it due to PP of Sr?
If this is true, then as paolo said, eigenvalues are not the same and
I guess band gaps of them might be either not same (need to check).
So can this possible bandgap difference cause to the big difference for
dielectric constant in xx and yy in two cells?

To check this for PTO, I did the same calculation for tetragonal PbTiO3
with k-point grid of 4*4*4 for 1x1x1 cell and 2*2*4 for 2x2x1 supercell,
using the same PPs of Ti and O as those in STO. I got that the total energy
difference between them is
-333.74323319*4 - (-1334.97293292) = 0.00000016 ryd
which is quite reasonable.

Here I attached the input files of STO.
1x1x1 unit cell,
========================================================
&CONTROL
title = 'relaxed cubic SrTiO3' ,
calculation = 'scf' ,
restart_mode = 'from_scratch' ,
outdir = './tmp/' ,
pseudo_dir = '../../pseudo/' ,
prefix = 'cb-st' ,
tstress = .true. ,
tprnfor = .true. ,
/
&SYSTEM
ibrav = 1,
celldm(1) = 7.27663673,
nat = 5,
ntyp = 3,
ecutwfc = 30 ,
ecutrho = 270 ,
/
&ELECTRONS
conv_thr = 1.D-8 ,
/
ATOMIC_SPECIES
Sr 87.62000 038-Sr-ca-sp-vgrp.uspp.UPF
Ti 47.86700 022-Ti-ca-sp-vgrp.uspp.UPF
O 16.00000 008-O-ca--vgrp.uspp.UPF
ATOMIC_POSITIONS crystal
Sr 0.000000000 0.000000000 0.000000000
Ti 0.500000000 0.500000000 0.500000000
O 0.000000000 0.500000000 0.500000000
O 0.500000000 0.000000000 0.500000000
O 0.500000000 0.500000000 0.000000000
K_POINTS automatic
4 4 4 0 0 0
=========================================================

2x2x1 supercell
=========================================================

&CONTROL
title = 'scf on cubic perovskite SrTiO3' ,
calculation = 'scf' ,
restart_mode = 'from_scratch' ,
outdir = './tmp/' ,
pseudo_dir = '../../pseudo/' ,
prefix = 'cb-st' ,
tstress = .true. ,
tprnfor = .true. ,
/
&SYSTEM
ibrav = 6,
celldm(1) = 14.55327346
celldm(3) = 0.5
nat = 20,
ntyp = 3,
ecutwfc = 30 ,
ecutrho = 270 ,
/
&ELECTRONS
conv_thr = 1.D-8 ,
/
ATOMIC_SPECIES
Sr 87.62000 038-Sr-ca-sp-vgrp.uspp.UPF
Ti 47.86700 022-Ti-ca-sp-vgrp.uspp.UPF
O 16.00000 008-O-ca--vgrp.uspp.UPF
ATOMIC_POSITIONS crystal
Sr 0.00 0.00 0.00
Sr 0.50 0.00 0.00
Sr 0.00 0.50 0.00
Sr 0.50 0.50 0.00
O 0.25 0.25 0.00
O 0.25 0.75 0.00
O 0.75 0.25 0.00
O 0.75 0.75 0.00
Ti 0.25 0.25 0.5
Ti 0.25 0.75 0.5
Ti 0.75 0.25 0.5
Ti 0.75 0.75 0.5
O 0.00 0.25 0.5
O 0.00 0.75 0.5
O 0.50 0.25 0.5
O 0.50 0.75 0.5
O 0.25 0.00 0.5
O 0.75 0.00 0.5
O 0.25 0.50 0.5
O 0.75 0.50 0.5
K_POINTS automatic
2 2 4 0 0 0



From lzhuang at whu.edu.cn  Wed Apr 12 08:36:32 2006
From: lzhuang at whu.edu.cn (Lin Zhuang)
Date: Wed, 12 Apr 2006 14:36:32 +0800
Subject: [Pw_forum] relax vs MD
Message-ID: <2b80d0af0604112336k26e3f3edib52ae1e940494edf@mail.gmail.com>

Hi there,
I am a newbie of Quantum ESPRESSO, I plan to do some calculation about
adsorption energy, e.g., oxygen molecule adsorbed on a Pt slab. I wonder
that the proper calculation type should be 'relax' or 'md', what is the
major difference between these two calculations? would CPMD be better in
this case?
Any suggestion would be greatly appreciated.
with best regards,
Lin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/attachments/20060412/fc269c7d/attachment.htm 

From rjxiao at blem.ac.cn  Wed Apr 12 09:05:36 2006
From: rjxiao at blem.ac.cn (Ruijuan Xiao)
Date: Wed, 12 Apr 2006 15:05:36 +0800
Subject: [Pw_forum] How to adjust emass,dt and cutoff in cp.x calculation?
Message-ID: <20060412070142.5D579112816@democritos.sissa.it>

Dear all,
I met some problems when I do some calculations by cp.x. What I calculated is a cubic box in which 54 Na atoms exist. When I use dt=5.0d0, emass=400.0d0, and emass_cutoff=3.0d0, it can run without any problems. When I put dt=5.0d0,emass=400.0d0, then change the value of emass_cutoff, the calculation also runs without problems.

But when I put emass=400.0d0 and emass_cutoff=3.0d0,then change dt into 10.0d0, the following error message appears and the program stopped.
-----------------------------------
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
     from ortho : error #        21
     max number of iterations exceeded
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

     stopping ...
------------------------------------

When I put dt=5.0d0 and emass_cutoff=3.0d0, but change emass into 200.0d0, the program stopped after 12 iterations. The message is :
------------------------------------
  nfi    ekinc  temph  tempp        etot      enthal       econs       econt    vnhh   xnhh0    vnhp   xnhp0
   10 ********    0.0    0.0    41.82500    41.82500    41.82500   146.23636  0.0000  0.0000  0.0000  0.0000
   11  NaN        0.0    0.0    58.16717    58.16717    58.16717  NaN         0.0000  0.0000  0.0000  0.0000
   12  NaN        0.0    0.0  NaN         NaN         NaN         NaN         0.0000  0.0000  0.0000  0.0000

   MAIN:          EKINC   (thr)          DETOT   (thr)       MAXFORCE   (thr)
   MAIN:  NaN            0.1D-03 NaN            0.1D-08  0.000000D+00  0.1D+11
   MAIN: convergence achieved for system relaxation


              averaged quantities :
         ekinc          ekin          epot          etot     tempp
 NaN           NaN           NaN           NaN                 0.0
-----------------------------------
It seems that the calculation is sensitive to these parameters. Since on the page 37 of the maunal, it says that "unless you are already experienced with the system you are studying or with the code internals, usually you need to tune some
input parameters, like emass, dt, and cut-offs.", so these parameters must be important for calculations, but now I am puzzled about how to adjust emass,dt and cutoff in cp calculations.Would you like to give me any information or any suggestion about that?

Thank you very much.


Best regards,

Sincerely,
Ruijuan Xiao
Institute of Physics,
Chinese Academy of Sciences





From marzari at MIT.EDU  Wed Apr 12 09:53:49 2006
From: marzari at MIT.EDU (Nicola Marzari)
Date: Wed, 12 Apr 2006 09:53:49 +0200
Subject: [Pw_forum] How to adjust emass,dt and cutoff in cp.x calculation?
In-Reply-To: <20060412070142.5D579112816@democritos.sissa.it>
References: <20060412070142.5D579112816@democritos.sissa.it>
Message-ID: <443CB20D.2020302@mit.edu>


Dear Ruijuan Xiao,

bulk Na is a metal, so it's very difficult to treat properly with a
straightforward Car-Parrinello approach - this is often discussed in
Car-Parrinello review papers, such as the one posted by Dominic Marx
on his webpage.

The cp code uses, for maximum efficiency, Gamma sampling only; it's
possible that at that point in the BZ a reasonable gap exists between
occupied and unoccupied states (even if, elesewhere in the BZ, these
cross). So you might be able to run a simulation for a while, but it's
a strategy that borders on disaster, as I think it is happening to you.

A safer strategy would be to begin by using PWSCF - an even better
strategy would be to go to the review literature - ideally something
like Richard Martin's electronic structure book, or taking the
electronic-structure lectures from
http://ocw.mit.edu/OcwWeb/Materials-Science-and-Engineering/3-320Spring-2005/CourseHome/index.htm

All the best,

			nicola


Ruijuan Xiao wrote:
> Dear all,
> I met some problems when I do some calculations by cp.x. What I calculated is a cubic box in which 54 Na atoms exist. When I use dt=5.0d0, emass=400.0d0, and emass_cutoff=3.0d0, it can run without any problems. When I put dt=5.0d0,emass=400.0d0, then change the value of emass_cutoff, the calculation also runs without problems.
> 
> But when I put emass=400.0d0 and emass_cutoff=3.0d0,then change dt into 10.0d0, the following error message appears and the program stopped.
> -----------------------------------
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
>      from ortho : error #        21
>      max number of iterations exceeded
>  %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
> 
>      stopping ...
> ------------------------------------
> 
> When I put dt=5.0d0 and emass_cutoff=3.0d0, but change emass into 200.0d0, the program stopped after 12 iterations. The message is :
> ------------------------------------
>   nfi    ekinc  temph  tempp        etot      enthal       econs       econt    vnhh   xnhh0    vnhp   xnhp0
>    10 ********    0.0    0.0    41.82500    41.82500    41.82500   146.23636  0.0000  0.0000  0.0000  0.0000
>    11  NaN        0.0    0.0    58.16717    58.16717    58.16717  NaN         0.0000  0.0000  0.0000  0.0000
>    12  NaN        0.0    0.0  NaN         NaN         NaN         NaN         0.0000  0.0000  0.0000  0.0000
> 
>    MAIN:          EKINC   (thr)          DETOT   (thr)       MAXFORCE   (thr)
>    MAIN:  NaN            0.1D-03 NaN            0.1D-08  0.000000D+00  0.1D+11
>    MAIN: convergence achieved for system relaxation
> 
> 
>               averaged quantities :
>          ekinc          ekin          epot          etot     tempp
>  NaN           NaN           NaN           NaN                 0.0
> -----------------------------------
> It seems that the calculation is sensitive to these parameters. Since on the page 37 of the maunal, it says that "unless you are already experienced with the system you are studying or with the code internals, usually you need to tune some
> input parameters, like emass, dt, and cut-offs.", so these parameters must be important for calculations, but now I am puzzled about how to adjust emass,dt and cutoff in cp calculations.Would you like to give me any information or any suggestion about that?
> 
> Thank you very much.
> 
> 
> Best regards,
> 
> Sincerely,
> Ruijuan Xiao
> Institute of Physics,
> Chinese Academy of Sciences
> 
> 
> 
> _______________________________________________
> Pw_forum mailing list
> Pw_forum at pwscf.org
> http://www.democritos.it/mailman/listinfo/pw_forum

-- 
---------------------------------------------------------------------
Prof Nicola Marzari   Department of Materials Science and Engineering
13-5066   MIT   77 Massachusetts Avenue   Cambridge MA 02139-4307 USA
tel 617.4522758 fax 2586534 marzari at mit.edu http://quasiamore.mit.edu


From marzari at MIT.EDU  Wed Apr 12 10:08:13 2006
From: marzari at MIT.EDU (Nicola Marzari)
Date: Wed, 12 Apr 2006 10:08:13 +0200
Subject: [Pw_forum] relax vs MD
In-Reply-To: <2b80d0af0604112336k26e3f3edib52ae1e940494edf@mail.gmail.com>
References: <2b80d0af0604112336k26e3f3edib52ae1e940494edf@mail.gmail.com>
Message-ID: <443CB56D.20606@mit.edu>


Dear Lin,

you should use pwscf, relax, but first you should complete
successfully problem sets 2 and 3 from
http://ocw.mit.edu/OcwWeb/Materials-Science-and-Engineering/3-320Spring-2005/CourseHome/index.htm

			nicola


Lin Zhuang wrote:

> Hi there,
> I am a newbie of Quantum ESPRESSO, I plan to do some calculation about 
> adsorption energy, e.g., oxygen molecule adsorbed on a Pt slab. I wonder 
> that the proper calculation type should be 'relax' or 'md', what is the 
> major difference between these two calculations? would CPMD be better in 
> this case?
> Any suggestion would be greatly appreciated.
> with best regards,
> Lin

-- 
---------------------------------------------------------------------
Prof Nicola Marzari   Department of Materials Science and Engineering
13-5066   MIT   77 Massachusetts Avenue   Cambridge MA 02139-4307 USA
tel 617.4522758 fax 2586534 marzari at mit.edu http://quasiamore.mit.edu


From rjxiao at blem.ac.cn  Wed Apr 12 10:15:41 2006
From: rjxiao at blem.ac.cn (Ruijuan Xiao)
Date: Wed, 12 Apr 2006 16:15:41 +0800
Subject: [Pw_forum] How to adjust emass,dt and cutoff in cp.x calculation?
Message-ID: <20060412081147.BE51D112891@democritos.sissa.it>

Dear Prof Nicola Marzari,

Thank you very much. I'll read the book and the lectrues. They are really wonderful materials to learn calculations.

Thanks a lot!

Best regards,

Sincerely,
Ruijuan Xiao
Institute of Physics,
Chinese Academy of Sciences


----- Original Message -----

From: Nicola Marzari <marzari at MIT.EDU>
To?pw_forum at pwscf.org <pw_forum at pwscf.org>
Sent?2006-04-12 15:53:49
Subject?Re: [Pw_forum] How to adjust emass,dt and cutoff in cp.x calculation?

>
>
>Dear Ruijuan Xiao,
>
>bulk Na is a metal, so it's very difficult to treat properly with a
>straightforward Car-Parrinello approach - this is often discussed in
>Car-Parrinello review papers, such as the one posted by Dominic Marx
>on his webpage.
>
>The cp code uses, for maximum efficiency, Gamma sampling only; it's
>possible that at that point in the BZ a reasonable gap exists between
>occupied and unoccupied states (even if, elesewhere in the BZ, these
>cross). So you might be able to run a simulation for a while, but it's
>a strategy that borders on disaster, as I think it is happening to you.
>
>A safer strategy would be to begin by using PWSCF - an even better
>strategy would be to go to the review literature - ideally something
>like Richard Martin's electronic structure book, or taking the
>electronic-structure lectures from
>http://ocw.mit.edu/OcwWeb/Materials-Science-and-Engineering/3-320Spring-2005/CourseHome/index.htm
>
>All the best,
>
>			nicola
>
>
>Ruijuan Xiao wrote:
>> Dear all,
>> I met some problems when I do some calculations by cp.x. What I calculated is a cubic box in which 54 Na atoms exist. When I use dt=5.0d0, emass=400.0d0, and emass_cutoff=3.0d0, it can run without any problems. When I put dt=5.0d0,emass=400.0d0, then change the value of emass_cutoff, the calculation also runs without problems.
>> 
>> But when I put emass=400.0d0 and emass_cutoff=3.0d0,then change dt into 10.0d0, the following error message appears and the program stopped.
>> -----------------------------------
>> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
>>      from ortho : error #        21
>>      max number of iterations exceeded
>>  %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
>> 
>>      stopping ...
>> ------------------------------------
>> 
>> When I put dt=5.0d0 and emass_cutoff=3.0d0, but change emass into 200.0d0, the program stopped after 12 iterations. The message is :
>> ------------------------------------
>>   nfi    ekinc  temph  tempp        etot      enthal       econs       econt    vnhh   xnhh0    vnhp   xnhp0
>>    10 ********    0.0    0.0    41.82500    41.82500    41.82500   146.23636  0.0000  0.0000  0.0000  0.0000
>>    11  NaN        0.0    0.0    58.16717    58.16717    58.16717  NaN         0.0000  0.0000  0.0000  0.0000
>>    12  NaN        0.0    0.0  NaN         NaN         NaN         NaN         0.0000  0.0000  0.0000  0.0000
>> 
>>    MAIN:          EKINC   (thr)          DETOT   (thr)       MAXFORCE   (thr)
>>    MAIN:  NaN            0.1D-03 NaN            0.1D-08  0.000000D+00  0.1D+11
>>    MAIN: convergence achieved for system relaxation
>> 
>> 
>>               averaged quantities :
>>          ekinc          ekin          epot          etot     tempp
>>  NaN           NaN           NaN           NaN                 0.0
>> -----------------------------------
>> It seems that the calculation is sensitive to these parameters. Since on the page 37 of the maunal, it says that "unless you are already experienced with the system you are studying or with the code internals, usually you need to tune some
>> input parameters, like emass, dt, and cut-offs.", so these parameters must be important for calculations, but now I am puzzled about how to adjust emass,dt and cutoff in cp calculations.Would you like to give me any information or any suggestion about that?
>> 
>> Thank you very much.
>> 
>> 
>> Best regards,
>> 
>> Sincerely,
>> Ruijuan Xiao
>> Institute of Physics,
>> Chinese Academy of Sciences
>> 
>> 
>> 
>> _______________________________________________
>> Pw_forum mailing list
>> Pw_forum at pwscf.org
>> http://www.democritos.it/mailman/listinfo/pw_forum
>
>-- 
>---------------------------------------------------------------------
>Prof Nicola Marzari   Department of Materials Science and Engineering
>13-5066   MIT   77 Massachusetts Avenue   Cambridge MA 02139-4307 USA
>tel 617.4522758 fax 2586534 marzari at mit.edu http://quasiamore.mit.edu
>_______________________________________________
>Pw_forum mailing list
>Pw_forum at pwscf.org
>http://www.democritos.it/mailman/listinfo/pw_forum
>


From giannozz at nest.sns.it  Wed Apr 12 10:26:56 2006
From: giannozz at nest.sns.it (Paolo Giannozzi)
Date: Wed, 12 Apr 2006 10:26:56 +0200
Subject: [Pw_forum] error on phonon calculation  (root not converged)
In-Reply-To: <443C6865.8060003@ncsu.edu>
References: <20060407150924.61726.qmail@web60325.mail.yahoo.com> <200604101956.24764.giannozz@nest.sns.it> <443C6865.8060003@ncsu.edu>
Message-ID: <200604121026.56943.giannozz@nest.sns.it>

On Wednesday 12 April 2006 04:39, Liping YU wrote:

> >total energies per cell are not the same. Also eigenvalues are clearly
> >not the same. Your 2x2x1 supercell is not 4 times a 1x1x1 cell.
>
> Yes. The total energy difference between them is
> -275.21362101 *4 - (-1100.81820918) = 0.03627486 ryd
> What's the reason for this difference? Is it due to PP of Sr?

no, it is due to either a structural difference, or to a different level 
of approximation (k-points or something else).

> If this is true, then as paolo said, eigenvalues are not the same and
> I guess band gaps of them might be either not same (need to check).
> So can this possible bandgap difference cause to the big difference for
> dielectric constant in xx and yy in two cells?

if you are close to a metallic state, small bandgap differences
can do a large difference in the dielectric constant

P.
-- 
Paolo Giannozzi             e-mail:  giannozz at nest.sns.it
Scuola Normale Superiore    Phone:   +39/050-509876, Fax:-563513 
Piazza dei Cavalieri 7      I-56126 Pisa, Italy


From scandolo at ictp.it  Wed Apr 12 11:49:21 2006
From: scandolo at ictp.it (Sandro Scandolo)
Date: Wed, 12 Apr 2006 11:49:21 +0200
Subject: [Pw_forum] How to adjust emass,dt and cutoff in cp.x calculation?
In-Reply-To: <20060412070142.5D579112816@democritos.sissa.it>
References: <20060412070142.5D579112816@democritos.sissa.it>
Message-ID: <443CCD21.8050907@ictp.it>

What Nicola says is entirely correct, and you should pay special
attention when studying metallic systems with CP (or seriously
considering using extensions of the CP method like the ones pioneered by
Nicola and by others).

However, should you still be willing to study Na with CP as a test case,
or should you consider studying "easier" (say, nonmetallic) systems in
the future, the recipe for setting emass, emass_cutoff, and dt is
roughly as follows:

1) set emass to a physical sound value. The value of emass determines
how much the fictitiuous dynamics of the electrons couples with the real
dynamics of the ions. A small emass guarantees decoupling. How small is
small is typically determined by the excitation gap E_gap of your
system. The minimum frequency of the fictitious electronic dynamics
scales like sqrt(E_gap/emass) [see, e.g., Pastore et al, PRA 44, 6334
(1991)], and this has to be much higher than the maximum frequency of
the ion dynamics. Typically a factor of three larger is enough. As you
see, metallic systems, where E_gap=0 are a bit of a nightmare for CP,
unless the finite size of your system introduces a finite gap, but then
you have to be extra-careful...

2) start playing with emass_ecutoff, by fixing it to a starting value,
and checking what is the maximum dt that alllows you to integrate the
equations of motion. The error you got is precisely a sign that the dt
you used is too large for the integrator to converge.

3) choose the value of emass_ecutoff that allows you to use the largest dt.

4) Set dt accordingly.

Points (2-4) are described in detail in Tassone, Mauri, Car, PRB 50,
10561 (1994).

Regards,
Sandro


Ruijuan Xiao wrote:

>Dear all,
>I met some problems when I do some calculations by cp.x. What I calculated is a cubic box in which 54 Na atoms exist. When I use dt=5.0d0, emass=400.0d0, and emass_cutoff=3.0d0, it can run without any problems. When I put dt=5.0d0,emass=400.0d0, then change the value of emass_cutoff, the calculation also runs without problems.
>
>But when I put emass=400.0d0 and emass_cutoff=3.0d0,then change dt into 10.0d0, the following error message appears and the program stopped.
>-----------------------------------
>%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
>     from ortho : error #        21
>     max number of iterations exceeded
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
>
>     stopping ...
>------------------------------------
>
>When I put dt=5.0d0 and emass_cutoff=3.0d0, but change emass into 200.0d0, the program stopped after 12 iterations. The message is :
>------------------------------------
>  nfi    ekinc  temph  tempp        etot      enthal       econs       econt    vnhh   xnhh0    vnhp   xnhp0
>   10 ********    0.0    0.0    41.82500    41.82500    41.82500   146.23636  0.0000  0.0000  0.0000  0.0000
>   11  NaN        0.0    0.0    58.16717    58.16717    58.16717  NaN         0.0000  0.0000  0.0000  0.0000
>   12  NaN        0.0    0.0  NaN         NaN         NaN         NaN         0.0000  0.0000  0.0000  0.0000
>
>   MAIN:          EKINC   (thr)          DETOT   (thr)       MAXFORCE   (thr)
>   MAIN:  NaN            0.1D-03 NaN            0.1D-08  0.000000D+00  0.1D+11
>   MAIN: convergence achieved for system relaxation
>
>
>              averaged quantities :
>         ekinc          ekin          epot          etot     tempp
> NaN           NaN           NaN           NaN                 0.0
>-----------------------------------
>It seems that the calculation is sensitive to these parameters. Since on the page 37 of the maunal, it says that "unless you are already experienced with the system you are studying or with the code internals, usually you need to tune some
>input parameters, like emass, dt, and cut-offs.", so these parameters must be important for calculations, but now I am puzzled about how to adjust emass,dt and cutoff in cp calculations.Would you like to give me any information or any suggestion about that?
>
>Thank you very much.
>
>
>Best regards,
>
>Sincerely,
>Ruijuan Xiao
>Institute of Physics,
>Chinese Academy of Sciences
>
>
>
>_______________________________________________
>Pw_forum mailing list
>Pw_forum at pwscf.org
>http://www.democritos.it/mailman/listinfo/pw_forum
>
>  
>


From lyu7 at ncsu.edu  Wed Apr 12 16:11:59 2006
From: lyu7 at ncsu.edu (Liping YU)
Date: Wed, 12 Apr 2006 10:11:59 -0400
Subject: [Pw_forum] error on phonon calculation  (root not converged)
In-Reply-To: <443A9507.9060209@mit.edu>
References: <20060407150924.61726.qmail@web60325.mail.yahoo.com> <4439515D.2050505@ncsu.edu> <200604101422.15850.giannozz@nest.sns.it> <443A4FC9.7090608@mit.edu> <443A7B2B.4060202@ncsu.edu> <443A7E77.3000004@mit.edu> <443A9217.10309@ncsu.edu> <443A9507.9060209@mit.edu>
Message-ID: <443D0AAF.6080707@ncsu.edu>

Nicola Marzari wrote:

>>>Next, if you use the same identical input files, but you put
>>>Pb instead of Sr, do you get identical dielectric constants
>>>      
>>>
>>>from 1x1x1 and 2x2x1 ?
>>    
>>
>>> 
>>>
>>>      
>>>
>>No, for PbTiO3, it's tetragonal structure, not cubic one as SrTiO3. 
>>    
>>
>
>I know - I just wanted to make the point that if there were something
>odd with the pseudopotential (although I do not know what - a ghost
>state ? Even that is unlikey to appear in only one of the two
>calculations) you could use the exact SrTiO3 input files, but just put
>Pb instead of Sr.
>  
>
I just replace Sr (and its PP file name) by Pb in the inputfile of
SrTiO3 and
leave all other parameters unchanged. The odd problems (unconvergence and
large dielectric constant in plane) disappeared.

>  
>
>>Note for no reason I used 4x4x4 k-point grid for both unit cell and 
>>super cells.
>>
>>1x1x1 unit cell,
>>    (       7.981121520       0.000000000       0.000000000 )
>>    (       0.000000000       7.981121520       0.000000000 )
>>    (       0.000000000       0.000000000       7.542263658 )
>>
>>2x2x1 supercell,
>>    (       7.775208874       0.000000000       0.000000000 )
>>    (       0.000000000       7.775208874       0.000000000 )
>>    (       0.000000000       0.000000000       7.491522972 )
>>
>>Maybe I should also try same k-point (4x4x4) sampling for SrTiO3 in two
>>different cells, although they are not equivalent, and see what will happen.
>>
>>    
>>
>
>
>OK, this could show you if there were some odd problem with the
>calculation with the larger number of kpoints. Also, make sure
>oyu have no leftovers from previous calculations, i.e. your directories
>are clean.
>
>  
>
Here is the result for this case. The odd problem still exists. Thank
you very much!

liping

================================================================
Program PHONON v.3.0 starts ...
Today is 11Apr2006 at 1: 0:10

Parallel version (MPI)

Number of processors in use: 32
K-points division: npool = 2
R & G space division: proc/pool = 16

Ultrasoft (Vanderbilt) Pseudopotentials

Reading file cb-st.save ... only dimensions
read complete

Reading file cb-st.save ... all except wavefuctions
read complete

Planes per process (thick) : nr3 = 40 npp = 3 ncplane = 6400

Planes per process (smooth): nr3s= 28 npps= 2 ncplanes= 3136

Proc/ planes cols G planes cols G columns G
Pool (dense grid) (smooth grid) (wavefct grid)
1 3 283 7211 2 126 2130 37 349
2 3 283 7211 2 127 2137 37 349
3 3 283 7211 2 127 2135 37 349
4 3 285 7211 2 127 2135 37 349
5 3 285 7211 2 127 2133 37 349
6 3 285 7211 2 127 2135 37 349
7 3 285 7211 2 127 2133 37 349
8 3 284 7210 2 127 2131 37 349
9 2 284 7210 2 127 2131 37 349
10 2 284 7210 2 127 2127 38 350
11 2 284 7210 2 126 2122 39 349
12 2 284 7210 2 126 2126 39 349
13 2 284 7210 1 126 2132 38 348
14 2 284 7210 1 126 2134 38 348
15 2 284 7210 1 126 2132 38 348
16 2 284 7210 1 126 2132 38 348
0 40 4545 115367 28 2025 34105 601 5581


nbndx = 80 nbnd = 80 natomwfc = 108 npwx = 276
nelec = 160.00 nkb = 240 ngl = 944
autoval = -.5378E+01
Real(aut_vet)= ( 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000)
Real(aut_vet)= ( 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000)
Real(aut_vet)= ( 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000)
[.....]
Imm(aut_vet)= ( 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000)
Imm(aut_vet)= ( 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000)

'2*2*1 cb srtio3'

crystal is

bravais-lattice index = 6
lattice parameter (a_0) = 14.5533 a.u.
unit-cell volume = 1541.1754 (a.u.)^3
number of atoms/cell = 20
number of atomic types = 3
kinetic-energy cut-off = 30.0000 Ry
charge density cut-off = 270.0000 Ry
convergence threshold = 1.0E-14
beta = 0.1000
number of iterations used = 4

celldm(1)= 14.55327 celldm(2)= 0.00000 celldm(3)= 0.50000
celldm(4)= 0.00000 celldm(5)= 0.00000 celldm(6)= 0.00000

crystal axes: (cart. coord. in units of a_0)
a(1) = ( 1.0000 0.0000 0.0000 )
a(2) = ( 0.0000 1.0000 0.0000 )
a(3) = ( 0.0000 0.0000 0.5000 )

reciprocal axes: (cart. coord. in units 2 pi/a_0)
b(1) = ( 1.0000 0.0000 0.0000 )
b(2) = ( 0.0000 1.0000 0.0000 )
b(3) = ( 0.0000 0.0000 2.0000 )


Atoms inside the unit cell:

Cartesian axes

site n. atom mass positions (a_0 units)
1 Sr 87.6200 tau( 1) = ( 0.00000 0.00000 0.00000 )
2 Sr 87.6200 tau( 2) = ( 0.50000 0.00000 0.00000 )
3 Sr 87.6200 tau( 3) = ( 0.00000 0.50000 0.00000 )
4 Sr 87.6200 tau( 4) = ( 0.50000 0.50000 0.00000 )
5 O 16.0000 tau( 5) = ( 0.25000 0.25000 0.00000 )
6 O 16.0000 tau( 6) = ( 0.25000 0.75000 0.00000 )
7 O 16.0000 tau( 7) = ( 0.75000 0.25000 0.00000 )
8 O 16.0000 tau( 8) = ( 0.75000 0.75000 0.00000 )
9 Ti 47.8670 tau( 9) = ( 0.25000 0.25000 0.25000 )
10 Ti 47.8670 tau(10) = ( 0.25000 0.75000 0.25000 )
11 Ti 47.8670 tau(11) = ( 0.75000 0.25000 0.25000 )
12 Ti 47.8670 tau(12) = ( 0.75000 0.75000 0.25000 )
13 O 16.0000 tau(13) = ( 0.00000 0.25000 0.25000 )
14 O 16.0000 tau(14) = ( 0.00000 0.75000 0.25000 )
15 O 16.0000 tau(15) = ( 0.50000 0.25000 0.25000 )
16 O 16.0000 tau(16) = ( 0.50000 0.75000 0.25000 )
17 O 16.0000 tau(17) = ( 0.25000 0.00000 0.25000 )
18 O 16.0000 tau(18) = ( 0.75000 0.00000 0.25000 )
19 O 16.0000 tau(19) = ( 0.25000 0.50000 0.25000 )
20 O 16.0000 tau(20) = ( 0.75000 0.50000 0.25000 )

Computing dynamical matrix for
q = ( 0.00000 0.00000 0.00000 )

17 Sym.Ops. (with q -> -q+G )

s frac. trans.

isym = 1 identity

cryst. s( 1) = ( 1 0 0 )
( 0 1 0 )
( 0 0 1 )
[.........]
isym = 17 identity

cryst. s(17) = ( 1 0 0 )
( 0 1 0 )
( 0 0 1 )

cart. s(17) = ( 1.0000000 0.0000000 0.0000000 )
( 0.0000000 1.0000000 0.0000000 )
( 0.0000000 0.0000000 1.0000000 )


G cutoff = 1448.5230 ( 7211 G-vectors) FFT grid: ( 80, 80, 40)
G cutoff = 643.7880 ( 2130 G-vectors) smooth grid: ( 56, 56, 28)
number of k points= 18
cart. coord. in units 2pi/a_0
k( 1) = ( 0.0000000 0.0000000 0.0000000), wk = 0.0312500
k( 2) = ( 0.0000000 0.0000000 0.5000000), wk = 0.0625000
k( 3) = ( 0.0000000 0.0000000 -1.0000000), wk = 0.0312500
k( 4) = ( 0.0000000 0.2500000 0.0000000), wk = 0.1250000
k( 5) = ( 0.0000000 0.2500000 0.5000000), wk = 0.2500000
k( 6) = ( 0.0000000 0.2500000 -1.0000000), wk = 0.1250000
k( 7) = ( 0.0000000 -0.5000000 0.0000000), wk = 0.0625000
k( 8) = ( 0.0000000 -0.5000000 0.5000000), wk = 0.1250000
k( 9) = ( 0.0000000 -0.5000000 -1.0000000), wk = 0.0625000
k( 10) = ( 0.2500000 0.2500000 0.0000000), wk = 0.1250000
k( 11) = ( 0.2500000 0.2500000 0.5000000), wk = 0.2500000
k( 12) = ( 0.2500000 0.2500000 -1.0000000), wk = 0.1250000
k( 13) = ( 0.2500000 -0.5000000 0.0000000), wk = 0.1250000
k( 14) = ( 0.2500000 -0.5000000 0.5000000), wk = 0.2500000
k( 15) = ( 0.2500000 -0.5000000 -1.0000000), wk = 0.1250000
k( 16) = ( -0.5000000 -0.5000000 0.0000000), wk = 0.0312500
k( 17) = ( -0.5000000 -0.5000000 0.5000000), wk = 0.0625000
k( 18) = ( -0.5000000 -0.5000000 -1.0000000), wk = 0.0312500

cryst. coord.
k( 1) = ( 0.0000000 0.0000000 0.0000000), wk = 0.0312500
k( 2) = ( 0.0000000 0.0000000 0.2500000), wk = 0.0625000
k( 3) = ( 0.0000000 0.0000000 -0.5000000), wk = 0.0312500
k( 4) = ( 0.0000000 0.2500000 0.0000000), wk = 0.1250000
k( 5) = ( 0.0000000 0.2500000 0.2500000), wk = 0.2500000
k( 6) = ( 0.0000000 0.2500000 -0.5000000), wk = 0.1250000
k( 7) = ( 0.0000000 -0.5000000 0.0000000), wk = 0.0625000
k( 8) = ( 0.0000000 -0.5000000 0.2500000), wk = 0.1250000
k( 9) = ( 0.0000000 -0.5000000 -0.5000000), wk = 0.0625000
k( 10) = ( 0.2500000 0.2500000 0.0000000), wk = 0.1250000
k( 11) = ( 0.2500000 0.2500000 0.2500000), wk = 0.2500000
k( 12) = ( 0.2500000 0.2500000 -0.5000000), wk = 0.1250000
k( 13) = ( 0.2500000 -0.5000000 0.0000000), wk = 0.1250000
k( 14) = ( 0.2500000 -0.5000000 0.2500000), wk = 0.2500000
k( 15) = ( 0.2500000 -0.5000000 -0.5000000), wk = 0.1250000
k( 16) = ( -0.5000000 -0.5000000 0.0000000), wk = 0.0312500
k( 17) = ( -0.5000000 -0.5000000 0.2500000), wk = 0.0625000
k( 18) = ( -0.5000000 -0.5000000 -0.5000000), wk = 0.0312500

pseudo 1 is st (US) zval = 10.0 lmax= 2 lloc= 0
Version 0 0 0 of US pseudo code

Using log mesh of 883 points

The pseudopotential has 6 beta functions with:

l(1) = 0
l(2) = 0
l(3) = 1
l(4) = 1
l(5) = 2
l(6) = 2

Q(r) pseudized with 8 coefficients, rinner = 1.000 1.000 1.000
1.000 1.000

pseudo 2 is ti (US) zval = 12.0 lmax= 2 lloc= 0
Version 0 0 0 of US pseudo code

Using log mesh of 851 points

The pseudopotential has 6 beta functions with:

l(1) = 0
l(2) = 0
l(3) = 1
l(4) = 1
l(5) = 2
l(6) = 2

Q(r) pseudized with 5 coefficients, rinner = 1.000 1.000 1.000
1.000 1.000

pseudo 3 is ox (US) zval = 6.0 lmax= 1 lloc= 0
Version 0 0 0 of US pseudo code

Using log mesh of 737 points

The pseudopotential has 4 beta functions with:

l(1) = 0
l(2) = 0
l(3) = 1
l(4) = 1

Q(r) pseudized with 8 coefficients, rinner = 0.700 0.700 0.700



Atomic displacements:
There are 44 irreducible representations

Representation 1 1 modes - To be done
Phonon polarizations are as follows:

mode # 1
( 0.00000 0.00000 )
( 0.00000 0.00000 )
( 0.00000 0.00000 )
( 0.00000 0.00000 )
( 0.00000 0.00000 )
( 0.00000 0.00000 )
[........]
( 0.00000 0.00000 )
( 0.00000 0.00000 )
( -0.50000 0.00000 )
( 0.00000 0.00000 )
( 0.00000 0.00000 )
( -0.50000 0.00000 )
PHONON : 1m50.15s CPU time


Alpha used in Ewald sum = 2.3000

Electric Fields Calculation

iter # 1 total cpu time : 295.2 secs av.it.: 7.2
thresh= 0.100E-01 alpha_mix = 0.100 |ddv_scf|^2 = 0.430E-08

iter # 2 total cpu time : 367.1 secs av.it.: 13.0
thresh= 0.656E-05 alpha_mix = 0.100 |ddv_scf|^2 = 0.309E-08

iter # 3 total cpu time : 448.7 secs av.it.: 14.9
thresh= 0.556E-05 alpha_mix = 0.100 |ddv_scf|^2 = 0.169E-09

iter # 4 total cpu time : 528.0 secs av.it.: 14.5
thresh= 0.130E-05 alpha_mix = 0.100 |ddv_scf|^2 = 0.174E-10

iter # 5 total cpu time : 609.2 secs av.it.: 14.9
thresh= 0.417E-06 alpha_mix = 0.100 |ddv_scf|^2 = 0.235E-11

iter # 6 total cpu time : 692.4 secs av.it.: 15.3
thresh= 0.153E-06 alpha_mix = 0.100 |ddv_scf|^2 = 0.155E-12

iter # 7 total cpu time : 766.8 secs av.it.: 13.9
thresh= 0.394E-07 alpha_mix = 0.100 |ddv_scf|^2 = 0.945E-13

iter # 8 total cpu time : 847.0 secs av.it.: 15.1
thresh= 0.307E-07 alpha_mix = 0.100 |ddv_scf|^2 = 0.660E-14

End of electric fields calculation

Dielectric constant in cartesian axis

( 6.380587095 0.000000000 0.000000000 )
( 0.000000000 6.380587095 0.000000000 )
( 0.000000000 0.000000000 6.611263268 )

Effective charges E-U in cartesian axis

atom 1
( 2.56446 0.00000 0.00000 )
( 0.00000 2.56446 0.00000 )
( 0.00000 0.00000 2.55308 )
atom 2
( 2.56529 0.00000 0.00000 )
( 0.00000 2.56442 0.00000 )
( 0.00000 0.00000 2.55308 )
atom 3
( 2.56442 0.00000 0.00000 )
( 0.00000 2.56529 0.00000 )
( 0.00000 0.00000 2.55308 )
atom 4
( 2.56532 0.00000 0.00000 )
( 0.00000 2.56532 0.00000 )
( 0.00000 0.00000 2.55308 )
atom 5
( -2.13094 -0.00001 0.00000 )
( -0.00001 -2.13094 0.00000 )
( 0.00000 0.00000 -6.05328 )
atom 6
( -2.13094 0.00001 0.00000 )
( 0.00001 -2.13094 0.00000 )
( 0.00000 0.00000 -6.05328 )
atom 7
( -2.13094 0.00001 0.00000 )
( 0.00001 -2.13094 0.00000 )
( 0.00000 0.00000 -6.05328 )
atom 8
( -2.13094 -0.00001 0.00000 )
( -0.00001 -2.13094 0.00000 )
( 0.00000 0.00000 -6.05328 )
atom 9
( 7.28587 -0.00004 0.00000 )
( -0.00004 7.28587 0.00000 )
( 0.00000 0.00000 7.43190 )
atom 10
( 7.28587 0.00004 0.00000 )
( 0.00004 7.28587 0.00000 )
( 0.00000 0.00000 7.43190 )
atom 11
( 7.28587 0.00004 0.00000 )
( 0.00004 7.28587 0.00000 )
( 0.00000 0.00000 7.43190 )
atom 12
( 7.28587 -0.00004 0.00000 )
( -0.00004 7.28587 0.00000 )
( 0.00000 0.00000 7.43190 )
atom 13
( -5.71166 0.00000 0.00000 )
( 0.00000 -2.04665 0.00000 )
( 0.00000 0.00000 -2.10683 )
atom 14
( -5.71166 0.00000 0.00000 )
( 0.00000 -2.04665 0.00000 )
( 0.00000 0.00000 -2.10683 )
atom 15
( -5.71103 0.00000 0.00000 )
( 0.00000 -2.04665 0.00000 )
( 0.00000 0.00000 -2.10684 )
atom 16
( -5.71103 0.00000 0.00000 )
( 0.00000 -2.04665 0.00000 )
( 0.00000 0.00000 -2.10684 )
atom 17
( -2.04665 0.00000 0.00000 )
( 0.00000 -5.71166 0.00000 )
( 0.00000 0.00000 -2.10683 )
atom 18
( -2.04665 0.00000 0.00000 )
( 0.00000 -5.71166 0.00000 )
( 0.00000 0.00000 -2.10683 )
atom 19
( -2.04665 0.00000 0.00000 )
( 0.00000 -5.71103 0.00000 )
( 0.00000 0.00000 -2.10684 )
atom 20
( -2.04665 0.00000 0.00000 )
( 0.00000 -5.71103 0.00000 )
( 0.00000 0.00000 -2.10684 )


Representation # 1 mode # 1

Self-consistent Calculation

iter # 1 total cpu time : 1635.4 secs av.it.: 6.5
thresh= 0.100E-01 alpha_mix = 0.100 |ddv_scf|^2 = 0.246E-06

iter # 2 total cpu time : 1656.4 secs av.it.: 11.5
thresh= 0.496E-04 alpha_mix = 0.100 |ddv_scf|^2 = 0.174E-06

iter # 3 total cpu time : 1681.4 secs av.it.: 14.4
thresh= 0.417E-04 alpha_mix = 0.100 |ddv_scf|^2 = 0.133E-08

iter # 4 total cpu time : 1706.2 secs av.it.: 14.1
thresh= 0.365E-05 alpha_mix = 0.100 |ddv_scf|^2 = 0.148E-09

iter # 5 total cpu time : 1731.5 secs av.it.: 14.8
thresh= 0.122E-05 alpha_mix = 0.100 |ddv_scf|^2 = 0.384E-11

iter # 6 total cpu time : 1758.3 secs av.it.: 15.4
thresh= 0.196E-06 alpha_mix = 0.100 |ddv_scf|^2 = 0.226E-12

iter # 7 total cpu time : 1784.6 secs av.it.: 15.5
thresh= 0.475E-07 alpha_mix = 0.100 |ddv_scf|^2 = 0.300E-13

iter # 8 total cpu time : 1810.6 secs av.it.: 15.2
thresh= 0.173E-07 alpha_mix = 0.100 |ddv_scf|^2 = 0.665E-15

End of self-consistent calculation

Convergence has been achieved


* [......] ( Everything is fine here )*


Representation # 24 mode # 34

Self-consistent Calculation

iter # 1 total cpu time : 10453.7 secs av.it.: 8.6
thresh= 0.100E-01 alpha_mix = 0.100 |ddv_scf|^2 = 0.248E-04

iter # 2 total cpu time : 10474.7 secs av.it.: 11.4
thresh= 0.498E-03 alpha_mix = 0.100 |ddv_scf|^2 = 0.720E-05

iter # 3 total cpu time : 10497.1 secs av.it.: 12.6
thresh= 0.268E-03 alpha_mix = 0.100 |ddv_scf|^2 = 0.161E-06

iter # 4 total cpu time : 10522.5 secs av.it.: 14.4
thresh= 0.401E-04 alpha_mix = 0.100 |ddv_scf|^2 = 0.197E-07

iter # 5 total cpu time : 10545.1 secs av.it.: 13.0
thresh= 0.140E-04 alpha_mix = 0.100 |ddv_scf|^2 = 0.982E-08

iter # 6 total cpu time : 10569.9 secs av.it.: 14.4
thresh= 0.991E-05 alpha_mix = 0.100 |ddv_scf|^2 = 0.625E-10

iter # 7 total cpu time : 10594.1 secs av.it.: 14.0
thresh= 0.791E-06 alpha_mix = 0.100 |ddv_scf|^2 = 0.239E-10

iter # 8 total cpu time : 10619.9 secs av.it.: 15.4
thresh= 0.489E-06 alpha_mix = 0.100 |ddv_scf|^2 = 0.658E-12

iter # 9 total cpu time : 10645.8 secs av.it.: 15.2
thresh= 0.811E-07 alpha_mix = 0.100 |ddv_scf|^2 = 0.805E-11

iter # 10 total cpu time : 10662.0 secs av.it.: 8.2
thresh= 0.284E-06 alpha_mix = 0.100 |ddv_scf|^2 = 0.414E-07

iter # 11 total cpu time : 10672.2 secs av.it.: 3.8
thresh= 0.203E-04 alpha_mix = 0.100 |ddv_scf|^2 = 0.414E-07

iter # 12 total cpu time : 10681.4 secs av.it.: 3.6
thresh= 0.203E-04 alpha_mix = 0.100 |ddv_scf|^2 = 0.696E-07

iter # 13 total cpu time : 10690.3 secs av.it.: 3.1
thresh= 0.264E-04 alpha_mix = 0.100 |ddv_scf|^2 = 0.696E-07

iter # 14 total cpu time : 10697.7 secs av.it.: 2.0
thresh= 0.264E-04 alpha_mix = 0.100 |ddv_scf|^2 = 0.696E-07

iter # 15 total cpu time : 10707.0 secs av.it.: 3.0
thresh= 0.264E-04 alpha_mix = 0.100 |ddv_scf|^2 = 0.429E-07

iter # 16 total cpu time : 10716.7 secs av.it.: 3.7
thresh= 0.207E-04 alpha_mix = 0.100 |ddv_scf|^2 = 0.470E-06

iter # 17 total cpu time : 10722.2 secs av.it.: 1.0
thresh= 0.686E-04 alpha_mix = 0.100 |ddv_scf|^2 = 0.470E-06

iter # 18 total cpu time : 10727.9 secs av.it.: 1.0
thresh= 0.686E-04 alpha_mix = 0.100 |ddv_scf|^2 = 0.470E-06

iter # 19 total cpu time : 10733.4 secs av.it.: 1.0
thresh= 0.686E-04 alpha_mix = 0.100 |ddv_scf|^2 = 0.470E-06

iter # 20 total cpu time : 10739.2 secs av.it.: 1.0
thresh= 0.686E-04 alpha_mix = 0.100 |ddv_scf|^2 = 0.470E-06

iter # 21 total cpu time : 10762.8 secs av.it.: 13.9
thresh= 0.686E-04 alpha_mix = 0.100 |ddv_scf|^2 = 0.163E+02

iter # 22 total cpu time : 10773.0 secs av.it.: 4.1
thresh= 0.100E-01 alpha_mix = 0.100 |ddv_scf|^2 = 0.556E+01

iter # 23 total cpu time : 10783.3 secs av.it.: 4.1
thresh= 0.100E-01 alpha_mix = 0.100 |ddv_scf|^2 = 0.627E+00

iter # 24 total cpu time : 10790.9 secs av.it.: 2.1
thresh= 0.100E-01 alpha_mix = 0.100 |ddv_scf|^2 = 0.451E-01

iter # 25 total cpu time : 10798.3 secs av.it.: 2.0
thresh= 0.100E-01 alpha_mix = 0.100 |ddv_scf|^2 = 0.451E-01

iter # 26 total cpu time : 10806.6 secs av.it.: 2.8
thresh= 0.100E-01 alpha_mix = 0.100 |ddv_scf|^2 = 0.109E+00

iter # 27 total cpu time : 10812.9 secs av.it.: 1.1
thresh= 0.100E-01 alpha_mix = 0.100 |ddv_scf|^2 = 0.121E-01

iter # 28 total cpu time : 10819.0 secs av.it.: 1.0
thresh= 0.100E-01 alpha_mix = 0.100 |ddv_scf|^2 = 0.121E-01

iter # 29 total cpu time : 10828.0 secs av.it.: 3.4
thresh= 0.100E-01 alpha_mix = 0.100 |ddv_scf|^2 = 0.229E+00

iter # 30 total cpu time : 10833.8 secs av.it.: 1.0
thresh= 0.100E-01 alpha_mix = 0.100 |ddv_scf|^2 = 0.229E+00

iter # 31 total cpu time : 10841.1 secs av.it.: 2.1
thresh= 0.100E-01 alpha_mix = 0.100 |ddv_scf|^2 = 0.673E-01

iter # 32 total cpu time : 10846.2 secs av.it.: 1.0
thresh= 0.100E-01 alpha_mix = 0.100 |ddv_scf|^2 = 0.673E-01

iter # 33 total cpu time : 10855.3 secs av.it.: 3.1
thresh= 0.100E-01 alpha_mix = 0.100 |ddv_scf|^2 = 0.329E+01

iter # 34 total cpu time : 10867.7 secs av.it.: 5.8
thresh= 0.100E-01 alpha_mix = 0.100 |ddv_scf|^2 = 0.949E+02

iter # 35 total cpu time : 10880.9 secs av.it.: 6.2
thresh= 0.100E-01 alpha_mix = 0.100 |ddv_scf|^2 = 0.316E+03

iter # 36 total cpu time : 10895.1 secs av.it.: 7.1
thresh= 0.100E-01 alpha_mix = 0.100 |ddv_scf|^2 = 0.846E+03

iter # 37 total cpu time : 10910.3 secs av.it.: 7.9
thresh= 0.100E-01 alpha_mix = 0.100 |ddv_scf|^2 = 0.126E+02

iter # 38 total cpu time : 10920.9 secs av.it.: 4.1
thresh= 0.100E-01 alpha_mix = 0.100 |ddv_scf|^2 = 0.277E+00

iter # 39 total cpu time : 10927.5 secs av.it.: 1.1
thresh= 0.100E-01 alpha_mix = 0.100 |ddv_scf|^2 = 0.299E-01

iter # 40 total cpu time : 10934.2 secs av.it.: 1.1
thresh= 0.100E-01 alpha_mix = 0.100 |ddv_scf|^2 = 0.299E-01

iter # 41 total cpu time : 10941.0 secs av.it.: 2.0
thresh= 0.100E-01 alpha_mix = 0.100 |ddv_scf|^2 = 0.299E-01

iter # 42 total cpu time : 10950.1 secs av.it.: 3.1
thresh= 0.100E-01 alpha_mix = 0.100 |ddv_scf|^2 = 0.104E+01

iter # 43 total cpu time : 10958.9 secs av.it.: 3.1
thresh= 0.100E-01 alpha_mix = 0.100 |ddv_scf|^2 = 0.278E+01

iter # 44 total cpu time : 10967.9 secs av.it.: 3.1
thresh= 0.100E-01 alpha_mix = 0.100 |ddv_scf|^2 = 0.971E+01

iter # 45 total cpu time : 10977.0 secs av.it.: 3.1
thresh= 0.100E-01 alpha_mix = 0.100 |ddv_scf|^2 = 0.282E+01

iter # 46 total cpu time : 10986.5 secs av.it.: 3.8
thresh= 0.100E-01 alpha_mix = 0.100 |ddv_scf|^2 = 0.106E+00

iter # 47 total cpu time : 10992.4 secs av.it.: 1.1
thresh= 0.100E-01 alpha_mix = 0.100 |ddv_scf|^2 = 0.550E-02

iter # 48 total cpu time : 10999.5 secs av.it.: 2.0
thresh= 0.742E-02 alpha_mix = 0.100 |ddv_scf|^2 = 0.550E-02

iter # 49 total cpu time : 11006.6 secs av.it.: 2.1
thresh= 0.742E-02 alpha_mix = 0.100 |ddv_scf|^2 = 0.846E-02

iter # 50 total cpu time : 11012.0 secs av.it.: 1.0
thresh= 0.920E-02 alpha_mix = 0.100 |ddv_scf|^2 = 0.846E-02

iter # 51 total cpu time : 11020.1 secs av.it.: 2.4
thresh= 0.920E-02 alpha_mix = 0.100 |ddv_scf|^2 = 0.846E-02

iter # 52 total cpu time : 11026.2 secs av.it.: 1.0
thresh= 0.920E-02 alpha_mix = 0.100 |ddv_scf|^2 = 0.846E-02

iter # 53 total cpu time : 11035.2 secs av.it.: 3.1
thresh= 0.920E-02 alpha_mix = 0.100 |ddv_scf|^2 = 0.392E+00

iter # 54 total cpu time : 11047.0 secs av.it.: 5.1
thresh= 0.100E-01 alpha_mix = 0.100 |ddv_scf|^2 = 0.154E+02

iter # 55 total cpu time : 11061.5 secs av.it.: 7.0
thresh= 0.100E-01 alpha_mix = 0.100 |ddv_scf|^2 = 0.157E+03

iter # 56 total cpu time : 11075.8 secs av.it.: 7.1
thresh= 0.100E-01 alpha_mix = 0.100 |ddv_scf|^2 = 0.543E+01

iter # 57 total cpu time : 11087.1 secs av.it.: 4.9
thresh= 0.100E-01 alpha_mix = 0.100 |ddv_scf|^2 = 0.848E-02

iter # 58 total cpu time : 11094.0 secs av.it.: 2.0
thresh= 0.921E-02 alpha_mix = 0.100 |ddv_scf|^2 = 0.848E-02

iter # 59 total cpu time : 11104.1 secs av.it.: 4.1
thresh= 0.921E-02 alpha_mix = 0.100 |ddv_scf|^2 = 0.291E+00

iter # 60 total cpu time : 11110.3 secs av.it.: 1.1
thresh= 0.100E-01 alpha_mix = 0.100 |ddv_scf|^2 = 0.584E-01

iter # 61 total cpu time : 11117.3 secs av.it.: 2.1
thresh= 0.100E-01 alpha_mix = 0.100 |ddv_scf|^2 = 0.524E-02

iter # 62 total cpu time : 11123.8 secs av.it.: 1.7
thresh= 0.724E-02 alpha_mix = 0.100 |ddv_scf|^2 = 0.524E-02

iter # 63 total cpu time : 11130.4 secs av.it.: 2.0
thresh= 0.724E-02 alpha_mix = 0.100 |ddv_scf|^2 = 0.524E-02

iter # 64 total cpu time : 11135.5 secs av.it.: 1.0
thresh= 0.724E-02 alpha_mix = 0.100 |ddv_scf|^2 = 0.524E-02

iter # 65 total cpu time : 11140.7 secs av.it.: 1.0
thresh= 0.724E-02 alpha_mix = 0.100 |ddv_scf|^2 = 0.524E-02

iter # 66 total cpu time : 11168.5 secs av.it.: 16.4
thresh= 0.724E-02 alpha_mix = 0.100 |ddv_scf|^2 = 0.297E+07

iter # 67 total cpu time : 11196.8 secs av.it.: 16.8
thresh= 0.100E-01 alpha_mix = 0.100 |ddv_scf|^2 = 0.380E+08

iter # 68 total cpu time : 11222.5 secs av.it.: 15.3
thresh= 0.100E-01 alpha_mix = 0.100 |ddv_scf|^2 = 0.245E+08

iter # 69 total cpu time : 11250.2 secs av.it.: 16.6
thresh= 0.100E-01 alpha_mix = 0.100 |ddv_scf|^2 = 0.294E+07

iter # 70 total cpu time : 11276.4 secs av.it.: 15.3
thresh= 0.100E-01 alpha_mix = 0.100 |ddv_scf|^2 = 0.117E+05

iter # 71 total cpu time : 11298.4 secs av.it.: 12.4
thresh= 0.100E-01 alpha_mix = 0.100 |ddv_scf|^2 = 0.653E+03

iter # 72 total cpu time : 11319.4 secs av.it.: 11.7
thresh= 0.100E-01 alpha_mix = 0.100 |ddv_scf|^2 = 0.672E+03

iter # 73 total cpu time : 11342.2 secs av.it.: 13.4
thresh= 0.100E-01 alpha_mix = 0.100 |ddv_scf|^2 = 0.193E-01
kpoint 2 ibnd 81 solve_linter: root not converged 0.304E+00

iter # 74 total cpu time : 11362.9 secs av.it.: 11.7
thresh= 0.100E-01 alpha_mix = 0.100 |ddv_scf|^2 = 0.899E+02

iter # 75 total cpu time : 11382.1 secs av.it.: 9.8
thresh= 0.100E-01 alpha_mix = 0.100 |ddv_scf|^2 = 0.133E+03

iter # 76 total cpu time : 11397.7 secs av.it.: 7.9
thresh= 0.100E-01 alpha_mix = 0.100 |ddv_scf|^2 = 0.167E+03

iter # 77 total cpu time : 11417.7 secs av.it.: 11.3
thresh= 0.100E-01 alpha_mix = 0.100 |ddv_scf|^2 = 0.383E+01

iter # 78 total cpu time : 11435.0 secs av.it.: 8.8
thresh= 0.100E-01 alpha_mix = 0.100 |ddv_scf|^2 = 0.733E-03

iter # 79 total cpu time : 11455.7 secs av.it.: 11.7
thresh= 0.271E-02 alpha_mix = 0.100 |ddv_scf|^2 = 0.258E-02

iter # 80 total cpu time : 11477.5 secs av.it.: 12.6
thresh= 0.508E-02 alpha_mix = 0.100 |ddv_scf|^2 = 0.135E+00

iter # 81 total cpu time : 11491.4 secs av.it.: 6.7
thresh= 0.100E-01 alpha_mix = 0.100 |ddv_scf|^2 = 0.166E-01

iter # 82 total cpu time : 11505.2 secs av.it.: 6.8
thresh= 0.100E-01 alpha_mix = 0.100 |ddv_scf|^2 = 0.276E-03

iter # 83 total cpu time : 11521.6 secs av.it.: 8.7
thresh= 0.166E-02 alpha_mix = 0.100 |ddv_scf|^2 = 0.197E-02

iter # 84 total cpu time : 11536.2 secs av.it.: 7.2
thresh= 0.444E-02 alpha_mix = 0.100 |ddv_scf|^2 = 0.197E-02

iter # 85 total cpu time : 11554.4 secs av.it.: 9.5
thresh= 0.444E-02 alpha_mix = 0.100 |ddv_scf|^2 = 0.237E+00

iter # 86 total cpu time : 11568.3 secs av.it.: 6.7
thresh= 0.100E-01 alpha_mix = 0.100 |ddv_scf|^2 = 0.191E+00

iter # 87 total cpu time : 11582.5 secs av.it.: 6.9
thresh= 0.100E-01 alpha_mix = 0.100 |ddv_scf|^2 = 0.600E-01

iter # 88 total cpu time : 11591.9 secs av.it.: 3.7
thresh= 0.100E-01 alpha_mix = 0.100 |ddv_scf|^2 = 0.600E-01

iter # 89 total cpu time : 11604.1 secs av.it.: 5.7
thresh= 0.100E-01 alpha_mix = 0.100 |ddv_scf|^2 = 0.933E+00

iter # 90 total cpu time : 11614.2 secs av.it.: 4.1
thresh= 0.100E-01 alpha_mix = 0.100 |ddv_scf|^2 = 0.221E+01

iter # 91 total cpu time : 11623.2 secs av.it.: 3.0
thresh= 0.100E-01 alpha_mix = 0.100 |ddv_scf|^2 = 0.221E+01

iter # 92 total cpu time : 11633.0 secs av.it.: 4.1
thresh= 0.100E-01 alpha_mix = 0.100 |ddv_scf|^2 = 0.609E+00

iter # 93 total cpu time : 11643.1 secs av.it.: 4.1
thresh= 0.100E-01 alpha_mix = 0.100 |ddv_scf|^2 = 0.461E-01

iter # 94 total cpu time : 11649.2 secs av.it.: 1.0
thresh= 0.100E-01 alpha_mix = 0.100 |ddv_scf|^2 = 0.461E-01

iter # 95 total cpu time : 11658.7 secs av.it.: 4.1
thresh= 0.100E-01 alpha_mix = 0.100 |ddv_scf|^2 = 0.143E+00

iter # 96 total cpu time : 11666.1 secs av.it.: 2.2
thresh= 0.100E-01 alpha_mix = 0.100 |ddv_scf|^2 = 0.143E+00

iter # 97 total cpu time : 11673.9 secs av.it.: 3.0
thresh= 0.100E-01 alpha_mix = 0.100 |ddv_scf|^2 = 0.143E+00

iter # 98 total cpu time : 11680.4 secs av.it.: 1.7
thresh= 0.100E-01 alpha_mix = 0.100 |ddv_scf|^2 = 0.143E+00

iter # 99 total cpu time : 11686.7 secs av.it.: 1.1
thresh= 0.100E-01 alpha_mix = 0.100 |ddv_scf|^2 = 0.581E+00

iter # 100 total cpu time : 11693.7 secs av.it.: 2.1
thresh= 0.100E-01 alpha_mix = 0.100 |ddv_scf|^2 = 0.345E+00

End of self-consistent calculation

No convergence has been achieved

PHONON : 3h14m CPU time

INITIALIZATION:
phq_setup : 0.07s CPU
phq_init : 109.25s CPU

phq_init : 109.25s CPU
init_vloc : 0.19s CPU ( 2 calls, 0.095 s avg)
init_us_1 : 1.00s CPU
newd : 0.33s CPU
dvanqq : 34.72s CPU
drho : 72.56s CPU
cmpt_qdipol : 0.08s CPU ( 24 calls, 0.003 s avg)

DIELECTRIC CONSTANT AND EFFECTIVE CHARGES:
solve_e : 736.31s CPU
dielec : 0.18s CPU
zstar_eu : 772.94s CPU

DYNAMICAL MATRIX:
dynmat0 : 2.31s CPU
phqscf : 10077.15s CPU

phqscf : 10077.15s CPU
solve_linter : 9685.63s CPU ( 24 calls, 403.568 s avg)
drhodv : 27.46s CPU ( 23 calls, 1.194 s avg)
add_zstar_ue : 0.98s CPU ( 23 calls, 0.043 s avg)
add_zstar_us : 363.06s CPU ( 23 calls, 15.785 s avg)





From lyu7 at ncsu.edu  Wed Apr 12 16:38:04 2006
From: lyu7 at ncsu.edu (Liping YU)
Date: Wed, 12 Apr 2006 10:38:04 -0400
Subject: [Pw_forum] error on phonon calculation  (root not converged)
In-Reply-To: <443D0AAF.6080707@ncsu.edu>
References: <20060407150924.61726.qmail@web60325.mail.yahoo.com> <4439515D.2050505@ncsu.edu> <200604101422.15850.giannozz@nest.sns.it> <443A4FC9.7090608@mit.edu> <443A7B2B.4060202@ncsu.edu> <443A7E77.3000004@mit.edu> <443A9217.10309@ncsu.edu> <443A9507.9060209@mit.edu> <443D0AAF.6080707@ncsu.edu>
Message-ID: <443D10CC.5060206@ncsu.edu>

Liping YU wrote:

>Nicola Marzari wrote:
>
>  
>
>>>>Next, if you use the same identical input files, but you put
>>>>Pb instead of Sr, do you get identical dielectric constants
>>>>     
>>>>
>>>>        
>>>>
>>>>from 1x1x1 and 2x2x1 ?
>>>   
>>>
>>>      
>>>
>>>>     
>>>>
>>>>        
>>>>
>>>No, for PbTiO3, it's tetragonal structure, not cubic one as SrTiO3. 
>>>   
>>>
>>>      
>>>
>>I know - I just wanted to make the point that if there were something
>>odd with the pseudopotential (although I do not know what - a ghost
>>state ? Even that is unlikey to appear in only one of the two
>>calculations) you could use the exact SrTiO3 input files, but just put
>>Pb instead of Sr.
>> 
>>
>>    
>>
I replaced Sr (and its PP file name) by Pb in the inputfile of SrTiO3 and
leave all other parameters unchanged. The odd problems (unconvergence and
large dielectric constant in plane) disappeared.

>>>Note for no reason I used 4x4x4 k-point grid for both unit cell and 
>>>super cells.
>>>
>>>1x1x1 unit cell,
>>>   (       7.981121520       0.000000000       0.000000000 )
>>>   (       0.000000000       7.981121520       0.000000000 )
>>>   (       0.000000000       0.000000000       7.542263658 )
>>>
>>>2x2x1 supercell,
>>>   (       7.775208874       0.000000000       0.000000000 )
>>>   (       0.000000000       7.775208874       0.000000000 )
>>>   (       0.000000000       0.000000000       7.491522972 )
>>>
>>>Maybe I should also try same k-point (4x4x4) sampling for SrTiO3 in two
>>>different cells, although they are not equivalent, and see what will happen.
>>>
>>>   
>>>
>>>      
>>>
>>OK, this could show you if there were some odd problem with the
>>calculation with the larger number of kpoints. Also, make sure
>>oyu have no leftovers from previous calculations, i.e. your directories
>>are clean.
>>
>> 
>>
>>    
>>
>Here is the result for this case. The odd problem still exists. Thank
>you very much!
>
I should have made odd problem more clear here.  The dielectric constant
in plane reduced from 222.1 (using 4x4x8 k-point grid) to 6.380 
(4x4x4 k-point grid). The unconvergence problem came up in the 
phonon calculation of Representation # 24 (mode # 34). Pls see below. 
It seems that different k-point samplings can affect the results a lot. 
And so something of SrTiO3 is very sensitive to k-point sampling, though
I don't what it is.  Thank you very much for your help.

liping


Output file ( 4x4x4 k-point grid
================================================================
Program PHONON v.3.0 starts ...
Today is 11Apr2006 at 1: 0:10

Parallel version (MPI)

Number of processors in use: 32
K-points division: npool = 2
R & G space division: proc/pool = 16

Ultrasoft (Vanderbilt) Pseudopotentials

Reading file cb-st.save ... only dimensions
read complete

Reading file cb-st.save ... all except wavefuctions
read complete

Planes per process (thick) : nr3 = 40 npp = 3 ncplane = 6400

Planes per process (smooth): nr3s= 28 npps= 2 ncplanes= 3136

Proc/ planes cols G planes cols G columns G
Pool (dense grid) (smooth grid) (wavefct grid)
1 3 283 7211 2 126 2130 37 349
2 3 283 7211 2 127 2137 37 349
3 3 283 7211 2 127 2135 37 349
4 3 285 7211 2 127 2135 37 349
5 3 285 7211 2 127 2133 37 349
6 3 285 7211 2 127 2135 37 349
7 3 285 7211 2 127 2133 37 349
8 3 284 7210 2 127 2131 37 349
9 2 284 7210 2 127 2131 37 349
10 2 284 7210 2 127 2127 38 350
11 2 284 7210 2 126 2122 39 349
12 2 284 7210 2 126 2126 39 349
13 2 284 7210 1 126 2132 38 348
14 2 284 7210 1 126 2134 38 348
15 2 284 7210 1 126 2132 38 348
16 2 284 7210 1 126 2132 38 348
0 40 4545 115367 28 2025 34105 601 5581


nbndx = 80 nbnd = 80 natomwfc = 108 npwx = 276
nelec = 160.00 nkb = 240 ngl = 944
autoval = -.5378E+01
Real(aut_vet)= ( 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000)
Real(aut_vet)= ( 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000)
Real(aut_vet)= ( 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000)
[.....]
Imm(aut_vet)= ( 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000)
Imm(aut_vet)= ( 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000)

'2*2*1 cb srtio3'

crystal is

bravais-lattice index = 6
lattice parameter (a_0) = 14.5533 a.u.
unit-cell volume = 1541.1754 (a.u.)^3
number of atoms/cell = 20
number of atomic types = 3
kinetic-energy cut-off = 30.0000 Ry
charge density cut-off = 270.0000 Ry
convergence threshold = 1.0E-14
beta = 0.1000
number of iterations used = 4

celldm(1)= 14.55327 celldm(2)= 0.00000 celldm(3)= 0.50000
celldm(4)= 0.00000 celldm(5)= 0.00000 celldm(6)= 0.00000

crystal axes: (cart. coord. in units of a_0)
a(1) = ( 1.0000 0.0000 0.0000 )
a(2) = ( 0.0000 1.0000 0.0000 )
a(3) = ( 0.0000 0.0000 0.5000 )

reciprocal axes: (cart. coord. in units 2 pi/a_0)
b(1) = ( 1.0000 0.0000 0.0000 )
b(2) = ( 0.0000 1.0000 0.0000 )
b(3) = ( 0.0000 0.0000 2.0000 )


Atoms inside the unit cell:

Cartesian axes

site n. atom mass positions (a_0 units)
1 Sr 87.6200 tau( 1) = ( 0.00000 0.00000 0.00000 )
2 Sr 87.6200 tau( 2) = ( 0.50000 0.00000 0.00000 )
3 Sr 87.6200 tau( 3) = ( 0.00000 0.50000 0.00000 )
4 Sr 87.6200 tau( 4) = ( 0.50000 0.50000 0.00000 )
5 O 16.0000 tau( 5) = ( 0.25000 0.25000 0.00000 )
6 O 16.0000 tau( 6) = ( 0.25000 0.75000 0.00000 )
7 O 16.0000 tau( 7) = ( 0.75000 0.25000 0.00000 )
8 O 16.0000 tau( 8) = ( 0.75000 0.75000 0.00000 )
9 Ti 47.8670 tau( 9) = ( 0.25000 0.25000 0.25000 )
10 Ti 47.8670 tau(10) = ( 0.25000 0.75000 0.25000 )
11 Ti 47.8670 tau(11) = ( 0.75000 0.25000 0.25000 )
12 Ti 47.8670 tau(12) = ( 0.75000 0.75000 0.25000 )
13 O 16.0000 tau(13) = ( 0.00000 0.25000 0.25000 )
14 O 16.0000 tau(14) = ( 0.00000 0.75000 0.25000 )
15 O 16.0000 tau(15) = ( 0.50000 0.25000 0.25000 )
16 O 16.0000 tau(16) = ( 0.50000 0.75000 0.25000 )
17 O 16.0000 tau(17) = ( 0.25000 0.00000 0.25000 )
18 O 16.0000 tau(18) = ( 0.75000 0.00000 0.25000 )
19 O 16.0000 tau(19) = ( 0.25000 0.50000 0.25000 )
20 O 16.0000 tau(20) = ( 0.75000 0.50000 0.25000 )

Computing dynamical matrix for
q = ( 0.00000 0.00000 0.00000 )

17 Sym.Ops. (with q -> -q+G )

s frac. trans.

isym = 1 identity

cryst. s( 1) = ( 1 0 0 )
( 0 1 0 )
( 0 0 1 )
[.........]
isym = 17 identity

cryst. s(17) = ( 1 0 0 )
( 0 1 0 )
( 0 0 1 )

cart. s(17) = ( 1.0000000 0.0000000 0.0000000 )
( 0.0000000 1.0000000 0.0000000 )
( 0.0000000 0.0000000 1.0000000 )


G cutoff = 1448.5230 ( 7211 G-vectors) FFT grid: ( 80, 80, 40)
G cutoff = 643.7880 ( 2130 G-vectors) smooth grid: ( 56, 56, 28)
number of k points= 18
cart. coord. in units 2pi/a_0
k( 1) = ( 0.0000000 0.0000000 0.0000000), wk = 0.0312500
k( 2) = ( 0.0000000 0.0000000 0.5000000), wk = 0.0625000
k( 3) = ( 0.0000000 0.0000000 -1.0000000), wk = 0.0312500
k( 4) = ( 0.0000000 0.2500000 0.0000000), wk = 0.1250000
k( 5) = ( 0.0000000 0.2500000 0.5000000), wk = 0.2500000
k( 6) = ( 0.0000000 0.2500000 -1.0000000), wk = 0.1250000
k( 7) = ( 0.0000000 -0.5000000 0.0000000), wk = 0.0625000
k( 8) = ( 0.0000000 -0.5000000 0.5000000), wk = 0.1250000
k( 9) = ( 0.0000000 -0.5000000 -1.0000000), wk = 0.0625000
k( 10) = ( 0.2500000 0.2500000 0.0000000), wk = 0.1250000
k( 11) = ( 0.2500000 0.2500000 0.5000000), wk = 0.2500000
k( 12) = ( 0.2500000 0.2500000 -1.0000000), wk = 0.1250000
k( 13) = ( 0.2500000 -0.5000000 0.0000000), wk = 0.1250000
k( 14) = ( 0.2500000 -0.5000000 0.5000000), wk = 0.2500000
k( 15) = ( 0.2500000 -0.5000000 -1.0000000), wk = 0.1250000
k( 16) = ( -0.5000000 -0.5000000 0.0000000), wk = 0.0312500
k( 17) = ( -0.5000000 -0.5000000 0.5000000), wk = 0.0625000
k( 18) = ( -0.5000000 -0.5000000 -1.0000000), wk = 0.0312500

cryst. coord.
k( 1) = ( 0.0000000 0.0000000 0.0000000), wk = 0.0312500
k( 2) = ( 0.0000000 0.0000000 0.2500000), wk = 0.0625000
k( 3) = ( 0.0000000 0.0000000 -0.5000000), wk = 0.0312500
k( 4) = ( 0.0000000 0.2500000 0.0000000), wk = 0.1250000
k( 5) = ( 0.0000000 0.2500000 0.2500000), wk = 0.2500000
k( 6) = ( 0.0000000 0.2500000 -0.5000000), wk = 0.1250000
k( 7) = ( 0.0000000 -0.5000000 0.0000000), wk = 0.0625000
k( 8) = ( 0.0000000 -0.5000000 0.2500000), wk = 0.1250000
k( 9) = ( 0.0000000 -0.5000000 -0.5000000), wk = 0.0625000
k( 10) = ( 0.2500000 0.2500000 0.0000000), wk = 0.1250000
k( 11) = ( 0.2500000 0.2500000 0.2500000), wk = 0.2500000
k( 12) = ( 0.2500000 0.2500000 -0.5000000), wk = 0.1250000
k( 13) = ( 0.2500000 -0.5000000 0.0000000), wk = 0.1250000
k( 14) = ( 0.2500000 -0.5000000 0.2500000), wk = 0.2500000
k( 15) = ( 0.2500000 -0.5000000 -0.5000000), wk = 0.1250000
k( 16) = ( -0.5000000 -0.5000000 0.0000000), wk = 0.0312500
k( 17) = ( -0.5000000 -0.5000000 0.2500000), wk = 0.0625000
k( 18) = ( -0.5000000 -0.5000000 -0.5000000), wk = 0.0312500

pseudo 1 is st (US) zval = 10.0 lmax= 2 lloc= 0
Version 0 0 0 of US pseudo code

Using log mesh of 883 points

The pseudopotential has 6 beta functions with:

l(1) = 0
l(2) = 0
l(3) = 1
l(4) = 1
l(5) = 2
l(6) = 2

Q(r) pseudized with 8 coefficients, rinner = 1.000 1.000 1.000
1.000 1.000

pseudo 2 is ti (US) zval = 12.0 lmax= 2 lloc= 0
Version 0 0 0 of US pseudo code

Using log mesh of 851 points

The pseudopotential has 6 beta functions with:

l(1) = 0
l(2) = 0
l(3) = 1
l(4) = 1
l(5) = 2
l(6) = 2

Q(r) pseudized with 5 coefficients, rinner = 1.000 1.000 1.000
1.000 1.000

pseudo 3 is ox (US) zval = 6.0 lmax= 1 lloc= 0
Version 0 0 0 of US pseudo code

Using log mesh of 737 points

The pseudopotential has 4 beta functions with:

l(1) = 0
l(2) = 0
l(3) = 1
l(4) = 1

Q(r) pseudized with 8 coefficients, rinner = 0.700 0.700 0.700



Atomic displacements:
There are 44 irreducible representations

Representation 1 1 modes - To be done
Phonon polarizations are as follows:

mode # 1
( 0.00000 0.00000 )
( 0.00000 0.00000 )
( 0.00000 0.00000 )
( 0.00000 0.00000 )
( 0.00000 0.00000 )
( 0.00000 0.00000 )
[........]
( 0.00000 0.00000 )
( 0.00000 0.00000 )
( -0.50000 0.00000 )
( 0.00000 0.00000 )
( 0.00000 0.00000 )
( -0.50000 0.00000 )
PHONON : 1m50.15s CPU time


Alpha used in Ewald sum = 2.3000

Electric Fields Calculation

iter # 1 total cpu time : 295.2 secs av.it.: 7.2
thresh= 0.100E-01 alpha_mix = 0.100 |ddv_scf|^2 = 0.430E-08

iter # 2 total cpu time : 367.1 secs av.it.: 13.0
thresh= 0.656E-05 alpha_mix = 0.100 |ddv_scf|^2 = 0.309E-08

iter # 3 total cpu time : 448.7 secs av.it.: 14.9
thresh= 0.556E-05 alpha_mix = 0.100 |ddv_scf|^2 = 0.169E-09

iter # 4 total cpu time : 528.0 secs av.it.: 14.5
thresh= 0.130E-05 alpha_mix = 0.100 |ddv_scf|^2 = 0.174E-10

iter # 5 total cpu time : 609.2 secs av.it.: 14.9
thresh= 0.417E-06 alpha_mix = 0.100 |ddv_scf|^2 = 0.235E-11

iter # 6 total cpu time : 692.4 secs av.it.: 15.3
thresh= 0.153E-06 alpha_mix = 0.100 |ddv_scf|^2 = 0.155E-12

iter # 7 total cpu time : 766.8 secs av.it.: 13.9
thresh= 0.394E-07 alpha_mix = 0.100 |ddv_scf|^2 = 0.945E-13

iter # 8 total cpu time : 847.0 secs av.it.: 15.1
thresh= 0.307E-07 alpha_mix = 0.100 |ddv_scf|^2 = 0.660E-14

End of electric fields calculation

Dielectric constant in cartesian axis

( 6.380587095 0.000000000 0.000000000 )
( 0.000000000 6.380587095 0.000000000 )
( 0.000000000 0.000000000 6.611263268 )

Effective charges E-U in cartesian axis

atom 1
( 2.56446 0.00000 0.00000 )
( 0.00000 2.56446 0.00000 )
( 0.00000 0.00000 2.55308 )
atom 2
( 2.56529 0.00000 0.00000 )
( 0.00000 2.56442 0.00000 )
( 0.00000 0.00000 2.55308 )
atom 3
( 2.56442 0.00000 0.00000 )
( 0.00000 2.56529 0.00000 )
( 0.00000 0.00000 2.55308 )
atom 4
( 2.56532 0.00000 0.00000 )
( 0.00000 2.56532 0.00000 )
( 0.00000 0.00000 2.55308 )
atom 5
( -2.13094 -0.00001 0.00000 )
( -0.00001 -2.13094 0.00000 )
( 0.00000 0.00000 -6.05328 )
atom 6
( -2.13094 0.00001 0.00000 )
( 0.00001 -2.13094 0.00000 )
( 0.00000 0.00000 -6.05328 )
atom 7
( -2.13094 0.00001 0.00000 )
( 0.00001 -2.13094 0.00000 )
( 0.00000 0.00000 -6.05328 )
atom 8
( -2.13094 -0.00001 0.00000 )
( -0.00001 -2.13094 0.00000 )
( 0.00000 0.00000 -6.05328 )
atom 9
( 7.28587 -0.00004 0.00000 )
( -0.00004 7.28587 0.00000 )
( 0.00000 0.00000 7.43190 )
atom 10
( 7.28587 0.00004 0.00000 )
( 0.00004 7.28587 0.00000 )
( 0.00000 0.00000 7.43190 )
atom 11
( 7.28587 0.00004 0.00000 )
( 0.00004 7.28587 0.00000 )
( 0.00000 0.00000 7.43190 )
atom 12
( 7.28587 -0.00004 0.00000 )
( -0.00004 7.28587 0.00000 )
( 0.00000 0.00000 7.43190 )
atom 13
( -5.71166 0.00000 0.00000 )
( 0.00000 -2.04665 0.00000 )
( 0.00000 0.00000 -2.10683 )
atom 14
( -5.71166 0.00000 0.00000 )
( 0.00000 -2.04665 0.00000 )
( 0.00000 0.00000 -2.10683 )
atom 15
( -5.71103 0.00000 0.00000 )
( 0.00000 -2.04665 0.00000 )
( 0.00000 0.00000 -2.10684 )
atom 16
( -5.71103 0.00000 0.00000 )
( 0.00000 -2.04665 0.00000 )
( 0.00000 0.00000 -2.10684 )
atom 17
( -2.04665 0.00000 0.00000 )
( 0.00000 -5.71166 0.00000 )
( 0.00000 0.00000 -2.10683 )
atom 18
( -2.04665 0.00000 0.00000 )
( 0.00000 -5.71166 0.00000 )
( 0.00000 0.00000 -2.10683 )
atom 19
( -2.04665 0.00000 0.00000 )
( 0.00000 -5.71103 0.00000 )
( 0.00000 0.00000 -2.10684 )
atom 20
( -2.04665 0.00000 0.00000 )
( 0.00000 -5.71103 0.00000 )
( 0.00000 0.00000 -2.10684 )


Representation # 1 mode # 1

Self-consistent Calculation

iter # 1 total cpu time : 1635.4 secs av.it.: 6.5
thresh= 0.100E-01 alpha_mix = 0.100 |ddv_scf|^2 = 0.246E-06

iter # 2 total cpu time : 1656.4 secs av.it.: 11.5
thresh= 0.496E-04 alpha_mix = 0.100 |ddv_scf|^2 = 0.174E-06

iter # 3 total cpu time : 1681.4 secs av.it.: 14.4
thresh= 0.417E-04 alpha_mix = 0.100 |ddv_scf|^2 = 0.133E-08

iter # 4 total cpu time : 1706.2 secs av.it.: 14.1
thresh= 0.365E-05 alpha_mix = 0.100 |ddv_scf|^2 = 0.148E-09

iter # 5 total cpu time : 1731.5 secs av.it.: 14.8
thresh= 0.122E-05 alpha_mix = 0.100 |ddv_scf|^2 = 0.384E-11

iter # 6 total cpu time : 1758.3 secs av.it.: 15.4
thresh= 0.196E-06 alpha_mix = 0.100 |ddv_scf|^2 = 0.226E-12

iter # 7 total cpu time : 1784.6 secs av.it.: 15.5
thresh= 0.475E-07 alpha_mix = 0.100 |ddv_scf|^2 = 0.300E-13

iter # 8 total cpu time : 1810.6 secs av.it.: 15.2
thresh= 0.173E-07 alpha_mix = 0.100 |ddv_scf|^2 = 0.665E-15

End of self-consistent calculation

Convergence has been achieved


* [......] ( Everything is fine here )*


Representation # 24 mode # 34

Self-consistent Calculation

iter # 1 total cpu time : 10453.7 secs av.it.: 8.6
thresh= 0.100E-01 alpha_mix = 0.100 |ddv_scf|^2 = 0.248E-04

iter # 2 total cpu time : 10474.7 secs av.it.: 11.4
thresh= 0.498E-03 alpha_mix = 0.100 |ddv_scf|^2 = 0.720E-05

iter # 3 total cpu time : 10497.1 secs av.it.: 12.6
thresh= 0.268E-03 alpha_mix = 0.100 |ddv_scf|^2 = 0.161E-06

iter # 4 total cpu time : 10522.5 secs av.it.: 14.4
thresh= 0.401E-04 alpha_mix = 0.100 |ddv_scf|^2 = 0.197E-07

iter # 5 total cpu time : 10545.1 secs av.it.: 13.0
thresh= 0.140E-04 alpha_mix = 0.100 |ddv_scf|^2 = 0.982E-08

iter # 6 total cpu time : 10569.9 secs av.it.: 14.4
thresh= 0.991E-05 alpha_mix = 0.100 |ddv_scf|^2 = 0.625E-10

iter # 7 total cpu time : 10594.1 secs av.it.: 14.0
thresh= 0.791E-06 alpha_mix = 0.100 |ddv_scf|^2 = 0.239E-10

iter # 8 total cpu time : 10619.9 secs av.it.: 15.4
thresh= 0.489E-06 alpha_mix = 0.100 |ddv_scf|^2 = 0.658E-12

iter # 9 total cpu time : 10645.8 secs av.it.: 15.2
thresh= 0.811E-07 alpha_mix = 0.100 |ddv_scf|^2 = 0.805E-11

iter # 10 total cpu time : 10662.0 secs av.it.: 8.2
thresh= 0.284E-06 alpha_mix = 0.100 |ddv_scf|^2 = 0.414E-07

iter # 11 total cpu time : 10672.2 secs av.it.: 3.8
thresh= 0.203E-04 alpha_mix = 0.100 |ddv_scf|^2 = 0.414E-07

iter # 12 total cpu time : 10681.4 secs av.it.: 3.6
thresh= 0.203E-04 alpha_mix = 0.100 |ddv_scf|^2 = 0.696E-07

iter # 13 total cpu time : 10690.3 secs av.it.: 3.1
thresh= 0.264E-04 alpha_mix = 0.100 |ddv_scf|^2 = 0.696E-07

iter # 14 total cpu time : 10697.7 secs av.it.: 2.0
thresh= 0.264E-04 alpha_mix = 0.100 |ddv_scf|^2 = 0.696E-07

iter # 15 total cpu time : 10707.0 secs av.it.: 3.0
thresh= 0.264E-04 alpha_mix = 0.100 |ddv_scf|^2 = 0.429E-07

iter # 16 total cpu time : 10716.7 secs av.it.: 3.7
thresh= 0.207E-04 alpha_mix = 0.100 |ddv_scf|^2 = 0.470E-06

iter # 17 total cpu time : 10722.2 secs av.it.: 1.0
thresh= 0.686E-04 alpha_mix = 0.100 |ddv_scf|^2 = 0.470E-06

iter # 18 total cpu time : 10727.9 secs av.it.: 1.0
thresh= 0.686E-04 alpha_mix = 0.100 |ddv_scf|^2 = 0.470E-06

iter # 19 total cpu time : 10733.4 secs av.it.: 1.0
thresh= 0.686E-04 alpha_mix = 0.100 |ddv_scf|^2 = 0.470E-06

iter # 20 total cpu time : 10739.2 secs av.it.: 1.0
thresh= 0.686E-04 alpha_mix = 0.100 |ddv_scf|^2 = 0.470E-06

iter # 21 total cpu time : 10762.8 secs av.it.: 13.9
thresh= 0.686E-04 alpha_mix = 0.100 |ddv_scf|^2 = 0.163E+02

iter # 22 total cpu time : 10773.0 secs av.it.: 4.1
thresh= 0.100E-01 alpha_mix = 0.100 |ddv_scf|^2 = 0.556E+01

iter # 23 total cpu time : 10783.3 secs av.it.: 4.1
thresh= 0.100E-01 alpha_mix = 0.100 |ddv_scf|^2 = 0.627E+00

iter # 24 total cpu time : 10790.9 secs av.it.: 2.1
thresh= 0.100E-01 alpha_mix = 0.100 |ddv_scf|^2 = 0.451E-01

iter # 25 total cpu time : 10798.3 secs av.it.: 2.0
thresh= 0.100E-01 alpha_mix = 0.100 |ddv_scf|^2 = 0.451E-01

iter # 26 total cpu time : 10806.6 secs av.it.: 2.8
thresh= 0.100E-01 alpha_mix = 0.100 |ddv_scf|^2 = 0.109E+00

iter # 27 total cpu time : 10812.9 secs av.it.: 1.1
thresh= 0.100E-01 alpha_mix = 0.100 |ddv_scf|^2 = 0.121E-01

iter # 28 total cpu time : 10819.0 secs av.it.: 1.0
thresh= 0.100E-01 alpha_mix = 0.100 |ddv_scf|^2 = 0.121E-01

iter # 29 total cpu time : 10828.0 secs av.it.: 3.4
thresh= 0.100E-01 alpha_mix = 0.100 |ddv_scf|^2 = 0.229E+00

iter # 30 total cpu time : 10833.8 secs av.it.: 1.0
thresh= 0.100E-01 alpha_mix = 0.100 |ddv_scf|^2 = 0.229E+00

iter # 31 total cpu time : 10841.1 secs av.it.: 2.1
thresh= 0.100E-01 alpha_mix = 0.100 |ddv_scf|^2 = 0.673E-01

iter # 32 total cpu time : 10846.2 secs av.it.: 1.0
thresh= 0.100E-01 alpha_mix = 0.100 |ddv_scf|^2 = 0.673E-01

iter # 33 total cpu time : 10855.3 secs av.it.: 3.1
thresh= 0.100E-01 alpha_mix = 0.100 |ddv_scf|^2 = 0.329E+01

iter # 34 total cpu time : 10867.7 secs av.it.: 5.8
thresh= 0.100E-01 alpha_mix = 0.100 |ddv_scf|^2 = 0.949E+02

iter # 35 total cpu time : 10880.9 secs av.it.: 6.2
thresh= 0.100E-01 alpha_mix = 0.100 |ddv_scf|^2 = 0.316E+03

iter # 36 total cpu time : 10895.1 secs av.it.: 7.1
thresh= 0.100E-01 alpha_mix = 0.100 |ddv_scf|^2 = 0.846E+03

iter # 37 total cpu time : 10910.3 secs av.it.: 7.9
thresh= 0.100E-01 alpha_mix = 0.100 |ddv_scf|^2 = 0.126E+02

iter # 38 total cpu time : 10920.9 secs av.it.: 4.1
thresh= 0.100E-01 alpha_mix = 0.100 |ddv_scf|^2 = 0.277E+00

iter # 39 total cpu time : 10927.5 secs av.it.: 1.1
thresh= 0.100E-01 alpha_mix = 0.100 |ddv_scf|^2 = 0.299E-01

iter # 40 total cpu time : 10934.2 secs av.it.: 1.1
thresh= 0.100E-01 alpha_mix = 0.100 |ddv_scf|^2 = 0.299E-01

iter # 41 total cpu time : 10941.0 secs av.it.: 2.0
thresh= 0.100E-01 alpha_mix = 0.100 |ddv_scf|^2 = 0.299E-01

iter # 42 total cpu time : 10950.1 secs av.it.: 3.1
thresh= 0.100E-01 alpha_mix = 0.100 |ddv_scf|^2 = 0.104E+01

iter # 43 total cpu time : 10958.9 secs av.it.: 3.1
thresh= 0.100E-01 alpha_mix = 0.100 |ddv_scf|^2 = 0.278E+01

iter # 44 total cpu time : 10967.9 secs av.it.: 3.1
thresh= 0.100E-01 alpha_mix = 0.100 |ddv_scf|^2 = 0.971E+01

iter # 45 total cpu time : 10977.0 secs av.it.: 3.1
thresh= 0.100E-01 alpha_mix = 0.100 |ddv_scf|^2 = 0.282E+01

iter # 46 total cpu time : 10986.5 secs av.it.: 3.8
thresh= 0.100E-01 alpha_mix = 0.100 |ddv_scf|^2 = 0.106E+00

iter # 47 total cpu time : 10992.4 secs av.it.: 1.1
thresh= 0.100E-01 alpha_mix = 0.100 |ddv_scf|^2 = 0.550E-02

iter # 48 total cpu time : 10999.5 secs av.it.: 2.0
thresh= 0.742E-02 alpha_mix = 0.100 |ddv_scf|^2 = 0.550E-02

iter # 49 total cpu time : 11006.6 secs av.it.: 2.1
thresh= 0.742E-02 alpha_mix = 0.100 |ddv_scf|^2 = 0.846E-02

iter # 50 total cpu time : 11012.0 secs av.it.: 1.0
thresh= 0.920E-02 alpha_mix = 0.100 |ddv_scf|^2 = 0.846E-02

iter # 51 total cpu time : 11020.1 secs av.it.: 2.4
thresh= 0.920E-02 alpha_mix = 0.100 |ddv_scf|^2 = 0.846E-02

iter # 52 total cpu time : 11026.2 secs av.it.: 1.0
thresh= 0.920E-02 alpha_mix = 0.100 |ddv_scf|^2 = 0.846E-02

iter # 53 total cpu time : 11035.2 secs av.it.: 3.1
thresh= 0.920E-02 alpha_mix = 0.100 |ddv_scf|^2 = 0.392E+00

iter # 54 total cpu time : 11047.0 secs av.it.: 5.1
thresh= 0.100E-01 alpha_mix = 0.100 |ddv_scf|^2 = 0.154E+02

iter # 55 total cpu time : 11061.5 secs av.it.: 7.0
thresh= 0.100E-01 alpha_mix = 0.100 |ddv_scf|^2 = 0.157E+03

iter # 56 total cpu time : 11075.8 secs av.it.: 7.1
thresh= 0.100E-01 alpha_mix = 0.100 |ddv_scf|^2 = 0.543E+01

iter # 57 total cpu time : 11087.1 secs av.it.: 4.9
thresh= 0.100E-01 alpha_mix = 0.100 |ddv_scf|^2 = 0.848E-02

iter # 58 total cpu time : 11094.0 secs av.it.: 2.0
thresh= 0.921E-02 alpha_mix = 0.100 |ddv_scf|^2 = 0.848E-02

iter # 59 total cpu time : 11104.1 secs av.it.: 4.1
thresh= 0.921E-02 alpha_mix = 0.100 |ddv_scf|^2 = 0.291E+00

iter # 60 total cpu time : 11110.3 secs av.it.: 1.1
thresh= 0.100E-01 alpha_mix = 0.100 |ddv_scf|^2 = 0.584E-01

iter # 61 total cpu time : 11117.3 secs av.it.: 2.1
thresh= 0.100E-01 alpha_mix = 0.100 |ddv_scf|^2 = 0.524E-02

iter # 62 total cpu time : 11123.8 secs av.it.: 1.7
thresh= 0.724E-02 alpha_mix = 0.100 |ddv_scf|^2 = 0.524E-02

iter # 63 total cpu time : 11130.4 secs av.it.: 2.0
thresh= 0.724E-02 alpha_mix = 0.100 |ddv_scf|^2 = 0.524E-02

iter # 64 total cpu time : 11135.5 secs av.it.: 1.0
thresh= 0.724E-02 alpha_mix = 0.100 |ddv_scf|^2 = 0.524E-02

iter # 65 total cpu time : 11140.7 secs av.it.: 1.0
thresh= 0.724E-02 alpha_mix = 0.100 |ddv_scf|^2 = 0.524E-02

iter # 66 total cpu time : 11168.5 secs av.it.: 16.4
thresh= 0.724E-02 alpha_mix = 0.100 |ddv_scf|^2 = 0.297E+07

iter # 67 total cpu time : 11196.8 secs av.it.: 16.8
thresh= 0.100E-01 alpha_mix = 0.100 |ddv_scf|^2 = 0.380E+08

iter # 68 total cpu time : 11222.5 secs av.it.: 15.3
thresh= 0.100E-01 alpha_mix = 0.100 |ddv_scf|^2 = 0.245E+08

iter # 69 total cpu time : 11250.2 secs av.it.: 16.6
thresh= 0.100E-01 alpha_mix = 0.100 |ddv_scf|^2 = 0.294E+07

iter # 70 total cpu time : 11276.4 secs av.it.: 15.3
thresh= 0.100E-01 alpha_mix = 0.100 |ddv_scf|^2 = 0.117E+05

iter # 71 total cpu time : 11298.4 secs av.it.: 12.4
thresh= 0.100E-01 alpha_mix = 0.100 |ddv_scf|^2 = 0.653E+03

iter # 72 total cpu time : 11319.4 secs av.it.: 11.7
thresh= 0.100E-01 alpha_mix = 0.100 |ddv_scf|^2 = 0.672E+03

iter # 73 total cpu time : 11342.2 secs av.it.: 13.4
thresh= 0.100E-01 alpha_mix = 0.100 |ddv_scf|^2 = 0.193E-01
kpoint 2 ibnd 81 solve_linter: root not converged 0.304E+00

iter # 74 total cpu time : 11362.9 secs av.it.: 11.7
thresh= 0.100E-01 alpha_mix = 0.100 |ddv_scf|^2 = 0.899E+02

iter # 75 total cpu time : 11382.1 secs av.it.: 9.8
thresh= 0.100E-01 alpha_mix = 0.100 |ddv_scf|^2 = 0.133E+03

iter # 76 total cpu time : 11397.7 secs av.it.: 7.9
thresh= 0.100E-01 alpha_mix = 0.100 |ddv_scf|^2 = 0.167E+03

iter # 77 total cpu time : 11417.7 secs av.it.: 11.3
thresh= 0.100E-01 alpha_mix = 0.100 |ddv_scf|^2 = 0.383E+01

iter # 78 total cpu time : 11435.0 secs av.it.: 8.8
thresh= 0.100E-01 alpha_mix = 0.100 |ddv_scf|^2 = 0.733E-03

iter # 79 total cpu time : 11455.7 secs av.it.: 11.7
thresh= 0.271E-02 alpha_mix = 0.100 |ddv_scf|^2 = 0.258E-02

iter # 80 total cpu time : 11477.5 secs av.it.: 12.6
thresh= 0.508E-02 alpha_mix = 0.100 |ddv_scf|^2 = 0.135E+00

iter # 81 total cpu time : 11491.4 secs av.it.: 6.7
thresh= 0.100E-01 alpha_mix = 0.100 |ddv_scf|^2 = 0.166E-01

iter # 82 total cpu time : 11505.2 secs av.it.: 6.8
thresh= 0.100E-01 alpha_mix = 0.100 |ddv_scf|^2 = 0.276E-03

iter # 83 total cpu time : 11521.6 secs av.it.: 8.7
thresh= 0.166E-02 alpha_mix = 0.100 |ddv_scf|^2 = 0.197E-02

iter # 84 total cpu time : 11536.2 secs av.it.: 7.2
thresh= 0.444E-02 alpha_mix = 0.100 |ddv_scf|^2 = 0.197E-02

iter # 85 total cpu time : 11554.4 secs av.it.: 9.5
thresh= 0.444E-02 alpha_mix = 0.100 |ddv_scf|^2 = 0.237E+00

iter # 86 total cpu time : 11568.3 secs av.it.: 6.7
thresh= 0.100E-01 alpha_mix = 0.100 |ddv_scf|^2 = 0.191E+00

iter # 87 total cpu time : 11582.5 secs av.it.: 6.9
thresh= 0.100E-01 alpha_mix = 0.100 |ddv_scf|^2 = 0.600E-01

iter # 88 total cpu time : 11591.9 secs av.it.: 3.7
thresh= 0.100E-01 alpha_mix = 0.100 |ddv_scf|^2 = 0.600E-01

iter # 89 total cpu time : 11604.1 secs av.it.: 5.7
thresh= 0.100E-01 alpha_mix = 0.100 |ddv_scf|^2 = 0.933E+00

iter # 90 total cpu time : 11614.2 secs av.it.: 4.1
thresh= 0.100E-01 alpha_mix = 0.100 |ddv_scf|^2 = 0.221E+01

iter # 91 total cpu time : 11623.2 secs av.it.: 3.0
thresh= 0.100E-01 alpha_mix = 0.100 |ddv_scf|^2 = 0.221E+01

iter # 92 total cpu time : 11633.0 secs av.it.: 4.1
thresh= 0.100E-01 alpha_mix = 0.100 |ddv_scf|^2 = 0.609E+00

iter # 93 total cpu time : 11643.1 secs av.it.: 4.1
thresh= 0.100E-01 alpha_mix = 0.100 |ddv_scf|^2 = 0.461E-01

iter # 94 total cpu time : 11649.2 secs av.it.: 1.0
thresh= 0.100E-01 alpha_mix = 0.100 |ddv_scf|^2 = 0.461E-01

iter # 95 total cpu time : 11658.7 secs av.it.: 4.1
thresh= 0.100E-01 alpha_mix = 0.100 |ddv_scf|^2 = 0.143E+00

iter # 96 total cpu time : 11666.1 secs av.it.: 2.2
thresh= 0.100E-01 alpha_mix = 0.100 |ddv_scf|^2 = 0.143E+00

iter # 97 total cpu time : 11673.9 secs av.it.: 3.0
thresh= 0.100E-01 alpha_mix = 0.100 |ddv_scf|^2 = 0.143E+00

iter # 98 total cpu time : 11680.4 secs av.it.: 1.7
thresh= 0.100E-01 alpha_mix = 0.100 |ddv_scf|^2 = 0.143E+00

iter # 99 total cpu time : 11686.7 secs av.it.: 1.1
thresh= 0.100E-01 alpha_mix = 0.100 |ddv_scf|^2 = 0.581E+00

iter # 100 total cpu time : 11693.7 secs av.it.: 2.1
thresh= 0.100E-01 alpha_mix = 0.100 |ddv_scf|^2 = 0.345E+00

End of self-consistent calculation

No convergence has been achieved

PHONON : 3h14m CPU time

INITIALIZATION:
phq_setup : 0.07s CPU
phq_init : 109.25s CPU

phq_init : 109.25s CPU
init_vloc : 0.19s CPU ( 2 calls, 0.095 s avg)
init_us_1 : 1.00s CPU
newd : 0.33s CPU
dvanqq : 34.72s CPU
drho : 72.56s CPU
cmpt_qdipol : 0.08s CPU ( 24 calls, 0.003 s avg)

DIELECTRIC CONSTANT AND EFFECTIVE CHARGES:
solve_e : 736.31s CPU
dielec : 0.18s CPU
zstar_eu : 772.94s CPU

DYNAMICAL MATRIX:
dynmat0 : 2.31s CPU
phqscf : 10077.15s CPU

phqscf : 10077.15s CPU
solve_linter : 9685.63s CPU ( 24 calls, 403.568 s avg)
drhodv : 27.46s CPU ( 23 calls, 1.194 s avg)
add_zstar_ue : 0.98s CPU ( 23 calls, 0.043 s avg)
add_zstar_us : 363.06s CPU ( 23 calls, 15.785 s avg)



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




From ding at sissa.it  Wed Apr 12 18:09:33 2006
From: ding at sissa.it (Xunlei Ding)
Date: Wed, 12 Apr 2006 18:09:33 +0200
Subject: [Pw_forum] Why the energies are different when two molecules are calculated
 together and separate?
Message-ID: <443D263D.9070600@sissa.it>

Dear all,
In a supercell (15A^3), I calculated the energies of one CO2 molecule, 
and a H atom, separately.
I got the energies E(CO2) and E(H). Then I calculated the system 
contained both CO2 and H in the same supercell, and get the energy E(CO2+H).
It is surprising to me that E(CO2+H) is lower than E(CO2)+E(H) by about 
more than 0.1eV.
All calculations are used PBE functional and with Gamma point.
I have put the H atom from CO2 at different places and the distances are 
tested for 6A and 9A. The cutoff are tested for 24Ry and 32Ry. The 
supercell are tested for 15A^3 and 20A^3. All these tests give the 
similar results and the energies differences are still more than 0.1eV.

Then with Gaussian03, both with PBC (period boundary conditions) and 
without PBC (just free molecules), the results show that E(CO2+H) is 
very close to E(CO2)+E(H).

It is found that the HOMO of H atom is also the HOMO of the system 
H+CO2, but in PWSCF results, HOMO of (H+CO2) is lower than that in H 
atom by ahout 0.1eV, while in Gaussian03 calculation, the HOMO is almost 
the same in H+CO2 and H . This is the reason why the total energy of 
H+CO2 is lower than E(H) + E(CO2).

I want to know the reason for this energy difference.

Thank you!

Yours sincerely,
Ding





From marzari at MIT.EDU  Wed Apr 12 18:30:46 2006
From: marzari at MIT.EDU (Nicola Marzari)
Date: Wed, 12 Apr 2006 18:30:46 +0200
Subject: [Pw_forum] Why the energies are different when two molecules
 are calculated together and separate?
In-Reply-To: <443D263D.9070600@sissa.it>
References: <443D263D.9070600@sissa.it>
Message-ID: <443D2B36.3050905@mit.edu>


My guess is that if you make your cell larger and larger the difference
will, very slowly, disappear.

You have two sources of error

1) the "covalent" interaction between CO2 and H. You do not see this
in Gaussian because of the shortcomings of the basis set there -
there are no states able to represent the weak overlap of wavefunctions
midway between the molecule and the atom.

2) the dipole of the system, that interacts with itself periodically 
repeated. See e.g. Makov Payne PRB 1995, or cond-mat/0602599 and Refs. 
[14] in it.

Let us know if 1) or 2) are to blame.

			nicola



Xunlei Ding wrote:

> Dear all,
> In a supercell (15A^3), I calculated the energies of one CO2 molecule, 
> and a H atom, separately.
> I got the energies E(CO2) and E(H). Then I calculated the system 
> contained both CO2 and H in the same supercell, and get the energy 
> E(CO2+H).
> It is surprising to me that E(CO2+H) is lower than E(CO2)+E(H) by about 
> more than 0.1eV.
> All calculations are used PBE functional and with Gamma point.
> I have put the H atom from CO2 at different places and the distances are 
> tested for 6A and 9A. The cutoff are tested for 24Ry and 32Ry. The 
> supercell are tested for 15A^3 and 20A^3. All these tests give the 
> similar results and the energies differences are still more than 0.1eV.
> 
> Then with Gaussian03, both with PBC (period boundary conditions) and 
> without PBC (just free molecules), the results show that E(CO2+H) is 
> very close to E(CO2)+E(H).
> 
> It is found that the HOMO of H atom is also the HOMO of the system 
> H+CO2, but in PWSCF results, HOMO of (H+CO2) is lower than that in H 
> atom by ahout 0.1eV, while in Gaussian03 calculation, the HOMO is almost 
> the same in H+CO2 and H . This is the reason why the total energy of 
> H+CO2 is lower than E(H) + E(CO2).
> 
> I want to know the reason for this energy difference.
> 
> Thank you!
> 
> Yours sincerely,
> Ding
> 
> 
> 
> _______________________________________________
> Pw_forum mailing list
> Pw_forum at pwscf.org
> http://www.democritos.it/mailman/listinfo/pw_forum

-- 
---------------------------------------------------------------------
Prof Nicola Marzari   Department of Materials Science and Engineering
13-5066   MIT   77 Massachusetts Avenue   Cambridge MA 02139-4307 USA
tel 617.4522758 fax 2586534 marzari at mit.edu http://quasiamore.mit.edu


From giannozz at nest.sns.it  Wed Apr 12 19:33:24 2006
From: giannozz at nest.sns.it (Paolo Giannozzi)
Date: Wed, 12 Apr 2006 19:33:24 +0200
Subject: [Pw_forum] error on phonon calculation  (root not converged)
In-Reply-To: <443C6865.8060003@ncsu.edu>
References: <20060407150924.61726.qmail@web60325.mail.yahoo.com> <200604101956.24764.giannozz@nest.sns.it> <443C6865.8060003@ncsu.edu>
Message-ID: <200604121933.24709.giannozz@nest.sns.it>

On Wednesday 12 April 2006 04:39, Liping YU wrote:

> >total energies per cell are not the same. Also eigenvalues are clearly
> >not the same. Your 2x2x1 supercell is not 4 times a 1x1x1 cell.
>
> Yes. The total energy difference between them is
> -275.21362101 *4 - (-1100.81820918) = 0.03627486 ryd
> What's the reason for this difference?

actually the reason for this difference is more subtle than I 
initially though. If you run the 1x1x1 cell with more bands, 
or with a small gaussian broadening, you will get exactly 
the same results as with the default setting for an insulator
(in fact your system has a sizable gap, ~2 eV). If you do the 
same with the 2x2x1 supercell, you find a nonnegligible 
difference between the two runs. It looks like the system 
with default options for an insulator falls into a metastable 
self-consistent solution. Then you will get very strange 
phonons and dielectric tensors.
I have never seen anything like this before.

Paolo
-- 
Paolo Giannozzi             e-mail:  giannozz at nest.sns.it
Scuola Normale Superiore    Phone:   +39/050-509876, Fax:-563513 
Piazza dei Cavalieri 7      I-56126 Pisa, Italy


From brsahu at physics.utexas.edu  Wed Apr 12 19:43:53 2006
From: brsahu at physics.utexas.edu (Bhagawan Sahu)
Date: Wed, 12 Apr 2006 12:43:53 -0500 (CDT)
Subject: [Pw_forum] SOC
Message-ID: <Pine.LNX.4.44.0604121240330.18953-100000@linux2.ph.utexas.edu>

Dear pwscf users,

  Is it true that

the  bulk spin-orbit coupling (SOC) calculation is done using a 
relativistic 
PP for the atom/ion (RRKJ scheme and Andrea Dal Carso's PRB paper) and the 
SOC effect is not included self-consistently on the valence states during 
the scf cycle?

Sahu 



From quevedin at gmail.com  Wed Apr 12 19:45:18 2006
From: quevedin at gmail.com (Lucas Fernandez Seivane)
Date: Wed, 12 Apr 2006 19:45:18 +0200
Subject: [Pw_forum] Why the energies are different when two molecules are calculated together and separate?
In-Reply-To: <443D2B36.3050905@mit.edu>
References: <443D263D.9070600@sissa.it> <443D2B36.3050905@mit.edu>
Message-ID: <2ebe300a0604121045t5a25c3cbrb2eb6d6b486d7da9@mail.gmail.com>

I believe that this is more or less the case that Prof. Marzari states
as 1). It may due to an effect well known related to localized basis
(LCAO, gaussians) which has to do with the number of wavefunctions in
each one of your simulations: the  Basis Set Superposition Error.
Quoting from http://iqc.udg.es/~perico/bbopt.html:
"The theoretical study of molecular interactions under the
supermolecular approach with finite basis sets centered at the atomic
positions originates the so-called Basis Set Superposition Error
(BSSE) Within the LCAO-MO approach, each fragment can be expanded to
some extent in the basis set of the partner. Thus, BSSE is the
unphysical effect due to the improvement of the quantum mechanical
description of the fragments within the supermolecule. It has been
recognised for long time that this effect results in an increase of
the interaction energy."

Some ideas for dealing with it are seen for instance in
http://arxiv.org/PS_cache/physics/pdf/9908/9908022.pdf or in
http://dx.doi.org/10.1103/PhysRevB.72.075431

On 4/12/06, Nicola Marzari <marzari at mit.edu> wrote:
>
>
> My guess is that if you make your cell larger and larger the difference
> will, very slowly, disappear.
>
> You have two sources of error
>
> 1) the "covalent" interaction between CO2 and H. You do not see this
> in Gaussian because of the shortcomings of the basis set there -
> there are no states able to represent the weak overlap of wavefunctions
> midway between the molecule and the atom.
>
> 2) the dipole of the system, that interacts with itself periodically
> repeated. See e.g. Makov Payne PRB 1995, or cond-mat/0602599 and Refs.
> [14] in it.
>
> Let us know if 1) or 2) are to blame.
>
>                         nicola
>
>
>
> Xunlei Ding wrote:
>
> > Dear all,
> > In a supercell (15A^3), I calculated the energies of one CO2 molecule,
> > and a H atom, separately.
> > I got the energies E(CO2) and E(H). Then I calculated the system
> > contained both CO2 and H in the same supercell, and get the energy
> > E(CO2+H).
> > It is surprising to me that E(CO2+H) is lower than E(CO2)+E(H) by about
> > more than 0.1eV.
> > All calculations are used PBE functional and with Gamma point.
> > I have put the H atom from CO2 at different places and the distances are
> > tested for 6A and 9A. The cutoff are tested for 24Ry and 32Ry. The
> > supercell are tested for 15A^3 and 20A^3. All these tests give the
> > similar results and the energies differences are still more than 0.1eV.
> >
> > Then with Gaussian03, both with PBC (period boundary conditions) and
> > without PBC (just free molecules), the results show that E(CO2+H) is
> > very close to E(CO2)+E(H).
> >
> > It is found that the HOMO of H atom is also the HOMO of the system
> > H+CO2, but in PWSCF results, HOMO of (H+CO2) is lower than that in H
> > atom by ahout 0.1eV, while in Gaussian03 calculation, the HOMO is almost
> > the same in H+CO2 and H . This is the reason why the total energy of
> > H+CO2 is lower than E(H) + E(CO2).
> >
> > I want to know the reason for this energy difference.
> >
> > Thank you!
> >
> > Yours sincerely,
> > Ding
> >
> >
> >
> > _______________________________________________
> > Pw_forum mailing list
> > Pw_forum at pwscf.org
> > http://www.democritos.it/mailman/listinfo/pw_forum
>
> --
> ---------------------------------------------------------------------
> Prof Nicola Marzari   Department of Materials Science and Engineering
> 13-5066   MIT   77 Massachusetts Avenue   Cambridge MA 02139-4307 USA
> tel 617.4522758 fax 2586534 marzari at mit.edu http://quasiamore.mit.edu
> _______________________________________________
> Pw_forum mailing list
> Pw_forum at pwscf.org
> http://www.democritos.it/mailman/listinfo/pw_forum
>


From naromero at gmail.com  Wed Apr 12 20:06:57 2006
From: naromero at gmail.com (Nichols A. Romero)
Date: Wed, 12 Apr 2006 14:06:57 -0400
Subject: [Pw_forum] Why the energies are different when two molecules are calculated together and separate?
In-Reply-To: <2ebe300a0604121045t5a25c3cbrb2eb6d6b486d7da9@mail.gmail.com>
References: <443D263D.9070600@sissa.it> <443D2B36.3050905@mit.edu>
	 <2ebe300a0604121045t5a25c3cbrb2eb6d6b486d7da9@mail.gmail.com>
Message-ID: <6ac064b60604121106r666b87cdke2268d412252da58@mail.gmail.com>

Xunlei,

I am not surprised that your two calculations:

E(CO2) and E(H) separate supercells
versus
E(CO2+H) same supercell

give different energies, even if they are well separated in a *huge* empty box.

My former adviser, Richard Martin, tells me this is *famous* DFT problem.
See,
C. Almbladh and U. von Barth, "Exact results for the charge and spin
densities, exchange-correlation potentials, and density-functional
eigenvalues," Phys. Rev. B 31:3231, 1985.

The *fundamental* problem is not with the basis set. "The general gist
is that the exact functional must be discontinuous at integer
occupations.  This shows the problems with any functional that does
not have discontinuities -  like LDA and GGA!", my former adviser. So,
I think if you have an asymptotically corrected functional, and I
don't know of any publicly available code that have this available,
you wouldn't have this problem.

I tried a similar test in SIESTA not too long ago. And even with an
LCAO basis set, you will see charge transfer in the combined systems
that is well separated in a *huge* empty box. It will be a *very*
small charge transfer but its there! Because of this small charge
transfer, there will be an energy difference between the two
calculations.

Bests,
On 4/12/06, Lucas Fernandez Seivane <quevedin at gmail.com> wrote:
> I believe that this is more or less the case that Prof. Marzari states
> as 1). It may due to an effect well known related to localized basis
> (LCAO, gaussians) which has to do with the number of wavefunctions in
> each one of your simulations: the  Basis Set Superposition Error.
> Quoting from http://iqc.udg.es/~perico/bbopt.html:
> "The theoretical study of molecular interactions under the
> supermolecular approach with finite basis sets centered at the atomic
> positions originates the so-called Basis Set Superposition Error
> (BSSE) Within the LCAO-MO approach, each fragment can be expanded to
> some extent in the basis set of the partner. Thus, BSSE is the
> unphysical effect due to the improvement of the quantum mechanical
> description of the fragments within the supermolecule. It has been
> recognised for long time that this effect results in an increase of
> the interaction energy."
>
> Some ideas for dealing with it are seen for instance in
> http://arxiv.org/PS_cache/physics/pdf/9908/9908022.pdf or in
> http://dx.doi.org/10.1103/PhysRevB.72.075431
>
> On 4/12/06, Nicola Marzari <marzari at mit.edu> wrote:
> >
> >
> > My guess is that if you make your cell larger and larger the difference
> > will, very slowly, disappear.
> >
> > You have two sources of error
> >
> > 1) the "covalent" interaction between CO2 and H. You do not see this
> > in Gaussian because of the shortcomings of the basis set there -
> > there are no states able to represent the weak overlap of wavefunctions
> > midway between the molecule and the atom.
> >
> > 2) the dipole of the system, that interacts with itself periodically
> > repeated. See e.g. Makov Payne PRB 1995, or cond-mat/0602599 and Refs.
> > [14] in it.
> >
> > Let us know if 1) or 2) are to blame.
> >
> >                         nicola
> >
> >
> >
> > Xunlei Ding wrote:
> >
> > > Dear all,
> > > In a supercell (15A^3), I calculated the energies of one CO2 molecule,
> > > and a H atom, separately.
> > > I got the energies E(CO2) and E(H). Then I calculated the system
> > > contained both CO2 and H in the same supercell, and get the energy
> > > E(CO2+H).
> > > It is surprising to me that E(CO2+H) is lower than E(CO2)+E(H) by about
> > > more than 0.1eV.
> > > All calculations are used PBE functional and with Gamma point.
> > > I have put the H atom from CO2 at different places and the distances are
> > > tested for 6A and 9A. The cutoff are tested for 24Ry and 32Ry. The
> > > supercell are tested for 15A^3 and 20A^3. All these tests give the
> > > similar results and the energies differences are still more than 0.1eV.
> > >
> > > Then with Gaussian03, both with PBC (period boundary conditions) and
> > > without PBC (just free molecules), the results show that E(CO2+H) is
> > > very close to E(CO2)+E(H).
> > >
> > > It is found that the HOMO of H atom is also the HOMO of the system
> > > H+CO2, but in PWSCF results, HOMO of (H+CO2) is lower than that in H
> > > atom by ahout 0.1eV, while in Gaussian03 calculation, the HOMO is almost
> > > the same in H+CO2 and H . This is the reason why the total energy of
> > > H+CO2 is lower than E(H) + E(CO2).
> > >
> > > I want to know the reason for this energy difference.
> > >
> > > Thank you!
> > >
> > > Yours sincerely,
> > > Ding
> > >
> > >
> > >
> > > _______________________________________________
> > > Pw_forum mailing list
> > > Pw_forum at pwscf.org
> > > http://www.democritos.it/mailman/listinfo/pw_forum
> >
> > --
> > ---------------------------------------------------------------------
> > Prof Nicola Marzari   Department of Materials Science and Engineering
> > 13-5066   MIT   77 Massachusetts Avenue   Cambridge MA 02139-4307 USA
> > tel 617.4522758 fax 2586534 marzari at mit.edu http://quasiamore.mit.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
>


--
Nichols A. Romero, Ph.D.
1613 Denise Dr. Apt. D
Forest Hill, MD 21050
443-567-8328 (C)
410-306-0709 (O)


From marzari at MIT.EDU  Wed Apr 12 20:31:41 2006
From: marzari at MIT.EDU (Nicola Marzari)
Date: Wed, 12 Apr 2006 20:31:41 +0200
Subject: [Pw_forum] Why the energies are different when two molecules
 are calculated together and separate?
In-Reply-To: <6ac064b60604121106r666b87cdke2268d412252da58@mail.gmail.com>
References: <443D263D.9070600@sissa.it> <443D2B36.3050905@mit.edu>	 <2ebe300a0604121045t5a25c3cbrb2eb6d6b486d7da9@mail.gmail.com> <6ac064b60604121106r666b87cdke2268d412252da58@mail.gmail.com>
Message-ID: <443D478D.1050301@mit.edu>


Nichols,

you make an excellent point, but then it should be seen in
Gaussian as well.

OK, enough mails for today.

			nicola


---------------------------------------------------------------------
Prof Nicola Marzari   Department of Materials Science and Engineering
13-5066   MIT   77 Massachusetts Avenue   Cambridge MA 02139-4307 USA
tel 617.4522758 fax 2586534 marzari at mit.edu http://quasiamore.mit.edu


From tangney at civet.berkeley.edu  Wed Apr 12 21:30:25 2006
From: tangney at civet.berkeley.edu (Paul Tangney)
Date: Wed, 12 Apr 2006 12:30:25 -0700
Subject: [Pw_forum] How to adjust emass,dt and cutoff in cp.x calculation?
Message-ID: <443D5551.4020402@civet.berkeley.edu>

Hi,

Nicola and Sandro give good advice and I
just want to add to Sandro's list:

5) Check the forces to make sure that they are close
to the ground state forces. If they're not, reduce emass
further until they are. The difference between
the Car-Parrinello forces and the ground state
forces is roughly proportional to emass so you only have
to check the forces once...and then reduce emass to get
your desired level of accuracy.

6) If you reduce emass by a factor of X you reduce
the errors in the forces by a factor of X but you need
to reduce the time step by roughly a factor of sqrt(X)
so that you can still accurately integrate the
equations of motion of the orbitals.


Step 5 is necessary because, in theory, Car-Parrinello
dynamics does not give you the correct forces (even on average)
except in the limit emass --> 0.
Silicon was checked many years ago and it
gave good forces and I think the assumption was made that
you could therefore get good forces for all materials with
emasses of the same order of magnitude.
This is not true, and silicon is actually a very special case
because its valence wavefunctions are unusually smooth (you
can describe them using a very low plane-wave cutoff) and so
they don't change quickly as the ions move.
For some other systems that have been tested (oxides),
emasses that have been chosen by simply using the
prescription of Pastore et al. give you horrendous
forces.

By "horrendous" I mean: forces that have average errors
(with respect to the ground state forces) with a magnitude
that is only a factor of between 3 and 20 smaller than
the (r.m.s) magnitude of the forces themselves.
These errors are 2 or 3 orders of magnitude larger than what
you would get in most Born-Oppenheimer MD simulations.
Very few tests have been published so I'm just going
by those that have.

Most people either don't know about this issue or use the
ostrich approach to computer simulation and skip step 5 but
the tests that have been published suggest that this is
a mistake.

This issue is not discussed in review papers or in Richard
Martin's book which predate the work of Sandro and I:
See P. Tangney, S. Scandolo JCP 116, 14 (2002) and
P. Tangney JCP 124, 044111 (2006). You can download them
here: http://civet.berkeley.edu/tangney/JCPs.html

You could also just use Born-Oppenheimer MD, which is
always faster for a chosen level of accuracy on the forces
or the Kohn-Sham energy.
It doesn't conserve energy as well, but the energy that
is conserved in Car-Parrinello MD is a physically meaningless
quantity anyway, so who cares?
If temperature drifts too much, attach a weak thermostat.


Regards,

Paul












What Nicola says is entirely correct, and you should pay special
attention when studying metallic systems with CP (or seriously
considering using extensions of the CP method like the ones pioneered by
Nicola and by others).

However, should you still be willing to study Na with CP as a test case,
or should you consider studying "easier" (say, nonmetallic) systems in
the future, the recipe for setting emass, emass_cutoff, and dt is
roughly as follows:

1) set emass to a physical sound value. The value of emass determines
how much the fictitiuous dynamics of the electrons couples with the real
dynamics of the ions. A small emass guarantees decoupling. How small is
small is typically determined by the excitation gap E_gap of your
system. The minimum frequency of the fictitious electronic dynamics
scales like sqrt(E_gap/emass) [see, e.g., Pastore et al, PRA 44, 6334
(1991)], and this has to be much higher than the maximum frequency of
the ion dynamics. Typically a factor of three larger is enough. As you
see, metallic systems, where E_gap=0 are a bit of a nightmare for CP,
unless the finite size of your system introduces a finite gap, but then
you have to be extra-careful...

2) start playing with emass_ecutoff, by fixing it to a starting value,
and checking what is the maximum dt that alllows you to integrate the
equations of motion. The error you got is precisely a sign that the dt
you used is too large for the integrator to converge.

3) choose the value of emass_ecutoff that allows you to use the largest dt.

4) Set dt accordingly.

Points (2-4) are described in detail in Tassone, Mauri, Car, PRB 50,
10561 (1994).

Regards,
Sandro


Ruijuan Xiao wrote:

 >Dear all,
 >I met some problems when I do some calculations by cp.x. What I 
calculated is a cubic box in which 54 Na atoms exist. When I use 
dt=5.0d0, emass=400.0d0, and emass_cutoff=3.0d0, it can run without any 
problems. When I put dt=5.0d0,emass=400.0d0, then change the value of 
emass_cutoff, the calculation also runs without problems.
 >
 >But when I put emass=400.0d0 and emass_cutoff=3.0d0,then change dt 
into 10.0d0, the following error message appears and the program stopped.
 >-----------------------------------
 >%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 >     from ortho : error #        21
 >     max number of iterations exceeded
 > 
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 >
 >     stopping ...
 >------------------------------------
 >
 >When I put dt=5.0d0 and emass_cutoff=3.0d0, but change emass into 
200.0d0, the program stopped after 12 iterations. The message is :
 >------------------------------------
 >  nfi    ekinc  temph  tempp        etot      enthal       econs 
  econt    vnhh   xnhh0    vnhp   xnhp0
 >   10 ********    0.0    0.0    41.82500    41.82500    41.82500 
146.23636  0.0000  0.0000  0.0000  0.0000
 >   11  NaN        0.0    0.0    58.16717    58.16717    58.16717  NaN 
         0.0000  0.0000  0.0000  0.0000
 >   12  NaN        0.0    0.0  NaN         NaN         NaN         NaN 
         0.0000  0.0000  0.0000  0.0000
 >
 >   MAIN:          EKINC   (thr)          DETOT   (thr)       MAXFORCE 
   (thr)
 >   MAIN:  NaN            0.1D-03 NaN            0.1D-08  0.000000D+00 
  0.1D+11
 >   MAIN: convergence achieved for system relaxation
 >
 >
 >              averaged quantities :
 >         ekinc          ekin          epot          etot     tempp
 > NaN           NaN           NaN           NaN                 0.0
 >-----------------------------------
 >It seems that the calculation is sensitive to these parameters. Since 
on the page 37 of the maunal, it says that "unless you are already 
experienced with the system you are studying or with the code internals, 
usually you need to tune some
 >input parameters, like emass, dt, and cut-offs.", so these parameters 
must be important for calculations, but now I am puzzled about how to 
adjust emass,dt and cutoff in cp calculations.Would you like to give me 
any information or any suggestion about that?
 >
 >Thank you very much.
 >
 >
 >Best regards,
 >
 >Sincerely,
 >Ruijuan Xiao
 >Institute of Physics,
 >Chinese Academy of Sciences
 >
 >
 >
 >_______________________________________________
 >Pw_forum mailing list
 >Pw_forum at pwscf.org
 >http://www.democritos.it/mailman/listinfo/pw_forum
 >
 >
 >






-- 
ooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
Dr. Paul Tangney
Theory of Nanostructured Materials Facility
The Molecular Foundry
Lawrence Berkeley National Lab.         E-mail: PTTangney at lbl.gov
1 Cyclotron Road, Bldg 66                  Phone: (510) 642-2635
Berkeley, CA 94720                         Fax :  (510) 643-9345
ooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo



From akohlmey at vitae.cmm.upenn.edu  Wed Apr 12 21:49:32 2006
From: akohlmey at vitae.cmm.upenn.edu (Axel Kohlmeyer)
Date: Wed, 12 Apr 2006 15:49:32 -0400 (EDT)
Subject: [Pw_forum] How to adjust emass,dt and cutoff in cp.x calculation?
In-Reply-To: <443D5551.4020402@civet.berkeley.edu>
Message-ID: <Pine.LNX.4.44.0604121537080.12246-100000@localhost.localdomain>

On Wed, 12 Apr 2006, Paul Tangney wrote:


hi paul (and the others).

just to add one more detail to that.

[...]

PT> Most people either don't know about this issue or use the
PT> ostrich approach to computer simulation and skip step 5 but
PT> the tests that have been published suggest that this is
PT> a mistake.

well put. 

[...]

PT> You could also just use Born-Oppenheimer MD, which is
PT> always faster for a chosen level of accuracy on the forces
PT> or the Kohn-Sham energy.
PT> It doesn't conserve energy as well, but the energy that
PT> is conserved in Car-Parrinello MD is a physically meaningless
PT> quantity anyway, so who cares?
PT> If temperature drifts too much, attach a weak thermostat.

...also it actually does not drift as much if you use 
wavefunction extrapolation with BO-MD. in my tests 4th-order
extrapolation gives not only a _very_ good guess, i.e. reduces
the number of iterations needed for convergence, but also seems
to reduce the drift in kinetic energy, _even_ if you losen the 
convergence criterion. we recently had somebody here presenting
MD studies with gaussian 03 and he was seeing the same.

regards,
   axel.

PT> 
PT> 
PT> Regards,
PT> 
PT> Paul
PT> 
PT> 
PT> 
PT> 
PT> 
PT> 
PT> 
PT> 
PT> 
PT> 
PT> 
PT> 
PT> What Nicola says is entirely correct, and you should pay special
PT> attention when studying metallic systems with CP (or seriously
PT> considering using extensions of the CP method like the ones pioneered by
PT> Nicola and by others).
PT> 
PT> However, should you still be willing to study Na with CP as a test case,
PT> or should you consider studying "easier" (say, nonmetallic) systems in
PT> the future, the recipe for setting emass, emass_cutoff, and dt is
PT> roughly as follows:
PT> 
PT> 1) set emass to a physical sound value. The value of emass determines
PT> how much the fictitiuous dynamics of the electrons couples with the real
PT> dynamics of the ions. A small emass guarantees decoupling. How small is
PT> small is typically determined by the excitation gap E_gap of your
PT> system. The minimum frequency of the fictitious electronic dynamics
PT> scales like sqrt(E_gap/emass) [see, e.g., Pastore et al, PRA 44, 6334
PT> (1991)], and this has to be much higher than the maximum frequency of
PT> the ion dynamics. Typically a factor of three larger is enough. As you
PT> see, metallic systems, where E_gap=0 are a bit of a nightmare for CP,
PT> unless the finite size of your system introduces a finite gap, but then
PT> you have to be extra-careful...
PT> 
PT> 2) start playing with emass_ecutoff, by fixing it to a starting value,
PT> and checking what is the maximum dt that alllows you to integrate the
PT> equations of motion. The error you got is precisely a sign that the dt
PT> you used is too large for the integrator to converge.
PT> 
PT> 3) choose the value of emass_ecutoff that allows you to use the largest dt.
PT> 
PT> 4) Set dt accordingly.
PT> 
PT> Points (2-4) are described in detail in Tassone, Mauri, Car, PRB 50,
PT> 10561 (1994).
PT> 
PT> Regards,
PT> Sandro
PT> 
PT> 
PT> Ruijuan Xiao wrote:
PT> 
PT>  >Dear all,
PT>  >I met some problems when I do some calculations by cp.x. What I 
PT> calculated is a cubic box in which 54 Na atoms exist. When I use 
PT> dt=5.0d0, emass=400.0d0, and emass_cutoff=3.0d0, it can run without any 
PT> problems. When I put dt=5.0d0,emass=400.0d0, then change the value of 
PT> emass_cutoff, the calculation also runs without problems.
PT>  >
PT>  >But when I put emass=400.0d0 and emass_cutoff=3.0d0,then change dt 
PT> into 10.0d0, the following error message appears and the program stopped.
PT>  >-----------------------------------
PT>  >%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
PT>  >     from ortho : error #        21
PT>  >     max number of iterations exceeded
PT>  > 
PT> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
PT>  >
PT>  >     stopping ...
PT>  >------------------------------------
PT>  >
PT>  >When I put dt=5.0d0 and emass_cutoff=3.0d0, but change emass into 
PT> 200.0d0, the program stopped after 12 iterations. The message is :
PT>  >------------------------------------
PT>  >  nfi    ekinc  temph  tempp        etot      enthal       econs 
PT>   econt    vnhh   xnhh0    vnhp   xnhp0
PT>  >   10 ********    0.0    0.0    41.82500    41.82500    41.82500 
PT> 146.23636  0.0000  0.0000  0.0000  0.0000
PT>  >   11  NaN        0.0    0.0    58.16717    58.16717    58.16717  NaN 
PT>          0.0000  0.0000  0.0000  0.0000
PT>  >   12  NaN        0.0    0.0  NaN         NaN         NaN         NaN 
PT>          0.0000  0.0000  0.0000  0.0000
PT>  >
PT>  >   MAIN:          EKINC   (thr)          DETOT   (thr)       MAXFORCE 
PT>    (thr)
PT>  >   MAIN:  NaN            0.1D-03 NaN            0.1D-08  0.000000D+00 
PT>   0.1D+11
PT>  >   MAIN: convergence achieved for system relaxation
PT>  >
PT>  >
PT>  >              averaged quantities :
PT>  >         ekinc          ekin          epot          etot     tempp
PT>  > NaN           NaN           NaN           NaN                 0.0
PT>  >-----------------------------------
PT>  >It seems that the calculation is sensitive to these parameters. Since 
PT> on the page 37 of the maunal, it says that "unless you are already 
PT> experienced with the system you are studying or with the code internals, 
PT> usually you need to tune some
PT>  >input parameters, like emass, dt, and cut-offs.", so these parameters 
PT> must be important for calculations, but now I am puzzled about how to 
PT> adjust emass,dt and cutoff in cp calculations.Would you like to give me 
PT> any information or any suggestion about that?
PT>  >
PT>  >Thank you very much.
PT>  >
PT>  >
PT>  >Best regards,
PT>  >
PT>  >Sincerely,
PT>  >Ruijuan Xiao
PT>  >Institute of Physics,
PT>  >Chinese Academy of Sciences
PT>  >
PT>  >
PT>  >
PT>  >_______________________________________________
PT>  >Pw_forum mailing list
PT>  >Pw_forum at pwscf.org
PT>  >http://www.democritos.it/mailman/listinfo/pw_forum
PT>  >
PT>  >
PT>  >
PT> 
PT> 
PT> 
PT> 
PT> 
PT> 
PT> 

-- 
=======================================================================
Axel Kohlmeyer   akohlmey at cmm.chem.upenn.edu   http://www.cmm.upenn.edu
   Center for Molecular Modeling   --   University of Pennsylvania
Department of Chemistry, 231 S.34th Street, Philadelphia, PA 19104-6323
tel: 1-215-898-1582,  fax: 1-215-573-6233,  office-tel: 1-215-898-5425
=======================================================================
If you make something idiot-proof, the universe creates a better idiot.



From giannozz at nest.sns.it  Wed Apr 12 23:08:21 2006
From: giannozz at nest.sns.it (Paolo Giannozzi)
Date: Wed, 12 Apr 2006 23:08:21 +0200
Subject: [Pw_forum] Why the energies are different when two molecules are calculated together and separate?
In-Reply-To: <2ebe300a0604121045t5a25c3cbrb2eb6d6b486d7da9@mail.gmail.com>
References: <443D263D.9070600@sissa.it> <443D2B36.3050905@mit.edu> <2ebe300a0604121045t5a25c3cbrb2eb6d6b486d7da9@mail.gmail.com>
Message-ID: <200604122308.21651.giannozz@nest.sns.it>

On Wednesday 12 April 2006 19:45, Lucas Fernandez Seivane wrote:

> I believe that this is more or less the case that Prof. Marzari states
> as 1). It may due to an effect well known related to localized basis
> (LCAO, gaussians) which has to do with the number of wavefunctions in
> each one of your simulations: the  Basis Set Superposition Error.

if you compare results obtained with the same supercell and the 
same cutoff for all calculations, the BSSE is exactly zero

Paolo
-- 
Paolo Giannozzi             e-mail:  giannozz at nest.sns.it
Scuola Normale Superiore    Phone:   +39/050-509876, Fax:-563513 
Piazza dei Cavalieri 7      I-56126 Pisa, Italy


From degironc at sissa.it  Wed Apr 12 23:59:02 2006
From: degironc at sissa.it (Stefano de Gironcoli)
Date: Wed, 12 Apr 2006 23:59:02 +0200 (CEST)
Subject: [Pw_forum] Why the energies are different when two molecules
 are calculated together and separate?
In-Reply-To: <6ac064b60604121106r666b87cdke2268d412252da58@mail.gmail.com>
References: <443D263D.9070600@sissa.it> <443D2B36.3050905@mit.edu> 
 <2ebe300a0604121045t5a25c3cbrb2eb6d6b486d7da9@mail.gmail.com>
 <6ac064b60604121106r666b87cdke2268d412252da58@mail.gmail.com>
Message-ID: <Pine.LNX.4.61.0604122323570.26326@shannon-01.sissa.it>

I think this argument is in general correct and that this effect would 
show up even more dramatically if you consider fragments that are open 
shell like E(H+F) compared with E(H)+E(F).

This effect came from the fact that the two fragments tend to align 
their chemical potential and you have some (small) charge transert.
With the *true* DFT funcional xc potentials and chemical potentials would 
have sudden jumps when crossing integer number of electrons so the
equal chemical potential condition is pinned at integer numbers but with
LDA, GGA etc this is not true and there is in general some charge 
transfer.

In the present case, however, CO2 is a closed shell molecule so its LUMO 
is well separated from the HOMO and if the Hydrogen last eigenvalue is
higher than the CO2 HOMO but lover than CO2 LUMO then charge transfer 
should not occur.

In order to clarify what is happening one could calculate projected 
density of states in the two cases and see if there is indeed some charge 
transfer between the fragments..

Also, in order to remove possible source of spurious interaction between
the fragments, one should use large ecutrho (I guess you are using USPP 
for C and O) in order to avoid the augmentation charge to have small but 
not vanishing oscillating tails all around that could "mediate" the 
interaction.

I assume you did the calculation using nspin=2 so as to allow H to be 
magnetic.

let us know what are the results of these tests.

best,
  stefano


On Wed, 12 Apr 2006, Nichols A. Romero wrote:

> Xunlei,
>
> I am not surprised that your two calculations:
>
> E(CO2) and E(H) separate supercells
> versus
> E(CO2+H) same supercell
>
> give different energies, even if they are well separated in a *huge* empty box.
>
> My former adviser, Richard Martin, tells me this is *famous* DFT problem.
> See,
> C. Almbladh and U. von Barth, "Exact results for the charge and spin
> densities, exchange-correlation potentials, and density-functional
> eigenvalues," Phys. Rev. B 31:3231, 1985.
>
> The *fundamental* problem is not with the basis set. "The general gist
> is that the exact functional must be discontinuous at integer
> occupations.  This shows the problems with any functional that does
> not have discontinuities -  like LDA and GGA!", my former adviser. So,
> I think if you have an asymptotically corrected functional, and I
> don't know of any publicly available code that have this available,
> you wouldn't have this problem.
>
> I tried a similar test in SIESTA not too long ago. And even with an
> LCAO basis set, you will see charge transfer in the combined systems
> that is well separated in a *huge* empty box. It will be a *very*
> small charge transfer but its there! Because of this small charge
> transfer, there will be an energy difference between the two
> calculations.
>
> Bests,
> On 4/12/06, Lucas Fernandez Seivane <quevedin at gmail.com> wrote:
>> I believe that this is more or less the case that Prof. Marzari states
>> as 1). It may due to an effect well known related to localized basis
>> (LCAO, gaussians) which has to do with the number of wavefunctions in
>> each one of your simulations: the  Basis Set Superposition Error.
>> Quoting from http://iqc.udg.es/~perico/bbopt.html:
>> "The theoretical study of molecular interactions under the
>> supermolecular approach with finite basis sets centered at the atomic
>> positions originates the so-called Basis Set Superposition Error
>> (BSSE) Within the LCAO-MO approach, each fragment can be expanded to
>> some extent in the basis set of the partner. Thus, BSSE is the
>> unphysical effect due to the improvement of the quantum mechanical
>> description of the fragments within the supermolecule. It has been
>> recognised for long time that this effect results in an increase of
>> the interaction energy."
>>
>> Some ideas for dealing with it are seen for instance in
>> http://arxiv.org/PS_cache/physics/pdf/9908/9908022.pdf or in
>> http://dx.doi.org/10.1103/PhysRevB.72.075431
>>
>> On 4/12/06, Nicola Marzari <marzari at mit.edu> wrote:
>>>
>>>
>>> My guess is that if you make your cell larger and larger the difference
>>> will, very slowly, disappear.
>>>
>>> You have two sources of error
>>>
>>> 1) the "covalent" interaction between CO2 and H. You do not see this
>>> in Gaussian because of the shortcomings of the basis set there -
>>> there are no states able to represent the weak overlap of wavefunctions
>>> midway between the molecule and the atom.
>>>
>>> 2) the dipole of the system, that interacts with itself periodically
>>> repeated. See e.g. Makov Payne PRB 1995, or cond-mat/0602599 and Refs.
>>> [14] in it.
>>>
>>> Let us know if 1) or 2) are to blame.
>>>
>>>                         nicola
>>>
>>>
>>>
>>> Xunlei Ding wrote:
>>>
>>>> Dear all,
>>>> In a supercell (15A^3), I calculated the energies of one CO2 molecule,
>>>> and a H atom, separately.
>>>> I got the energies E(CO2) and E(H). Then I calculated the system
>>>> contained both CO2 and H in the same supercell, and get the energy
>>>> E(CO2+H).
>>>> It is surprising to me that E(CO2+H) is lower than E(CO2)+E(H) by about
>>>> more than 0.1eV.
>>>> All calculations are used PBE functional and with Gamma point.
>>>> I have put the H atom from CO2 at different places and the distances are
>>>> tested for 6A and 9A. The cutoff are tested for 24Ry and 32Ry. The
>>>> supercell are tested for 15A^3 and 20A^3. All these tests give the
>>>> similar results and the energies differences are still more than 0.1eV.
>>>>
>>>> Then with Gaussian03, both with PBC (period boundary conditions) and
>>>> without PBC (just free molecules), the results show that E(CO2+H) is
>>>> very close to E(CO2)+E(H).
>>>>
>>>> It is found that the HOMO of H atom is also the HOMO of the system
>>>> H+CO2, but in PWSCF results, HOMO of (H+CO2) is lower than that in H
>>>> atom by ahout 0.1eV, while in Gaussian03 calculation, the HOMO is almost
>>>> the same in H+CO2 and H . This is the reason why the total energy of
>>>> H+CO2 is lower than E(H) + E(CO2).
>>>>
>>>> I want to know the reason for this energy difference.
>>>>
>>>> Thank you!
>>>>
>>>> Yours sincerely,
>>>> Ding
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Pw_forum mailing list
>>>> Pw_forum at pwscf.org
>>>> http://www.democritos.it/mailman/listinfo/pw_forum
>>>
>>> --
>>> ---------------------------------------------------------------------
>>> Prof Nicola Marzari   Department of Materials Science and Engineering
>>> 13-5066   MIT   77 Massachusetts Avenue   Cambridge MA 02139-4307 USA
>>> tel 617.4522758 fax 2586534 marzari at mit.edu http://quasiamore.mit.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
>>
>
>
> --
> Nichols A. Romero, Ph.D.
> 1613 Denise Dr. Apt. D
> Forest Hill, MD 21050
> 443-567-8328 (C)
> 410-306-0709 (O)
> _______________________________________________
> Pw_forum mailing list
> Pw_forum at pwscf.org
> http://www.democritos.it/mailman/listinfo/pw_forum
>



From rjxiao at blem.ac.cn  Thu Apr 13 05:03:11 2006
From: rjxiao at blem.ac.cn (Ruijuan Xiao)
Date: Thu, 13 Apr 2006 11:03:11 +0800
Subject: [Pw_forum] How to adjust emass,dt and cutoff in cp.x calculation?
Message-ID: <20060413025919.811F91127D0@democritos.sissa.it>

Dear Nicola,Dear Sandro,Dear Paul,and Dear Axel,

I am so happy to receive so much valuable information. Thank you so much.
The system that I want to study is metallic. It seems that I should be more careful with that. Now I decide to start from a nonmetallic system to learn the CP method following your instructions.After I understand the method more, I hope I can move to my metallic system correctly. 

The details you provide are really helpful. Thanks a lot.

Best regards,

Sincerely,
Ruijuan Xiao
Institute of Physics,
Chinese Academy of Sciences


----- Original Message -----

From: Axel Kohlmeyer <akohlmey at vitae.cmm.upenn.edu>
To?Paul Tangney <tangney at civet.berkeley.edu>
Sent?2006-04-13 03:49:32
Subject?Re: [Pw_forum] How to adjust emass,dt and cutoff in cp.x calculation?

>On Wed, 12 Apr 2006, Paul Tangney wrote:
>
>
>hi paul (and the others).
>
>just to add one more detail to that.
>
>[...]
>
>PT> Most people either don't know about this issue or use the
>PT> ostrich approach to computer simulation and skip step 5 but
>PT> the tests that have been published suggest that this is
>PT> a mistake.
>
>well put. 
>
>[...]
>
>PT> You could also just use Born-Oppenheimer MD, which is
>PT> always faster for a chosen level of accuracy on the forces
>PT> or the Kohn-Sham energy.
>PT> It doesn't conserve energy as well, but the energy that
>PT> is conserved in Car-Parrinello MD is a physically meaningless
>PT> quantity anyway, so who cares?
>PT> If temperature drifts too much, attach a weak thermostat.
>
>...also it actually does not drift as much if you use 
>wavefunction extrapolation with BO-MD. in my tests 4th-order
>extrapolation gives not only a _very_ good guess, i.e. reduces
>the number of iterations needed for convergence, but also seems
>to reduce the drift in kinetic energy, _even_ if you losen the 
>convergence criterion. we recently had somebody here presenting
>MD studies with gaussian 03 and he was seeing the same.
>
>regards,
>   axel.
>
>PT> 
>PT> 
>PT> Regards,
>PT> 
>PT> Paul
>PT> 
>PT> 
>PT> 
>PT> 
>PT> 
>PT> 
>PT> 
>PT> 
>PT> 
>PT> 
>PT> 
>PT> 
>PT> What Nicola says is entirely correct, and you should pay special
>PT> attention when studying metallic systems with CP (or seriously
>PT> considering using extensions of the CP method like the ones pioneered by
>PT> Nicola and by others).
>PT> 
>PT> However, should you still be willing to study Na with CP as a test case,
>PT> or should you consider studying "easier" (say, nonmetallic) systems in
>PT> the future, the recipe for setting emass, emass_cutoff, and dt is
>PT> roughly as follows:
>PT> 
>PT> 1) set emass to a physical sound value. The value of emass determines
>PT> how much the fictitiuous dynamics of the electrons couples with the real
>PT> dynamics of the ions. A small emass guarantees decoupling. How small is
>PT> small is typically determined by the excitation gap E_gap of your
>PT> system. The minimum frequency of the fictitious electronic dynamics
>PT> scales like sqrt(E_gap/emass) [see, e.g., Pastore et al, PRA 44, 6334
>PT> (1991)], and this has to be much higher than the maximum frequency of
>PT> the ion dynamics. Typically a factor of three larger is enough. As you
>PT> see, metallic systems, where E_gap=0 are a bit of a nightmare for CP,
>PT> unless the finite size of your system introduces a finite gap, but then
>PT> you have to be extra-careful...
>PT> 
>PT> 2) start playing with emass_ecutoff, by fixing it to a starting value,
>PT> and checking what is the maximum dt that alllows you to integrate the
>PT> equations of motion. The error you got is precisely a sign that the dt
>PT> you used is too large for the integrator to converge.
>PT> 
>PT> 3) choose the value of emass_ecutoff that allows you to use the largest dt.
>PT> 
>PT> 4) Set dt accordingly.
>PT> 
>PT> Points (2-4) are described in detail in Tassone, Mauri, Car, PRB 50,
>PT> 10561 (1994).
>PT> 
>PT> Regards,
>PT> Sandro
>PT> 
>PT> 
>PT> Ruijuan Xiao wrote:
>PT> 
>PT>  >Dear all,
>PT>  >I met some problems when I do some calculations by cp.x. What I 
>PT> calculated is a cubic box in which 54 Na atoms exist. When I use 
>PT> dt=5.0d0, emass=400.0d0, and emass_cutoff=3.0d0, it can run without any 
>PT> problems. When I put dt=5.0d0,emass=400.0d0, then change the value of 
>PT> emass_cutoff, the calculation also runs without problems.
>PT>  >
>PT>  >But when I put emass=400.0d0 and emass_cutoff=3.0d0,then change dt 
>PT> into 10.0d0, the following error message appears and the program stopped.
>PT>  >-----------------------------------
>PT>  >%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
>PT>  >     from ortho : error #        21
>PT>  >     max number of iterations exceeded
>PT>  > 
>PT> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
>PT>  >
>PT>  >     stopping ...
>PT>  >------------------------------------
>PT>  >
>PT>  >When I put dt=5.0d0 and emass_cutoff=3.0d0, but change emass into 
>PT> 200.0d0, the program stopped after 12 iterations. The message is :
>PT>  >------------------------------------
>PT>  >  nfi    ekinc  temph  tempp        etot      enthal       econs 
>PT>   econt    vnhh   xnhh0    vnhp   xnhp0
>PT>  >   10 ********    0.0    0.0    41.82500    41.82500    41.82500 
>PT> 146.23636  0.0000  0.0000  0.0000  0.0000
>PT>  >   11  NaN        0.0    0.0    58.16717    58.16717    58.16717  NaN 
>PT>          0.0000  0.0000  0.0000  0.0000
>PT>  >   12  NaN        0.0    0.0  NaN         NaN         NaN         NaN 
>PT>          0.0000  0.0000  0.0000  0.0000
>PT>  >
>PT>  >   MAIN:          EKINC   (thr)          DETOT   (thr)       MAXFORCE 
>PT>    (thr)
>PT>  >   MAIN:  NaN            0.1D-03 NaN            0.1D-08  0.000000D+00 
>PT>   0.1D+11
>PT>  >   MAIN: convergence achieved for system relaxation
>PT>  >
>PT>  >
>PT>  >              averaged quantities :
>PT>  >         ekinc          ekin          epot          etot     tempp
>PT>  > NaN           NaN           NaN           NaN                 0.0
>PT>  >-----------------------------------
>PT>  >It seems that the calculation is sensitive to these parameters. Since 
>PT> on the page 37 of the maunal, it says that "unless you are already 
>PT> experienced with the system you are studying or with the code internals, 
>PT> usually you need to tune some
>PT>  >input parameters, like emass, dt, and cut-offs.", so these parameters 
>PT> must be important for calculations, but now I am puzzled about how to 
>PT> adjust emass,dt and cutoff in cp calculations.Would you like to give me 
>PT> any information or any suggestion about that?
>PT>  >
>PT>  >Thank you very much.
>PT>  >
>PT>  >
>PT>  >Best regards,
>PT>  >
>PT>  >Sincerely,
>PT>  >Ruijuan Xiao
>PT>  >Institute of Physics,
>PT>  >Chinese Academy of Sciences
>PT>  >
>PT>  >
>PT>  >
>PT>  >_______________________________________________
>PT>  >Pw_forum mailing list
>PT>  >Pw_forum at pwscf.org
>PT>  >http://www.democritos.it/mailman/listinfo/pw_forum
>PT>  >
>PT>  >
>PT>  >
>PT> 
>PT> 
>PT> 
>PT> 
>PT> 
>PT> 
>PT> 
>
>-- 
>=======================================================================
>Axel Kohlmeyer   akohlmey at cmm.chem.upenn.edu   http://www.cmm.upenn.edu
>   Center for Molecular Modeling   --   University of Pennsylvania
>Department of Chemistry, 231 S.34th Street, Philadelphia, PA 19104-6323
>tel: 1-215-898-1582,  fax: 1-215-573-6233,  office-tel: 1-215-898-5425
>=======================================================================
>If you make something idiot-proof, the universe creates a better idiot.
>
>_______________________________________________
>Pw_forum mailing list
>Pw_forum at pwscf.org
>http://www.democritos.it/mailman/listinfo/pw_forum
>


From dalcorso at sissa.it  Thu Apr 13 09:11:32 2006
From: dalcorso at sissa.it (Andrea Dal Corso)
Date: Thu, 13 Apr 2006 09:11:32 +0200
Subject: [Pw_forum] SOC
In-Reply-To: <Pine.LNX.4.44.0604121240330.18953-100000@linux2.ph.utexas.edu>
References: <Pine.LNX.4.44.0604121240330.18953-100000@linux2.ph.utexas.edu>
Message-ID: <1144912293.4002.7.camel@dhpc-5-26.sissa.it>

Yes the SO term is only in the pseudo-potential but valence states
interact with a fully relativistic pseudo-potential at each scf cycle. 
We make an approximation because we neglect the spin-orbit coupling
outside the core radius where however the effect is expected to be
small.

Andrea


On Wed, 2006-04-12 at 12:43 -0500, Bhagawan Sahu wrote:
> Dear pwscf users,
> 
>   Is it true that
> 
> the  bulk spin-orbit coupling (SOC) calculation is done using a 
> relativistic 
> PP for the atom/ion (RRKJ scheme and Andrea Dal Carso's PRB paper) and the 
> SOC effect is not included self-consistently on the valence states during 
> the scf cycle?
> 
> Sahu 
> 
> _______________________________________________
> Pw_forum mailing list
> Pw_forum at pwscf.org
> http://www.democritos.it/mailman/listinfo/pw_forum
-- 
Andrea Dal Corso                    Tel. 0039-040-3787428
SISSA, Via Beirut 2/4               Fax. 0039-040-3787528
34014 Trieste (Italy)               e-mail: dalcorso at sissa.it



From ding at sissa.it  Thu Apr 13 10:24:26 2006
From: ding at sissa.it (Xunlei Ding)
Date: Thu, 13 Apr 2006 10:24:26 +0200
Subject: [Pw_forum] Re: Why the energies are different when two molecules are calculated
 together and separate?
Message-ID: <443E0ABA.3020907@sissa.it>

Dear All,

Thank you  for all the useful discussion.

I have tested the cutoff both for the wavefunction and ecutoff. The 
results is below.
The first line indecate the cutoff, such as 24Ry288 means ecutwfc = 
24.0, ecutrho = 288.0.
The 2-5 lines are the total energies of HCO2 (in one supercell), CO2, H, 
CO2+H (just the sum of line3 and line4).
And the 6th line is the energies between E(HCO2) and E(H)+E(CO2) in eV.

                            24Ry288    32Ry400     32Ry600    40Ry600
HCO2 (Ry)         -76.156        -76.202        -76.202        -76.205
CO2 (Ry)            -75.144        -75.188        -75.188        -75.190
H atom (Ry)          -0.998          -0.999          -0.999          -0.999
CO2+H (Ry)       -76.142        -76.187        -76.187       -76.189
delta (eV)              -0.187          -0.206          -0.205         
-0.212

It can been seen that the cutoff will influence the energy difference 
little in this case.

I also think the charge transfer may pay an inportant role for this 
problem.  So I have done projwfc.x calculation, but there is error in 
the output file,
like:
     e =   -29.29871 eV
     psi =   Inf*[#  2]+  Inf*[#  6]+  Inf*[#  8]+  Inf*[# 10]+  Inf*[# 12]+
          +******[#  1]+******[#  9]+******[# 13]+******[# 11]+******[#  7]+
          +******[#  5]+******[#  4]+******[#  3]+
The expansions for alpha wavefunction are all with Inf coefficients. So 
the charges are not provided by this calculation.

So should I calculate the differential charge density to see the charge 
transfer?

I used spin=2 calculation for HCO2 and H atom, but spin=1 for CO2.  It 
has been tested that spin=2 for CO2 will give almost the same results.

I think the input files for these calculations are worth to be checked. 
I list them below.

Thank you all!

Yours sincerely,
Ding

------------------------------For HCO2:---relax is converged in one 
step------------------------------
&control
    calculation='relax',
    restart_mode='from_scratch',
    pseudo_dir = '/scratch/cne0fm32/dxl/pseudo/',
    outdir='/scratch/cne0fm32/dxl/test' , prefix='HCO2',
    tprnfor = .true.,
    tstress = .true.
 /
 &system
    ibrav=8, celldm(1) =28.345891875, celldm(2)=1.0, celldm(3)=1.0, 
nat=4, ntyp=3,
    nspin = 2,  starting_magnetization(1)=1.0,
    ecutwfc = 24.0, ecutrho = 288.0,
    occupations='fixed'
    nelup=9, neldw=8, nelec=17
 /
 &electrons
    electron_maxstep= 200
    diagonalization=''
    conv_thr = 1.0e-6
    mixing_beta = 0.2
 /
 &ions
  ion_dynamics = 'bfgs'
 /
ATOMIC_SPECIES
 H  2.00  H.pbe-rrkjus.UPF
 C 12.00  C.pbe-rrkjus.UPF
 O 16.00  O.pbe-rrkjus.UPF
ATOMIC_POSITIONS
H        0.0000        0.4  0.00
C        0.0000        0.000000000  0.00000000
O        0.078114541   0.000000000  0.00000000
O       -0.078114541   0.000000000  0.00000000

---------------------------for CO2-----relax is converged in one 
step---------------------------
&control
    calculation='relax',
    restart_mode='from_scratch',
    pseudo_dir = '/scratch/cne0fm32/dxl/pseudo/',
    outdir='/scratch/cne0fm32/dxl/test' , prefix='CO2',
    tprnfor = .true.,
    tstress = .true.
 /
 &system
    ibrav=8, celldm(1) =28.345891875, celldm(2)=1.0, celldm(3)=1.0, 
nat=3, ntyp=2,
    nspin = 1,  starting_magnetization(1)=0.0,
    ecutwfc = 24.0, ecutrho = 288.0,
    occupations='fixed'
 /
 &electrons
    electron_maxstep= 200
    diagonalization=''
    conv_thr = 1.0e-6
    mixing_beta = 0.2

 /

 &ions
  ion_dynamics = 'bfgs'
 /

ATOMIC_SPECIES
 C 12.00  C.pbe-rrkjus.UPF
 O 16.00  O.pbe-rrkjus.UPF

ATOMIC_POSITIONS
C        0.0000        0.000000000  0.00000000
O        0.078114541   0.000000000  0.00000000
O       -0.078114541   0.000000000  0.00000000

K_POINTS (gamma)

---------------------------For H atom--------------
&control
    calculation='scf',
    restart_mode='from_scratch',
    pseudo_dir = '/sfs/sanfs/home/userinfm/cne0fm32/dxl/pseudo',
    outdir='./' , prefix='H',
    tprnfor = .true.,
    tstress = .true.
 /
 &system
    ibrav=8, celldm(1) =28.345891875, celldm(2)=1.0, celldm(3)=1.0, 
nat=1, ntyp=1,
    nspin = 2, starting_magnetization=1.0
    ecutwfc = 24.0, ecutrho = 288.0,
    occupations='fixed'
    nelup=1, neldw=0, nelec=1

 /
 &electrons
    electron_maxstep= 200
    diagonalization=''
    conv_thr = 1.0e-6
    mixing_beta = 0.2

 /

 &ions
  ion_dynamics = 'bfgs'
 /

ATOMIC_SPECIES
 H 2.00  H.pbe-rrkjus.UPF

ATOMIC_POSITIONS
H    0.0   0.000000000  0.00000000

K_POINTS (gamma)





From proffess at yandex.ru  Thu Apr 13 17:02:34 2006
From: proffess at yandex.ru (Sergey Lisenkov)
Date: Thu, 13 Apr 2006 19:02:34 +0400 (MSD)
Subject: [Pw_forum] Error in polarization calculations
Message-ID: <443E680A.000003.05003@mfront8.yandex.ru>

 Dear All,

  During Berry Phase calculations (3.0 version), I got the error:

.....
==================================================
                            POLARIZATION CALCULATION
                         !!! NOT THOROUGHLY TESTED !!!
               --------------------------------------------------


 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
     from  ylm_q : error #  12915072
      not programmed for L>
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

 I use RRKJUS pseudopotentials and one pseudo from opium. What is wrong?

   Thanks,
     Sergey


From wlyim at puccini.che.pitt.edu  Fri Apr 14 00:13:10 2006
From: wlyim at puccini.che.pitt.edu (wlyim at puccini.che.pitt.edu)
Date: Thu, 13 Apr 2006 18:13:10 -0400 (EDT)
Subject: [Pw_forum] converged to wrong magnetic state of hcp cobalt in Opteron
Message-ID: <Pine.LNX.4.44.0604131757410.21814-100000@puccini.che.pitt.edu>

Dear all,

I did a test on crystalline hcp cobalt by pwscf.2.1.4, both on Opteron
(pgf90 5.2-4, lam 7.1.1) and Origin. I found that the calculation 
converged to a wrong magnetic state in Opteron, while the calculation in 
Origin was okay.
==============================================================
Opteron result:
     the Fermi energy is    13.9304 ev

!    total energy              =  -148.81668356 ryd
     estimated scf accuracy    <        2.1E-12 ryd

     band energy sum           =    15.05020575 ryd
     one-electron contribution =     6.02718194 ryd
     hartree contribution      =    21.83280247 ryd
     xc contribution           =   -65.85608477 ryd
     ewald contribution        =  -110.85073891 ryd
     correction for metals     =     0.03015572 ryd

     total magnetization       =     3.75 Bohr mag/cell
     absolute magnetization    =     4.14 Bohr mag/cell
=======================================================
Orign result:
!    total energy              =  -148.87218353 ryd
     estimated scf accuracy    <        8.6E-13 ryd

     band energy sum           =    15.19971935 ryd
     one-electron contribution =     5.99807576 ryd
     hartree contribution      =    21.85114624 ryd
     xc contribution           =   -65.77200504 ryd
     ewald contribution        =  -110.85073891 ryd
     correction for metals     =    -0.09866157 ryd

     total magnetization       =     2.75 Bohr mag/cell
     absolute magnetization    =     3.00 Bohr mag/cell
=======================================================

I used the PBE uspp as provided in pwscf website. On the other hand, I 
have also tried the calculations on platinum, which is a closed-shell 
system, and I got essentially the same results from Opteron and Origin.

Does anyone experience a similar thing? I will be appreciated if someone 
can give a help hand.

Many thanks in advance!

I am also attaching the input file at the bottom of this meesage.

regards,
William


=================================================================
Co
Cobalt
 &control
    calculation='scf'
    restart_mode='from_scratch',
    tstress = .true.
    tprnfor = .true.
    prefix='Co',
    pseudo_dir='/scratch/wlyim/work/Co/phonon/',
    outdir='/scratch/wlyim/work/Co/phonon/',
 /
 &system    
    nbnd=22,
    ibrav=4,
    celldm(1)= 4.7377320259662183,
    celldm(3)= 1.6329931618554500
    nat=2, ntyp=1,
    ecutwfc=30.0d0,
    ecutrho=180.0d0,
    occupations='smearing',
    smearing='m-v',
    degauss=0.070d0,
    nosym=.false.,
    nspin=2
    starting_magnetization(1)=1.00
    nr1s=24,nr2s=24,nr3s=36
 /
 &electrons
    conv_thr = 1.0d-11
    mixing_beta = 0.7
 /
ATOMIC_SPECIES
 Co 58.933 Co.pbe-nd-rrkjus.UPF
ATOMIC_POSITIONS {crystal}
Co  0.33333333333333333  0.66666666666666667  0.25000000  
Co  0.66666666666666667  0.33333333333333333  0.75000000 
K_POINTS {automatic}
9 9 6 0 0 0
=======================================================




From akohlmey at vitae.cmm.upenn.edu  Fri Apr 14 01:07:12 2006
From: akohlmey at vitae.cmm.upenn.edu (Axel Kohlmeyer)
Date: Thu, 13 Apr 2006 19:07:12 -0400 (EDT)
Subject: [Pw_forum] converged to wrong magnetic state of hcp cobalt in
 Opteron
In-Reply-To: <Pine.LNX.4.44.0604131757410.21814-100000@puccini.che.pitt.edu>
Message-ID: <Pine.LNX.4.44.0604131902050.22523-100000@localhost.localdomain>

On Thu, 13 Apr 2006 wlyim at puccini.che.pitt.edu wrote:

WL> Dear all,

dear william,

please check the mailing list archives. the PGI compilers version 5.x
are _known_ to miscompile several parts of quantum espresso (and not
only that code, i know of several other DFT codes as well).
the same is true for quite few SGI compilers...
if you can, please try with the intel (EM64t) compilers on opteron
to check, whether it is still going to the wrong state. it additionally
may depend on the kind of BLAS/LAPACK library you are using. there are 
a few bugs in several of them as well.

best regards,
  axel.

WL> 
WL> I did a test on crystalline hcp cobalt by pwscf.2.1.4, both on Opteron
WL> (pgf90 5.2-4, lam 7.1.1) and Origin. I found that the calculation 
WL> converged to a wrong magnetic state in Opteron, while the calculation in 
WL> Origin was okay.

[...]

WL> I used the PBE uspp as provided in pwscf website. On the other hand, I 
WL> have also tried the calculations on platinum, which is a closed-shell 
WL> system, and I got essentially the same results from Opteron and Origin.
WL> 
WL> Does anyone experience a similar thing? I will be appreciated if someone 
WL> can give a help hand.
WL> 
WL> Many thanks in advance!
WL> 
WL> I am also attaching the input file at the bottom of this meesage.
WL> 
WL> regards,
WL> William
WL> 

[...]

-- 
=======================================================================
Axel Kohlmeyer   akohlmey at cmm.chem.upenn.edu   http://www.cmm.upenn.edu
   Center for Molecular Modeling   --   University of Pennsylvania
Department of Chemistry, 231 S.34th Street, Philadelphia, PA 19104-6323
tel: 1-215-898-1582,  fax: 1-215-573-6233,  office-tel: 1-215-898-5425
=======================================================================
If you make something idiot-proof, the universe creates a better idiot.



From wlyim at puccini.che.pitt.edu  Fri Apr 14 02:52:41 2006
From: wlyim at puccini.che.pitt.edu (wlyim at puccini.che.pitt.edu)
Date: Thu, 13 Apr 2006 20:52:41 -0400 (EDT)
Subject: [Pw_forum] converged to wrong magnetic state of hcp cobalt in
 Opteron
In-Reply-To: <Pine.LNX.4.44.0604131902050.22523-100000@localhost.localdomain>
Message-ID: <Pine.LNX.4.44.0604132031550.28189-100000@puccini.che.pitt.edu>

Dear Axel,

Thanks for your advice.

I have compiled pwscf.2.1.4 using EM64T Version 9.0 with MKL 8.0.1. Again, 
the electronic structure went to the wrong state.
==================================================
INTEL EM64T result:
!    total energy              =  -148.81668356 ryd
     estimated scf accuracy    <        2.0E-12 ryd

     band energy sum           =    15.05020564 ryd
     one-electron contribution =     6.02718174 ryd
     hartree contribution      =    21.83280277 ryd
     xc contribution           =   -65.85608487 ryd
     ewald contribution        =  -110.85073891 ryd
     correction for metals     =     0.03015572 ryd

     total magnetization       =     3.75 Bohr mag/cell
     absolute magnetization    =     4.14 Bohr mag/cell
=======================================================

It seemed to me that in this chemical system, the energy is constantly
shifted by 0.06 Ry when compared to Origin result. I pick up the first 
iteration step for comparison:
================================================
Origin:
     iteration #  1     ecut=    30.00 ryd     beta=0.70
     Davidson diagonalization (with overlap)
     ethr =  1.00E-02,  avg # of iterations =  4.2

     npt with rhoup < 0:        2, npt tot    20736,      0.01 %

     npt with rhoup < 0:        2, npt tot    20736,      0.01 %

     total cpu time spent up to now is     15.75 secs

     total energy              =  -147.96340174 ryd
     estimated scf accuracy    <     2.11694003 ryd

     total magnetization       =     5.92 Bohr mag/cell
     absolute magnetization    =     5.97 Bohr mag/cell
=================================================
Opteron(PGI) or INTEL(EM64T) result:
     iteration #  1     ecut=    30.00 ryd     beta=0.70
     Davidson diagonalization (with overlap)
     ethr =  1.00E-02,  avg # of iterations =  4.1

     npt with rhoup < 0:        2, npt tot    20736,      0.01 %

     npt with rhoup < 0:        2, npt tot    20736,      0.01 %

     total cpu time spent up to now is     30.39 secs

     total energy              =  -147.90474844 ryd
     estimated scf accuracy    <     2.13792299 ryd

     total magnetization       =     5.95 Bohr mag/cell
     absolute magnetization    =     6.00 Bohr mag/cell
======================================================

At the initial stage, I would expect that the "total energy" are quite 
similar calculated in two different platforms. However this is not the 
case. Origin's energy is about 0.06 Ry lower than that in Opteron. And 
such a difference was kept till the end. I can't imagine what reasoned for 
this. On the other hand, platinum is free of this problem.

Is it due to different fft treatments in Origin and Linux machines? Or 
code/library problem?

Many thanks in advance.

Best regards,
William

On Thu, 13 Apr 2006, Axel Kohlmeyer wrote:

> On Thu, 13 Apr 2006 wlyim at puccini.che.pitt.edu wrote:
> 
> WL> Dear all,
> 
> dear william,
> 
> please check the mailing list archives. the PGI compilers version 5.x
> are _known_ to miscompile several parts of quantum espresso (and not
> only that code, i know of several other DFT codes as well).
> the same is true for quite few SGI compilers...
> if you can, please try with the intel (EM64t) compilers on opteron
> to check, whether it is still going to the wrong state. it additionally
> may depend on the kind of BLAS/LAPACK library you are using. there are 
> a few bugs in several of them as well.
> 
> best regards,
>   axel.
> 
> WL> 
> WL> I did a test on crystalline hcp cobalt by pwscf.2.1.4, both on Opteron
> WL> (pgf90 5.2-4, lam 7.1.1) and Origin. I found that the calculation 
> WL> converged to a wrong magnetic state in Opteron, while the calculation in 
> WL> Origin was okay.
> 
> [...]
> 
> WL> I used the PBE uspp as provided in pwscf website. On the other hand, I 
> WL> have also tried the calculations on platinum, which is a closed-shell 
> WL> system, and I got essentially the same results from Opteron and Origin.
> WL> 
> WL> Does anyone experience a similar thing? I will be appreciated if someone 
> WL> can give a help hand.
> WL> 
> WL> Many thanks in advance!
> WL> 
> WL> I am also attaching the input file at the bottom of this meesage.
> WL> 
> WL> regards,
> WL> William
> WL> 
> 
> [...]
> 
> 




From konstantin_kudin at yahoo.com  Fri Apr 14 08:23:41 2006
From: konstantin_kudin at yahoo.com (Konstantin Kudin)
Date: Thu, 13 Apr 2006 23:23:41 -0700 (PDT)
Subject: [Pw_forum] converged to wrong magnetic state of hcp cobalt in Opteron
In-Reply-To: <Pine.LNX.4.44.0604132031550.28189-100000@puccini.che.pitt.edu>
Message-ID: <20060414062341.45963.qmail@web52007.mail.yahoo.com>

 Hi all,

 I'd like to point out that as long as the code converges to a proper
*local* minimum, all is OK. One cannot really expect that the code is
going to find the *global* minimum in a system where there are many
accessible low energy minima. The way things are implemented is to find
*a* minimum, not *the* minimum! Note that finding *the* minimum is a
quite tricky issue, and not a solved one.

 Different platforms (compilers/architectures) might have different
initial random wavefunctions, leading to different local minima. Is
that a sign of a problem? - Not at all!

 Until things improve, making sure that the electronic state obtained
is lowest in energy (i.e. the global minimum) is the operator's
responsibility.

 Kostya


--- wlyim at puccini.che.pitt.edu wrote:

> Dear Axel,
> 
> Thanks for your advice.
> 
> I have compiled pwscf.2.1.4 using EM64T Version 9.0 with MKL 8.0.1.
> Again, 
> the electronic structure went to the wrong state.
> ==================================================
> INTEL EM64T result:
> !    total energy              =  -148.81668356 ryd
>      estimated scf accuracy    <        2.0E-12 ryd
> 
>      band energy sum           =    15.05020564 ryd
>      one-electron contribution =     6.02718174 ryd
>      hartree contribution      =    21.83280277 ryd
>      xc contribution           =   -65.85608487 ryd
>      ewald contribution        =  -110.85073891 ryd
>      correction for metals     =     0.03015572 ryd
> 
>      total magnetization       =     3.75 Bohr mag/cell
>      absolute magnetization    =     4.14 Bohr mag/cell
> =======================================================
> 
> It seemed to me that in this chemical system, the energy is
> constantly
> shifted by 0.06 Ry when compared to Origin result. I pick up the
> first 
> iteration step for comparison:
> ================================================
> Origin:
>      iteration #  1     ecut=    30.00 ryd     beta=0.70
>      Davidson diagonalization (with overlap)
>      ethr =  1.00E-02,  avg # of iterations =  4.2
> 
>      npt with rhoup < 0:        2, npt tot    20736,      0.01 %
> 
>      npt with rhoup < 0:        2, npt tot    20736,      0.01 %
> 
>      total cpu time spent up to now is     15.75 secs
> 
>      total energy              =  -147.96340174 ryd
>      estimated scf accuracy    <     2.11694003 ryd
> 
>      total magnetization       =     5.92 Bohr mag/cell
>      absolute magnetization    =     5.97 Bohr mag/cell
> =================================================
> Opteron(PGI) or INTEL(EM64T) result:
>      iteration #  1     ecut=    30.00 ryd     beta=0.70
>      Davidson diagonalization (with overlap)
>      ethr =  1.00E-02,  avg # of iterations =  4.1
> 
>      npt with rhoup < 0:        2, npt tot    20736,      0.01 %
> 
>      npt with rhoup < 0:        2, npt tot    20736,      0.01 %
> 
>      total cpu time spent up to now is     30.39 secs
> 
>      total energy              =  -147.90474844 ryd
>      estimated scf accuracy    <     2.13792299 ryd
> 
>      total magnetization       =     5.95 Bohr mag/cell
>      absolute magnetization    =     6.00 Bohr mag/cell
> ======================================================
> 
> At the initial stage, I would expect that the "total energy" are
> quite 
> similar calculated in two different platforms. However this is not
> the 
> case. Origin's energy is about 0.06 Ry lower than that in Opteron.
> And 
> such a difference was kept till the end. I can't imagine what
> reasoned for 
> this. On the other hand, platinum is free of this problem.
> 
> Is it due to different fft treatments in Origin and Linux machines?
> Or 
> code/library problem?
> 
> Many thanks in advance.
> 
> Best regards,
> William
> 
> On Thu, 13 Apr 2006, Axel Kohlmeyer wrote:
> 
> > On Thu, 13 Apr 2006 wlyim at puccini.che.pitt.edu wrote:
> > 
> > WL> Dear all,
> > 
> > dear william,
> > 
> > please check the mailing list archives. the PGI compilers version
> 5.x
> > are _known_ to miscompile several parts of quantum espresso (and
> not
> > only that code, i know of several other DFT codes as well).
> > the same is true for quite few SGI compilers...
> > if you can, please try with the intel (EM64t) compilers on opteron
> > to check, whether it is still going to the wrong state. it
> additionally
> > may depend on the kind of BLAS/LAPACK library you are using. there
> are 
> > a few bugs in several of them as well.
> > 
> > best regards,
> >   axel.
> > 
> > WL> 
> > WL> I did a test on crystalline hcp cobalt by pwscf.2.1.4, both on
> Opteron
> > WL> (pgf90 5.2-4, lam 7.1.1) and Origin. I found that the
> calculation 
> > WL> converged to a wrong magnetic state in Opteron, while the
> calculation in 
> > WL> Origin was okay.
> > 
> > [...]
> > 
> > WL> I used the PBE uspp as provided in pwscf website. On the other
> hand, I 
> > WL> have also tried the calculations on platinum, which is a
> closed-shell 
> > WL> system, and I got essentially the same results from Opteron and
> Origin.
> > WL> 
> > WL> Does anyone experience a similar thing? I will be appreciated
> if someone 
> > WL> can give a help hand.
> > WL> 
> > WL> Many thanks in advance!
> > WL> 
> > WL> I am also attaching the input file at the bottom of this
> meesage.
> > WL> 
> > WL> regards,
> > WL> William
> > WL> 
> > 
> > [...]
> > 
> > 
> 
> 
> _______________________________________________
> Pw_forum mailing list
> Pw_forum at pwscf.org
> http://www.democritos.it/mailman/listinfo/pw_forum
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


From wlyim at puccini.che.pitt.edu  Fri Apr 14 09:23:11 2006
From: wlyim at puccini.che.pitt.edu (wlyim at puccini.che.pitt.edu)
Date: Fri, 14 Apr 2006 03:23:11 -0400 (EDT)
Subject: [Pw_forum] converged to wrong magnetic state of hcp cobalt in
 Opteron
In-Reply-To: <20060414062341.45963.qmail@web52007.mail.yahoo.com>
Message-ID: <Pine.LNX.4.44.0604140312010.3349-100000@puccini.che.pitt.edu>

Hi all,

I don't think different machine will generate very different initial 
wavefunction. For platinum, the energy in the first iteration step are the 
same from Origin and Opteron. As stated in my second post, the energies 
are different for cobalt. I think the "global minimum" issue cannot 
explain all these evidences. I wanna know any fundamental difference 
between Origin and Opteron (compiler, fft and math librarys) would cause 
this. One can get the input in my first post to test it on Opteron. I will 
be appreciated if anyone can tell what I did wrongly.

Many thanks in advance.

Best regards,
William

On Thu, 13 Apr 2006, Konstantin Kudin wrote:

>  Hi all,
> 
>  I'd like to point out that as long as the code converges to a proper
> *local* minimum, all is OK. One cannot really expect that the code is
> going to find the *global* minimum in a system where there are many
> accessible low energy minima. The way things are implemented is to find
> *a* minimum, not *the* minimum! Note that finding *the* minimum is a
> quite tricky issue, and not a solved one.
> 
>  Different platforms (compilers/architectures) might have different
> initial random wavefunctions, leading to different local minima. Is
> that a sign of a problem? - Not at all!
> 
>  Until things improve, making sure that the electronic state obtained
> is lowest in energy (i.e. the global minimum) is the operator's
> responsibility.
> 
>  Kostya
> 
> 
> --- wlyim at puccini.che.pitt.edu wrote:
> 
> > Dear Axel,
> > 
> > Thanks for your advice.
> > 
> > I have compiled pwscf.2.1.4 using EM64T Version 9.0 with MKL 8.0.1.
> > Again, 
> > the electronic structure went to the wrong state.
> > ==================================================
> > INTEL EM64T result:
> > !    total energy              =  -148.81668356 ryd
> >      estimated scf accuracy    <        2.0E-12 ryd
> > 
> >      band energy sum           =    15.05020564 ryd
> >      one-electron contribution =     6.02718174 ryd
> >      hartree contribution      =    21.83280277 ryd
> >      xc contribution           =   -65.85608487 ryd
> >      ewald contribution        =  -110.85073891 ryd
> >      correction for metals     =     0.03015572 ryd
> > 
> >      total magnetization       =     3.75 Bohr mag/cell
> >      absolute magnetization    =     4.14 Bohr mag/cell
> > =======================================================
> > 
> > It seemed to me that in this chemical system, the energy is
> > constantly
> > shifted by 0.06 Ry when compared to Origin result. I pick up the
> > first 
> > iteration step for comparison:
> > ================================================
> > Origin:
> >      iteration #  1     ecut=    30.00 ryd     beta=0.70
> >      Davidson diagonalization (with overlap)
> >      ethr =  1.00E-02,  avg # of iterations =  4.2
> > 
> >      npt with rhoup < 0:        2, npt tot    20736,      0.01 %
> > 
> >      npt with rhoup < 0:        2, npt tot    20736,      0.01 %
> > 
> >      total cpu time spent up to now is     15.75 secs
> > 
> >      total energy              =  -147.96340174 ryd
> >      estimated scf accuracy    <     2.11694003 ryd
> > 
> >      total magnetization       =     5.92 Bohr mag/cell
> >      absolute magnetization    =     5.97 Bohr mag/cell
> > =================================================
> > Opteron(PGI) or INTEL(EM64T) result:
> >      iteration #  1     ecut=    30.00 ryd     beta=0.70
> >      Davidson diagonalization (with overlap)
> >      ethr =  1.00E-02,  avg # of iterations =  4.1
> > 
> >      npt with rhoup < 0:        2, npt tot    20736,      0.01 %
> > 
> >      npt with rhoup < 0:        2, npt tot    20736,      0.01 %
> > 
> >      total cpu time spent up to now is     30.39 secs
> > 
> >      total energy              =  -147.90474844 ryd
> >      estimated scf accuracy    <     2.13792299 ryd
> > 
> >      total magnetization       =     5.95 Bohr mag/cell
> >      absolute magnetization    =     6.00 Bohr mag/cell
> > ======================================================
> > 
> > At the initial stage, I would expect that the "total energy" are
> > quite 
> > similar calculated in two different platforms. However this is not
> > the 
> > case. Origin's energy is about 0.06 Ry lower than that in Opteron.
> > And 
> > such a difference was kept till the end. I can't imagine what
> > reasoned for 
> > this. On the other hand, platinum is free of this problem.
> > 
> > Is it due to different fft treatments in Origin and Linux machines?
> > Or 
> > code/library problem?
> > 
> > Many thanks in advance.
> > 
> > Best regards,
> > William
> > 
> > On Thu, 13 Apr 2006, Axel Kohlmeyer wrote:
> > 
> > > On Thu, 13 Apr 2006 wlyim at puccini.che.pitt.edu wrote:
> > > 
> > > WL> Dear all,
> > > 
> > > dear william,
> > > 
> > > please check the mailing list archives. the PGI compilers version
> > 5.x
> > > are _known_ to miscompile several parts of quantum espresso (and
> > not
> > > only that code, i know of several other DFT codes as well).
> > > the same is true for quite few SGI compilers...
> > > if you can, please try with the intel (EM64t) compilers on opteron
> > > to check, whether it is still going to the wrong state. it
> > additionally
> > > may depend on the kind of BLAS/LAPACK library you are using. there
> > are 
> > > a few bugs in several of them as well.
> > > 
> > > best regards,
> > >   axel.
> > > 
> > > WL> 
> > > WL> I did a test on crystalline hcp cobalt by pwscf.2.1.4, both on
> > Opteron
> > > WL> (pgf90 5.2-4, lam 7.1.1) and Origin. I found that the
> > calculation 
> > > WL> converged to a wrong magnetic state in Opteron, while the
> > calculation in 
> > > WL> Origin was okay.
> > > 
> > > [...]
> > > 
> > > WL> I used the PBE uspp as provided in pwscf website. On the other
> > hand, I 
> > > WL> have also tried the calculations on platinum, which is a
> > closed-shell 
> > > WL> system, and I got essentially the same results from Opteron and
> > Origin.
> > > WL> 
> > > WL> Does anyone experience a similar thing? I will be appreciated
> > if someone 
> > > WL> can give a help hand.
> > > WL> 
> > > WL> Many thanks in advance!
> > > WL> 
> > > WL> I am also attaching the input file at the bottom of this
> > meesage.
> > > WL> 
> > > WL> regards,
> > > WL> William
> > > WL> 
> > > 
> > > [...]
> > > 
> > > 
> > 
> > 
> > _______________________________________________
> > Pw_forum mailing list
> > Pw_forum at pwscf.org
> > http://www.democritos.it/mailman/listinfo/pw_forum
> > 
> 
> 
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around 
> http://mail.yahoo.com 
> _______________________________________________
> Pw_forum mailing list
> Pw_forum at pwscf.org
> http://www.democritos.it/mailman/listinfo/pw_forum
> 




From wlyim at puccini.che.pitt.edu  Fri Apr 14 10:50:39 2006
From: wlyim at puccini.che.pitt.edu (wlyim at puccini.che.pitt.edu)
Date: Fri, 14 Apr 2006 04:50:39 -0400 (EDT)
Subject: [Pw_forum] converged to wrong magnetic state of hcp cobalt in
 Opteron
In-Reply-To: <20060414062341.45963.qmail@web52007.mail.yahoo.com>
Message-ID: <Pine.LNX.4.44.0604140438011.3349-100000@puccini.che.pitt.edu>

Dear Kostya and Axel,

Thanks for all  valuable discussions.

Eventually I figured out that it was not the platform problem, but the 
smearing parameter. Cold smearing was supposed to give reasonable result 
at larger smearing value. It was true for Pt, Pd, Ni those I have tested. 
However, it is not true for cobalt. After I changed smearing parameter to 
0.007 Ryd, Opteron and Origin gave almost the same results.
================================================
Opteron:
!    total energy              =  -148.83154364 ryd
     estimated scf accuracy    <        2.6E-12 ryd

     band energy sum           =    15.10288935 ryd
     one-electron contribution =     5.98708540 ryd
     hartree contribution      =    21.83747050 ryd
     xc contribution           =   -65.80523901 ryd
     ewald contribution        =  -110.85073891 ryd
     correction for metals     =    -0.00012162 ryd

     total magnetization       =     3.15 Bohr mag/cell
     absolute magnetization    =     3.56 Bohr mag/cell
=================================================
Origin:
!    total energy              =  -148.83189344 ryd
     estimated scf accuracy    <        1.0E-12 ryd

     band energy sum           =    15.10215635 ryd
     one-electron contribution =     5.98854047 ryd
     hartree contribution      =    21.83686466 ryd
     xc contribution           =   -65.80577746 ryd
     ewald contribution        =  -110.85073891 ryd
     correction for metals     =    -0.00078219 ryd

     total magnetization       =     3.16 Bohr mag/cell
     absolute magnetization    =     3.57 Bohr mag/cell
=======================================================

It seems to me that the term "correction for metals" is a very important 
parameter to be checked...

Thanks again.

Best regards,
William

On Thu, 13 Apr 2006, Konstantin Kudin wrote:

>  Hi all,
> 
>  I'd like to point out that as long as the code converges to a proper
> *local* minimum, all is OK. One cannot really expect that the code is
> going to find the *global* minimum in a system where there are many
> accessible low energy minima. The way things are implemented is to find
> *a* minimum, not *the* minimum! Note that finding *the* minimum is a
> quite tricky issue, and not a solved one.
> 
>  Different platforms (compilers/architectures) might have different
> initial random wavefunctions, leading to different local minima. Is
> that a sign of a problem? - Not at all!
> 
>  Until things improve, making sure that the electronic state obtained
> is lowest in energy (i.e. the global minimum) is the operator's
> responsibility.
> 
>  Kostya
> 
> 
> --- wlyim at puccini.che.pitt.edu wrote:
> 
> > Dear Axel,
> > 
> > Thanks for your advice.
> > 
> > I have compiled pwscf.2.1.4 using EM64T Version 9.0 with MKL 8.0.1.
> > Again, 
> > the electronic structure went to the wrong state.
> > ==================================================
> > INTEL EM64T result:
> > !    total energy              =  -148.81668356 ryd
> >      estimated scf accuracy    <        2.0E-12 ryd
> > 
> >      band energy sum           =    15.05020564 ryd
> >      one-electron contribution =     6.02718174 ryd
> >      hartree contribution      =    21.83280277 ryd
> >      xc contribution           =   -65.85608487 ryd
> >      ewald contribution        =  -110.85073891 ryd
> >      correction for metals     =     0.03015572 ryd
> > 
> >      total magnetization       =     3.75 Bohr mag/cell
> >      absolute magnetization    =     4.14 Bohr mag/cell
> > =======================================================
> > 
> > It seemed to me that in this chemical system, the energy is
> > constantly
> > shifted by 0.06 Ry when compared to Origin result. I pick up the
> > first 
> > iteration step for comparison:
> > ================================================
> > Origin:
> >      iteration #  1     ecut=    30.00 ryd     beta=0.70
> >      Davidson diagonalization (with overlap)
> >      ethr =  1.00E-02,  avg # of iterations =  4.2
> > 
> >      npt with rhoup < 0:        2, npt tot    20736,      0.01 %
> > 
> >      npt with rhoup < 0:        2, npt tot    20736,      0.01 %
> > 
> >      total cpu time spent up to now is     15.75 secs
> > 
> >      total energy              =  -147.96340174 ryd
> >      estimated scf accuracy    <     2.11694003 ryd
> > 
> >      total magnetization       =     5.92 Bohr mag/cell
> >      absolute magnetization    =     5.97 Bohr mag/cell
> > =================================================
> > Opteron(PGI) or INTEL(EM64T) result:
> >      iteration #  1     ecut=    30.00 ryd     beta=0.70
> >      Davidson diagonalization (with overlap)
> >      ethr =  1.00E-02,  avg # of iterations =  4.1
> > 
> >      npt with rhoup < 0:        2, npt tot    20736,      0.01 %
> > 
> >      npt with rhoup < 0:        2, npt tot    20736,      0.01 %
> > 
> >      total cpu time spent up to now is     30.39 secs
> > 
> >      total energy              =  -147.90474844 ryd
> >      estimated scf accuracy    <     2.13792299 ryd
> > 
> >      total magnetization       =     5.95 Bohr mag/cell
> >      absolute magnetization    =     6.00 Bohr mag/cell
> > ======================================================
> > 
> > At the initial stage, I would expect that the "total energy" are
> > quite 
> > similar calculated in two different platforms. However this is not
> > the 
> > case. Origin's energy is about 0.06 Ry lower than that in Opteron.
> > And 
> > such a difference was kept till the end. I can't imagine what
> > reasoned for 
> > this. On the other hand, platinum is free of this problem.
> > 
> > Is it due to different fft treatments in Origin and Linux machines?
> > Or 
> > code/library problem?
> > 
> > Many thanks in advance.
> > 
> > Best regards,
> > William
> > 
> > On Thu, 13 Apr 2006, Axel Kohlmeyer wrote:
> > 
> > > On Thu, 13 Apr 2006 wlyim at puccini.che.pitt.edu wrote:
> > > 
> > > WL> Dear all,
> > > 
> > > dear william,
> > > 
> > > please check the mailing list archives. the PGI compilers version
> > 5.x
> > > are _known_ to miscompile several parts of quantum espresso (and
> > not
> > > only that code, i know of several other DFT codes as well).
> > > the same is true for quite few SGI compilers...
> > > if you can, please try with the intel (EM64t) compilers on opteron
> > > to check, whether it is still going to the wrong state. it
> > additionally
> > > may depend on the kind of BLAS/LAPACK library you are using. there
> > are 
> > > a few bugs in several of them as well.
> > > 
> > > best regards,
> > >   axel.
> > > 
> > > WL> 
> > > WL> I did a test on crystalline hcp cobalt by pwscf.2.1.4, both on
> > Opteron
> > > WL> (pgf90 5.2-4, lam 7.1.1) and Origin. I found that the
> > calculation 
> > > WL> converged to a wrong magnetic state in Opteron, while the
> > calculation in 
> > > WL> Origin was okay.
> > > 
> > > [...]
> > > 
> > > WL> I used the PBE uspp as provided in pwscf website. On the other
> > hand, I 
> > > WL> have also tried the calculations on platinum, which is a
> > closed-shell 
> > > WL> system, and I got essentially the same results from Opteron and
> > Origin.
> > > WL> 
> > > WL> Does anyone experience a similar thing? I will be appreciated
> > if someone 
> > > WL> can give a help hand.
> > > WL> 
> > > WL> Many thanks in advance!
> > > WL> 
> > > WL> I am also attaching the input file at the bottom of this
> > meesage.
> > > WL> 
> > > WL> regards,
> > > WL> William
> > > WL> 
> > > 
> > > [...]
> > > 
> > > 
> > 
> > 
> > _______________________________________________
> > Pw_forum mailing list
> > Pw_forum at pwscf.org
> > http://www.democritos.it/mailman/listinfo/pw_forum
> > 
> 
> 
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around 
> http://mail.yahoo.com 
> _______________________________________________
> Pw_forum mailing list
> Pw_forum at pwscf.org
> http://www.democritos.it/mailman/listinfo/pw_forum
> 




From marzari at MIT.EDU  Fri Apr 14 10:58:50 2006
From: marzari at MIT.EDU (Nicola Marzari)
Date: Fri, 14 Apr 2006 10:58:50 +0200
Subject: [Pw_forum] converged to wrong magnetic state of hcp cobalt in
 Opteron
In-Reply-To: <Pine.LNX.4.44.0604140438011.3349-100000@puccini.che.pitt.edu>
References: <Pine.LNX.4.44.0604140438011.3349-100000@puccini.che.pitt.edu>
Message-ID: <443F644A.8010903@mit.edu>

Dear William,

I haven't really followed the discussion, but

1) the amount of smearing you use is always an important
parameter to asses, and it is strictly linked to the
number of k-points you use (i.e. for very small smearings,
in a metal, you need to use a lot of k-points. That's the
whole point - increasing the smearing can get you to a more
accurate result, if you know what you are doing).

2) if you are using the same smearing, and same input,
on two different machines, and you get two different results,
there maybe some good reasons (two different physical minima, reached
through different initizializations of wavefunctions; or
one machine is broken; or...), but the fact that the smearing is
finite is not one of the reasons, strictly speaking. The potential
energy surface of the system, if the machines work properly,
should be the same", with one or many minima. The minimum in
which you end up will depend on where you start, and how you proceed,
that can have an amount of randomness, or numerical noise.


			nicola


wlyim at puccini.che.pitt.edu wrote:
> Dear Kostya and Axel,
> 
> Thanks for all  valuable discussions.
> 
> Eventually I figured out that it was not the platform problem, but the 
> smearing parameter. Cold smearing was supposed to give reasonable result 
> at larger smearing value. It was true for Pt, Pd, Ni those I have tested. 
> However, it is not true for cobalt. After I changed smearing parameter to 
> 0.007 Ryd, Opteron and Origin gave almost the same results.
> ================================================
> Opteron:
> !    total energy              =  -148.83154364 ryd
>      estimated scf accuracy    <        2.6E-12 ryd
> 
>      band energy sum           =    15.10288935 ryd
>      one-electron contribution =     5.98708540 ryd
>      hartree contribution      =    21.83747050 ryd
>      xc contribution           =   -65.80523901 ryd
>      ewald contribution        =  -110.85073891 ryd
>      correction for metals     =    -0.00012162 ryd
> 
>      total magnetization       =     3.15 Bohr mag/cell
>      absolute magnetization    =     3.56 Bohr mag/cell
> =================================================
> Origin:
> !    total energy              =  -148.83189344 ryd
>      estimated scf accuracy    <        1.0E-12 ryd
> 
>      band energy sum           =    15.10215635 ryd
>      one-electron contribution =     5.98854047 ryd
>      hartree contribution      =    21.83686466 ryd
>      xc contribution           =   -65.80577746 ryd
>      ewald contribution        =  -110.85073891 ryd
>      correction for metals     =    -0.00078219 ryd
> 
>      total magnetization       =     3.16 Bohr mag/cell
>      absolute magnetization    =     3.57 Bohr mag/cell
> =======================================================
> 
> It seems to me that the term "correction for metals" is a very important 
> parameter to be checked...
> 
> Thanks again.
> 
> Best regards,
> William
> 
> On Thu, 13 Apr 2006, Konstantin Kudin wrote:
> 
> 
>> Hi all,
>>
>> I'd like to point out that as long as the code converges to a proper
>>*local* minimum, all is OK. One cannot really expect that the code is
>>going to find the *global* minimum in a system where there are many
>>accessible low energy minima. The way things are implemented is to find
>>*a* minimum, not *the* minimum! Note that finding *the* minimum is a
>>quite tricky issue, and not a solved one.
>>
>> Different platforms (compilers/architectures) might have different
>>initial random wavefunctions, leading to different local minima. Is
>>that a sign of a problem? - Not at all!
>>
>> Until things improve, making sure that the electronic state obtained
>>is lowest in energy (i.e. the global minimum) is the operator's
>>responsibility.
>>
>> Kostya
>>
>>
>>--- wlyim at puccini.che.pitt.edu wrote:
>>
>>
>>>Dear Axel,
>>>
>>>Thanks for your advice.
>>>
>>>I have compiled pwscf.2.1.4 using EM64T Version 9.0 with MKL 8.0.1.
>>>Again, 
>>>the electronic structure went to the wrong state.
>>>==================================================
>>>INTEL EM64T result:
>>>!    total energy              =  -148.81668356 ryd
>>>     estimated scf accuracy    <        2.0E-12 ryd
>>>
>>>     band energy sum           =    15.05020564 ryd
>>>     one-electron contribution =     6.02718174 ryd
>>>     hartree contribution      =    21.83280277 ryd
>>>     xc contribution           =   -65.85608487 ryd
>>>     ewald contribution        =  -110.85073891 ryd
>>>     correction for metals     =     0.03015572 ryd
>>>
>>>     total magnetization       =     3.75 Bohr mag/cell
>>>     absolute magnetization    =     4.14 Bohr mag/cell
>>>=======================================================
>>>
>>>It seemed to me that in this chemical system, the energy is
>>>constantly
>>>shifted by 0.06 Ry when compared to Origin result. I pick up the
>>>first 
>>>iteration step for comparison:
>>>================================================
>>>Origin:
>>>     iteration #  1     ecut=    30.00 ryd     beta=0.70
>>>     Davidson diagonalization (with overlap)
>>>     ethr =  1.00E-02,  avg # of iterations =  4.2
>>>
>>>     npt with rhoup < 0:        2, npt tot    20736,      0.01 %
>>>
>>>     npt with rhoup < 0:        2, npt tot    20736,      0.01 %
>>>
>>>     total cpu time spent up to now is     15.75 secs
>>>
>>>     total energy              =  -147.96340174 ryd
>>>     estimated scf accuracy    <     2.11694003 ryd
>>>
>>>     total magnetization       =     5.92 Bohr mag/cell
>>>     absolute magnetization    =     5.97 Bohr mag/cell
>>>=================================================
>>>Opteron(PGI) or INTEL(EM64T) result:
>>>     iteration #  1     ecut=    30.00 ryd     beta=0.70
>>>     Davidson diagonalization (with overlap)
>>>     ethr =  1.00E-02,  avg # of iterations =  4.1
>>>
>>>     npt with rhoup < 0:        2, npt tot    20736,      0.01 %
>>>
>>>     npt with rhoup < 0:        2, npt tot    20736,      0.01 %
>>>
>>>     total cpu time spent up to now is     30.39 secs
>>>
>>>     total energy              =  -147.90474844 ryd
>>>     estimated scf accuracy    <     2.13792299 ryd
>>>
>>>     total magnetization       =     5.95 Bohr mag/cell
>>>     absolute magnetization    =     6.00 Bohr mag/cell
>>>======================================================
>>>
>>>At the initial stage, I would expect that the "total energy" are
>>>quite 
>>>similar calculated in two different platforms. However this is not
>>>the 
>>>case. Origin's energy is about 0.06 Ry lower than that in Opteron.
>>>And 
>>>such a difference was kept till the end. I can't imagine what
>>>reasoned for 
>>>this. On the other hand, platinum is free of this problem.
>>>
>>>Is it due to different fft treatments in Origin and Linux machines?
>>>Or 
>>>code/library problem?
>>>
>>>Many thanks in advance.
>>>
>>>Best regards,
>>>William
>>>
>>>On Thu, 13 Apr 2006, Axel Kohlmeyer wrote:
>>>
>>>
>>>>On Thu, 13 Apr 2006 wlyim at puccini.che.pitt.edu wrote:
>>>>
>>>>WL> Dear all,
>>>>
>>>>dear william,
>>>>
>>>>please check the mailing list archives. the PGI compilers version
>>>
>>>5.x
>>>
>>>>are _known_ to miscompile several parts of quantum espresso (and
>>>
>>>not
>>>
>>>>only that code, i know of several other DFT codes as well).
>>>>the same is true for quite few SGI compilers...
>>>>if you can, please try with the intel (EM64t) compilers on opteron
>>>>to check, whether it is still going to the wrong state. it
>>>
>>>additionally
>>>
>>>>may depend on the kind of BLAS/LAPACK library you are using. there
>>>
>>>are 
>>>
>>>>a few bugs in several of them as well.
>>>>
>>>>best regards,
>>>>  axel.
>>>>
>>>>WL> 
>>>>WL> I did a test on crystalline hcp cobalt by pwscf.2.1.4, both on
>>>
>>>Opteron
>>>
>>>>WL> (pgf90 5.2-4, lam 7.1.1) and Origin. I found that the
>>>
>>>calculation 
>>>
>>>>WL> converged to a wrong magnetic state in Opteron, while the
>>>
>>>calculation in 
>>>
>>>>WL> Origin was okay.
>>>>
>>>>[...]
>>>>
>>>>WL> I used the PBE uspp as provided in pwscf website. On the other
>>>
>>>hand, I 
>>>
>>>>WL> have also tried the calculations on platinum, which is a
>>>
>>>closed-shell 
>>>
>>>>WL> system, and I got essentially the same results from Opteron and
>>>
>>>Origin.
>>>
>>>>WL> 
>>>>WL> Does anyone experience a similar thing? I will be appreciated
>>>
>>>if someone 
>>>
>>>>WL> can give a help hand.
>>>>WL> 
>>>>WL> Many thanks in advance!
>>>>WL> 
>>>>WL> I am also attaching the input file at the bottom of this
>>>
>>>meesage.
>>>
>>>>WL> 
>>>>WL> regards,
>>>>WL> William
>>>>WL> 
>>>>
>>>>[...]
>>>>
>>>>
>>>
>>>
>>>_______________________________________________
>>>Pw_forum mailing list
>>>Pw_forum at pwscf.org
>>>http://www.democritos.it/mailman/listinfo/pw_forum
>>>
>>
>>
>>__________________________________________________
>>Do You Yahoo!?
>>Tired of spam?  Yahoo! Mail has the best spam protection around 
>>http://mail.yahoo.com 
>>_______________________________________________
>>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

-- 
---------------------------------------------------------------------
Prof Nicola Marzari   Department of Materials Science and Engineering
13-5066   MIT   77 Massachusetts Avenue   Cambridge MA 02139-4307 USA
tel 617.4522758 fax 2586534 marzari at mit.edu http://quasiamore.mit.edu


From caohui1209 at yahoo.com.cn  Fri Apr 14 16:51:49 2006
From: caohui1209 at yahoo.com.cn (=?gb2312?q?=BB=D4=20=B2=DC?=)
Date: Fri, 14 Apr 2006 22:51:49 +0800 (CST)
Subject: [Pw_forum] problems with running example
Message-ID: <20060414145149.76996.qmail@web15701.mail.cnb.yahoo.com>

Dear all:
    
  I installed the quantum-espresso 3.0 and tried to run some examples to test it. However, it did not work. The output files contain no content. The problem is that there is undefined symbol " _intel_fast_memset" with pw.x. What should I do ?
   
  Thank you very much
  Regards
  Hui Cao
   

		
---------------------------------
 ???????????????????????
-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/attachments/20060414/89524a28/attachment.htm 

From marzari at MIT.EDU  Fri Apr 14 17:02:21 2006
From: marzari at MIT.EDU (Nicola Marzari)
Date: Fri, 14 Apr 2006 17:02:21 +0200
Subject: [Pw_forum] problems with running example
In-Reply-To: <20060414145149.76996.qmail@web15701.mail.cnb.yahoo.com>
References: <20060414145149.76996.qmail@web15701.mail.cnb.yahoo.com>
Message-ID: <443FB97D.40305@mit.edu>


? ? wrote:

> Dear all:
>  
> I installed the quantum-espresso 3.0 and tried to run some examples to 
> test it. However, it did not work. The output files contain no 
> content. The problem is that there is undefined symbol " 
> _intel_fast_memset" with pw.x. What should I do ?


Dear Hui Cao,

here are some suggestions:

1) Do the previous versions compile ?
2) Does it work in serial ?
3) Does it work in parallel ?
4) Does it work with Atlas instead of MKL ?
5) Does it work with another software compiler ?

Often, it is too complicate for anyone to give advice on such
a generic question - we do not know which compilers you have installed,
which libraries, with processors, etc... And most of the problems
are obscure, complex to find out, and always dependent on an unusual
implementation of the above on the sepcific machine.

So, best luck...

				nicola



---------------------------------------------------------------------
Prof Nicola Marzari   Department of Materials Science and Engineering
13-5066   MIT   77 Massachusetts Avenue   Cambridge MA 02139-4307 USA
tel 617.4522758 fax 2586534 marzari at mit.edu http://quasiamore.mit.edu


From lanhaiping at gmail.com  Fri Apr 14 18:33:40 2006
From: lanhaiping at gmail.com (lan haiping)
Date: Sat, 15 Apr 2006 00:33:40 +0800
Subject: [Pw_forum] Problem not related PWscf
Message-ID: <c92002fa0604140933n12e4b994oa7bfbbee500f4a44@mail.gmail.com>

Dear All:

   I am sorry to ask a question not related to the topics of maillist.
  I just want to  know which distribution is good for building
HPC-cluster.My computers are AMD248-64bit cpu.
Recently, i tried to build with RHEL AS4.0, but failed due to unstable
NIS service.  So ,  Would anyone have experience building
HPC cluster for AMD x86-64 CPU? Would you please give me some suggestion?

 Regards

Hai-Ping
-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/attachments/20060415/80e8c626/attachment.htm 

From akohlmey at vitae.cmm.upenn.edu  Fri Apr 14 21:23:26 2006
From: akohlmey at vitae.cmm.upenn.edu (Axel Kohlmeyer)
Date: Fri, 14 Apr 2006 15:23:26 -0400 (EDT)
Subject: [Pw_forum] Problem not related PWscf
In-Reply-To: <c92002fa0604140933n12e4b994oa7bfbbee500f4a44@mail.gmail.com>
Message-ID: <Pine.LNX.4.44.0604141520000.12062-100000@localhost.localdomain>

On Sat, 15 Apr 2006, lan haiping wrote:

LH> Dear All:
LH> 
LH>    I am sorry to ask a question not related to the topics of maillist.
LH>   I just want to  know which distribution is good for building
LH> HPC-cluster.My computers are AMD248-64bit cpu.
LH> Recently, i tried to build with RHEL AS4.0, but failed due to unstable
LH> NIS service.  So ,  Would anyone have experience building

hmmm. are you sure you are not overloading the headnode?
we've made good experiences with RHEL clones.

LH> HPC cluster for AMD x86-64 CPU? Would you please give me some suggestion?

you may want to dig through the resources at
https://www.liniac.upenn.edu/wiki/tiki-index.php?page=HomePage
especially the system administration section has a lot of useful hints
for the guys running quite a few clusters here at penn (9 in total, IIRC).

regards,
    axel.

LH> 
LH>  Regards
LH> 
LH> Hai-Ping
LH> 

-- 
=======================================================================
Axel Kohlmeyer   akohlmey at cmm.chem.upenn.edu   http://www.cmm.upenn.edu
   Center for Molecular Modeling   --   University of Pennsylvania
Department of Chemistry, 231 S.34th Street, Philadelphia, PA 19104-6323
tel: 1-215-898-1582,  fax: 1-215-573-6233,  office-tel: 1-215-898-5425
=======================================================================
If you make something idiot-proof, the universe creates a better idiot.



From hqzhou at nju.edu.cn  Sat Apr 15 04:32:00 2006
From: hqzhou at nju.edu.cn (Huiqun Zhou)
Date: Sat, 15 Apr 2006 10:32:00 +0800
Subject: [Pw_forum] Problem not related PWscf
References: <c92002fa0604140933n12e4b994oa7bfbbee500f4a44@mail.gmail.com>
Message-ID: <002201c66034$c633fea0$1d00a8c0@solarflare>

I recommend you Rocks distribution, it's easy to install and management. it was just
took me one and half an hour to build a 16 node cluster. With this cluster distribution, 
you can choose commercial RHEL 4, or its clone, such as CentOS.

Please refer to the following link:
www.rocksclusters.org


Huiqun Zhou
 
  ----- Original Message ----- 
  From: lan haiping 
  To: pw_forum at pwscf.org 
  Sent: Saturday, April 15, 2006 12:33 AM
  Subject: [Pw_forum] Problem not related PWscf


  Dear All:

     I am sorry to ask a question not related to the topics of maillist.
    I just want to  know which distribution is good for building HPC-cluster.My computers are AMD248-64bit cpu.
  Recently, i tried to build with RHEL AS4.0, but failed due to unstable NIS service.  So ,  Would anyone have experience building 
  HPC cluster for AMD x86-64 CPU? Would you please give me some suggestion?

   Regards 

  Hai-Ping


-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/attachments/20060415/6ccd6429/attachment.htm 

From lzhuang at whu.edu.cn  Sat Apr 15 15:30:47 2006
From: lzhuang at whu.edu.cn (Lin Zhuang)
Date: Sat, 15 Apr 2006 21:30:47 +0800
Subject: [Pw_forum] error while parallel running
Message-ID: <2b80d0af0604150630y35afa4f5kcb4a7e4819cdef39@mail.gmail.com>

 Hi all,
I was testing the compiled parallel version of pw.x, an error appeared when
I tried to run with more than one CPU, even those CPUs were on the same
computer. The error message was:
%%%%%%%%%%%%%%%%%%%%%%%%%%%
from read_namelists : error #    17
   reading namelist control
%%%%%%%%%%%%%%%%%%%%%%%%%%%
I runned the input file in a NFS-shared directory, and set the scratch to a
local directory.
I don't know what was the mistake I had made.
Any advice would be greatly appreciated.
best,
Lin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/attachments/20060415/f6332b10/attachment.htm 

From eyvaz_isaev at yahoo.com  Sat Apr 15 15:50:45 2006
From: eyvaz_isaev at yahoo.com (Eyvaz Isaev)
Date: Sat, 15 Apr 2006 06:50:45 -0700 (PDT)
Subject: [Pw_forum] error while parallel running
In-Reply-To: <2b80d0af0604150630y35afa4f5kcb4a7e4819cdef39@mail.gmail.com>
Message-ID: <20060415135045.95911.qmail@web60312.mail.yahoo.com>

Hi, 

Unlikely that it is due to NFS because pw.x started
reading input file. Check your input file carefully,
more likely, something (a keyword) is wrong in
"&control" section.

Bests,
Eyvaz.

--- Lin Zhuang <lzhuang at whu.edu.cn> wrote:

>  Hi all,
> I was testing the compiled parallel version of pw.x,
> an error appeared when
> I tried to run with more than one CPU, even those
> CPUs were on the same
> computer. The error message was:
> %%%%%%%%%%%%%%%%%%%%%%%%%%%
> from read_namelists : error #    17
>    reading namelist control
> %%%%%%%%%%%%%%%%%%%%%%%%%%%
> I runned the input file in a NFS-shared directory,
> and set the scratch to a
> local directory.
> I don't know what was the mistake I had made.
> Any advice would be greatly appreciated.
> best,
> Lin
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


From eyvaz_isaev at yahoo.com  Sat Apr 15 17:21:59 2006
From: eyvaz_isaev at yahoo.com (Eyvaz Isaev)
Date: Sat, 15 Apr 2006 08:21:59 -0700 (PDT)
Subject: [Pw_forum] error while parallel running
In-Reply-To: <2b80d0af0604150630y35afa4f5kcb4a7e4819cdef39@mail.gmail.com>
Message-ID: <20060415152159.13425.qmail@web60316.mail.yahoo.com>

By the way, did you try serial version on the same
computer? Does it work?

Bests, 
Eyvaz.

--- Lin Zhuang <lzhuang at whu.edu.cn> wrote:

>  Hi all,
> I was testing the compiled parallel version of pw.x,
> an error appeared when
> I tried to run with more than one CPU, even those
> CPUs were on the same
> computer. The error message was:
> %%%%%%%%%%%%%%%%%%%%%%%%%%%
> from read_namelists : error #    17
>    reading namelist control
> %%%%%%%%%%%%%%%%%%%%%%%%%%%
> I runned the input file in a NFS-shared directory,
> and set the scratch to a
> local directory.
> I don't know what was the mistake I had made.
> Any advice would be greatly appreciated.
> best,
> Lin
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


From akhavr at gmail.com  Sun Apr 16 00:14:37 2006
From: akhavr at gmail.com (Andrey Khavryuchenko)
Date: Sun, 16 Apr 2006 01:14:37 +0300
Subject: [Pw_forum] building espresso-3.0 with g95?
Message-ID: <m31wvyqyeq.fsf@netmaster.kds.com.ua>

Hi!

Had anyone success compiling espresso-3.0 code with g95?

My distro doesn't have g95 bundled, so I've tried binary from
http://www.g95.org.  I'm getting the following result:

g95 -O3 -cpp -D__LINUX -D__G95 -D__FFTW -I../include  -I. -I../Modules -I../PW -I../PH -I../iotk/src -c ptoolkit.f90
ptoolkit.f90:0: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://www.g95.org or mail andyv at firstinter.net for instructions.
make[1]: *** [ptoolkit.o] ??????? 1

Are there any success stories with g95?
-- 
Andrey V Khavryuchenko            http://www.kds.com.ua/
Silver Bullet Software Solutions  http://www.livejournal.com/~akhavr


From lzhuang at whu.edu.cn  Sun Apr 16 08:47:11 2006
From: lzhuang at whu.edu.cn (Lin Zhuang)
Date: Sun, 16 Apr 2006 14:47:11 +0800
Subject: [Pw_forum] Re: Re: error while parallel running
Message-ID: <2b80d0af0604152347l79575a50h86264cfae33b6dd3@mail.gmail.com>

Hi, Eyvaz:

Thank you for your suggestion.

I had succesfully run the input file with serial version pw.x and parallel
version pw.x if only one CPU had been specified, i.e.,
  $ mpirun c0 pw.x -in inputfile > outputfile
But when I tried to run the same input file with more than one CPU, like
  $ mpirun c0-1 pw.x -in inputfile > outputfile   # CPU c0-1 are on the same
computer
or
  $ mpirun -np 4 pw.x -in inputfile > outputfile  # 4 CPUs cross 2 computers
I got error like
%%%%%%%%%%%%%%%%%%%%%%%%%%%
from read_namelists : error #    17
  reading namelist control
%%%%%%%%%%%%%%%%%%%%%%%%%%%

Acturally, the input file was just Example 01 in espresso 3.0,
si.scf.david.in, and I just modified those pseudo/scratch directories.

By the way, the MPI environment is LAM/MPI 7.1.2, and was complied with
Intel icc/ifort 9.0, the same compilers as I used for espresso 3.0, and was
fully tested with the test suit of LAM/MPI. I had other ab initio MD
software, e.g., Dacapo, run successfully on the same computers and MPI
environment.

I used to add wt_collect = .TRUE. in &control in the input file, although
above error message disappeared, but pw.x still crashed with a message like
invalid argument (rank 0, MPI_COMM_WORLD).

I totally lost here. Any comment would be highly appreciated.

best,
Lin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/attachments/20060416/05ff7ac2/attachment.htm 

From ding at sissa.it  Sun Apr 16 13:01:30 2006
From: ding at sissa.it (Xunlei Ding)
Date: Sun, 16 Apr 2006 13:01:30 +0200
Subject: [Pw_forum] Re: building espresso-3.0 with g95?
Message-ID: <4442240A.1090502@sissa.it>

I have just compiled espresso-3.0 with g95 successfully.
Just use "./configure" and "make all".
You can try it.

Yours,
Ding



From akhavr at gmail.com  Sun Apr 16 13:56:23 2006
From: akhavr at gmail.com (Andrey Khavryuchenko)
Date: Sun, 16 Apr 2006 14:56:23 +0300
Subject: [Pw_forum] Re: building espresso-3.0 with g95?
In-Reply-To: <4442240A.1090502@sissa.it> (Xunlei Ding's message of "Sun, 16
 Apr 2006 13:01:30 +0200")
References: <4442240A.1090502@sissa.it>
Message-ID: <m3psjhpwd4.fsf@netmaster.kds.com.ua>

Xunlei,

"XD" == Xunlei Ding wrote:

 XD> I have just compiled espresso-3.0 with g95 successfully.
 XD> Just use "./configure" and "make all".
 XD> You can try it.

What is your g95 version?  Mine is:

$ g95 --version
G95 (GCC 4.0.3 (g95!) Apr  3 2006)
Copyright (C) 2002-2005 Free Software Foundation, Inc.

G95 comes with NO WARRANTY, to the extent permitted by law.
You may redistribute copies of G95
under the terms of the GNU General Public License.
For more information about these matters, see the file named COPYING


-- 
Andrey V Khavryuchenko            http://www.kds.com.ua/
Silver Bullet Software Solutions  http://www.livejournal.com/~akhavr


From lanhaiping at gmail.com  Sun Apr 16 20:27:53 2006
From: lanhaiping at gmail.com (lan haiping)
Date: Mon, 17 Apr 2006 02:27:53 +0800
Subject: [Pw_forum] Problem not related PWscf
In-Reply-To: <002201c66034$c633fea0$1d00a8c0@solarflare>
References: <c92002fa0604140933n12e4b994oa7bfbbee500f4a44@mail.gmail.com>
	 <002201c66034$c633fea0$1d00a8c0@solarflare>
Message-ID: <c92002fa0604161127jbccdb18p55b9b37fc860096d@mail.gmail.com>

I heard Rocks distribution before.

Thanks for your recommendation,

Regards,

Hai-Ping


On 4/15/06, Huiqun Zhou <hqzhou at nju.edu.cn> wrote:
>
>  I recommend you Rocks distribution, it's easy to install and management.
> it was just
> took me one and half an hour to build a 16 node cluster. With this cluster
> distribution,
> you can choose commercial RHEL 4, or its clone, such as CentOS.
>
> Please refer to the following link:
> www.rocksclusters.org
>
>
> Huiqun Zhou
>
>
> ----- Original Message -----
> *From:* lan haiping <lanhaiping at gmail.com>
> *To:* pw_forum at pwscf.org
> *Sent:* Saturday, April 15, 2006 12:33 AM
> *Subject:* [Pw_forum] Problem not related PWscf
>
>
> Dear All:
>
>    I am sorry to ask a question not related to the topics of maillist.
>   I just want to  know which distribution is good for building
> HPC-cluster.My computers are AMD248-64bit cpu.
> Recently, i tried to build with RHEL AS4.0, but failed due to unstable
> NIS service.  So ,  Would anyone have experience building
> HPC cluster for AMD x86-64 CPU? Would you please give me some suggestion?
>
>  Regards
>
> Hai-Ping
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/attachments/20060417/0c737dac/attachment.htm 

From dkorotin at gmail.com  Mon Apr 17 13:44:24 2006
From: dkorotin at gmail.com (Dmitry Korotin)
Date: Mon, 17 Apr 2006 17:44:24 +0600
Subject: [Pw_forum] which k-point
Message-ID: <2fd252650604170444w26679ccahccb95d6f9a3cae1d@mail.gmail.com>

Dear ESPRESSO authors,
does the number of current k-point stored in some variable during
diagonalization of Hamiltonian? (I need to know k-point number inside
the call to hpsi procedure).

Thank you in advance,
Dmitry Korotin.


From cc-lee at imre.a-star.edu.sg  Tue Apr 18 07:36:47 2006
From: cc-lee at imre.a-star.edu.sg (LEE Chin Chai)
Date: Tue, 18 Apr 2006 13:36:47 +0800
Subject: [Pw_forum] RE: Pw_forum digest, Vol 1 #954 - 5 msgs
Message-ID: <272068EBD0867D438A9A81EBFE3356DA04ABCEDE@staffexch1.imre.local>


-----Original Message-----
From: pw_forum-admin at pwscf.org [mailto:pw_forum-admin at pwscf.org] On Behalf Of pw_forum-request at pwscf.org
Sent: Saturday, April 15, 2006 1:37 PM
To: pw_forum at pwscf.org
Subject: Pw_forum digest, Vol 1 #954 - 5 msgs

Send Pw_forum mailing list submissions to
	pw_forum at pwscf.org

To subscribe or unsubscribe via the World Wide Web, visit
	http://www.democritos.it/mailman/listinfo/pw_forum
or, via email, send a message with subject or body 'help' to
	pw_forum-request at pwscf.org

You can reach the person managing the list at
	pw_forum-admin at pwscf.org

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


Today's Topics:

   1. problems with running example (=?gb2312?q?=BB=D4=20=B2=DC?=)
   2. Re: problems with running example (Nicola Marzari)
   3. Problem not related PWscf (lan haiping)
   4. Re: Problem not related PWscf (Axel Kohlmeyer)
   5. Re: Problem not related PWscf (Huiqun Zhou)

--__--__--

Message: 1
Date: Fri, 14 Apr 2006 22:51:49 +0800 (CST)
From: =?gb2312?q?=BB=D4=20=B2=DC?= <caohui1209 at yahoo.com.cn>
To: pw_forum at pwscf.org
Subject: [Pw_forum] problems with running example
Reply-To: pw_forum at pwscf.org

--0-1782785206-1145026309=:71787
Content-Type: text/plain; charset=gb2312
Content-Transfer-Encoding: 8bit

Dear all:
    
  I installed the quantum-espresso 3.0 and tried to run some examples to test it. However, it did not work. The output files contain no content. The problem is that there is undefined symbol " _intel_fast_memset" with pw.x. What should I do ?
   
  Thank you very much
  Regards
  Hui Cao
   

		
---------------------------------
 ??????????????????????????????????????????????
--0-1782785206-1145026309=:71787
Content-Type: text/html; charset=gb2312
Content-Transfer-Encoding: 8bit

<div>Dear all:</div>  <div>&nbsp; </div>  <div>I installed the quantum-espresso 3.0 and&nbsp;tried to run some examples to test it. However, it did not work.&nbsp;The output files contain no content.&nbsp;The problem is that there is undefined symbol " _intel_fast_memset" with pw.x. What should I do ?</div>  <div>&nbsp;</div>  <div>Thank you very much</div>  <div>Regards</div>  <div>Hui Cao</div>  <div>&nbsp;</div><p>
		<hr size=1><a href="http://sostar.cn.yahoo.com" target=blank> 
??????????????????????????????????????????????</a>
--0-1782785206-1145026309=:71787--

--__--__--

Message: 2
Date: Fri, 14 Apr 2006 17:02:21 +0200
From: Nicola Marzari <marzari at MIT.EDU>
Organization: Massachusetts Institute of Technology
To: pw_forum at pwscf.org
Subject: Re: [Pw_forum] problems with running example
Reply-To: pw_forum at pwscf.org



?? ?? wrote:

> Dear all:
>  
> I installed the quantum-espresso 3.0 and tried to run some examples to 
> test it. However, it did not work. The output files contain no 
> content. The problem is that there is undefined symbol " 
> _intel_fast_memset" with pw.x. What should I do ?


Dear Hui Cao,

here are some suggestions:

1) Do the previous versions compile ?
2) Does it work in serial ?
3) Does it work in parallel ?
4) Does it work with Atlas instead of MKL ?
5) Does it work with another software compiler ?

Often, it is too complicate for anyone to give advice on such
a generic question - we do not know which compilers you have installed,
which libraries, with processors, etc... And most of the problems
are obscure, complex to find out, and always dependent on an unusual
implementation of the above on the sepcific machine.

So, best luck...

				nicola



---------------------------------------------------------------------
Prof Nicola Marzari   Department of Materials Science and Engineering
13-5066   MIT   77 Massachusetts Avenue   Cambridge MA 02139-4307 USA
tel 617.4522758 fax 2586534 marzari at mit.edu http://quasiamore.mit.edu

--__--__--

Message: 3
Date: Sat, 15 Apr 2006 00:33:40 +0800
From: "lan haiping" <lanhaiping at gmail.com>
To: pw_forum at pwscf.org
Subject: [Pw_forum] Problem not related PWscf
Reply-To: pw_forum at pwscf.org

------=_Part_7226_29467865.1145032420972
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Dear All:

   I am sorry to ask a question not related to the topics of maillist.
  I just want to  know which distribution is good for building
HPC-cluster.My computers are AMD248-64bit cpu.
Recently, i tried to build with RHEL AS4.0, but failed due to unstable
NIS service.  So ,  Would anyone have experience building
HPC cluster for AMD x86-64 CPU? Would you please give me some suggestion?

 Regards

Hai-Ping

------=_Part_7226_29467865.1145032420972
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

<div>Dear All:</div>
<div>&nbsp;</div>
<div>&nbsp; &nbsp;I am sorry to ask a question not related to the topics of=
 maillist.</div>
<div>&nbsp; I just want to&nbsp; know which distribution is good for buildi=
ng HPC-cluster.My computers are AMD248-64bit cpu.</div>
<div>Recently, i tried to build with RHEL AS4.0, but failed due to unstable=
 NIS&nbsp;service.&nbsp; So ,&nbsp; Would anyone have experience building <=
/div>
<div>HPC cluster for AMD x86-64 CPU? Would you please give me some suggesti=
on?</div>
<div>&nbsp;</div>
<div>&nbsp;Regards </div>
<div>&nbsp;</div>
<div>Hai-Ping</div>
<div>&nbsp;</div>
<div>&nbsp;</div>
<div>&nbsp;</div>

------=_Part_7226_29467865.1145032420972--

--__--__--

Message: 4
Date: Fri, 14 Apr 2006 15:23:26 -0400 (EDT)
From: Axel Kohlmeyer <akohlmey at vitae.cmm.upenn.edu>
To: lan haiping <lanhaiping at gmail.com>
Cc: PW Forum <pw_forum at pwscf.org>
Subject: Re: [Pw_forum] Problem not related PWscf
Reply-To: pw_forum at pwscf.org

On Sat, 15 Apr 2006, lan haiping wrote:

LH> Dear All:
LH> 
LH>    I am sorry to ask a question not related to the topics of maillist.
LH>   I just want to  know which distribution is good for building
LH> HPC-cluster.My computers are AMD248-64bit cpu.
LH> Recently, i tried to build with RHEL AS4.0, but failed due to unstable
LH> NIS service.  So ,  Would anyone have experience building

hmmm. are you sure you are not overloading the headnode?
we've made good experiences with RHEL clones.

LH> HPC cluster for AMD x86-64 CPU? Would you please give me some suggestion?

you may want to dig through the resources at
https://www.liniac.upenn.edu/wiki/tiki-index.php?page=HomePage
especially the system administration section has a lot of useful hints
for the guys running quite a few clusters here at penn (9 in total, IIRC).

regards,
    axel.

LH> 
LH>  Regards
LH> 
LH> Hai-Ping
LH> 

-- 
=======================================================================
Axel Kohlmeyer   akohlmey at cmm.chem.upenn.edu   http://www.cmm.upenn.edu
   Center for Molecular Modeling   --   University of Pennsylvania
Department of Chemistry, 231 S.34th Street, Philadelphia, PA 19104-6323
tel: 1-215-898-1582,  fax: 1-215-573-6233,  office-tel: 1-215-898-5425
=======================================================================
If you make something idiot-proof, the universe creates a better idiot.


--__--__--

Message: 5
From: "Huiqun Zhou" <hqzhou at nju.edu.cn>
To: <pw_forum at pwscf.org>
Subject: Re: [Pw_forum] Problem not related PWscf
Date: Sat, 15 Apr 2006 10:32:00 +0800
Reply-To: pw_forum at pwscf.org

This is a multi-part message in MIME format.

------=_NextPart_000_001F_01C66077.D40AF360
Content-Type: text/plain;
	charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable

I recommend you Rocks distribution, it's easy to install and management. =
it was just
took me one and half an hour to build a 16 node cluster. With this =
cluster distribution,=20
you can choose commercial RHEL 4, or its clone, such as CentOS.

Please refer to the following link:
www.rocksclusters.org


Huiqun Zhou
=20
  ----- Original Message -----=20
  From: lan haiping=20
  To: pw_forum at pwscf.org=20
  Sent: Saturday, April 15, 2006 12:33 AM
  Subject: [Pw_forum] Problem not related PWscf


  Dear All:

     I am sorry to ask a question not related to the topics of maillist.
    I just want to  know which distribution is good for building =
HPC-cluster.My computers are AMD248-64bit cpu.
  Recently, i tried to build with RHEL AS4.0, but failed due to unstable =
NIS service.  So ,  Would anyone have experience building=20
  HPC cluster for AMD x86-64 CPU? Would you please give me some =
suggestion?

   Regards=20

  Hai-Ping



------=_NextPart_000_001F_01C66077.D40AF360
Content-Type: text/html;
	charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2900.2802" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>I recommend you Rocks distribution, =
it's easy to=20
install and management. it was just</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>took me one and half an hour to build a =
16 node=20
cluster. With this </FONT><FONT face=3DArial size=3D2>cluster =
distribution,=20
</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>you can choose commercial RHEL 4, or =
its clone,=20
such as&nbsp;</FONT><FONT face=3DArial size=3D2>CentOS.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Please refer to the following =
link:</FONT></DIV>
<DIV><FONT face=3DArial size=3D2><A=20
href=3D"http://www.rocksclusters.org">www.rocksclusters.org</A></FONT></D=
IV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Huiqun Zhou</FONT></DIV>
<DIV>&nbsp;</DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV>
  <DIV=20
  style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: =
black"><B>From:</B>=20
  <A title=3Dlanhaiping at gmail.com =
href=3D"mailto:lanhaiping at gmail.com">lan=20
  haiping</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A =
title=3Dpw_forum at pwscf.org=20
  href=3D"mailto:pw_forum at pwscf.org">pw_forum at pwscf.org</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Saturday, April 15, 2006 =
12:33=20
  AM</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> [Pw_forum] Problem not =
related=20
  PWscf</DIV>
  <DIV><BR></DIV>
  <DIV>Dear All:</DIV>
  <DIV>&nbsp;</DIV>
  <DIV>&nbsp; &nbsp;I am sorry to ask a question not related to the =
topics of=20
  maillist.</DIV>
  <DIV>&nbsp; I just want to&nbsp; know which distribution is good for =
building=20
  HPC-cluster.My computers are AMD248-64bit cpu.</DIV>
  <DIV>Recently, i tried to build with RHEL AS4.0, but failed due to =
unstable=20
  NIS&nbsp;service.&nbsp; So ,&nbsp; Would anyone have experience =
building=20
</DIV>
  <DIV>HPC cluster for AMD x86-64 CPU? Would you please give me some=20
  suggestion?</DIV>
  <DIV>&nbsp;</DIV>
  <DIV>&nbsp;Regards </DIV>
  <DIV>&nbsp;</DIV>
  <DIV>Hai-Ping</DIV>
  <DIV>&nbsp;</DIV>
  <DIV>&nbsp;</DIV>
  <DIV>&nbsp;</DIV></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_001F_01C66077.D40AF360--



--__--__--

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


End of Pw_forum Digest



**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

www.imre.a-star.edu.sg
**********************************************************************



From Steven.Kirk at hv.se  Tue Apr 18 11:16:47 2006
From: Steven.Kirk at hv.se (Steven Kirk)
Date: Tue, 18 Apr 2006 11:16:47 +0200
Subject: [Pw_forum] Symmetry-finding problems in pw.x
Message-ID: <4444AE7F.9010108@hv.se>

Hello,

I am trying to simulate a multiwalled carbon nanotube in pw.x using the
input file:

   &CONTROL
    title='MWNT calculation',
    calculation='scf',
    restart_mode='from_scratch',
    prefix='MWNT',
  /
  &SYSTEM
    ibrav = 6,
    A = 17.0, B = 17.0, C = 4.26, cosAB = 0, cosAC = 0, cosBC = 0,
    nat = 24,
    ntyp = 1,
    ecutwfc = 73.4986,
  /
  &ELECTRONS
  /
ATOMIC_SPECIES
C 12.0107 C.pbe-rrkjus.UPF
ATOMIC_POSITIONS {crystal}
C     0.18067    0.03594    0.47051
C     0.18067    0.03594    0.80385
C     0.15316    0.10234    0.97051
C     0.15316    0.10234    0.30385
C     0.10234    0.15316    0.47051
C     0.10234    0.15316    0.80385
C     0.03594    0.18067    0.97051
C     0.03594    0.18067    0.30385
C    -0.35480   -0.09923    0.18505
C    -0.32863   -0.16654    0.35171
C    -0.35480   -0.09923    0.85171
C    -0.28982   -0.22745    0.18505
C    -0.23988   -0.27962    0.35171
C    -0.32863   -0.16654    0.68505
C    -0.28982   -0.22745    0.85171
C    -0.18072   -0.32105    0.18505
C    -0.11461   -0.35014    0.35171
C    -0.23988   -0.27962    0.68505
C    -0.18072   -0.32105    0.85171
C    -0.04410   -0.36577    0.18505
C     0.02810   -0.36734    0.35171
C    -0.11461   -0.35014    0.68505
C    -0.04410   -0.36577    0.85171
C     0.02810   -0.36734    0.68505
K_POINTS gamma

I am trying to make maximum use of symmetry, because the wavefunction
file gets too big when I don't use it.

Unfortunately it seems that pw.x says 'No symmetry !' with the input
data above. How can I make sure that pw.x detects the 4-fold symmetry
and simulates the structure correctly with the minimum number of atoms ?

Many thanks in advance,
Steve Kirk
-- 
Dr. Steven R. Kirk           <Steven.Kirk at hv.se, S.R.Kirk at physics.org>
Dept. of Technology, Mathematics & Computer Science  (P)+46 520 223215
University West                                      (F)+46 520 223299
P.O. Box 957 Trollhattan 461 29 SWEDEN       http://taconet.webhop.org



From marzari at MIT.EDU  Tue Apr 18 13:38:42 2006
From: marzari at MIT.EDU (Nicola Marzari)
Date: Tue, 18 Apr 2006 13:38:42 +0200
Subject: [Pw_forum] Symmetry-finding problems in pw.x
In-Reply-To: <4444AE7F.9010108@hv.se>
References: <4444AE7F.9010108@hv.se>
Message-ID: <4444CFC2.2080009@mit.edu>


Hi Steve,


here are a few comments (in your case, 2), and then 1) are the likely
culprits).

1) you need to have enough significant digits in your
input for the code to recognize symmetry operations - 5 is probably
borderline, and not enough.

2) you shouldn't force to code to look for fractional translations:
arrange the nanotube such that your coordinates show
symmetry: x in -x, or such (that is to say, place the nanotube so that 
it is bisected by symmetry planes such as x=0).

You should also start with a SWNT, and experiment a bit to see when
operations are found.

3) for an ultrasoft carbon, you need between 25 and 30 Ry. your cutoff 
is much much larger than needed or reasonable. But you need a dual of
8 to 12 for the charge density cutoff. The tests are actually published 
in the pseudopotential page, for this pseudo.

Advice: try to reproduce diamond and graphene results, and then
a simple swnt, before moving to mwnt. Extensive results on
carbon, with this pseudo, are e.g. on a Mounet/Marzari PRB of 2005.

A question for everyone else: could there be an input mode in which
point-group symmetry operations are specified by hand ? Once could have
the code then 1) check that those are symmetry operations, or 2)
multiply atoms using the point group symmetries that have been read.


			nicola



Steven Kirk wrote:

> Hello,
> 
> I am trying to simulate a multiwalled carbon nanotube in pw.x using the
> input file:
> 
>   &CONTROL
>    title='MWNT calculation',
>    calculation='scf',
>    restart_mode='from_scratch',
>    prefix='MWNT',
>  /
>  &SYSTEM
>    ibrav = 6,
>    A = 17.0, B = 17.0, C = 4.26, cosAB = 0, cosAC = 0, cosBC = 0,
>    nat = 24,
>    ntyp = 1,
>    ecutwfc = 73.4986,
>  /
>  &ELECTRONS
>  /
> ATOMIC_SPECIES
> C 12.0107 C.pbe-rrkjus.UPF
> ATOMIC_POSITIONS {crystal}
> C     0.18067    0.03594    0.47051
> C     0.18067    0.03594    0.80385
> C     0.15316    0.10234    0.97051
> C     0.15316    0.10234    0.30385
> C     0.10234    0.15316    0.47051
> C     0.10234    0.15316    0.80385
> C     0.03594    0.18067    0.97051
> C     0.03594    0.18067    0.30385
> C    -0.35480   -0.09923    0.18505
> C    -0.32863   -0.16654    0.35171
> C    -0.35480   -0.09923    0.85171
> C    -0.28982   -0.22745    0.18505
> C    -0.23988   -0.27962    0.35171
> C    -0.32863   -0.16654    0.68505
> C    -0.28982   -0.22745    0.85171
> C    -0.18072   -0.32105    0.18505
> C    -0.11461   -0.35014    0.35171
> C    -0.23988   -0.27962    0.68505
> C    -0.18072   -0.32105    0.85171
> C    -0.04410   -0.36577    0.18505
> C     0.02810   -0.36734    0.35171
> C    -0.11461   -0.35014    0.68505
> C    -0.04410   -0.36577    0.85171
> C     0.02810   -0.36734    0.68505
> K_POINTS gamma
> 
> I am trying to make maximum use of symmetry, because the wavefunction
> file gets too big when I don't use it.
> 
> Unfortunately it seems that pw.x says 'No symmetry !' with the input
> data above. How can I make sure that pw.x detects the 4-fold symmetry
> and simulates the structure correctly with the minimum number of atoms ?
> 
> Many thanks in advance,
> Steve Kirk

-- 
---------------------------------------------------------------------
Prof Nicola Marzari   Department of Materials Science and Engineering
13-5066   MIT   77 Massachusetts Avenue   Cambridge MA 02139-4307 USA
tel 617.4522758 fax 2586534 marzari at mit.edu http://quasiamore.mit.edu


From ejl7240 at chemail.tamu.edu  Tue Apr 18 15:09:31 2006
From: ejl7240 at chemail.tamu.edu (Eduardo J. Lamas)
Date: Tue, 18 Apr 2006 08:09:31 -0500
Subject: [Pw_forum] pw.x always crashes at the end of relax calculations
Message-ID: <001a01c662e9$54d27ae0$0ee35ba5@ch0316>

Hi, pw.x always crashes to me during the last check of the relax
calculations
it happened in versions 2.1.3 and 3.0 and with different compilers.
In order to avoid this I commented the following lines in move_ions.f90
(then the program proceed
normally and ends normally but the check without electronic history is not
longer really done):

              CALL hinit0()
              CALL potinit()
              CALL newd()
              CALL wfcinit()

When I want to check that the forces are indeed low I take the coordinates
without the verifications
and run a scf calculation and print the forces.

I am wondering if it is something wrong in those subroutines and if somebody
else was having the same problem.
Maybe during the reinitialization a variable is deleted twice or something
or is accessed after it is deleted?. 

Thanks,

Eduardo  

This run for example crashes (but nearly all runs were having this problem):

 &CONTROL
                       title='H20',
                 calculation='relax',
                 restart_mode='from_scratch',
                      tprnfor=.true.,
                  pseudo_dir='/home/lamas/espresso/pseudo/',
                       outdir='./tmp/',
                   max_seconds=90000,
 /
 &SYSTEM
                       ibrav = 1,
                    celldm(1)= 15,
                         nat = 3,
                        ntyp = 2,
                        nbnd = 5,
                     ecutwfc =50.0,
                     ecutrho =500,
                  occupations='from_input',
                        nspin=2,
       starting_magnetization=0.0
 /
&ELECTRONS
    mixing_beta = 0.2,
    conv_thr =  1.0d-6
 /
&IONS
ion_dynamics='bfgs',
/

ATOMIC_SPECIES
  O   16.00  O_PBE_v1.vdb
  H    1.00  H_PBE_v1.vdb
ATOMIC_POSITIONS {angstrom}
  O        2.021843520   1.760434290    0.28003039
  H        2.286102819   0.815021260    0.08933101
  H        2.811655420   2.359926539    0.15037213
OCCUPATIONS
1.0 1.0 1.0 1.0 0.0
1.0 1.0 1.0 1.0 0.0







From proffess at yandex.ru  Tue Apr 18 15:33:50 2006
From: proffess at yandex.ru (Sergey Lisenkov)
Date: Tue, 18 Apr 2006 17:33:50 +0400 (MSD)
Subject: [Pw_forum] metallic or not
Message-ID: <4444EABE.000003.05743@ariel.yandex.ru>

 Dear all,

  I have a problem. I am stdying the silicon clathrates. One of them has became metallic after full relaxation using pwscf (2.1.5 version). It is well known that silicon clathrates have band gap wider than tetrahedral silicon.

 What can be the problem?

  Thanks,
   Sergey


From dalcorso at sissa.it  Tue Apr 18 15:44:13 2006
From: dalcorso at sissa.it (Andrea Dal Corso)
Date: Tue, 18 Apr 2006 15:44:13 +0200
Subject: [Pw_forum] Non-colinear magnetism
In-Reply-To: <Pine.LNX.4.64.0604101605420.15921@hermes-1.csi.cam.ac.uk>
References: <Pine.LNX.4.64.0604101605420.15921@hermes-1.csi.cam.ac.uk>
Message-ID: <1145367853.4626.24.camel@dhpc-5-26.sissa.it>

On Mon, 2006-04-10 at 16:09 +0100, H.S.Domingos wrote:
> Dear all,
> 
> I would like to ask if the non-colinear magnetism part of the code is 
> fairly stable. I would like to do magnetism in permalloys and I dont have 
> a feel for how hard that might be with this code.
> Is it advised to use the experimental features for this or is it 
> half-baked and unstable ?


As far as I know, the non-collinear and the spin-orbit parts of pw.x are
working. This part of the code has been used less extensively than the
other parts so bugs could still be present. Please help us to find
them. 

Best wishes,

Andrea

> Thank you very much once again,
> 
> Helder
> 
> 
> =======================================================================
> |  Dr. Helder S. Domingos                                             |
> |                                                                     |
> | INESC Microsyst & Nanotechnol, Lisbon, P-1000 Portugal              |
> | and                                                                 |
> | R&D unit for  Molecular Chemical Physics                            |
> | Chemistry Department, University of Coimbra                         |
> =======================================================================
> 
> _______________________________________________
> Pw_forum mailing list
> Pw_forum at pwscf.org
> http://www.democritos.it/mailman/listinfo/pw_forum
-- 
Andrea Dal Corso                    Tel. 0039-040-3787428
SISSA, Via Beirut 2/4               Fax. 0039-040-3787528
34014 Trieste (Italy)               e-mail: dalcorso at sissa.it



From emenendez at macul.ciencias.uchile.cl  Tue Apr 18 17:48:12 2006
From: emenendez at macul.ciencias.uchile.cl (Eduardo Ariel Menendez P)
Date: Tue, 18 Apr 2006 11:48:12 -0400 (CLT)
Subject: [Pw_forum] Re: SOC
In-Reply-To: <20060414053744.17757.95638.Mailman@democritos.sissa.it>
References: <20060414053744.17757.95638.Mailman@democritos.sissa.it>
Message-ID: <Pine.LNX.4.58.0604181145210.11207@macul.ciencias.uchile.cl>

Does it means that one can obtain bands with spin-orbit splitting using a
fully relativistic pseudopotentials?
Thanks
Eduardo

>
> Message: 1
> Subject: Re: [Pw_forum] SOC
> From: Andrea Dal Corso <dalcorso at sissa.it>
> To: pw_forum at pwscf.org
> Organization: SISSA
> Date: Thu, 13 Apr 2006 09:11:32 +0200
> Reply-To: pw_forum at pwscf.org
>
> Yes the SO term is only in the pseudo-potential but valence states
> interact with a fully relativistic pseudo-potential at each scf cycle.
> We make an approximation because we neglect the spin-orbit coupling
> outside the core radius where however the effect is expected to be
> small.
>
> Andrea
>
>
> On Wed, 2006-04-12 at 12:43 -0500, Bhagawan Sahu wrote:
> > Dear pwscf users,
> >
> >   Is it true that
> >
> > the  bulk spin-orbit coupling (SOC) calculation is done using a
> > relativistic
> > PP for the atom/ion (RRKJ scheme and Andrea Dal Carso's PRB paper) and the
> > SOC effect is not included self-consistently on the valence states during
> > the scf cycle?
> >
> > Sahu
> >
> > _______________________________________________
> > Pw_forum mailing list
> > Pw_forum at pwscf.org
> > http://www.democritos.it/mailman/listinfo/pw_forum
> --
> Andrea Dal Corso                    Tel. 0039-040-3787428
> SISSA, Via Beirut 2/4               Fax. 0039-040-3787528
> 34014 Trieste (Italy)               e-mail: dalcorso at sissa.it
>


From dalcorso at sissa.it  Tue Apr 18 17:54:55 2006
From: dalcorso at sissa.it (Andrea Dal Corso)
Date: Tue, 18 Apr 2006 17:54:55 +0200
Subject: [Pw_forum] Re: SOC
In-Reply-To: <Pine.LNX.4.58.0604181145210.11207@macul.ciencias.uchile.cl>
References: <20060414053744.17757.95638.Mailman@democritos.sissa.it>
	 <Pine.LNX.4.58.0604181145210.11207@macul.ciencias.uchile.cl>
Message-ID: <1145375695.4626.30.camel@dhpc-5-26.sissa.it>

Yes, the bands published in Phys. Rev. B 71, 115106 (2005) can be
obtained with pw.x. See example22.

Andrea


On Tue, 2006-04-18 at 11:48 -0400, Eduardo Ariel Menendez P wrote:
> Does it means that one can obtain bands with spin-orbit splitting using a
> fully relativistic pseudopotentials?
> Thanks
> Eduardo
> 
> >
> > Message: 1
> > Subject: Re: [Pw_forum] SOC
> > From: Andrea Dal Corso <dalcorso at sissa.it>
> > To: pw_forum at pwscf.org
> > Organization: SISSA
> > Date: Thu, 13 Apr 2006 09:11:32 +0200
> > Reply-To: pw_forum at pwscf.org
> >
> > Yes the SO term is only in the pseudo-potential but valence states
> > interact with a fully relativistic pseudo-potential at each scf cycle.
> > We make an approximation because we neglect the spin-orbit coupling
> > outside the core radius where however the effect is expected to be
> > small.
> >
> > Andrea
> >
> >
> > On Wed, 2006-04-12 at 12:43 -0500, Bhagawan Sahu wrote:
> > > Dear pwscf users,
> > >
> > >   Is it true that
> > >
> > > the  bulk spin-orbit coupling (SOC) calculation is done using a
> > > relativistic
> > > PP for the atom/ion (RRKJ scheme and Andrea Dal Carso's PRB paper) and the
> > > SOC effect is not included self-consistently on the valence states during
> > > the scf cycle?
> > >
> > > Sahu
> > >
> > > _______________________________________________
> > > Pw_forum mailing list
> > > Pw_forum at pwscf.org
> > > http://www.democritos.it/mailman/listinfo/pw_forum
> > --
> > Andrea Dal Corso                    Tel. 0039-040-3787428
> > SISSA, Via Beirut 2/4               Fax. 0039-040-3787528
> > 34014 Trieste (Italy)               e-mail: dalcorso at sissa.it
> >
> _______________________________________________
> Pw_forum mailing list
> Pw_forum at pwscf.org
> http://www.democritos.it/mailman/listinfo/pw_forum
-- 
Andrea Dal Corso                    Tel. 0039-040-3787428
SISSA, Via Beirut 2/4               Fax. 0039-040-3787528
34014 Trieste (Italy)               e-mail: dalcorso at sissa.it



From eyvaz_isaev at yahoo.com  Tue Apr 18 22:07:08 2006
From: eyvaz_isaev at yahoo.com (Eyvaz Isaev)
Date: Tue, 18 Apr 2006 13:07:08 -0700 (PDT)
Subject: [Pw_forum] metallic or not
In-Reply-To: <4444EABE.000003.05743@ariel.yandex.ru>
Message-ID: <20060418200708.31189.qmail@web60315.mail.yahoo.com>

Hi Sergei,

One can suggest that it is due to the LDA which
underestmate the band gap. Did you check with a
pseudopotential you used the band gap in Si, and
unrelaxed clathrate? Is your clathrate direct or
indirect semiconductor?

On the other side relaxation will violate  your
initial symmetry that may lead to appearence
additional bands so that a band cross-section might
take place.
Please pay attention that you may have a direct band
gap for a given k-point (even a set of k-points) in
BZ, but indirect gap might be close to zero.
In this case  according DOS calculations you can not
conclude whether you have metal or semoconductor. In
this case band structure calculations are more useful.

Hope it helps,
Eyvaz.


--- Sergey Lisenkov <proffess at yandex.ru> wrote:

> 
>  Dear all,
> 
>   I have a problem. I am stdying the silicon
> clathrates. One of them has became metallic after
> full relaxation using pwscf (2.1.5 version). It is
> well known that silicon clathrates have band gap
> wider than tetrahedral silicon.
> 
>  What can be the problem?
> 
>   Thanks,
>    Sergey
> _______________________________________________
> Pw_forum mailing list
> Pw_forum at pwscf.org
> http://www.democritos.it/mailman/listinfo/pw_forum
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


From proffess at yandex.ru  Tue Apr 18 23:15:58 2006
From: proffess at yandex.ru (Sergey Lisenkov)
Date: Wed, 19 Apr 2006 01:15:58 +0400 (MSD)
Subject: [Pw_forum] metallic or not
In-Reply-To: <20060418200708.31189.qmail@web60315.mail.yahoo.com>
References: <20060418200708.31189.qmail@web60315.mail.yahoo.com>
Message-ID: <4445570E.000001.19710@mfront8.yandex.ru>

 Hi Eyvaz,

  Thanks a lot for the reply. Yes, the underestimation was the first thing I thought. I use PBE functional and test for silicon diamond gave me a band gap of ~0.8 eV, which is the _standart_ DFT band gap value.

 Another thing is that when this clathrate was relaxed by TBMD, the final structure is semiconductor with a band gap around 1.6 eV which is appropriate value. When I relaxed this "relaxed by TBMD" structure it becames a metallic. When I compared two DOS (one from TBMD and another one from PW) I see that are almost identical with one difference. The DOS obtained by PW conatains some additional peaks on Fermi Level.

I think this is a DFT fault. I remember, that in case of carbon clathrates people using DFT found that these structures are metallic, which WAS not confirmed by experiments.

  Thanks,
    Sergey



From baroni at sissa.it  Wed Apr 19 08:18:18 2006
From: baroni at sissa.it (Stefano Baroni)
Date: Wed, 19 Apr 2006 08:18:18 +0200
Subject: [Pw_forum] Fwd: how to input crystal structure of Amm2 SrTiO3
References: <20060419013530.93264.qmail@web15804.mail.cnb.yahoo.com>
Message-ID: <89B2A50A-A6E8-447C-BABA-2F9D55205003@sissa.it>

Dear All: I am forwarding here this message that was sent directly to  
me. A reply will follow shortly.

Dear Zhuzhenye: please, send this kind of messages to this forum (to  
which you can subscribe from the "users' forum section" of the pwscf  
home page" www.pwscf.org). Also, do not forget to browse the mailing  
list's archive before starting a new thread in the list. The archive  
already contains many answers to many of the questions that you may  
want to ask. Thaank you for using PWscf and for writing to us.

Stefano B.


Begin forwarded message:

> From: ?? ? <coldwind1978 at yahoo.com.cn>
> Date: April 19, 2006 3:35:30 AM GMT+02:00
> To: stefano.baroni at democritos.it
> Subject: how to input crystal structure of Amm2 SrTiO3
>
> Dear stefano Baroni:
> i want to caculate the properties of SrTiO3 under tensile strain. i  
> have known the crystal structure of SrTiO3 under tensile strain is  
> Amm2 space group, and atomic cartesian cooridinate : Sr(0,0,0),Ti 
> ((0.5+?x,0,0.5),O1(0.5+?x,0,0) O2(0.25+?x,0.25+?y,0.5).there is  
> several question about atomic question.
> first, in ATOMIC_POSITION{alat}, is atomic cooridinates along  
> cartesian cooridinate? second in ATOMIC_POSITION{crystal}, is  
> atomic cooridinates along crystal axis of primitive unit cell   
> cooridinate?for hobr and angstrom,the case is same to the alat?
> from symmestry, The SrTiO3 cartesian cooridinate:
> Sr      0.000000      0.000000      0.000000
> Ti      0.500000      0.000000      0.500000
> O      0.500000      0.000000      0.000000
> O      0.250000     -0.250000      0.000000
> O      0.750000     -0.250000      0.500000
> O      0.750000     -0.250000      0.000000
> O      0.250000     -0.250000      0.500000
> but i found that the ion position in still after optimization.  
> please tell me how to input structure of AMM2 SrTiO3?
> There is my inputfile of
> SrTIO3
> &CONTROL
>             title='st'
>             calculation='relax'
>             restart_mode = 'from_scratch' ,
>             outdir = 'tmp' ,
>             pseudo_dir = '/home/zzy/pwscf/pseudo/' ,
>             prefix = 'pst' ,
>             forc_conv_thr=1.0D-4
>             tstress = .true. ,
>             tprnfor = .true. ,
> /
> &SYSTEM
>            ibrav=9,
>            celldm(1)=7.5,
>            celldm(2)=1
>            celldm(3)=0.955
>            nat=7,
>            ntyp=3,
>           ecutwfc=50,
>           ecutrho=450
> /
> &ELECTRONS
>              conv_thr=1.0d-6
> /
> &IONS
>                 ion_dynamics = 'bfgs' ,
> /
> ATOMIC_SPECIES
>  Sr   87.62000  038-Sr-ca-sp-vgrp.uspp.UPF
>  Ti   47.88000  022-Ti-ca-sp-vgrp.uspp.UPF
>  O    15.99960  008-O-ca--vgrp.uspp.UPF
> ATOMIC_POSITIONS {crystal}
> Sr 0    0     0    0 0 0
> Ti 0.5  0     0.5  1 0 0
> O  0.5  0      0   1 0 0
> O  0.25 -0.25  0.0 1 1 0
> O  0.75 -0.25 0.5  1 1 0
> O  0.25 -0.25 0.5  1 1 0
> O  0.75 -0.25  0   1 1 0
> K_POINTS {automatic}
> 6 6 6 1 1 1
>
> Regards
>
>                                                  zhuzhenye
> __________________________________________________
> ???????????????
> http://cn.mail.yahoo.com

---
Stefano Baroni - SISSA  &  DEMOCRITOS National Simulation Center -  
Trieste
[+39] 040 3787 406 (tel) -528 (fax) / stefanobaroni (skype)

Please, if possible, don't  send me MS Word or PowerPoint attachments
Why? See:  http://www.gnu.org/philosophy/no-word-attachments.html



-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/attachments/20060419/5ecbcc7d/attachment.htm 

From baroni at sissa.it  Wed Apr 19 09:19:27 2006
From: baroni at sissa.it (Stefano Baroni)
Date: Wed, 19 Apr 2006 09:19:27 +0200
Subject: [Pw_forum] Re: how to input crystal structure of Amm2 SrTiO3
In-Reply-To: <20060419013530.93264.qmail@web15804.mail.cnb.yahoo.com>
References: <20060419013530.93264.qmail@web15804.mail.cnb.yahoo.com>
Message-ID: <512F5B15-BC10-4D90-8AF3-CAC20AAFE9E2@sissa.it>


On Apr 19, 2006, at 3:35 AM, ?? ? wrote:

> Dear stefano Baroni:
> i want to caculate the properties of SrTiO3 under tensile strain. i  
> have known the crystal structure of SrTiO3 under tensile strain is  
> Amm2 space group, and atomic cartesian cooridinate : Sr(0,0,0),Ti 
> ((0.5+?x,0,0.5),O1(0.5+?x,0,0) O2(0.25+?x,0.25+?y,0.5).there is  
> several question about atomic question.
> first, in ATOMIC_POSITION{alat}, is atomic cooridinates along  
> cartesian cooridinate?

YES atomic coordinates are cartesian for every option of the  
ATOMIC_POSITION control card, but "crystal"

> second in ATOMIC_POSITION{crystal}, is atomic cooridinates along  
> crystal axis of primitive unit cell  cooridinate?for hobr and  
> angstrom,the case is same to the alat?

I do not quite understand the question, in any case the "crystal"  
atomic coordinates are defined by the convention:

x(:)  = \sum_j AT(:,j)*c(j),

where x(:) are the atomic (cartesian) coordinates, and AT(:,1), AT(:, 
2), AT(:,3) are the the basis vectors of the Bravais lattice with  
their own units (you usually specify AT giving "ibrav" and "celldm 
(:)", the latter in Bohr radii). A list of conventional basis vectors  
used by PWscf (as well as much other useful information) is found in  
the documentation files distributed with the code (INPUT_PW, in the  
present case). Beware, though, that you hardly need to pass atomic  
positions in crystal units. It is usually far easier to pass them in  
cartesian coordinates.

> from symmestry, The SrTiO3 cartesian cooridinate:
> Sr      0.000000      0.000000      0.000000
> Ti      0.500000      0.000000      0.500000
> O      0.500000      0.000000      0.000000
> O      0.250000     -0.250000      0.000000
> O      0.750000     -0.250000      0.500000
> O      0.750000     -0.250000      0.000000
> O      0.250000     -0.250000      0.500000
> but i found that the ion position in still after optimization.  
> please tell me how to input structure of AMM2 SrTiO3?

This is a more subtle question which I would invite you to think  
about carefully by yourself.

Suppose you want to find the (stable) equilibrium position of a  
particle in a double potential well, say V(x)=(x^2-1)^2, and that you  
start your numerical search from x=0. The force acting on the  
particle at this position is zero by symmetry. So, any algorithm  
aiming at finding the zeroes of the force would keep the particle  
fixed at x=0. Does this imply that this is an equilibrim position?  
Does this imply that this a _stable_ equilibrium position? How would  
you use an algorithm which finds the zeroes of the force to find a  
stable equilibrium configuration in this case? What has this all to  
do with you problem?

Please, give a thought at these questions and revert to us with or  
without a solution to your problem.

Stefano B.



> There is my inputfile of
> SrTIO3
> &CONTROL
>             title='st'
>             calculation='relax'
>             restart_mode = 'from_scratch' ,
>             outdir = 'tmp' ,
>             pseudo_dir = '/home/zzy/pwscf/pseudo/' ,
>             prefix = 'pst' ,
>             forc_conv_thr=1.0D-4
>             tstress = .true. ,
>             tprnfor = .true. ,
> /
> &SYSTEM
>            ibrav=9,
>            celldm(1)=7.5,
>            celldm(2)=1
>            celldm(3)=0.955
>            nat=7,
>            ntyp=3,
>           ecutwfc=50,
>           ecutrho=450
> /
> &ELECTRONS
>              conv_thr=1.0d-6
> /
> &IONS
>                 ion_dynamics = 'bfgs' ,
> /
> ATOMIC_SPECIES
>  Sr   87.62000  038-Sr-ca-sp-vgrp.uspp.UPF
>  Ti   47.88000  022-Ti-ca-sp-vgrp.uspp.UPF
>  O    15.99960  008-O-ca--vgrp.uspp.UPF
> ATOMIC_POSITIONS {crystal}
> Sr 0    0     0    0 0 0
> Ti 0.5  0     0.5  1 0 0
> O  0.5  0      0   1 0 0
> O  0.25 -0.25  0.0 1 1 0
> O  0.75 -0.25 0.5  1 1 0
> O  0.25 -0.25 0.5  1 1 0
> O  0.75 -0.25  0   1 1 0
> K_POINTS {automatic}
> 6 6 6 1 1 1
>
> Regards
>
>                                                  zhuzhenye
> __________________________________________________
> ???????????????
> http://cn.mail.yahoo.com

---
Stefano Baroni - SISSA  &  DEMOCRITOS National Simulation Center -  
Trieste
[+39] 040 3787 406 (tel) -528 (fax) / stefanobaroni (skype)

Please, if possible, don't  send me MS Word or PowerPoint attachments
Why? See:  http://www.gnu.org/philosophy/no-word-attachments.html



-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/attachments/20060419/c2cc1698/attachment.htm 

From sir_puding at tut.by  Thu Apr 20 16:01:20 2006
From: sir_puding at tut.by (sir_puding at tut.by)
Date: Thu, 20 Apr 2006 17:01:20 +0300
Subject: [Pw_forum] PW compilation with Threaded and MPI FFTW
Message-ID: <157275544.20060420170120@tut.by>

Hi, All.

Is it possible to use threaded and MPI version of FFTW with espresso?
Configure script produces only -lfftw link option and i think it means
that nonparallel version of FFTW is used. So, how RG space separation
(on several CPU/nodes in pool) is possible in this case?

I'm not a good programmer, so excuse me for dumb questions.


Sergey

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



From hsd22 at hermes.cam.ac.uk  Thu Apr 20 16:21:34 2006
From: hsd22 at hermes.cam.ac.uk (H.S.Domingos)
Date: Thu, 20 Apr 2006 15:21:34 +0100 (BST)
Subject: [Pw_forum] PW compilation with Threaded and MPI FFTW
In-Reply-To: <157275544.20060420170120@tut.by>
References: <157275544.20060420170120@tut.by>
Message-ID: <Pine.LNX.4.64.0604201518470.761@hermes-1.csi.cam.ac.uk>

I would also be interested to know this.

For example in the makefile e have :

DFLAGS = ...-D__FFTW -D__USE_INTERNAL_FFTW ....

and that seems to suggest that you can use threaded FFTW by changing the 
flags and giving the FFTW path.

Could  I then ask if you would kindly tell me what the right flags are ?

best regards,

Helder


=======================================================================
|  Dr. Helder S. Domingos                                             |
|                                                                     |
| INESC Microsyst & Nanotechnol, Lisbon, P-1000 Portugal              |
| and                                                                 |
| R&D unit for  Molecular Chemical Physics                            |
| Chemistry Department, University of Coimbra                         |
=======================================================================


On Thu, 20 Apr 2006, sir_puding at tut.by wrote:

> Hi, All.
>
> Is it possible to use threaded and MPI version of FFTW with espresso?
> Configure script produces only -lfftw link option and i think it means
> that nonparallel version of FFTW is used. So, how RG space separation
> (on several CPU/nodes in pool) is possible in this case?
>
> I'm not a good programmer, so excuse me for dumb questions.
>
>
> Sergey
>
> --
> Please avoid sending me Word or PowerPoint attachments.
> See http://www.gnu.org/philosophy/no-word-attachments.html
>
> _______________________________________________
> Pw_forum mailing list
> Pw_forum at pwscf.org
> http://www.democritos.it/mailman/listinfo/pw_forum
>


From ceresoli at sissa.it  Thu Apr 20 16:45:46 2006
From: ceresoli at sissa.it (Davide Ceresoli)
Date: Thu, 20 Apr 2006 16:45:46 +0200
Subject: [Pw_forum] PW compilation with Threaded and MPI FFTW
In-Reply-To: <157275544.20060420170120@tut.by>
References: <157275544.20060420170120@tut.by>
Message-ID: <44479E9A.9080909@sissa.it>

sir_puding at tut.by wrote:
> Hi, All.
> 
> Is it possible to use threaded and MPI version of FFTW with espresso?
Is not that simple as just linking a different library (libfftw_threads.a)!
The MPI and threaded version of FFTW require different subroutine calls.
See e.g.: http://www.fftw.org/fftw2_doc/fftw_4.html#SEC47

> Configure script produces only -lfftw link option and i think it means
> that nonparallel version of FFTW is used. So, how RG space separation
> (on several CPU/nodes in pool) is possible in this case?
Parallel FFT is implemented in espresso. See Modules/fft_base.f90.

Davide



From konstantin_kudin at yahoo.com  Thu Apr 20 17:36:30 2006
From: konstantin_kudin at yahoo.com (Konstantin Kudin)
Date: Thu, 20 Apr 2006 08:36:30 -0700 (PDT)
Subject: [Pw_forum] question on potential energy in constant pressure simulations
Message-ID: <20060420153630.11356.qmail@web52011.mail.yahoo.com>

 Hi all,

 I am doing the CP dynamics with one of the lattice vectors being
optimized as well.

 I am using a very recent CVS (yesterday's), which should have the
correct stress (knocking on wood).

 The parameters for the modified kinetic energy functional are:
ecutwfc = 30.0, ecfixed = 25.0, qcutz = 25.0, q2sigma = 3.0
 This is for what used to be just ecutwfc=25.0 in constant volume
simulations.

 So what I am seeing is that while the stress becomes smaller, the
potential energy of the system goes up at the same time with the
decreasing stress.

 Should not the decrease in stress correspond to the *decreasing*
potential energy? Or is there some funny business with this modified
kinetic energy functional such that I should disregard the potential
energy values and trust the stress instead ?

 Thanks!
 Kostya


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


From marzari at MIT.EDU  Thu Apr 20 17:47:50 2006
From: marzari at MIT.EDU (Nicola Marzari)
Date: Thu, 20 Apr 2006 17:47:50 +0200
Subject: [Pw_forum] question on potential energy in constant pressure
 simulations
In-Reply-To: <20060420153630.11356.qmail@web52011.mail.yahoo.com>
References: <20060420153630.11356.qmail@web52011.mail.yahoo.com>
Message-ID: <4447AD26.2050007@mit.edu>


Dear Kostya,

great that your are testing the constant-pressure cp.

There is still an unresolved issue (bug...) for ultrasoft psp, in
the diagonal terms only - that could explain your results. On the bright
side, a lot of other arcane issues (bugs) that had crept in the CVS
have been recently found  and fixed  by Carlo C. and Paolo G.

The safest first step would be to look at the numerical derivative of
the ground-state energy with respect to your variable lattice
vector - should be equal with the calculated stress
(again, if you are using psp, it will not...).



			nicola


Konstantin Kudin wrote:
>  Hi all,
> 
>  I am doing the CP dynamics with one of the lattice vectors being
> optimized as well.
> 
>  I am using a very recent CVS (yesterday's), which should have the
> correct stress (knocking on wood).
> 
>  The parameters for the modified kinetic energy functional are:
> ecutwfc = 30.0, ecfixed = 25.0, qcutz = 25.0, q2sigma = 3.0
>  This is for what used to be just ecutwfc=25.0 in constant volume
> simulations.
> 
>  So what I am seeing is that while the stress becomes smaller, the
> potential energy of the system goes up at the same time with the
> decreasing stress.
> 
>  Should not the decrease in stress correspond to the *decreasing*
> potential energy? Or is there some funny business with this modified
> kinetic energy functional such that I should disregard the potential
> energy values and trust the stress instead ?
> 
>  Thanks!
>  Kostya
> 
> 
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around 
> http://mail.yahoo.com 
> _______________________________________________
> Pw_forum mailing list
> Pw_forum at pwscf.org
> http://www.democritos.it/mailman/listinfo/pw_forum

-- 
---------------------------------------------------------------------
Prof Nicola Marzari   Department of Materials Science and Engineering
13-5066   MIT   77 Massachusetts Avenue   Cambridge MA 02139-4307 USA
tel 617.4522758 fax 2586534 marzari at mit.edu http://quasiamore.mit.edu


From konstantin_kudin at yahoo.com  Thu Apr 20 18:20:40 2006
From: konstantin_kudin at yahoo.com (Konstantin Kudin)
Date: Thu, 20 Apr 2006 09:20:40 -0700 (PDT)
Subject: [Pw_forum] question on potential energy in constant pressure simulations
In-Reply-To: <4447AD26.2050007@mit.edu>
Message-ID: <20060420162040.77487.qmail@web52002.mail.yahoo.com>

 Hi Nicola,

 Thanks for the info! I was under the impression that ALL bugs were
fixed by now, but apparently - not. I do in fact use ultra-soft PSPs,
so that would explain my results.

 An important consideration for me is that I did not intend just to
test the stress, but rather to use it for some production jobs. So
unfortunately it looks like this has to wait.

 Kostya


--- Nicola Marzari <marzari at MIT.EDU> wrote:

> 
> 
> Dear Kostya,
> 
> great that your are testing the constant-pressure cp.
> 
> There is still an unresolved issue (bug...) for ultrasoft psp, in
> the diagonal terms only - that could explain your results. On the
> bright
> side, a lot of other arcane issues (bugs) that had crept in the CVS
> have been recently found  and fixed  by Carlo C. and Paolo G.
> 
> The safest first step would be to look at the numerical derivative of
> the ground-state energy with respect to your variable lattice
> vector - should be equal with the calculated stress
> (again, if you are using psp, it will not...).
> 
> 
> 
> 			nicola
> 
> 
> Konstantin Kudin wrote:
> >  Hi all,
> > 
> >  I am doing the CP dynamics with one of the lattice vectors being
> > optimized as well.
> > 
> >  I am using a very recent CVS (yesterday's), which should have the
> > correct stress (knocking on wood).
> > 
> >  The parameters for the modified kinetic energy functional are:
> > ecutwfc = 30.0, ecfixed = 25.0, qcutz = 25.0, q2sigma = 3.0
> >  This is for what used to be just ecutwfc=25.0 in constant volume
> > simulations.
> > 
> >  So what I am seeing is that while the stress becomes smaller, the
> > potential energy of the system goes up at the same time with the
> > decreasing stress.
> > 
> >  Should not the decrease in stress correspond to the *decreasing*
> > potential energy? Or is there some funny business with this
> modified
> > kinetic energy functional such that I should disregard the
> potential
> > energy values and trust the stress instead ?
> > 
> >  Thanks!
> >  Kostya
> > 
> > 
> > __________________________________________________
> > Do You Yahoo!?
> > Tired of spam?  Yahoo! Mail has the best spam protection around 
> > http://mail.yahoo.com 
> > _______________________________________________
> > Pw_forum mailing list
> > Pw_forum at pwscf.org
> > http://www.democritos.it/mailman/listinfo/pw_forum
> 
> -- 
> ---------------------------------------------------------------------
> Prof Nicola Marzari   Department of Materials Science and Engineering
> 13-5066   MIT   77 Massachusetts Avenue   Cambridge MA 02139-4307 USA
> tel 617.4522758 fax 2586534 marzari at mit.edu http://quasiamore.mit.edu
> _______________________________________________
> Pw_forum mailing list
> Pw_forum at pwscf.org
> http://www.democritos.it/mailman/listinfo/pw_forum
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


From cesar at cuca.mda.cinvestav.mx  Thu Apr 20 20:14:20 2006
From: cesar at cuca.mda.cinvestav.mx (Cesar Alberto Cab Cauich)
Date: Thu, 20 Apr 2006 13:14:20 -0500 (CDT)
Subject: [Pw_forum] Problem with examples
Message-ID: <Pine.LNX.3.96.1060420130117.4027A-100000@cuca.mda.cinvestav.mx>

Hi espresso users, I am a new user for this code, I already Work with
siesta, and I want Know about the abilities for cp and pwscf. I compiled
the code without errors in a xeon box 3.2 GHz with intel fortran 9.0 and
mkl 8.0 using "configure" utility.
When I try to run the examples, I obtain this error for al.scf.cg.out: 






 G cutoff =   85.4897  (    869 G-vectors)     FFT grid: ( 15, 15, 15)
     
     nbndx  =     6  nbnd   =     6  natomwfc =     9  npwx   =     113
     nelec  =   3.00  nkb   =     4  ngl    =      31
     
     Initial potential from superposition of free atoms
     
     starting charge    2.99794, renormalised to    3.00000
     Starting wfc are atomic
 

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
    from cfts_3 : error #         1
     routine called by wrong architecture

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
     
     stopping ...
  



and for  al.band.cg.out:
 



 G cutoff =   85.4897  (    869 G-vectors)     FFT grid: ( 15, 15, 15)
        
     nbndx  =     8  nbnd   =     8  natomwfc =     9  npwx   =     113
     nelec  =   3.00  nkb   =     4  ngl    =      31
     Cannot read rho : file not found
        
     Initial potential from superposition of free atoms
     

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

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
        
     stopping ...






In resume, there are errors for all .out files .....
Some idea?


Greetings



Cesar Alberto Cab Cauich
PhD Student 
Departamento de Fisica Aplicada
Centro de Investigacion y Estudios Avanzados 
Merida, Mexico.





From nhviet at sissa.it  Thu Apr 20 20:12:17 2006
From: nhviet at sissa.it (Nguyen Huy Viet)
Date: Thu, 20 Apr 2006 20:12:17 +0200 (CEST)
Subject: [Pw_forum] Problem with examples
In-Reply-To: <Pine.LNX.3.96.1060420130117.4027A-100000@cuca.mda.cinvestav.mx>
References: <Pine.LNX.3.96.1060420130117.4027A-100000@cuca.mda.cinvestav.mx>
Message-ID: <Pine.LNX.4.64.0604201955200.5016@dhpc-5-14.sissa.it>

Hi,

>
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
>    from cfts_3 : error #         1
>     routine called by wrong architecture
>
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
>
>     stopping ...

It seems that there are problems with using ifc 9.0 (possibly 
with precompilation, but I am not very sure) to compile ESPRESSO.
I am using FEDORA CORE 4 and exactly the same error messages appeared.
I solve this problem by using ifc 8.1.
Hope this helps.
Regards,
Huy Viet

-- 
Huy-Viet Nguyen
PhD student in Condensed Matter Theory Sector,
International School for Advanced Studies,
via Beirut 2-4, I-34014, Trieste, Italy
Office: R 205 New Building
Phone:  +39 040 3787 492
Fax:    +39 040 3787 528
--


From stewart at cnf.cornell.edu  Thu Apr 20 20:59:33 2006
From: stewart at cnf.cornell.edu (stewart at cnf.cornell.edu)
Date: Thu, 20 Apr 2006 14:59:33 -0400
Subject: [Pw_forum] Re: Problem with examples
In-Reply-To: <Pine.LNX.3.96.1060420130117.4027A-100000@cuca.mda.cinvestav.mx>
References: <Pine.LNX.3.96.1060420130117.4027A-100000@cuca.mda.cinvestav.mx>
Message-ID: <20060420185933.22444.qmail@xuxa.iecc.com>

Hi Cesar, 

  Can you post the Make.sys file generated by configure.  This will help 
determine where the problem is.  I have been able to get the espresso 
package 3.0 to compile with ifort 9.0 and mkl 8.0 on a xeon box. 

Best regards, 

Derek 


Cesar Alberto Cab Cauich writes: 

> Hi espresso users, I am a new user for this code, I already Work with
> siesta, and I want Know about the abilities for cp and pwscf. I compiled
> the code without errors in a xeon box 3.2 GHz with intel fortran 9.0 and
> mkl 8.0 using "configure" utility.
> When I try to run the examples, I obtain this error for al.scf.cg.out:  
> 
>  
> 
>  
> 
> 
>  G cutoff =   85.4897  (    869 G-vectors)     FFT grid: ( 15, 15, 15)
>      
>      nbndx  =     6  nbnd   =     6  natomwfc =     9  npwx   =     113
>      nelec  =   3.00  nkb   =     4  ngl    =      31
>      
>      Initial potential from superposition of free atoms
>      
>      starting charge    2.99794, renormalised to    3.00000
>      Starting wfc are atomic
>   
> 
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
>     from cfts_3 : error #         1
>      routine called by wrong architecture 
> 
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
>      
>      stopping ...
>    
> 
>  
> 
> and for  al.band.cg.out:
>   
> 
>  
> 
>  G cutoff =   85.4897  (    869 G-vectors)     FFT grid: ( 15, 15, 15)
>         
>      nbndx  =     8  nbnd   =     8  natomwfc =     9  npwx   =     113
>      nelec  =   3.00  nkb   =     4  ngl    =      31
>      Cannot read rho : file not found
>         
>      Initial potential from superposition of free atoms
>       
> 
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
>      from potinit : error #         1
>      starting and expected charges differ 
> 
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
>         
>      stopping ... 
> 
>  
> 
>  
> 
> 
> In resume, there are errors for all .out files .....
> Some idea? 
> 
> 
> Greetings 
> 
>  
> 
> Cesar Alberto Cab Cauich
> PhD Student 
> Departamento de Fisica Aplicada
> Centro de Investigacion y Estudios Avanzados 
> Merida, Mexico. 
> 
>  
> 
> _______________________________________________
> Pw_forum mailing list
> Pw_forum at pwscf.org
> http://www.democritos.it/mailman/listinfo/pw_forum
 


################################
Derek Stewart, Ph. D.
Scientific Computation Associate
250 Duffield Hall
Cornell Nanoscale Facility (CNF)
Ithaca, NY 14853
stewart (at) cnf.cornell.edu
(607) 255-2856 



From konstantin_kudin at yahoo.com  Fri Apr 21 02:42:19 2006
From: konstantin_kudin at yahoo.com (Konstantin Kudin)
Date: Thu, 20 Apr 2006 17:42:19 -0700 (PDT)
Subject: [Pw_forum] Problem with Wannier function centers
In-Reply-To: <20060420185933.22444.qmail@xuxa.iecc.com>
Message-ID: <20060421004219.57870.qmail@web52014.mail.yahoo.com>

 Hi all,

 It appears that the Wannier code in CP (recent CVS) outputs the
Wannier function centers incorrectly for cells that are specified by
ibrav. The input producing strange centers for a water molecule is
here:
 https://kiev.princeton.edu/failing_example_wannier.j

 With these coordinates:
ATOMIC_POSITIONS angstrom
   O    0.99999987E+00  0.99999761E+00  0.11192157E+01
   H    0.10000039E+01  0.17655545E+01  0.52313723E+00
   H    0.99999715E+00  0.23446441E+00  0.52313869E+00

 wannier centers (fort.26) come out as :
  13.042997  11.149277  10.237439
   1.702475  -0.381710  -1.063049
   1.309338  -0.584178  -0.629999
   2.165164  -0.547665  -1.062867

 This does not make much sense ...

 Kostya

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


From liyanpcl at yahoo.com.cn  Fri Apr 21 07:58:01 2006
From: liyanpcl at yahoo.com.cn (li yan)
Date: Fri, 21 Apr 2006 13:58:01 +0800 (CST)
Subject: [Pw_forum] problems about the structure
Message-ID: <20060421055801.34307.qmail@web15608.mail.cnb.yahoo.com>

dear all,
         I'm doing the calculation about the scf CuI (P21/M). But the Sym.Ops. in the output file is not constent with that in Materials studio or Wien2k. My input file for pwscf is 
   &control
    calculation='scf',
    restart_mode='from_scratch',
    prefix='cui'
    pseudo_dir = '$PSEUDO_DIR/',
    outdir='$TMP_DIR/'
    tstress=.t.,
    tprnfor=.t.
 /
 &system
    ibrav = 14, celldm(1) =celldm(1) =6.779395,celldm(2) =1.11291986,celldm(3)=1.47949825,celldm(4)=-0.146169358,  nat=  4, ntyp= 2,
    ecutwfc=100,
/
 &electrons
    mixing_beta = 0.7
    conv_thr =  1.0d-8
 /
ATOMIC_SPECIES
 Cu  107.87  cu.cpi.UPF
 I   126.90  i.cpi.UPF
ATOMIC_POSITIONS {crystal}
 Cu    0.815700000   0.75000000   0.77970000
 Cu    0.184300000   0.25000000   0.22030000
 I    0.300400000   0.25000000   0.71340000
 I    0.699600000   0.75000000   0.28660000
K_POINTS {automatic}
8 8 6 0 0 0
EOF
and the  Sym.Ops. in the output file cui.scf.out is 2 (with inversion), while it is 4 in Materials studio or Wien2k.
  could you please tell me the reason about this difference?
  best regards.

		
---------------------------------
 ???????????????????????
-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/attachments/20060421/84265cc7/attachment.htm 

From luch001 at 126.com  Fri Apr 21 08:36:16 2006
From: luch001 at 126.com (luch001)
Date: Fri, 21 Apr 2006 14:36:16 +0800 (CST)
Subject: [Pw_forum] A question about elelectron-phonon coupli
 ng
Message-ID: <44487D60.00003A.17008@m54.126.com>

Dear all,
I use the version 2.1.5 of pwscf. When I calculate the electron-phonon coupling constant of  the LiH. I calculate 47 k points in the IBZ.The output file lambda.dat is like this:
# degauss   lambda    int alpha2F  <log w>     N(Ef)
  0.010    0.519654    0.000000    94.413    0.949231
  0.020    0.481122    0.000000    94.412    0.886274
  0.030    0.470335    0.000000    94.412    0.880906
  0.040    0.458617    0.000000    94.413    0.857064
  0.050    0.430279    0.000000    94.415    0.810680
  0.060    0.431049    0.000000    94.416    0.811986
  0.070    0.475063    0.000000    94.415    0.877232
  0.080    0.526288    0.000000    94.412    0.958069
  0.090    0.563168    0.000000    94.410    1.022181
  0.100    0.581296    0.000000    94.409    1.062365

We kown that   .  My question is why the  lambda has some value while the  int alpha2F are totally zero.
Any comments will be appreciated.
Best regards.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/attachments/20060421/a2fe22a3/attachment.htm 

From cbarreteau at cea.fr  Fri Apr 21 09:29:46 2006
From: cbarreteau at cea.fr (Cyrille Barreteau)
Date: Fri, 21 Apr 2006 09:29:46 +0200 (CEST)
Subject: [Pw_forum] SOC on surfaces: charge is wrong...
In-Reply-To: <Pine.LNX.4.58.0604181145210.11207@macul.ciencias.uchile.cl>
References: <20060414053744.17757.95638.Mailman@democritos.sissa.it>
    <Pine.LNX.4.58.0604181145210.11207@macul.ciencias.uchile.cl>
Message-ID: <60281.132.166.17.128.1145604586.squirrel@dsm-mail.saclay.cea.fr>

Dear PWscf users,

I am trying to run pw.x inlcuding spin-orbit coupling
for a Febcc(100) surface (11 layers) and I am facing some problems.
After the first iteration the code stops with the following
error:

WARNING: integrated charge=    87.50803650, expected=    88.00000000
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
     from electrons : error #         1
     charge is wrong
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

Any idea for the origin of this mistake.

I have included below the corresponding input and output files.

 thanks in advance

     Cyrille


-- 
==================================================================
Cyrille Barreteau  | phone : +33 (0)1 69 08 29 51
CEA Saclay         | fax   : +33 (0)1 69 08 84 46
DSM/DRECAM/SPCSI   | email : cyrille.barreteau at cea.fr
Batiment 462       |
91191 Gif sur Yvette Cedex  FRANCE
           ~~~~~~~~~~~~~~~~~~~~~~~~
http://www-drecam.cea.fr/spcsi/index.php
http://www-drecam.cea.fr/Images/Pisp/cbarreteau/cbarreteau_fr.html
http://www-drecam.cea.fr/Phocea/Membres/Cours/index.php
==================================================================

-------------- next part --------------
A non-text attachment was scrubbed...
Name: fe_surf_001_so_00.in
Type: application/octet-stream
Size: 1436 bytes
Desc: not available
Url : /pipermail/attachments/20060421/c91fd465/attachment.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fe_surf_001_so_00.out
Type: application/octet-stream
Size: 20915 bytes
Desc: not available
Url : /pipermail/attachments/20060421/c91fd465/attachment-0001.obj 

From ceresoli at sissa.it  Fri Apr 21 09:53:03 2006
From: ceresoli at sissa.it (Davide Ceresoli)
Date: Fri, 21 Apr 2006 09:53:03 +0200
Subject: [Pw_forum] Re: Problem with examples
In-Reply-To: <20060420185933.22444.qmail@xuxa.iecc.com>
References: <Pine.LNX.3.96.1060420130117.4027A-100000@cuca.mda.cinvestav.mx> <20060420185933.22444.qmail@xuxa.iecc.com>
Message-ID: <44488F5F.9080208@sissa.it>

stewart at cnf.cornell.edu wrote:
> Hi Cesar,
>  Can you post the Make.sys file generated by configure.  This will help 
> determine where the problem is.  I have been able to get the espresso 
> package 3.0 to compile with ifort 9.0 and mkl 8.0 on a xeon box.
> Best regards,
> Derek
Dear all,
     I run into this problem several months ago.
Even though -DFFTW is defined in the make.sys, there is a (documented) bug
in the fortran preprocessor of the 9.0 compiler, at least in some
version of it.

Look at this piece of code PW/cft3s.f90:

#if defined (__FFT_MODULE_DRV) && ( defined __AIX || defined __FFTW )
      !
      CALL cfft3ds( f, n1, n2, n3, nx1, nx2, nx3, 1, dffts%isind, dffts%iplw )
      !
#elif defined (__FFT_MODULE_DRV)
      !
      CALL cfft3d( f, n1, n2, n3, nx1, nx2, nx3, 1 )
      !
#elif defined (NOPENCILS)
      !
      CALL cft_3( f, n1, n2, n3, nx1, nx2, nx3, 2, 1 )
      !
#else
      !
      CALL cfts_3( f, n1, n2, n3, nx1, nx2, nx3, 2, 1, dffts%isind, dffts%iplw )
      !
#endif

It happens that last case (#else) always passes through the fortran
preprocessor (fpp).
Possible solutions:
1) upgrade you compiler
2) substitute /opt/intel/blahblah/bin/fpp with that from version 8.1
3) comment all lines such as CALL cfts_3(...)
HTH.

Davide



From scandolo at ictp.it  Fri Apr 21 09:52:56 2006
From: scandolo at ictp.it (Sandro Scandolo)
Date: Fri, 21 Apr 2006 09:52:56 +0200
Subject: [Pw_forum] question on potential energy in constant pressure
 simulations
In-Reply-To: <20060420162040.77487.qmail@web52002.mail.yahoo.com>
References: <20060420162040.77487.qmail@web52002.mail.yahoo.com>
Message-ID: <44488F58.6050303@ictp.it>

Dear Kostya,

an additional note on the stress tensor, perhaps trivial for you, but 
hopefully useful for other less experienced users:

the stress tensor calculated in the Q-E codes is based on the expression 
derived by Nielsen and Martin (PRL 50, 697, 1983). Nielsen and Martin's 
derivation is based on the Hellmann-Feynman theorem, and therefore 
assumes that the basis set is complete. It can be shown that the 
derivation is valid also when the basis set is not complete, as long as 
the derivative is taken in such a way that the basis set does not 
change, to first order, upon infinitesimal changes of the strain tensor.

As a consequence, you should expect the calculated stress tensor to 
coincide with the derivative of the energy with respect to the strain, 
as calculated by small finite strains, *only* if you are able to keep 
the same number of plane waves in the calculations with and without 
strain. For isotropic strains (i.e. volume changes, where V->V+dV) this 
is easily done by changing the energy cut-off by [(V+dV)/V]^2/3 . For 
anisotropic strains (i.e. for the off-diagonal elements of the stress 
tensor) it may be more tricky. This is the correct procedure for testing 
if the stress tensor is calculated correctly by the code. However, as 
you probably know, when the basis set is not complete, a better (in 
physical terms) estimate of the stress tensor is obtained by 
differentiating the total energy (or potential energy in your notation) 
calculated by keeping the wfc cut-off (ecutwfc) fixed in the finite 
difference calculation. Unfortunately this leads to discontinous 
pressure-volume  (or stress-strain) curves, as the basis set size 
changes discontinuosly upon strain changes, if the cut-off is fixed (NB: 
to be more precise, it leads to a continuous curve only if the k-point 
sampling is infinitely dense, which is never the case in practice, and 
certainly not with Gamma-point only).

The "qcutz" trick has been introduced as a partial relief of the above 
problem. By introducing a (smooth) penalty function for plane waves 
whose kinetic energy exceeds a given *fixed* cut off (ecfixed), you can 
forget about the need to keep the cut-off fixed in the construction of 
the basis set (ecutwfc), as  long as ecutwfc is above the tail of the 
smooth penalty function. All this is described in M. Bernasconi et al, 
J. Phys. Chem. Solids 56, 501 (1995). As a strightforward consequence, 
the stress tensor calculated with this trick should be much less 
sensitive to whether it is calculated at constant cut-off or at constant 
number of plane waves. Hence, Nielsen and Martin's expression, with this 
modified functional, gives you a stress tensor in much better agreement 
with the physically sounder expression obtained by keeping the cut-off 
fixed.  However, you should not expect it to coincide exactly with the 
derivative of the potential energy when the derivative is calculated by 
keeping the cut-off fixed. You should however expect it to coincide 
exactly with the derivative taken at constant number of plane waves 
(like for the stress tensor without "qcutz").

Regards,
Sandro


Konstantin Kudin wrote:

> Hi Nicola,
>
> Thanks for the info! I was under the impression that ALL bugs were
>fixed by now, but apparently - not. I do in fact use ultra-soft PSPs,
>so that would explain my results.
>
> An important consideration for me is that I did not intend just to
>test the stress, but rather to use it for some production jobs. So
>unfortunately it looks like this has to wait.
>
> Kostya
>
>
>--- Nicola Marzari <marzari at MIT.EDU> wrote:
>
>  
>
>>Dear Kostya,
>>
>>great that your are testing the constant-pressure cp.
>>
>>There is still an unresolved issue (bug...) for ultrasoft psp, in
>>the diagonal terms only - that could explain your results. On the
>>bright
>>side, a lot of other arcane issues (bugs) that had crept in the CVS
>>have been recently found  and fixed  by Carlo C. and Paolo G.
>>
>>The safest first step would be to look at the numerical derivative of
>>the ground-state energy with respect to your variable lattice
>>vector - should be equal with the calculated stress
>>(again, if you are using psp, it will not...).
>>
>>
>>
>>			nicola
>>
>>
>>Konstantin Kudin wrote:
>>    
>>
>>> Hi all,
>>>
>>> I am doing the CP dynamics with one of the lattice vectors being
>>>optimized as well.
>>>
>>> I am using a very recent CVS (yesterday's), which should have the
>>>correct stress (knocking on wood).
>>>
>>> The parameters for the modified kinetic energy functional are:
>>>ecutwfc = 30.0, ecfixed = 25.0, qcutz = 25.0, q2sigma = 3.0
>>> This is for what used to be just ecutwfc=25.0 in constant volume
>>>simulations.
>>>
>>> So what I am seeing is that while the stress becomes smaller, the
>>>potential energy of the system goes up at the same time with the
>>>decreasing stress.
>>>
>>> Should not the decrease in stress correspond to the *decreasing*
>>>potential energy? Or is there some funny business with this
>>>      
>>>
>>modified
>>    
>>
>>>kinetic energy functional such that I should disregard the
>>>      
>>>
>>potential
>>    
>>
>>>energy values and trust the stress instead ?
>>>
>>> Thanks!
>>> Kostya
>>>
>>>
>>>__________________________________________________
>>>Do You Yahoo!?
>>>Tired of spam?  Yahoo! Mail has the best spam protection around 
>>>http://mail.yahoo.com 
>>>_______________________________________________
>>>Pw_forum mailing list
>>>Pw_forum at pwscf.org
>>>http://www.democritos.it/mailman/listinfo/pw_forum
>>>      
>>>
>>-- 
>>---------------------------------------------------------------------
>>Prof Nicola Marzari   Department of Materials Science and Engineering
>>13-5066   MIT   77 Massachusetts Avenue   Cambridge MA 02139-4307 USA
>>tel 617.4522758 fax 2586534 marzari at mit.edu http://quasiamore.mit.edu
>>_______________________________________________
>>Pw_forum mailing list
>>Pw_forum at pwscf.org
>>http://www.democritos.it/mailman/listinfo/pw_forum
>>
>>    
>>
>
>
>__________________________________________________
>Do You Yahoo!?
>Tired of spam?  Yahoo! Mail has the best spam protection around 
>http://mail.yahoo.com 
>_______________________________________________
>Pw_forum mailing list
>Pw_forum at pwscf.org
>http://www.democritos.it/mailman/listinfo/pw_forum
>  
>


From marzari at MIT.EDU  Fri Apr 21 17:39:46 2006
From: marzari at MIT.EDU (Nicola Marzari)
Date: Fri, 21 Apr 2006 17:39:46 +0200
Subject: [Pw_forum] Re: Problem with Wannier function centers
In-Reply-To: <20060421150915.84822.qmail@web52014.mail.yahoo.com>
References: <20060421150915.84822.qmail@web52014.mail.yahoo.com>
Message-ID: <4448FCC2.9090709@mit.edu>


Hi Kostya,

it could be a bug, but it could also be an intrinsic issue.

The localization functional, in general, has multiple minima, of
which only one is meaningful in the chemical sense we have grown used to
(sometimes there can be more than one meaningful minimum, but that's
a longer story).

In fact, in the general wannier code (www.wannier.org) we use
projections onto trial wavefunctions to start our localization from
the basin of attraction of the minimum we want. The existence of
  "false" minima is ultimately related to the fact that Im ln <u_nk|u_m
k+b> is a multiply-valued function, and the arbitrary phases of the u_nk
that the wannier code tries to optimize can be such that there is
a 2 pi discontinuity, somewhere in the BZ, between u_nk and its
neigbours.

If you use CP/Gamma sampling (only real wavefunctions), in an orthogonal 
cell, this problem has never appeared.

In CP, if the cell is not orthogonal, and you are using more than
3 G vectors to calculate the WF center (it's a sum on a shell of
neighboring G vectors, of Im ln <psi|e(igr)|psi>), you
can still converge to a local minimum.

Yudong Wu had tested the code for all the ibrav, so the Wannier
algebra should be correct - maybe you are converging to a local
minimum.

1) avoid non-orthogonal cells in CP

2) use www.wannier.org, in combination with pwscf, as soon as it is
released (end of April).

3) use projections in CP. We'll add this in the future, but probably
not right away.


				nicola


Konstantin Kudin wrote:
>  Hi Manu & Nicola,
> 
>  The centers produced for an orthogonal cell seems to be fine (so the
> code works in generic sense), however, when the cell vectors are
> general, things do not work.
> 
>  I have peeked briefly at the part of the code that computes the
> centers [wf.f90, near line that has "write( 26" ], it appears that the
> calculation is clearly wrong if the cells are not orthogonal.
> 
>  Kostya
> 
> 
> --- Nicola Marzari <marzari at MIT.EDU> wrote:
> 
> 
>>Dear Manu,
>>
>>do you have any sense if the Wannier part still works ?
>>
>>This is your code in the CP, correct ?
>>
>>			nicola
>>
>>
>>Konstantin Kudin wrote:
>>
>>
>>> Hi all,
>>>
>>> It appears that the Wannier code in CP (recent CVS) outputs the
>>>Wannier function centers incorrectly for cells that are specified
>>
>>by
>>
>>>ibrav. The input producing strange centers for a water molecule is
>>>here:
>>> https://kiev.princeton.edu/failing_example_wannier.j
>>>
>>> With these coordinates:
>>>ATOMIC_POSITIONS angstrom
>>>   O    0.99999987E+00  0.99999761E+00  0.11192157E+01
>>>   H    0.10000039E+01  0.17655545E+01  0.52313723E+00
>>>   H    0.99999715E+00  0.23446441E+00  0.52313869E+00
>>>
>>> wannier centers (fort.26) come out as :
>>>  13.042997  11.149277  10.237439
>>>   1.702475  -0.381710  -1.063049
>>>   1.309338  -0.584178  -0.629999
>>>   2.165164  -0.547665  -1.062867
>>>
>>> This does not make much sense ...
>>>
>>> Kostya
>>>
>>>__________________________________________________
>>>Do You Yahoo!?
>>>Tired of spam?  Yahoo! Mail has the best spam protection around 
>>>http://mail.yahoo.com 
>>>_______________________________________________
>>>Pw_forum mailing list
>>>Pw_forum at pwscf.org
>>>http://www.democritos.it/mailman/listinfo/pw_forum
>>
>>-- 
>>---------------------------------------------------------------------
>>Prof Nicola Marzari   Department of Materials Science and Engineering
>>13-5066   MIT   77 Massachusetts Avenue   Cambridge MA 02139-4307 USA
>>tel 617.4522758 fax 2586534 marzari at mit.edu http://quasiamore.mit.edu
>>
> 
> 
> 
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around 
> http://mail.yahoo.com 

-- 
---------------------------------------------------------------------
Prof Nicola Marzari   Department of Materials Science and Engineering
13-5066   MIT   77 Massachusetts Avenue   Cambridge MA 02139-4307 USA
tel 617.4522758 fax 2586534 marzari at mit.edu http://quasiamore.mit.edu


From cesar at cuca.mda.cinvestav.mx  Fri Apr 21 20:48:42 2006
From: cesar at cuca.mda.cinvestav.mx (Cesar Alberto Cab Cauich)
Date: Fri, 21 Apr 2006 13:48:42 -0500 (CDT)
Subject: [Pw_forum] Re:  Problem with examples
Message-ID: <Pine.LNX.3.96.1060421133246.4906A-100000@cuca.mda.cinvestav.mx>

Thank you very much for your help, Derek, here is my make.sys:


# make.sys.  Generated from make.sys.in by configure.

# compilation rules

.SUFFIXES :
.SUFFIXES : .o .c .f .f90

.f90.o:
        $(MPIF90) $(F90FLAGS) -c $<

.f.o:
        $(F77) $(FFLAGS) -c $<

.c.o:
        $(CC) $(CFLAGS) -c $<


CC             = icc
MPICC          = icc
CFLAGS         = -O3 $(DFLAGS) $(IFLAGS)
CPP            = icc -E
CPPFLAGS       =  $(DFLAGS) $(IFLAGS)
F90            = ifort
MPIF90         = ifort
F90FLAGS       = $(FFLAGS) -nomodule -fpp $(FDFLAGS) $(IFLAGS) $(MODFLAGS)
F90FLAGS_NOOPT = $(FFLAGS_NOOPT) -nomodule -fpp $(FDFLAGS) $(IFLAGS)$(MODFLAGS)
F77            = ifort
MPIF77         = ifort
FFLAGS         = -O2 -tpp6 -assume byterecl
FFLAGS_NOOPT   = -O0 -assume byterecl
LD             = ifort
LDFLAGS        =
AR             = ar
ARFLAGS        = ruv
RANLIB         = echo
BLAS_LIBS      = -L/opt/intel/mkl/8.0.1/lib/32 -lmkl_ia32 -lguide
-lpthread
LAPACK_LIBS    = -lmkl_lapack
FFT_LIBS       =
MPI_LIBS       =
MASS_LIBS      =

# -----------------------------
# application-specific settings

# See include/defs.h.README for a list of precompilation options
# (possible arguments to -D or -U) and their meaning
DFLAGS         = -D__LINUX -D__INTEL -D__FFTW -D__USE_INTERNAL_FFTW
FDFLAGS        = $(DFLAGS)
IFLAGS         = -I../include
MODFLAGS       = -I. -I../Modules -I../PW -I../PH -I../iotk/src

LIBOBJS        = ../flib/ptools.a ../flib/flib.a ../clib/clib.a
../iotk/src/libiotk.a
# LIBS must contain the location of all needed external libraries
LIBS           = $(LAPACK_LIBS) $(BLAS_LIBS) $(FFT_LIBS) $(MPI_LIBS)
$(MASS_LIBS)
# MYLIB can be one of the following (depending on LIBS):
# blas       : compile the local copy of blas routines
# lapack     : compile the local copy of lapack routines
# blas_and_lapack : all of the above - use this for a quick test
#              or if you don't have an optimized blas/lapack library
# lapack_ibm : compile only lapack routines not present in IBM ESSL
#              use this together with IBM ESSL
# lapack_t3e : compile only lapack routines not present in T3E scilib
#              use this together with T3E scilib
# lapack_mkl : compile only lapack routines not present in Intel MKL
#              use this together with Intel MKL
MYLIB          = lapack_mkl




From stewart at cnf.cornell.edu  Fri Apr 21 20:37:35 2006
From: stewart at cnf.cornell.edu (stewart at cnf.cornell.edu)
Date: Fri, 21 Apr 2006 14:37:35 -0400
Subject: [Pw_forum] Re: Problem with examples
In-Reply-To: <Pine.LNX.3.96.1060421133246.4906A-100000@cuca.mda.cinvestav.mx>
References: <Pine.LNX.3.96.1060421133246.4906A-100000@cuca.mda.cinvestav.mx>
Message-ID: <20060421183735.18803.qmail@xuxa.iecc.com>

Hi Cesar, 

   That looks almost identical to the one that I am using to compile things. 
The only difference is that I am using the external fftw library for the FFT 
routines.  This could be the difference since I believe your crash was in 
some fft calls.  Try downloading the fftw library, compile it with the intel 
compiler, and link it in.  It should be a little faster anyway :). 

Regards, 

Derek 

 

Cesar Alberto Cab Cauich writes: 

> 
> Thank you very much for your help, Derek, here is my make.sys: 
> 
> 
> # make.sys.  Generated from make.sys.in by configure. 
> 
> # compilation rules 
> 
> .SUFFIXES :
> .SUFFIXES : .o .c .f .f90 
> 
> .f90.o:
>         $(MPIF90) $(F90FLAGS) -c $< 
> 
> .f.o:
>         $(F77) $(FFLAGS) -c $< 
> 
> .c.o:
>         $(CC) $(CFLAGS) -c $< 
> 
> 
> CC             = icc
> MPICC          = icc
> CFLAGS         = -O3 $(DFLAGS) $(IFLAGS)
> CPP            = icc -E
> CPPFLAGS       =  $(DFLAGS) $(IFLAGS)
> F90            = ifort
> MPIF90         = ifort
> F90FLAGS       = $(FFLAGS) -nomodule -fpp $(FDFLAGS) $(IFLAGS) $(MODFLAGS)
> F90FLAGS_NOOPT = $(FFLAGS_NOOPT) -nomodule -fpp $(FDFLAGS) $(IFLAGS)$(MODFLAGS)
> F77            = ifort
> MPIF77         = ifort
> FFLAGS         = -O2 -tpp6 -assume byterecl
> FFLAGS_NOOPT   = -O0 -assume byterecl
> LD             = ifort
> LDFLAGS        =
> AR             = ar
> ARFLAGS        = ruv
> RANLIB         = echo
> BLAS_LIBS      = -L/opt/intel/mkl/8.0.1/lib/32 -lmkl_ia32 -lguide
> -lpthread
> LAPACK_LIBS    = -lmkl_lapack
> FFT_LIBS       =
> MPI_LIBS       =
> MASS_LIBS      = 
> 
> # -----------------------------
> # application-specific settings 
> 
> # See include/defs.h.README for a list of precompilation options
> # (possible arguments to -D or -U) and their meaning
> DFLAGS         = -D__LINUX -D__INTEL -D__FFTW -D__USE_INTERNAL_FFTW
> FDFLAGS        = $(DFLAGS)
> IFLAGS         = -I../include
> MODFLAGS       = -I. -I../Modules -I../PW -I../PH -I../iotk/src 
> 
> LIBOBJS        = ../flib/ptools.a ../flib/flib.a ../clib/clib.a
> ../iotk/src/libiotk.a
> # LIBS must contain the location of all needed external libraries
> LIBS           = $(LAPACK_LIBS) $(BLAS_LIBS) $(FFT_LIBS) $(MPI_LIBS)
> $(MASS_LIBS)
> # MYLIB can be one of the following (depending on LIBS):
> # blas       : compile the local copy of blas routines
> # lapack     : compile the local copy of lapack routines
> # blas_and_lapack : all of the above - use this for a quick test
> #              or if you don't have an optimized blas/lapack library
> # lapack_ibm : compile only lapack routines not present in IBM ESSL
> #              use this together with IBM ESSL
> # lapack_t3e : compile only lapack routines not present in T3E scilib
> #              use this together with T3E scilib
> # lapack_mkl : compile only lapack routines not present in Intel MKL
> #              use this together with Intel MKL
> MYLIB          = lapack_mkl 
> 
> 
> _______________________________________________
> Pw_forum mailing list
> Pw_forum at pwscf.org
> http://www.democritos.it/mailman/listinfo/pw_forum
 


################################
Derek Stewart, Ph. D.
Scientific Computation Associate
250 Duffield Hall
Cornell Nanoscale Facility (CNF)
Ithaca, NY 14853
stewart (at) cnf.cornell.edu
(607) 255-2856 



From giannozz at nest.sns.it  Sun Apr 23 22:50:35 2006
From: giannozz at nest.sns.it (Paolo Giannozzi)
Date: Sun, 23 Apr 2006 22:50:35 +0200
Subject: [Pw_forum] building espresso-3.0 with g95?
In-Reply-To: <m31wvyqyeq.fsf@netmaster.kds.com.ua>
References: <m31wvyqyeq.fsf@netmaster.kds.com.ua>
Message-ID: <200604232250.35947.giannozz@nest.sns.it>

On Sunday 16 April 2006 00:14, Andrey Khavryuchenko wrote:

> g95 -O3 -cpp -D__LINUX -D__G95 -D__FFTW -I../include  -I. -I../Modules
> -I../PW -I../PH -I../iotk/src -c ptoolkit.f90 ptoolkit.f90:0: internal
> compiler error: Segmentation fault 
> Please submit a full bug report, with preprocessed source if appropriate.
> See http://www.g95.org or mail andyv at firstinter.net for instructions.

> Are there any success stories with g95?

I tried several different versions of g95 in the past (for instance:
G95 (GCC 4.0.1 (g95!) Dec 14 2005) with success. Please do what
the message says: submit a bug report to the author of g95

Paolo
-- 
Paolo Giannozzi             e-mail:  giannozz at nest.sns.it
Scuola Normale Superiore    Phone:   +39/050-509876, Fax:-563513 
Piazza dei Cavalieri 7      I-56126 Pisa, Italy


From konstantin_kudin at yahoo.com  Mon Apr 24 02:34:37 2006
From: konstantin_kudin at yahoo.com (Konstantin Kudin)
Date: Sun, 23 Apr 2006 17:34:37 -0700 (PDT)
Subject: [Pw_forum] still wrong stress in CP [was: question on potential energy in constant pressure simulations]
In-Reply-To: <4447AD26.2050007@mit.edu>
Message-ID: <20060424003437.25438.qmail@web52004.mail.yahoo.com>

--- Nicola Marzari <marzari at MIT.EDU> wrote:

> There is still an unresolved issue (bug...) for ultrasoft psp, in
> the diagonal terms only - that could explain your results. On the
> bright
> side, a lot of other arcane issues (bugs) that had crept in the CVS
> have been recently found  and fixed  by Carlo C. and Paolo G.

 I have tried the recent CVS with CP and PWSCF and ultrasoft psp's, and
indeed, while the forces and the off-diagonal stress terms seem to
match quite well, the diagonal stress elements are wrong. CG's stress
evaluation goes through the standard CP stuff, correct?

 Another interesting thing is that trajectory files *.cel and *.str
have the 3x3 components transposed compared to the input, such each
lattice vector goes vertically, not horizontally. Is there any reason
for this?

 Kostya

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


From caohui1209 at yahoo.com.cn  Tue Apr 25 04:59:34 2006
From: caohui1209 at yahoo.com.cn (=?gb2312?q?=BB=D4=20=B2=DC?=)
Date: Tue, 25 Apr 2006 10:59:34 +0800 (CST)
Subject: [Pw_forum] problems with running example
Message-ID: <20060425025934.28499.qmail@web15702.mail.cnb.yahoo.com>

Dear all:
  I've installed espresso-2.1.5 and the whole processure seemed to be successful, including configuration and "make pwall". When I ran example01,
  it also seemed to be normal. However, the .out files in the result directory were unexpected.  The .out files end with " from cfts_3: error #   1; routine called by wrong architecture". It stopped with the k-point list and did not give out the band-energy. 
  I chose icc and ifort as c- and fortran- compiler. My libs are lapack and blas. I installed  espresso in a parallel system but I did not use mpic and mpif90. 
   
  Thank you.
   

		
---------------------------------
 ??1G???????????
 ????-?????????  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/attachments/20060425/3337c289/attachment.htm 

From akhavr at gmail.com  Tue Apr 25 20:36:42 2006
From: akhavr at gmail.com (Andrey Khavryuchenko)
Date: Tue, 25 Apr 2006 21:36:42 +0300
Subject: [Pw_forum] Re: building espresso-3.0 with g95?
In-Reply-To: <200604232250.35947.giannozz@nest.sns.it> (Paolo Giannozzi's
 message of "Sun, 23 Apr 2006 22:50:35 +0200")
References: <m31wvyqyeq.fsf@netmaster.kds.com.ua>
	<200604232250.35947.giannozz@nest.sns.it>
Message-ID: <m3odypbiyt.fsf@netmaster.kds.com.ua>

Paolo,

Thanks for your email.

"PG" == Paolo Giannozzi wrote:

 PG> On Sunday 16 April 2006 00:14, Andrey Khavryuchenko wrote:
 >> g95 -O3 -cpp -D__LINUX -D__G95 -D__FFTW -I../include  -I. -I../Modules
 >> -I../PW -I../PH -I../iotk/src -c ptoolkit.f90 ptoolkit.f90:0: internal
 >> compiler error: Segmentation fault 
 >> Please submit a full bug report, with preprocessed source if appropriate.
 >> See http://www.g95.org or mail andyv at firstinter.net for instructions.

 >> Are there any success stories with g95?

 PG> I tried several different versions of g95 in the past (for instance:
 PG> G95 (GCC 4.0.1 (g95!) Dec 14 2005) with success. Please do what
 PG> the message says: submit a bug report to the author of g95

Before reporting the bug, I've updated my g95 installation to the most
recent binary available:

akhavr at t30 ~/src/espresso-3.0 $ g95 --version
G95 (GCC 4.0.3 (g95!) Apr 25 2006)
Copyright (C) 2002-2005 Free Software Foundation, Inc.


Now I fail at cell_base.f90 compilation:

g95 -O3 -cpp -D__LINUX -D__G95 -D__FFTW -I../include  -I. -I../Modules -I../PW -I../PH -I../iotk/src -c cell_base.f90
In file cell_base.f90:75

        REAL(DP) :: at(3,3) = RESHAPE( (/ 0.0d0 /), (/ 3, 3 /), (/ 0.0d0 /) )
                                     1
Error: Array assignment at (1) has different shape on dimension 1 (3/9)
In file cell_base.f90:76

        REAL(DP) :: bg(3,3) = RESHAPE( (/ 0.0d0 /), (/ 3, 3 /), (/ 0.0d0 /) )
                                     1
Error: Array assignment at (1) has different shape on dimension 1 (3/9)
In file cell_base.f90:521

        celldm(1) = SQRT( at(1,1)**2 + at(1,2)**2 + at(1,3)**2 )
                            1
Error: Unexpected array reference at (1)
...
(so on for other 'at' references)


-- 
Andrey V Khavryuchenko            http://www.kds.com.ua/
Silver Bullet Software Solutions  http://www.livejournal.com/~akhavr


From giannozz at nest.sns.it  Tue Apr 25 21:15:53 2006
From: giannozz at nest.sns.it (Paolo Giannozzi)
Date: Tue, 25 Apr 2006 21:15:53 +0200
Subject: [Pw_forum] problems with running example
In-Reply-To: <20060425025934.28499.qmail@web15702.mail.cnb.yahoo.com>
References: <20060425025934.28499.qmail@web15702.mail.cnb.yahoo.com>
Message-ID: <200604252115.53012.giannozz@nest.sns.it>

On Tuesday 25 April 2006 04:59, ? ? wrote:

> " from cfts_3: error # 1; routine called by wrong architecture".

this is a known problem of some compilers. Please see the message
by Davide Ceresoli (just 4 day old):
http://www.democritos.it/pipermail/pw_forum/2006-April/004011.html
-- 
Paolo Giannozzi             e-mail:  giannozz at nest.sns.it
Scuola Normale Superiore    Phone:   +39/050-509876, Fax:-563513 
Piazza dei Cavalieri 7      I-56126 Pisa, Italy


From giannozz at nest.sns.it  Tue Apr 25 22:01:38 2006
From: giannozz at nest.sns.it (Paolo Giannozzi)
Date: Tue, 25 Apr 2006 22:01:38 +0200
Subject: [Pw_forum] problems about the structure
In-Reply-To: <20060421055801.34307.qmail@web15608.mail.cnb.yahoo.com>
References: <20060421055801.34307.qmail@web15608.mail.cnb.yahoo.com>
Message-ID: <200604252201.38594.giannozz@nest.sns.it>

On Friday 21 April 2006 07:58, li yan wrote:

> I'm doing the calculation about the scf CuI (P21/M). But the Sym.Ops.
> in the output file is not constent with that in Materials studio or Wien2k.
> [...] the Sym.Ops. in the output file cui.scf.out is 2 (with inversion),
> while it is 4 in Materials studio or Wien2k. could you please tell me the
> reason about this difference?

this question has been asked no less than 1001 times and it is 
answered in detail in the documentation. See for instance
http://www.pwscf.org/guide/3.0/html-node/node60.html
-- 
Paolo Giannozzi             e-mail:  giannozz at nest.sns.it
Scuola Normale Superiore    Phone:   +39/050-509876, Fax:-563513 
Piazza dei Cavalieri 7      I-56126 Pisa, Italy


From konstantin_kudin at yahoo.com  Wed Apr 26 05:34:42 2006
From: konstantin_kudin at yahoo.com (Konstantin Kudin)
Date: Tue, 25 Apr 2006 20:34:42 -0700 (PDT)
Subject: [Pw_forum] still wrong stress in CP - update
In-Reply-To: <20060424003437.25438.qmail@web52004.mail.yahoo.com>
Message-ID: <20060426033442.21066.qmail@web52010.mail.yahoo.com>

 OK, I went through some of the older CVS versions of CP with an H2O
that had ultra-soft potentials.

 The stress appears to be correct in the CP version from Feb. 11, 2003
(V1), I base this conclusion on a loose comparison with recent PW
results.

 The other version I tried is from Apr. 3, 2004 (V2), and there the
stress is different. This version appears to get the same results as
the recent CVS.

 Comparing the components of the stress from V1 and V2 I get the main
differences in de(ps). The difference is in the 3rd significant digit,
and seems to come from drhotmp. This is the main contribution to the
differences in de(tot).

 Kostya

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


From giannozz at nest.sns.it  Wed Apr 26 12:24:06 2006
From: giannozz at nest.sns.it (Paolo Giannozzi)
Date: Wed, 26 Apr 2006 12:24:06 +0200
Subject: [Pw_forum] Error in polarization calculations
In-Reply-To: <443E680A.000003.05003@mfront8.yandex.ru>
References: <443E680A.000003.05003@mfront8.yandex.ru>
Message-ID: <200604261224.06205.giannozz@nest.sns.it>

On Thursday 13 April 2006 17:02, Sergey Lisenkov wrote:

>   During Berry Phase calculations (3.0 version), I got the error:

>  from  ylm_q : error #  12915072 
>  not programmed for L

>  I use RRKJUS pseudopotentials and one pseudo from opium.
>  What is wrong? 

hard to say with so little information ...
-- 
Paolo Giannozzi             e-mail:  giannozz at nest.sns.it
Scuola Normale Superiore    Phone:   +39/050-509876, Fax:-563513 
Piazza dei Cavalieri 7      I-56126 Pisa, Italy


From giannozz at nest.sns.it  Wed Apr 26 13:41:10 2006
From: giannozz at nest.sns.it (Paolo Giannozzi)
Date: Wed, 26 Apr 2006 13:41:10 +0200
Subject: [Pw_forum] A question about elelectron-phonon coupli ng
In-Reply-To: <44487D60.00003A.17008@m54.126.com>
References: <44487D60.00003A.17008@m54.126.com>
Message-ID: <200604261341.10095.giannozz@nest.sns.it>

On Friday 21 April 2006 08:36, luch001 wrote:

> I use the version 2.1.5 of pwscf. When I calculate the electron-phonon
> coupling constant of  the LiH. I calculate 47 k points in the IBZ.The
> output file lambda.dat is like this:
> [...] 
> My question is why the  lambda has some value while the  
> int alpha2F are totally zero. Any comments will be appreciated.

with so little information available it is hard to offer any meaningful
comment. Please look inside the lambda.f90 code: it is trivial and 
to check what is happening there.
-- 
Paolo Giannozzi             e-mail:  giannozz at nest.sns.it
Scuola Normale Superiore    Phone:   +39/050-509876, Fax:-563513 
Piazza dei Cavalieri 7      I-56126 Pisa, Italy


From ezadshojaee at hotmail.com  Wed Apr 26 14:52:21 2006
From: ezadshojaee at hotmail.com (Ezad Shojaee)
Date: Wed, 26 Apr 2006 12:52:21 +0000
Subject: [Pw_forum] a question about relaxing
Message-ID: <BAY19-F123B395CFA899699BB767BAABC0@phx.gbl>

hi
i want to relax a structure like TiO2 and when i set the parameter " dt " 
greater than about  " 1 " , i get this message :

from checkallsym : error #     5
not orthogonal operation

i wander if anyone knows the exact role of the " dt " parameter & the 
meaning of the error ?
thanks

_________________________________________________________________
Don't just search. Find. Check out the new MSN Search! 
http://search.msn.click-url.com/go/onm00200636ave/direct/01/



From degironc at sissa.it  Wed Apr 26 14:54:49 2006
From: degironc at sissa.it (degironc)
Date: Wed, 26 Apr 2006 14:54:49 +0200
Subject: [Pw_forum] a question about relaxing
In-Reply-To: <BAY19-F123B395CFA899699BB767BAABC0@phx.gbl>
References: <BAY19-F123B395CFA899699BB767BAABC0@phx.gbl>
Message-ID: <444F6D99.205@sissa.it>

What kind of relaxation are you performing ?
Notice that Parrinello-Rahman damped dynamics in general does not 
preserve symmetry while
Wentzovitch damped dynamics does.
  stefano


Ezad Shojaee wrote:

> hi
> i want to relax a structure like TiO2 and when i set the parameter " 
> dt " greater than about  " 1 " , i get this message :
>
> from checkallsym : error #     5
> not orthogonal operation
>
> i wander if anyone knows the exact role of the " dt " parameter & the 
> meaning of the error ?
> thanks
>
> _________________________________________________________________
> Don't just search. Find. Check out the new MSN Search! 
> http://search.msn.click-url.com/go/onm00200636ave/direct/01/
>
> _______________________________________________
> Pw_forum mailing list
> Pw_forum at pwscf.org
> http://www.democritos.it/mailman/listinfo/pw_forum





From ezadshojaee at hotmail.com  Wed Apr 26 15:00:38 2006
From: ezadshojaee at hotmail.com (Ezad Shojaee)
Date: Wed, 26 Apr 2006 13:00:38 +0000
Subject: [Pw_forum] about vc-relax
Message-ID: <BAY19-F14B01944F0C3EE54ECE37CAABC0@phx.gbl>

hi
i want to do a vc-relax for TiO2 and when i set the parameter " dt " greater 
than about  " 1 " , i get this message :

from checkallsym : error #     5
not orthogonal operation

i wander if anyone knows the exact role of the " dt " parameter & the 
meaning of the error ?
thanks

_________________________________________________________________
Don't just search. Find. Check out the new MSN Search! 
http://search.msn.click-url.com/go/onm00200636ave/direct/01/



From ezadshojaee at hotmail.com  Wed Apr 26 15:10:50 2006
From: ezadshojaee at hotmail.com (Ezad Shojaee)
Date: Wed, 26 Apr 2006 13:10:50 +0000
Subject: [Pw_forum] (no subject)
Message-ID: <BAY19-F1018C87F9B8C0C7619F12CAABC0@phx.gbl>

i am doing vc-relax with these characters:
cell_dynamics='damp_w'
ion_dynamics='damp'

_________________________________________________________________
FREE pop-up blocking with the new MSN Toolbar - get it now! 
http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/



From giannozz at nest.sns.it  Wed Apr 26 17:15:21 2006
From: giannozz at nest.sns.it (Paolo Giannozzi)
Date: Wed, 26 Apr 2006 17:15:21 +0200
Subject: [Pw_forum] Re: building espresso-3.0 with g95?
In-Reply-To: <m3odypbiyt.fsf@netmaster.kds.com.ua>
References: <m31wvyqyeq.fsf@netmaster.kds.com.ua> <200604232250.35947.giannozz@nest.sns.it> <m3odypbiyt.fsf@netmaster.kds.com.ua>
Message-ID: <200604261715.21972.giannozz@nest.sns.it>

On Tuesday 25 April 2006 20:36, Andrey Khavryuchenko wrote:

> I've updated my g95 installation to the most recent binary available:
>
> akhavr at t30 ~/src/espresso-3.0 $ g95 --version
> G95 (GCC 4.0.3 (g95!) Apr 25 2006)
> Copyright (C) 2002-2005 Free Software Foundation, Inc.
>
> Now I fail at cell_base.f90 compilation:

I did the same and it works for me

Paolo
-- 
Paolo Giannozzi             e-mail:  giannozz at nest.sns.it
Scuola Normale Superiore    Phone:   +39/050-509876, Fax:-563513 
Piazza dei Cavalieri 7      I-56126 Pisa, Italy


From giannozz at nest.sns.it  Wed Apr 26 17:18:57 2006
From: giannozz at nest.sns.it (Paolo Giannozzi)
Date: Wed, 26 Apr 2006 17:18:57 +0200
Subject: [Pw_forum] pw.x always crashes at the end of relax calculations
In-Reply-To: <001a01c662e9$54d27ae0$0ee35ba5@ch0316>
References: <001a01c662e9$54d27ae0$0ee35ba5@ch0316>
Message-ID: <200604261718.57613.giannozz@nest.sns.it>

On Tuesday 18 April 2006 15:09, Eduardo J. Lamas wrote:

> Hi, pw.x always crashes to me during the last check of the relax
> calculations. it happened in versions 2.1.3 and 3.0 and with different
> compilers.  [..] 
> I am wondering [..] if somebody else was having the same problem. 

never heard before. I tried your job (with a smaller cutoff) 
and it works for me. If the problem is as reproducible as you 
claim it is, you should be able to locate where it crashes and why

Paolo
-- 
Paolo Giannozzi             e-mail:  giannozz at nest.sns.it
Scuola Normale Superiore    Phone:   +39/050-509876, Fax:-563513 
Piazza dei Cavalieri 7      I-56126 Pisa, Italy


From giannozz at nest.sns.it  Wed Apr 26 17:31:49 2006
From: giannozz at nest.sns.it (Paolo Giannozzi)
Date: Wed, 26 Apr 2006 17:31:49 +0200
Subject: [Pw_forum] Re: Re: error while parallel running
In-Reply-To: <2b80d0af0604152347l79575a50h86264cfae33b6dd3@mail.gmail.com>
References: <2b80d0af0604152347l79575a50h86264cfae33b6dd3@mail.gmail.com>
Message-ID: <200604261731.49923.giannozz@nest.sns.it>

On Sunday 16 April 2006 08:47, Lin Zhuang wrote:

> I had succesfully run the input file with serial version pw.x and
> parallel version pw.x if only one CPU had been specified, i.e.,
>  $ mpirun c0 pw.x -in inputfile > outputfile
> But when I tried to run the same input file with more than one 
> CPU  [...] I got error like 
> from read_namelists : error #    17
>   reading namelist control

mis-configured MPI libraries may have strange ideas of what the 
current directory is. Try to provide an explicit path to the file 
containing the input data.
-- 
Paolo Giannozzi             e-mail:  giannozz at nest.sns.it
Scuola Normale Superiore    Phone:   +39/050-509876, Fax:-563513 
Piazza dei Cavalieri 7      I-56126 Pisa, Italy


From giannozz at nest.sns.it  Wed Apr 26 18:04:14 2006
From: giannozz at nest.sns.it (Paolo Giannozzi)
Date: Wed, 26 Apr 2006 18:04:14 +0200
Subject: [Pw_forum] Phonon frequencies different for equivalent q points
In-Reply-To: <20060411184542.11682.qmail@xuxa.iecc.com>
References: <443BD1B3.6090200@ictp.it> <20060411184542.11682.qmail@xuxa.iecc.com>
Message-ID: <200604261804.14603.giannozz@nest.sns.it>

On Tuesday 11 April 2006 20:45, stewart at cnf.cornell.edu wrote:

> I am looking at the high symmetry lines, Gamma-K-M along the [x,x,0]
> direction going from [0,0,0] to [1,1,0]*(2pi/a) and the Gamma-M line
> along the [x,0,0] going from [0,0,0] to [1/sqrt(3),0,0]*(2pi/a).

are you sure these are the correct high-symmetry lines? please note
that phonon wavevectors must be supplied in cartesian coordinates

Paolo
-- 
Paolo Giannozzi             e-mail:  giannozz at nest.sns.it
Scuola Normale Superiore    Phone:   +39/050-509876, Fax:-563513 
Piazza dei Cavalieri 7      I-56126 Pisa, Italy


From naromero at gmail.com  Wed Apr 26 18:41:39 2006
From: naromero at gmail.com (Nichols A. Romero)
Date: Wed, 26 Apr 2006 12:41:39 -0400
Subject: [Pw_forum] parallel scaling in PWSCF
Message-ID: <6ac064b60604260941u15471f47oe6d45fee2ff6ce8@mail.gmail.com>

Hi,

Has anyone performed any very-large scale DFT calculations on PWSCF
using over 64 processors and over 1000 atoms? Does anyone know what
its current limits (system sizes and processors) are on parallel
computing environments with fast interconnects?

Thanks,
--
Nichols A. Romero, Ph.D.
1613 Denise Dr. Apt. D
Forest Hill, MD 21050
443-567-8328 (C)
410-306-0709 (O)


From akohlmey at cmm.upenn.edu  Wed Apr 26 19:38:31 2006
From: akohlmey at cmm.upenn.edu (Axel Kohlmeyer)
Date: Wed, 26 Apr 2006 13:38:31 -0400
Subject: [Pw_forum] parallel scaling in PWSCF
In-Reply-To: <6ac064b60604260941u15471f47oe6d45fee2ff6ce8@mail.gmail.com>
References: <6ac064b60604260941u15471f47oe6d45fee2ff6ce8@mail.gmail.com>
Message-ID: <7b6913e90604261038t25d0bb43le5c8a740e793d981@mail.gmail.com>

On 4/26/06, Nichols A. Romero <naromero at gmail.com> wrote:
> Hi,

hi.

> Has anyone performed any very-large scale DFT calculations on PWSCF
> using over 64 processors and over 1000 atoms? Does anyone know what
> its current limits (system sizes and processors) are on parallel
> computing environments with fast interconnects?

i've recently run a comparatively large job (272 atoms, 560 electrons,
4x4x4 k-points) across 768 processors on a Cray XT3. i had to hack
some constants to make it work. however the scaling is not (yet)
so good and depending on what kind of atoms you want to put into
your system, i.e. if it is metallic, you may be better of with gamma
only and car-parrinello dynamics. i ran the same system as above
with a car-parrinello code (one that is not in quantum espresso) and
would scale out at 512 nodes for gamma point only on an IBM BG/L.
even though i had to use a much smaller time step, i did get much
more trajectory that way.

judging from the CVS commit messages, efforts to optimize the
quantum espresso codes for that kind of machine with large numbers
of nodes are underway. note, that for systems as large as that,
you might run into the scaling limitations of DFT with plane waves,
so for a system that big using one of those 'linear scaling' DFT codes
could be a more promising alternative.

best regards,
     axel.


>
> Thanks,
> --
> Nichols A. Romero, Ph.D.
> 1613 Denise Dr. Apt. D
> Forest Hill, MD 21050
> 443-567-8328 (C)
> 410-306-0709 (O)
> _______________________________________________
> Pw_forum mailing list
> Pw_forum at pwscf.org
> http://www.democritos.it/mailman/listinfo/pw_forum
>
>


--
=======================================================================
Axel Kohlmeyer   akohlmey at cmm.chem.upenn.edu   http://www.cmm.upenn.edu
  Center for Molecular Modeling   --   University of Pennsylvania
Department of Chemistry, 231 S.34th Street, Philadelphia, PA 19104-6323
tel: 1-215-898-1582,  fax: 1-215-573-6233,  office-tel: 1-215-898-5425
=======================================================================
If you make something idiot-proof, the universe creates a better idiot.


From afloris at physik.fu-berlin.de  Wed Apr 26 19:51:48 2006
From: afloris at physik.fu-berlin.de (Andrea Floris)
Date: Wed, 26 Apr 2006 19:51:48 +0200 (CEST)
Subject: [Pw_forum] fhi98PP lloc
Message-ID: <Pine.LNX.4.58.0604261933400.30613@g34.physik.fu-berlin.de>

Hi everybody,
I generated a NCPP with fhi98PP for Ca with semicore states in the
valence, with lmax=lloc=2 (variables values in fhi98PP).
In the UPF conversion it results  (correctly, because of the
Kleinman-Bylander form) that:

Max angular momentum component = 1
Number of Projectors           = 2
Wavefunctions          nl  l   occ
                       3S  0  2.00
                       3P  1  6.00
                       3D  2  0.00

Moreover the <PP_LOCAL>  field is the correct conversion of the local
pseudo that I've chosen in the generation.

Question: in the output of pwscf for Ca results lloc=0. I do not
understand this, I was expecting lloc=2...
Does it have any wrong consequence? I
plotted my bands
and they seems reasonable compared with all electron bands.

thanks in advance for any explanation,
Andrea



>> In the .UPF pseudopotential my "Max angular momentum component"
>> in <<PP_HEADER>> is 1 instead of 2.

>correct: the UPF file contains PPs in separable (Kleinman-Bylander)
>form, so you have l=0 and l=1 projectors, l=2 as the local potential.

>P.


From giannozz at nest.sns.it  Wed Apr 26 20:41:20 2006
From: giannozz at nest.sns.it (Paolo Giannozzi)
Date: Wed, 26 Apr 2006 20:41:20 +0200
Subject: [Pw_forum] fhi98PP lloc
In-Reply-To: <Pine.LNX.4.58.0604261933400.30613@g34.physik.fu-berlin.de>
References: <Pine.LNX.4.58.0604261933400.30613@g34.physik.fu-berlin.de>
Message-ID: <200604262041.20651.giannozz@nest.sns.it>

On Wednesday 26 April 2006 19:51, Andrea Floris wrote:

> Question: in the output of pwscf for Ca results lloc=0.
> I do not understand this, I was expecting lloc=2...

I am afraid that the printed value for lloc does not correspond
to anything sensible, except for obsolete pseudopotential
formats ... 

Paolo
-- 
Paolo Giannozzi             e-mail:  giannozz at nest.sns.it
Scuola Normale Superiore    Phone:   +39/050-509876, Fax:-563513 
Piazza dei Cavalieri 7      I-56126 Pisa, Italy


From giannozz at nest.sns.it  Wed Apr 26 20:40:00 2006
From: giannozz at nest.sns.it (Paolo Giannozzi)
Date: Wed, 26 Apr 2006 20:40:00 +0200
Subject: [Pw_forum] fhi98PP lloc
In-Reply-To: <Pine.LNX.4.58.0604261933400.30613@g34.physik.fu-berlin.de>
References: <Pine.LNX.4.58.0604261933400.30613@g34.physik.fu-berlin.de>
Message-ID: <200604262040.00067.giannozz@nest.sns.it>

On Wednesday 26 April 2006 19:51, Andrea Floris wrote:

> Question: in the output of pwscf for Ca results lloc=0.
> I do not understand this, I was expecting lloc=2...

I am afraid that the printed value for lloc does not correspond
to anything sensible, except for obsolete pseudopotential
formats ... 

Paolo
-- 
Paolo Giannozzi             e-mail:  giannozz at nest.sns.it
Scuola Normale Superiore    Phone:   +39/050-509876, Fax:-563513 
Piazza dei Cavalieri 7      I-56126 Pisa, Italy


From reboredofa at ornl.gov  Wed Apr 26 21:16:16 2006
From: reboredofa at ornl.gov (Fernando A Reboredo)
Date: Wed, 26 Apr 2006 15:16:16 -0400
Subject: [Pw_forum] parallel scaling in PWSCF
References: <6ac064b60604260941u15471f47oe6d45fee2ff6ce8@mail.gmail.com>
 <7b6913e90604261038t25d0bb43le5c8a740e793d981@mail.gmail.com>
Message-ID: <003b01c66965$e4178d80$fcc2db80@ornl.gov>

Nichols
The largest things I have run with pwscf are cobalt clusters with stuff on 
the surface
55 Co atoms 12 CO molecules and 12au of vacuum around, 45 Ry ecut.
~560 electron including spin and PBE. Those calculation run in 48 nodes 90 
processors. I did not study the scaling carefully. The scaling was 
reasonably good provided the number of proccessors was a submultiple of the 
FFT grid dimension.
 Fernando Reboredo

----- Original Message ----- 
From: "Axel Kohlmeyer" <akohlmey at cmm.upenn.edu>
To: <pw_forum at pwscf.org>
Sent: Wednesday, April 26, 2006 1:38 PM
Subject: Re: [Pw_forum] parallel scaling in PWSCF


On 4/26/06, Nichols A. Romero <naromero at gmail.com> wrote:
> Hi,

hi.

> Has anyone performed any very-large scale DFT calculations on PWSCF
> using over 64 processors and over 1000 atoms? Does anyone know what
> its current limits (system sizes and processors) are on parallel
> computing environments with fast interconnects?

i've recently run a comparatively large job (272 atoms, 560 electrons,
4x4x4 k-points) across 768 processors on a Cray XT3. i had to hack
some constants to make it work. however the scaling is not (yet)
so good and depending on what kind of atoms you want to put into
your system, i.e. if it is metallic, you may be better of with gamma
only and car-parrinello dynamics. i ran the same system as above
with a car-parrinello code (one that is not in quantum espresso) and
would scale out at 512 nodes for gamma point only on an IBM BG/L.
even though i had to use a much smaller time step, i did get much
more trajectory that way.

judging from the CVS commit messages, efforts to optimize the
quantum espresso codes for that kind of machine with large numbers
of nodes are underway. note, that for systems as large as that,
you might run into the scaling limitations of DFT with plane waves,
so for a system that big using one of those 'linear scaling' DFT codes
could be a more promising alternative.

best regards,
     axel.


>
> Thanks,
> --
> Nichols A. Romero, Ph.D.
> 1613 Denise Dr. Apt. D
> Forest Hill, MD 21050
> 443-567-8328 (C)
> 410-306-0709 (O)
> _______________________________________________
> Pw_forum mailing list
> Pw_forum at pwscf.org
> http://www.democritos.it/mailman/listinfo/pw_forum
>
>


--
=======================================================================
Axel Kohlmeyer   akohlmey at cmm.chem.upenn.edu   http://www.cmm.upenn.edu
  Center for Molecular Modeling   --   University of Pennsylvania
Department of Chemistry, 231 S.34th Street, Philadelphia, PA 19104-6323
tel: 1-215-898-1582,  fax: 1-215-573-6233,  office-tel: 1-215-898-5425
=======================================================================
If you make something idiot-proof, the universe creates a better idiot.
_______________________________________________
Pw_forum mailing list
Pw_forum at pwscf.org
http://www.democritos.it/mailman/listinfo/pw_forum 



From ferretti.andrea at unimore.it  Wed Apr 26 22:28:21 2006
From: ferretti.andrea at unimore.it (Andrea Ferretti)
Date: Wed, 26 Apr 2006 22:28:21 +0200 (CEST)
Subject: [Pw_forum] parallel scaling in PWSCF
In-Reply-To: <003b01c66965$e4178d80$fcc2db80@ornl.gov>
References: <6ac064b60604260941u15471f47oe6d45fee2ff6ce8@mail.gmail.com>
 <7b6913e90604261038t25d0bb43le5c8a740e793d981@mail.gmail.com>
 <003b01c66965$e4178d80$fcc2db80@ornl.gov>
Message-ID: <Pine.LNX.4.58.0604262209040.5061@bamboo.fisica.unimo.it>


Hi everybody,

I am currently running a Copper surface with 140 Cu atoms + a molecule...
the system has 1642 electrons and (due to metallicity) the calculation is 
performed for 985 bands (few kpt, like 4)...
due to the 11 electrons for each Cu atom, I have a huge number of bands in 
a (relatively) small cell, and so a (relatively) low number of PWs respect 
to nbnd.
taking a look at the dimension of wfc, no problem with memory in 
principle, even if, due to the weird 
dimensions of the system, non-scalable memory is quite large, around 1Gb.

on a IBM Sp5 machine I observed a severe limit in the scaling passing from 
32 to 64 procs using both espresso 2.1.x and espresso 3.0...
( anyway, I succeeded in performing a "relax" calculation for the system 
!!!! )

as far as I know, this problem might be connected to a serial part in the 
diagonalization which has been parallelized in the current CVS version 
(as already pointed out by Axel)...
At the moment I am testing this CVS version against my system, I will let 
you know the results as soon as possible...

cheers
andrea  


-- 
Andrea Ferretti
Dipartimento di Fisica, Universita' di Modena e Reggio Emilia
Natl. Res. Center S3 INFM-CNR  ( http://s3.infm.it )
Via Campi 213/A I-41100 Modena, Italy
Tel:     +39 059 2055283
Fax:     +39 059 374794
E-mail:  ferretti.andrea at unimore.it
URL:     http://www.nanoscience.unimo.it

Please, if possible, don't  send me MS Word or PowerPoint attachments
Why? See:  http://www.gnu.org/philosophy/no-word-attachments.html


On Wed, 26 Apr 2006, Fernando A Reboredo wrote:

> Nichols
> The largest things I have run with pwscf are cobalt clusters with stuff on 
> the surface
> 55 Co atoms 12 CO molecules and 12au of vacuum around, 45 Ry ecut.
> ~560 electron including spin and PBE. Those calculation run in 48 nodes 90 
> processors. I did not study the scaling carefully. The scaling was 
> reasonably good provided the number of proccessors was a submultiple of the 
> FFT grid dimension.
>  Fernando Reboredo
> 
> ----- Original Message ----- 
> From: "Axel Kohlmeyer" <akohlmey at cmm.upenn.edu>
> To: <pw_forum at pwscf.org>
> Sent: Wednesday, April 26, 2006 1:38 PM
> Subject: Re: [Pw_forum] parallel scaling in PWSCF
> 
> 
> On 4/26/06, Nichols A. Romero <naromero at gmail.com> wrote:
> > Hi,
> 
> hi.
> 
> > Has anyone performed any very-large scale DFT calculations on PWSCF
> > using over 64 processors and over 1000 atoms? Does anyone know what
> > its current limits (system sizes and processors) are on parallel
> > computing environments with fast interconnects?
> 
> i've recently run a comparatively large job (272 atoms, 560 electrons,
> 4x4x4 k-points) across 768 processors on a Cray XT3. i had to hack
> some constants to make it work. however the scaling is not (yet)
> so good and depending on what kind of atoms you want to put into
> your system, i.e. if it is metallic, you may be better of with gamma
> only and car-parrinello dynamics. i ran the same system as above
> with a car-parrinello code (one that is not in quantum espresso) and
> would scale out at 512 nodes for gamma point only on an IBM BG/L.
> even though i had to use a much smaller time step, i did get much
> more trajectory that way.
> 
> judging from the CVS commit messages, efforts to optimize the
> quantum espresso codes for that kind of machine with large numbers
> of nodes are underway. note, that for systems as large as that,
> you might run into the scaling limitations of DFT with plane waves,
> so for a system that big using one of those 'linear scaling' DFT codes
> could be a more promising alternative.
> 
> best regards,
>      axel.
> 
> 
> >
> > Thanks,
> > --
> > Nichols A. Romero, Ph.D.
> > 1613 Denise Dr. Apt. D
> > Forest Hill, MD 21050
> > 443-567-8328 (C)
> > 410-306-0709 (O)
> > _______________________________________________
> > Pw_forum mailing list
> > Pw_forum at pwscf.org
> > http://www.democritos.it/mailman/listinfo/pw_forum
> >
> >
> 
> 
> --
> =======================================================================
> Axel Kohlmeyer   akohlmey at cmm.chem.upenn.edu   http://www.cmm.upenn.edu
>   Center for Molecular Modeling   --   University of Pennsylvania
> Department of Chemistry, 231 S.34th Street, Philadelphia, PA 19104-6323
> tel: 1-215-898-1582,  fax: 1-215-573-6233,  office-tel: 1-215-898-5425
> =======================================================================
> If you make something idiot-proof, the universe creates a better idiot.
> _______________________________________________
> 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
> 


From sbraccia at sissa.it  Wed Apr 26 22:40:51 2006
From: sbraccia at sissa.it (carlo sbraccia)
Date: Wed, 26 Apr 2006 16:40:51 -0400
Subject: [Pw_forum] parallel scaling in PWSCF
In-Reply-To: <Pine.LNX.4.58.0604262209040.5061@bamboo.fisica.unimo.it>
References: <6ac064b60604260941u15471f47oe6d45fee2ff6ce8@mail.gmail.com> <7b6913e90604261038t25d0bb43le5c8a740e793d981@mail.gmail.com> <003b01c66965$e4178d80$fcc2db80@ornl.gov> <Pine.LNX.4.58.0604262209040.5061@bamboo.fisica.unimo.it>
Message-ID: <444FDAD3.4050002@sissa.it>

Hi,

beware using the CVS version of PWSCF: the parallel Davidson has not yet 
been fully tested and seems to be buggy.
For this reason we are going to disable it until we shall be able to 
solve the problem. To avoid the serial bottleneck in the diagonalization 
you can use conjugate-gradient.

carlo

Andrea Ferretti wrote:

>Hi everybody,
>
>I am currently running a Copper surface with 140 Cu atoms + a molecule...
>the system has 1642 electrons and (due to metallicity) the calculation is 
>performed for 985 bands (few kpt, like 4)...
>due to the 11 electrons for each Cu atom, I have a huge number of bands in 
>a (relatively) small cell, and so a (relatively) low number of PWs respect 
>to nbnd.
>taking a look at the dimension of wfc, no problem with memory in 
>principle, even if, due to the weird 
>dimensions of the system, non-scalable memory is quite large, around 1Gb.
>
>on a IBM Sp5 machine I observed a severe limit in the scaling passing from 
>32 to 64 procs using both espresso 2.1.x and espresso 3.0...
>( anyway, I succeeded in performing a "relax" calculation for the system 
>!!!! )
>
>as far as I know, this problem might be connected to a serial part in the 
>diagonalization which has been parallelized in the current CVS version 
>(as already pointed out by Axel)...
>At the moment I am testing this CVS version against my system, I will let 
>you know the results as soon as possible...
>
>cheers
>andrea  
>
>
>  
>



From naromero at gmail.com  Wed Apr 26 23:32:32 2006
From: naromero at gmail.com (Nichols A. Romero)
Date: Wed, 26 Apr 2006 17:32:32 -0400
Subject: [Pw_forum] parallel scaling in PWSCF
In-Reply-To: <444FDAD3.4050002@sissa.it>
References: <6ac064b60604260941u15471f47oe6d45fee2ff6ce8@mail.gmail.com>
	 <7b6913e90604261038t25d0bb43le5c8a740e793d981@mail.gmail.com>
	 <003b01c66965$e4178d80$fcc2db80@ornl.gov>
	 <Pine.LNX.4.58.0604262209040.5061@bamboo.fisica.unimo.it>
	 <444FDAD3.4050002@sissa.it>
Message-ID: <6ac064b60604261432y26b9a5d5x166562fb6870da19@mail.gmail.com>

Carlo,

I am using the CVS version of PWSCF which I checked out on Monday.

I did 216 carbon atoms (bulk diamond) with USPP from the PWSCF
website. Using E_c = 40 Ry and only the gamma point:

Davidson took 14 min 33 sec. CG took 22 min 46 sec. That is the CPU
time as reported by PWSCF on an SGI Altix running on 8 processors.

I tried a 1728 atom calculation using the same parameters as above and
I ran into some trouble when trying to run it in parallel on 128
processors.

PWSCF seems to seg. fault with an error *possibly* originating in a
setup.f90 routine located here
check_para_diag_efficiency_

I was using the 'Davidson' algorithm in the 1728 atom calculation. I
have *not* tried the larger calculation with 'cg.'

I hope this is helpful.

Bests,
On 4/26/06, carlo sbraccia <sbraccia at sissa.it> wrote:
> Hi,
>
> beware using the CVS version of PWSCF: the parallel Davidson has not yet
> been fully tested and seems to be buggy.
> For this reason we are going to disable it until we shall be able to
> solve the problem. To avoid the serial bottleneck in the diagonalization
> you can use conjugate-gradient.
>
> carlo
>
> Andrea Ferretti wrote:
>
> >Hi everybody,
> >
> >I am currently running a Copper surface with 140 Cu atoms + a molecule...
> >the system has 1642 electrons and (due to metallicity) the calculation is
> >performed for 985 bands (few kpt, like 4)...
> >due to the 11 electrons for each Cu atom, I have a huge number of bands in
> >a (relatively) small cell, and so a (relatively) low number of PWs respect
> >to nbnd.
> >taking a look at the dimension of wfc, no problem with memory in
> >principle, even if, due to the weird
> >dimensions of the system, non-scalable memory is quite large, around 1Gb.
> >
> >on a IBM Sp5 machine I observed a severe limit in the scaling passing from
> >32 to 64 procs using both espresso 2.1.x and espresso 3.0...
> >( anyway, I succeeded in performing a "relax" calculation for the system
> >!!!! )
> >
> >as far as I know, this problem might be connected to a serial part in the
> >diagonalization which has been parallelized in the current CVS version
> >(as already pointed out by Axel)...
> >At the moment I am testing this CVS version against my system, I will let
> >you know the results as soon as possible...
> >
> >cheers
> >andrea
> >
> >
> >
> >
>
> _______________________________________________
> Pw_forum mailing list
> Pw_forum at pwscf.org
> http://www.democritos.it/mailman/listinfo/pw_forum
>


--
Nichols A. Romero, Ph.D.
1613 Denise Dr. Apt. D
Forest Hill, MD 21050
443-567-8328 (C)
410-306-0709 (O)


From lyw1983 at 163.com  Thu Apr 27 14:33:22 2006
From: lyw1983 at 163.com (lyw1983)
Date: Thu, 27 Apr 2006 20:33:22 +0800 (CST)
Subject: [Pw_forum] How should I input the positions of atoms
 for such material?
Message-ID: <4450BA12.000098.08570@bj163app60.163.com>

Dear all:
   The structure of the Ga2o3 is Monoclinic base-centered, and with
 a spacegroup of number12, so the primitive cell of it is not the 
unit cell, for this material, we should input celldm(1)=a,
celldm(2)=b/a,celldm(3)=c/a and celldm(4)=cos(ab),but the angle between a and b is 90o, and the angle between a and c is 103.7o, 
so we should change the axis as follow: a changes to b, b change 
to c and c change to a, now the angle between a and b is 103.7o, 
but when I input the positions of atoms, how should I change the 
positions?
  the iformation of Ga2O3 as below:a=12.23&Aring;, b=3.04&Aring;, c=5.80&Aring;, ?=90o,  
 ?=103.7o, ?=90o, the positions of atoms in primitive cell are:
Ga    0.09040   0.09040   0.79480
Ga    0.34140   0.34140   0.68570
O     0.16740   0.16740   0.10110
O     0.49570   0.49570   0.25530
O     0.82790   0.82790   0.43650
Ga    0.90960   0.90960   0.20520
Ga    0.65860   0.65860   0.31430
O     0.83260   0.83260   0.89890
O     0.50430   0.50430   0.74470
O     0.17210   0.17210   0.56350
  Perhaps this question is very stupid, but it really puzzled me for a 
long time, so I really need your help!
  Thanks very much!
 
 
 
 
 
 
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/attachments/20060427/de9ba2c4/attachment.htm 

From lukethulin at netscape.net  Thu Apr 27 14:41:55 2006
From: lukethulin at netscape.net (Luke Thulin)
Date: Thu, 27 Apr 2006 08:41:55 -0400
Subject: [Pw_forum] Can't run pwgui and missing chden.x
Message-ID: <4450BC13.7010402@netscape.net>

Hello,

I'm just trying Quantum Espresso for the first time.  I've installed it 
and successfully run the first few examples.  However, I see a couple 
problems.  If I try to run pwgui I get the following error:

Please define the PWGUI environment variable !!!
PWGUI should point to the PWgui package root directory.

Also, when I looked at the packages that should be available after doing 
the make all, chdens.x is not in my espresso-3.0/bin folder.

Thanks,
Luke Thulin


From Giovanni.Cantele at na.infn.it  Thu Apr 27 14:53:06 2006
From: Giovanni.Cantele at na.infn.it (Giovanni Cantele)
Date: Thu, 27 Apr 2006 14:53:06 +0200
Subject: [Pw_forum] Can't run pwgui and missing chden.x
In-Reply-To: <4450BC13.7010402@netscape.net>
References: <4450BC13.7010402@netscape.net>
Message-ID: <4450BEB2.4010508@na.infn.it>

>
>
> Please define the PWGUI environment variable !!!
> PWGUI should point to the PWgui package root directory.

You should define the PWGUI environment variable!!
Depending on which shell you are using:
setenv PWGUI something/espresso-3.0/PWgui-3.0
export PWGUI=something/espresso-3.0/PWgui-3.0

>
> Also, when I looked at the packages that should be available after 
> doing the make all, chdens.x is not in my espresso-3.0/bin folder.
>
As far as I know, chdens.x has been merged into pp.x. From Changelog in 
the CVS version:
2005-09-13 22:30  giannozz

        * Doc/INPUT_CHDENS, Doc/INPUT_PP, PP/Makefile, PP/chdens.f90,
          PP/postproc.f90, PW/clean_pw.f90, examples/example05/README,
          examples/example05/run_example, examples/example16/README,
          examples/example16/run_example:

        chdens.x merged into pp.x - all functionalities are still there
        and it is still possible to do the two steps independently.
        The output is basically the sum of the two outputs with minor
        differences. Documentation and examples updated, GUI not yet.

You find how to use the "new" pp.x for both post-processing and plotting 
(old chdens.x) in espresso3.0/Doc/INPUT_PP

Hope this helps,
Giovanni

-- 



Dr. Giovanni Cantele
Coherentia CNR-INFM and Dipartimento di Scienze Fisiche
Universita' di Napoli "Federico II"
Complesso Universitario di Monte S. Angelo - Ed. G
Via Cintia, I-80126, Napoli, Italy
Phone: +39 081 676910
Fax:   +39 081 676346
E-mail: Giovanni.Cantele at na.infn.it
Web: http://people.na.infn.it/~cantele



From lukethulin at netscape.net  Thu Apr 27 15:52:04 2006
From: lukethulin at netscape.net (Luke Thulin)
Date: Thu, 27 Apr 2006 09:52:04 -0400
Subject: [Pw_forum] Can't run pwgui and missing chden.x
In-Reply-To: <4450BEB2.4010508@na.infn.it>
References: <4450BC13.7010402@netscape.net> <4450BEB2.4010508@na.infn.it>
Message-ID: <4450CC84.5040309@netscape.net>

Thanks,

I was confused because I was expecting to see the chdens.x.  Also, pwgui 
is working after the export command.
Luke

Giovanni.Cantele at na.infn.it wrote:

>
>>
>>
>> Please define the PWGUI environment variable !!!
>> PWGUI should point to the PWgui package root directory.
>
>
> You should define the PWGUI environment variable!!
> Depending on which shell you are using:
> setenv PWGUI something/espresso-3.0/PWgui-3.0
> export PWGUI=something/espresso-3.0/PWgui-3.0
>
>>
>> Also, when I looked at the packages that should be available after 
>> doing the make all, chdens.x is not in my espresso-3.0/bin folder.
>>
> As far as I know, chdens.x has been merged into pp.x. From Changelog 
> in the CVS version:
> 2005-09-13 22:30  giannozz
>
>        * Doc/INPUT_CHDENS, Doc/INPUT_PP, PP/Makefile, PP/chdens.f90,
>          PP/postproc.f90, PW/clean_pw.f90, examples/example05/README,
>          examples/example05/run_example, examples/example16/README,
>          examples/example16/run_example:
>
>        chdens.x merged into pp.x - all functionalities are still there
>        and it is still possible to do the two steps independently.
>        The output is basically the sum of the two outputs with minor
>        differences. Documentation and examples updated, GUI not yet.
>
> You find how to use the "new" pp.x for both post-processing and 
> plotting (old chdens.x) in espresso3.0/Doc/INPUT_PP
>
> Hope this helps,
> Giovanni
>


From lukethulin at netscape.net  Thu Apr 27 16:01:03 2006
From: lukethulin at netscape.net (Luke Thulin)
Date: Thu, 27 Apr 2006 10:01:03 -0400
Subject: [Pw_forum] Can't run pwgui and missing chden.x
In-Reply-To: <4450CC84.5040309@netscape.net>
References: <4450BC13.7010402@netscape.net> <4450BEB2.4010508@na.infn.it> <4450CC84.5040309@netscape.net>
Message-ID: <4450CE9F.1030607@netscape.net>

I take that back, PWgui 3.0 isn't working.  If I go to the website and 
get version 2.1.3, that works, but 3.0 aborts and because the wish 
command is not found.

lukethulin at netscape.net wrote:

> Thanks,
>
> I was confused because I was expecting to see the chdens.x.  Also, 
> pwgui is working after the export command.
> Luke
>
> Giovanni.Cantele at na.infn.it wrote:
>
>>
>>>
>>>
>>> Please define the PWGUI environment variable !!!
>>> PWGUI should point to the PWgui package root directory.
>>
>>
>>
>> You should define the PWGUI environment variable!!
>> Depending on which shell you are using:
>> setenv PWGUI something/espresso-3.0/PWgui-3.0
>> export PWGUI=something/espresso-3.0/PWgui-3.0
>>
>>>
>>> Also, when I looked at the packages that should be available after 
>>> doing the make all, chdens.x is not in my espresso-3.0/bin folder.
>>>
>> As far as I know, chdens.x has been merged into pp.x. From Changelog 
>> in the CVS version:
>> 2005-09-13 22:30  giannozz
>>
>>        * Doc/INPUT_CHDENS, Doc/INPUT_PP, PP/Makefile, PP/chdens.f90,
>>          PP/postproc.f90, PW/clean_pw.f90, examples/example05/README,
>>          examples/example05/run_example, examples/example16/README,
>>          examples/example16/run_example:
>>
>>        chdens.x merged into pp.x - all functionalities are still there
>>        and it is still possible to do the two steps independently.
>>        The output is basically the sum of the two outputs with minor
>>        differences. Documentation and examples updated, GUI not yet.
>>
>> You find how to use the "new" pp.x for both post-processing and 
>> plotting (old chdens.x) in espresso3.0/Doc/INPUT_PP
>>
>> Hope this helps,
>> Giovanni
>>
> _______________________________________________
> Pw_forum mailing list
> Pw_forum at pwscf.org
> http://www.democritos.it/mailman/listinfo/pw_forum



From giannozz at nest.sns.it  Thu Apr 27 17:20:50 2006
From: giannozz at nest.sns.it (Paolo Giannozzi)
Date: Thu, 27 Apr 2006 17:20:50 +0200
Subject: [Pw_forum] Can't run pwgui and missing chden.x
In-Reply-To: <4450CE9F.1030607@netscape.net>
References: <4450BC13.7010402@netscape.net> <4450CC84.5040309@netscape.net> <4450CE9F.1030607@netscape.net>
Message-ID: <200604271720.50195.giannozz@nest.sns.it>

On Thursday 27 April 2006 16:01, Luke Thulin wrote:

> I take that back, PWgui 3.0 isn't working.  If I go to the website and
> get version 2.1.3, that works, but 3.0 aborts and because the wish
> command is not found.

if I remember correctly version 3.0 of the GUI is available only as 
source code and requires some external libraries to work. For version 
2.1.3 stand-alone binaries are available that do not require anything.

-- 
Paolo Giannozzi             e-mail:  giannozz at nest.sns.it
Scuola Normale Superiore    Phone:   +39/050-509876, Fax:-563513 
Piazza dei Cavalieri 7      I-56126 Pisa, Italy


From tone.kokalj at ijs.si  Thu Apr 27 17:33:13 2006
From: tone.kokalj at ijs.si (Tone Kokalj)
Date: Thu, 27 Apr 2006 17:33:13 +0200
Subject: [Pw_forum] Can't run pwgui and missing chden.x
In-Reply-To: <4450CE9F.1030607@netscape.net>
References: <4450BC13.7010402@netscape.net> <4450BEB2.4010508@na.infn.it>
	 <4450CC84.5040309@netscape.net>  <4450CE9F.1030607@netscape.net>
Message-ID: <1146151993.6568.29.camel@localhost.localdomain>

On Thu, 2006-04-27 at 10:01 -0400, Luke Thulin wrote:
> I take that back, PWgui 3.0 isn't working.  If I go to the website and 
> get version 2.1.3, that works, but 3.0 aborts and because the wish 
> command is not found.

You need the Tcl/Tk software to run the PWgui's source version (see the
README file in the top PWgui's directory). 

For the version 2.1.3 you very likely using the binary version (that's
not yet available for 3.0, my fault).

Regards, Tone



From tone.kokalj at ijs.si  Fri Apr 28 11:43:28 2006
From: tone.kokalj at ijs.si (Tone Kokalj)
Date: Fri, 28 Apr 2006 11:43:28 +0200
Subject: [Pw_forum] Can't run pwgui and missing chden.x
In-Reply-To: <1146151993.6568.29.camel@localhost.localdomain>
References: <4450BC13.7010402@netscape.net> <4450BEB2.4010508@na.infn.it>
	 <4450CC84.5040309@netscape.net>  <4450CE9F.1030607@netscape.net>
	 <1146151993.6568.29.camel@localhost.localdomain>
Message-ID: <1146217408.6098.21.camel@localhost.localdomain>

The binaries for PWgui-3.0 have just been created. See: 
http://www-k3.ijs.si/kokalj/pwgui/

Regards, Tone




From lukethulin at netscape.net  Fri Apr 28 15:24:18 2006
From: lukethulin at netscape.net (Luke Thulin)
Date: Fri, 28 Apr 2006 09:24:18 -0400
Subject: [Pw_forum] Can't run pwgui and missing chden.x
In-Reply-To: <1146217408.6098.21.camel@localhost.localdomain>
References: <4450BC13.7010402@netscape.net> <4450BEB2.4010508@na.infn.it>	 <4450CC84.5040309@netscape.net>  <4450CE9F.1030607@netscape.net>	 <1146151993.6568.29.camel@localhost.localdomain> <1146217408.6098.21.camel@localhost.localdomain>
Message-ID: <44521782.7090607@netscape.net>

I downloaded the new version and I think it's working.  However, when I 
execute the pwgui command from my shell, it says it's starting up PWgui 
version 2.1.3.  I don't see anything in the actual program that tells me 
which version I'm running.  So is there any way to be sure that I'm 
actually running 3.0?  I don't see how it could still be the 2.1.3, but 
just to be sure.

Thanks,
Luke

tone.kokalj at ijs.si wrote:

>The binaries for PWgui-3.0 have just been created. See: 
>http://www-k3.ijs.si/kokalj/pwgui/
>
>Regards, Tone
>
>
>_______________________________________________
>Pw_forum mailing list
>Pw_forum at pwscf.org
>http://www.democritos.it/mailman/listinfo/pw_forum
>  
>


From tone.kokalj at ijs.si  Fri Apr 28 15:30:13 2006
From: tone.kokalj at ijs.si (Tone Kokalj)
Date: Fri, 28 Apr 2006 15:30:13 +0200
Subject: [Pw_forum] Can't run pwgui and missing chden.x
In-Reply-To: <44521782.7090607@netscape.net>
References: <4450BC13.7010402@netscape.net> <4450BEB2.4010508@na.infn.it>
	 <4450CC84.5040309@netscape.net>  <4450CE9F.1030607@netscape.net>
	 <1146151993.6568.29.camel@localhost.localdomain>
	 <1146217408.6098.21.camel@localhost.localdomain>
	 <44521782.7090607@netscape.net>
Message-ID: <1146231013.6098.28.camel@localhost.localdomain>

On Fri, 2006-04-28 at 09:24 -0400, Luke Thulin wrote:
> I downloaded the new version and I think it's working. 

When you launch it, it should say:
 ==================================================
  This is PWgui version: 3.0
 --------------------------------------------------

Moreover,  the help documents (menu Help) also reveal the version
number. It should be 3.0.  If it is not, then probably you are not
running the right program?

I just downloaded from the WEB page, and it is really the 3.0 !

Ciao, Tone



From lukethulin at netscape.net  Fri Apr 28 15:43:37 2006
From: lukethulin at netscape.net (Luke Thulin)
Date: Fri, 28 Apr 2006 09:43:37 -0400
Subject: [Pw_forum] Can't run pwgui and missing chden.x
In-Reply-To: <1146231013.6098.28.camel@localhost.localdomain>
References: <4450BC13.7010402@netscape.net> <4450BEB2.4010508@na.infn.it>	 <4450CC84.5040309@netscape.net>  <4450CE9F.1030607@netscape.net>	 <1146151993.6568.29.camel@localhost.localdomain>	 <1146217408.6098.21.camel@localhost.localdomain>	 <44521782.7090607@netscape.net> <1146231013.6098.28.camel@localhost.localdomain>
Message-ID: <44521C09.70106@netscape.net>

The .zip version that I just downloaded now says The is PWgui version: 3.0.
The tar-gzip version that I downloaded initially was the one that said 
2.1.3.

tone.kokalj at ijs.si wrote:

>On Fri, 2006-04-28 at 09:24 -0400, Luke Thulin wrote:
>  
>
>>I downloaded the new version and I think it's working. 
>>    
>>
>
>When you launch it, it should say:
> ==================================================
>  This is PWgui version: 3.0
> --------------------------------------------------
>
>Moreover,  the help documents (menu Help) also reveal the version
>number. It should be 3.0.  If it is not, then probably you are not
>running the right program?
>
>I just downloaded from the WEB page, and it is really the 3.0 !
>
>Ciao, Tone
>
>_______________________________________________
>Pw_forum mailing list
>Pw_forum at pwscf.org
>http://www.democritos.it/mailman/listinfo/pw_forum
>  
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/attachments/20060428/9330cb5c/attachment.htm 

From stewart at cnf.cornell.edu  Fri Apr 28 20:17:04 2006
From: stewart at cnf.cornell.edu (stewart at cnf.cornell.edu)
Date: Fri, 28 Apr 2006 14:17:04 -0400
Subject: [Pw_forum] Re: Phonon frequencies different for equivalent q points
In-Reply-To: <200604261804.14603.giannozz@nest.sns.it>
References: <443BD1B3.6090200@ictp.it>
            <20060411184542.11682.qmail@xuxa.iecc.com>
            <200604261804.14603.giannozz@nest.sns.it>
Message-ID: <20060428181704.24228.qmail@xuxa.iecc.com>

Hi Paolo, 

  Thanks for the tip on the cartesian coordinates.  I had assumed the 
coordinates were in terms of reciprocal lattice vectors.  The results for M 
along the two directions now match. 

Best regards, 

Derek 

 

Paolo Giannozzi writes: 

> On Tuesday 11 April 2006 20:45, stewart at cnf.cornell.edu wrote: 
> 
>> I am looking at the high symmetry lines, Gamma-K-M along the [x,x,0]
>> direction going from [0,0,0] to [1,1,0]*(2pi/a) and the Gamma-M line
>> along the [x,0,0] going from [0,0,0] to [1/sqrt(3),0,0]*(2pi/a).
> 
> are you sure these are the correct high-symmetry lines? please note
> that phonon wavevectors must be supplied in cartesian coordinates 
> 
> Paolo
> -- 
> Paolo Giannozzi             e-mail:  giannozz at nest.sns.it
> Scuola Normale Superiore    Phone:   +39/050-509876, Fax:-563513 
> Piazza dei Cavalieri 7      I-56126 Pisa, Italy
> _______________________________________________
> Pw_forum mailing list
> Pw_forum at pwscf.org
> http://www.democritos.it/mailman/listinfo/pw_forum
 


################################
Derek Stewart, Ph. D.
Scientific Computation Associate
250 Duffield Hall
Cornell Nanoscale Facility (CNF)
Ithaca, NY 14853
stewart (at) cnf.cornell.edu
(607) 255-2856 



From emenendez at macul.ciencias.uchile.cl  Fri Apr 28 23:25:57 2006
From: emenendez at macul.ciencias.uchile.cl (Eduardo Ariel Menendez P)
Date: Fri, 28 Apr 2006 17:25:57 -0400 (CLT)
Subject: [Pw_forum] nodes halt problem
Message-ID: <Pine.LNX.4.58.0604281621590.27528@macul.ciencias.uchile.cl>

Dear friends
I apologize for a question of sys admin and not of espresso. However, this
is important for me to be able to has either espresso or siesta.

I would like to know if someone has had problem with this hardware
CPU: Xeom 3.06 GHz EMT64 (configures as 32 bits)
Chipset Intel E7320
Network adapter Intel 825401GI integrated in the mother board.
SATA hard disk in each node.
SATA controller 6300 ESB
My Linux is 2.4-27-2-686-smp Debian 1:3.3.6-10

When  running large parallel jobs, some nodes halt without any message.
We have made tests to determine if due it is hardware or software, but
we are not sure yet.

The system halts happen with at least two codes and with several versions
of LAM-MPI and MPICH, so it is no the problem.

One job using two CPU in the same node runs up to the end.
The same job using 2CPU in two nodes aborts due to one node halt.
The moment of halt seems random, also the node.
Nodes are connected via a Gbit switch. This make the switch and the
network cards suspects.

One job using 2 nodes and 4 CPU, linked using crossover cables, not the
switch, also abort due to halt. Then it seems that the switch is not
guilty.

Then it seems a problem of the kernel, or the network
controller, or the network adapter. How can I know who is guilty?
Is the problem is software, is there a solution other than install other
operative system? Can I discard software problems?

Thanks
Eduardo


From ezadshojaee at hotmail.com  Sat Apr 29 10:38:39 2006
From: ezadshojaee at hotmail.com (Ezad Shojaee)
Date: Sat, 29 Apr 2006 08:38:39 +0000
Subject: [Pw_forum] symmetry problem in vc-relax
Message-ID: <BAY19-F72C14AF124FFFD760413DAAB30@phx.gbl>

hi
i am doing vc-relax for TiO2 using symmetry-conserving algorithm ( 
cell_dynamics='damp-w' ) but still i have this message:

from checkallsym : error #         5
  not orthogonal operation

does anyone have any suggestion ?
this is the input file for pw.x   i am using :
&CONTROL
  calculation  = "vc-relax",
  restart_mode='from_scratch',
  prefix       = "TiO2",
  tstress = .true.
  tprnfor = .true.
  dt          =1,
  pseudo_dir   = "/root/pseudo",
  outdir       = "/root/tmp",
/
&SYSTEM
  ibrav     = 7,
  celldm(1) = 3.785,
  celldm(3) = 2.5136,
  nat       = 6,
  ntyp      = 2,
  ecutwfc   =40.0,

/
&ELECTRONS
  mixing_mode = 'plain'
  conv_thr    = 1.D-9,
  mixing_beta = 0.7,
/
&IONS
  ion_dynamics ='damp',
  pot_extrapolation='second-order',
  wfc_extrapolation='second-order',

/
&CELL
cell_dynamics='damp-w'
/
ATOMIC_SPECIES
Ti  1.00   Ti.vdb.UPF
O   1.00   O.vdb.UPF
ATOMIC_POSITIONS  { bohr }
Ti  0.00000000 -0.94625000 -1.18925000
Ti  0.00000000  0.94625000  1.18925000
O   0.00000000  0.94625000 -0.77634000
O   0.00000000 -0.94625000  0.77634000
O   1.89250000  0.94625000  1.60216000
O  -1.89250000 -0.94625000 -1.60216000
K_POINTS { automatic }
1  1  1     0 0 0

_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today it's FREE! 
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/