Page 1 of 1

RMM convergence issues with LEPSILON

PostPosted: Fri May 18, 2018 4:07 pm
by jcg_forum
Hi all,

I'm having some troubles properly converging linear response calculations using the LEPSILON tag. I have a slightly complex system (layered perovskite), which is elongated in one direction. In this direction, the RMM algo used to solve the Sternheimer equation including local field effects at the DFT level seems not to converge. Here a short sample of an OSZICAR:

Code: Select all
 Linear response to external field, progress :
  Direction:   1
       N       E                     dE             d eps       ncg     rms          rms(c)
RMM:   1    -0.850584656635E+01   -0.85058E+01   -0.26103E+01 13340   0.423E+00
RMM:   2    -0.874603943914E+01   -0.24019E+00   -0.19829E-01 11342   0.968E-01    0.597E+00
RMM:   3    -0.748967270442E+01    0.12564E+01   -0.10579E+00 12067   0.138E+00    0.292E+00
RMM:   4    -0.730654704832E+01    0.18313E+00   -0.12068E+00 12239   0.130E+00    0.111E+00
RMM:   5    -0.731457232913E+01   -0.80253E-02   -0.13850E+00 12843   0.685E-01    0.524E-01
RMM:   6    -0.726168940721E+01    0.52883E-01   -0.12933E+00 12661   0.258E-01    0.365E-01
RMM:   7    -0.711357711134E+01    0.14811E+00   -0.24243E+00 11848   0.345E-01    0.164E-01
RMM:   8    -0.710307277916E+01    0.10504E-01   -0.32406E+00 13050   0.162E-01    0.102E-01
RMM:   9    -0.701358586939E+01    0.89487E-01   -0.27760E+00 12605   0.941E-02    0.457E-02
RMM:  10    -0.705063689592E+01   -0.37051E-01   -0.32854E+00 12669   0.475E-02    0.220E-02
RMM:  11    -0.700366510845E+01    0.46972E-01   -0.28143E+00 12758   0.276E-02    0.563E-03
RMM:  12    -0.705342455625E+01   -0.49759E-01   -0.33081E+00 13589   0.162E-02    0.343E-03
RMM:  13    -0.700526629954E+01    0.48158E-01   -0.28231E+00 13420   0.120E-02    0.941E-04
RMM:  14    -0.705390675078E+01   -0.48640E-01   -0.33095E+00 15276   0.951E-03    0.666E-04
RMM:  15    -0.700535516486E+01    0.48552E-01   -0.28229E+00 15425   0.836E-03    0.237E-04
RMM:  16    -0.705400285065E+01   -0.48648E-01   -0.33092E+00 15764   0.778E-03    0.148E-04
RMM:  17    -0.700534540025E+01    0.48657E-01   -0.28228E+00 15958   0.749E-03    0.135E-04
RMM:  18    -0.705399439894E+01   -0.48649E-01   -0.33093E+00 16055   0.736E-03    0.883E-05
RMM: 147    -0.700538452600E+01    0.48607E-01   -0.28232E+00 16132   0.721E-03    0.676E-05
RMM: 148    -0.705398501495E+01   -0.48600E-01   -0.33092E+00 16089   0.720E-03    0.535E-05
RMM: 149    -0.700536610283E+01    0.48619E-01   -0.28230E+00 16136   0.720E-03    0.677E-05
RMM: 150    -0.705398678068E+01   -0.48621E-01   -0.33093E+00 16144   0.721E-03    0.535E-05

In this case, the algo did not converged in the maximum number of iterations allowed, with a charge-sloshing-like behavior.

Sometimes this behavior is visible, but the algorithm "converges", without reaching the required EDIFF (I'm not sure EDIFF makes sense for this solver, actually). I've checked the code, there's another alternative criterion of "convergence" for the residue minimization algo of LEPSILON, based on the difference in residue between the current iteration and the two previous one. I don't know if that is a reliable convergence criterion - I think that it's more of a way to see if the solver just won't improve things with more iterations. Actually in the OUTCAR, the same message is always printed ("aborting loop because EDIFF is reached"), which is incorrect.

I therefore have three questions:

  • How sensitive are results of linear response computations to the RMM convergence? Can we trust poorly converged results (I could try that on my own in fact)?
  • Is there a way to improve the RMM convergence? Tightening the kmesh seems to help a bit, but not that much. What about mixing parameters - do these apply to this very specific algo?
  • I have absolutely no issues converging a standard scf on these systems. I also didn't have issues with RMM convergence in LEPSILON runs on other systems (bulk Si, etc). Is this convergence issue something often observed?

many thanks,

Re: RMM convergence issues with LEPSILON

PostPosted: Wed Jul 18, 2018 10:39 am
by admin
In case you have an odd number of electrons please use ISPIN = 2 with proper settings for MAGMOM (if you haven't done so already).
More informations about MAGMOM and related settings can be found on our wiki-page:

It seems you have set somewhere ALGO = Fast in the INCAR.
Usually ALGO = Fast is more reliable and only slightly slower.
If you encounter convergence issuses with ALGO = Fast,
we recommend to switch to the more reliable blocked Davidson algorithm (ALGO = Normal).

More information about algorithms for DFT calculations can be found here:

Re: RMM convergence issues with LEPSILON

PostPosted: Thu Jul 19, 2018 3:29 am
by jcg_forum
Thank you for your reply. However, I am actually already using the blocked Davidson algorithm, and have an even number of electrons.

Here's a typical INCAR I'm using to obtain the static dielectric matrix on a given displaced configuration:

Code: Select all
    AMIN = 0.001
    ISYM = -1
    NPAR = 2

  SYSTEM = No title

    PREC = Accurate
   ENCUT = 800.0
  IBRION = -1
     NSW = 0
    ISIF = 2
  NELMIN = 5
   EDIFF = 1.0e-08
  EDIFFG = -0.02
  NBLOCK = 1
  NWRITE = 1
    NELM = 150
    ALGO = Normal
    IVDW = 11
  VDW_S6 = 1.0
  VDW_S8 = 0.722
  VDW_SR = 1.217
   ISPIN = 1
  INIWAV = 1
  ISTART = 0
  ICHARG = 2
  ISMEAR = 0
   SIGMA = 0.05
RWIGS = 0.32 0.77 0.75 1.33 1.47

Re: RMM convergence issues with LEPSILON

PostPosted: Wed Jul 25, 2018 9:06 am
by admin
We have reproduced the problem, i.e. the insufficient convergence of the RMM algorithm.
This issue appears only for the response of the displacement in the x-direction when including local field effects,
in all other cases RMM converges.

Since your cell is elongated in the x-direction, we suspect that charge sloshing is responsible for this problem.
Typically charge sloshing might be avoided using a different minimizer.
Unfortunately, LEPSILON = .TRUE. does not support any other solver.

However, since your system has a band gap (of roughly 2 eV) we suggest to switch to LCALEPS = .TRUE. instead.

Here is more information on both methods: