Note that the only change you have to make to stop using mpif.h is to remove include mpif.h and add use mpi. Sadly, you can’t just do this with line substitution because use comes before implicit none while include comes after. The mpi module is API compatible with mpif.h so no other source code changes should be required, unless you are doing something wrong and only getting away with it because mpif.h can’t check anything.
Everyone should move use mpi_f08 but that requires source code changes and there is no automated tool to convert to its API yet.
The ABI standardization effort is expected to have a large impact on the MPI ecosystem. The hope is that excluding mpif.h from it motivates Fortran users to use modern MPI support. I want to exclude it because not doing so forces us to rely on COMMON in the ABI definition, which has been obsolescent since Fortran 90.
Jeff, this may need clarification. The title question asks if the deprecated mpif.h should be supported. But the question immediately before the poll element asks if we’d be willing to switch to the mpi module. These two seem contrary.
I am not familiar with internals of MPI implementations, so I have a few questions:
What is an ABI support? So that you can switch different MPI implementations at runtime? MPI does not support this, but it will (except possibly mpif.h)?
I think mpif.h should not be used, maybe you can create a poll just to ask if people still need mpif.h, or if they can upgrade?
A separate question is about upgrading mpif.h. It seems no new codes should use common blocks. Something is fundamentally wrong if that is required, and so I would rather focus our effort on fixing that.
If people will switch to the MPI module, then it is easy to not support the ABI in mpif.h. There is no contradiction. There is a literal causal relationship between the two queries.
" Will you switch to the API-equivalent mpi module ?" is the poll question. Can you tell me how that is different from what you suggest? I am asking if they will upgrade.
We need a global variable to create a buffer address sentinel. Because mpif.h is included after implicit none, it cannot have use MPI in it, which would address this. Therefore, we must use COMMON if mpif.h is used.
Technically, it doesn’t have to declare any subroutines, because Fortran doesn’t require those declaration, but the types and constants have to be in the module. In any case, this should not be a problem anymore and even if it was, I wouldn’t hamstring the MPI standard because some implementer isn’t doing their job.
Actually, this is a very important point: any Fortran module (including the mpi module) has to have those subroutine and function definitions. If it doesn’t, then you rely on implicit typing, which is discouraged from about 1990. It’s the same feature level like the common block. Neither should be used for new codes.
Since you are involved in MPI standardization, I would think it should be required to provide those procedure definitions.
They are required in MPI_F08 because it’s actual possible to do it there. We cannot require in MPI (module) because without Fortran 2008 type(*), dimension(..), it cannot be done. The MPI module uses nonstandard extensions like ignore_tkr in order to accommodate Fortran without 2008 features. That’s why some implementations just omit them.