[MPIWG Fortran] F08 and pair types?

[Bill Long]

On Dec 9, 2015, at 7: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)?

There are two ways to define a type that has enforced memory layout.  One is SEQUENCE types which (for default numeric and logical components) are laid out as a sequence of numeric memory storage units (2 for double precision and 1 for real, integer, logical).  The other is to make the type a BIND(C) type, in which case the C compiler’s rules determine the layout. 

However, knowing the layout is only important for the legacy interfaces.  I would not expect any new feature to be back-ported to those old interfaces.  After all, I assume the intention is to deprecate and eventually delete them. Why waste ink putting more lipstick on the old pig?  The F08 interfaces include enough information sent to the callee that it can figure out the memory layout. 


> 
>> 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)?
> 

The difference between DOUBLE PRECISION and REAL(C_DOUBLE) is that the first can change depending on compilation options like “-i8” which, with normal sizes of today would be 8 bytes (without -i8) or 16 bytes (with -i8).  Unless there is an intent to support quad floats on the C side, I’d avoid the DOUBLE PRECISION option.  Using the C types makes things unambiguously correct when the arguments make it to the C library code. 

Cheers,
Bill


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

Bill Long                                                                       longb at cray.com
Fortran Technical Support  &                                  voice:  651-605-9024
Bioinformatics Software Development                     fax:  651-605-9142
Cray Inc./ Cray Plaza, Suite 210/ 380 Jackson St./ St. Paul, MN 55101