[MPI3 Fortran] Request for a straw vote.

[Lionel, Steve]

Here's my take on the various questions, with input from Alexander Supalov (Intel).

Steve Lionel
Intel Developer Support
Nashua, NH



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

[sl] Yes, but care must be taken that the INTENT specifiers accurately map to how MPI treats the argument (and also making sure that the Fortran meaning of INTENT matches!)

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.

[sl] Yes, as an "opaque" type (with PRIVATE component(s))

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.

[sl] I think more evaluation from an MPI usage perspective needs to be applied to this one.  From a Fortran perspective, I'm not in favor of a direct use of C_PTR, but the alternatives don't feel better.  I see that extra_state is defined in the C interface as void*, so perhaps what is really wanted here is "TYPE(*),DIMENSION(..)", but we get into that later.  If C_PTR is to be used here then why not also for the BUF arguments? 

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.

[sl] Yes.

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.

[sl] Yes, but there seems to be a misunderstanding among some.  I think what we are discussing is how the arguments should be documented in the spec.  This documentation needs to include the kind the same way that the C programmer needs to know whether to use int, long or whatever. The lazy Fortran programmer can often get away with using default integer if that kind happens to match what is expected, but many compilers allow the default integer kind to be changed (-i8, etc.), which can wreak havoc.

I feel that the spec should specify the kind.  It could be done with specific MPI_KIND values or those taken from ISO_C_BINDING.  The actual module must use the correct kind values and the programmer will be encouraged to do so as well.  Old code that matches the kinds will still work - programmers will not be forced to add explicit kinds except when it's not default.

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?

[sl] You need some notation in the spec to explain to the programmer what she should put in her code.  No matter what you say here, you're going to have to explain it because there is no current Fortran standard syntax for this concept.  TYPE(*), DIMENSION(..) is not even in an approved TR yet - I would not call it "vetted", though it has gone through several reviews and committee votes.  The risk of using syntax not yet in a published standard or TR is that it MIGHT change.  We (former DEC) have been burned by this in the past: the no-parentheses form of PARAMETER in F77 which changed right at the end, after we had already implemented it.

To the best of my knowledge, use of this syntax does not stop copyin/out.  That should be dealt with separately.

Personally, I lean towards a <any-type-and-shape> notation as it won't lead readers to start with their Fortran documentation to figure out what this means.  That said, it is not a strong lean and if this usage perhaps encourages vendors to support it early, recognizing the risks, that is goodness.

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?

[sl] Again, we are (I think) discussing the spec.  The nuts and bolts of how it is implemented by vendors should be left unspecified, as long as a program written to the spec works.

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.

[sl] VALUE and INTENT are different concepts.  If this is a pure Fortran interface, I see no value in VALUE.  If we're writing interfaces to C routines, then VALUE might be required.

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.

[sl] Yes, given that we have no other tool for the purpose, but I know there are strong feelings about this one.

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.

[sl] No, if what you mean is spelling out all the combinations of type and shape that can be used for a given routine.  That will be overwhelming and ultimately LESS clear.

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

[sl] As long as the reader can find the old interfaces, that's fine. I am not in favor of "deleting" old interfaces.

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.

[sl] Yes, it is an error.  It would be nice for compilers to diagnose this, but Fortran 2003 does not provide a "hook" for them to do so.  Fortran 2008 includes a CONTIGUOUS attribute which can be used for this purpose.   I think it would be useful to include CONTIGUOUS in the list of attributes for arguments that must be contiguous.  It would be implementation-dependent if such an attribute actually got used.

Note that CONTIGUOUS can't be used with C_PTR, but note that Fortran 2008 allows C_LOC of a POINTER array that has the CONTIGUOUS attribute.

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.

[sl] Yes.