communication domain
Any point-to-point or collective communication occurs in MPI within a communication domain. Such a communication domain is represented by a set of communicators with consistent values, one at each of the participating processes; each communicator is the local representation of the global communication domain. If this domain is for intra-group communication then all the communicators are intracommunicators, and all have the same group attribute. Each communicator identifies all the other corresponding communicators.
One can think of a communicator as an array of links to other communicators. An intra-group communication domain is specified by a set of communicators such that communication domain, intra
Figure: Distributed data structure for intra-communication domain.
We discuss inter-group communication domains in
Section .
In point-to-point communication, matching send and receive calls should have communicator arguments that represent the same communication domains. The rank of the processes is interpreted relative to the group, or groups, associated with the communicator. Thus, in an intra-group communication domain, process ranks are relative to the group associated with the communicator.
Similarly, a collective communication call involves all processes in the group of an intra-group communication domain, and all processes should use a communicator argument that represents this domain. Intercommunicators may not be used in collective communication operations.
We shall sometimes say, for simplicity, that two communicators are the same, if they represent the same communication domain. One should not be misled by this abuse of language: Each communicator is really a distinct object, local to a process. Furthermore, communicators that represent the same communication domain may have different attribute values attached to them at different processes.
MPI is designed to ensure that communicator constructors always
generate consistent communicators that are a valid representation of
the newly created communication domain.
This is done by requiring that a new
intracommunicator be
constructed out of an existing parent communicator, and that
this be a collective operation over all processes in the group associated with
the parent communicator. The group associated with a new intracommunicator
must be a subgroup of that associated with the parent
intracommunicator.
Thus, all
the intracommunicator constructor routines described
in Section have an existing
communicator as an input argument, and the newly created intracommunicator
as an output argument. This leads to a chicken-and-egg situation since
we must have an existing communicator to create a new communicator.
This problem is solved by the provision of a predefined intracommunicator,
MPI_COMM_WORLD, which is available for use once
MPI_COMM_WORLD
the routine MPI_INIT has been called.
MPI_COMM_WORLD, which has
as its group attribute all processes with which the local process can
communicate, can be used as the parent communicator in
constructing new communicators.
A second pre-defined communicator, MPI_COMM_SELF, is also
MPI_COMM_SELF
available for use after calling MPI_INIT and
has as its associated group just the process itself.
MPI_COMM_SELF is provided as a convenience since it could
easily be created out of MPI_COMM_WORLD.