<div dir="ltr">
From MPI 3.1, page 674:<div><br></div><div>"If an accompanying C++ compiler is missing, then the MPI datatypes in this table are not defined."</div><div><br></div><div>Please tell me why we want to do something different for Fortran.</div><div><br></div><div>While we do not currently say "If an accompanying Fortran compiler is missing, then the MPI datatypes in this table are not defined," as a footnote to the appropriate table, that is not a good reason to define something brittle. Let's just add the footnote and call it good.</div><div><br></div><div>Users that expect Fortran features without a Fortran compiler are like people who try to withdraw money from a bank where they do not have an account. Both types of people are criminals :-)</div><div><br></div><div>Jeff<br><br>On Thu, Feb 18, 2016 at 7:10 AM, Jeff Hammond <<a href="mailto:jeff.science@gmail.com">jeff.science@gmail.com</a>> wrote:<br>><br>> The only reasonable thing to do here is to include MPI_INTEGER and other Fortran datatype enumerations in the meaning of Fortran bindings and not define them in the absence of a Fortran compiler. Any other solution is unreliable, ill-defined and going to lead to sadness.<br>><br>> More below.<br>><br>> On Thu, Feb 18, 2016 at 3:45 AM, Jeff Squyres (jsquyres) <<a href="mailto:jsquyres@cisco.com">jsquyres@cisco.com</a>> wrote:<br>> ><br>> > A question has come up recently in the Open MPI community (being debated in a lengthy thread here <a href="https://www.open-mpi.org/community/lists/users/2016/02/28448.php">https://www.open-mpi.org/community/lists/users/2016/02/28448.php</a>):<br>> ><br>> > If Fortran support is not provided in an Open MPI installation (e.g., if Open MPI's configure script detects that there is no Fortran compiler, and therefore none of the mpif.h, mpi module, or mpi_f08 module are compiled), should Fortran datatypes (e.g., MPI_INTEGER) be available in the C bindings?<br>> ><br>> > It was pointed out that MPI-3.1 says that the Fortran bindings are optional -- but datatypes are not currently marked as optional.<br>> ><br>> > Hence, even if you don't have to Fortran compiler, you still have to have declarations for MPI_INTEGER (and friends) in mpi.h.<br>> ><br>> > What do people think about this?<br>> ><br>> > ARGUMENTS FOR KEEPING IT THE SAME<br>> > =================================<br>> ><br>> > A1. MPI can set MPI_INTEGER to be equivalent to MPI_DATATYPE_NULL.<br>><br>> I will repeat what I said on the Open-MPI list. THIS IS HORRIBLE. It delays the failure until runtime. There is absolutely no value whatsoever in allowing a successful build of an application that is going to crash and burn the moment it touches this datatype, particularly in light of our discussion about a month ago regarding when MPI_DATATYPE_NULL can be used (basically never).<br>><br>> I do not want MPI implementations to lie to build systems about the availability of MPI_INTEGER in C when it is not actually a functional feature.<br>><br>> Additional reasons: Jed Brown. PETSc. <<< This is here for Jed's email filters.<br>> <br>> > A2. MPI could probably figure out what Fortran INTEGER would have been (i.e., probably equivalent to C int) and just set MPI_INTEGER to be that.<br>><br>> This is also horrible, because Fortran INTEGER does not have fixed width. Here is what ISO Fortran 2008 says about INTEGER:<br>><br>> "The processor shall provide at least one representation method with a decimal exponent range greater than or equal to 18."<br>><br>> Please explain the unambiguous mapping between this definition and the definition of ISO C int.<br>> <br>> ><br>> > A3. The whole point of having Fortran datatypes available in C is that even an MPI process written in C can receive/send data from MPI processes in Fortran. Hence, *this* MPI process -- compiled by an MPI implementation that does not have a Fortran compiler -- may not have Fortran support, but a peer MPI process in the same MPI job may have Fortran support.<br>><br>> Such a process cannot send or receive Fortran INTEGER data because it has no idea the size of such data.<br>><br>> This sort of use case is best supported by sending and receiving the data as bytes, because the no-Fortran process can understand that.<br>><br>> Alternatively, the Fortran processes can use ISO_C_BINDING and convert to C datatypes before sending. Since we have standardized the use of Fortran 2008 in MPI-3, there is absolutely no reason why this should not be the recommended practice, because it is completely reliable and well-defined.<br>><br>> > ARGUMENTS FOR A CHANGE<br>> > ======================<br>> ><br>> > B1. Setting MPI_INTEGER (and friends) to MPI_DATATYPE_NULL -- which will cause a run-time MPI exception -- is somewhat anti-social behavior (and potentially confusing to the user).<br>><br>> See above.<br>><br>> > B2. An MPI implementation can *assume* but can't *know* what the size/representation of Fortran datatypes are unless there's a Fortran compiler with which to test.<br>><br>> You know what happens when you assume, right?<br>><br>> What possible value does it serve to guess? We create a situation where sometimes it works and sometimes MPI programs crash and burn? While we are at it, let's add MPI_Barrier_sometimes(double randomness_factor)...<br>><br>> > B3. A3 is a somewhat sketchy claim. It's obviously possible and valid, but fairly uncommon to have multiple MPI implementation installations involved in a single execution of an MPI application.<br>><br>> It is valid to have multiple implementations, but not valid to expect processes that use a Fortran-oblivious MPI library to understand Fortran data.<br>><br>> Jeff <br>><br>> --<br>> Jeff Hammond<br>> <a href="mailto:jeff.science@gmail.com">jeff.science@gmail.com</a><br>> <a href="http://jeffhammond.github.io/">http://jeffhammond.github.io/</a><br>><br><br><br><br>--<br>Jeff Hammond<br><a href="mailto:jeff.science@gmail.com">jeff.science@gmail.com</a><br><a href="http://jeffhammond.github.io/">http://jeffhammond.github.io/</a><div class="gmail_extra">
</div></div></div>