<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, May 13, 2014 at 2:00 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:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class=""><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>
</div>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>
<div class=""><br>
><br>
> No, if dtype is a vector then it is applied to a virtual<br>
</div>> 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></blockquote><div><br></div><div>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. </div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
Cheers,<br>
Bill<br>
<div><div class="h5"><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>
</div></div>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>
<div class=""><div class="h5"><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>