[mpiwg-abi] MPI Fortran ABI discussion scheduling and agenda

[Holmes, Daniel John]

Hi Jeff,

Do the calls to MPI_TYPE_SIZE really need to happen before MPI_INIT?

The use-case for “before” is that the user could refuse to call MPI_INIT if they get an answer they don’t like, but The MPI Way ™ for that is to initialise first, query the environment/situation, and then abort if desired.

The “after” approach works better with sessions as well.

#if USE_SESSIONS
MPI_Info_set(my_info, …); // set a new key “mpi_assert_abi_sizes” to “ILP64” (request/assert)
MPI_Session_init(my_info, &my_session);
MPI_Info_get(my_info, …); // ask about the ABI of the library that was loaded (query)
MPI_TYPE_SIZE(MPI_INTEGER, &size_of_fortran_integer);
If (BAD) MPI_Abort();
#else
// out-of-band, e.g. env var like mpi_mem_alloc_kinds (request/assert)
MPI_Init();
MPI_Info_get(MPI_INFO_ENV, …); // ask about the ABI of the library that was loaded (query)
MPI_TYPE_SIZE(MPI_INTEGER, &size_of_fortran_integer);
If (BAD) MPI_Abort();
#endif

Best wishes,
Dan.

From: mpiwg-abi <mpiwg-abi-bounces at lists.mpi-forum.org> On Behalf Of Jeff Hammond
Sent: Tuesday, August 29, 2023 4:18 PM
To: mpiwg-abi <mpiwg-abi at lists.mpi-forum.org>; MPI Forum <mpiwg-fortran at lists.mpi-forum.org>
Subject: Re: [mpiwg-abi] MPI Fortran ABI discussion scheduling and agenda

Terse minutes from the meeting follow.  Please correct the record if I have made an error.  Thanks to everyone who attended (I didn't transcript it, but at least Jeff H, Quincy K, Bill W, Bill L, Ken R, Julien J, Joseph S, Christian N, M Klemm, and Abraham N were there).

Decision 1:

The sizes of Fortran types is part of the MPI ABI and each choice/combination of these requires a separate implementation.  The stipulation that the user must use exactly one of these throughout the application extends to the Fortran sizes.

Rationale: Every other option is extremely difficult to implement and unpleasant to reason about.  If we figure out a more compact way to solve this problem, we can standardize it in the future.  The O(n) solution is practical because today no implementation implements n>2.

Corollary 1:

There is one mpi.h, one libmpi_abi.so and one of each for the Fortran modules (and header, if supported) for every MPI C+Fortran ABI.  If an implementation provides more than one MPI C+Fortran ABI, the implementation should distinguish them using paths.

Decision 2:

The sizes prescribed by the external32 specification are required to be supported in the ABI.  All other sets of sizes are optional.

Corollary 2:

User code must do one of the following:
1. Assume the external32 ABI.  If wrong SO is linked, that's a user error and bad things will happen.
2. Query the Fortran size ABI to ensure that the MPI SO matches the Fortran object code, and abort if they don't match.
2. Query the Fortran size ABI to ensure that the MPI SO matches the Fortran object code, and handle any differences manually, e.g. using MPI_INTEGER8 instead of MPI_INTEGER.

Corollary 3:

MPI_Type_size must be callable before MPI_Init for all predefined datatypes (and only predefined datatypes), because this is how a user can detect potential ABI problems.

If people don't like this, then I'll add MPI_Abi_type_sizes that meets the need, without supporting the generality of MPI_Type_size.

Jeff

On Fri, Aug 25, 2023 at 11:35 AM Jeff Hammond <jeff.science at gmail.com<mailto:jeff.science at gmail.com>> wrote:
We need to meet to discuss some of the open problems with the MPI Fortran ABI.

https://www.when2meet.com/?21032099-f9qjp

The agenda is https://docs.google.com/document/d/1URUIbHhGQfUcoNg_KTX1lhWS-Z80LwJA9LH2QL7HCuo/edit?usp=sharing.  You'll need to request access to comment/edit because this email list is public and I do not want to deal with vandalism.

Jeff

--
Jeff Hammond
jeff.science at gmail.com<mailto:jeff.science at gmail.com>
http://jeffhammond.github.io/


--
Jeff Hammond
jeff.science at gmail.com<mailto:jeff.science at gmail.com>
http://jeffhammond.github.io/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpi-forum.org/pipermail/mpiwg-abi/attachments/20230829/12ec7f58/attachment-0001.html>