9.5.5. Topology Inquiry Functions

If a virtual topology has been defined with one of the above functions, then the topology information can be looked up using inquiry functions. They all are local calls.

The function MPI_TOPO_TEST returns the type of topology that is associated with a communicator.

The output value status is one of the following:

The functions MPI_CARTDIM_GET and MPI_CART_GET return the Cartesian topology information that is associated with the communicator. If comm is associated with a zero-dimensional Cartesian topology, MPI_CARTDIM_GET returns ndims = 0 and MPI_CART_GET will keep all output arguments unchanged.

For a communicator with an associated Cartesian topology, the function MPI_CART_RANK translates the logical coordinates of an MPI process to the corresponding rank in the group of the communicator. For dimension i with periods(i) = true, if the coordinate, coords(i), is out of range, that is, coords(i) < 0 or coords(i) ≥ dims(i), it is shifted back to the interval 0 ≤ coords(i) < dims(i) automatically. Out-of-range coordinates are erroneous for nonperiodic dimensions.

If comm is associated with a zero-dimensional Cartesian topology, coords is not significant and 0 is returned in rank.

The inverse mapping, rank-to-coordinates translation is provided by MPI_CART_COORDS. If comm is associated with a zero-dimensional Cartesian topology, coords will be unchanged. If maxdims is less than the number of dimensions of the Cartesian topology associated with the communicator comm, the outcome is unspecified.

MPI_GRAPH_NEIGHBORS_COUNT and MPI_GRAPH_NEIGHBORS provide adjacency information for a graph topology. The returned count and array of neighbors for the queried rank will both include all neighbors and reflect the same edge ordering as was specified by the original call to MPI_GRAPH_CREATE. Specifically, MPI_GRAPH_NEIGHBORS_COUNT and MPI_GRAPH_NEIGHBORS will return values based on the original index and edges array passed to MPI_GRAPH_CREATE (for the purpose of this example, we assume that index[-1] is zero):

• The number of neighbors ( nneighbors) returned from MPI_GRAPH_NEIGHBORS_COUNT will be ( index[rank] - index[rank-1]).
• The neighbors array returned from MPI_GRAPH_NEIGHBORS will be edges[index[rank-1]] through edges[index[rank]-1].

Assume there are four MPI processes with ranks 0, 1, 2, 3 in the input communicator with the following adjacency matrix (note that some neighbors are listed multiple times):

Thus, the input arguments to MPI_GRAPH_CREATE are:

Therefore, calling MPI_GRAPH_NEIGHBORS_COUNT and MPI_GRAPH_NEIGHBORS for each of the four MPI processes will return:

Example Using a communicator with an associated graph topology that represents a shuffle-exchange network.

Suppose that comm is a communicator with a shuffle-exchange topology. The group has 2ⁿ members. Each MPI process is labeled by a₁ , ..., a_n with a_i ∈ {0,1}, and has three neighbors: exchange( ( ), shuffle(a₁ , ..., a_n )= a₂ , ..., a_n, a₁, and unshuffle(a₁ , ..., a_n ) = a_n , a₁ , ... , a_n-1. The graph adjacency list is illustrated below for n=3.

Suppose that the communicator comm has this topology associated with it. The following code fragment cycles through the three types of neighbors and performs an appropriate permutation for each.

!  assume: each MPI process has stored a real number A. 
!  extract neighborhood information 
CALL MPI_COMM_RANK(comm, myrank, ierr) 
CALL MPI_GRAPH_NEIGHBORS(comm, myrank, 3, neighbors, ierr) 
!  perform exchange permutation 
CALL MPI_SENDRECV_REPLACE(A, 1, MPI_REAL, neighbors(1), 0, & 
                          neighbors(1), 0, comm, status, ierr) 
!  perform shuffle permutation 
CALL MPI_SENDRECV_REPLACE(A, 1, MPI_REAL, neighbors(2), 0, & 
                          neighbors(3), 0, comm, status, ierr) 
!  perform unshuffle permutation 
CALL MPI_SENDRECV_REPLACE(A, 1, MPI_REAL, neighbors(3), 0, & 
                          neighbors(2), 0, comm, status, ierr) 

MPI_DIST_GRAPH_NEIGHBORS_COUNT and MPI_DIST_GRAPH_NEIGHBORS provide adjacency information for a distributed graph topology.

These calls are local. The number of edges into and out of the MPI process returned by MPI_DIST_GRAPH_NEIGHBORS_COUNT are the total number of such edges given in the call to MPI_DIST_GRAPH_CREATE_ADJACENT or MPI_DIST_GRAPH_CREATE (potentially by MPI processes other than the calling MPI process in the case of MPI_DIST_GRAPH_CREATE). Multiply-defined edges are all counted and returned by MPI_DIST_GRAPH_NEIGHBORS in some order. If MPI_UNWEIGHTED is supplied for sourceweights or destweights or both, or if MPI_UNWEIGHTED was supplied during the construction of the graph then no weight information is returned in that array or those arrays. If the communicator was created with MPI_DIST_GRAPH_CREATE_ADJACENT then for each MPI process in comm, the order of the values in sources and destinations is identical to the input that was used by the MPI process with the same rank in comm_old in the creation call. If the communicator was created with MPI_DIST_GRAPH_CREATE then the only requirement on the order of values in sources and destinations is that two calls to the routine with same input argument comm will return the same sequence of edges. If maxindegree or maxoutdegree is smaller than the numbers returned by MPI_DIST_GRAPH_NEIGHBORS_COUNT, then only the first part of the full list is returned.

Advice to implementors.

Since the query calls are defined to be local, each MPI process needs to store the list of its neighbors with incoming and outgoing edges. Communication is required at the collective MPI_DIST_GRAPH_CREATE call in order to compute the neighbor lists for each MPI process from the distributed graph specification. ( End of advice to implementors.)