[MPIWG Fortran] Topics to discuss

[Bill Long]

On 12/11/13 7:03 PM, Jeff Hammond wrote:
> On Wed, Dec 11, 2013 at 6:40 PM, Jeff Squyres (jsquyres)
> <jsquyres at cisco.com> wrote:
>> I think we have 3 topics to discuss:
>>

Maybe 4.

>> 1. MPI_Arecv: Rolf posted a reply, and I think it's mostly sufficient.  But there might still be an issue or three to discuss.
>>
>> 2. MPI_Aint functions
>>
>> 3. What's the plan for deprecating mpif.h in MPI-4?
>
> Just do it.  Do it now.

Since Jeff S. knows that I was in favor of *deleting* this in MPI 3.0, 
no surprise I agree.  It's been 20+ years that a better alternative 
(modules) has existed.   The source code changes in applications are 
simple (trivial) to switch to using a module.

>
> I think we should deprecate without intent to delete but rather to
> prevent F77-like semantics from hamstringing us forever, i.e. not
> create new features with F77 bindings ala C++ in MPI-2.2+.
>
>> 4. Do we want to deprecate the mpi module?  This is a complex issue.
>
> Yes.  No, it's not :-)

I'm in the middle here. It is a bigger user change to move from the mpi 
module to the mpi_f08 module because user variable types have to be 
changed. That can be a lot more work, and less mechanical, than the 
transition from mpif.h to using a module.

However, the use of INTEGER arguments is the only relevant feature of 
the mpi module that is worth preserving for user convenience (as much as 
I dislike using default INTEGER declarations).    The rest of the mpi 
module could/should be modernized to make it more like the mpi_f08 
module, including:

a) TYPE(*) declarations for choice buffer arguments
b) DIMENSION(..) attribute for choice buffer arguments
c) ASYNCHRONOUS attribute for choice buffer arguments where relevant
d) OPTIONAL arguments, particularly for the ierror argument
e) INTENT specifications for arguments

I think it is desirable that people still using the mpi module should be 
able to take advantage of the other improvements that came with mpi_f08. 
  In addition, these changes would make the two module sources a lot 
more similar, simplifying maintenance.

I realize that this sort of change would reduce the motivation for users 
of the mpi module to move to the mpi_f08 module, which is a potential 
marketing issue.   Perhaps that could be balanced with a "no new MPI 4.0 
  features/routines supported" rule for the mpi module.

>
>> Should we webex next week to discuss these things?
>
> Sure but my calander is very colorful already.  We might need Doodle.

Being in vacation for all of December except next Tuesday-Friday has put 
a lot of meetings into those days, so it might be a challenge. Worse, 
the IT people think I need a new laptop, so I may be in configuration 
hell for part of next week. (I'm keeping the old one during the 
transition, though. It's just a matter of yet another time sink.) 
Doodle, definitely, and I'd likely not fill it in until Tuesday.

Cheers,
Bill


>
> Jeff
>
>> --
>> Jeff Squyres
>> jsquyres at cisco.com
>> For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/
>>
>> _______________________________________________
>> mpiwg-fortran mailing list
>> mpiwg-fortran at lists.mpi-forum.org
>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran
>
>
>

-- 
Bill Long                                           longb at cray.com
Fortran Technical Support    &                 voice: 651-605-9024
Bioinformatics Software Development            fax:   651-605-9142
Cray Inc./Cray Plaza, Suite 210/380 Jackson St./St. Paul, MN 55101