- mpiwg-rma - mailman3.cels.anl.gov

MPI_Lock... for MPI shared memory
by Rolf Rabenseifner 13 Sep '16

13 Sep '16

Hello, my colleague Joseph detected that an MPI implementation is allowed to not allow passive target communication/synchronization (i.e., all forms of MPI_Lock and Unlock) on MPI shared memory windows. Was it intented or is it only a historical review-bug that MPI_WIN_ALLOCATE_SHARED was never added to the list of MPI_ALLOC_MEM (since MPI-2.0), and MPI_WIN_ALLOCATE & MPI_WIN_ATTACH (since MPI-3.0) in the following text. MPI-3.1 Sect. 11.5.3 on page 448 lines 1-12 say "Implementors may restrict the use of RMA communication that is synchronized by lock calls to windows in memory allocated by MPI_ALLOC_MEM (Section 8.2), MPI_WIN_ALLOCATE (Section 11.2.2), or attached with MPI_WIN_ATTACH (Section 11.2.4). Locks can be used portably only in such memory. Rationale. The implementation of passive target communication when Memory is not shared may require an asynchronous software agent. Such an agent can be implemented more easily, and can achieve better performance, if restricted to specially allocated memory. It can be avoided altogether if shared memory is used. It seems natural to impose restrictions that allows one to use shared memory for third party communication in shared memory machines. (End of rationale.)" The rationale not really fits to the current state that MPI_WIN_ALLOCATE_SHARED is missing in the list. It would fit if MPI_WIN_ALLOCATE_SHARED would be added to the list. Best regards Rolf -- Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner(a)hlrs.de High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner Nobelstr. 19, D-70550 Stuttgart, Germany . . . . (Office: Room 1.307)

1 0

MPI Forum Web/Mailing List Migration Update
by Bland, Wesley 06 Sep '16

06 Sep '16

TL;DR - The DNS records for the MPI Forum will be moving from Illinois to Google tonight<http://airmail.calendar/2016-09-06%2019:00:00%20CDT>. This should have user impact, but it’s possible that there will be a short outage depending on your local DNS caches. Other services will be migrating soon. More Details - As part of the overall migration process that I referenced in an email about a month ago, we’re moving the DNS records out of the University of Illinois and up to the cloud (in this case, Google Domains). This should have no impact on your ability to view websites or send emails to these mailing lists, but it’s possible that as the new DNS information propagates to all of the caches around the world, there will be some brief outages. For now, nothing should change. If everything goes well tonight<http://airmail.calendar/2016-09-06%2019:00:00%20CDT>, I hope to start migrating services next week (with the intention of having everything migrated before the 14th<http://airmail.calendar/2016-09-06%2012:00:00%20CDT> so we can make sure everything is stable for EuroMPI and the September MPI Forum meeting. Here is the rough timeline: Sometime this week - Move DNS records from UIUC to Google (hard to predict exactly when this happens) This week - Prepare mailing lists (moving from Indiana to Argonne) and website (website preview available at https://mpi-forum.github.io/) for move. Early next week - Move mailing lists and website to their new hosts September 14th<http://airmail.calendar/2016-09-14%2012:00:00%20CDT> - Migration complete (anything not migrated will be postponed until after the EuroMPI/MPI Forum meeting) If you have questions/concerns about the migration, new website, mailing lists, etc., please let me know. Thanks, Wesley

1 0

Re: [mpiwg-rma] Use of MPI_SHORT_INT, etc with MPI_Accumulate
by Jim Dinan 13 May '16

13 May '16

Some masochist actually wrote a unit test for this, not too long ago. :) http://git.mpich.org/mpich.git/blob/HEAD:/test/mpi/rma/acc-loc.c ~Jim. On Thu, May 12, 2016 at 3:50 PM, Jeff Hammond <jeff.science(a)gmail.com> wrote: > > > On Thu, May 12, 2016 at 1:38 PM, Nathan Hjelm <hjelmn(a)mac.com> wrote: > > > > Ok, so in this case “predefined type” means any type defined by MPI. > That is not clear from the text and it is reasonable to assume that > non-homogenous (and possibly non-contiguous) datatypes are not allowed. > > It is absolutely clear from page 12 of MPI 3.1: > > A predefined datatype is a datatype with a predefined (constant) name > (such as MPI_INT, MPI_FLOAT_INT, or MPI_PACKED) or a datatype constructed > with MPI_TYPE_CREATE_F90_INTEGER, MPI_TYPE_CREATE_F90_REAL, or > MPI_TYPE_CREATE_F90_COMPLEX. The former are named whereas the latter are > unnamed. > > > MPI_MINLOC and MPI_MAXLOC could be be assumed to be only allowed for > MPI_2INT, MPI_2REAL, etc for example. > > Except for MPI_2INT, the homogeneous pair types are for Fortran. If we > added this restriction, we might as well remove MAXLOC/MINLOC from RMA > altogether. > > > Allowing MPI_SHORT_INT, MPI_DOUBLE_INT, etc requires MPI implementations > to write special cases to handle these potentially non-contiguous datatypes. > > MPI RMA permits the use of user-defined non-contiguous datatypes where all > basic components are of the same predefined datatype. The only difference > here is that the atomicity covers the whole pair type. However, since > accumulate atomicity is only assured when the same datatype is used, you > can implement e.g. MPI_LONG_DOUBLE_INT using locking and use atomic > instructions for other types where it is easier. > > > A lot of extra code for what is likely no benefit to end users. > > How is it *a lot* of extra code? Do you not already have a "stupid" RMA > code path for at least some of MPI_C(XX)_LONG_DOUBLE, > MPI_C(XX)_DOUBLE_COMPLEX, MPI_C(XX)_LONG_DOUBLE_COMPLEX and/or MPI_PROD? > Remember that the accumulate atomicity rules are very strict, which permits > a fast (potentially hardware) implementation for some (op,type) pairs and a > slow but functional implementation for others. > > > Does anyone know of a code that makes use of this feature? > > I know users that depend upon the symmetry of MPI_Accumulate and > MPI_Reduce w.r.t. MAXLOC and MINLOC. I don't know what state the code is > in, but PETSc developers have said they want to use this. > > Jeff > > > -Nathan > > > > > > > On May 11, 2016, at 8:35 AM, William Gropp <wgropp(a)illinois.edu> > wrote: > > > > > > Read this as (predefined datatype) or (derived datatype where all > basic components are of the same predefined datatype). > > > > > > MPI_SHORT_INT is a predefined datatype, and so is valid for accumulate. > > > > > > Bill > > > > > > William Gropp > > > Director, Parallel Computing Institute > > > Thomas M. Siebel Chair in Computer Science > > > Chief Scientist, NCSA > > > University of Illinois Urbana-Champaign > > > > > > > > > > > > > > > > > > On May 11, 2016, at 9:02 AM, Nathan Hjelm <hjelmn(a)mac.com> wrote: > > > > > >> I have a user who is trying to use MPI_SHORT_INT as the origin and > target datatype arguments of MPI_Accumulate. My interpretation of the > standard does not allow this type. I am justifying this because of MPI 3-1 > § 11.3.4 pp 425:2-8: > > >> > > >> Each datatype argument must be a predefined datatype or a derived > datatype, where > > >> all basic components are of the same predefined datatype. Both > datatype arguments must > > >> be constructed from the same predefined datatype. > > >> > > >> MPI_SHORT_INT, MPI_LONG_DOUBLE_INT, etc are not in any of the A.1 > tables labeled as "predefined datatypes”. They show up in a separate list > of datatypes for reduction functions. Since these datatypes are not > “predefined datatypes” and are not composite datatypes of the "same > predefined datatype” they are not valid for MPI_Accumulate, > MPI_Get_accumulate, etc. Am I wrong in my interpretation? > > >> > > >> -Nathan > > >> _______________________________________________ > > >> mpiwg-rma mailing list > > >> mpiwg-rma(a)mpi-forum.org > > >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma > > > > > > _______________________________________________ > > > mpiwg-rma mailing list > > > mpiwg-rma(a)mpi-forum.org > > > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma > > > > > > _______________________________________________ > > mpiwg-rma mailing list > > mpiwg-rma(a)mpi-forum.org > > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma > > > > > -- > Jeff Hammond > jeff.science(a)gmail.com > http://jeffhammond.github.io/ > > _______________________________________________ > mpiwg-rma mailing list > mpiwg-rma(a)mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma >

1 0

Fwd: Use of MPI_SHORT_INT, etc with MPI_Accumulate
by Jeff Hammond 12 May '16

12 May '16

---------- Forwarded message ---------- From: Jeff Hammond <jeff.science(a)gmail.com> Date: Thu, May 12, 2016 at 10:50 PM Subject: Re: [mpiwg-rma] Use of MPI_SHORT_INT, etc with MPI_Accumulate To: MPI WG Remote Memory Access working group <mpiwg-rma(a)mpi-forum.org> Cc: MPI WG Remote Memory Access working group <mpiwg-rma(a)lists.mpi-forum.org > On Thu, May 12, 2016 at 1:38 PM, Nathan Hjelm <hjelmn(a)mac.com> wrote: > > Ok, so in this case “predefined type” means any type defined by MPI. That is not clear from the text and it is reasonable to assume that non-homogenous (and possibly non-contiguous) datatypes are not allowed. It is absolutely clear from page 12 of MPI 3.1: A predefined datatype is a datatype with a predefined (constant) name (such as MPI_INT, MPI_FLOAT_INT, or MPI_PACKED) or a datatype constructed with MPI_TYPE_CREATE_F90_INTEGER, MPI_TYPE_CREATE_F90_REAL, or MPI_TYPE_CREATE_F90_COMPLEX. The former are named whereas the latter are unnamed. > MPI_MINLOC and MPI_MAXLOC could be be assumed to be only allowed for MPI_2INT, MPI_2REAL, etc for example. Except for MPI_2INT, the homogeneous pair types are for Fortran. If we added this restriction, we might as well remove MAXLOC/MINLOC from RMA altogether. > Allowing MPI_SHORT_INT, MPI_DOUBLE_INT, etc requires MPI implementations to write special cases to handle these potentially non-contiguous datatypes. MPI RMA permits the use of user-defined non-contiguous datatypes where all basic components are of the same predefined datatype. The only difference here is that the atomicity covers the whole pair type. However, since accumulate atomicity is only assured when the same datatype is used, you can implement e.g. MPI_LONG_DOUBLE_INT using locking and use atomic instructions for other types where it is easier. > A lot of extra code for what is likely no benefit to end users. How is it *a lot* of extra code? Do you not already have a "stupid" RMA code path for at least some of MPI_C(XX)_LONG_DOUBLE, MPI_C(XX)_DOUBLE_COMPLEX, MPI_C(XX)_LONG_DOUBLE_COMPLEX and/or MPI_PROD? Remember that the accumulate atomicity rules are very strict, which permits a fast (potentially hardware) implementation for some (op,type) pairs and a slow but functional implementation for others. > Does anyone know of a code that makes use of this feature? I know users that depend upon the symmetry of MPI_Accumulate and MPI_Reduce w.r.t. MAXLOC and MINLOC. I don't know what state the code is in, but PETSc developers have said they want to use this. Jeff > -Nathan > > > > On May 11, 2016, at 8:35 AM, William Gropp <wgropp(a)illinois.edu> wrote: > > > > Read this as (predefined datatype) or (derived datatype where all basic components are of the same predefined datatype). > > > > MPI_SHORT_INT is a predefined datatype, and so is valid for accumulate. > > > > Bill > > > > William Gropp > > Director, Parallel Computing Institute > > Thomas M. Siebel Chair in Computer Science > > Chief Scientist, NCSA > > University of Illinois Urbana-Champaign > > > > > > > > > > > > On May 11, 2016, at 9:02 AM, Nathan Hjelm <hjelmn(a)mac.com> wrote: > > > >> I have a user who is trying to use MPI_SHORT_INT as the origin and target datatype arguments of MPI_Accumulate. My interpretation of the standard does not allow this type. I am justifying this because of MPI 3-1 § 11.3.4 pp 425:2-8: > >> > >> Each datatype argument must be a predefined datatype or a derived datatype, where > >> all basic components are of the same predefined datatype. Both datatype arguments must > >> be constructed from the same predefined datatype. > >> > >> MPI_SHORT_INT, MPI_LONG_DOUBLE_INT, etc are not in any of the A.1 tables labeled as "predefined datatypes”. They show up in a separate list of datatypes for reduction functions. Since these datatypes are not “predefined datatypes” and are not composite datatypes of the "same predefined datatype” they are not valid for MPI_Accumulate, MPI_Get_accumulate, etc. Am I wrong in my interpretation? > >> > >> -Nathan > >> _______________________________________________ > >> mpiwg-rma mailing list > >> mpiwg-rma(a)mpi-forum.org > >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma > > > > _______________________________________________ > > mpiwg-rma mailing list > > mpiwg-rma(a)mpi-forum.org > > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma > > > _______________________________________________ > mpiwg-rma mailing list > mpiwg-rma(a)mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma -- Jeff Hammond jeff.science(a)gmail.com http://jeffhammond.github.io/ -- Jeff Hammond jeff.science(a)gmail.com http://jeffhammond.github.io/

1 0

Re: [mpiwg-rma] Use of MPI_SHORT_INT, etc with MPI_Accumulate
by Jeff Hammond 12 May '16

12 May '16

On Thu, May 12, 2016 at 1:38 PM, Nathan Hjelm <hjelmn(a)mac.com> wrote: > > Ok, so in this case “predefined type” means any type defined by MPI. That is not clear from the text and it is reasonable to assume that non-homogenous (and possibly non-contiguous) datatypes are not allowed. It is absolutely clear from page 12 of MPI 3.1: A predefined datatype is a datatype with a predefined (constant) name (such as MPI_INT, MPI_FLOAT_INT, or MPI_PACKED) or a datatype constructed with MPI_TYPE_CREATE_F90_INTEGER, MPI_TYPE_CREATE_F90_REAL, or MPI_TYPE_CREATE_F90_COMPLEX. The former are named whereas the latter are unnamed. > MPI_MINLOC and MPI_MAXLOC could be be assumed to be only allowed for MPI_2INT, MPI_2REAL, etc for example. Except for MPI_2INT, the homogeneous pair types are for Fortran. If we added this restriction, we might as well remove MAXLOC/MINLOC from RMA altogether. > Allowing MPI_SHORT_INT, MPI_DOUBLE_INT, etc requires MPI implementations to write special cases to handle these potentially non-contiguous datatypes. MPI RMA permits the use of user-defined non-contiguous datatypes where all basic components are of the same predefined datatype. The only difference here is that the atomicity covers the whole pair type. However, since accumulate atomicity is only assured when the same datatype is used, you can implement e.g. MPI_LONG_DOUBLE_INT using locking and use atomic instructions for other types where it is easier. > A lot of extra code for what is likely no benefit to end users. How is it *a lot* of extra code? Do you not already have a "stupid" RMA code path for at least some of MPI_C(XX)_LONG_DOUBLE, MPI_C(XX)_DOUBLE_COMPLEX, MPI_C(XX)_LONG_DOUBLE_COMPLEX and/or MPI_PROD? Remember that the accumulate atomicity rules are very strict, which permits a fast (potentially hardware) implementation for some (op,type) pairs and a slow but functional implementation for others. > Does anyone know of a code that makes use of this feature? I know users that depend upon the symmetry of MPI_Accumulate and MPI_Reduce w.r.t. MAXLOC and MINLOC. I don't know what state the code is in, but PETSc developers have said they want to use this. Jeff > -Nathan > > > > On May 11, 2016, at 8:35 AM, William Gropp <wgropp(a)illinois.edu> wrote: > > > > Read this as (predefined datatype) or (derived datatype where all basic components are of the same predefined datatype). > > > > MPI_SHORT_INT is a predefined datatype, and so is valid for accumulate. > > > > Bill > > > > William Gropp > > Director, Parallel Computing Institute > > Thomas M. Siebel Chair in Computer Science > > Chief Scientist, NCSA > > University of Illinois Urbana-Champaign > > > > > > > > > > > > On May 11, 2016, at 9:02 AM, Nathan Hjelm <hjelmn(a)mac.com> wrote: > > > >> I have a user who is trying to use MPI_SHORT_INT as the origin and target datatype arguments of MPI_Accumulate. My interpretation of the standard does not allow this type. I am justifying this because of MPI 3-1 § 11.3.4 pp 425:2-8: > >> > >> Each datatype argument must be a predefined datatype or a derived datatype, where > >> all basic components are of the same predefined datatype. Both datatype arguments must > >> be constructed from the same predefined datatype. > >> > >> MPI_SHORT_INT, MPI_LONG_DOUBLE_INT, etc are not in any of the A.1 tables labeled as "predefined datatypes”. They show up in a separate list of datatypes for reduction functions. Since these datatypes are not “predefined datatypes” and are not composite datatypes of the "same predefined datatype” they are not valid for MPI_Accumulate, MPI_Get_accumulate, etc. Am I wrong in my interpretation? > >> > >> -Nathan > >> _______________________________________________ > >> mpiwg-rma mailing list > >> mpiwg-rma(a)mpi-forum.org > >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma > > > > _______________________________________________ > > mpiwg-rma mailing list > > mpiwg-rma(a)mpi-forum.org > > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma > > > _______________________________________________ > mpiwg-rma mailing list > mpiwg-rma(a)mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma -- Jeff Hammond jeff.science(a)gmail.com http://jeffhammond.github.io/

1 0

Re: [mpiwg-rma] Use of MPI_SHORT_INT, etc with MPI_Accumulate
by Nathan Hjelm 12 May '16

12 May '16

Ok, so in this case “predefined type” means any type defined by MPI. That is not clear from the text and it is reasonable to assume that non-homogenous (and possibly non-contiguous) datatypes are not allowed. MPI_MINLOC and MPI_MAXLOC could be be assumed to be only allowed for MPI_2INT, MPI_2REAL, etc for example. Allowing MPI_SHORT_INT, MPI_DOUBLE_INT, etc requires MPI implementations to write special cases to handle these potentially non-contiguous datatypes. A lot of extra code for what is likely no benefit to end users. Does anyone know of a code that makes use of this feature? -Nathan > On May 11, 2016, at 8:35 AM, William Gropp <wgropp(a)illinois.edu> wrote: > > Read this as (predefined datatype) or (derived datatype where all basic components are of the same predefined datatype). > > MPI_SHORT_INT is a predefined datatype, and so is valid for accumulate. > > Bill > > William Gropp > Director, Parallel Computing Institute > Thomas M. Siebel Chair in Computer Science > Chief Scientist, NCSA > University of Illinois Urbana-Champaign > > > > > > On May 11, 2016, at 9:02 AM, Nathan Hjelm <hjelmn(a)mac.com> wrote: > >> I have a user who is trying to use MPI_SHORT_INT as the origin and target datatype arguments of MPI_Accumulate. My interpretation of the standard does not allow this type. I am justifying this because of MPI 3-1 § 11.3.4 pp 425:2-8: >> >> Each datatype argument must be a predefined datatype or a derived datatype, where >> all basic components are of the same predefined datatype. Both datatype arguments must >> be constructed from the same predefined datatype. >> >> MPI_SHORT_INT, MPI_LONG_DOUBLE_INT, etc are not in any of the A.1 tables labeled as "predefined datatypes”. They show up in a separate list of datatypes for reduction functions. Since these datatypes are not “predefined datatypes” and are not composite datatypes of the "same predefined datatype” they are not valid for MPI_Accumulate, MPI_Get_accumulate, etc. Am I wrong in my interpretation? >> >> -Nathan >> _______________________________________________ >> mpiwg-rma mailing list >> mpiwg-rma(a)mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma > > _______________________________________________ > mpiwg-rma mailing list > mpiwg-rma(a)mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma

1 0

Fwd: Use of MPI_SHORT_INT, etc with MPI_Accumulate
by Jeff Hammond 11 May '16

11 May '16

> From: Jeff Hammond <jeff.science(a)gmail.com> > Date: May 11, 2016 at 5:34:12 PM GMT+3 > To: MPI WG Remote Memory Access working group <mpiwg-rma(a)mpi-forum.org> > Cc: mpiwg-rma(a)lists.mpi-forum.org > Subject: Re: [mpiwg-rma] Use of MPI_SHORT_INT, etc with MPI_Accumulate > > How else can you call with eg op=MAXLOC? > > Sent from my iPhone > >> On May 11, 2016, at 5:02 PM, Nathan Hjelm <hjelmn(a)mac.com> wrote: >> >> I have a user who is trying to use MPI_SHORT_INT as the origin and target datatype arguments of MPI_Accumulate. My interpretation of the standard does not allow this type. I am justifying this because of MPI 3-1 § 11.3.4 pp 425:2-8: >> >> Each datatype argument must be a predefined datatype or a derived datatype, where >> all basic components are of the same predefined datatype. Both datatype arguments must >> be constructed from the same predefined datatype. >> >> MPI_SHORT_INT, MPI_LONG_DOUBLE_INT, etc are not in any of the A.1 tables labeled as "predefined datatypes”. They show up in a separate list of datatypes for reduction functions. Since these datatypes are not “predefined datatypes” and are not composite datatypes of the "same predefined datatype” they are not valid for MPI_Accumulate, MPI_Get_accumulate, etc. Am I wrong in my interpretation? >> >> -Nathan >> _______________________________________________ >> mpiwg-rma mailing list >> mpiwg-rma(a)mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma

1 0

Re: [mpiwg-rma] Use of MPI_SHORT_INT, etc with MPI_Accumulate
by William Gropp 11 May '16

11 May '16

Read this as (predefined datatype) or (derived datatype where all basic components are of the same predefined datatype). MPI_SHORT_INT is a predefined datatype, and so is valid for accumulate. Bill William Gropp Director, Parallel Computing Institute Thomas M. Siebel Chair in Computer Science Chief Scientist, NCSA University of Illinois Urbana-Champaign On May 11, 2016, at 9:02 AM, Nathan Hjelm <hjelmn(a)mac.com> wrote: > I have a user who is trying to use MPI_SHORT_INT as the origin and target datatype arguments of MPI_Accumulate. My interpretation of the standard does not allow this type. I am justifying this because of MPI 3-1 § 11.3.4 pp 425:2-8: > > Each datatype argument must be a predefined datatype or a derived datatype, where > all basic components are of the same predefined datatype. Both datatype arguments must > be constructed from the same predefined datatype. > > MPI_SHORT_INT, MPI_LONG_DOUBLE_INT, etc are not in any of the A.1 tables labeled as "predefined datatypes”. They show up in a separate list of datatypes for reduction functions. Since these datatypes are not “predefined datatypes” and are not composite datatypes of the "same predefined datatype” they are not valid for MPI_Accumulate, MPI_Get_accumulate, etc. Am I wrong in my interpretation? > > -Nathan > _______________________________________________ > mpiwg-rma mailing list > mpiwg-rma(a)mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma

1 0

Re: [mpiwg-rma] Use of MPI_SHORT_INT, etc with MPI_Accumulate
by Jeff Hammond 11 May '16

11 May '16

How else can you call with eg op=MAXLOC? Sent from my iPhone > On May 11, 2016, at 5:02 PM, Nathan Hjelm <hjelmn(a)mac.com> wrote: > > I have a user who is trying to use MPI_SHORT_INT as the origin and target datatype arguments of MPI_Accumulate. My interpretation of the standard does not allow this type. I am justifying this because of MPI 3-1 § 11.3.4 pp 425:2-8: > > Each datatype argument must be a predefined datatype or a derived datatype, where > all basic components are of the same predefined datatype. Both datatype arguments must > be constructed from the same predefined datatype. > > MPI_SHORT_INT, MPI_LONG_DOUBLE_INT, etc are not in any of the A.1 tables labeled as "predefined datatypes”. They show up in a separate list of datatypes for reduction functions. Since these datatypes are not “predefined datatypes” and are not composite datatypes of the "same predefined datatype” they are not valid for MPI_Accumulate, MPI_Get_accumulate, etc. Am I wrong in my interpretation? > > -Nathan > _______________________________________________ > mpiwg-rma mailing list > mpiwg-rma(a)mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma

1 0

Use of MPI_SHORT_INT, etc with MPI_Accumulate
by Nathan Hjelm 11 May '16

11 May '16

I have a user who is trying to use MPI_SHORT_INT as the origin and target datatype arguments of MPI_Accumulate. My interpretation of the standard does not allow this type. I am justifying this because of MPI 3-1 § 11.3.4 pp 425:2-8: Each datatype argument must be a predefined datatype or a derived datatype, where all basic components are of the same predefined datatype. Both datatype arguments must be constructed from the same predefined datatype. MPI_SHORT_INT, MPI_LONG_DOUBLE_INT, etc are not in any of the A.1 tables labeled as "predefined datatypes”. They show up in a separate list of datatypes for reduction functions. Since these datatypes are not “predefined datatypes” and are not composite datatypes of the "same predefined datatype” they are not valid for MPI_Accumulate, MPI_Get_accumulate, etc. Am I wrong in my interpretation? -Nathan

1 0