[MPI3 Fortran] Agenda for MPI3 Fortran Working group next week
alexander.supalov at intel.com
Wed Jun 3 06:35:38 CDT 2009
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.
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,
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.,
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
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,
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.
mpi3-fortran mailing list
mpi3-fortran at lists.mpi-forum.org
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.
More information about the mpiwg-fortran