Project

General

Profile

Bug #851

FindMPI does not work correctly with cmake 2.8.1 and 2.8.2

Added by Roland Schulz about 8 years ago. Updated almost 8 years ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Category:
-
Target version:
-
Affected version - extra info:
Affected version:
Difficulty:
uncategorized
Close

Description


Related issues

Related to Support Platforms - Bug #854: Remaing problems with Jenkins auto-buildClosed12/10/2011

Associated revisions

Revision 417d0aff (diff)
Added by Mark Abraham almost 8 years ago

Remove use of FindMPI.cmake

The functionality of FindMPI.cmake should not be needed for GROMACS,
since the wrapper compiler will do the complete job. This already
worked for Cray and BlueGene, and so far this new version is known
to work for OpenMPI wrapping icc and gcc.

CMake now warns the user about possible unsuitable versions of
OpenMPI and MVAPICH2.

The process of managing MPI is more modular than it used to be.

To use:

cmake .. -DGMX_MPI=ON -DCMAKE_C_COMPILER=`which mpicc`

or with bash

CC=mpicc cmake .. -DGMX_MPI=ON

and whatever else suits your setup.

Fixes #851 and #636.

Change-Id: Ibe41206bed8b70b83a25da1e4e29dd87b61ea17d

Revision 92789c84 (diff)
Added by Roland Schulz over 7 years ago

Fix MPI build for MPI library without mpi wrapper

Some MPI library (e.g. MPICH and OpenMPI on Windows) don't
contain any MPI wrappers and thus 417d0afff broke the support for
those MPI libraries.

This change uses the FindMPI module if the compiler is not a
mpi wrapper and cmake >= 2.8.5. Requiring mpi wrappers for
cmake < 2.8.5 avoids reintroducing the problems of #851.

To avoid any confusion of different behavior with older and newer
versions of cmake, all documentation should recommend the mpi wrapper
approach, which works for all versions. The FindMPI approach should
only be discussed for advanced users (to support e.g. Windows).

As a side effect this change makes it more convinient to use with
cmake>=2.8.5. No need to speciy mpi wrapper and less problems with
nvcc.

Fixes #958

Change-Id: Ic53d8125c5a58edc6789fe16f2b710e7e2568d4f

History

#1 Updated by Szilárd Páll about 8 years ago

We have discussed this (see issue #815) and the conclusion was that we do want the minimum version to be 2.8.0.

#2 Updated by Mark Abraham about 8 years ago

release-4-6 works for me with CMake 2.8.2. I don't have the git hash reported by Jenkins in my repo. So something looks weird - is the fail reproducible? Where did the hash come from?

#3 Updated by Szilárd Páll about 8 years ago

Actually, it works for me as well with CMake 2.8.0 on Linux with OpenMPI.

#4 Updated by Roland Schulz about 8 years ago

Szilárd Páll wrote:

We have discussed this (see issue #815) and the conclusion was that we do want the minimum version to be 2.8.0.

Does this mean we fix bugs in cmake affecting GROMACS? E.g. will we have a copy of the CMakeDetermineASMCompiler.cmake module so that it works with 2.8.3? In #815 it was only said that in 2.8.3 the ASM is broken. But not whether we support 2.8.3 and if so how.

What about MPI? I think FindMPI is seriously broken. Especially in older version. Do we have our own version of FindMPI.cmake? I'm not sure whether it is possible to get the FindMPI.cmake from 2.8.5 working in <2.8.5. So which FindMPI.cmake would we choose if we decide to have our own copy?

Or should we change the approach for MPI? We already support to build with CC=mpicc and using the wrapper. Should we make this the default/recommended approach? The pro/cons of that approach is discussed at http://www.mail-archive.com/cmake@cmake.org/msg18437.html. The thread also has an example module to find the mpicc wrapper. Trilinos (they started that thread) decided to use the wrapper approach. The usage of that approach is described at http://trilinos.sandia.gov/Trilinos10CMakeQuickstart.txt

#5 Updated by Roland Schulz about 8 years ago

Mark Abraham wrote:

release-4-6 works for me with CMake 2.8.2. I don't have the git hash reported by Jenkins in my repo. So something looks weird - is the fail reproducible? Where did the hash come from?

The hash is of https://gerrit.gromacs.org/#change,278,patchset=10 . ( Just in case you are interested: You can either put the hash into the Gerrit search bar or the build page in Jenkins has a link to the Gerrit page ). The change is only adding the GerritBuild shell script and thus can't affect this issue.

On Ubuntu 10.04 it works with 2.8.0 (installed from package). On Ubuntu 11.10 it fails which 2.8.1, 2.8.2, 2.8.3, 2.8.4 (installed from source) but works with 2.8.5 (installed from package).

#6 Updated by Roland Schulz about 8 years ago

I installed 2.8.2 manually on 10.04 and it is OK. Also 2.8.5 manually on 11.10 is OK (to check that it is not how I install cmake). 2.8.0 on Ubuntu 11.10 is not OK.

So it seems that for Ubuntu 11.10 (OpenMPI 1.4.3-2.1ubuntu1) cmake <2.8.5 doesn't work.

#7 Updated by Szilárd Páll about 8 years ago

Roland Schulz wrote:

Mark Abraham wrote:

release-4-6 works for me with CMake 2.8.2. I don't have the git hash reported by Jenkins in my repo. So something looks weird - is the fail reproducible? Where did the hash come from?

The hash is of https://gerrit.gromacs.org/#change,278,patchset=10 . ( Just in case you are interested: You can either put the hash into the Gerrit search bar or the build page in Jenkins has a link to the Gerrit page ). The change is only adding the GerritBuild shell script and thus can't affect this issue.

On Ubuntu 10.04 it works with 2.8.0 (installed from package). On Ubuntu 11.10 it fails which 2.8.1, 2.8.2, 2.8.3, 2.8.4 (installed from source) but works with 2.8.5 (installed from package).

On Ubuntu 10.04 it works with 2.8.0 (installed from package). On Ubuntu 11.10 it fails which 2.8.1, 2.8.2, 2.8.3, 2.8.4 (installed from source) but works with 2.8.5 (installed from package).

This would mean that not supporting some versions would only help (in not having to "fix bugs in cmake affecting GROMACS") if we'd bump the required version to 2.8.5 which IMO is not reasonable at all.

Therefore, we have to come up with a solution. Based on the mail you liked in the CMake list, to me it sounds that the FindMPI module's approach is fundamentally flawed and we might want to reconsider using our/a custom FindMPI.

#8 Updated by Szilárd Páll about 8 years ago

Roland Schulz wrote:

I installed 2.8.2 manually on 10.04 and it is OK. Also 2.8.5 manually on 11.10 is OK (to check that it is not how I install cmake). 2.8.0 on Ubuntu 11.10 is not OK.

So it seems that for Ubuntu 11.10 (OpenMPI 1.4.3-2.1ubuntu1) cmake <2.8.5 doesn't work.

Damn, that doesn't sound good. I have the feeling that for reference we need another Linux test platform as well (say CentOS), otherwise in the future we might get stuck with issues like this and won't realize when we're facing a Linux-flavor specific problem.

#9 Updated by Mark Abraham about 8 years ago

Roland Schulz wrote:

Szilárd Páll wrote:
What about MPI? I think FindMPI is seriously broken. Especially in older version. Do we have our own version of FindMPI.cmake? I'm not sure whether it is possible to get the FindMPI.cmake from 2.8.5 working in <2.8.5. So which FindMPI.cmake would we choose if we decide to have our own copy?

My initial thought is that we don't need FindMPI.cmake. Brad King makes good points here http://www.mail-archive.com/cmake@cmake.org/msg18444.html in that thread Roland posted.

Or should we change the approach for MPI? We already support to build with CC=mpicc and using the wrapper. Should we make this the default/recommended approach? The pro/cons of that approach is discussed at http://www.mail-archive.com/cmake@cmake.org/msg18437.html. The thread also has an example module to find the mpicc wrapper. Trilinos (they started that thread) decided to use the wrapper approach. The usage of that approach is described at http://trilinos.sandia.gov/Trilinos10CMakeQuickstart.txt

We already encourage separate CMake builds for mdrun and tools (though with modern MPI, compiling all with MPI will work fine, and with the advent of MPI-enabled tools, perhaps we should encourage this), so the wrapper approach looks fine to me. In effect, we already support that (as an exception) for Cray. For the vast majority of users, cmake .. -DCMAKE_CXX_COMPILER=mpicxx will Just Work. For example, BlueGene/L doesn't have a proper wrapper, so we already work around that in cmake/Toolchain-BlueGeneL-xlc.cmake

The GROMACS changes that would be required look straightforward enough. There's about a dozen lines that deal with taking results from FindMPI.cmake and using them, which would disappear. We'd need some logic for finding $MPIEXEC if we want to keep the test for broken OpenMPI versions (or find a compile-time test?).

#10 Updated by Mark Abraham about 8 years ago

Szilárd Páll wrote:

Roland Schulz wrote:

I installed 2.8.2 manually on 10.04 and it is OK. Also 2.8.5 manually on 11.10 is OK (to check that it is not how I install cmake). 2.8.0 on Ubuntu 11.10 is not OK.

So it seems that for Ubuntu 11.10 (OpenMPI 1.4.3-2.1ubuntu1) cmake <2.8.5 doesn't work.

Damn, that doesn't sound good. I have the feeling that for reference we need another Linux test platform as well (say CentOS), otherwise in the future we might get stuck with issues like this and won't realize that it's Linux a Linux-flavor specific problem.

Sounds like we need some virtualization to allow for a few OS on the automated testing machines.

#11 Updated by Szilárd Páll about 8 years ago

The GROMACS changes that would be required look straightforward enough. There's about a dozen lines that deal with taking results from FindMPI.cmake and using them, which would disappear. We'd need some logic for finding $MPIEXEC if we want to keep the test for broken OpenMPI versions (or find a compile-time test?).

If we switch to an mpicc wrapper-based approach version-check can be implemented in a compiler-detection/checking CMake module which one way or another we'll anyway need.

#12 Updated by Szilárd Páll about 8 years ago

Sounds like we need some virtualization to allow for a few OS on the automated testing machines.

All GROMACS-related services as well as build-slaves (currently only an Ubuntu 11.04 and a Win7) are running on our virtual server so more OS-es is not a big deal.

#13 Updated by Mark Abraham almost 8 years ago

Hopefully https://gerrit.gromacs.org/#change,400 will allow us to circumvent these issues.

#14 Updated by Szilárd Páll almost 8 years ago

Mark Abraham wrote:

Hopefully https://gerrit.gromacs.org/#change,400 will allow us to circumvent these issues.

Just wondering, are there any known drawbacks of this implementation -- except that the path to the mpi wrapper has to be manually specified additional to flipping the GMX_MPI switch?

#15 Updated by Mark Abraham almost 8 years ago

My suggested invocation is ccmake .. -DGMX_MPI -DCMAKE_C_COMPILER=`which mpicc`, but with bash one can use CC=mpicc ccmake .. -DGMX_MPI also. I don't know if there is an equivalent csh form.

Another option is that if GMX_MPI==ON we set CMAKE_C_COMPILER from the environment variable MPICC, but that feels a bit like we're subverting the user.

We do need someone to test that a suitably recent MPICH works with this approach.

The upshot of the CMake list thread linked above was that FindMPI.cmake was good if you wanted to mix MPI and non-MPI builds in the same tree. Since we already don't do this, then the value of FindMPI.cmake is low and its inconvenience noticeable.

#16 Updated by Mark Abraham almost 8 years ago

  • Status changed from New to Closed

FindMPI.cmake has been removed, so this issue is resolved.

Also available in: Atom PDF