<div dir="ltr"><div><span style="font-size:13px">Jeff Squyres wrote:</span></div><div><span style="font-size:13px"><br></span></div><span style="font-size:13px">>Hmm.  Ok, that's the opposite advice we got for MPI-3.0 (which was now admittedly several years ago).</span><br style="font-size:13px">><br style="font-size:13px"><span style="font-size:13px">>Soo... which way should it go these days?</span><br style="font-size:13px">><br style="font-size:13px"><span style="font-size:13px">>- use native Fortran datatypes</span><br style="font-size:13px"><span style="font-size:13px">>- use C datatypes (via BIND(C))</span><br style="font-size:13px"><br style="font-size:13px"><div>I don't think the advice has changed since MPI-3.0.  I believe the preference is for the application programmer to see native Fortran datatypes, not, for example, REAL(C_DOUBLE).  However, BIND(C) kinds can be used in the MPI_F08 module to declare the new datatypes, e.g.,</div><div><br></div><div><span style="color:rgb(80,0,80);font-size:13px">TYPE MPI_DOUBLE_INT_TYPE</span><br style="color:rgb(80,0,80);font-size:13px"><span style="color:rgb(80,0,80);font-size:13px">  SEQUENCE</span><br style="color:rgb(80,0,80);font-size:13px"><span style="color:rgb(80,0,80);font-size:13px">  REAL(kind=C_DOUBLE) :: VAL</span><br style="color:rgb(80,0,80);font-size:13px"><span style="color:rgb(80,0,80);font-size:13px">  INTEGER :: LOC</span><br style="color:rgb(80,0,80);font-size:13px"><span style="color:rgb(80,0,80);font-size:13px">END TYPE</span><br style="color:rgb(80,0,80);font-size:13px"></div><div><span style="color:rgb(80,0,80);font-size:13px"><br></span></div><div>as the application programmer will only use TYPE(MPI_DOUBLE_INT_TYPE) in a type declaration and not know that it is defined in terms of native C types.<span style="color:rgb(80,0,80);font-size:13px"><br></span></div><div><br></div><div>I also don't think it matters that SEQUENCE is used to define MPI_DOUBLE_INT_TYPE even if it is no longer considered to be so pretty.  However, I'm still confused by how this is used in C.  Jeff S. in responding to Bill L. said:</div><div><br></div><div><span class="im" style="font-size:13px">>> How do you handle  MPI_SHORT_INT?  A short immediately followed in memory by an int will cause the int to have bad memory alignment.<br>><br></span><span style="font-size:13px">> Right.  MPI knows this; MPI_SHORT_INT will include padding between the SHORT and INT if it needs to.</span><br style="font-size:13px"></div><div><span style="font-size:13px">></span></div><div><span style="font-size:13px"><br></span></div><div><span style="font-size:13px">How does a C programmer get the value returned in MPI_SHORT_INT?  By accessing a member of a C struct? Google suggests MPI_SHORT_INT is a struct {short, int} as well as a pair of short integers followed by a 32 bit integer.  Since these data types really do contain the proper amount of padding (despite what I infer from reading the MPI 3.1 standard), I think Bill's suggestion of declaring the Fortran types to be BIND(C) equivalent to a C struct is the right thing to do.  Note that the Fortran application programmer won't ever see the BIND(C) attribute.</span></div><div><span style="font-size:13px"><br></span></div><div><span style="font-size:13px">Final note:  I was searching the WRONG Fortran standard document when I couldn't find SEQUENCE and therefore said it looked like it was no longer in the standard.  My bad...  :-(</span></div><div><span style="font-size:13px"><br></span></div><div><span style="font-size:13px">-craig</span></div><div><span style="font-size:13px"><br></span></div><div><br></div><div>-craig</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Dec 9, 2015 at 5:45 AM, Jeff Squyres (jsquyres) <span dir="ltr"><<a href="mailto:jsquyres@cisco.com" target="_blank">jsquyres@cisco.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Dec 8, 2015, at 6:31 PM, Bill Long <<a href="mailto:longb@cray.com">longb@cray.com</a>> wrote:<br>
><br>
> As I understand the high-level situation, this is all for MPI_REDUCE and friends, and MPI_2INTEGER and MPI_MINLOC or MPI_MAXLOC are all just magic constants that the MPI_REDUCE routine internally decodes to determine what to do.  The actual data, the in and out arguments of MPI_REDUCE, are choice arguments (void *).<br>
<br>
> Current codes have the actual argument IN declared as INTEGER :: IN (2, K) where K is the number of things in the list to be reduced. IN(1,*) is the “VAL" value, and IN(2,*) is the “LOC” value.  Since the corresponding dummy argument is (void *) you can pass any actual type, since only the memory layout matters.<br>
<br>
</span>Correct.<br>
<span class=""><br>
> If the above is correct, then the following declarations would have the same memory layouts for the actual arguments:<br>
><br>
> INTEGER :: IN(2, K)<br>
><br>
> and<br>
><br>
> TYPE MPI_2INTEGER_TYPE<br>
>    SEQUENCE<br>
>    INTEGER :: VAL<br>
>    INTEGER :: LOC<br>
> END TYPE<br>
><br>
> TYPE(MPI_2INTEGER_TYPE) :: IN(K)<br>
><br>
> This seems like sugar coating for the 2INTEGER case.<br>
<br>
</span>Yes, exactly.<br>
<br>
Is there a way to do it without SEQUENCE (since that is frowned upon)?<br>
<span class=""><br>
> But, the following would likely not be equivalent:<br>
><br>
> DOUBLE PRECISION :: IN(2, K)<br>
><br>
> and<br>
><br>
> TYPE MPI_DOUBLE_INT_TYPE<br>
>   SEQUENCE<br>
>   DOUBLE PRECISION :: VAL<br>
>   INTEGER :: LOC<br>
> END TYPE<br>
><br>
> TYPE(MPI_DOUBLE_INT_TYPE) :: IN(K)<br>
<br>
</span>Right -- I'm not trying to make those equivalent.<br>
<br>
To be clear:<br>
<br>
- the only one where we need this equivalence MPI_2INTEGER.<br>
- the intent is to deprecate MPI_2DOUBLE_PRECISION and MPI_2REAL<br>
  --> I assume that these are historical artifacts that were created before derived types existed<br>
- and then create 2 new types: MPI_DOUBLE_PRECISION_INTEGER and MPI_REAL_INTEGER<br>
  --> these will be analogous to their C counterparts (but using Fortran types, not C types)<br>
<span class=""><br>
>> 2. I wasn't looking to emulate the C types in Fortran -- I think we've had this discussion before.  The intent is to have Fortran-native types (that would be natural for Fortran programmers).<br>
><br>
> I think BIND(C) is “natural” for Fortran programmers these days.  This stuff has been around for over a decade.  The use of “DOUBLE PRECISION” is far less natural these days.  Essentially everyone has switched to REAL(KIND= ) instead.  That stuff is 25 years old.<br>
<br>
</span>Hmm.  Ok, that's the opposite advice we got for MPI-3.0 (which was now admittedly several years ago).<br>
<br>
Soo... which way should it go these days?<br>
<br>
- use native Fortran datatypes<br>
- use C datatypes (via BIND(C))<br>
<br>
I.e., when users want to use MINLOC / MAXLOC in fortran, will they be using this across DOUBLE PRECISION values, or Type(C_DOUBLE)?<br>
<div class="HOEnZb"><div class="h5"><br>
--<br>
Jeff Squyres<br>
<a href="mailto:jsquyres@cisco.com">jsquyres@cisco.com</a><br>
For corporate legal information go to: <a href="http://www.cisco.com/web/about/doing_business/legal/cri/" rel="noreferrer" target="_blank">http://www.cisco.com/web/about/doing_business/legal/cri/</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" rel="noreferrer" target="_blank">http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran</a><br>
</div></div></blockquote></div><br></div>