mpiwg-p2p / p2p-issues

Repository to discuss internal P2P working group issues
3 stars 0 forks source link

Make Fortran datatypes unavailable if no Fortran compiler #1

Open jsquyres opened 8 years ago

jsquyres commented 8 years ago

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.

jsquyres commented 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.

jsquyres commented 8 years ago

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).

jsquyres commented 8 years ago

Slides presented in the March 2016 MPI Forum meeting in Chicago.

Straw votes from that meeting:

  1. If an MPI implemenetation has no support for Fortran bindings, should there be Fortran datatypes declared in mpi.h?
    • Yes: 4
    • No: 14
    • Abstain: 10
  2. If we remove the Fortran datatypes from mpi.h when there is no Fortran compiler, how should we remove them?
    • Remove them altogether from mpi.h (i.e., no MPI_INTEGER in mpi.h): 24
    • Make the datatypes be exactly equivalent to MPI_DATATYPE_NULL (as a compile-time constant): 3
    • Make the datatypes be invalid, but not necessarily exactly equivalent to MPI_DATATYPE_NULL (i.e., implementation can detect / prettyprint): 0
    • Abstain: 2
  3. Should we add macros saying that the datatypes are not there (e.g., #define MPI_NO_GOT_INTEGER_SORRY 1)
    • Yes: 20
    • No: 2
    • Abstain: 8
jsquyres commented 8 years ago

After the meeting, it was pointed out that the following should also be removed: