From: "Rajeev Thakur" To: "Marc Snir" , Subject: RE: clarification text for MPI_Reduce_scatter Date: Fri, 11 Oct 2002 16:33:13 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.21 X-Spam-Level: Sender: owner-mpi-core@XXXXXXXXXXXXX Precedence: bulk Marc, Ah, I missed the sentence you quote, namely, that "the receiving data is stored in the receive buffer defined by recvbuf, recvcounts[i] and datatype" because that appears in the MPI-1 standard as part of the general definition of reduce_scatter, whereas I was looking at the MPI-2 spec. that deals with MPI_IN_PLACE. The text for the other collective functions in the MPI-2 spec. is quite clear what happens in the case of MPI_IN_PLACE, which made me feel that something was missing in the definition of reduce_scatter. I am fine with the intended definition you point out. Perhaps it would be good to have a sentence there to clarify that, because I was confused when I went to implement it. Rajeev > -----Original Message----- > From: Marc Snir [mailto:snir@XXXXXXXXX > Sent: Thursday, October 10, 2002 6:55 PM > To: Rajeev Thakur; mpi-core@XXXXXXXXXXX > Subject: RE: clarification text for MPI_Reduce_scatter > > > What you propose is not a clarification, it is a change. The current > definition says that the receiving data is stored in "the receive buffer > defined by recvbuf, recvcounts[i] and datatype". This means the first > recvcounts[i] entries of the buffer that starts at address recvbuf. > I.e., the output should be stored at the top of the input buffer. > Following the same model as for MPI_SCATTER is not a compelling > argument: for MPI_SCATTER the input data provided by the root is not > modified. Here, the data provided by each process is modified. I do > remember that we discussed this issue and decided on the current > definition. > > I agree that the last sentence does not make sense. > > -----Original Message----- > From: Rajeev Thakur [mailto:thakur@XXXXXXXXXXXX > Sent: Thursday, October 10, 2002 5:59 PM > To: mpi-core@XXXXXXXXXXX > Subject: clarification text for MPI_Reduce_scatter > > > Dear MPI-Core group, > I would like to clarify the definition of > MPI_Reduce_scatter for the case where MPI_IN_PLACE is passed as the > sendbuf argument. The current definition is ambiguous about where in the > recvbuf is the reduce-scattered data placed on each process when > sendbuf=MPI_IN_PLACE. Is it stored at the beginning of the recvbuf or at > the location corresponding to that process's segment in the recvbuf? I > propose that we specify the latter, which follows the same model as > defined for MPI_Scatter. The text for MPI_Scatter clearly says that, in > the case of MPI_IN_PLACE, the segment that the root should send to > itself is not moved. > > Therefore, I propose to replace lines 16-20, pg. 163, MPI-2 Standard, > with the following text: > > ----- > The "in place" option for intracommunicators is specified by passing > MPI_IN_PLACE in the sendbuf argument. In this case, on each process, the > input data is taken from recvbuf. Process i gets the ith segment of the > result, and it is stored at the location corresponding to segment i in > recvbuf. > ----- > > I also note that line 19, pg 163, in the existing text makes no sense, > and I have not included it above. The line says "Note that the area > occupied by the input data may be either longer or shorter than the data > filled by the output data." > > Rajeev > > >