RMIX: very serious problems / the old and the new charge density differ

Message

lahaye · #1 Post by **lahaye** » Thu Jul 06, 2006 6:24 am

Hello,

I run the serial version of VASP 4.6.28 on an itanium based HP-UX
system. I start with a clean input (only INCAR, KPOINTS, POSCAR and
POTCAR). In the middle of the electronic relaxation, I get this message:

Code: Select all

BRMIX: very serious problems
 the old and the new charge density differ
 old charge density:   128.00000 new  127.99784

Why is there suddenly a problem with the charge density?
Or is this a mathematical inaccuracy?
(I'm using HP-UX lapack and veclib libraries).

Can someone help me understand what is the problem here?

Input and output files are here:

http://surfion.snu.ac.kr/~lahaye/vasp

Thank you,
Rob.

#2 Post by **admin** » Fri Jul 07, 2006 11:42 am

1) please have a look whether the grid for the Broyden mixing is lage enough
(WARNING: grid for Broyden might be to small in OUTCAR). If so, increase PREC and check if the error persists
2) in case you use a tetrahedron method for BZ integration your k-mesh should be large enough to fill the (I)BZ with tetrahedra completely

lahaye · #3 Post by **lahaye** » Sun Jul 09, 2006 2:35 pm

I'm using Monkhorst-Pack for the K-point sampling.

But yes indeed, I have this broyden warning in my OUTCAR file:

Code: Select all

$ grep "WARNING: grid for Broyden" OUTCAR 
  WARNING: grid for Broyden might be to small

However, my PREC setting is already "High".
This should be highest setting, right?
Also, this problem seems to occur on my HP-UX system
only; similar calculation on Linux system goes fine.

Is there something known about HP-UX related issues?

Thanks,
Rob.

PS: typo in the WARNING message: s/to/too/

uludogan · #4 Post by **uludogan** » Tue Feb 13, 2007 8:10 pm

Hi ,
I upgraded vasp version from 4.6.27 to 4.6.31 and compiled it with ifc 9.1. With the new executables, I had the same problem on an SGI itanium machine with intel compilers,
BRMIX, old and new charge density problem. So it seemed to me that something was wrong with the compilation because with the same inputs, I did the calculations on different arthitectures without any problem.. So I decreased the intel fortran compiler version level to 9.0.
Now everthing seems to be fine. No BRMIX problem.
NB: I only had this problem on SGI Itanium. On Linux EM64t machines withifc 9.1 , I have no problem.
Mustafa

pavel · #5 Post by **pavel** » Mon Jul 23, 2007 3:17 pm

Hi, all
I have the same problem with vasp serial version 4.6.31 compiled with IBM xlf90 10.1.0.5 compiler.
The error occurs already by running benchmark test supplied with VASP.
On other machines there was no this error

pavel · #6 Post by **pavel** » Wed Jul 25, 2007 2:52 pm

The problem disappears after reducing optimization level from -O4 to -O3.

michaeleric.williams · #7 Post by **michaeleric.williams** » Fri Dec 07, 2007 3:33 pm

I am having the same problem on Linux EM64T machine. I am using intel fortran compiler 10.1.008. It works with serial version just fine, but the parallel version only works if I reduce optimization flag to -01 at which point the serial version is faster anyways.

hatdau · #8 Post by **hatdau** » Mon Apr 12, 2010 6:57 am

[quote="admin"]1) please have a look whether the grid for the Broyden mixing is lage enough
(WARNING: grid for Broyden might be to small in OUTCAR). If so, increase PREC and check if the error persists
2) in case you use a tetrahedron method for BZ integration your k-mesh should be large enough to fill the (I)BZ with tetrahedra completely[/quote]

Increase KPOINT mesh and it helped.

chenweiguang · #9 Post by **chenweiguang** » Mon Apr 19, 2010 7:07 am

Add the item "ADDGRID = TRUE"

albertg · #10 Post by **albertg** » Fri Feb 25, 2011 10:54 am

Set ISYM = 0 explicitly in the INCAR file. (I had ADDGRID added as well). Helped me with VASP 4.6 and VASP 5.2.2

huberl · #11 Post by **huberl** » Tue May 07, 2013 10:06 am

I have run into this problem before and just hit it again. I know this thread is a little old, but for me it is the top google result when searching the error, so it is maybe useful to contribute.

I most recently ran into this running simple bulk Al in a 3x3x3 supercell. It happened at a variety of kmeshes, and didn't happen at all when I was using basically the same settings on a 4x4x4 supercell.

Like albertg, I found that decreasing the symmetry solved the problem, but I found that it was sufficient to merely offset one of my atoms' initial position just a little bit. This is I think less expensive than turning off symmetry, so hopefully it is helpful to you.

I'm still not sure what caused the problem to start with...bulk Al is basically as simple as it gets :p

Cheers

shuo_tao · #12 Post by **shuo_tao** » Fri Jun 02, 2023 4:50 pm

Same issue here, set ISYM=0 do solve the problem

My Community