<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, May 13, 2014 at 2:37 PM, Bill Long <span dir="ltr"><<a href="mailto:longb@cray.com" target="_blank">longb@cray.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class=""><br>
On May 13, 2014, at 2:19 PM, Junchao Zhang <<a href="mailto:jczhang@mcs.anl.gov">jczhang@mcs.anl.gov</a>> wrote:<br>
<br>
><br>
> On Tue, May 13, 2014 at 2:00 PM, Bill Long <<a href="mailto:longb@cray.com">longb@cray.com</a>> wrote:<br>
><br>
> On May 13, 2014, at 12:44 PM, Junchao Zhang <<a href="mailto:jczhang@mcs.anl.gov">jczhang@mcs.anl.gov</a>> wrote:<br>
><br>
> ><br>
> > On Tue, May 13, 2014 at 11:56 AM, Rolf Rabenseifner <<a href="mailto:rabenseifner@hlrs.de">rabenseifner@hlrs.de</a>> wrote:<br>
> > > REAL s(100)<br>
> > > MPI_SEND(s (1:100:5) , 3, dtype, ...)<br>
> > > dtype can only be MPI_REAL. In other words, dtype is kind of<br>
> > > redundant here since the type map is actually specified by the<br>
> > > subarray.<br>
><br>
> Right.  The descriptor for the first argument has a member whose value is a type code.  In principal the library could verify this is compatible with the data type handle supplied as the third argument, and issue an error if not.  Perhaps in a “debug” mode.<br>

><br>
> ><br>
> > No, if dtype is a vector then it is applied to a virtual<br>
> > contiguous array that consists of s(1), s(6), s(11) …<br>
><br>
> dtype is not  a vector, is it?  That argument is a scalar of type TYPE(MPI_DATATYPE).  At least that is what the interface says.<br>
><br>
> Rolf meant dtype is an MPI datatype created by MPI_Type_vector.  For this case, I will have two datatypes, one from the MPI_Datatype argument, the other from the choice buffer itself. It is hard to implement that. Perhaps it is useless since it obscures the program.<br>

<br>
</div>OK. But one of the virtues of the new interface for users is that you do not have to create such data types anymore for array sections.   Even if someone did do this, you can detect that the incoming data type is user-created, and in that case ignore the type code in the descriptor.  If the program is valid at all, the element length, strides, and extents in the descriptor should be correct.<br>
</blockquote><div><br></div><div>Yes, I can do that. The hard part is when the subarray is non-contiguous, and it is a non-blocking call. I need to allocate a scratch buffer and pack the subarray. Since it is non-blocking, I can not free the buffer.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Cheers,<br>
Bill<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
<br>
><br>
><br>
><br>
> Cheers,<br>
> Bill<br>
><br>
><br>
> ><br>
> > That is nasty. Then I will have two data types. I even can not assume any relationship between the two types. I have to allocate a scratch buffer for the virtual contiguous array in MPI_ISEND etc, do memory copying and then free the buffer in MPI_WAIT. I'm not sure one can implement it efficiently.<br>

> ><br>
> ><br>
> ><br>
> > ----- Original Message -----<br>
> > > From: "Junchao Zhang" <<a href="mailto:jczhang@mcs.anl.gov">jczhang@mcs.anl.gov</a>><br>
> > > To: "MPI-WG Fortran working group" <<a href="mailto:mpiwg-fortran@lists.mpi-forum.org">mpiwg-fortran@lists.mpi-forum.org</a>><br>
> > > Sent: Tuesday, May 13, 2014 6:23:08 PM<br>
> > > Subject: Re: [MPIWG Fortran] Data type of F08 subarray<br>
> > ><br>
> > ><br>
> > ><br>
> > > Thanks, Rolf. And I feel there is a jump from contiguous subarray to<br>
> > > non-contiguous subarray.<br>
> > ><br>
> > ><br>
> > ><br>
> > > For contiguous subarray, such as<br>
> > ><br>
> > ><br>
> > ><br>
> > ><br>
> > > REAL s(100)<br>
> > ><br>
> > > MPI_SEND(s(2:50), 3, dtype, ...) s only gives the start address.<br>
> > > dtype can be anything, e.g., either a basic type or a derived type<br>
> > > created by MPI_Type_vector() etc.<br>
> > ><br>
> > ><br>
> > ><br>
> > > For non-contiguous subarray, such as<br>
> > ><br>
> > ><br>
> > ><br>
> > > REAL s(100)<br>
> > > MPI_SEND(s (1:100:5) , 3, dtype, ...)<br>
> > > dtype can only be MPI_REAL. In other words, dtype is kind of<br>
> > > redundant here since the type map is actually specified by the<br>
> > > subarray.<br>
> > ><br>
> > ><br>
> > ><br>
> > ><br>
> > ><br>
> > ><br>
> > > --Junchao Zhang<br>
> > ><br>
> > ><br>
> > > On Tue, May 13, 2014 at 10:20 AM, Rolf Rabenseifner <<br>
> > > <a href="mailto:rabenseifner@hlrs.de">rabenseifner@hlrs.de</a> > wrote:<br>
> > ><br>
> > ><br>
> > > Dear Junchao,<br>
> > ><br>
> > > MPI-3.0 p25:7-8 describes only communication with language type<br>
> > > of the buffer argument matches to the MPI datatype used<br>
> > > in the datatype argument.<br>
> > > Same p83:36-37.<br>
> > ><br>
> > > Therefore, the answer is no and the compiler cannot detect<br>
> > > a mismatch beteen language buffer specification and<br>
> > > MPI datatype specification.<br>
> > ><br>
> > > I hope my answer could help.<br>
> > ><br>
> > > Best regards<br>
> > > Rolf<br>
> > ><br>
> > ><br>
> > ><br>
> > ><br>
> > > ----- Original Message -----<br>
> > > > From: "Junchao Zhang" < <a href="mailto:jczhang@mcs.anl.gov">jczhang@mcs.anl.gov</a> ><br>
> > > > To: "MPI-WG Fortran working group" <<br>
> > > > <a href="mailto:mpiwg-fortran@lists.mpi-forum.org">mpiwg-fortran@lists.mpi-forum.org</a> ><br>
> > > > Sent: Tuesday, May 13, 2014 5:08:30 PM<br>
> > > > Subject: [MPIWG Fortran] Data type of F08 subarray<br>
> > > ><br>
> > > ><br>
> > > ><br>
> > > ><br>
> > > > p626 of MPI-3.0 gives such an example<br>
> > > ><br>
> > > ><br>
> > > > REAL s(100), r(100)<br>
> > > > CALL MPI_Isend(s(1:100:5), 3, MPI_REAL, ..., rq, ierror)<br>
> > > ><br>
> > > > All nonblocking MPI functions behave as if the user-specified<br>
> > > > elements of choice buffers are copied to a contiguous scratch<br>
> > > > buffer<br>
> > > > in the MPI runtime environment. All datatype descriptions (in the<br>
> > > > example above, “3, MPI_REAL”) read and store data from and to this<br>
> > > > virtual contiguous scratch buffer ...<br>
> > > ><br>
> > > > Here, data type of s(100) match with MPI_REAL, so everything is<br>
> > > > fine.<br>
> > > > But I want to know if MPI permits mismatched types, for example,<br>
> > > > can<br>
> > > > s(100) be an integer array? If the answer is no, then compilers can<br>
> > > > not detect this error ; if yes, then it is hard to implement that.<br>
> > > > To avoid memory copying to a scratch buffer, I want to use MPI<br>
> > > > datatypes. But if I have two types, one is given by the choice<br>
> > > > buffer itself, the other is given by the MPI_Datatype argument, how<br>
> > > > could I do that?<br>
> > > ><br>
> > > > Any thoughts?<br>
> > > ><br>
> > > > Thanks<br>
> > > ><br>
> > > > --Junchao Zhang<br>
> > > > _______________________________________________<br>
> > > > mpiwg-fortran mailing list<br>
> > > > <a href="mailto:mpiwg-fortran@lists.mpi-forum.org">mpiwg-fortran@lists.mpi-forum.org</a><br>
> > > > <a href="http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran" target="_blank">http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran</a><br>
> > ><br>
> > > --<br>
> > > Dr. Rolf Rabenseifner . . . . . . . . . .. email <a href="mailto:rabenseifner@hlrs.de">rabenseifner@hlrs.de</a><br>
> > > High Performance Computing Center (HLRS) . phone <a href="tel:%2B%2B49%280%29711%2F685-65530" value="+4971168565530">++49(0)711/685-65530</a><br>
> > > University of Stuttgart . . . . . . . . .. fax <a href="tel:%2B%2B49%280%29711%20%2F%20685-65832" value="+4971168565832">++49(0)711 / 685-65832</a><br>
> > > Head of Dpmt Parallel Computing . . . <a href="http://www.hlrs.de/people/rabenseifner" target="_blank">www.hlrs.de/people/rabenseifner</a><br>
> > > Nobelstr. 19, D-70550 Stuttgart, Germany . . . . (Office: Room 1.307)<br>
> > > _______________________________________________<br>
> > > mpiwg-fortran mailing list<br>
> > > <a href="mailto:mpiwg-fortran@lists.mpi-forum.org">mpiwg-fortran@lists.mpi-forum.org</a><br>
> > > <a href="http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran" target="_blank">http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran</a><br>
> > ><br>
> > > _______________________________________________<br>
> > > mpiwg-fortran mailing list<br>
> > > <a href="mailto:mpiwg-fortran@lists.mpi-forum.org">mpiwg-fortran@lists.mpi-forum.org</a><br>
> > > <a href="http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran" target="_blank">http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran</a><br>
> ><br>
> > --<br>
> > Dr. Rolf Rabenseifner . . . . . . . . . .. email <a href="mailto:rabenseifner@hlrs.de">rabenseifner@hlrs.de</a><br>
> > High Performance Computing Center (HLRS) . phone <a href="tel:%2B%2B49%280%29711%2F685-65530" value="+4971168565530">++49(0)711/685-65530</a><br>
> > University of Stuttgart . . . . . . . . .. fax <a href="tel:%2B%2B49%280%29711%20%2F%20685-65832" value="+4971168565832">++49(0)711 / 685-65832</a><br>
> > Head of Dpmt Parallel Computing . . . <a href="http://www.hlrs.de/people/rabenseifner" target="_blank">www.hlrs.de/people/rabenseifner</a><br>
> > Nobelstr. 19, D-70550 Stuttgart, Germany . . . . (Office: Room 1.307)<br>
> > _______________________________________________<br>
> > mpiwg-fortran mailing list<br>
> > <a href="mailto:mpiwg-fortran@lists.mpi-forum.org">mpiwg-fortran@lists.mpi-forum.org</a><br>
> > <a href="http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran" target="_blank">http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran</a><br>
> ><br>
> > _______________________________________________<br>
> > mpiwg-fortran mailing list<br>
> > <a href="mailto:mpiwg-fortran@lists.mpi-forum.org">mpiwg-fortran@lists.mpi-forum.org</a><br>
> > <a href="http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran" target="_blank">http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran</a><br>
><br>
> Bill Long                                                                       <a href="mailto:longb@cray.com">longb@cray.com</a><br>
> Fortran Technical Suport  &                                  voice:  <a href="tel:651-605-9024" value="+16516059024">651-605-9024</a><br>
> Bioinformatics Software Development                     fax:  <a href="tel:651-605-9142" value="+16516059142">651-605-9142</a><br>
> Cray Inc./ Cray Plaza, Suite 210/ 380 Jackson St./ St. Paul, MN 55101<br>
><br>
><br>
> _______________________________________________<br>
> mpiwg-fortran mailing list<br>
> <a href="mailto:mpiwg-fortran@lists.mpi-forum.org">mpiwg-fortran@lists.mpi-forum.org</a><br>
> <a href="http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran" target="_blank">http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran</a><br>
><br>
> _______________________________________________<br>
> mpiwg-fortran mailing list<br>
> <a href="mailto:mpiwg-fortran@lists.mpi-forum.org">mpiwg-fortran@lists.mpi-forum.org</a><br>
> <a href="http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran" target="_blank">http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran</a><br>
<br>
Bill Long                                                                       <a href="mailto:longb@cray.com">longb@cray.com</a><br>
Fortran Technical Suport  &                                  voice:  <a href="tel:651-605-9024" value="+16516059024">651-605-9024</a><br>
Bioinformatics Software Development                     fax:  <a href="tel:651-605-9142" value="+16516059142">651-605-9142</a><br>
Cray Inc./ Cray Plaza, Suite 210/ 380 Jackson St./ St. Paul, MN 55101<br>
<br>
<br>
_______________________________________________<br>
mpiwg-fortran mailing list<br>
<a href="mailto:mpiwg-fortran@lists.mpi-forum.org">mpiwg-fortran@lists.mpi-forum.org</a><br>
<a href="http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran" target="_blank">http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran</a><br>
</div></div></blockquote></div><br></div></div>