<div><div dir="auto">To help aid in the depreciation of mpif.h, perhaps Cray/HPE can contribute a source-to-source translation tool that can be recommended to the MPI user community.</div><div dir="auto"><br></div><div dir="auto">Jeff</div></div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jul 10, 2020 at 9:54 AM Bill Long via mpiwg-fortran <<a href="mailto:mpiwg-fortran@lists.mpi-forum.org">mpiwg-fortran@lists.mpi-forum.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)"><br>
<br>
> On Jul 10, 2020, at 11:11 AM, Jeff Squyres (jsquyres) <<a href="mailto:jsquyres@cisco.com" target="_blank">jsquyres@cisco.com</a>> wrote:<br>
> <br>
>> <br>
>> 2) \begin{unpopular} Why are the legacy mpi module and mpif.h still included in the spec?  These are embarrassingly obsolete.  If this was fixed, none of the above mentioned conversion routines would be needed.  \end(unpopular}<br>
> <br>
> <br>
> I would love it if we could ditch -- at a minimum -- mpif.h.<br>
> <br>
> However, there's oodles of legacy code out there that uses it.  That's why even deprecating it gets shouted down at Forum meetings.<br>
<br>
We have the same discussions in the Fortran committee about deleting things, or at least making them “obsolescent”, which seems functionally similar to deprecated in MPI.   In the end, we specify certain archaic and now-redundant features as deleted with full knowledge that implementors will not remove the capabilities from compilers because of old codes.  However, the Intent is to guide programmers writing new code in the direction of using the new (hopefully better) alternatives.  And, relevant to the present discussion, deleting certain old stuff makes the standard document cleaner. <br>
<br>
Fundamentally, MPI is a C library.  Other languages, like C++ and Python, don’t require separate bindings specified in the MPI spec  because they can call C library routines.  The whole mpi_f08 module exercise was to demonstrate that Fortran can now do the same.  The whole idea of specifying a separate Fortran MPI interface needs to be rethought.  Perhaps something like<br>
<br>
“This version of MPI specifies the contents of a vendor-required Fortran module for MPI that allows access to the underlying C specification.  The separate language binding for Fortran has been deleted, but is still available for historical reference in the MPI-3 and earlier specifications.”<br>
<br>
That should allow for a significant simplification of the MPI specification document. <br>
<br>
<br>
Cheers,<br>
Bill<br>
<br>
<br>
Bill Long                                                                       <a href="mailto:longb@cray.com" target="_blank">longb@cray.com</a><br>
Principal Engineer, Fortran Technical Support &   voice:  651-605-9024<br>
Bioinformatics Software Development                      fax:  651-605-9143<br>
Cray, a Hewlett Packard Enterprise company/ 2131 Lindau Lane/  Suite 1000/  Bloomington, MN  55425<br>
<br>
<br>
<br>
_______________________________________________<br>
mpiwg-fortran mailing list<br>
<a href="mailto:mpiwg-fortran@lists.mpi-forum.org" target="_blank">mpiwg-fortran@lists.mpi-forum.org</a><br>
<a href="https://lists.mpi-forum.org/mailman/listinfo/mpiwg-fortran" rel="noreferrer" target="_blank">https://lists.mpi-forum.org/mailman/listinfo/mpiwg-fortran</a><br>
</blockquote></div></div>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature">Jeff Hammond<br><a href="mailto:jeff.science@gmail.com" target="_blank">jeff.science@gmail.com</a><br><a href="http://jeffhammond.github.io/" target="_blank">http://jeffhammond.github.io/</a></div>