[SOLVED] boxcut > 2.2 ???

Total energy, geometry optimization, DFT+U, spin....

Moderator: bguster

Locked
spamrefuse
Posts: 35
Joined: Wed Jan 20, 2010 3:08 am

[SOLVED] boxcut > 2.2 ???

Post by spamrefuse » Fri Jul 16, 2010 5:10 pm

Hi,

When I run abinit, I have this comment in the log file:
---------------------------------------------------------------------
getcut : COMMENT -
Note that boxcut > 2.2 ; recall that boxcut=Gcut(box)/Gcut(sphere) = 2
is sufficient for exact treatment of convolution.
Such a large boxcut is a waste : you could raise ecut
e.g. ecut= XXXXXXX Hartrees makes boxcut=2
---------------------------------------------------------------------

where XXXXX suggests some larger value for ecut.

When I put this suggested value for ecut in the input file, I get the same
comment suggesting an even larger value; when I then try that larger value
it again suggests me to use a much larger value, etc. etc.
I've been trying for ecut:
35 -> 75 -> 115 -> 160 -> 300 -> 470

What is this?
Should I ignore this comment, as its suggestion does not seem to solve
the problem.......or is this a bug in abinit?

Is there another way to solve this?

Thank you!
Rob.

pmanglade
Posts: 20
Joined: Mon Aug 17, 2009 9:49 am

Re: boxcut > 2.2 ???

Post by pmanglade » Fri Jul 16, 2010 7:41 pm

The only "sensible" explanation I can guess for such a behavior is that you always round Abinit suggestion to a slightly greater number. Could it be the case ? What happens if you try a value of ecut slightly lower than what is suggested by Abinit ?

mverstra
Posts: 655
Joined: Wed Aug 19, 2009 12:01 pm

Re: boxcut > 2.2 ???

Post by mverstra » Wed Jul 28, 2010 6:06 pm

Hello,

just leave the ecut as it was, and converge it alone. You are probably using dilatmx and ecutsm. This means the effective ecut_eff is larger than ecut, and the density cutoff is 2*ecut_eff. The warning (which just means that ecut is smaller than it could be given the density grid) should be ignored in these cases, as you really want the ecut_eff to be a bit too big, in order to accomodate the possibility of a changing unit cell size.

matthieu
Matthieu Verstraete
University of Liege, Belgium

Locked