Hi Rajeev, thank you for the clarification. It is most helpful. kindest regards Mike On 18 February 2016 at 13:55, Thakur, Rajeev <[email protected]> wrote:

Your understanding is correct in that the communicator you pass needs to contain the processes to which the message is sent or received from. The standard is saying it in a simple way.

But I would suggest reconsidering whether you really need pack and unpack in the first place. They are rarely used functions, and there is an associated performance penalty. You could try sending the messages directly, e.g., by using derived datatypes if the data is noncontiguous.

Rajeev

...

On Feb 17, 2016, at 8:38 PM, Michael Rezny <[email protected]> wrote:

Hi Rajeev, thanks for the prompt response.

I am attempting to ensure that our code conforms to the standard.

Would it be correct to say that, for the MPI standard, the communicator used in MPI_Pack must be a superset of the ranks in the communicator used subsequently by MPI calls that use the packed buffer?

And likewise, is it correct to state that MPI_Unpack must use a communicator that is a superset of the communicator used to receive or create the buffer that is input to MPI_Unpack?

If that is the case, then would MPI_COMM_WORLD always bea valid option for use as a communicator in MPI_Pack and MPI_Unpack?

Then, as you said, in a homogeneous system, there should be no disadvantage in specifying MPI_COMM_WORLD.

Perhaps the standard and man pages for MPI_Pack could be restated:

...

The comm argument must include all (be a superset) of all the

communicator"s" that will be

...

subsequently used for sending the packed message.

And something similar for MPI_Unpack.

kindest regards Mike

On 18 February 2016 at 12:57, Thakur, Rajeev <[email protected]> wrote: You can use MPI_COMM_WORLD as the communicator. If you are running on a homogeneous system, there shouldn’t be any performance issue in using MPI_COMM_WORLD as the communicator either.

Rajeev

...

On Feb 17, 2016, at 6:09 PM, Michael Rezny <[email protected]> wrote:

Hi, I have a question regarding the use of a communicator in MPI_Pack and MPI_Unpack. I have googled and search the MPI mailing lists but haven't found an answer.

The OpenMPI man page for MPI_Pack states: The comm argument is the communicator that will be subsequently used for sending the packed message.

And something similar for MPI_Unpack.

Which seems to reflect what is defined in the MPI standards.

Basically, what I would like to do is to have an MPI rank as a coupler. That is, receiving a packed message from one application and passing it to another application.

Comm_A would be the ranks of application A plus the coupler and Comm_B would be the ranks of application B plus the coupler.

In this case, MPI_COMM_WORLD = Comm_A U Comm_B.

I would like to have a solution that does not have the coupler unpacking the buffer received from application A and then packing it to send it to application B

I just found a very nice explanation of the need for a communicator in Pack / Unpack on page 135 of Using MPI Portable Parallel Programming with the Message-Passing Interface second edition by Gropp, Lusk, and Skjellum.

If I understand this correctly, it would be legal to use MPI_COMM_WORLD as the communicator for MPI_Pack and MPI_Unpack. The only downside is that one might not get the optimal performance.

The alternative we are using is to use MPI_Pack_external and MPI_Unpack_external which requires no communicator. But the downside is that on homogeneous little-endian HPCs, this will always entail byte swapping on packing and unpacking.

So my question is: What is the correct and optimal way to implement passing packed messages in the coupling example described above?

kindest regards Mike _______________________________________________ mpi-forum mailing list [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum

_______________________________________________ mpi-forum mailing list [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum

_______________________________________________ mpi-forum mailing list [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum

_______________________________________________ mpi-forum mailing list [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum