[MPIWG Fortran] F08 and pair types?

[Craig Rasmusen]

Jeff Squyres wrote:

>Hmm.  Ok, that's the opposite advice we got for MPI-3.0 (which was now
admittedly several years ago).
>
>Soo... which way should it go these days?
>
>- use native Fortran datatypes
>- use C datatypes (via BIND(C))

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.,

TYPE MPI_DOUBLE_INT_TYPE
  SEQUENCE
  REAL(kind=C_DOUBLE) :: VAL
  INTEGER :: LOC
END TYPE

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.

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:

>> 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.
>
> Right.  MPI knows this; MPI_SHORT_INT will include padding between the
SHORT and INT if it needs to.
>

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.

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...  :-(

-craig


-craig

On Wed, Dec 9, 2015 at 5:45 AM, Jeff Squyres (jsquyres) <jsquyres at cisco.com>
wrote:

> On Dec 8, 2015, at 6:31 PM, Bill Long <longb at cray.com> wrote:
> >
> > 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 *).
>
> > 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.
>
> Correct.
>
> > If the above is correct, then the following declarations would have the
> same memory layouts for the actual arguments:
> >
> > INTEGER :: IN(2, K)
> >
> > and
> >
> > TYPE MPI_2INTEGER_TYPE
> >    SEQUENCE
> >    INTEGER :: VAL
> >    INTEGER :: LOC
> > END TYPE
> >
> > TYPE(MPI_2INTEGER_TYPE) :: IN(K)
> >
> > This seems like sugar coating for the 2INTEGER case.
>
> Yes, exactly.
>
> Is there a way to do it without SEQUENCE (since that is frowned upon)?
>
> > But, the following would likely not be equivalent:
> >
> > DOUBLE PRECISION :: IN(2, K)
> >
> > and
> >
> > TYPE MPI_DOUBLE_INT_TYPE
> >   SEQUENCE
> >   DOUBLE PRECISION :: VAL
> >   INTEGER :: LOC
> > END TYPE
> >
> > TYPE(MPI_DOUBLE_INT_TYPE) :: IN(K)
>
> Right -- I'm not trying to make those equivalent.
>
> To be clear:
>
> - the only one where we need this equivalence MPI_2INTEGER.
> - the intent is to deprecate MPI_2DOUBLE_PRECISION and MPI_2REAL
>   --> I assume that these are historical artifacts that were created
> before derived types existed
> - and then create 2 new types: MPI_DOUBLE_PRECISION_INTEGER and
> MPI_REAL_INTEGER
>   --> these will be analogous to their C counterparts (but using Fortran
> types, not C types)
>
> >> 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).
> >
> > 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.
>
> Hmm.  Ok, that's the opposite advice we got for MPI-3.0 (which was now
> admittedly several years ago).
>
> Soo... which way should it go these days?
>
> - use native Fortran datatypes
> - use C datatypes (via BIND(C))
>
> I.e., when users want to use MINLOC / MAXLOC in fortran, will they be
> using this across DOUBLE PRECISION values, or Type(C_DOUBLE)?
>
> --
> Jeff Squyres
> jsquyres at cisco.com
> For corporate legal information go to:
> http://www.cisco.com/web/about/doing_business/legal/cri/
>
> _______________________________________________
> mpiwg-fortran mailing list
> mpiwg-fortran at lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpi-forum.org/pipermail/mpiwg-fortran/attachments/20151210/d5806c52/attachment-0001.html>