[gmx-developers] Re: [gmx-users] Link to Intel MKL (fftw) via cmake options

[Szilárd Páll]

I've just realized that both you and the similar report you linked to
were using CMake 2.8.3. If you don't succeed could you try another
CMake version?
--
Szilárd



On Mon, Oct 24, 2011 at 11:14 PM, Szilárd Páll <szilard.pall at cbr.su.se> wrote:
> Please keep all discussions on the mailing list! Also, I'm also CC-ing
> to the gmx-devel list, maybe somebody over there has an better what
> causes your CMake issue.
>
>>>> //Flags used by the compiler during all build types
>>>> CMAKE_C_FLAGS:STRING=' -msse2 -ip -funroll-all-loops -std=gnu99  '
>>>>
>>>> //Flags used by the compiler during release builds.
>>>> CMAKE_C_FLAGS_RELEASE:STRING=-mtune=itanium2 -mtune=core2  -O3 -DNDEBUG
>>>> ...
>>>> These are obviously the wrong flags for the detected architecture,
>>>> sse2 is no longer available and so are the the mtune architectures.
>>>
>>> Indeed, some of those flags are wrong (CXX -std=gnu99), others simply
>>> outdated (-mtune=itanium2). There are plans to correct these issues
>>> for 4.6, but let's agree on the fact that they are not show-stoppers
>>> (FYI you won't get more than a few percent speedup with the right
>>> compiler options, the most I've seen is ~5%.)
>>
>> OK, I was under the impression it would be simple to correct that -
>> independend of gains if any.
>
> Theoretically it is, but in practice not so much. Keeping up with the
> ever changing compiler options - especially the architecture-related
> optimization flags - is not a fun job. We'll try to improve these
> aspects of the CMkake build system the next release.
>
>>> If you want to get rid of them, the solution is pretty simple: just
>>> remove the offending options and pick new ones if you think they work
>>> better for you.
>>
>> That involves hand-editing the CMakeCache which may be no less
>> bothersome than enduring the warnings ;-)
>
> You can use ccmake (or cmake-gui), they will make your life easier.
> Otherwise, editing the cache is nowhere near as difficult as it
> sounds. ;)
>
>>> However, I'm not sure what do you mean by "sse2 is no longer
>>> available"? Of course it is, both the Intel Compiler and the majority
>>> of current processors support it. Also, -mtune=core2 is perfectly
>>> valid as is -msse2.
>>
>> I checked that with the documentation on the Intel site and
>> the code generation options written out by the compiler (as
>> help info). On the Intel site, -msse2 and -mtune=core2 are
>> still listed as valid, whereas they aren't mentioned in the
>> help provided by the compiler I installed. Maybe they are
>> redundant with the Intel64-compiler and set by default
>> (not entirely sure). Bottom line: you are right here, I
>> missed some information.
>
> i) Indded the "-msse2" is redundant. From the icc man page:
>
> "On  Linux  systems, if neither -x nor -m is specified, the default is -msse2."
>
> ii) Nope, the default as usually is -mtune=generic on "IA-32" and
> "Intel 64" - as Intel likes to call them.
>
> Btw, core2 is essentially equivalent with -xSSSE3. Depending on the
> processors you intend to run on you can try -xSSE4.1 or -xSSE4.2, but
> I doubt you'll see a noticeable difference.
>
>>>> CMAKE_CXX_FLAGS:STRING=' -msse3 -ip -funroll-all-loops -std=gnu99 '
>>>
>>> As Mark said, SSE3 won't help you in any noticeable way.
>>
>> The only 'help' I envisioned here was to avoid screen cluttering
>> by loads of warnings. mMy suggested 'fixes' weren't really fixes,
>> as I can see now. In my own development work, I can't stand
>> pages of recurring warning messages ;-) So I probably
>> overreacted here ...
>
> Sure, warnings are not nice and we dislike them as well. That's why
> these issues will be corrected in the future.
>
>>>> But the install is broken. On `make install-mdrun`, the scripts would
>>>> remove any library from "src/gmxlib/CMakeFiles/CMakeRelink.dir"
>>>> and bail out with the error below. Even if you copy the libraries
>>>> by hand to CMakeRelink.dir/, the'll get removed by make install-mdrun
>>>> before trying to link with them.
>>>
>>> Now that is a bug. I'd appreciate if you could enter it in
>>> redmine.gromacs.org withe all details on how to reproduce it!
>>
>> I didn't do that until now but examined this further. There is already
>> an identical error posted by some other researcher (as you know):
>> http://www.mail-archive.com/gmx-users@gromacs.org/msg39228.html
>>
>> I was able to replicate the error somehow on a different machine without
>> any intel compiler around (when building with -DGMX_MPI=ON and cmake).
>>
>> Gromacs 4.5.5: autoconf/configure on SuSE 11.4/x64 on i7
>> ----------------------------------------------------------------
>>                 icc/64-12.1.0    gcc/x64/4.5.1
>> intThread           OK                OK
>> MPI(1.3.2)          OK                OK
>>
>>
>> Gromacs 4.5.5: cmake 2.8.3 on SuSE 11.4/x64 on i7
>> ----------------------------------------------------------------
>>                 icc/64-12.1.0    gcc/x64/4.5.1
>> intThread          error              OK
>> MPI(1.3.2)         error             error
>>
>>
>> Gromacs 4.5.5:  autoconf/configure on SuSE 11.4/x64 on Phenom/X4
>> ----------------------------------------------------------------
>>                 gcc/x64/4.5.1    gcc/x64/4.6.1
>> intThread           OK                OK
>> MPI(1.3.2)          OK                OK
>>
>>
>> Gromacs 4.5.5:  cmake 2.8.3 on SuSE 11.4/x64 on Phenom/X4
>> ----------------------------------------------------------------
>>                 gcc/x64/4.5.1    gcc/x64/4.6.1
>> intThread           OK                OK
>> MPI(1.3.2)         error             error
>>
>>
>> Gromacs/git (2011-10-18): cmake 2.8.3 on SuSE 11.4/x64 on Phenom/X4
>> -------------------------------------------------------------------
>>                gcc/x64/4.5.1    gcc/x64/4.6.1
>> intThread         error              error
>> MPI(1.3.2)        error              error
>>
>>
>> Notes: - the MPI is openmpi out-out-the-box w/SuSE 11.4
>>       - Gromacs/git - w/autoconf was not tested
>>       - Intel-Compiler on AMD Phenom N/A
>>       - Gromacs/git failed w/compile error
>>         on Boost(?) -> src/gromacs/analysisdata/modules/plot.cpp:60
>>            boost::mpl::aux::template_arity<mpl_::na>::value’ is not a
>>            valid template argument for type ‘int’ because it is a
>>            non-constant expression (many following)
>>       - Boost version is 1.4.6 (actual version)
>>
>> Resumé:
>>  - autoconf succeeds in almost all cases with any compiler
>>  - cmake fails in almost all cases except the simplest ones (cmake
>> ../gromacs-src)
>>
>> I really don't know what to make out of this.
>
> Me neither, but let's try to figure it out.
>
> First of all, your OpenMPI is quite outdated; as the
> build-generation-time message warns OpenMPI <v1.4.1 has known issues.
>
> However, I've just tried gcc 4.6.0 + OpenMPI 1.3 with cmake 2.6.4 as
> well as 2.8.2 and in both cases my installation went just fine.
> Although I didn't remember seeing you full command line call to CMake,
> I tried to replicate a quite common scenario: build & install full
> Gromacs with MPI off and "threads" on, then build & install mdrun with
> MPI. Here are my command lines:
>
> CMAKE_PREFIX_PATH=/my/path/to/fftw3 cmake ../ -DGMX_MPI=OFF
> -DCMAKE_INSTALL_PREFIX=/tmp/gromacs-4.5 && make -j6 && make install
>
> CMAKE_PREFIX_PATH=/my/path/to/fftw3 cmake ../ -DGMX_MPI=ON
> -DCMAKE_INSTALL_PREFIX=/tmp/gromacs-4.5 && make mdrun -j6 && make
> install-mdrun
>
> Could you please run the above commands and see what you get. If make
> install-mdrun still fails, please attach your CMakeCache.txt so we can
> take a look at it.
>
> Cheers,
> --
> Szilárd
>