[Pw_forum] LDA+U and occupations matrix problems / call for NC P Cu & Co

Gabriele Sclauzero sclauzer at sissa.it
Wed Apr 29 09:02:44 CEST 2009



Ricardo Faccio wrote:
> Dear Stefano
> 
> Thanks for your quick response. I found the CVS log in the mailing list, 
> but I decided to write you since the problem persist. 

Are you meaning that using the latest CVS you found the same problem? Does it change 
anything from the output of the previous version. If there is a PP with wavefunctions 
which need to be renormalized you should find a warning at the beginning of the output. Do


> Now I'm attaching 
> my input file, which I used to perform U=1.0d-8 eV, U= 3.5 eV and U= 7 
> eV. Making a revision of the problem, I found the only difference 
> regards in the GGA xc-potential. Maybe it is the problem; I found some 
> early posts indicating that GGA+U is not yet implemented. 

Which posts? Please give reference. I think GGA+U can be used and it has been used 
extensively by the developer himself, so I think it should be safe. There is no conceptual 
and practical difference in using GGA+U rather than LDA+U.

> If it is the 
> case sorry, but in the meanwhile I'll comment I little bit on the problem.
> 
> 1) U=1.0d-8 eV, everything is ok, since there is no U and pwscf runs in 
> the normal GGA procedure, this is the initial occupations matrix for one 
> Co atom
> 
> atom  5  spin  1
> occupations
> 0.400  0.000  0.000  0.000  0.000
> 0.000  0.400  0.000  0.000  0.000
> 0.000  0.000  0.400  0.000  0.000
> 0.000  0.000  0.000  0.400  0.000
> 0.000  0.000  0.000  0.000  0.400
> atom  5  spin  2
> occupations
> 1.000  0.000  0.000  0.000  0.000
> 0.000  1.000  0.000  0.000  0.000
> 0.000  0.000  1.000  0.000  0.000
> 0.000  0.000  0.000  1.000  0.000
> 0.000  0.000  0.000  0.000  1.000
> 
> This is normal for the d7 pseudo for Co, and in the last step we found:
> 
> occupations
> atom  5  spin  1
> occupations
> 
> 0.532  0.000  0.000  0.000  0.000
> 0.000  0.434  0.000  0.000  0.000
> 0.000  0.000  0.434  0.000  0.000
> 0.000  0.000  0.000  0.993  0.000
> 0.000  0.000  0.000  0.000  0.435
> atom  5  spin  2
> occupations
> 0.976  0.000  0.000  0.000  0.000
> 0.000  0.992  0.000  0.000  0.000
> 0.000  0.000  0.992  0.000  0.000
> 0.000  0.000  0.000  0.995  0.000
> 0.000  0.000  0.000  0.000  0.935
> 
> 2) In the case of U=3.5 eV (for both Cu & Co)
> 
> In the first scf cycle the occupations matrix looks like the one in the 
> U=0 case, 

Of course, because at the first iteration occupations are fixed using Hund's rule, not 
calculated from projections onto atomic wavefunctions.


> but in the second scf step I found:
> 
> atom  5   Tr[ns(na)]=  14.9317605
> atom  5  spin  1
> eigenvalues:  0.2107738 0.2794264 0.2794264 0.5053719 0.5799705
> eigenvectors
> 1   0.0000000  0.0000000  0.0000000 -1.0000000  0.0000000
> 2   0.0000000 -0.8886367  0.4586119  0.0000000  0.0000000
> 3   0.0000000 -0.4586119 -0.8886367  0.0000000  0.0000000
> 4   0.0000000  0.0000000  0.0000000  0.0000000 -1.0000000
> 5  -1.0000000  0.0000000  0.0000000  0.0000000  0.0000000
> occupations
> 0.580  0.000  0.000  0.000  0.000
> 0.000  0.279  0.000  0.000  0.000
> 0.000  0.000  0.279  0.000  0.000
> 0.000  0.000  0.000  0.211  0.000
> 0.000  0.000  0.000  0.000  0.505
> atom  5  spin  2
> eigenvalues:  2.5970604 2.6187425 2.6187425 2.6211004 2.6211456
> eigenvectors
> 1   1.0000000  0.0000000  0.0000000  0.0000000  0.0000000
> 2   0.0000000 -0.8592401  0.5115724  0.0000000  0.0000000
> 3   0.0000000  0.5115724  0.8592401  0.0000000  0.0000000
> 4   0.0000000  0.0000000  0.0000000  0.0000000  1.0000000
> 5   0.0000000  0.0000000  0.0000000 -1.0000000  0.0000000
> occupations
> 2.597  0.000  0.000  0.000  0.000
> 0.000  2.619  0.000  0.000  0.000
> 0.000  0.000  2.619  0.000  0.000
> 0.000  0.000  0.000  2.621  0.000
> 0.000  0.000  0.000  0.000  2.621
> The occupations  jumps from 1 to 2.6 always in the second scf, and 
> stands in this value until the end of the scf procedure. 

These values are quite strange. If you are sure that the pseudo-atomic wavefunction from 
the PP file has been renormalized at the beginning, you could try to generate a new PP of 
Co (using ld1.x from the cvs version, which should produce already normalized wfcs) with 
the same cut-off radii and see if the problem persists.

You can also try to fix occupations on Co for the first scf iterations using 
mixing_fixed_ns or try different initial occupations with starting_ns_eigenvalue.

Another critical point could be convergence of local occupations ns with respect to 
ecutwfc and number of k-points, but the exceedingly high values you get seem to point at a 
different problem.

HTH

GS

> As I mentioned 
> before, I didn't use the U_projection_type flag for these three cases. I 
> resolved the problem adding the explicitly the flag: U_projection_type = 
> 'norm-atomic', since 'atomic' leads to the same erratic occupations 
> matrix. The problem is only related with Co electrons, since Cu always 
> presents occupations terms in the range of 0 to 1.
> 
> But as I mentioned before, maybe the problem is that “GGA+U” is not yet 
> implemented.
> 
> 
> 
> Thanks once again
> 
> Ricardo
> 
> 
> 
> 
> -------------------------------------------------------------------------
>  Dr. Ricardo Faccio
>  Prof. Adjunto de Física
>  Mail: Cryssmat-Lab., Cátedra de Física, DETEMA
>  Facultad de Química, Universidad de la República
>       Av. Gral. Flores 2124, C.C. 1157
>       C.P. 11800, Montevideo, Uruguay.
>  E-mail: rfaccio at fq.edu.uy
>  Phone: 598 2 924 98 59
>              598 2 929 06 48
>  Fax:    598 2 9241906
>  Web:  http://cryssmat.fq.edu.uy/ricardo/ricardo.htm
> --------------------------------------------------------------------------------- 

-- 


o ------------------------------------------------ o
| Gabriele Sclauzero, PhD Student                  |
| c/o:   SISSA & CNR-INFM Democritos,              |
|        via Beirut 2-4, 34014 Trieste (Italy)     |
| email: sclauzer at sissa.it                         |
| phone: +39 040 3787 511                          |
| skype: gurlonotturno                             |
o ------------------------------------------------ o



More information about the users mailing list