CP2K build with Intel Compiler and MKL

[Axel Kohlmeyer]

>
> This sounds quite scary to me. CP2K is notoriously tricky to compile
> and so far for me the only reasonable way to tell whether I have a
> working binary was to see if it can run the regtests successfully.
> What you are saying means that this is not a very good method.

well, you have to compare with other codes, where there is not such
a detailed library of tests at all, but people just run a few test
systems and when they work well, they are happy. on top of that you
have the fact, that some people are better at writing "stable" code
than others and that some problems only show up in cases that were
not considered when writing the original code, or due to bad
interactions
with some higher or lower level code that got changed. the flexibility
that makes cp2k a unique computational tool is at the same time its
biggest enemy, as it causes a complexity that is hard to control,
particularly in an environment with multiple developers, where not
everybody has the same attitude to software development.

that all being said, i don't know of any better alternative.
the failing regtest example that you mentioned is using a
feature, that the people i am supporting don't use, so at
the moment, it doesn't bother me much, that this regtest would
fail. the features, that we are using, seem to be working stable
and have not created much problems for a long time. the majority
of the problematic regtests seem to be related to not so commonly
used features.

> I do realize that I can never be sure that the build is 100% good.
> However, in this case, I can't even tell if the build is wrong. It
> crashes on the tests, but perhaps it is due to unstable tests,
> perhapas it is due to miscompilation. This is really nasty.
>
> Let me ask a slightly more general question. Does anyone routinely run
> a build that does not pass the tests? Does it work well outside of the
> tests?

i am seeing _much_ less problems when using g95 and juerg recently
mentioned that his group would be mainly using gfortran 4.4.x.
i have not yet tested a newer gfortran, but my measure of checking
whether there is a real bug in the code is whether i can reproduce
this issue with the g95 build, and for production runs, i usually
run the exact system with a g95 and intel build side-by-side for a
bit and see if the results are equivalent.

[...]

> I do all of this on the x86-64 platform. Also, it certainly is not
> only the Intel compiler that has (or did have) trouble producing a
> build that would pass the tests.

indeed, you cannot imagine the pains that i had to go through to get
a working executable on a cray xt3, where there was only a limited
collection
of PGI fortran compilers available, all of them badly broken wrt.
cp2k.
the only way to get a reasonable executable would be to build all
object
files with g95 using a special flag to not use the fortran startup
code,
write a c-wrapper for that and then link with the (PGI compiled) MPI,
scalapack, blacs, blas, etc. libraries.

there is some hope though, since cray has now bought the pathscale
compiler division, but then again, it is hard to imagine that as
small a shop as cray is, that they will have the manpower to follow
the complexity of the new fortran language features with the level
of detail that cp2k requires, as most current codes are much less
demanding.

cheers,
    axel.

> Ondrej