4
$\begingroup$

Specifically, how does one go about writing code that works with, say, both MPICH and OpenMPI?

I am currently in the process of cleaning up the build scripts and code for a distributed-memory stochastic mixed-integer linear programming package we aim to release this Spring. One of idiosyncrasies of the code (or rather, one of the libraries we rely on from our collaborators) is that it will only work with MPICH, and it will not build or run with OpenMPI. What sort of things should I look to be implementing in an MPI implementation-independent fashion? (e.g., a coworker has pointed out that OpenMPI and MPICH represent communicators differently.) My goal is to try and patch the software so it will work with both OpenMPI and MPICH, and any high-level guidance about how to do that (hopefully with some references) would be extremely helpful.

Edit: Here's an example error message from the compiler (OS X, Clang from Xcode 7.2):

PIPS/PIPS-IPM/Core/QpStoch/sTree.C:147:9: error: no matching function for call to 'MPI_Comm_create'
        ierr = MPI_Comm_create(mpiWorldGroup, childGroup, &childComm); assert(ierr==MPI_SUCCESS);
               ^~~~~~~~~~~~~~~
/usr/local/Cellar/open-mpi/1.10.1_1/include/mpi.h:1271:20: note: candidate function not viable: cannot convert argument of incomplete type 'MPI_Group' (aka 'ompi_group_t *') to 'MPI_Comm' (aka 'ompi_communicator_t *')
OMPI_DECLSPEC  int MPI_Comm_create(MPI_Comm comm, MPI_Group group, MPI_Comm *newcomm);
                   ^
1 error generated.

I should make more clear: the errors are in a library I am helping some collaborators get ready for a new release. I was not the original author, but I have patched up the code to add functionality I needed, plus I helped improve the build system. So this question is really geared more towards the situation where a developer is somewhat familiar with MPI, can write MPI-standard-compliant code, but is now trying to debug someone else's code and replace it with MPI-standard-compliant code. I'm looking for common pitfalls, basically.

Improve this question
$\endgroup$

2 Answers 2

Reset to default
6
$\begingroup$

Always use the correct types as specified by the standard. MPI_Comm for your communicators not int unless you're in Fortran. Etc., etc.

This should be relatively easy. What problems are you really having?

Edited to add in response to update: It looks like the type of childGroup is not an MPI_Group but an MPI_Comm, so you should either fix that or use a temporary MPI_Group to extract the group from the communicator locally. It looks like these two types are typdefed to int or something in OpenMPI, so the code "works" there and not under MPICH where they may each be their own opaque structures.

Improve this answer
$\endgroup$
5
  • $\begingroup$ Updated the question. Basically, the main issue is that I didn't write the bulk of the code I'm debugging, so I am asking more of "where are there likely to be common problems so I can fix them" and try to fix problems in batch, rather than the time-consuming bugfix-compile-repeat cycle of picking off compiler errors one by one. $\endgroup$
    – Geoff Oxberry
    Commented Feb 19, 2016 at 17:43
  • 1
    $\begingroup$ It's actually the reverse: those two types are probably typedef'd to an int in MPICH, but not in OpenMPI, so the code works with MPICH (it was written at Argonne), but not with OpenMPI. $\endgroup$
    – Geoff Oxberry
    Commented Feb 19, 2016 at 21:07
  • $\begingroup$ More generally, I seem to be running into these weird sorts of compile-time or runtime bugs in codes with one MPI implementation, but not others. Another example would be building hypre on OS X via the Homebrew package manager (I wrote the first version of the hypre package in there): it builds cleanly with both MPICH and OpenMPI, but passes all of its tests with OpenMPI only, and returns errors with MPICH. Obviously, for that instance, I need to contact the hypre team, but given how some codes seem a little finicky about MPI implementation, it seemed worth asking about trends. $\endgroup$
    – Geoff Oxberry
    Commented Feb 19, 2016 at 21:11
  • $\begingroup$ @GeoffOxberry, "code to the standard" has always been my mantra. Test against at least one OpenMPI- and one MPICH-derived stack always, as well. $\endgroup$
    – Bill Barth
    Commented Feb 19, 2016 at 22:13
  • $\begingroup$ Turned out it was a different argument: github.com/goxberry/PIPS/commit/… $\endgroup$
    – Geoff Oxberry
    Commented Feb 21, 2016 at 1:13
6
$\begingroup$

Bill Barth already gave great advice. My advice is to not read the MPICH or OpenMPI documents. Read the MPI standard instead. As far as standards are concerned, it's actually quite readable. Implementations are, in my experience, quite conforming to the standard, but they add and extend them. These extensions are part of the problem that makes code incompatible.

Improve this answer
$\endgroup$
1
  • $\begingroup$ Yeah, I should have said "Write code that complies with the standard." $\endgroup$
    – Bill Barth
    Commented Feb 19, 2016 at 3:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.