[Mpi-forum] use of communicator in MPI_Pack and MPI_Unpack

[Michael Rezny]

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 <thakur at mcs.anl.gov> 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 <michael.rezny at monash.edu>
> 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
> > mpi-forum at lists.mpi-forum.org
> > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum
>
> _______________________________________________
> mpi-forum mailing list
> mpi-forum at lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpi-forum.org/pipermail/mpi-forum/attachments/20160218/fef7f9ae/attachment-0001.html>