Additionally, the official site for MPI is http://www.mpi-forum.org/, not the Argonne

Fixed.

Do you perhaps have a reference regarding the 454 XLR-HD numbers for the storage and processing requirements?

I don’t think 454 has made that information widely available yet. Until they do, you can always cite this entry.

Can you cite a specific problem [with multiple MPI implementations]?

As someone who has developed in MPI a bit, I agree that from a developer standpoint, the spec works. As someone who has dealt with MPI as a system administrator, I agree that as long as you set up your environment properly, multiple implementations can coexist on the same system. It was the difficulty in getting all that sorted out, especially integrating it with cluster management/scheduling software, e.g., Platform LSF, that I was referring. It is certainly possible to make it work, it just is more difficult that it probably should be. As for an MPI-ABI, I think that is a lower priority (I don’t mind recompiling) than getting all the helper tools to have similar calling semantics and capabilities (in fact, being better able to specify which implementation you would like would likely allow you to avoid many such complications). And thanks for the pointer to Environment Modules.

“…it is unfortunate that MPI implementations are so fragmented and often incompatible, i.e., if one vendor uses MPICH2 and another uses LAM, you need to set up different systems to support each because they cannot coexist on the same system without problems.”

Can you cite a specific problem? All MPI implementations that I am aware of can co-exist just fine on a single host without problems. Most of the time, all you need to do it set your PATH and possibly LD_LIBRARY_PATH and MANPATH to point to the MPI implementation that you want, and you’re good to go (sometimes you need to do this in shell setup files, especially if you’re using rsh/ssh to login to remote nodes to start MPI processes). As such, it is perfectly possible to run multiple MPI apps, each using a different MPI implementation on the back-end, and hide all that glue from the end-user.

I do agree, however, that it is a bummer that a) ISVs are forced to choose to support one or multiple MPI implementations, and b) that sysadmins have to deal with this in the first place (e.g., making glue to hide the differences and/or seamlessly allow users to swap between different MPI implementations — BTW, one package that many have found useful for this is Environment Modules: http://modules.sf.net/).

MPI apps are source code compatible between MPI implementations, of course, but that doesn’t necessarily mean that they will run with the same characteristics with different MPI implementations. This can be a real headache to handle properly, especially for ISVs. Having an application binary interface (ABI) is something that the MPI 3.0 Forum is looking at, but to be honest, I’m a little skeptical as to whether it will actually happen and/or be useful. One obvious example is that even if you have an app that will run with MPI implementations A and B simply by switching your LD_LIBRARY_PATH, a) how many users will screw this up, and b) will the app run the same way between A and B?

There are many more ABI issues than this, of course (both pro and con)… (please see http://meetings.mpi-forum.org/ if you’d like to express your opinions about an MPI ABI!)

Additionally, the official site for MPI is http://www.mpi-forum.org/, not the Argonne site.