MPI: Fortran working group

The Fortran working group of MPI is currently on hold: MPI 4.1. I don’t know what is required to activate it, but maybe someone is interested to find out.

2 Likes

That is quite strange. Does anyone know in detail what being “on hold” mean?

This is just a guess but I suspect “on hold” means they cant find enough folks willing to participate to form a critical mass.

Getting feedback on Fortran is challenging. Not enough Fortran developers attend meetings or monitor the GitHub issues. Help with this is welcome. At present many working group meetings are online. There are a few other distributed memory parallel programming options for Fortran, including co-arrays.

Wow that’s weird. I would believe most Fortran codes still being run out there are MPI ones. I’ve never seen a survey, but I would bet MPI codes are the vast majority compared to co-arrays codes.

1 Like

Very few people who develop Fortran codes participate in the meetings. For example the following workshop on RMA FoRMA'22: The First Workshop on the Future of MPI RMA | FoRMA'22 continues today in a few minutes.

1 Like

Thank you for the link. I am myself an avid MPI-Fortran developer, but still pretty basic on the abstraction standpoint - in other words, I tend to be doing all the complex communication abstractions on the Fortran side rather than with the MPI library.

One simple reason is to achieve maximum backward compatibility, i.e., to be able to compile all the way back to mpif.h versions of MPI-Fortran

1 Like

mpif.h looks like it will be deprecated, use mpi will need to be used. Maintenance considerations and new features being introduced that are difficult to support using Fortran 77. However, simply changing those lines should enable most codes to work if a new compiler is used.

1 Like

Does that mean MPI will drop support for Fortran?

I’m aware of that but let me make an example: MS Windows + gfortran + MPI, the only way to do it is to use MS-MPI, but since gfortran is not supported by it, using the old-style mpif.h headers is necessary (they’re still like the original MPICH2 headers, and they have bugs BTW)

But should progress be determined by the slow adopters? Microsoft would have the resources to position Windows as a OS for multi-core applications but they focus on other things: Microsoft Could Soon Let You Play Solitaire On Teams Between Office Meetings :grimacing:

3 Likes

I think it’s a feedback loop, like always. Samewise for Modern Fortran features: are the users preventing them from being more widely adopted, or the compilers that don’t implement all of them soon enough, or a combination of the two?

In the case of Fortran MPI support, I think the true disaster is that module files are not standardized, so if say MS wanted to give its MS-MPI library broad compiler support, it’d need tens of different module versions, versus 1 C header file

3 Likes

I would also think that open-source software (think the GNU compiler suite, that I’m a huge fan of!) is funded by companies that benefit from it; Fortran compilers are historically commercial products, maybe large companies prefer using them, rather than contributing to open-source projects by funding them?

I agree. I’m working in academia and it is fully accepted to pay license fees for software. Even with the discount that one gets the sums can get quite high. But don’t dare to request 10 Eur as a donation for an open source project…

2 Likes

Fujitsu has done a lot to support development of Flang as they base their compiler on it. Companies that sell compute hardware also often support compiler and other software development. Many academics also write open source software. A culture change is needed, which may be more difficult in more established and conservative fields.

1 Like

A lot of HPC is done on Linux, so MS MPI efforts are probably not so high on the agenda, but it is open source and available at GitHub - microsoft/Microsoft-MPI: Microsoft MPI - the last commit is from someone who is very knowledgeable in MPI. Another option is to use the Windows Subsystem for Linux.

I find it interesting that Fujitsu relies on Classic Flang (based on PGI Fortran) instead of LLVM F18 / Flang. But at the time of writing, looks like AMD and Arm also ships Classic Flang-based Fortran compilers, which are AMD AOCC flang and Arm armflang, respectively. I have access to Fujitsu compilers through access to Ookami system at Stony Brook University, but haven’t toyed much with it yet.

Agreed, looks like WSL2 is the way to go moving forwards. I don’t think MS-MPI even supports MPI 3.0 yet, let alone newer standards…

Classic Flang is a complete (except for some recent features) Fortran compiler. LLVM Flang is still under development. Presumably all of the compilers based on Classic Flang will move to LLVM Flang eventually, but it’s not ready yet.

Here is a link to our compiler conformance tables. https://www.fortranplus.co.uk/app/download/30202489/compiler_support_fortran_2008_and_2018_standards.pdf As clang is based on PGI it is probably missing quite a few 2008 features - here is the info for PGI (41 yes, 1 yes with notes, 24 no, 1 partial with notes and 12 no information out of 79) and PGI is missing all but 5 of the 104 features in the 2018 standard.