[MPI3 Fortran] Request for a straw vote.

[Craig Rasmussen]

We made a lot of progress today on prospective MPI-3 interfaces for  
Fortran.  Since not everyone was able to attend the MPI Forum meeting,  
I'd like to open the issues up for a straw vote.  Everyone may vote or  
otherwise express their opinion as this isn't an official Forum vote.   
I've formed the vote in terms of a question and an answer.  If you  
agree with the answer, vote yes.  Otherwise vote no and please give  
the reason why along with a suggested alternative.

I should note that I personally haven't participated in the resent  
discussions because I've been on travel to foreign lands.

-craig

---------------

Issues to straw vote:

1. Q: Should intents be specified in the MPI-3 interfaces?
    A: Yes, specifying intent in the Fortran interfaces helps the user  
to understand the call (it may also help the compiler with  
optimization).

2. Q: Should derived types be used in place of some MPI handles that  
are currently integers?  For example, TYPE(MPI_Comm).
    A: Yes, the use of specific types enhances type safety.

3. Q: What type should be specified for the extra_state and value  
parameters in MPI_Comm_create_keyval and MPI_Comm_attr_set?
    A: TYPE(C_PTR).  Use of C_PTR allows the MPI implementation to  
store the address of the Fortran type and the user to subsequently  
associate a Fortran pointer with the stored C_PTR with a call to  
C_F_POINTER.
    NOTE: C addresses are to be obtained using C_LOC which requires  
the target attribute on the actual argument.  This warns the compiler  
that MPI may store (alias) the extra_state or value parameters.

4. Q: What should the name of the MPI-3 module be?
    A: MPI3 to distinguish it from the current MPI module.
    Unresolved Issue: A consensus was not reached on this question.   
An alternative is to use module names MPI2, MPI3, ..., as well as  
MPI.  If "USE MPI" is used, the MPI vendor will allow the module to be  
chosen with a compile time option specifying the location of the MPI  
module.

5. Q: Should default integer kinds be used for most integer parameters?
    A: Yes, this has not caused problems in the past and will have the  
least impact on existing code.
    NOTE: A specified kind, MPI_COUNT_KIND will be used for buffer  
count arguments.

6. Q: How should type and rank be specified for buffer choice arguments?
    A: TYPE(*), DIMENSION(..)
    NOTE: This has been vetted by the Fortran J3 standards committee.   
MPI vendors will use the Fortran descriptor interface.
    Unresolved Issue 1: Will this block the compiler from using copyin/ 
copyout?

7. Q: Are vendors allowed to provide a different actual interface in  
the MPI-3 module for TYPE(*), DIMENSION(..) as a workaround until  
compilers catch up.
    A: Yes, if possible.
    Unresolved issue: Can existing IGNORE TKR compiler directives be  
used instead?

8. Q: Should the value attribute be given to some parameters?
    A: No, it would be different from current semantics (though more  
true to the C interface) and there is no need to make the change.   
Specify intent instead.

9. Q: What syntax should be specified to inhibit aggresive compiler  
optimizations associated with asynchronous MPI calls.
    A: Used the Fortran asynchronous attribute on dummy variables.
    NOTE: The MPI-3 standard will need to make clear that there are  
requirements on the user to get this correct.

10. Q: Should specific Fortran interfaces be specified in the MPI-3  
standard?
     A: Yes, this is preferable to use of <type> in the current  
standard.  While <type> is shorted, specific Fortran interfaces  
provide greater clarity for users.

11. Q: Should the F77 and F90 interfaces be deprecated?
     A: Yes.
     NOTE: Old interface descriptions should be moved to an appendix.

12. Q: Is it an error if the user gives a non-contiguous buffer to a  
choice argument as it is for C?
     A: Yes.
     Unresolved issue:  Should the vendor be required to catch the  
error as always checking the argument is a performance issue.

13. Q: Should mixed MPI-3 and older MPI code be compatible within the  
same application.
     A: Yes, this allows a gentler transition path to MPI-3 if the  
user doesn't have to convert all of this code at once.
     NOTE: This will require conversion routines between, for example,  
integer handles and MPI-3 typed handles.  This would allow a  
TYPE(MPI_Comm) to be converted to an integer and passed to code in a  
user's older Fortran library.