[MPI3 Fortran] Agenda for MPI3 Fortran Working group next week

[Supalov, Alexander]

Hi,

Thanks. I won't be at the Forum meeting this time (Keith will), so I am commenting right away below mostly from the MPI side.

Best regards.

Alexander 

-----Original Message-----
From: mpi3-fortran-bounces at lists.mpi-forum.org [mailto:mpi3-fortran-bounces at lists.mpi-forum.org] On Behalf Of Craig Rasmussen
Sent: Tuesday, June 02, 2009 7:28 PM
To: MPI-3 Fortran working group
Subject: [MPI3 Fortran] Agenda for MPI3 Fortran Working group next week

Jeff and I have worked out a list of items we need to discuss for next  
week.  The goal is to finalize things so that we can begin to put the  
API down in LaTex documents.  Some of this issues are pretty much  
resolved but we should go over them one more time.


1. Use of intent(IN/OUT/INOUT) for parameters.

These requires careful thought in some circumstances.  For example,  
should the Send/Recv and Isend/Irecv data buffers all be INOUT to keep  
the compiler for doing surprising things?

AS> Note also a possible bizzare connection to the const buffer modifier matter (#140, https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/140) that has been pushed back on by most MPI implementors and is likely to become an MPI-3 rather than MPI-2.2 topic. I don't think it would be good if different language bindings were to allow syntactically different things to happen.

2. Review of new MPI derived types to be used, for example,  
type(MPI_Comm).

AS> There's certain beauty in the integer handle approach of the current Fortran interface. It specifies pretty clearly that the meat of the object lives outside of the application. With the derived type, implementors might be tempted to put more than a handle into the application space, and then we may have issues with tools, compatibility between different MPI versions, etc.

3. How to handle MPI attributes and extra state variables.  This can  
be done in a very Fortran way as it doesn't have to look the MPI C.

AS> It would be better if the solution resembled C in some way. Having language bindings diverge too far from each other may not be good for usability, after all.

4. What should the name of the new module be.  We had discussed not  
changing the name, i.e.,

      USE MPI

However, users will have to explicitly change their code to use the  
new module so I don't see how we can get away with using the old  
module name.

AS> What about MPI3?

5. Review what integer kind should be used for things like tags.   
We've previously decided to use default integer kinds except for  
possibly for counts, in which case we would specify a specific kind,  
MPI_COUNT.

AS> Please look into #117 that already proposes MPI_COUNT_KIND (https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/117).

Any other issues?  Please let me know and I'll add it to the agenda.

-craig

_______________________________________________
mpi3-fortran mailing list
mpi3-fortran at lists.mpi-forum.org
http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran
---------------------------------------------------------------------
Intel GmbH
Dornacher Strasse 1
85622 Feldkirchen/Muenchen Germany
Sitz der Gesellschaft: Feldkirchen bei Muenchen
Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer
Registergericht: Muenchen HRB 47456 Ust.-IdNr.
VAT Registration No.: DE129385895
Citibank Frankfurt (BLZ 502 109 00) 600119052

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.