Skip to content

Update to mpi_f08#1828

Open
J-Lentz wants to merge 14 commits intoNOAA-GFDL:mainfrom
J-Lentz:mpi_f08
Open

Update to mpi_f08#1828
J-Lentz wants to merge 14 commits intoNOAA-GFDL:mainfrom
J-Lentz:mpi_f08

Conversation

@J-Lentz
Copy link
Contributor

@J-Lentz J-Lentz commented Jan 23, 2026

Description
Update to the mpi_f08 version of MPI's Fortran API.

How Has This Been Tested?
Builds on C5 with ifx. Land model builds, runs, and reproduces answers with ifort. non-MPI version of the land model builds and runs on GFDL workstation with ifort.

Checklist:

  • My code follows the style guidelines of this project
  • I have performed a self-review of my own code
  • I have commented my code, particularly in hard-to-understand areas
  • I have made corresponding changes to the documentation
  • My changes generate no new warnings
  • Any dependent changes have been merged and published in downstream modules
  • New check tests, if applicable, are included
  • make distcheck passes

Jesse Lentz added 9 commits January 22, 2026 12:53
Change `use mpi` to `use mpi_f08` in drifters_comm_mod.
Migrate `metadata_transfer_mod` from `mpi` to `mpi_f08`.
Migrate MPP from the legacy mpi library to mpi_f08.
Deprecate mpp_commID(), which returns an integral communicator ID, in favor of
mpp_comm(), which returns an mpi_f08 communicator handle. Analogously,
all arguments of MPP procedures which take or return an integral
communicator ID have been deprecated in favor of new arguments which
take or return an mpi_f08 handle.
@J-Lentz J-Lentz marked this pull request as ready for review February 4, 2026 21:26
Copy link
Contributor

@rem1776 rem1776 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for working on this! I think its great to be using a more modern mpi module.

I think one thing we could think about later on is abstracting/wrapping the new mpi types within mpp, then we can use that type for the serial build too and not have as many ifdefs when the two build options diverge. This looks good though just left a couple smaller comments.

integer, optional, intent(in) :: flags !< Flags for debug output, can be MPP_VERBOSE or MPP_DEBUG
integer, optional, intent(in) :: localcomm !< Id of MPI communicator used to initialize
type(mpi_comm), optional, intent(in) :: comm !< Handle to the MPI communicator used to initialize
integer, optional, intent(in) :: localcomm !< ID of MPI communicator used to initialize (deprecated)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the comm argument name could bit confusing, maybe something like mpi_comm_type would be a bit more clear?

@@ -0,0 +1,130 @@
subroutine mpp_pset_create(npset,pset,stacksize,pelist,comm)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

needs a license header, also could you move the comments above the routine for the docs?

@@ -0,0 +1,120 @@
subroutine mpp_pset_create(npset,pset,stacksize,pelist)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

same comments as above

integer, parameter :: MPP_COMM_NULL = MPI_COMM_NULL
#else
integer, parameter :: MPP_COMM_NULL = 67108864
#endif
Copy link
Contributor

@rem1776 rem1776 Feb 25, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe instead of deleting these we could keep them but change them to the mpi_comm type? This should allow you to take out some of the ifdefs later on.

I think external code bases might be using these values instead of accessing the mpi module directly, not 100% sure though.

Copy link
Contributor

@rem1776 rem1776 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for working on this! I think its great to be using a more modern mpi module.

I think one thing we could think about later on is abstracting/wrapping the new mpi types within mpp, then we can use that type for the serial build too and not have as many ifdefs when the two build options diverge. This looks good though just left a couple smaller comments.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants