To be fair, Microsoft just doesn't have resources left over for MPI after all they've been putting into making sure nobody in China learns about Tiananmen Square.
"Smith, Barry F. via petsc-dev" <[email protected]> writes: > MS-MPI has in their include file > > #define MPI_VERSION 2 > #define MPI_SUBVERSION 0 > > Their last release was Oct 2018 > https://docs.microsoft.com/en-us/message-passing-interface/microsoft-mpi-release-notes > > They also don't provide a mpi.mod file though they do provide mpif.h and > Fortran stubs in their library see the discussion at > https://bitbucket.org/petsc/petsc/pull-requests/1666/error-and-stop-configure-if-the-mpi-module/diff > > As a side note, Microsoft's C compiler also does not support all of C99 :-) > > > >> On May 24, 2019, at 5:23 PM, Jeff Hammond via petsc-dev >> <[email protected]> wrote: >> >> No, it's really not better to keep it. MPI 2.2 support is ubiquitous. It >> has been 10 years, which is 1-2 lifetimes of an HPC system or PC. Anybody >> who insists on using an MPI library that doesn't support 2.2 should accept >> that they must use a version of PETSc from 2018 or earlier. >> >> In the HPC space, MPI 3.0 has been available on most machines for 5+ years. >> The last platform that I used that didn't have MPI 2.2 support was IBM Blue >> Gene/P and all of those machines were taken offline long ago. As of SC18, >> the MPI 3.1 support matrix (see below) is essentially complete and the only >> feature that PETSc would need to test for is MS-MPI's lack of neighborhood >> collectives. >> >> I am aware that people are using Open-MPI 1.10 in production today. These >> people are bad. Don't allow their poor life choices to force the pollution >> of PETSc source code with unnecessary macros. >> >> https://lists.mpi-forum.org/pipermail/mpi-forum/2014-June/006086.html <- MPI >> 3.0 >> https://lists.mpi-forum.org/pipermail/mpi-forum/2016-November/006532.html <- >> MPI 3.1 >> https://lists.mpi-forum.org/pipermail/mpi-forum/2018-November/006783.html <- >> MPI 3.1 >> >> Jeff >> >> On Fri, May 24, 2019 at 2:15 PM Zhang, Junchao via petsc-dev >> <[email protected]> wrote: >> PetscSF has many PETSC_HAVE_MPI_REDUCE_LOCAL. It is disturbing. But consider >> the time gap between MPI-2.0 (1998) and MPI-2.2 (2009), it is better to keep >> it. >> >> >> On Fri, May 24, 2019 at 3:53 PM Jed Brown <[email protected]> wrote: >> "Zhang, Junchao" <[email protected]> writes: >> >> > How about stuff in MPI-2.2 (approved in 2009), the last of MPI-2.x, e.g., >> > PETSC_HAVE_MPI_REDUCE_LOCAL? >> >> Currently we only require MPI-2.0, but I would not object to increasing >> to MPI-2.1 or 2.2 if such systems are sufficiently rare (almost >> nonexistent) in the wild. I'm not sure how great the benefits are. >> >> > On Fri, May 24, 2019 at 2:51 PM Jed Brown via petsc-dev >> > <[email protected]<mailto:[email protected]>> wrote: >> > Lisandro Dalcin via petsc-dev >> > <[email protected]<mailto:[email protected]>> writes: >> > >> >> These two are definitely wrong, we need PETSC_HAVE_MPI_XXX instead. >> > >> > Thanks, we can delete both of these cpp guards. >> > >> >> include/petscsf.h:#if defined(MPI_REPLACE) >> > >> > MPI-2.0 >> > >> >> src/sys/objects/init.c:#if defined(PETSC_USE_64BIT_INDICES) || >> >> !defined(MPI_2INT) >> > >> > MPI-1.0 >> >> >> -- >> Jeff Hammond >> [email protected] >> http://jeffhammond.github.io/
