4.5 Restrictions in vasp.4.X and restrictions due to parallelization

 

In most respects vasp.4.X should behave like vasp.3.2. However in vasp.4.4, IALGO=48 was redesigned to work more reliable in problematic cases. Therefore the iteration history might not be directly comparable. Vasp.4.X also subtracts the atomic energies in each iteration, vasp.3.2 does not. Once again this means that the energies written in each electronic step are not comparable.

But the parallel version (i.e. if vasp is compiled with the MPI flag) has some further restriction, some of them might be removed in the future (but to remove them a rather larger programming effort would be required, so currently there are no plans to do that).

Here is a list of features not supported by vasp.4.2 running on a parallel machine:

• The most severe restriction is that it is not possible to change cutoff or cell size/shape on restart with an existing WAVECAR file. This means that if the cell size/shape and or the cutoff has been changed the WAVECAR should be removed before starting the next calculation (actually vasp will realize if the cutoff or the cell shape have Venn changed and will proceed automatically as if the WAVECAR file does not exist). The reason for this restriction is that the re-padding (i.e. the redistribution of the plane wave coefficients on changing the cutoff sphere) would require a highly sophisticated redistribution and communication routine.

  As a matter of fact is of course possible to restart with an existing WAVECAR file, if the number of nodes has changed.

• Symmetry is fully supported with the parallel version, BUT we have used a brute force method to implement it. The charge density is first merged from all nodes, then symmetrized locally and finally the result is redistributed onto the nodes. This means that the symmetrization of the charge density will be very slow, this can have serious impact on the total performance.

  If this algorithm turns out to be too slow, we might change this point in a future release.

• Reading and writing of the CHGCAR (charge density) file can be problematic, because the charge density is read by one node and then distributed. For large system this will result in large memory requirements per node. Therefore it might be necessary to switch of the writing of the CHGCAR file (LCHARG=.FALSE.) in the INCAR file.
• Partial local DOS is only supported with parallelization over plane wave coefficients and NOT with parallelization over bands. The reason is that some files (like PROCAR) have a rather complicated band-by-band layout, and it would be complicated to mimic this layout with distribution over bands.