[MPIWG Fortran] F08 and pair types?

[Rolf Rabenseifner]

Dear Jeff and Hubert,

I strongly recommend that you both check my answer from 
Dec. 11, 2015 to this topic (see below).

It stays in the Fortran world, i.e., it fits exactly to
all reasons listed by Hubert.

Best regards
Rolf

----- Forwarded Message -----
From: "Rolf Rabenseifner" <rabenseifner at hlrs.de>
To: "MPI-WG Fortran working group" <mpiwg-fortran at lists.mpi-forum.org>
Sent: Friday, December 11, 2015 11:38:00 AM
Subject: Re: [MPIWG Fortran] F08 and pair types?

A few comments - shortcut: F08 and pair types
is a good idea and helps to get MPI-4.0 more consistent.


1. After the fiasco with the MPI-3.0 BIND(C) back-end and 
   a completely rewritten Fortran back-end section without BIND(C),
   I would strongly recommend to stay within Fortran without C.

One possible reason: if somebody wants to add something 
to MAX/MINLOC with a datatype that is not directly C compatible
(like LOGICAL), then we would have an inconsistent Interface.

This applies to the type of the numerical data itself, i.e.,
the following application code would fit to the
MPI datatype handle MPI_DOUBLE_PRECISION_INT_TYPE 

  TYPE MY_DOUBLE_PRECISION_INT_TYPE
    SEQUENCE
    DOUBLE PRECISION :: VAL
    INTEGER :: LOC
  END TYPE

and we should ***never*** do

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

and it also applies to the whole stucture, i.e., 
we should ***never*** do

  TYPE, BIND(C) :: MY_DOUBLE_PRECISION_INT_TYPE
    DOUBLE PRECISION :: VAL
    INTEGER :: LOC
  END TYPE

nor 

  TYPE, BIND(C) :: MY_DOUBLE_PRECISION_INT_TYPE
    REAL(kind=C_DOUBLE) :: VAL
    INTEGER :: LOC
  END TYPE

2. The names for Fortran and C should be clearly different.

   In Fortran we should define the following datatype handles:

   - new MPI_DOUBLE_PRECISION_INT_TYPE (29 character :-)
   - new MPI_REAL_INT and
   - existing MPI_2INTEGER 
     (but with this new meaning [i.e. SEQUENCE derived type
      with two INTEGERs], which is memory-wise identical
      to the current definition of an array of two INTEGERs)

3. It is up to the MPI library to understand the 
   alignment rules for these types.

   Implication: 
   Because we will define this through MPI_TYPE_CREATE_STRUCT
   as on MPI-3.1 page 180 lines 33-42,
   we must define MPI_TYPE_CREATE_STRUCT correctly.
   This means, that the attomatic alignment epsilon on page 105
   for Fortran types must be according to the rules 
   for Fortran derived types with the SEQUENCE attribute.
   Currently it is not defined, which is bad for old MPI-1.1
   application when BIND(C) was not yet invented.
   The text of MPI-3.1 Section 17.1.15 Fortran Derived Types
   must also reflect this now well-defined definition of 
   the Fortran alignment epsilon.

   This change is a change from undefined to defined,
   i.e., existing correct MPI applications must not
   have a problem with this change.

   Some MPI libraries do not yet calculate correct 
   Fortran alignments (in this sense), because they apply 
   C alignments to Fortran types. 
   These MPI libraries must be corrected.

4. If somebody uses MPI_FLOAT_INT together with MAX/MIN_LOC
   in Fortran, then this is already allowed based on 
   MPI-3.1 page 659 lines 1-9!

   A Fortran programmer may program the buffer 
   for MPI_FLOAT_INT with 

   TYPE, BIND(C) :: my_float_int
     REAL(kind=C_FLOAT)  :: VAL
     INTEGER(kind=C_INT) :: LOC
   END TYPE

5. All said is of course valid for all three
   mpi_f08 module, mpi module, and mpif.h


I hope that my comments are not inconflicht with
previous discussions.
 
Best regards
Rolf


----- Original Message -----
> From: "Hubert Ritzdorf" <Hubert.Ritzdorf at EMEA.NEC.COM>
> To: "MPI-WG Fortran working group" <mpiwg-fortran at lists.mpi-forum.org>
> Sent: Friday, December 18, 2015 8:34:36 PM
> Subject: Re: [MPIWG Fortran] F08 and pair types?

> 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 think that MPI Fortran Interface should support native Fortran datatypes in
> pair types !
> 
> (*) We (NEC) don't know any relevant Fortran application which doesn't use
> native Fortran datatypes.
> If you switch for C Datatypes in MINLOC/MAXLOC, all application programmers must
> solve
> the portability problems (possibly loosing accuracy in reduce operations).
> 
> (*) Nearly all Fortran compilers support compile time options such as "-r8" or
> "-size real64"
> which would cause problems with the C datatypes.
> And this options are used by application programmers !
> 
> (*) C datatypes would be inconsistent with functions such as
> MPI_Type_create_f90_real.
> 
> (*) Supporting Fortran subarrays without supporting native Fortran datatypes
> doesn't make sense for me.
> 
> Hubert
> 
> 
> 
> _______________________________________________
> mpiwg-fortran mailing list
> mpiwg-fortran at lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran

-- 
Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner at hlrs.de
High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530
University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832
Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner
Nobelstr. 19, D-70550 Stuttgart, Germany . . . . (Office: Room 1.307)