{"action":"created","issue":{"url":"https://api.github.com/repos/mpiforumbot/mpi-forum-historic/issues/33","repository_url":"https://api.github.com/repos/mpiforumbot/mpi-forum-historic","labels_url":"https://api.github.com/repos/mpiforumbot/mpi-forum-historic/issues/33/labels{/name}","comments_url":"https://api.github.com/repos/mpiforumbot/mpi-forum-historic/issues/33/comments","events_url":"https://api.github.com/repos/mpiforumbot/mpi-forum-historic/issues/33/events","html_url":"https://github.com/mpiforumbot/mpi-forum-historic/issues/33","id":167211305,"number":33,"title":"Fix Scalability Issues in Graph Topology Interface","user":{"login":"mpiforumbot","id":20617676,"avatar_url":"https://avatars.githubusercontent.com/u/20617676?v=3","gravatar_id":"","url":"https://api.github.com/users/mpiforumbot","html_url":"https://github.com/mpiforumbot","followers_url":"https://api.github.com/users/mpiforumbot/followers","following_url":"https://api.github.com/users/mpiforumbot/following{/other_user}","gists_url":"https://api.github.com/users/mpiforumbot/gists{/gist_id}","starred_url":"https://api.github.com/users/mpiforumbot/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/mpiforumbot/subscriptions","organizations_url":"https://api.github.com/users/mpiforumbot/orgs","repos_url":"https://api.github.com/users/mpiforumbot/repos","events_url":"https://api.github.com/users/mpiforumbot/events{/privacy}","received_events_url":"https://api.github.com/users/mpiforumbot/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/mpiforumbot/mpi-forum-historic/labels/MPI%202%5C.2","name":"MPI 2\\.2","color":"ededed"},{"url":"https://api.github.com/repos/mpiforumbot/mpi-forum-historic/labels/New%20routine%5C(s%5C)","name":"New routine\\(s\\)","color":"ededed"},{"url":"https://api.github.com/repos/mpiforumbot/mpi-forum-historic/labels/Not%20ready%20%5C/%20author%20rework","name":"Not ready \\/ author rework","color":"ededed"},{"url":"https://api.github.com/repos/mpiforumbot/mpi-forum-historic/labels/Text%20committed","name":"Text committed","color":"d93f0b"}],"state":"open","locked":false,"assignee":{"login":"mpiforumbot","id":20617676,"avatar_url":"https://avatars.githubusercontent.com/u/20617676?v=3","gravatar_id":"","url":"https://api.github.com/users/mpiforumbot","html_url":"https://github.com/mpiforumbot","followers_url":"https://api.github.com/users/mpiforumbot/followers","following_url":"https://api.github.com/users/mpiforumbot/following{/other_user}","gists_url":"https://api.github.com/users/mpiforumbot/gists{/gist_id}","starred_url":"https://api.github.com/users/mpiforumbot/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/mpiforumbot/subscriptions","organizations_url":"https://api.github.com/users/mpiforumbot/orgs","repos_url":"https://api.github.com/users/mpiforumbot/repos","events_url":"https://api.github.com/users/mpiforumbot/events{/privacy}","received_events_url":"https://api.github.com/users/mpiforumbot/received_events","type":"User","site_admin":false},"assignees":[{"login":"mpiforumbot","id":20617676,"avatar_url":"https://avatars.githubusercontent.com/u/20617676?v=3","gravatar_id":"","url":"https://api.github.com/users/mpiforumbot","html_url":"https://github.com/mpiforumbot","followers_url":"https://api.github.com/users/mpiforumbot/followers","following_url":"https://api.github.com/users/mpiforumbot/following{/other_user}","gists_url":"https://api.github.com/users/mpiforumbot/gists{/gist_id}","starred_url":"https://api.github.com/users/mpiforumbot/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/mpiforumbot/subscriptions","organizations_url":"https://api.github.com/users/mpiforumbot/orgs","repos_url":"https://api.github.com/users/mpiforumbot/repos","events_url":"https://api.github.com/users/mpiforumbot/events{/privacy}","received_events_url":"https://api.github.com/users/mpiforumbot/received_events","type":"User","site_admin":false}],"milestone":{"url":"https://api.github.com/repos/mpiforumbot/mpi-forum-historic/milestones/6","html_url":"https://github.com/mpiforumbot/mpi-forum-historic/milestones/2009/04/06%20Chicago","labels_url":"https://api.github.com/repos/mpiforumbot/mpi-forum-historic/milestones/6/labels","id":1900467,"number":6,"title":"2009/04/06 Chicago","description":"","creator":{"login":"mpiforumbot","id":20617676,"avatar_url":"https://avatars.githubusercontent.com/u/20617676?v=3","gravatar_id":"","url":"https://api.github.com/users/mpiforumbot","html_url":"https://github.com/mpiforumbot","followers_url":"https://api.github.com/users/mpiforumbot/followers","following_url":"https://api.github.com/users/mpiforumbot/following{/other_user}","gists_url":"https://api.github.com/users/mpiforumbot/gists{/gist_id}","starred_url":"https://api.github.com/users/mpiforumbot/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/mpiforumbot/subscriptions","organizations_url":"https://api.github.com/users/mpiforumbot/orgs","repos_url":"https://api.github.com/users/mpiforumbot/repos","events_url":"https://api.github.com/users/mpiforumbot/events{/privacy}","received_events_url":"https://api.github.com/users/mpiforumbot/received_events","type":"User","site_admin":false},"open_issues":1,"closed_issues":3,"state":"closed","created_at":"2016-07-23T22:09:07Z","updated_at":"2016-07-24T01:10:02Z","due_on":"2009-04-08T04:00:00Z","closed_at":"2016-07-23T22:09:07Z"},"comments":44,"created_at":"2016-07-24T01:04:36Z","updated_at":"2016-07-24T01:15:48Z","closed_at":null,"body":"**Originally by _traff_ on 2008-10-10 08:27:53 -0500**\n\n___\n# Fix Scalability Issues in Graph Topology InterfaceAuthor: Torsten Hoefler on behalf of the Collectives Workgroup. Alternative\nproposed after July 31st telecon by Jesper Larsson Traff. Proposal prepared\nbefore Menlo Park, December 2008, by Torsten and Jesper.\n\n## Status\n Sep 8 2008 Straw votes\n\n For a scalable description\n\n|| Yes || Maybe || No for 2.2 || Abstain ||\n|| 7 || 20 ||0 || 3 ||\n\n For adding info to weight of edges\n\n|| Yes || Maybe || No for 2.2 || Abstain ||\n|| 4 || 22 || 1 || 6 ||\n\nOctober 2008 Straw Vote\n\n|| Yes || Maybe || No for 2.2 || Abstain ||\n|| 23 || 0 || 0 || 5 ||\n\n## Description\nThe graph interface in MPI-1 has some serious (and unnecessary) scalability\nissues that prohibit efficient usage on large-scale machines.\n\nThe new scalable interface is essentially a single function, that\nis complemented by two inquiry functions. The concrete proposal introduces\ntwo new constants, and entails a few other changes related to the\ntopology functionality.\n\n## History\n\nThis interface was introduced in MPI-1 designed based on some older parallel\nlibrary (Alexander Supalov can provide details). However, the interface was\nnever changed. Right now, each process has to know the whole topology during\ngraph creation and every process can query the neighbors of every other process\nin the communicator with a local operation. This makes it necessary to store\nthe whole topology at every process locally which might be a prohibitive waste\nof memory resources.\n\nThe proposal is to introduce new functionality for specifying topologies by\ndistributed graphs, and deprecate the current MPI 2.1 graph topology\nfunctionality.\n\n## Proposed Solution\n\nPage 15, line 5, add:\n\n`MPI_UNWEIGHTED`\n\nPage 195, line 27, add:\n\n`MPI::Distgraphcomm MPI::Distgraphcomm::Dup() const`\n\nPage 242:15-22 - remove sentence\n\n\"Edges in the communication graph are not weighted, so that processes are either simply connected or not connected at\nall.\"\n\nand (outdated) rationale.\n\nPage 243, line 3: Replace\n\n\"The functions `MPI_GRAPH_CREATE` and `MPI_CART_CREATE` are used\"\n\nby\n\n\"The functions `MPI_GRAPH_CREATE`, `MPI_DIST_GRAPH_CREATE` and `MPI_CART_CREATE` are used\"\n\nPage 243, line 8, replace:\n\n\"All input arguments must have identical values on all processes of the group of comm_old. A new communicator ...\"\n\nby:\n\n\"For MPI_GRAPH_CREATE and MPI_CART_CREATE all input arguments must have identical values on all processes of the group of comm_old. \nFor MPI_DIST_GRAPH_CREATE the input communication graph is distributed across the calling processes. Therefore the processes provide different values for the arguments specifying the graph. Processes locally decide on whether reordering is allowed or desired, and may provide different values also for this argument. However, all processes must give the same value for the info argument. In all cases, a new communicator ...\"\n\nPage 243, line 33, add:\n\nFor distributed graphs, the functions `MPI_DIST_NEIGHBORS_COUNT` and `MPI_DIST_NEIGHBORS` can be used to extract the neighbors of the calling node.\n\nPage 247, after line 48, add new section:\n\n7.5.4 Distributed (Graph) Constructor\n\nThe general graph constructor assumes that each process passes the full (global) communication graph to the call. This limits the scalability of this\nconstructor. With the distributed graph interface, the communication graph is\nspecified in a fully distributed fashion. Each process contributes\nonly the part of the communication graph of which it is aware. Typically, this could be the set of processes from which the process will eventually receive or get data, or the set of processes to which the process will send or put data, or some combination of such edges. The interface, however, provides full flexibility, and processes can indicate that communication will occur between other pairs of processes.\nConcretely, each process calls the constructor\nwith a set of directed `(source,destination)` communication edges as described below. \nTo provide better possibilitites for\noptimization by the MPI implementation, the distributed graph constructor\npermits weighted communication edges, and takes an info argument that\ncan further influence process reordering or other optimizations performed by the\nMPI library, for instance by hinting on how the edge weights are to be\ninterpreted, on the quality of the reordering, and/or the time permitted\nfor the MPI library to process the graph.\n\n```\n#!c\nMPI_DIST_GRAPH_CREATE(comm_old, n, sources, degrees, destinations, weights, info, reorder, comm_graph)\n IN  comm_old      input communicator (handle)\n IN  n             number of source nodes for which this process\n                   contributes edges (non-negative integer)\n IN  sources       array containing the n source nodes for which this     \n                   process contributes edges (array of non-negative integers)\n IN  degrees       array specifying the number of destinations for each source node \n                   in the source node array (array of non-negative integers)\n IN  destinations  target nodes for the source nodes in the \n                   source node array (array of non-negative integers)\n IN  weights       weights for source to destination edges (array of non-negative integers)\n IN  info          hints on optimization and interpretation of weights (handle)\n IN  reorder       the process may be reordered (true) or not (false) (logical)\n OUT comm_graph    communicator with distributed graph topology added (handle)\n\nint MPI_Dist_graph_create(MPI_Comm comm_old, int n, int sources[], int degrees[], int destinations[],\n                          int weights[], MPI_Info info, int reorder, MPI_Comm *comm_graph)\n\n\nMPI_DIST_GRAPH_CREATE(COMM_OLD, N, SOURCES, DEGREES, DESTINATIONS, WEIGHTS, INFO, REORDER, COMM_GRAPH, IERROR)\n    INTEGER COMM_OLD, N, SOURCES(*), DEGREES(*), TARGETS(*) WEIGHTS(*) INFO, COMM_GRAPH, IERROR\n    LOGICAL REORDER\n\nMPI::Distgraphcomm MPI::Intracomm::Dist_graph_create(int n, \n                   const int sources[], const int degrees[],\n                   const int destinations[], const int weights[], \n                   MPI_Info info, bool reorder) const\n```\n\n`MPI_DIST_GRAPH_CREATE` returns a handle to a new communicator to which\nthe distributed graph topology information is attached.  Each process\npasses an array of `n` source nodes in the `sources` array.  For each source node, a non-negative number of destination nodes are specified in the\n`degrees` array. The destination nodes are stored in the corresponding\nconsecutive segment of the `destinations` array. More precisely if the\n`i`-th node in `sources` is `s`, this specifies\n`degrees[i]` edges `(s,d)` with the `j`-th such edge stored\nin `destinations[degrees[0]+...+degrees[i-1]+j]`. The weight of this edge\nis stored in `weights[degrees[0]+...+degrees[i-1]+j]`.  Both the\n`sources` and the `destinations` arrays may contain the same node more\nthan once, and the order in which nodes are listed as destinations or sources\nis not significant. Source and destination nodes must be process ranks of\n`comm_old`. Different processes may specify different numbers of source and destination nodes, as well as different source to destination edges. This allows a fully distributed specification of the communication graph.\n\nThe call creates a new communicator `comm_graph` of distributed\ngraph topology type to which topology information has been attached. The size\nof `comm_graph` is identical to the size of `comm_old`.\nIsolated processes (i.e., processes with no outgoing or incoming edges, that is, processes that do not occur as source or destination node in the graph specification) are allowed. The call to `MPI_Dist_graph_create` is collective.\n\nA process calling with `reorder` # `false` will have the same rank in `comm_graph` as in `comm_old`. For processes calling with `reorder``true` the MPI library is free to remap to other processes (of `comm_old`) in order to improve communication on the edges of the communication graph.\nThe weight\nassociated with each edge is a hint to the MPI library about the amount or\nintensity of communication on that edge, and may be used to compute a\n\"best\" reordering.\n\n-Advice to users.*\nSpecifying `reorder` # `false` on only some processes can support heterogeneous application to hardware mapping. For example, suppose an application does visualization or heavy I/O on rank 0, and that only this processor has the corresponding visualization or I/O capabilities. If this rank should be part of a distributed graph topology, it is useful to specify that this rank will not be remapped. Allowing remapping of other ranks can then exploit features of the interconnection network topology. Another scenario is an application where some ranks have large state information that would be (too) expensive to migrate. Setting `reorder``false` for these ranks guarantees that migration will not be necessary since these processes will preserve their rank in the distributed graph communicator.\n(*End of advice to users.*)\n\n-Advice to implementors.*\nThe reordering optimization problem must account for the constraint that processes with `reorder` = `false` must remain fixed. An easy way to do this is to eliminate the fixed nodes and all their edges, and solve the optimization problem on the reduced graph. However, better results may be possible by considering the entire graph.\n(*End of advice to implementors.*)\n\nWeights are specified as non-negative integers and can be used to\ninfluence the process remapping strategy and other internal MPI\noptimizations. For instance, approximate count arguments of later\ncommunication calls along specific edges could be used as their edge\nweights. Multiplicity of edges can likewise indicate more intense\ncommunication between pairs of processes. However, the exact meaning of\nedge weights is not specified by the MPI standard, and left to the\nimplementation. An application can supply the special value `MPI_UNWEIGHTED` for the weight array to\nindicate that all edges have the same (effectively no) weight. It is erroneous\nto supply `MPI_UNWEIGHTED` for some but not all processes of\n`comm_old`.\n\nThe meaning of the `weights` argument can be influenced by the\n`info` argument. Info arguments can be used to guide the mapping,\npossible options are for example minimizing the maximum number of edges between processes on different SMP nodes (for SMP systems), or minimizing the sum of all such edges.  An MPI\nimplementation is not obliged to follow specific hints, and it is \nlegal for an MPI implementation not to do any reordering.  An MPI\nimplementation may specify more `info` key-value pairs. All processes must specify the same set of key-value `info` pairs. \n\n-Advice to implementors.*\nMPI implementations must document any additionally supported\nkey-value `info` pairs. `MPI_INFO_NULL` is always valid,\nand may indicate the default creation of the distributed graph topology to the MPI library.\n(*End of advice to implementors.*)\n\n-Advice to implementors.*\nAn implementation does not explicitly need to construct the topology from its distributed parts. However, all processes can easily construct the full topology from the distributed specification and use this in a call to `MPI_GRAPH_CREATE` to create the topology.\nThis may serve as a reference implementation of the\nfunctionality, and may be acceptable for small communicators. However, a\nscalable high-quality implementation would save the topology graph in a\ndistributed way.\n(*End of advice to implementors.*)\n\nExample 7.3  \nAs for Example 7.2., assume there are four processes 0, 1,\n2, 3 with the following adjacency matrix and unit edge weights:\n\n|| process || neighbors ||\n|| 0       || 1, 3      ||\n|| 1       || 0         ||\n|| 2       || 3         ||\n|| 3       || 0, 2      ||\n\nThis graph could be constructed in many different ways. One way would be\nthat each process contributes its outgoing edges. The arguments per\nprocess would be:\n\n|| process ||  n  || sources || degrees || destinations || weights ||\n|| 0       ||  1  || 0       || 2       || 1,3          || 1,1     ||\n|| 1       ||  1  || 1       || 1       || 0            || 1       ||\n|| 2       ||  1  || 2       || 1       || 3            || 1       ||\n|| 3       ||  1  || 3       || 2       || 0,2          || 1,1     ||\n\nAnother way would be to pass the whole graph on process 0, this could be\ndone with the following arguments per process:\n|| process ||  n  || sources || degrees || destinations || weights     ||\n|| 0       ||  4  || 0,1,2,3 || 2,1,1,2 || 1,3,0,3,0,2  || 1,1,1,1,1,1 ||\n|| 1       ||  0  || -       || -       || -            || -           ||\n|| 2       ||  0  || -       || -       || -            || -           ||\n|| 3       ||  0  || -       || -       || -            ||           ||\n\nIn both cases above, the user could supply `MPI_UNWEIGHTED` instead of explicitly providing identical weights.\n\nExample 7.4  \nA two-dimensional PxQ torus where all processes communicate\nalong the dimensions and along the diagonal edges. This cannot be modelled with Cartesian topologies, but can easily be captured with the distributed graph functionality as shown in the following\ncode. In this example, the communications along the dimensions is twice as heavy as the\ncommunication along the diagonals:\n\n```\n#!c\n/*\nInput:     dimensions P, Q\nCondition: number of processes equal to P*Q; otherwise only \n           ranks smaller than P*Q participate\n*/\nint rank;\nMPI_Comm_rank(MPI_COMM_WORLD, &rank);\n\n/* get x and y dimension */\nint y=rank/P; int x=rank%P;\n\nint destinations[8], weights[8];\n/* get my communication partners along x dimension */\ndestinations[0] # P*y+(x+1)%P; weights[0]2;\ndestinations[1] # P*y+(P+x-1)%P; weights[1]2;\n\n/* get my communication partners along y dimension */\ndestinations[2] # P*((y+1)%Q)+x; weights[3]2;\ndestinations[3] # P*((Q+y-1)%Q)+x; weights[4]2;\n\n/* get my communication partners along diagonals */\ndestinations[4] # P*((y+1)%Q)+(x+1)%P; weights[5]1;\ndestinations[5] # P*((Q+y-1)%Q)+(x+1)%P; weights[6]1;\ndestinations[6] # P*((y+1)%Q)+(P+x-1)%P; weights[7]1;\ndestinations[7] # P*((Q+y-1)%Q)+(P+x-1)%P; weights[8]2;\n\nint sources[1], degrees[1];\nsources[0] = rank;\ndegrees[0] = 8;\nMPI_Dist_graph_create(MPI_COMM_WORLD, 1, sources, degrees, destinations,\n  weights, MPI_INFO_NULL, 1, comm_graph)\n```\n\n\nPage 248, line 21, add: \n\n`MPI_DIST_GRAPH`   distributed graph topology\n\n\nPage 252, line 6, add:\n\n```\n#!c\nMPI_DIST_GRAPH_NEIGHBORS_COUNT(comm, indegree, outdegree, weighted)\n IN      comm          communicator with distributed graph topology (handle)\n OUT     indegree      number of edges into this process (non-negative integer)\n OUT     outdegree     number of edges out of this process (non-negative integer)\n OUT     weighted      false if MPI_UNWEIGHTED was supplied during creation, true otherwise\n\nint MPI_Dist_graph_neighbors_count(MPI_Comm comm, int *indegree, int *outdegree, int *weighted)\n\nMPI_DIST_GRAPH_NEIGHBORS_COUNT(COMM, INDEGREE, OUTDEGREE, WEIGHTED, IERROR)\n  INTEGER COMM, INDEGREE, OUTDEGREE, IERROR\n  LOGICAL WEIGHTED\n\nvoid MPI::Distgraphcomm::Get_dist_neighbors_count(int rank, int indegree[], int outdegree[], bool *weighted) const\n\n```\n\nMPI_DIST_GRAPH_NEIGHBORS_COUNT and MPI_DIST_GRAPH_NEIGHBORS provide adjacency\ninformation for a distributed graph topology.\n\n```\n#!c\nMPI_DIST_GRAPH_NEIGHBORS(comm, maxindegree, sources, sourceweights, maxoutdegree, destinations, destweights)\n IN      comm           communicator with distributed graph topology (handle)\n IN      maxindegree    size of sources and sourceweights arrays (non-negative integer)\n OUT     sources        processes for which the calling process is a destination (array of non-negative integers)\n OUT     sourceweights  weights of the edges into the calling process (array of non-negative integers)\n IN      maxoutdegree   size of destinations and destweights arrays (non-negative integer)\n OUT     destinations   processes for which the calling process is a source (array of non-negative integers)\n OUT     destweights    weights of the edges out of the calling process (array of non-negative integers)\n\nint MPI_Dist_graph_neighbors(MPI_Comm comm, int maxindegree, in sources[], int sourceweights[],\n                             int maxoutdegree, int destinations[], int destweights[])\n\nMPI_DIST_GRAPH_NEIGHBORS(COMM, MAXINDEGREE, SOURCES, SOURCEWEIGHTS, MAXOUTDEGREE, OUTDEGREE,\n                         DESTINATIONS, DESTWEIGHTS, IERROR)\n  INTEGER COMM, MAXINDEGREE, SOURCES(*), SOURCEWEIGHTS(*), MAXOUTDEGREE, OUTDEGREE, DESTINATIONS(*),\n          DESTWEIGHTS(*), IERROR\n\nvoid MPI::Distgraphcomm::Get_dist_neighbors(int rank, int maxindegree, int sources[],\n                                        int sourceweights[], int maxoutdegree, int destinations[],\n                                        int destweights[])\n```\n\nThese calls are local. If `MPI_UNWEIGHTED` is supplied for `sourceweights` or\n`destweights` or both, or if `MPI_UNWEIGHTED` was supplied during the\nconstruction of the graph then no weight information is returned in that array\nor those arrays. The only requirement on the sequence of values in\n`sources` and `destinations` is that two calls to the routine with same input\nargument `comm` will return the same sequence of edges. If `maxindegree`\nor `maxoutdegree` is smaller than the numbers returned by\nMPI_DIST_GRAPH_NEIGHBOR_COUNT, then only the first part of the full list is\nreturned. \n\n-Advice to implementors:* \nSince the query calls are defined to be local,\neach process needs to store the list of its neighbors with incoming and\noutgoing edges. Communication is required at the collective `MPI_Dist_graph_create` call in order to compute the neighbor lists for each process from the distributed graph specification,\n(*End of advice to implementors.*)\n\nPage 450, line 13, add:\n\n`class Distgraphcomm : public Intracomm  {...};`\n\nPage 457, line 11, add:\n\n`Distgraphcomm& Distgraphcomm::Clone() const`\n\nPage 457, line 34, replace:\n\n`// Cartcomm and Graphcomm are similarly defined`\n\nby:\n\n`// Cartcomm, Graphcomm and Distgraphcomm are similarly defined`\n\nPage 497 (Appendix A), line 9, add:\n\n`MPI_DIST_GRAPH MPI::DIST_GRAPH`\n\nPage 500, line 6, add:\n\n`MPI::Distgraphcomm`\n\n## Functions to Deprecate (optional)\n\nThe following functions may be deprecated by this proposal (for\nMPI 2.2 or MPI 3.0). The proposal is not dependent on whether this\nhappens or not, and the discussion on this should be kept separate.\n\n```\n#!c\nMPI_GRAPH_CREATE(comm_old, nnodes, index, edges, reorder, comm_graph)\n IN  comm_old   input communicator (handle)\n IN  nnodes     number of nodes in graph (integer)\n IN  index      array of integers describing node degrees (see below)\n IN  edges      array of integers describing graph edges (see below)\n IN  reorder    ranking may be reordered (true) or not (false) (logical)\n OUT comm_graph communicator with graph topology added (handle)\n```\n```\n#!c\nMPI_GRAPH_MAP(comm, nnodes, index, edges, newrank)\n IN      comm                      input communicator (handle)\n IN      nnodes                    number of graph nodes (integer)\n IN      index                     integer array specifying the graph structure, see MPI_GRAPH_CREATE\n IN      edges                     integer array specifying the graph structure\n OUT     newrank                   reordered rank of the calling process;\n                                   MPI_UNDEFINED if the calling process does not belong to graph (integer)\n```\n\n```\n#!c\nMPI_GRAPH_NEIGHBORS(comm, rank, maxneighbors, neighbors)\n IN      comm                    communicator with graph topology (handle)\n IN      rank                    rank of process in group of comm (integer)\n IN      maxneighbors            size of array neighbors (integer)\n OUT     neighbors               ranks of processes that are neighbors to specified process (array of integer)\n```\n\n```\n#!c\nMPI_GRAPH_NEIGHBORS_COUNT(comm, rank, nneighbors)\n IN      comm                 communicator with graph topology (handle)\n IN      rank                 rank of process in group of comm (integer)\n OUT     nneighbors           number of neighbors of specified process (integer)\n```\n\n```\n#!c\nMPI_GRAPH_GET(comm, maxindex, maxedges, index, edges)\n IN      comm                     communicator with graph structure (handle)\n IN      maxindex                 length of vector index in the calling program\n                                  (integer)\n IN      maxedges                 length of vector edges in the calling program\n                                  (integer)\n OUT     index                    array of integers containing the graph structure (for\n                                  details see the definition of MPI_GRAPH_CREATE)\n OUT     edges                    array of integers containing the graph structure\n```\n\n\n```\n#!c\nMPI_GRAPHDIMS_GET(comm, nnodes, nedges)\n IN      comm                    communicator for group with graph structure (handle)\n OUT     nnodes                  number of nodes in graph (integer) (same as number\n                                 of processes in the group)\n OUT     nedges                  number of edges in graph (integer)\n```\n\nSince MPI_DIST_GRAPH_CREATE is collective, it would be a small matter to compute the total number of edges. Thus, MPI_GRAPHDIMS_GET could be kept. Note that nnodes is equal to the number of processes in comm.\n\n### Possible additional functionality\n\nTo be discussed:\n\n```\n#!c\nMPI_DIST_EDGE_COUNT(comm, edges)\n IN comm              communicator with distributed graph topology (handle)\n OUT edges (integer)  total number of edges in distributed graph\n```\n\n\n## Impact on Implementations\n\nImplementations have to add the new functions, which can easily be\nimplemented on top of the existing, general graph interface. This\ntrivial implementation requires little work.\n\n\n## Impact on Applications / Users\n\nUsers who want to use the new functionality will have to change calls to\ngraph creation and neighbor query functions. They have to introduce\nexplicit communication of neighbor lists if they query other processes\nneighbors (this is unlikely).\n\n## Alternative Solutions\n\nFor more discussion/connection to topological collectives, see [wiki:TopoColl]\n\n\n## Entry for the Change Log\n\nNew functions for a scalable distributed graph topology interface has been added. \n\nSection 7.5.3, page 247, add function\n`MPI_DIST_GRAPH_CREATE`.\n\nSection 7.5.4, page 252, add functions\n`MPI_DIST_NEIGHBORS_COUNT` and `MPI_DIST_NEIGHBORS`.\n\nSection 7.5.3, page 247, add constant `MPI_UNWEIGHTED`.\n\nSection 7.5.4, page 248, add constant `MPI_DIST_GRAPH`.\n\nSection 7.5.4, page 247, add derived C++ class `Distgraphcomm`.\n "},"comment":{"url":"https://api.github.com/repos/mpiforumbot/mpi-forum-historic/issues/comments/234750629","html_url":"https://github.com/mpiforumbot/mpi-forum-historic/issues/33#issuecomment-234750629","issue_url":"https://api.github.com/repos/mpiforumbot/mpi-forum-historic/issues/33","id":234750629,"user":{"login":"mpiforumbot","id":20617676,"avatar_url":"https://avatars.githubusercontent.com/u/20617676?v=3","gravatar_id":"","url":"https://api.github.com/users/mpiforumbot","html_url":"https://github.com/mpiforumbot","followers_url":"https://api.github.com/users/mpiforumbot/followers","following_url":"https://api.github.com/users/mpiforumbot/following{/other_user}","gists_url":"https://api.github.com/users/mpiforumbot/gists{/gist_id}","starred_url":"https://api.github.com/users/mpiforumbot/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/mpiforumbot/subscriptions","organizations_url":"https://api.github.com/users/mpiforumbot/orgs","repos_url":"https://api.github.com/users/mpiforumbot/repos","events_url":"https://api.github.com/users/mpiforumbot/events{/privacy}","received_events_url":"https://api.github.com/users/mpiforumbot/received_events","type":"User","site_admin":false},"created_at":"2016-07-24T01:15:48Z","updated_at":"2016-07-24T01:15:48Z","body":"**Originally by _htor_ on 2009-04-02 13:08:19 -0500**\n\n___\nReplying to smithbr:\n> In the example, why is the weight 2 for the \"backwards\" diagonal? Is that a typo?\nyes, that's indeed a typo - fixed!\n\nBest,\n Torsten"}}
{"actor":{"display_login":"mpiforumbot"}}