As JH mentioned the examples are not normative. The type MPI_DATATYPE_NULL is not part of the MPI predefined datatypes, and as such is not expected to be a commited datatype, thus improper for communications (even when the count is 0).
George. On Tue, Jan 12, 2016 at 8:25 PM, Jim Edwards <jedwa...@ucar.edu> wrote: > Hi Gilles, > > I think that your conversation with Jeff pretty much covered it but > your understanding of my original problem is correct. > Thanks for the prompt response and the PR. > > On Tue, Jan 12, 2016 at 5:59 PM, Jeff Hammond <jeff.scie...@gmail.com> > wrote: > >> Consider MPI_Get_accumulate with op=MPI_NO_OP, which is used to achieve >> atomic Get. Obviously, one does not want to allocate and describe a source >> buffer that will not be touched by this. This is a case like MPI_Alltoallw >> where (NULL,0,MPI_DATATYPE_NULL) needs to work at participating processes. >> >> Best, >> >> Jeff >> >> On Tue, Jan 12, 2016 at 4:46 PM, Gilles Gouaillardet < >> gilles.gouaillar...@gmail.com> wrote: >> >>> Thanks Jeff, >>> >>> i could not find anything in the standard that says this is an invalid >>> usage ... so i can only agree this is a bug. >>> >>> fwiw, example 4.23 is working fine with OpenMPI >>> but that is a different case : with MPI_Gather and friends, recv stuff >>> is irrelevant on non root task. >>> in the case of MPI_Alltoallw and friends, no parameter is ignored. >>> >>> fortunatly, the fix is pretty trivial, so i will make a PR from now >>> >>> Cheers, >>> >>> Gilles >>> >>> >>> On Wed, Jan 13, 2016 at 9:37 AM, Jeff Hammond <jeff.scie...@gmail.com> >>> wrote: >>> > Example 4.23 of MPI 3.1 (it is hardly a new example, but may have a >>> > different number in older versions) demonstrates the use of >>> > (buffer=NULL,count=0,type=MPI_DATATYPE_NULL). While examples in the >>> MPI >>> > standard are not normative text, this is certainly a valid use of >>> MPI. I >>> > can't find a citation where it says explicitly that this is correct, >>> but it >>> > follows logically from other text. >>> > >>> > The MPICH macro MPIR_ERRTEST_USERBUFFER that is used through the code >>> to >>> > test for valid user buffers begins with "if (count > 0..." and thus >>> does >>> > concern itself with the type or buffer pointer when count=0. >>> Furthermore, >>> > this macro is redundantly protected with a count>0 check when used in >>> > MPI_Alltoallw (and other collectives). >>> > >>> > Best, >>> > >>> > Jeff >>> > >>> > >>> > On Tue, Jan 12, 2016 at 4:18 PM, Gilles Gouaillardet < >>> gil...@rist.or.jp> >>> > wrote: >>> >> >>> >> Hi Jim, >>> >> >>> >> can you please confirm my understanding is correct : >>> >> >>> >> - OpenMPI does *not* accept MPI_DATATYPE_NULL as an input of >>> MPI_Alltoallw >>> >> - mpich does accept MPI_DATATYPE_NULL as an input of MPI_Alltoallw >>> *if* >>> >> the corresponding count *is* zero >>> >> - mpich does *not* accept MPI_DATATYPE_NULL as an input of >>> MPI_Alltoallw >>> >> *if* the corresponding count is *not* zero >>> >> >>> >> So you are considering as a bug the fact OpenMPI does not accept >>> >> MPI_DATATYPE_NULL *with* a zero count. >>> >> >>> >> am i correct ? >>> >> >>> >> Cheers, >>> >> >>> >> Gilles >>> >> >>> >> >>> >> On 1/13/2016 8:27 AM, Jim Edwards wrote: >>> >> >>> >> Hi, >>> >> >>> >> I am using OpenMPI-1.8.3 built with gcc 4.8.3 >>> >> and I am using an MPI_Alltoallw call to perform >>> >> an all to some (or some to all) communication. >>> >> >>> >> In the case in which my task is not sending (or receiving) any data I >>> set >>> >> the >>> >> datatype for that send or recv buffer to MPI_DATATYPE_NULL - this >>> >> works fine with other mpi libraries but fails in openmpi. If I set >>> >> the datatype to something else say MPI_CHAR - it works fine. I think >>> >> that this is a bug in open-mpi - would you agree? >>> >> >>> >> >>> >> >>> >> >>> >> -- >>> >> Jim Edwards >>> >> >>> >> CESM Software Engineer >>> >> National Center for Atmospheric Research >>> >> Boulder, CO >>> >> >>> >> >>> >> _______________________________________________ >>> >> users mailing list >>> >> us...@open-mpi.org >>> >> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/users >>> >> Link to this post: >>> >> http://www.open-mpi.org/community/lists/users/2016/01/28249.php >>> >> >>> >> >>> >> >>> >> _______________________________________________ >>> >> users mailing list >>> >> us...@open-mpi.org >>> >> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/users >>> >> Link to this post: >>> >> http://www.open-mpi.org/community/lists/users/2016/01/28250.php >>> > >>> > >>> > >>> > >>> > -- >>> > Jeff Hammond >>> > jeff.scie...@gmail.com >>> > http://jeffhammond.github.io/ >>> > >>> > _______________________________________________ >>> > users mailing list >>> > us...@open-mpi.org >>> > Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/users >>> > Link to this post: >>> > http://www.open-mpi.org/community/lists/users/2016/01/28251.php >>> _______________________________________________ >>> users mailing list >>> us...@open-mpi.org >>> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/users >>> Link to this post: >>> http://www.open-mpi.org/community/lists/users/2016/01/28252.php >>> >> >> >> >> -- >> Jeff Hammond >> jeff.scie...@gmail.com >> http://jeffhammond.github.io/ >> >> _______________________________________________ >> users mailing list >> us...@open-mpi.org >> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/users >> Link to this post: >> http://www.open-mpi.org/community/lists/users/2016/01/28253.php >> > > > > -- > Jim Edwards > > CESM Software Engineer > National Center for Atmospheric Research > Boulder, CO > > _______________________________________________ > users mailing list > us...@open-mpi.org > Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/users > Link to this post: > http://www.open-mpi.org/community/lists/users/2016/01/28254.php >
