{"action":"created","issue":{"url":"https://api.github.com/repos/mpiforumbot/mpi-forum-historic/issues/269","repository_url":"https://api.github.com/repos/mpiforumbot/mpi-forum-historic","labels_url":"https://api.github.com/repos/mpiforumbot/mpi-forum-historic/issues/269/labels{/name}","comments_url":"https://api.github.com/repos/mpiforumbot/mpi-forum-historic/issues/269/comments","events_url":"https://api.github.com/repos/mpiforumbot/mpi-forum-historic/issues/269/events","html_url":"https://github.com/mpiforumbot/mpi-forum-historic/issues/269","id":167239487,"number":269,"title":"Support for 'w' variants of 'v' collectives","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/Forum%20feedback%20requested","name":"Forum feedback requested","color":"f9d0c4"},{"url":"https://api.github.com/repos/mpiforumbot/mpi-forum-historic/labels/MPI%203%5C.0","name":"MPI 3\\.0","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/Withdrawn","name":"Withdrawn","color":"d4c5f9"}],"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/19","html_url":"https://github.com/mpiforumbot/mpi-forum-historic/milestones/2011/03/28%20Chicago,%20USA","labels_url":"https://api.github.com/repos/mpiforumbot/mpi-forum-historic/milestones/19/labels","id":1900480,"number":19,"title":"2011/03/28 Chicago, USA","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":0,"state":"closed","created_at":"2016-07-23T22:09:10Z","updated_at":"2016-07-24T15:46:40Z","due_on":"2011-03-30T04:00:00Z","closed_at":"2016-07-23T22:09:10Z"},"comments":2,"created_at":"2016-07-24T15:46:38Z","updated_at":"2016-07-24T15:46:44Z","closed_at":null,"body":"**Originally by _ftillier_ on 2011-03-04 16:10:27 -0600**\n\n___\nThis proposal completes support for transfers of more than 2^31^ elements by allowing such large transfers to be performed with collective operations.\n\nSpecifically, this proposal defines new 'w' versions of collective calls that are missing them but have 'v' versions to allow receiving different amounts of data from different ranks.  This is required since for large counts the count parameter is implied by the type, so receiving different length (non-multiple) data from different ranks requires different datatypes.\n\nThis ticket references mpi3.0_draft_1.pdf (aka the November 2010 MPI 3 draft.)\n\n# NOTE: THE LATEST ATTACHED PDF IS AUTHORITATIVE!  It contains some updates that are not included in the text of this ticket (per advice from the !Forum/Bill Gropp)## History\nThis proposal is a derivative of the MPI Forum Ticket #265, which originally included this functionality.  However the new collective functions were the main point of contention at the Febrary 2011 MPI Forum meeting.  The collective functionality was therefore broken out of Ticket #265 in order to separate the functionality into logically smaller, self-standing proposals.\n\n-*The need for datatype vector collectives:** The current gather, scatter, and allgather vector collectives do not support specifying different datatypes for different participants.  In light of support for large counts (Ticket #265) the current vector collectives prevent mixed small and large count operations.  This proposal introduces MPI_GATHERW, MPI_SCATTERW, MPI_ALLGATHERW, and their non-blockign counterparts to support non-uniform (vector) gather, scatter, or allgather operation where some of the participatns exchange more than 2^31^ elements requires using derived datatypes to represent such large counts.\n\n## Proposed Solution\n**Chapter 5: Collective Communication**\n\nPage 131, line 24:\n```\n#!div style=\"background: #f7f7f7; border: 1px solid #d7d7d7; margin: 1em 1.75em; padding: .25em; overflow: auto;\"\n - MPI_GATHER, MPI_IGATHER, MPI_GATHERV, MPI_IGATHERV[[span(__, MPI_GATHERW, MPI_IGATHERW__, style=color:blue)]]: Gather data from all members of a group to one member (Section 5.5 and Section 5.12.3). This is shown as \"gather\" in Figure 5.1.\n - MPI_SCATTER, MPI_ISCATTER, MPI_SCATTERV, MPI_ISCATTERV[[span(__, MPI_SCATTERW, MPI_ISCATTERW__, style=color:blue)]]: Scatter data from one member to all members of a group (Section 5.6 and Section 5.12.4). This is shown as \"scatter\" in Figure 5.1.\n - MPI_ALLGATHER, MPI_IALLGATHER, MPI_ALLGATHERV, MPI_IALLGATHERV[[span(__, MPI_ALLGATHERW, MPI_IALLGATHERW__, style=color:blue)]]: A variation on Gather where all members of a group receive the result (Section 5.7 and Section 5.12.5). This is shown as \"allgather\" in Figure 5.1.\n```\n\nPage 135, line 9:\n```\n#!div style=\"background: #f7f7f7; border: 1px solid #d7d7d7; margin: 1em 1.75em; padding: .25em; overflow: auto;\"\n**All-To-All** All processes contribute to the result. All processes receive the result.\n - MPI_ALLGATHER, MPI_IALLGATHER, MPI_ALLGATHERV, MPI_IALLGATHERV[[span(__, MPI_ALLGATHERW, MPI_IALLGATHERW__, style=color:blue)]]\n - MPI_ALLTOALL, MPI_IALLTOALL, MPI_ALLTOALLV, MPI_IALLTOALLV, MPI_ALLTOALLW, MPI_IALLTOALLW\n - MPI_ALLREDUCE, MPI_IALLREDUCE, MPI_REDUCE_SCATTER_BLOCK, MPI_IREDUCE_SCATTER_BLOCK, MPI_REDUCE_SCATTER, MPI_IREDUCE_SCATTER\n - MPI_BARRIER, MPI_IBARRIER\n\n-*All-To-One** All processes contribute to the result. One process receives the result.\n - MPI_GATHER, MPI_IGATHER, MPI_GATHERV, MPI_IGATHERV[[span(__, MPI_GATHERW, MPI_IGATHERW__, style=color:blue)]]\n - MPI_REDUCE, MPI_IREDUCE\n\n-*One-To-All** One process contributes to the result. All processes receive the result.\n - MPI_BCAST, MPI_IBCAST\n - MPI_SCATTER, MPI_ISCATTER, MPI_SCATTERV, MPI_ISCATTERV[[span(__, MPI_SCATTERW, MPI_ISCATTERW__, style=color:blue)]]\n```\n\n-* MPI_Gatherw **\n\nPage 142, line 25:\n```\n#!div style=\"background: #f7f7f7; border: 1px solid #d7d7d7; margin: 1em 1.75em; padding: .25em; overflow: auto; color:blue; text-decoration:underline\"\nMPI_GATHERW(sendbuf, sendcount, sendtype, recvbuf, recvcounts, displs, recvtypes, root, comm)[[br]]\n IN sendbuf::\n  starting address of send buffer (choice)\n IN sendcount::\n  number of elements in send buffer (non-negative integer)\n IN sendtype::\n  data type of send buffer elements (handle)\n OUT recvbuf::\n  address of receive buffer (choice, significant only at root)\n IN recvcounts::\n  non-negative integer array (of length group size) containing the number of elements that are received from each process (significant only at root)\n IN displs:\n  integer array (of length group size). Entry i specifies the displacement relative to recvbuf at which to place the incoming data from process i (significant only at root)\n IN recvtypes::\n  array of datatypes (of length group size). Entry i specifies the type of data received from process i (array of handles)\n IN root::\n  rank of receiving process (integer)\n IN comm::\n  communicator (handle)\n\nint MPI_Gatherw(void* sendbuf, int sendcount, MPI_Datatype sendtype, void* recvbuf, int recvcounts[], int displs[], MPI_Datatype recvtypes[], int root, MPI_Comm comm)[[br]]\n\nMPI_GATHERW(SENDBUF, SENDCOUNT, SENDTYPE, RECVBUF, RECVCOUNTS, DISPLS, RECVTYPES, ROOT, COMM, IERROR)[[br]]\n<type> SENDBUF(*), RECVBUF(*)[[br]]\nINTEGER SENDCOUNT, SENDTYPE, RECVCOUNTS(*), DISPLS(*), RECVTYPES(*), ROOT, COMM, IERROR[[br]]\n\nMPI_GATHERW extends the functionality of MPI_GATHERV by allowing varying datatype specifications for data received from each process, since datatypes is now an array.[[br]]\nIf comm is an intracommunicator, the outcome is as if each process, including the root\nprocess, sends a message to the root,\n  MPI_Send(sendbuf; sendcount; sendtype; root; ...),\nand the root executes n receives,\n  MPI_Recv(recvbuf + displs[j] * extent(recvtypes[j]); recvcounts[j]; recvtypes[j]; i; ...).\n\nThe data received from process j is placed into recvbuf of the root process beginning at\noffset displs[j] elements (in terms of recvtypes[j]).\n\nThe receive buffer is ignored for all non-root processes.\n\nThe type signature implied by sendcount, sendtype on process i must be equal to the type signature implied by recvcounts[i], recvtypes[i] at the root. This implies that the amount of data sent must be equal to the amount of data received, pairwise between each process and the root.\n\nAll arguments to the function are significant on process root, while on other processes, only arguments sendbuf, sendcount, sendtype, root, and comm are significant. The arguments root and comm must have identical values on all processes.\nThe specification of counts, types, and displacements should not cause any location on the root to be written more than once. Such a call is erroneous.\n\nThe \"in place\" option for intracommunicators is specified by passing MPI_IN_PLACE as the value of sendbuf at the root. In such a case, sendcount and sendtype are ignored, and the contribution of the root to the gathered vector is assumed to be already in the correct place in the receive buffer.\n\nIf comm is an intercommunicator, then the call involves all processes in the intercommunicator, but with one group (group A) defining the root process. All processes in the other group (group B) pass the same value in argument root, which is the rank of the root in group A. The root passes the value MPI_ROOT in root. All other processes in group A pass the value MPI_PROC_NULL in root. Data is gathered from all processes in group B to the root. The send buffer arguments of the processes in group B must be consistent with the receive buffer arguments of the root.\n```\n\n-* MPI_Scatterw **\n\nPage 152, line 21:\n```\n#!div style=\"background: #f7f7f7; border: 1px solid #d7d7d7; margin: 1em 1.75em; padding: .25em; overflow: auto; color:blue; text-decoration:underline\"\nMPI_SCATTERW(sendbuf, sendcounts, displs, sendtypes, recvbuf, recvcount, recvtype, root,comm)[[br]]\n IN sendbuf::\n  address of send buffer (choice, significant only at root)\n IN sendcounts::\n  non-negative integer array (of length group size) specifying the number of elements to send to each processor\n IN displs::\n  integer array (of length group size). Entry i specifies the displacement (relative to sendbuf) from which to take the outgoing data to process i\n IN sendtypes::\n  array of datatypes (of length group size). Entry j specifies the type of data to send to process j (array of handles)\n OUT recvbuf::\n  address of receive buffer (choice)\n IN recvcount::\n  number of elements in receive buffer (non-negative integer)\n IN recvtype::\n  data type of receive buffer elements (handle)\n IN root::\n  rank of sending process (integer)\n IN comm::\n  communicator (handle)\n\nint MPI_Scatterw(void* sendbuf, int sendcounts[], int displs[], MPI_Datatype sendtypes[], void* recvbuf, int recvcount, MPI_Datatype recvtype, int root, MPI_Comm comm)[[br]]\n\nMPI_SCATTERW(SENDBUF, SENDCOUNTS, DISPLS, SENDTYPES, RECVBUF, RECVCOUNT, RECVTYPE, ROOT, COMM, IERROR)[[br]]\n<type> SENDBUF(*), RECVBUF(*)[[br]]\nINTEGER SENDCOUNTS(*), DISPLS(*), SENDTYPES(*), RECVCOUNT, RECVTYPE, ROOT, COMM, IERROR[[br]]\n\nMPI_SCATTERW is the inverse operation to MPI_GATHERW.\n\nMPI_SCATTERW extends the functionality of MPI_SCATTERV by allowing varying datatype specifications for data sent to each process, since datatypes is now an array.\n\nIf comm is an intracommunicator, the outcome is as if the root executed n send operations,\n  MPI_Send(sendbuf + displs[i] * extent(sendtypes[i]); sendcounts[i]; sendtype; i; ...),\nand each process executed a receive,\n  MPI_Recv(recvbuf; recvcount; recvtype; i; ...).\nThe send buffer is ignored for all non-root processes.\n\nThe type signature implied by sendcount[i], sendtypes[i] at the root must be equal to the type signature implied by recvcount, recvtype at process i (however, the type maps may be different). This implies that the amount of data sent must be equal to the amount of data received, pairwise between each process and the root. Distinct type maps between sender and receiver are still allowed.\n\nAll arguments to the function are significant on process root, while on other processes, only arguments recvbuf, recvcount, recvtype, root, and comm are significant. The arguments root and comm must have identical values on all processes.\n\nThe specification of counts, types, and displacements should not cause any location on the root to be read more than once.\n\nThe \"in place\" option for intracommunicators is specified by passing MPI_IN_PLACE as the value of recvbuf at the root. In such a case, recvcount and recvtype are ignored, and root \"sends\" no data to itself. The scattered vector is still assumed to contain n segments,\nwhere n is the group size; the root-th segment, which root should \"send to itself,\" is not moved.\n\nIf comm is an intercommunicator, then the call involves all processes in the intercommunicator, but with one group (group A) defining the root process. All processes in the other group (group B) pass the same value in argument root, which is the rank of the root\nin group A. The root passes the value MPI_ROOT in root. All other processes in group A pass the value MPI_PROC_NULL in root. Data is scattered from the root to all processes in group B. The receive buffer arguments of the processes in group B must be consistent with\nthe send buffer arguments of the root.\n```\n\n-* MPI_Allgatherw **\n\nPage 157, line 22:\n```\n#!div style=\"background: #f7f7f7; border: 1px solid #d7d7d7; margin: 1em 1.75em; padding: .25em; overflow: auto; color:blue; text-decoration:underline\"\nMPI_ALLGATHERW(sendbuf, sendcount, sendtype, recvbuf, recvcounts, displs, recvtypes, comm)[[br]]\n IN sendbuf::\n  starting address of send buffer (choice)\n IN sendcount::\n  number of elements in send buffer (non-negative integer)\n IN sendtype::\n  data type of send buffer elements (handle)\n OUT recvbuf::\n  address of receive buffer (choice)\n IN recvcounts::\n  non-negative integer array (of length group size) containing the number of elements that are received from each process\n IN displs::\n  integer array (of length group size). Entry i specifies the displacement (relative to recvbuf) at which to place the incoming data from process i\n IN recvtypes::\n  array of datatypes (of length group size). Entry i specifies the type of data received from process i (array of handles)\n IN comm::\n  communicator (handle)\n\nint MPI_Allgatherw(void* sendbuf, int sendcount, MPI_Datatype sendtype, void* recvbuf, int recvcounts[], int displs[], MPI_Datatype recvtypes[], MPI_Comm comm)[[br]]\n\nMPI_ALLGATHERW(SENDBUF, SENDCOUNT, SENDTYPE, RECVBUF, RECVCOUNTS, DISPLS,RECVTYPE, COMM, IERROR)[[br]]\n<type> SENDBUF(*), RECVBUF(*)[[br]]\nINTEGER SENDCOUNT, SENDTYPE, RECVCOUNTS(*), DISPLS(*), RECVTYPES(*), COMM, IERROR[[br]]\n\nMPI_ALLGATHERW can be thought of as MPI_GATHERW, but where all processes receive the result, instead of just the root. The block of data sent from the j-th process is received by every process and placed in the j-th block of the buffer recvbuf. These blocks need not all be the same size.\n\nThe type signature associated with sendcount, sendtype, at process j must be equal to the type signature associated with recvcounts[j], recvtypes[j] at any other process.\n\nIf comm is an intracommunicator, the outcome is as if all processes executed calls to\n  MPI_GATHERW(sendbuf,sendcount,sendtype,recvbuf,recvcounts,displs, recvtypes,root,comm),\nfor root = 0 , ..., n-1. The rules for correct usage of MPI_ALLGATHERW are easily\nfound from the corresponding rules for MPI_GATHERW.\n\nThe \"in place\" option for intracommunicators is specified by passing the value MPI_IN_PLACE to the argument sendbuf at all processes. In such a case, sendcount and sendtype are ignored, and the input data of each process is assumed to be in the area where that process would receive its own contribution to the receive buffer.\n\nIf comm is an intercommunicator, then each process of one group (group A) contributes sendcount data items; these data are concatenated and the result is stored at each process in the other group (group B). Conversely the concatenation of the contributions of the\nprocesses in group B is stored at each process in group A. The send buffer arguments in group A must be consistent with the receive buffer arguments in group B, and vice versa.\n```\n\nPage 165, line 38:\n```\n#!div style=\"background: #f7f7f7; border: 1px solid #d7d7d7; margin: 1em 1.75em; padding: .25em; overflow: auto;\"\n[[span(__Size integer: MPI_AINT, MPI_OFFSET, MPI_COUNT__, style=color:blue)]][[br]]\nFortran integer: MPI_INTEGER[[span(~~, MPI_AINT, MPI_OFFSET~~, style=color:red)]],\n```\n\n-* MPI_Igatherw **\n\nPage 192, line 48:\n```\n#!div style=\"background: #f7f7f7; border: 1px solid #d7d7d7; margin: 1em 1.75em; padding: .25em; overflow: auto; color:blue; text-decoration:underline\"\nMPI_IGATHERW(sendbuf, sendcount, sendtype, recvbuf, recvcounts, displs, recvtypes, root, comm, request)\n IN sendbuf::\n  starting address of send buffer (choice)\n IN sendcount::\n  number of elements in send buffer (non-negative integer)\n IN sendtype::\n  data type of send buffer elements (handle)\n OUT recvbuf::\n  address of receive buffer (choice, significant only at root)\n IN recvcounts::\n  non-negative integer array (of length group size) containing the number of elements that are received from each process (significant only at root)\n IN displs::\n  integer array (of length group size). Entry i specifies the displacement relative to recvbuf at which to place the incoming data from process i (significant only at root)\n IN recvtypes::\n  array of datatypes (of length group size). Entry i specifies the type of data received from process i (significant only at\nroot) (array of handles)\n IN root::\n  rank of receiving process (integer)\n IN comm::\n  communicator (handle)\n OUT request::\n  communication request (handle)\n\nint MPI_Igatherw(void* sendbuf, int sendcount, MPI_Datatype sendtype, void* recvbuf, int recvcounts[], int displs[], MPI_Datatype recvtypes[], int root, MPI_Comm comm, MPI_Request *request)[[br]]\n\nMPI_IGATHERW(SENDBUF, SENDCOUNT, SENDTYPE, RECVBUF, RECVCOUNTS, DISPLS, RECVTYPES, ROOT, COMM, REQUEST, IERROR)[[br]]\n<type> SENDBUF(*), RECVBUF(*)[[br]]\nINTEGER SENDCOUNT, SENDTYPE, RECVCOUNTS(*), DISPLS(*), RECVTYPES(*), ROOT, COMM, REQUEST, IERROR[[br]]\n\nThis call starts a nonblocking variant of MPI_GATHERW (see Section 5.5).\n```\n\n-* MPI_Iscatterw **\n\nPage 188, line 48:\n```\n#!div style=\"background: #f7f7f7; border: 1px solid #d7d7d7; margin: 1em 1.75em; padding: .25em; overflow: auto; color:blue; text-decoration:underline\"\nMPI_ISCATTERW(sendbuf, sendcounts, displs, sendtypes, recvbuf, recvcount, recvtype, root, comm, request)\n IN sendbuf::\n  address of send buffer (choice, significant only at root)\n IN sendcounts::\n  non-negative integer array (of length group size) specifying the number of elements to send to each processor\n IN displs::\n  integer array (of length group size). Entry i specifies the displacement (relative to sendbuf) from which to take the outgoing data to process i\n IN sendtypes::\n  array of datatypes (of length group size). Entry j specifies the type of data to send to process j (array of handles)\n OUT recvbuf::\n  address of receive buffer (choice)\n IN recvcount::\n  number of elements in receive buffer (non-negative integer)\n IN recvtype::\n  data type of receive buffer elements (handle)\n IN root::\n  rank of sending process (integer)\n IN comm::\n  communicator (handle)\n OUT request::\n  communication request (handle)\n\nint MPI_Iscatterw(void* sendbuf, int sendcounts[], int displs[], MPI_Datatype sendtypes[], void* recvbuf, int recvcount, MPI_Datatype recvtype, int root, MPI_Comm comm, MPI_Request *request)[[br]]\n\nMPI_ISCATTERW(SENDBUF, SENDCOUNTS, DISPLS, SENDTYPES, RECVBUF, RECVCOUNT, RECVTYPE, ROOT, COMM, REQUEST, IERROR)[[br]]\n<type> SENDBUF(*), RECVBUF(*)[[br]]\nINTEGER SENDCOUNTS(*), DISPLS(*), SENDTYPES(*), RECVCOUNT, RECVTYPE, ROOT, COMM, REQUEST, IERROR[[br]]\n\nThis call starts a nonblocking variant of MPI_SCATTERW (see Section 5.6).\n```\n\n-* MPI_Iallgatherw **\n\nPage 192, line 48:\n```\n#!div style=\"background: #f7f7f7; border: 1px solid #d7d7d7; margin: 1em 1.75em; padding: .25em; overflow: auto; color:blue; text-decoration:underline\"\nMPI_IALLGATHERW(sendbuf, sendcount, sendtype, recvbuf, recvcounts, displs, recvtypes, comm, request)\n IN sendbuf::\n  starting address of send buffer (choice)\n IN sendcount::\n  number of elements in send buffer (non-negative integer)\n IN sendtype::\n  data type of send buffer elements (handle)\n OUT recvbuf::\n  address of receive buffer (choice)\n IN recvcounts::\n  non-negative integer array (of length group size) containing the number of elements that are received from each process\n IN displs::\n  integer array (of length group size). Entry i specifies the displacement (relative to recvbuf) at which to place the incoming data from process i\n IN recvtypes::\n  array of datatypes (of length group size). Entry i specifies the type of data received from process i (array of handles)\n IN comm::\n  communicator (handle)\n OUT request::\n  communication request (handle)\n\nint MPI_Iallgatherw(void* sendbuf, int sendcount, MPI_Datatype sendtype, void* recvbuf, int recvcounts[], int displs[], MPI_Datatype recvtypes[], MPI_Comm comm, MPI_Request* request)[[br]]\n\nMPI_IALLGATHERW(SENDBUF, SENDCOUNT, SENDTYPE, RECVBUF, RECVCOUNTS, DISPLS, RECVTYPES, COMM, REQUEST, IERROR)[[br]]\n<type> SENDBUF(*), RECVBUF(*)[[br]]\nINTEGER SENDCOUNT, SENDTYPE, RECVCOUNTS(*), DISPLS(*), RECVTYPES(*), COMM, REQUEST, IERROR[[br]]\n\nThis call starts a nonblocking variant of MPI_ALLGATHERW (see Section 5.7).\n```\n\n```\n#!comment\n[[span(__ __, style=color:blue)]]\n#!div style=\"background: #f7f7f7; border: 1px solid #d7d7d7; margin: 1em 1.75em; padding: .25em; overflow: auto; color:blue; text-decoration:underline\"\n```\n"},"comment":{"url":"https://api.github.com/repos/mpiforumbot/mpi-forum-historic/issues/comments/234784413","html_url":"https://github.com/mpiforumbot/mpi-forum-historic/issues/269#issuecomment-234784413","issue_url":"https://api.github.com/repos/mpiforumbot/mpi-forum-historic/issues/269","id":234784413,"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-24T15:46:44Z","updated_at":"2016-07-24T15:46:44Z","body":"**Originally by _traff_ on 2011-03-24 12:08:54 -0500**\n\n___\n\nAlthough providing more flexibility and expressivity, the proposal introduces further non-scalable collectives. What about considering including one additional (where appropriate: two) argument list of ranks (in increasing order), with its length - this list could be allowed to be some special, effectively NULL-value MPI_ALLRANKS (to mean that the identity list would have been provided) - of the ranks that actually contribute data, e.g. where count>0? This would free users from providing p-sized arrays when only few n<<p processes have actual data, at the price of an extra list and level of indirection, and thus improve scalability for such use-cases.\n\nBest regards,\n\nJesper\n"}}
{"actor":{"display_login":"mpiforumbot"}}