Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make Fortran datatypes unavailable if no Fortran compiler #1

Open
jsquyres opened this issue Mar 4, 2016 · 4 comments
Open

Make Fortran datatypes unavailable if no Fortran compiler #1

jsquyres opened this issue Mar 4, 2016 · 4 comments

Comments

@jsquyres
Copy link
Member

jsquyres commented Mar 4, 2016

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
Copy link
Member Author

jsquyres commented Mar 4, 2016

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
Copy link
Member Author

jsquyres commented Mar 5, 2016

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
Copy link
Member Author

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
Copy link
Member Author

jsquyres commented Apr 23, 2016

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

  • MPI_F_STATUS[ES]_IGNORE
  • MPI_F08_STATUS[ES]_IGNORE
  • What will MPI_*_F2C and MPI_*_C2F return?
    • Or should these functions -- and MPI_Fint -- not be declared?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant