How to compile cp2k with INTEL compilers and MKL.

[Axel]

On Jul 11, 10:47 am, fish <john... at uop.com> wrote:
> After looking thought the many negative posts about the INTEL
> compilers and MKL, I wanted to add a positive note.
>
> The key to using the INTEL compilers is to source the scripts provided
> by INTEL to set up your environment for the FORTRAN and C++ compilers
> and MKL libraries.  I source these scripts in my .profile script.

some comments to this.

the problem of getting cp2k compiled, particularly a serial version,
is generally a minor one and mostly requires people to read the
compiler
documentation. however, a compiled binary does not mean, that you
have a correctly functioning binary. if you had been using intel
10.1.008
for example, it would just segfault with an internal compiler error
and no environment variable would save you from that. miscompiled code
is more difficult to detect. so please download and run the regression
tests and see how far you get. particularly in the x86 market there is
now a growing pressure one compiler vendors to show that their
compilers
produce faster code than their free counterparts, so that they are
worth
the pricetag with the result that optimizations become more
aggressive
and are less well tested to bring the product faster to the market.

the problem becomes exponentially more complicated if you move to a
parallel
compile where you not only have to have a working compiler and a
correct
BLAS/LAPACK, but ScaLAPACK/BLACS correctly compiled on a correctly
working
MPI library that is consistent with your fortran compiler.
particularly on
linux machines (with too many options and packages by default compiled
in an
incompatible way, by people with little experience) and suboptimally
maintained
machines in supercomputing centers.

cp2k tries to be very standard conforming, but at the same time
expects compilers and libraries to work according to the standards.
unfortunately, not many compilers and installations fullfil this.

the consequence is a mixed bag. it is very annoying as a user that
the hurdle to get a correctly working cp2k executable on any machine
is so high (see my earlier - intentionally provocative - posts on
that
subject and the resulting discussions), but one also has to respect
the
desire of developers to keep their code free from clutter to
accommodate
buggy software and their freedom of choice in how they write their
software.

over the last couple of years, i have learned to adapt to this and am
trying to see the positive sides. with increasing popularity and
maturity
of cp2k, the pressure on compiler vendors and machine sysadmins to do
a
good jobs increases and that benefits everybody. cp2k has become my
personal
acid test for new machines, i.e. if cp2k compiles and runs correctly,
i have
a very high chance that _any_ standard conforming fortran code will
be
compiled and execute correctly.

> These scripts will allow you to have much simpler make files and lower
> the effort involved in compiling and linking.  I recently compiled the
> serial version of cp2k on my Pentium D desktop running Fedora Core 8
> at home using the "Linux-i686-intel.sopt" arch file attached below.
>
> I have used the same arch file to compile cp2k on my SGI Altix 350.  I
> think it should work with any architecure with the INTEL compilers.

well, you may get a compiled executable, but you may not get an
optimal
executable or it may not work always. particularly linking MKL in
default
mode requires you to explicitly disable multi-threading via setting
OMP_NUM_THREADS=1 and when running on a cluster you have to have a
copy
of the libraries (and set the environment) on each node. it is much
more
convenient to use a more complicated set of linker flags to build an
executable that requires only the minimal amount of shared libraries,
especially compiler runtime libraries (hence the preference for using
-i-static for linking with ifort). there are a few more things to
consider,
depending on the local installation (older compiler/mkl version,
better
performance with different optimization flags). one flag that i found
to
be very important for consistent results using intel compilers is the
-pc64 flag that switches the floating point unit from extended (80-
bit)
mode to 64-bit mode. i would not use -O3 as it tends to be slower than
-O2 -unroll, i would use internal preprocessing to speed up compiling,
and so on and so on...

if you want to get the best out of your machine you _have_ to compile
in
parallel, tweak the compiler flags, adjust to your installation and
the
arch files reflect that. if you are just playing around, you can now
have
it even easier and just download the precompiled executable.

cheers,
   axel.

> After working with the INTEL compilers for several years, I am having
> much better luck with them.
> The MKL libraries are very convienent because they contain many of the
> commonly used math libraries in them.  You can make wrappers for
> FTTW3, SCALAPACK, BLAS which use the MKL libraries.  This does make
> compiling open source like CP2K much easier.



>
> The INTEL MPI library is also convienent for compiling parallel code.
>
> A nice example is provided by the INTEL which shows how to compile
> VASP with their compilers, math libraries and MPI.
>
> (Seehttp://support.intel.com/support/performancetools/libraries/mkl/sb/CS....)
>
> This example should be helpful to someone trying to make an arch file
> for compiling cp2k with the INTEL compilers and libraries.
>
> ___________________________________________________________________________
>
> # by default some intel compilers put temporaries on the stack
> # this might lead to segmentation faults if the stack limit is set to
> low
> # stack limits can be increased by sysadmins or e.g with ulimit -s
> 256000
> # furthermore new ifort (tested to work fine with 10.0.015) compilers
> support the option
> # -heap-arrays 64
> # add this to the compilation flags if the other options do not work
> # These variables were simplified from earlier versions of this file.
> #
> # The following lines were added by jjlow 7/11/09
> #
> # You do not have to specify the location of mkl libraries if you run
> the
> # scripts provided by INTEL to setup your environment for the fortran
> compiler, c++ compiler
> # and mklibraries.  The names of these scripts are ifortvars.sh,
> iccvars.sh and
> # mklvars32.sh (for the bash or bourne shells).  Similar csh scripts
> are also
> # available.  Look for these scripts in the bin directory of the
> fortran and
> # cc installation directories and the tools/environment directory of
> the mkl
> # installation directory.
> CC       = icc
> CPP      = cpp
> FC       = ifort -FR
> FC_fixed = ifort -FI
> LD       = ifort
> AR       = ar -r
> DFLAGS   = -D__INTEL -D__FFTSG -D__FFTMKL
> CPPFLAGS = -traditional -C $(DFLAGS) -P
> FCFLAGS  = -O3 -Vaxlib
> LDFLAGS  = $(FCFLAGS)
> LIBS     = -lmkl_lapack -lmkl -lguide -lpthread
>
> OBJECTS_ARCHITECTURE = machine_intel.o