Open jsquyres opened 8 years ago
At the Feb 2016 Forum meeting, I was asked to reach out to MPI IO people and see what they thought of this. I just got a reply from Scot Breitenfeld at the HDF group (note: "the one he mentions" is where I mentioned the downside of a Fortran-enabled MPI writing an MPI IO file and then a non-Fortran-enabled MPI trying to read that file):
Other than the one he mentions, I don’t see any other downsides. I’m not sure it is far to compare to the C++ implementation, because C and C++ have common native types and this is never the case with Fortran and C. Fortran in no way resembles C++. So it makes sense to me that Fortran is handled differently than the C++ implementation. It does no harm having it, but it can cause problems by not having it, so I’m not clear on the reasons for removing it other than code clean-up. But, I guess if MPI_INTEGER is not valid when there is no Fortran compiler (or can be wrong), then it should be removed in that case.
Another reply, this time from @qkoziol:
BTW, your scenario about writing a file with MPI_INTEGER elements seemed like it may be flawed because of a couple of issues: there’s (probably) no self-description in the file saying that the elements are MPI_INTEGER, and also (even if there were) there’s no way to tell which FORTRAN implementation wrote them (and therefore what the definition of MPI_INTEGER was when they were written).
Slides presented in the March 2016 MPI Forum meeting in Chicago.
Straw votes from that meeting:
#define MPI_NO_GOT_INTEGER_SORRY 1
)
After the meeting, it was pointed out that the following should also be removed:
MPI_F_STATUS[ES]_IGNORE
MPI_F08_STATUS[ES]_IGNORE
MPI_*_F2C
and MPI_*_C2F
return?
MPI_Fint
-- not be declared?
Per the February 2016 Chicago MPI Forum meeting, slides were presented asking what to do when there are no Fortran bindings in an MPI implementation: should the Fortran datatypes be available in mpi.h or not?
This issue adds text to remove all Fortran datatypes from mpi.h when there is no Fortran support (just like MPI-3.1 does with C++). The result both modified some text and shifted some text around in section 3.2.2.
The attached PDF shows both the original 3.1 language in both section 3.2.2 and A.1.1, and then the resulting text after the change. The changed text did some unfortunate things with table placement; I'm assuming a LaTeX wizard can make this look better.