In general, the energy-cut-off must be chosen according to the pseudopotential. All POTCAR files contai an default energy cutoff. Use this energy cut-off - but please also perform some bulk calculations with different energy cut-off to find out whether the recommended setting is correct. The cut-off which is specified in the POTCAR file will usually result in an error in the cohesive energy which is less than 10 meV.
You should be aware of the difference between absolute and relative convergence. The absolute convergence with respect to the energy cut-off ENCUT is the convergence speed of the total energy, whereas relative convergence is the convergence speed of energy differences between different phases (e.g. energy of fcc minus energy of bcc structure). Energy differences converge much faster than the total energy. This is especially true if both situations are rather similar (e.g. hcp -- fcc). In this case the error due to the finite cut-off is 'transferable' from one situation to the other situation. If two configurations differ strongly from each other (different distribution of s p and d electrons, different hybridization) absolute convergence gets more and more critical.
There are some rule of thumbs, which you should check whenever making a calculation: For bulk materials the number of plane waves per atom should be between 50-100. A smaller basis set might result in serious errors. A larger basis set is rarely necessary, and is a hint for a badly optimized pseudopotential. If a large vacuum is included the number of plane waves will be larger (i.e. of your supercell vacuum number of plane waves increases by a factor of 2).
More problematic than ENCUT is the choice of the FFT-mesh, because this error is not easily transferable from one situation to the next. For a exact calculation the FFT-mesh must contain all wave vectors up to if , being the used energy-cut-off. Increasing the FFT-mesh from this value does not change the results, except for a possibly very small change due to the changed exchange-correlation potential. The reason for this behavior are explained in section 9.2. To generate a param.inc file which avoids any wrap around error with the makeparam utility one had to specify PREC=High in the INCAR file (section 6).
Nevertheless it is not always possible and necessary to use such a large FFT-mesh. In general only 'high quality' calculations (as defined in the previous section) require a mesh which avoids all wrap around errors. For most calculations -- and in particular for the supplied pseudopotentials with the default cutoff -- it is sufficient to set NGX,NGY and NGZ to 3/4 of the required values (set PREC=Medium or PREC=Low in the INCAR file before running the makeparam utility or vasp.4.X). The values which strictly avoid any wrap-around errors are also written to the OUTCAR file:
WARNING: wrap around error must be expected set NGX to 22 WARNING: wrap around error must be expected set NGY to 22 WARNING: wrap around error must be expected set NGZ to 22Just search for the string 'wrap'. As a rule of thumb the 3/4 will result in FFT-mesh, which contain approximately 8x8x8=256 FFT-points per atom (assuming that there is no vacuum).
One hint, that the FFT mesh is sufficient, is given by the lines
soft charge-density along one line 0 1 2 3 4 5 6 7 8 x 32.0000 -.7711 1.9743 .0141 .3397 -.0569 -.0162 -.0006 .0000 y 32.0000 6.7863 .0205 .2353 .1237 -.1729 -.0269 -.0006 .0000 z 32.0000 -.7057 -.7680 -.0557 .1610 -.2262 -.0042 -.0069 .0000also written to the file OUTCAR (search for the string 'along'). These lines contain the charge density in reciprocal space at the positions
The last number will be always 0 (it is set explicitly by VASP), but as a rule of thumb the previous value divided by the total number of electrons should be smaller than . To be more precise: Because of the wrap-around errors, certain parts of the charge density are wrapped to the other side of the grid, and the size of the ``wrapped'' charge density divided by the number of electrons should be less than .
Another important hint that the wrap around errors are too large is given by the forces. If there is a considerable drift in the forces, increase the FFT-mesh. Search for the string 'total drift' in the OUTCAR file, it is located beneath the line TOTAL-FORCE:
total drift: -.00273 -.01048 .03856The drift should definitely not exceed the magnitude of the forces, in general it should be smaller than the size of the forces you are interested in (usually 0.1 eV/ ).
For the representation of the augmentation charges a second more accurate FFT-mesh is used. Generally the time spent for the calculation on this mesh is relatively small, therefore there is no need to worry too much about the size of the mesh, and relying on the defaults of the makeparam utility is in most cases save. In some rare cases like Cu, Fe_pv with extremely 'hard' augmentation charges, it might be necessary to increase NGXF in comparison to the default setting. This can be done either by hand (setting NGXF in the param.inc file) or by giving a value for ENAUG in the INCAR file 7.6.
As for the soft part of the charge density the total charge density (which is the sum of augmentation charges and soft part) is also written to the file OUTCAR:
total charge-density along one line 0 1 2 3 4 5 6 7 8 x 32.0000 -.7711 1.9743 .0141 .3397 -.0569 -.0162 -.0006 .0000 y 32.0000 6.7863 .0205 .2353 .1237 -.1729 -.0269 -.0006 .0000 z 32.0000 -.7057 -.7680 -.0557 .1610 -.2262 -.0042 -.0069 .0000The same criterion which holds for the soft part should hold for the total charge density. If the second mesh is too small the forces might also be wrong (leading to a 'total drift' in the forces).
Mind: The second mesh is only used in conjunction with US-pseudopotentials. For normconserving pseudopotentials neither the charge density nor the local potentials are set on the fine mesh. In this case set NG(X,Y,Z)F to NGX,Y,Z or simply to 1. Both settings result in the same storage allocation.
Mind: If very hard non linear/partial core corrections are included the convergence of the exchange-correlation potential with respect to the FFT grid might cause problems. All supplied pseudopotentials have been tested in this respect and are save.