Compilation of vasp.4 is not always straightforward, because f90 compilers are in general not very reliable yet. Mind that the include file mpif.h must be supplied in f90 style for the compilation of the parallel version (see Section 3.5.11). Here is a list of compilers/platforms and the kind of problems we have detected:
No problems, but compilation (especially of main.F) takes a long time. If there are time-limits the f90 compiler might be killed during compilation. In that case a corrupt .o file remains, and must be removed by hand. If the last file compiled was for instance nonl.F, the user must logout, login again and type
rm nonl.obefore typing make again.
All compiler version starting from 3.2.5.0 work correctly (including xlf90 4.X.X.X). Compiler version 3.2.0.0 will not compile the parallel version correctly, but the serial version should be fine. One user reported that the version 3.2.3.0 compiles the parallel version correctly if the option -qddim is used.
On some systems the file mpif.h is located somewhere in the default
include search path.
Copying the mpif.h file to the local directory and converting it
to f90 style does not work (because the system wide mpif.h file
is always included). One solution is to rename the mpif.h file to mpif90.h.
If the new mpi routines (parallel 
ew.tar) are used only the line
INCLUDE "mpif.h"must be changed to
INCLUDE "mpif90.h"in the file pm.inc.
(use lslpp -L | grep xlf to find out the current compiler version)
On some SGI's the option -64 must be changed to -n32 in the makefiles of vasp.4.X and vasp.lib.
Power Fortran 90, 7.2 on irix 6.2 works correctly. Older version tend to crash when compiling main.F, in particular compiler version Fortran 90, 6.3 will not work. Compiler version 7.1 might produce in some circumstances working code. But with 7.1 it is required to remove all comment lines and all empty lines from the main.F file. A sed script is supplied in order to do that, and one should type
sedmain main.Fif compilation of main.F fails. If you encounter any additional problems with f90 7.1 you must however update to 7.2.
(use versions | grep f90 to find out the current compiler version)
The compiler version DIGITAL Fortran 90 V5.0-492 compiles vasp.4.X correctly. Older official compiler releases do not compile VASP, and require a compiler fix or upgrade (propably an update to version V5.0-492 is the only option you have).
No problems, but compilation (especially of main.F) takes a long time. If there are time-limits the f90 compiler might be killed during compilation. In that case a corrupt .o file remains, and must be removed by hand. If the last file compiled was for instance nonl.F, the user must logout, login again and type
rm nonl.obefore typing make again. Do not forget to upload all required modules before starting compilation. This is usually done in the profile, on the U.K. T3D the following modules must be initialized:
if [ -f /opt/modules/modules/init/ksh ] ; then # Initialize modules . /opt/modules/modules/init/ksh module load modules PrgEnv fi
VASP supports only the newest ``alpha'' scaLAPACK release on the T3D (on the T3E PrgEnv 3.0.1.0 must be installed), and VASP will not work correctly with the scaLAPACK version supplied in the libsci.a (libsci.a contains only a down-scaled scaLAPACK version, supporting very limited functionality). If you do not have access to this alpha release you must switch of the scaLAPACK (see Sec. 3.5.14).
The compiler versions 3.0.0.0 (and newer) should compile the code correctly, difficulties have been reported for older versions. However the use of version 3.0.1.0 (and newer) is very desirable.
On the T3E it might be necessary to change the makefiles slightly: On the IDRIS-T3E (the only T3E we had access to) the cpp (C-preprocessor) was located in the directory /usr/lib/make/, it might be necessary to change this location (line CPP in the makefiles) on other T3E machines.
In addition some versions of the T3E linker (3.0.0.0 or older) seem to have a bug, it is necessary to copy the file preclib.o from vasp.4.lib to vasp.4.X, this will result in several warning messages during linking, the final code is made explicitly executable in the supplied makefiles.
For best performance one should also allow hardware data streaming on the T3E, this can be done using
export SCACHE_D_STREAMS=1before running the code. The performance improvements can be up to
. But we have to point out
that the code crashed in that case from time to time if
the switch T3D_SMA was specified in the makefile. Therefore in the default
makefile, T3D_SMA is currently not specified (and the
optimized T3D/T3E communication routines are not used). If the performance
of communication is very important, T3D_SMA can be specified in
the makefile, but then it might be required to
to switch data streaming explicitly of in some cases by typing:
export SCACHE_D_STREAMS=0(This error will be fixed with a new set of data streaming aware shmem communication routines).
The switch -DscaLAPACK (see also compilation for T3D) works only in programming environment 3.0.1.0 (3.0.0.0 does not offer the required routines), thus the line -DscaLAPACK is currently missing in the makefile. To improve performance it worthwile trying whether VASP compiles and works correctly with -DscaLAPACK specified in the makefile.
Reportedly the NAG compiler NAGWare f90 compiler Version 2.2(260) can compile the code. We do not have access to this version, so that we can not help if problems are experienced with NAG compilers under LINUX. Please also check the makefiles before attempting the compilation.