If you do not find the error listed here, or the solution does not resolve your problem you can also check out the error-wiki.
VERY BAD NEWS! internal error in subroutine SGRCON:
Found some non-integer element in rotation matrix 2
This error is symmetry related. In the VASP forum the suggested solution is to increase the SYMPREC parameter. An alternative solution which also works but may be safer from the accuracy point of view (and increases the computational cost) is to switch of symmetry by setting ISYM = 0.
WARNING: Sub-Space-Matrix is not hermitian in DAV
combined with one of the following:
- Error FEXCP: supplied Exchange-correletion table is too small
- BRMIX: very serious problems, the old and the new charge density differ
This error occurs at the start of a “new” calculation and keeps popping up no matter how you modify your INCAR. This error seems to be linked to “small” systems as well, i.e. if you divide the number of bands used by the number of cores you often get a rather small value (e.g. <5). As a result, reducing the number of cores on which the calculation is performed seems to resolve the problem, stabilizing the calculation. (e.g. mympirun -h 14 vasp on a system with 28 cores/node, or increase KPAR such that fewer cores work on a single k-point)
VERY BAD NEWS! internal error in subroutine PRICEL (probably precision problem, try to change SYMPREC in INCAR ?):
Sorry, number of cells and number of vectors did not agree. 2
This error is also symmetry related. According to the VASP-masters it can pop up for a super cell with high symmetry atomic positions. For some reason part of the symmetry algorithm can not recognize the cell as being primitive. The suggested solution is to move one such highly symmetric atom slightly off, breaking the symmetry of the cell. However when you are optimizing a geometry this may not be the way you want to go (as it feels rather counterproductive). Two other suggested solutions (which both worked in my problem case with a MOF) that can work are: (1) Increase SYMPREC = 1.0E-8 (default is 1.0E-5) or (2) switch off symmetry altogether by setting ISYM = 0. As option 2 switches off the use of symmetry altogether, I believe this option should always work, as it may just skip the problematic part of the program.
VASP refuses to read (some) parameters from the INCAR file.
VASP is rather sturdy when it comes to input. Every parameter has a default value, and as such even an empty INCAR file is sufficient to start a calculation (albeit not a good idea). However, sometimes it looks like VASP just plainly refuses to read parameter value from the INCAR file. There are a few possible reasons for this:
- You made a typo in the parameter name (e.g. ICHARGE instead of ICHARG)
- You have multiple instances of the same parameter. This can easily happen if you have a large INCAR file. In such a case VASP will use the value of the first instance of the parameter.
- You used a double tab to start the line. This is a rather interesting feature a student ran into during a project (He noticed his ENCUT scan gave the exact same result for all ENCUT values.) Apparently, if you use 2 tabs to start a line VASP ignores the parameter. One tab seems not to be a problem. Adding additional spaces after the double tab doesn’t resolve the problem either. How can you distinguish between a double tab and a set of spaces? Open your INCAR file using midnight commander (and F4), and you will find double tabs indicated as “<—–>” symbols. Note: this feature was found in VASP 5.4 and 5.3 .
A single atom calculation refuses to converge in energy.
You can help VASP by setting (or guessing) the electronic structure more accurately:
- NUPDOWN parameter: set the difference between up and down electrons.
- FERWE and FERDO parameters: more stringent than the option above, you can tell VASP what the specific occupations of the up and down orbitals should be. And you may even want to fix these partial occupancies using ISMEAR = -2
- ALGO = All : Instead of the usual Davidson algorithm you could use a conjugate gradient algorithm to optimise the electronic structure. Use a step (smaller than the default) be setting TIME = 0.1. However, chance are you will end up with convergence problems in the Rotation steps (only shown in the standard output, not in the OSZICAR file. A way to avoid this is by switching of subspace rotations all-together: LSUBROT = .FALSE.. This may start to sound fishy, but normally you should have crossed the sign “desperate” already a few times before you arrive at this point. 😉
Internal error in SETUP_DEG_CLUSTERS: NB_TOT exceeds NMAX_DEG
increase NMAX_DEG to 107
This is a rather unpleasant error you may encounter when performing phonon calculations (IBRION = 7 or 8). It is one of these cases where you extend beyond the range of a hard coded array size. The first thing to try is to perform the modification suggested. This means, go to your VASP source and increase the hard-coded limit.(source)
- #go to the source directory of the VASP code
- cd $HOME/source/vasp.5.4.1/src/
- # find the location of the offending parameter, note that you modify the *.F files as these are preprocessed to .f90 files
- grep NMAX_DEG *.*
- #You find "subrot_cluster.F: INTEGER, PARAMETER :: NMAX_DEG=48"
- #modify the code with your prefered editor (do not use windows as this will introduce EOLN characters)
- nano subrot_cluster.F
- #-----before-----line 272 (Ctrl + i, 272) INTEGER, PARAMETER :: NMAX_DEG=48
- #-----after------line 272 INTEGER, PARAMETER :: NMAX_DEG=256
- cd ../
- make veryclean
- make all
This will quite often solve the problem. However, it will not do this always, and it could be that during your next run you just get the same error but this time with an even higher suggested value (in my case it went from 107 to 320). You could of course keep recompiling the code until the issue stops, but there is a chance it will never happen. What you can try as well is change your problem. In my specific case I was looking at fcc Al using a conventional cell. By changing to a primitive cell, I was able to resolve my problem.
The distance between some ions is very small please check the nearest neigbor list in the OUTCAR file
I HOPE YOU KNOW, WHAT YOU ARE DOING
Check the OUTCAR file to make sure this is what is going on. If this should not be the case, you should check your POSCAR file. Visualizing your POSCAR (e.g. using VESTA) can be an easy way to find the culprit atom. However, if the problematic atom is the result of two atoms having exactly the same position, you may end up checking the POSCAR file manually. If you are sure your POSCAR is correct and should not give rise to this error, you may also want to check your POTCAR file. VASP doesn’t care which atomic types you define in your POSCAR file, it just takes what it finds in the POTCAR file, and gives no warning message in case of discrepancies. Make sure that your C atoms are C atoms, and not Pt for example.
(Non-convergence of the energy of a slab)
The calculation of a slab has a very hard time converging electronically. The augmentation part seems to vary wildly during the ionic step.
Your surface-system is behaving badly, and other solutions such as manually setting mixing-tags (AMIX, BMIX, AMIX_MAG, BMIX_MAG), tweaking the algorithm (ALGO = All), or playing with the smearing (ISMEAR and SIGMA) show no improvement or even worsen the behavior. In case you have your slab located at the center of your unit cell (in contrast to symmetric around z=0), and you have dipole-corrections switched on (LDIPOL = .TRUE. , IDIPOL = 3 ), switching these off may be the trick to stabilize these calculations.
internal error in SET_INDPW_FULL: insufficient memory (see wave.F safeguard)
Trying to modify the accuracy settings, or other setting influencing memory usage seem not to resolve this problem. The solution was luckily provided by the VASPmasters : decrease the SYMPREC parameter in the INCAR file to a value of 1e-4. The problem apparently originated in a symmetry-breaking 5th digit in the Bravais matrix. In case the error occurs for HSE06 calculations, this can be due to a too small value of NPAR. Try setting NPAR = #cores such that NPAR * KPAR = Total number of cores in the calculation. Although tthis is a suggested setting, one may opt to use NPAR=1 as it speeds up calculations significantly.
In case of a continuation job, your calculation starts but hangs during initialization. The last thing you find in the standard out is:
charge-density read from file: $SomeFileName
magnetization density of overlapping atoms calculated
Everything seems alright. All your files are present and all input parameters in the INCAR file are spelled correctly. Your CHGCAR is present and is not empty. It seems like sometimes the CHGCAR file can be corrupt (i.e. not written entirely due to running into the walltime, etc) and then VASP seems to just keep waiting for the missing data to be read. While this is happening your calculation time just runs out. Easy solution: Delete the CHGCAR file and start without one or an entirely empty CHGCAR (e.g. created by touch CHGCAR)