摘自：http://blog.sina.com.cn/s/blog_606de31f0100k0m8.html 

问题1： 优化的结果已经很好了，但OUTCAR在似乎快要成功时异常终止，

/home/yexq/shanghai-opt/schx/sch3-opt2013-done/sch3-20G3f-2-SG8-Cm>

优化结果：

2501.01    41.79    28.96725655   OUTCAR_2500 *

2999.57    39.57    41.63901053   OUTCAR_3000 *

log文件提示：

      N       E                     dE             d eps       ncg     rms          rms(c)

DAV:   1    -0.362357753721E+02    0.14459E-01   -0.91127E-03 32032   0.150E+00    0.637E-02

DAV:   2    -0.362357515109E+02    0.23861E-04   -0.48738E-04 43568   0.199E-01    0.387E-02

DAV:   3    -0.362357260128E+02    0.25498E-04   -0.47978E-05 49296   0.858E-02    0.597E-03

DAV:   4    -0.362357260555E+02   -0.42743E-07   -0.22434E-06 27424   0.155E-02

 53 F= 0.28967257E+02 E0= 0.28966922E+02  d E =0.668547E-07

curvature:   0.00 expect dE= 0.171-306 dE for cont linesearch  0.320-307

ZBRENT: fatal error in bracketing

    please rerun with smaller EDIFF, or copy CONTCAR

    to POSCAR and continue

解决方案：局域优化，一次是不够的

(1) 例如下面的250GPa的情形

2500.08    41.31    46.63201555   OUTCAR_2500  ***

2999.88    38.88    46.99778506   OUTCAR_2500-01 ***

2999.82    38.88    59.13143639   OUTCAR_3000

2999.93    38.88    59.13145484   OUTCAR_3000-01

3499.71    36.91    70.94854669   OUTCAR_3500

3499.93    36.91    70.94855966   OUTCAR_3500-01

3999.78    35.27    82.20209796   OUTCAR_4000

4000.06    35.27    82.20210915   OUTCAR_4000-01

/////

OUTCAR_2500:                  Total CPU time used (sec):     2381.285

OUTCAR_3000:                  Total CPU time used (sec):       75.225

OUTCAR_3000-01:                  Total CPU time used (sec):     1961.047

OUTCAR_3500:                  Total CPU time used (sec):       69.272

OUTCAR_3500-01:                  Total CPU time used (sec):     3022.837

OUTCAR_4000:                  Total CPU time used (sec):       75.249

OUTCAR_4000-01:                  Total CPU time used (sec):     2452.477

(2)

# start calculation

$MPIDIR/mpirun -np $NP -machinefile $CURDIR/.nodelist $EXEDIR/vasp  > STDOUT

cp CONTCAR CONTCAR_$i-01

cp OSZICAR OSZICAR_$i-01

cp OUTCAR OUTCAR_$i-01

cp STDOUT STDOUT_$i-01

cp CONTCAR POSCAR

# 2nd

$MPIDIR/mpirun -np $NP -machinefile $CURDIR/.nodelist $EXEDIR/vasp  > STDOUT

cp CONTCAR CONTCAR_$i-02

cp OSZICAR OSZICAR_$i-02

cp OUTCAR OUTCAR_$i-02

cp STDOUT STDOUT_$i-02

cp CONTCAR POSCAR

# 3rd

$MPIDIR/mpirun -np $NP -machinefile $CURDIR/.nodelist $EXEDIR/vasp  > STDOUT

cp CONTCAR CONTCAR_$i-02

cp OSZICAR OSZICAR_$i-02

cp OUTCAR OUTCAR_$i-02

cp STDOUT STDOUT_$i-02

cp CONTCAR POSCAR

# 4th

$MPIDIR/mpirun -np $NP -machinefile $CURDIR/.nodelist $EXEDIR/vasp  > STDOUT

wait

问题2：LAPACK: Routine ZPOTRF failed

/home/xy83/work/strucSearch/optimization/done-opt/schx-opt/sch8-9-10-11/sch6-100G2-4f-11_63-cmcm

(1)  Log_2000

curvature: -12.99 expect dE=-0.220E+06 dEfor cont linesearch -0.734E+02

ZBRENT: increasingintervall

opt: ********  next Energy=  -452.895825 (dE=-0.463E+03)

bondcharge predicted

LAPACK: Routine ZPOTRF failed!           1           1           1

LAPACK: Routine ZPOTRF failed!           1           1           1

LAPACK: Routine ZPOTRF failed!           1           1           1

LAPACK: Routine ZPOTRF failed!           1           1           1

 IBRION=1，remove sym ; optm=0.1  increase;

Prasad解答（见【】部分）：

该错误一般是由于电荷重叠引起的或对称性不匹配引起的

for i in 2000 2500  

do

cat > INCAR << EOF

SYSTEM = Various- local optimisation

PREC = Accurate

ENCUT = 400.0   【增加ENCUT,如 460 eV】

EDIFF = 1e-6

EDIFFG = -1e-3

#SYMPREC=1e-6

IBRION = 2   【改变IBRION方式，如IBRION=1】

POTIM = 0.05   【增加POTIM如，POTIM=0.1】【为加快收敛，可以减小KPOINTS】

ISIF = 3 【对于包含20几个原子的体系，8个核优化，一个结构耗时~20h正常】

NSW = 100  【或改动/调整POSCAR中atomi position，例如改动小数点后的第5位及其以后的数值】

PSTRESS = $i

ISMEAR = 1

SIGMA = 0.2

ISYM = 0

LCHARG = FALSE

LWAVE = FALSE

#LREAL= FALSE

EOF

1Q.                                                                                                                                                                                                                                                                                                                                          

fatal internal in brackting                                                                                                                                                                                                                                                                                                                  

system-shutdown; contact gK immediately                                                                                                                                                                                                                                                                                                      

1A1.                                                                                                                                                                                                                                                                                                                                        

    this message says that during geometry optimisation no reasonable next step could be found with Brent's algorithm (linear bisectioning), please check the following                                                                                                                                                                          

1) is the system converged already? (look at the forces in OUTCAR, especially if you use the total energy change as congvergence criterium for ionic optimisation)                                                                                                                                                                            

2) if not: is each ionic step converged electronically ( this is needed to obtain reasonable forces)                                                                                                                                                                                                                                          

1A2.                                                                                                                                                                                                                                                                                                                                        

   Sometimes, if the calculation is already highly converged, vasp cannot interpolate the next step to within the numerical accuracy because it simply would be so small. (this behaviour is machine-dependent). If you have used IBRION=2, it may help to switch to IBRION=1 and set ADDGRID=.true. in addition.                                

1A3.                                                                                                                                                                                                                                                                                                                                          

    This error occurs if the next ionic step cannot be estimated with the ZBRENT algorithm (the algorithm is documented in the Numerical Recipies).                                                                                                                                                                                              

       --) you seem to be at the energy minimum of the parabola already (curvature=0.00,....):                                                                                                                                                                                                                                              

For most applications a geometry can be regarded as converged if the maximum remaining forces are less than 0.01 eV/AA, therefore EDIFFG = -1e-02 is a reasonable choice. Please check the forces of your last ionic step (in OUTCAR)                                                                                                        

       --) Please also have a look at the XDATCAR file: If the ionic step sizes have become very small already, the GC algorithm may fail to extrapolate the next step (---> switch to IBRION = 1 instead)                                                                                                                                  

       --) If you want to increase the accuracy of the calculated forces even more, set ADDGRID = .True. in INCAR.  

2Q.                                                                                                                                                                                                                                                                                                                                          

      LAPACK: Routine ZPOTRF failed                                                                                                                                                                                                                                                                                                        

2A.                                                                                                                                                                                                                                                                                                                                  

      1) most probably, the forces of the first+second ionic steps lead to an unreasonable geometry for the third step (huge differences in the total energies!), which could not be converged electronically. (ie this is no LAPACK error, but just an unreasonable setup for that ionic step)                                              

       to check:                                                                                                                                                                                                                                                                                                                            

      --) please have a look at the FORCES on the atoms at the end of ionic step #1 and #2, and the corresponding geometry changes which gave the input geometry for step #3 (the input geometries of each step are listed in XDATCAR). If the ions move too much, the wave function prediction may fail)                                    

      --) please reduce POTIM and/or use a different ionic relaxation algorithm (IBRION).                                                                                                                                                                                                                                                    

 3Q.                                                                                                                                                                                                                                                                                                                                  

      WARNING in EDDRMM: call to ZHEGV failed                                                                                                                                                                                                                                                                                                

    3A.                                                                                                                                                                                                                                                                                                                                    

 the error is due to a LAPCK call (ZHEGV): ZHEGV computes all the eigenvalues, and optionally, the eigenvectors of a complex generalized Hermitian-definite eigenproblem . there may be several reasons for that error:                                                                                                                      

 1) the RMM-DIIS diagonalisation algorithm is not stable for your specific setup of the calculation.                                                                                                                                                                                                                                        

--> use ALGO = Normal (blocked Davidson) or ALGO = Fast (5 steps blocked Davidson, RMM-DIIS)                                                                                                                                                                                                                                                  

 2) a) maybe your input geometry was not reasonable (error occurs at the very first ionic step, please have a look for the geometry data of your run in OUTCAR ) or b) the last ionic relaxation step lead to an unreasonable geometry (compare the input and output geometries of the last ionic relaxation steps in XDATCAR).              

    In that case (2b) it can be helpful to                                                                                                                                                                                                                                                                                                  

--> switch to a different relaxation algorithm (IBRION-tag)                                                                                                                                                                                                                                                                                  

--> reduce the step size of the first step by setting POTIM smaller than the default value                                                                                                                                                                                                                                                    

 3) The installation of the LAPACK on your machine was not done properly: use the LAPACK which is delivered with the code (vasp.4.lib/lapack_double.o)                                                                                                                                                                                      

 4) If the error persist although you switched to the Davidson algorithm: 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.

4Q.                                                                                                                                                                                                                                                                                                                                          

      p4_error: net_recv read:  probable EOF on socket: 1                                                                                                                                                                                                                                                                                    

  4A.                                                                                                                                                                                                                                                                                                                                        

I'm not the expert on this, but as best I understand it this is a fairly generic MPICH error which says a task tried to receive and the process it tried to receive from has gone away.  More often than not, unless you have lots of OTHER error messages, this is some kind of program error (IOW, *your* program's error).                

There are so many ways your program could be failing there is no way to do a reasonable job of telling you what to look for, but usually adding some kind of debugging output to your code will help.  If you can isolate which task is failing, you can crash it in gdb and see exactly where and why it crashed.                          

Since this is probably your code, there isn't a generic solution,and that's why it isn't posted.                                                                                                                                                                                                                                              

5Q:

ERROR FEXCP: supplied Exchange-correletion table

5A:

6Q:

the old and the new charge density differ

6A:

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

2) 增大K点。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