Project

General

Profile

Bug #849

C++ Compile with MPI fails

Added by Roland Schulz over 7 years ago. Updated about 7 years ago.

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

Description

In CMakeList we set -DMPI. This conflicts with the C++ namespace "MPI". It was added by Erik 2009-03-09 for FAHCORE (d1c6d34e).

Is this define at all needed? Why can FAH not just test for GMX_LIB_MPI?
We have two options:
- Use a different definition name.
- Tell the MPI library we don't want the C++ bindings with OMPI_SKIP_MPICXX / MPICH_SKIP_MPICXX. Since we don't need the C++ binding this would be nice (a bit faster compiler?). But than we would have a problem with any other MPI library. Is anyone still using something else than these two?

I have seen this error with OpenMPI and master. But it should also occur also with the 4.5 branch and MPICH.


Related issues

Related to GROMACS - Bug #852: Jenkins Build for masterClosed12/03/2011
Related to GROMACS - Task #853: Fix FAHCORE because it can no longer use -DMPI in CMakeLists.Closed12/10/2011

Associated revisions

Revision 93ba2ec9 (diff)
Added by Roland Schulz over 7 years ago

Set -DMPI only if compiled for FAH

MPI conflicts with C++ MPI namespace.
This allows to compile with FAH or with C++ and MPI.
Compiling with FAH and C++ and MPI will still have a name conflict.

Resolves #849

Change-Id: I73ccb7b0e682ae6d12352c76e26c6d79e93ea798

Revision d89f426b (diff)
Added by Roland Schulz about 7 years ago

Remove MPI define for FAH

FAH will use with 4.6 the standard GMX_MPI define instead of MPI.
This removes problems with C++ compile.

This fixes #849 and is related to #853.

Change-Id: I63bfc14400cda096350aba9a94a676e9c0952d56

History

#1 Updated by Peter Kasson over 7 years ago

For the released version (4.5), I think it's important that we not change the behavior of how Gromacs interacts with external packages that depend on it. So because FAHCORE expects -DMPI, suddenly removing it from a specific version is bad form. But for the master (and future releases), I think we can choose whichever option we think best.

#2 Updated by Roland Schulz over 7 years ago

So it would be OK for FAH to check for GMX_MPI/GMX_LIB_MPI? Thus we can remove -DMPI and don't need to rename it?

What about 4.6? Can we already make the change in that branch or do you prefer to wait till master. It is really important for master. But I think even 4.5 and 4.6 were supposed to compile with C++.

#3 Updated by Peter Kasson over 7 years ago

Let me be explicit: making this change will break the FAH build in ways that may not be immediately obvious to the compiler. I no longer maintain that code, so whoever does the builds next will have to notice (probably from bug reports) that the builds are failing and patch the code to use other variables.

Therefore we SHOULD NOT remove -DMPI for version 4.5. That will break the specs of a current release version. We CAN remove it for master and possibly 4.6. Versions that are not yet released can change their specs. But it will cause someone a headache down the line. :)

#4 Updated by Michael Shirts over 7 years ago

Peter Kasson wrote:

For the released version (4.5), I think it's important that we not change the behavior of how Gromacs interacts with external packages that depend on it. So because FAHCORE expects -DMPI, suddenly removing it from a specific version is bad form. But for the master (and future releases), I think we can choose whichever option we think best.

Hi guys-

The core wrapper is undergoing some changes, and we'll make sure that the #ifdef MPI is removed. The time scale is approximately on the scale of 4.6.

#5 Updated by Roland Schulz over 7 years ago

  • Target version set to 4.6

#6 Updated by Roland Schulz about 7 years ago

Can I go ahead and remove -DMPI for 4.6 as was agreed on? Or do you want to address task #853 first? If so what is the timeline on that?

#7 Updated by Michael Shirts about 7 years ago

In all cases, change the name to best fit. The gromacs core wrapper is changing for the 4.6 release, so we can adapt to any new name.

#8 Updated by Anonymous about 7 years ago

  • Status changed from New to Closed
  • % Done changed from 0 to 100

Also available in: Atom PDF