mpiforumbot
commented
8 years ago Originally by RolfRabenseifner on 2010-09-01 11:32:02 -0500
229-A: Overview over all related tickets## Description
This ticket gives an overview over all related new MPI-3 Fortran tickets. It is intended that they are independent or that the require-relation is only uni-directional. Therefore they have independent voting.
- Ticket #229-A - this Overview over all related tickets
- Ticket #230-B - New module "USE mpi_f08"
- Ticket #231-C - Fortran argument checking with individual handles
- Ticket #232-D - Existing module "USE mpi" with argument checking
- Ticket #233-E - Deprecating include 'mpif.h'
- Ticket #234-F - Choice buffers through TYPE(*) DIMENSION(..) declarations
- Ticket #235-G - Corrections to "Problems Due to Strong Typing" (MPI-2.2 page 482)
- Ticket #236-H - Corrections to "Problems Due to Data Copying and Sequence Association" (MPI-2.2 page 482)
- Ticket #237-I - Corrections to "Problems Due to Fortran 90 Derived Types" (MPI-2.2 page 484)
- Ticket #238-J - Corrections to "A Problem with Register Optimization" (MPI-2.2 page 485)
- Ticket #239-K - IERROR optional
- Ticket #240-L - New syntax used in all three (mpif.h, mpi, mpi_f08)
- Ticket #241-M - Not including old deprecated routines from MPI-2.0 - MPI-2.2
- Ticket #242-N - Arguments with INTENT=IN, OUT, INOUT
- Ticket #243-O - status(MPI_STATUS_SIZE) array versus MPI_Status Fortran derived type
- Ticket #244-P - MPI_STATUS(ES)_IGNORE through optional argument
- Ticket #245-Q - Upper and lower case letters in new Fortran bindings
- Ticket #246-R - Asynchronous arguments
- Ticket #247-S - All new Fortran 2008 bindings - Part 1
- Ticket #248-T - All new Fortran 2008 bindings - Part 2
- Ticket #249-U - Alternative formulation for Section 16.2 Fortran Support
- Ticket #250-V - Minor Corrections in Fortran Interfaces
All these tickets are owned by Rolf Rabenseifner, Craig Rasmussen, and Jeff Squyres together.
Extended Scope
None.
History
Nomenclature:
- Implicit interface = Fortran interface without argument checking.[[BR]] This was already available in Fortran 77.
- Explicit interface = Fortran interface with argument checking.[[BR]] This requires at least Fortran 90.
- Both interfaces are independent of the input style (fixed format or free format).
MPI-1.0 - MPI-1.3 were based on Fortran77 interfaces.
In MPI-2.0 - MPI-2.2, all interfaces are "Fortran" interfaces.
In many cases, new Fortran 90 methods (e.g., KIND=....) are used.
Buffers are defined as <type> BUF(*), which isn't a Fortran notation.
The behavior is defined through the usage in implicit interfaces
(old Fortran77 style subroutine definitions).
All handles are defined as INTEGER.
MPI libraries are allowed to enable argument checking of MPI applications, as long as the application behaves as with implicit interfaces (i.e., no argument checking).
To enable argument checking, current MPI libraries use special non-standard options for the buffer arguments.
Another problem area is the handling of Fortran optimization together with nonblocking MPI routines.
Proposed Solution
Major goals of the New MPI-3 Fortran support are:
- Enabling full argument checking.
- Enhanced argument checking quality through the use of individually typed handles.
- New solutions for the optimization problem in conjunction with MPI nonblocking routines.
- Correction of wrong hints in the current MPI-2.2.
To achieve a high argument checking quality together with acceptable backward compatibility,
the new features require the use of a new module USE mpi_f08.
Parts of the features are also included in existing USE mpi.
Old style include 'mpif.h' is kept as deprecated and continues to offer
an old style interface with (old Fortran77) implicit interfaces.
Impact on Implementations
The C-based backend of MPI routines with buffers is doubled.
[[BR]]
Routines without buffer arguments can use the same interface for
the existing include 'mpif.h' and USE mpi and the new
USE mpi_f08.
Impact on Applications / Users
None, as long as the application uses already an MPI library with argument checking.
Applications that are not consistent with argument checking may require some
bug corrections. Those application bugs are semantically correct programs,
but syntactically wrong according to the definition of MPI.
If an application programmer does not resolve those application bugs,
he/she is still able to switch to deprecated include 'mpif.h
and to postpone the fixing of his/her application bugs.
Alternative Solutions
See inside of ticket descriptions.
Entry for the Change Log
See inside of ticket descriptions.
Originally by RolfRabenseifner on 2010-09-01 10:37:25 -0500
229-A: Overview over all related tickets## Description
This ticket gives an overview over all related new MPI-3 Fortran tickets. It is intended that they are independent or that the require-relation is only uni-directional. Therefore they have independent voting.
All these tickets are owned by Rolf Rabenseifner, Craig Rasmussen, and Jeff Squyres together.
'''The official draft SOLUTION is always the latest pdf attached to this ticket.'''[[BR]] Tickets #230-B through #253-X show only background information. The solutions in these tickets were frozen after 2011-03-26. '''The final solution is developped only in a tex-tree and published to the Forum through the pdf drafts, see attacments below.'''
Extended Scope
None.
History
Nomenclature:
MPI-1.0 - MPI-1.3 were based on Fortran 77 interfaces. In MPI-2.0 - MPI-2.2, all interfaces are "Fortran" interfaces. In many cases, new Fortran 90 methods (e.g.,
KIND=....) are used. Buffers are defined as<type> BUF(*), which isn't a Fortran notation. The behavior is defined through the usage in implicit interfaces (old Fortran 77 style subroutine definitions). All handles are defined asINTEGER.MPI libraries are allowed to enable compile-time argument checking of MPI applications, as long as the application behaves as with implicit interfaces (i.e., no compile-time argument checking).
To enable compile-time argument checking, current MPI libraries use special non-standard options for the buffer arguments.
Another problem area is the handling of Fortran optimization together with nonblocking MPI routines.
Proposed Solution
Major goals of the New MPI-3 Fortran support are:
To achieve a high compile-time argument checking quality together with acceptable backward compatibility, the new features require the use of a new
USE mpi_f08module. Parts of the features are also included in existingUSE mpi. Old styleinclude 'mpif.h'is kept and can continues to offer an old style interface with (old Fortran 77) implicit interfaces, but the use of 'mpif.h' is strongly discouraged.'''The official draft SOLUTION is always the latest pdf attached to this ticket.'''
-The final version for voting is:*
It contains the 2011-09-08 version plus the changes based on the reviews and read in Santorini and Chicago in Sep. + Oct. 2011:
Impact on Implementations
The C-based backend of MPI routines with buffers is doubled. [[BR]] Routines without buffer arguments can use the same interface for the existing
INCLUDE 'mpif.h'andUSE mpiand the newUSE mpi_f08.Impact on Applications / Users
None, as long as the application uses already an MPI library with compile-time argument checking. Applications that are not consistent with compile-time argument checking may require some bug corrections. Those application bugs are semantically correct programs, but syntactically wrong according to the definition of MPI. If an application programmer does not resolve those application bugs, he/she is still able to switch to
include 'mpif.hand to postpone the fixing of his/her application bugs.Alternative Solutions
See inside of ticket descriptions.
Entry for the Change Log
-See latest attached pdf file.*