VASP errors

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.

 

Sub-Space-Matrix is not hermitian

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)

 

 

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.