ACFDT-RPA in vasp 6

Question on input files/tags, interpreting output, etc.

Please check whether the answer to your question is given in the VASP online manual or has been discussed in this forum previously!

Moderators: Global Moderator, Moderator

Post Reply
Message
Author
kdoblhoff
Newbie
Newbie
Posts: 3
Joined: Thu Feb 04, 2021 12:10 pm

ACFDT-RPA in vasp 6

#1 Post by kdoblhoff » Fri Feb 05, 2021 7:53 am

Dear all,

I am trying to learn how to perform a (reasonable) ACFDT calculation in vasp 6 (not having any experience on RPA calculations in vasp 5 either). In order to check that we correctly understand all relevant keywords, we tried to reproduce old results first. As we are ultimately interested in metallic systems, we chose the lattice constant of Al as first test-case and tried to follow PRB 81, 115126 (2010) (this is the RPA lattice constant paper by Harl, Schimka and Kresse that basically also describes the implementation in VASP 5). Currently, we thereby extract the lattice constant by a fit to an EOS, rather than by trying to optimize the geometry, which (I believe) should be possible for metallic systems as of vasp 6.2.

However, we ran into several issues/questions that were not quite clear to us (me):

Table III of the paper states the parameters used in the final calculations. For Al, it states E_cut^EXX=360; k^EXX=20; E_cut^RPA=300; E_cut^\chi=200; k^RPA=12 (in bold letters). In the caption, it says: bold values for k mean that the same k-point sampling was applied for EXX and correlation energy. This triggered several questions:
  • If the same k-point grid is used for EXX as for the correlation energy, why is then a separate k^EXX listed? Which parameter would this correspond to (nkred should decrease the number of k-points between the EXX calculation and the correlation calculation I believe, which is obviously not what one wants for metals)?
  • Unless I am very mistaken E_cut^\chi is set in vasp by default to 2/3 of the E_cut^\RPA via the parameters ENCUTGW (corresponding to E_cut^\chi) and ENCUT (corresponding to E_cut^\RPA), which is consistent with E_cut^chi/E_cut^RPA=2/3. But how would a different E_cut^EXX be achieved (particularly when using the 1-step routine in vasp 6)? Is this achieved indirectly by setting NBANDSEXACT to a value lower than the max. number of plane waves? If so, considering the fact that NBANDSEXACT is not documented, is it still advised to play with E_cut^EXX vs. E_cut^RPA, or has it become general practice to use all bands available (i.e., the same Ecut for the EXX calculation as for the correlation)?
Thank you for your advice,
Best regards,
Katharina Doblhoff-Dier

merzuk.kaltak
Administrator
Administrator
Posts: 122
Joined: Mon Sep 24, 2018 9:39 am

Re: ACFDT-RPA in vasp 6

#2 Post by merzuk.kaltak » Tue Feb 09, 2021 9:44 am

Dear Katharina,
The paper you are referring to was the first implementation of total energies within the ACFDT formalism.
Per se, this implementation uses a zero-temperature formalism that is strictly valid only for insulators, because this formalism, known as Goldstone perturbation theory, breaks down for metals. The perturbation series contains terms with infinite contribution (because each term is roughly proportional to the inverse of the band gap). If you throw away these contributions and replace them by a correction term (explained in Eq. 12 of the PRB 81,115126) one can arrive at a converged result.

I advice to use the finite-temperature formalism https://www.vasp.at/wiki/wiki/index.php ... EMPERATURE for RPA calculations of metals, where VASP uses the Matsubara-formalism that works for metals as well as for insulators.
Walter Kohn has a paper about this, where he explains why one should use this formalism instead of the Goldstone one: https://journals.aps.org/pr/abstract/10 ... Rev.118.41

Concerning your technical questions, I cannot answer them fully, but I can give some advice how to run decent RPA calculations for metals:
  • It is a good idea to use all NBANDS supported by the ENCUT choice. The finite basis set error might be too large if NBANDS is set manually. The easiest way would be to omit NBANDS and just set ALGO = RPAR. VASP then uses all available NBANDS based on the selected ENCUT value.
  • E_cut^chi is set by ENCUTGW and is ~ 2/3 of ENCUT, while ENCUT is the cutoff of the EXX part. I usually don't set any of these INCAR tags for single-point total energy calculations and use the default values VASP determines from the POTCAR. In my experience, the convergence of energy differences (like defect formation energies) with the default settings is sufficiently good.
    In contrast converging total energies for one specific POSCAR, with respect to k-points, energy cutoff, etc., is a really tough task and usually not necessary.
  • For metals, I set LFINITE_TEMPERATURE = T, ISMEAR = -1 and SIGMA to a value that corresponds to the electronic temperature in eV (~0.1-0.2 is most of the time sufficiently "cold" and doesn't requiere too many NOMEGA grid points, see https://journals.aps.org/prb/abstract/1 ... 101.205145).
  • I wouldn't change NBANDSEXACT, better change ENCUT to a lower value if you want a quick and dirty calculation.
Here is a minimal INCAR file that determines the total energy in the RPA, which also works for metals:

Code: Select all

ISMEAR=-1 ; LFINITE_TEMPERATURE = .TRUE. 
NBANDS=12
ALGO = RPAR
Look for "HF+E_corr(extrapolated)" in the OUTCAR and you will find a reasonable value for the total energy in the RPA (that is EXX + E_RPA).
The entry "HF+RPA corr. ..." contains the non-extrapolated value of the RPA correlation energy, while the former uses the extrapolated one.


I hope this helps.

merzuk.kaltak
Administrator
Administrator
Posts: 122
Joined: Mon Sep 24, 2018 9:39 am

Re: ACFDT-RPA in vasp 6

#3 Post by merzuk.kaltak » Mon Feb 15, 2021 11:54 am

Apologies, the minimal INCAR should read:

Code: Select all

ISMEAR=-1 ; LFINITE_TEMPERATURE = .TRUE. 
NOMEGA=12
ALGO = RPAR

kdoblhoff
Newbie
Newbie
Posts: 3
Joined: Thu Feb 04, 2021 12:10 pm

Re: ACFDT-RPA in vasp 6

#4 Post by kdoblhoff » Tue Feb 16, 2021 10:19 am

Thank you for the correction. We already gathered that :-)

Post Reply