[Pw_forum] how to fix the occupations in DFT+U (Matteo Cococcioni)

Paolo Giannozzi paolo.giannozzi at uniud.it
Sun Nov 9 21:48:34 CET 2014


On Sun, 2014-11-09 at 20:31 +0100, simone marocchi wrote:

> Unfortunately the symmetry operations implemented so far in Quantum
> Espresso can not handle screw rotations and glide reflections as in a
> standard Quantum Chemistry package

? QE should work with all point symmetries that are compatible
with translational symmetry

P.

> . So I am trying to impose such occupations as an approximation to the
> real symmetry of the system. Hereafter I will try also your "dirty
> trick" suggesting a starting_ns_eigenvalue bigger than one. Using the
> mixing_fixed_ns > electron_maxstep I obtained big differences in the
> occupations imposed and obtained, interestingly although I did not end
> in the predetermined states  the system fell always in the same
> strange occupation. The convergence was quite nice (tens of
> iterations) up to 10^-6 Ry. Perhaps, as you pointed out I have a
> different symmetry than the code finds for my system. Unfortunately,
> although I would like to try to develop some new parts codes, I do not
> feel enough trained and comfortable with the timetable of my current
> project. Thanks a lot for your suggestion !  
> 
> 
> S
> 
> 
> Dear Simone
> 
> I try to answer your questions below.
> 
> On Fri, Nov 7, 2014 at 3:32 PM, simone marocchi <simone.roz at gmail.com>
> wrote:
> 
> > Dear all, I am simulating compounds with rare earths within a
> collinear
> > calculation. I tried to suggest some occupations of the f orbitals
> for the
> > Tb atom, using the starting_ns_eigenvalue(m,ispin,I).
> >
> 
> 
> why do you need to do that? if you want to force different values of
> occupation on states that are equivalent by symmetry you will not be
> successful. If this is the case you have to do something that makes
> the
> system loose that symmetry operation connecting the two states.
> 
> 
> 
> > Unfortunately also with a small value of electronic mixing and big
> values
> > of U, the imposed occupations was lost during the iterative cycle.
> >
> 
> 
> this can happen. a dirty trick I learned recently is to suggest a
> starting_ns_eigenvalue(m,
> ispin,I) bigger than one in input (1.2 or 1.3 maybe). This does not
> make
> any physical sense of course. However the Hubbard potential becomes
> more
> attractive for the specific eigenvector of the occupation matrix you
> want
> to fill completely and the code takes more time to "come back" to a
> physical value. If that is a state it likes (at least a local minimum
> of
> the energy) it might fall into it. Of course you have to check at the
> end
> that the occupation has gone back to a value <= 1.
> 
> 
> 
> > So I used also mixing_fixed_ns > electron_maxstep. Also in this case
> after
> > I obtain the total energy convergence the density matrix of the last
> > iteration is different to the one imposed in the input_file.
> >
> 
> 
> this is (possibly) strange. How different is it? How well are you
> converging?
> The fact that it is different is not surprising: the routine that
> prints
> the ns, always prints the ones that are computed from the KS states
> just
> obtained from the new diagonalization. These can be different from the
> ones
> e.g. used in contructing the Hubbard potential.
> However if your calculation is well converged this difference should
> not be
> big: both KS wfcs and their occupations should be converged reasonably
> well.
> If this does not happen and you still see a significant difference
> maybe it
> means that the values you are trying to impose is not consistent with
> what
> the system wants to do (e.g., you have less symmetry than the code
> finds
> for your crystal)
> 
> 
> 
> 
> > Can someone of you kindly explain me how the mixing_fixed_ns works ?
> Do it
> > uses a sort of Lagrange multipliers to force the occupations or is
> more
> > like a penalty function ? Finally, is it possible to work around the
> > problem, converging to a determined occupation ?
> >
> 
> 
> no with the current version of the code. you could implement some
> (e.g.,
> quadratic) constraint and try. I think I once tried (long time ago)
> and
> seem to remember problems in convergence.
> 
> Best,
> 
> Matteo
> 
> 
> 
> -- 
> Simone Marocchi
> 
> S3 Center, Istituto Nanoscienze, CNR
> via Campi 213/A, 41125, Modena, Italy
> Tel: +39 0592055585;  Skype: jacobi84
> URL: http://www.nano.cnr.it
> 
> _______________________________________________
> Pw_forum mailing list
> Pw_forum at pwscf.org
> http://pwscf.org/mailman/listinfo/pw_forum





More information about the users mailing list