分类：
2012-02-13 16:39:35
有时，VASP在电子自洽计算的中间步骤中会出现如下的错误
WARNING: DENTET: can't reach specified precision
Number of Electrons is NELECT = 196.0137087990377
RMM: 7 -0.461353114525E+03 0.15540E+03 -0.29356E+02 6562 0.456E+01BRMI
X: very serious problems
the old and the new charge density differ
old charge density: 195.99999 new 196.01370
0.758E+01
RMM: 8 -0.228026134405E+03 0.23333E+03 -0.10404E+02 4963 0.286E+01BRMI
X: very serious problems
the old and the new charge density differ
old charge density: 196.01370 new 195.99999
0.376E+01
出现此警告(DENTET)的原因是因为无法通过tetrahedron方法得到足够精确的费米能级。也就是将态密度积分到费米面的电子数和体系的价电子数目不一致。可以尝试采用以下方法得以解决此问题：
a)选择另一种布里渊区内的积分方法(改变ISMEAR)
计算中Sub-Space-Matrix is not hermitian in DAV的错误
我在计算界面体系时候，其他计算条件不变，仅改变了一些k格点数，就一直提示如下的错误：
DAV: 13 -0.242323773333E+03 0.98155E+02 -0.87140E+01 48832 0.949E+01BRMIX: very serious problems
the old and the new charge density differ
old charge density: 252.00012 new 252.29979
0.809E+01
DAV: 14 -0.392866843695E+03 -0.15054E+03 -0.76122E+01 50857 0.731E+01BRMIX: very serious problems
the old and the new charge density differ
old charge density: 252.29979 new 252.48257
0.484E+01
WARNING: Sub-Space-Matrix is not hermitian in DAV 9
0.133520549894753
WARNING: Sub-Space-Matrix is not hermitian in DAV 17
495.153990161108
WARNING: Sub-Space-Matrix is not hermitian in DAV 6
0.250235927490523
WARNING: Sub-Space-Matrix is not hermitian in DAV 9
1876.75162244581
解决办法只需调整 AMIX, BMIX的值，把他们设置小一些。
Message of " Sub-Space-Matrix is not hermitian "
Moderators: admin.
Author
Post
Tue May 23 2006, 02:59PM
Registered Member #523
Joined Tue Jan 10 2006, 12:13PM
posts 4
Hi,
I do calculations for transition metals with respect to primitive
monoclinic structure containing 16 atoms. VASP runs in the cluster and
uses 4 processors. The INCAR is listed below:
SYSTEM = A12
ENCUT = 330
EDIFF=0.000001
ISMEAR =1
SIGMA = 0.1
IBRION=2
ISIF=3
NSW=1000
EDIFFG = -0.01
AMIX = 0.02
During
the electronic structure relaxation, it always display lots of warning
messages “WARNING: Sub-Space-Matrix is not hermitian in DAV 4” and
eventually the calculation fails with such error message “Error EDDDAV:
Call to ZHEGV failed. Returncode = 47 315”
As seen, I set AMIX from the default value of 0.4 to 0.02, and the problem still exists.
What is the reason and how can I avoid such problem?
Many thanks.
Tue May 23 2006, 03:45PM
posts 1693
there may be several reasons for this error, the most common are
1a) the input geometry was not reasonable (error occurs at the very first ionic step) or
1b) the last ionic relaxation step lead to an unreasonable geometry (compare the input and output geometries of the
last ionic relaxation steps). In that case it can be helpful to
--> switch to a different relaxation algorithm (IBRION-tag)
--> reduce the step size of the first step by setting POTIM explicitely
2) If this error shows up at all
your calculations: The installation of the LAPACK on your machine was
not done properly: use a different LAPACK, e.g. the LAPACK which is
delivered with the code
(vasp.4.lib/lapack_double.o)
3) on some architectures (especially SGI) some Lapack
routines are not working properly. However, it is
possible to avoid the usage of the ZHEGV subroutine
by commenting the line #define USE_ZHEEVX in
davidson.F, subrot.F, and wavpre_noio.F and recompiling
VASP.
Tue May 30 2006, 04:47PM
Registered Member #544
Joined: Tue Jan 24 2006, 04:13PM
posts 5
I got the same problem.
If you are using vasp 4.6. Try using "IALGO =48" in the INCAR file.
It solved the problem for me.
Sun Jan 07 2007, 07:06PM
Registered Member #760
Joined: Mon Jul 03 2006, 12:48PM
Location: Madrid
posts 10
Hi,
I
got the same problem on a sgi machine when running the Cu benchmark.
Changing to IALGO=48 just changed the problem; then I get the messages:
.............
lib-4201: UNRECOVERABLE library error.
Encountered during a direct access unformatted READ from unit 21.
Fortran unit 21 is connected to a direct unformatted unblocked file: "TMPCAR"
IOT trap
core dumped
.....................
These messages appeared after 20 cycles of RMM: and one line beginnig with
1 T= 2080. E= -.90209009E+04 E0=...
Please
help to solve. Concerning previous admin comments I should say that in
the davidson, subrot and wavpre_noio files the variable "USE_ZHEEVX"
does not control whether ZHEGV is used or not; this seems to depend
rather on the definition of the variable "gammareal".
Wed Jan 24 2007, 03:05PM
posts 1693
1) if you set USE_ZHEEVX
DSYEVX instead of DSYEV is used if gamma_real
ZHEEVX ZHEEV all other cases.
so it does not only affect the gamma-real version.
2) please have a look to the FAQs of the manual:
(,
"I am running VASP on a SGI Origin, and the ...)
set IWAVPR=10
Mon Feb 19 2007, 06:27PM
Registered Member #760
Joined: Mon Jul 03 2006, 12:48PM
Location: Madrid
posts 10
Hi,
I
continue to have the previously reported problem found when trying to
run the Cu benchmark on a sgi machine, i.e. the program aborts and the
output ends with a series of lines such as
entering main loop
N E dE d eps ncg rms
rms(c)
WARNING: Sub-Space-Matrix is not hermitian in DAV 1, -18.497193968206293
WARNING: Sub-Space-Matrix is not hermitian in DAV 2, -106.6910638174717
WARNING: Sub-Space-Matrix is not hermitian in DAV 3, -3.4046873909742339
WARNING: Sub-Space-Matrix is not hermitian in DAV 4, -37.403094929979197
WARNING: Sub-Space-Matrix is not hermitian in DAV 5, 0.14502948098981785
followed by
Error EDDDAV: Call to ZHEGV failed. Returncode = 13 1 8
The
earlier solution suggested by admin (suppressing the line #define
USE_ZHEEVX in davidson.F, subrot.F, and wavpre_noio.F and recompiling
VASP) does not work, i.e. the same error messages, and the same
indication of ZHEGV failure, still appear. I may add now that the
problem appears both with the lapack which comes with VASP and with a
system-native lapack library.
The warnings given suggest that
the problem actually appears at an earlier stage, in which a matrix is
generated with inadequate values which make it nonhermitian, and
consequently ZHEGV fails even if working correctly; the solution thus
would not be to avoid using ZHEGV, but to avoid an incorrect generation
of the said matrix.
Can someone give an idea to really solve the problem?
Tue Feb 20 2007, 04:01PM
Registered Member #248
Joined: Wed Jun 15 2005, 11:57AM
Location: Montreal
posts 35
Please try if it works by adding "LSCALAPACK = .FALSE." in your INCAR.
Tue Feb 20 2007, 04:03PM
Registered Member #248
Joined: Wed Jun 15 2005, 11:57AM
Location: Montreal
posts 35
Please try if it works by adding "LSCALAPACK = .FALSE." in your INCAR.
Wed Feb 21 2007, 12:04AM
Registered Member #760
Joined: Mon Jul 03 2006, 12:48PM
Location: Madrid
posts 10
No; adding "LSCALAPACK = .FALSE." in INCAR makes no dfference, the problem continues the same.
Sat Feb 21 2009, 07:11AM
Registered Member #2102
Joined: Thu Feb 28 2008, 01:30AM
Location: VIETNAM
posts 1
I was successful to fix this problem by using IALGO=48 instead of IALGO=Default
Fri Mar 06 2009, 10:15AM
Registered Member #917
Joined: Fri Oct 13 2006, 02:04PM
posts 3
unfortunately, when i set IALGO=48, the new warning is
WARNING in EDDRMM: call to ZHEGV failed, returncode = 6 314
how to solve this problem?
what does "ZBRENT" mean?
Moderators: admin.
Author
Post
Tue Oct 17 2006, 06:14AM
Registered Member #537
Joined Mon Jan 23 2006, 07:12AM
posts 2
Hi,
I relaxed a molecular system with 39 atoms, using ISMEAR = 0, SIGMA = 0.02, IBRION = 2, POTIM = 0.5.
Then I found some messages like
" ZBRENT: increasing intervall"
" ZBRENT: bracketing found"
" ZBRENT: interpolating"
" ZBRENT: can't locate minimum, use default step"
at the end of some ionic steps in the log file.
Could anyone tell me what these messages mean?
Thank you in advance.
Sinderely,
Kertick
Wed Oct 18 2006, 04:23PM
posts 1693
ZBRENT is an algorithm search for a root of a function by Brent's method: Numerical recipies, Section 9.3
The
problem in your case might be that the Conjugate Gradient algorithm
(IBRION=2) is not suitable for very small corrections of the atomic
positions if your system has almost reached equilibrium (please have a
look at XDATCAR to check the size of the relaxation steps done before
the ZBRENT warnings show up). Usually it is sufficient to converge a
system up to maximum remaining forces of about 0.01eV/A (EDIFFG=-0.01).
please try one of the following:
1) choose a different algorithm for ionic optimization (IBRION=1)
2) set ADDGRID=.True. in INCAR (only for vasp releases 4.4.5 and newer)
