March 2014 - mpiwg-fortran - mailman3.cels.anl.gov

Assumed-size array in MPI3
by Junchao Zhang 10 Mar '14

10 Mar '14

Hello, I read a Fortran textbook, which says "Assumed-size dummy arrays are a holdover from earlier versions of Fortran. They should never be used in any new programs". But I find MPI3 has interfaces like MPI_Alltoallv(sendbuf, sendcounts, sdispls, sendtype, recvbuf, recvcounts, rdispls, recvtype, comm, ierror) ... INTEGER, INTENT(IN) :: sendcounts(*), sdispls(*), recvcounts(*), rdispls(*) ... I was wondering why MPI3 still uses it. Thanks. --Junchao Zhang

1 0

Re: [MPIWG Fortran] Reading of #408: deprecating mpif.h/freezing mpi module
by Bill Long 05 Mar '14

05 Mar '14

Hi Jeff, Thanks for the update. I am encouraged about the vote on mpif.h - that is good news. The vote on the mpi module is less fortunate, but not unexpected. Is there sentiment for a Plan B? From a broad view, there are three areas of difference between the modules mpi and mpi_f08: 1) INTEGER handles (MPI) versus derived type handles (mpi_f08). 2) Choice buffer declarations that are TYPE(*),DIMENSION(*) [aka void *] (mpi) versus TYPE(*),DIMENSION(..) [aka C descriptor] and use of ASYNCHRONOUS attribute (mpi_f08). 3) No OPTIONAL arguments (mpi) versus allowing OPTIONAL arguments (mpi_f08). I believe our current Plan B is to “upgrade” the mpi module by keeping (1) as is but migrating (2) and (3) to the mpi_f08 conventions. Advantages: a) Solves the problems that (2) is intended to solve b) The convenience of (3). c) No required change to the user sources. (Particularly, the handle declarations). d) Potentially better performance (by avoiding the possible copy-in/copy-out of choice buffers at call sites). Disadvantages: a) Requires TS compiler support, because of (2). If that is even too much for the voters, then a watered down Plan C could involve keeping the mpi conventions for (1) and (2), but at least allowing the OPTIONAL arguments (3). Advantages: a) The convenience of (3) b) Does not require any new compiler technology. OPTIONAL arguments have been around for 20 years. c) No required change to user sources. Disadvantages: a) No access to the feature improvements from (2) b) Reduces momentum towards removing the mpi module, requiring longer period of dual maintenance by vendors. Personally, I prefer Plan B, but if that does not have enough support, Plan C is better than nothing. At least Plan C will reduce the number of times support people have to explain why the call to MPI_Init failed because the user forgot the error argument. Cheers, Bill On Mar 4, 2014, at 7:37 PM, Jeff Squyres (jsquyres) <jsquyres(a)cisco.com> wrote: > Due to scheduling, I ended up reading #408 today (instead of tomorrow): > > Please see the results: > > https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/408#comment:5 > > -- > Jeff Squyres > jsquyres(a)cisco.com > For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/ > > _______________________________________________ > mpiwg-fortran mailing list > mpiwg-fortran(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran Bill Long longb(a)cray.com Fortran Technical Suport & voice: 651-605-9024 Bioinformatics Software Development fax: 651-605-9142 Cray Inc./ Cray Plaza, Suite 210/ 380 Jackson St./ St. Paul, MN 55101

1 0

Reading of #408: deprecating mpif.h/freezing mpi module
by Jeff Squyres (jsquyres) 04 Mar '14

04 Mar '14

Due to scheduling, I ended up reading #408 today (instead of tomorrow): Please see the results: https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/408#comment:5 -- Jeff Squyres jsquyres(a)cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/

1 0

Re: [MPIWG Fortran] Questions on the F08 subarray format
by Balaji, Pavan 02 Mar '14

02 Mar '14

On Mar 2, 2014, at 7:42 PM, Junchao Zhang <jczhang(a)mcs.anl.gov> wrote: > Here is my understanding (inlined) > > WIN_CREATE was just an example. There are several functions that have a void*, but don’t have a datatype associated with them. For example, COMM_CREATE_KEYVAL, WIN_ATTACH (which doesn’t have the wording you are pointing out). > In WIN_ATTACH / DETATH, if <base> is non-contiguous, we can split it into multiple contiguous ATTACH / DETACH. I’m not asking what the implementation can do. For example, an implementation can provide a new internal function that deals with noncontiguous buffers called MPIR_WIN_ATTACH_NONCONTIG. I’m asking what the standard intended. Besides, that doesn’t make sense for the other example I gave above (CREATE_KEYVAL) and is not a generic solution for all routines that take a void* argument. FWIW, for your approach to work, the user will need to use the same attributes for both ATTACH and DETACH. Just giving a buffer address to detach is no longer sufficient since it loses information on the associated noncontiguous buffers. > As per my remaining questions, I don’t think those are answered. See the example about MPI_GATHER below, for instance. > > For MPI_GATHER, it is possible for the receive buffer be contiguous for some processes and noncontiguous for others. A choice buffer defines a virtually contiguous memory (may actually contiguous or not), the datatype defines type map on the memory, and the count defines the number of elements of this datatype. With these, users can do what they want. For example, one can gather data of MPI_2INT from processes into a row of a matrix in Fortran. Is that the WG’s interpretation or are you guessing here? If that was the intention of the Fortran WG, I’d strongly object to it. That’s a major change in the semantics of MPI_REDUCE if my receives can be contiguous for some processes and noncontiguous for others. — Pavan

1 0

Re: [MPIWG Fortran] Questions on the F08 subarray format
by Junchao Zhang 02 Mar '14

02 Mar '14

Here is my understanding (inlined) > > WIN_CREATE was just an example. There are several functions that have a > void*, but don't have a datatype associated with them. For example, > COMM_CREATE_KEYVAL, WIN_ATTACH (which doesn't have the wording you are > pointing out). > In WIN_ATTACH / DETATH, if <base> is non-contiguous, we can split it into multiple contiguous ATTACH / DETACH. > Furthermore, the problem with MPI_PUT doesn't go away. You can create a > window with noncontiguous memory regions using MPI_WIN_CREATE_DYNAMIC. But > my point is different -- the "offset" given to MPI_PUT can actually be a > void* that is just typecast to MPI_AINT (e.g., in WIN_CREATE_DYNAMIC, > offsets are against MPI_BOTTOM). So my question is: isn't this losing > information? The answer might be a simple, "yes, and we don't care", but I > want the Fortran WG to confirm that. > In MPI_PUT, <target_disp> is of INTEGER(KIND=MPI_ADDRESS_KIND), in other words, not a choice buffer. It is not an issue of the Standard. > As per my remaining questions, I don't think those are answered. See the > example about MPI_GATHER below, for instance. > For MPI_GATHER, it is possible for the receive buffer be contiguous for some processes and noncontiguous for others. A choice buffer defines a virtually contiguous memory (may actually contiguous or not), the datatype defines type map on the memory, and the count defines the number of elements of this datatype. With these, users can do what they want. For example, one can gather data of MPI_2INT from processes into a row of a matrix in Fortran. > Thanks, > > -- Pavan > > On Mar 2, 2014, at 4:18 PM, Rolf Rabenseifner <rabenseifner(a)hlrs.de> > wrote: > > > Pavan, > > > > I'm currently on travel for teaching a 3 day course, > > but a short answer: > > > > All blocking routines and all nonblocking routines with a blocking > > counter-part have already in MPI-2.2 a well-defined behavior for > > strided-subarray-buffers. > > Exactly the same behavior is expected with the new syntax. > > This behavior can be implemented exactly the same way > > as the compiler did in MPI-2.0 with blocking routines: > > - copying the strided subarray into a contiguous scratch buffer > > - calling the C routine with this contiguous scratch buffer > > - and > > -- in the case of blocking routines: dealloc the sctatch buffer > > -- in the case of nonblocking routines: mark for dealloc > > when the operation is completed, i.e., in the Wait or Test. > > > > If you want to do some optimizations, then thexy must behave as if > > it is coded in this described way. > > > > The only intersting cases seem to be: > > - MPI_Win_create - I would forbid strided windows, > > - and the remote part of MPI_Put/..., but this is solved > > if strided windows are not allowed. > > > > For MPI_Win_create, the problem is already solved as I wished above: > > MPI-3.0 p405:24-26: > > "In Fortran, one can pass the first element of a memory region > > or a whole array, which must be 'simply contiguous' (for > > 'simply contiguous', see also Section 17.1.12 on page 626)." > > > > For 'simply contiguous', see p628:14-27. > > > > Therefore, I expect that your questions are fully answered > > and there is no need for aditional clarifications. > > > > I may have missed some additional aspects in your questions? > > > > Bestregards > > Rolf > > > > ----- Original Message ----- > >> From: "Pavan Balaji" <balaji(a)anl.gov> > >> To: "MPI-WG Fortran working group" <mpiwg-fortran(a)lists.mpi-forum.org> > >> Sent: Sunday, March 2, 2014 10:47:14 PM > >> Subject: Re: [MPIWG Fortran] Questions on the F08 subarray format > >> > >> > >> Some more questions: > >> > >> 4. What happens when the void* corresponds to multiple counts of a > >> single datatype from different processes (e.g., GATHER or ALLTOALL)? > >> In the case of GATHER, suppose I'm gathering 2 INTEGERS from each > >> processes, can my receive buffer now be contiguous for some > >> processes and noncontiguous for others? > >> > >> 5. For some functions, the standard has wording that MPI_DATATYPE for > >> a particular function can only have predefined datatype. What > >> happens when the user uses a predefined datatype, but describes a > >> subarray in the void* argument? > >> > >> I'm assuming these are just holes that were not intended, but the > >> standard doesn't seem to clearly state this. > >> > >> It'll be great if someone can clarify the intention of the working > >> group for each of the five cases I mentioned. Rolf already > >> mentioned that the intention was to not allow noncontiguous buffers > >> for WIN_CREATE. What about other functions that take void*? E.g., > >> WIN_ATTACH/DETACH or other non-RMA functions that take void* but > >> don't provide a datatype? > >> > >> Thanks, > >> > >> -- Pavan > >> > >> On Mar 1, 2014, at 5:29 PM, Rolf Rabenseifner <rabenseifner(a)hlrs.de> > >> wrote: > >> > >>> I expect (after midnight) that clarifications are needed. > >>> On 1. MPI_WIN_CREATE: the goal should be contigues window, > >>> i.e., no strided subarrays. > >>> > >>> Rolf > >>> > >>> ----- Original Message ----- > >>>> From: "Pavan Balaji" <balaji(a)anl.gov> > >>>> To: mpiwg-fortran(a)lists.mpi-forum.org > >>>> Sent: Saturday, March 1, 2014 11:29:59 PM > >>>> Subject: [MPIWG Fortran] Questions on the F08 subarray format > >>>> > >>>> Folks, > >>>> > >>>> I had a few questions on the MPI-3 F08 bindings, which I couldn't > >>>> find answers to in the standard. Can someone point me to the > >>>> place > >>>> where these are defined? > >>>> > >>>> 1. How does the subarray format work for functions that have a > >>>> void* > >>>> argument, but no datatype to describe them (e.g., MPI_WIN_CREATE)? > >>>> In this case, What C function will MPI_WIN_CREATE_F08TS call? Do > >>>> we need to create an separate internal MPIR_WIN_CREATE_NEW > >>>> function > >>>> in our implementation that takes a datatype argument? Does this > >>>> mean that now MPI_WIN_CREATE can allow for noncontiguous buffers > >>>> on > >>>> each process? > >>>> > >>>> 2. How does the subarray format work for functions that have a > >>>> datatype argument, but no void* corresponding to that datatype? > >>>> For > >>>> example, the target buffer in MPI_PUT is described using an > >>>> MPI_AINT > >>>> (offset), rather than a void*. > >>>> > >>>> 3. How does the subarray format work for functions that have two > >>>> void* arguments corresponding to the same datatype (e.g., > >>>> MPI_REDUCE)? > >>>> > >>>> Thanks, > >>>> > >>>> -- Pavan > >>>> > >>>> _______________________________________________ > >>>> mpiwg-fortran mailing list > >>>> mpiwg-fortran(a)lists.mpi-forum.org > >>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran > >>>> > >>> > >>> -- > >>> 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) > >>> _______________________________________________ > >>> mpiwg-fortran mailing list > >>> mpiwg-fortran(a)lists.mpi-forum.org > >>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran > >> > >> _______________________________________________ > >> mpiwg-fortran mailing list > >> mpiwg-fortran(a)lists.mpi-forum.org > >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran > >> > > > > -- > > 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) > > _______________________________________________ > > mpiwg-fortran mailing list > > mpiwg-fortran(a)lists.mpi-forum.org > > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran > > _______________________________________________ > mpiwg-fortran mailing list > mpiwg-fortran(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran >

1 0

Re: [MPIWG Fortran] Questions on the F08 subarray format
by Balaji, Pavan 02 Mar '14

02 Mar '14

Hi Rolf, WIN_CREATE was just an example. There are several functions that have a void*, but don’t have a datatype associated with them. For example, COMM_CREATE_KEYVAL, WIN_ATTACH (which doesn’t have the wording you are pointing out). Furthermore, the problem with MPI_PUT doesn’t go away. You can create a window with noncontiguous memory regions using MPI_WIN_CREATE_DYNAMIC. But my point is different — the “offset” given to MPI_PUT can actually be a void* that is just typecast to MPI_AINT (e.g., in WIN_CREATE_DYNAMIC, offsets are against MPI_BOTTOM). So my question is: isn’t this losing information? The answer might be a simple, “yes, and we don’t care”, but I want the Fortran WG to confirm that. As per my remaining questions, I don’t think those are answered. See the example about MPI_GATHER below, for instance. Thanks, — Pavan On Mar 2, 2014, at 4:18 PM, Rolf Rabenseifner <rabenseifner(a)hlrs.de> wrote: > Pavan, > > I'm currently on travel for teaching a 3 day course, > but a short answer: > > All blocking routines and all nonblocking routines with a blocking > counter-part have already in MPI-2.2 a well-defined behavior for > strided-subarray-buffers. > Exactly the same behavior is expected with the new syntax. > This behavior can be implemented exactly the same way > as the compiler did in MPI-2.0 with blocking routines: > - copying the strided subarray into a contiguous scratch buffer > - calling the C routine with this contiguous scratch buffer > - and > -- in the case of blocking routines: dealloc the sctatch buffer > -- in the case of nonblocking routines: mark for dealloc > when the operation is completed, i.e., in the Wait or Test. > > If you want to do some optimizations, then thexy must behave as if > it is coded in this described way. > > The only intersting cases seem to be: > - MPI_Win_create - I would forbid strided windows, > - and the remote part of MPI_Put/..., but this is solved > if strided windows are not allowed. > > For MPI_Win_create, the problem is already solved as I wished above: > MPI-3.0 p405:24-26: > "In Fortran, one can pass the first element of a memory region > or a whole array, which must be 'simply contiguous' (for > 'simply contiguous', see also Section 17.1.12 on page 626)." > > For 'simply contiguous', see p628:14-27. > > Therefore, I expect that your questions are fully answered > and there is no need for aditional clarifications. > > I may have missed some additional aspects in your questions? > > Bestregards > Rolf > > ----- Original Message ----- >> From: "Pavan Balaji" <balaji(a)anl.gov> >> To: "MPI-WG Fortran working group" <mpiwg-fortran(a)lists.mpi-forum.org> >> Sent: Sunday, March 2, 2014 10:47:14 PM >> Subject: Re: [MPIWG Fortran] Questions on the F08 subarray format >> >> >> Some more questions: >> >> 4. What happens when the void* corresponds to multiple counts of a >> single datatype from different processes (e.g., GATHER or ALLTOALL)? >> In the case of GATHER, suppose I’m gathering 2 INTEGERS from each >> processes, can my receive buffer now be contiguous for some >> processes and noncontiguous for others? >> >> 5. For some functions, the standard has wording that MPI_DATATYPE for >> a particular function can only have predefined datatype. What >> happens when the user uses a predefined datatype, but describes a >> subarray in the void* argument? >> >> I’m assuming these are just holes that were not intended, but the >> standard doesn’t seem to clearly state this. >> >> It’ll be great if someone can clarify the intention of the working >> group for each of the five cases I mentioned. Rolf already >> mentioned that the intention was to not allow noncontiguous buffers >> for WIN_CREATE. What about other functions that take void*? E.g., >> WIN_ATTACH/DETACH or other non-RMA functions that take void* but >> don’t provide a datatype? >> >> Thanks, >> >> — Pavan >> >> On Mar 1, 2014, at 5:29 PM, Rolf Rabenseifner <rabenseifner(a)hlrs.de> >> wrote: >> >>> I expect (after midnight) that clarifications are needed. >>> On 1. MPI_WIN_CREATE: the goal should be contigues window, >>> i.e., no strided subarrays. >>> >>> Rolf >>> >>> ----- Original Message ----- >>>> From: "Pavan Balaji" <balaji(a)anl.gov> >>>> To: mpiwg-fortran(a)lists.mpi-forum.org >>>> Sent: Saturday, March 1, 2014 11:29:59 PM >>>> Subject: [MPIWG Fortran] Questions on the F08 subarray format >>>> >>>> Folks, >>>> >>>> I had a few questions on the MPI-3 F08 bindings, which I couldn’t >>>> find answers to in the standard. Can someone point me to the >>>> place >>>> where these are defined? >>>> >>>> 1. How does the subarray format work for functions that have a >>>> void* >>>> argument, but no datatype to describe them (e.g., MPI_WIN_CREATE)? >>>> In this case, What C function will MPI_WIN_CREATE_F08TS call? Do >>>> we need to create an separate internal MPIR_WIN_CREATE_NEW >>>> function >>>> in our implementation that takes a datatype argument? Does this >>>> mean that now MPI_WIN_CREATE can allow for noncontiguous buffers >>>> on >>>> each process? >>>> >>>> 2. How does the subarray format work for functions that have a >>>> datatype argument, but no void* corresponding to that datatype? >>>> For >>>> example, the target buffer in MPI_PUT is described using an >>>> MPI_AINT >>>> (offset), rather than a void*. >>>> >>>> 3. How does the subarray format work for functions that have two >>>> void* arguments corresponding to the same datatype (e.g., >>>> MPI_REDUCE)? >>>> >>>> Thanks, >>>> >>>> — Pavan >>>> >>>> _______________________________________________ >>>> mpiwg-fortran mailing list >>>> mpiwg-fortran(a)lists.mpi-forum.org >>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran >>>> >>> >>> -- >>> 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) >>> _______________________________________________ >>> mpiwg-fortran mailing list >>> mpiwg-fortran(a)lists.mpi-forum.org >>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran >> >> _______________________________________________ >> mpiwg-fortran mailing list >> mpiwg-fortran(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran >> > > -- > 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) > _______________________________________________ > mpiwg-fortran mailing list > mpiwg-fortran(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran

1 0

Re: [MPIWG Fortran] Questions on the F08 subarray format
by Rolf Rabenseifner 02 Mar '14

02 Mar '14

Pavan, I'm currently on travel for teaching a 3 day course, but a short answer: All blocking routines and all nonblocking routines with a blocking counter-part have already in MPI-2.2 a well-defined behavior for strided-subarray-buffers. Exactly the same behavior is expected with the new syntax. This behavior can be implemented exactly the same way as the compiler did in MPI-2.0 with blocking routines: - copying the strided subarray into a contiguous scratch buffer - calling the C routine with this contiguous scratch buffer - and -- in the case of blocking routines: dealloc the sctatch buffer -- in the case of nonblocking routines: mark for dealloc when the operation is completed, i.e., in the Wait or Test. If you want to do some optimizations, then thexy must behave as if it is coded in this described way. The only intersting cases seem to be: - MPI_Win_create - I would forbid strided windows, - and the remote part of MPI_Put/..., but this is solved if strided windows are not allowed. For MPI_Win_create, the problem is already solved as I wished above: MPI-3.0 p405:24-26: "In Fortran, one can pass the first element of a memory region or a whole array, which must be 'simply contiguous' (for 'simply contiguous', see also Section 17.1.12 on page 626)." For 'simply contiguous', see p628:14-27. Therefore, I expect that your questions are fully answered and there is no need for aditional clarifications. I may have missed some additional aspects in your questions? Bestregards Rolf ----- Original Message ----- > From: "Pavan Balaji" <balaji(a)anl.gov> > To: "MPI-WG Fortran working group" <mpiwg-fortran(a)lists.mpi-forum.org> > Sent: Sunday, March 2, 2014 10:47:14 PM > Subject: Re: [MPIWG Fortran] Questions on the F08 subarray format > > > Some more questions: > > 4. What happens when the void* corresponds to multiple counts of a > single datatype from different processes (e.g., GATHER or ALLTOALL)? > In the case of GATHER, suppose I’m gathering 2 INTEGERS from each > processes, can my receive buffer now be contiguous for some > processes and noncontiguous for others? > > 5. For some functions, the standard has wording that MPI_DATATYPE for > a particular function can only have predefined datatype. What > happens when the user uses a predefined datatype, but describes a > subarray in the void* argument? > > I’m assuming these are just holes that were not intended, but the > standard doesn’t seem to clearly state this. > > It’ll be great if someone can clarify the intention of the working > group for each of the five cases I mentioned. Rolf already > mentioned that the intention was to not allow noncontiguous buffers > for WIN_CREATE. What about other functions that take void*? E.g., > WIN_ATTACH/DETACH or other non-RMA functions that take void* but > don’t provide a datatype? > > Thanks, > > — Pavan > > On Mar 1, 2014, at 5:29 PM, Rolf Rabenseifner <rabenseifner(a)hlrs.de> > wrote: > > > I expect (after midnight) that clarifications are needed. > > On 1. MPI_WIN_CREATE: the goal should be contigues window, > > i.e., no strided subarrays. > > > > Rolf > > > > ----- Original Message ----- > >> From: "Pavan Balaji" <balaji(a)anl.gov> > >> To: mpiwg-fortran(a)lists.mpi-forum.org > >> Sent: Saturday, March 1, 2014 11:29:59 PM > >> Subject: [MPIWG Fortran] Questions on the F08 subarray format > >> > >> Folks, > >> > >> I had a few questions on the MPI-3 F08 bindings, which I couldn’t > >> find answers to in the standard. Can someone point me to the > >> place > >> where these are defined? > >> > >> 1. How does the subarray format work for functions that have a > >> void* > >> argument, but no datatype to describe them (e.g., MPI_WIN_CREATE)? > >> In this case, What C function will MPI_WIN_CREATE_F08TS call? Do > >> we need to create an separate internal MPIR_WIN_CREATE_NEW > >> function > >> in our implementation that takes a datatype argument? Does this > >> mean that now MPI_WIN_CREATE can allow for noncontiguous buffers > >> on > >> each process? > >> > >> 2. How does the subarray format work for functions that have a > >> datatype argument, but no void* corresponding to that datatype? > >> For > >> example, the target buffer in MPI_PUT is described using an > >> MPI_AINT > >> (offset), rather than a void*. > >> > >> 3. How does the subarray format work for functions that have two > >> void* arguments corresponding to the same datatype (e.g., > >> MPI_REDUCE)? > >> > >> Thanks, > >> > >> — Pavan > >> > >> _______________________________________________ > >> mpiwg-fortran mailing list > >> mpiwg-fortran(a)lists.mpi-forum.org > >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran > >> > > > > -- > > 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) > > _______________________________________________ > > mpiwg-fortran mailing list > > mpiwg-fortran(a)lists.mpi-forum.org > > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran > > _______________________________________________ > mpiwg-fortran mailing list > mpiwg-fortran(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran > -- 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

Re: [MPIWG Fortran] Questions on the F08 subarray format
by Balaji, Pavan 02 Mar '14

02 Mar '14

Some more questions: 4. What happens when the void* corresponds to multiple counts of a single datatype from different processes (e.g., GATHER or ALLTOALL)? In the case of GATHER, suppose I’m gathering 2 INTEGERS from each processes, can my receive buffer now be contiguous for some processes and noncontiguous for others? 5. For some functions, the standard has wording that MPI_DATATYPE for a particular function can only have predefined datatype. What happens when the user uses a predefined datatype, but describes a subarray in the void* argument? I’m assuming these are just holes that were not intended, but the standard doesn’t seem to clearly state this. It’ll be great if someone can clarify the intention of the working group for each of the five cases I mentioned. Rolf already mentioned that the intention was to not allow noncontiguous buffers for WIN_CREATE. What about other functions that take void*? E.g., WIN_ATTACH/DETACH or other non-RMA functions that take void* but don’t provide a datatype? Thanks, — Pavan On Mar 1, 2014, at 5:29 PM, Rolf Rabenseifner <rabenseifner(a)hlrs.de> wrote: > I expect (after midnight) that clarifications are needed. > On 1. MPI_WIN_CREATE: the goal should be contigues window, > i.e., no strided subarrays. > > Rolf > > ----- Original Message ----- >> From: "Pavan Balaji" <balaji(a)anl.gov> >> To: mpiwg-fortran(a)lists.mpi-forum.org >> Sent: Saturday, March 1, 2014 11:29:59 PM >> Subject: [MPIWG Fortran] Questions on the F08 subarray format >> >> Folks, >> >> I had a few questions on the MPI-3 F08 bindings, which I couldn’t >> find answers to in the standard. Can someone point me to the place >> where these are defined? >> >> 1. How does the subarray format work for functions that have a void* >> argument, but no datatype to describe them (e.g., MPI_WIN_CREATE)? >> In this case, What C function will MPI_WIN_CREATE_F08TS call? Do >> we need to create an separate internal MPIR_WIN_CREATE_NEW function >> in our implementation that takes a datatype argument? Does this >> mean that now MPI_WIN_CREATE can allow for noncontiguous buffers on >> each process? >> >> 2. How does the subarray format work for functions that have a >> datatype argument, but no void* corresponding to that datatype? For >> example, the target buffer in MPI_PUT is described using an MPI_AINT >> (offset), rather than a void*. >> >> 3. How does the subarray format work for functions that have two >> void* arguments corresponding to the same datatype (e.g., >> MPI_REDUCE)? >> >> Thanks, >> >> — Pavan >> >> _______________________________________________ >> mpiwg-fortran mailing list >> mpiwg-fortran(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran >> > > -- > 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) > _______________________________________________ > mpiwg-fortran mailing list > mpiwg-fortran(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran

1 0

Re: [MPIWG Fortran] Questions on the F08 subarray format
by Rolf Rabenseifner 01 Mar '14

01 Mar '14

I expect (after midnight) that clarifications are needed. On 1. MPI_WIN_CREATE: the goal should be contigues window, i.e., no strided subarrays. Rolf ----- Original Message ----- > From: "Pavan Balaji" <balaji(a)anl.gov> > To: mpiwg-fortran(a)lists.mpi-forum.org > Sent: Saturday, March 1, 2014 11:29:59 PM > Subject: [MPIWG Fortran] Questions on the F08 subarray format > > Folks, > > I had a few questions on the MPI-3 F08 bindings, which I couldn’t > find answers to in the standard. Can someone point me to the place > where these are defined? > > 1. How does the subarray format work for functions that have a void* > argument, but no datatype to describe them (e.g., MPI_WIN_CREATE)? > In this case, What C function will MPI_WIN_CREATE_F08TS call? Do > we need to create an separate internal MPIR_WIN_CREATE_NEW function > in our implementation that takes a datatype argument? Does this > mean that now MPI_WIN_CREATE can allow for noncontiguous buffers on > each process? > > 2. How does the subarray format work for functions that have a > datatype argument, but no void* corresponding to that datatype? For > example, the target buffer in MPI_PUT is described using an MPI_AINT > (offset), rather than a void*. > > 3. How does the subarray format work for functions that have two > void* arguments corresponding to the same datatype (e.g., > MPI_REDUCE)? > > Thanks, > > — Pavan > > _______________________________________________ > mpiwg-fortran mailing list > mpiwg-fortran(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran > -- 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

Questions on the F08 subarray format
by Balaji, Pavan 01 Mar '14

01 Mar '14

Folks, I had a few questions on the MPI-3 F08 bindings, which I couldn’t find answers to in the standard. Can someone point me to the place where these are defined? 1. How does the subarray format work for functions that have a void* argument, but no datatype to describe them (e.g., MPI_WIN_CREATE)? In this case, What C function will MPI_WIN_CREATE_F08TS call? Do we need to create an separate internal MPIR_WIN_CREATE_NEW function in our implementation that takes a datatype argument? Does this mean that now MPI_WIN_CREATE can allow for noncontiguous buffers on each process? 2. How does the subarray format work for functions that have a datatype argument, but no void* corresponding to that datatype? For example, the target buffer in MPI_PUT is described using an MPI_AINT (offset), rather than a void*. 3. How does the subarray format work for functions that have two void* arguments corresponding to the same datatype (e.g., MPI_REDUCE)? Thanks, — Pavan

1 0