[MPIWG Fortran] Provide Fortran datatypes if Fortran bindings not provided?

Thu Feb 18 08:48:46 CST 2016

I'm sure that I cannot oversee the whole problem in the moment,
therefore my proposal may be not good enough, 
but it is very simple.

I would propose to add an advice to implementers to the 
standard (e.g., after the first sentence of page 659
line 2) in the way:

In the case of a missing accompanying Fortran compiler,
a high-quality MPI implementation would provide
the Fortran datatypes with sizes based on 
Table 13.2 on page 540 and alignments that are
a identical to the size (single unit size x in
case of 2*x), but not larger than 4.

(As far as I remenber, this is the standard or usual
Fortran alignment for common blocks and SEQUENCEd derived
Fortran types, if  a numerical unit is 4 bytes,
which is used as the basis in Table 13.2) 

I hope, that this helpes and reduces any complication
that applications may have when 
 - not providing the Fortran datatypes, or
 - providing them as MPI_DATAYPE_NULL.

Rolf

----- Original Message -----
> From: "longb" <longb at cray.com>
> To: "MPI-WG Fortran working group" <mpiwg-fortran at lists.mpi-forum.org>
> Sent: Thursday, February 18, 2016 2:58:54 PM
> Subject: Re: [MPIWG Fortran] Provide Fortran datatypes if Fortran bindings not	provided?

> On Feb 18, 2016, at 5:45 AM, Jeff Squyres (jsquyres) <jsquyres at cisco.com> wrote:
> 
>> A question has come up recently in the Open MPI community (being debated in a
>> lengthy thread here
>> https://www.open-mpi.org/community/lists/users/2016/02/28448.php):
>> 
>> If Fortran support is not provided in an Open MPI installation (e.g., if Open
>> MPI's configure script detects that there is no Fortran compiler, and therefore
>> none of the mpif.h, mpi module, or mpi_f08 module are compiled), should Fortran
>> datatypes (e.g., MPI_INTEGER) be available in the C bindings?
> 
> 
> This argument seems shortsighted.
> 
> It would seem peculiar to have no Fortran compiler installed.  Even if that was
> the case at the moment, it could change in the future, and you would not want
> to have to rebuild MPI in that case.
> 
> What about MPI I/O?  Even if the local system that is writing a file does not
> have a Fortran compiler, the program (on a different system) reading the file
> might, and be expecting Fortran data types to have been used in writing the
> file.
> 
> 
>> 
>> It was pointed out that MPI-3.1 says that the Fortran bindings are optional --
>> but datatypes are not currently marked as optional.
>> 
>> Hence, even if you don't have to Fortran compiler, you still have to have
>> declarations for MPI_INTEGER (and friends) in mpi.h.
>> 
>> What do people think about this?
>> 
>> ARGUMENTS FOR KEEPING IT THE SAME
>> =================================
>> 
>> A1. MPI can set MPI_INTEGER to be equivalent to MPI_DATATYPE_NULL.
> 
> I agree with B1 in this case - this is unnecessarily hostile.
> 
>> A2. MPI could probably figure out what Fortran INTEGER would have been (i.e.,
>> probably equivalent to C int) and just set MPI_INTEGER to be that.
> 
> Instead, the spec might be more specific in this case.  If there is no Fortran
> information available, specify a default mapping, such as INTEGER -> int, REAL
> -> float, …  A sampling of existing Fortran and C compilers that are designed
> to interoperate would probably lead to a pretty universal set of mappings
> (ignoring the -r8 -i8 issue noted below).
> 
>> A3. The whole point of having Fortran datatypes available in C is that even an
>> MPI process written in C can receive/send data from MPI processes in Fortran.
>> Hence, *this* MPI process -- compiled by an MPI implementation that does not
>> have a Fortran compiler -- may not have Fortran support, but a peer MPI process
>> in the same MPI job may have Fortran support.
> 
> I think the MPI I/O argument might be a stronger case for A3.
> 
>> 
>> ARGUMENTS FOR A CHANGE
>> ======================
>> 
>> B1. Setting MPI_INTEGER (and friends) to MPI_DATATYPE_NULL -- which will cause a
>> run-time MPI exception -- is somewhat anti-social behavior (and potentially
>> confusing to the user).
> 
> Agree. But coming up with a bad idea is not a convincing argument for a change.
> 
>> B2. An MPI implementation can *assume* but can't *know* what the
>> size/representation of Fortran datatypes are unless there's a Fortran compiler
>> with which to test.
> 
> Even in that case, you can’t know for sure because (too many) Fortran compilers
> have command line switches like -r8 or -i8 that change, on a program by program
> basis, what REAL or INTEGER means.
> 
>> B3. A3 is a somewhat sketchy claim.  It's obviously possible and valid, but
>> fairly uncommon to have multiple MPI implementation installations involved in a
>> single execution of an MPI application.
> 
> I agree with this, but the MPI I/O example does not involve a single execution.
> 
> 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
> 
> 
> _______________________________________________
> 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)