Warning on forces using DFT_PLUS_U LOWDIN. Implemented or not?

491 views
Skip to first unread message

Gabriele

unread,
Feb 4, 2014, 2:58:27 PM2/4/14
to cp...@googlegroups.com
Hi all,

I am using DFT+U to relax a defective surface system. Specifically, I am using the LOWDIN method because I could not make SCF converge using the MULLIKEN based methods. The relaxation completes fine and the resulting structure agrees with the literature and calculations performed with a PW code. However, the following warning appears when computing the forces using LOWDIN:

 *** 18:28:47 WARNING in dft_plus_u:lowdin :: Forces are not yet fully ***
 *** implemented for DFT+U method LOWDIN                                     ***

What does it mean that the forces are not fully implemented? Is it possible just that they have not been fully tested?

Thanks.
Gabriele
inp1.inp
structure.xyz

Matthias Krack

unread,
Feb 5, 2014, 2:51:56 AM2/5/14
to cp...@googlegroups.com
Dear Gabriele,

it means that forces are not available for the DFT+U method LOWDIN. You have to use the DFT+U method MULLIKEN. You may try to converge the initial SCF run with U=0eV firstly and then try to restart with DFT+U. DFT+U is sensible to weird charge densities which may easily occur during the first SCF iteration steps when starting from scratch.

Matthias

Gabriele

unread,
Feb 10, 2014, 6:14:21 AM2/10/14
to cp...@googlegroups.com
Dear Matthias,

Thanks for the quick reply. After restarting the calculations a few times with subsequently larger values of U, the SCF and the whole geometry optimization converged using MULLIKEN. However, I would like to run MD on this system and after about 100 steps the same warning on unphysical Mulliken charges and negative U contribution to the energy appears and the SCF does not converge anymore. Using U_RAMPING [eV] 0.1 and INIT_U_RAMPING_EACH_SCF did not help. It seems that not only DFT+U is sensible to changes in the charge densities in the first SCF but also to changes from the previous MD step. I wonder if you or somebody else has experienced a similar issue and have any hint on that.

Best wishes,
Gabriele.
inp2.inp
PROJECT-1.restart

Matthias Krack

unread,
Feb 11, 2014, 8:51:58 AM2/11/14
to cp...@googlegroups.com
Dear Gabriele,

your system is rather large and not well suited for a quick testing. I can only suggest to use the PRINT_LEVEL medium (&GLOBAL section) together with

  &PRINT
  &PLUS_U on
   &EACH
    QS_SCF 1
   &END EACH
  &END PLUS_U
 &END PRINT

which will print the d orbital occupations of the Ti atoms in each SCF iteration step. This might give you some clue about what is going on.

CP2K produces orbital occupation pattern which differ to the values obtained in PW codes due to the different basis set and population analysis employed. For this reason the U values used with PW codes cannot directly be transferred to CP2K always. Due to my experience a lower U value can already cause a similar opening of the band gap for the reference bulk system.

You may also try to equilibrate the system in advance using a smaller U value, e.g. ~2eV instead of 4.2eV, and check if the problem persists.

Matthias
Reply all
Reply to author
Forward
0 new messages