DOS calculation stops after "aborting loop because EDIFF is reached "

[gevolo]

Hello,

I am trying to calculate the DOS for a large system. I have already relaxed the system and start a new static run, using the preconverged CHGCAR, while using a 2x2x2 gamma-centered k-point grid.

My input file:

Code: Select all

ISTART?=?0
ISYM?=?0
ICHARG?=?11
ENCUT?=?400
ISMEAR?=?-5
LWAVE?=?.False.
NBANDS?=?800
LREAL?=?Auto

EDIFF?=?0.001
EDIFFG?=?-0.01

NSW?=?0
IBRION?=?-1
ISIF?=?2

IALGO?=?48
NPAR?=??4

EMIN?=?-7
EMAX?=?10
NEDOS?=?2000

The run starts normally and after the ionic step (electronic steps converge normally) the run just stops. Nothing is written in the std.out or std.err nor at the log file. The last line in the OUTCAR file is :
------------------------ aborting loop because EDIFF is reached ----------------------------------------

Is this a memory related error ? (I have seen, some memory usage peaks when running much much smaller cases on my personal PC) The memory usage written in the OUTCAR is:

$ grep Bytes OUTCAR
total amount of memory used by VASP on root node 297766. kBytes
base : 30000. kBytes
nonlr-proj: 13677. kBytes
fftplans : 6332. kBytes
grid : 10856. kBytes
one-center: 153. kBytes
wavefun : 236748. kBytes


Thank you in advance,
George

[oloklir]

That looks similar to my team's problem.

I posted about calculation speed degradation EXACTLY after below line,
"
------------------------ aborting loop because EDIFF is reached ----------------------------------------
"
the post here,
http://cms.mpi.univie.ac.at/vasp-forum/ ... hp?3.11267


I experienced that is because of lack of memory.
Memory consumption depends on the size of system and kpoints, ISPIN options or memory related algorithm options.

If there are enough RAM space, it runs fast without problem.
If there are not enough RAM space but enough SWAP space, it runs extremely slow after "that last line" but makes results finally.
If there are not enough RAM and SWAP space, the calculation job just stops after "that last line".

This is a problem I experienced during using vasp 5.2.12.
There is no problem with vasp 4.6.36.

The memory usage suddenly increases after "that last line", when using vasp 5.2.12.
vasp 4.6.34 does not show that behavior. It uses constant memory.

Can you try that calculation with vasp 4.6.36?




<span class='smallblacktext'>[ Edited Wed Jun 13 2012, 08:05AM ]</span>

[gevolo]

Thank you for the reply,

Indeed I have seen the exact same...

"If there are enough RAM space, it runs fast without problem.
If there are not enough RAM space but enough SWAP space, it runs extremely slow after "that last line" but makes results finally.
If there are not enough RAM and SWAP space, the calculation job just stops after "that last line". "

I will check now with vasp 4.6, and I ll let you know what happened...

[gevolo]

[quote="oloklir"]That looks similar to my team's problem.

I posted about calculation speed degradation EXACTLY after below line,
"
------------------------ aborting loop because EDIFF is reached ----------------------------------------
"
the post here,
http://cms.mpi.univie.ac.at/vasp-forum/ ... hp?3.11267


I experienced that is because of lack of memory.
Memory consumption depends on the size of system and kpoints, ISPIN options or memory related algorithm options.

If there are enough RAM space, it runs fast without problem.
If there are not enough RAM space but enough SWAP space, it runs extremely slow after "that last line" but makes results finally.
If there are not enough RAM and SWAP space, the calculation job just stops after "that last line".

This is a problem I experienced during using vasp 5.2.12.
There is no problem with vasp 4.6.36.

The memory usage suddenly increases after "that last line", when using vasp 5.2.12.
vasp 4.6.34 does not show that behavior. It uses constant memory.

Can you try that calculation with vasp 4.6.36?




[/quote]

Indeed, I tried the same calculations with VASP 4.6.36 the memory demand was completely constant and the calculations finished succesfully.

Could anyone comment on why this peak appears when using VASP5?

[gevolo]

http://cms.mpi.univie.ac.at/vasp-forum/ ... hp?3.12143

This is interesting if anyone has the above problem...