FMS mixed mode

[jiandewang]

this PR contains code change in MOM_diag_manager_infra.F90 to allow UFS to run with FMS mixed mode (MOM6 at 64 bites but fv3 at 32 bites), see detail at
NOAA-EMC#88
The purpose of this PR is asking MOM6 users to test the updated MOM6 code here with the current FMS being used in their system to make sure there will be no issue or answer change.

[junwang-noaa]

@sanAkel @thomas-robinson I want to clarify that we have tested the code updates in this PR with following fms versions:

2021.03
2021.04
2022.01
the mixed mode FMS version: https://github.com/NOaA-EMC/FMS/tree/fms_mixedmode.

In the latest ufs-weather-model develop branch, we are using MOM6 with the code updates (in EMC fork) with FMS 2021.04 and we are moving to the fms 2022.01 in the upcoming PR this week.

So committing this MOM6 PR does not require the FMS/dycore updates with mixed mode changes. Instead, once this PR is committed, we can move on to update FMS/dycore with mixed code code changes. When these mixed mode changes are committed/released, MOM6 group can update to the new FMS at their convenient time. Please let me know if you have any questions. Thanks

[jiandewang]

@sanAkel @thomas-robinson I want to clarify that we have tested the code updates in this PR with following fms versions:

2021.03 2021.04 2022.01 the mixed mode FMS version: https://github.com/NOaA-EMC/FMS/tree/fms_mixedmode.

In the latest ufs-weather-model develop branch, we are using MOM6 with the code updates (in EMC fork) with FMS 2021.04 and we are moving to the fms 2022.01 in the upcoming PR this week.

So this MOM6 PR does not have dependency on the mixed mode FMS code updates. Please let me know if you have any questions. Thanks

The purpose of this PR is asking users to test the updated MOM6 code with the current FMS being used in their system to make sure there will be no issue or answer change.

[thomas-robinson]

OK thanks everyone for moving this forward.

We originally slated these updates in FMS for 2022.01, but we ultimately could not take them because then the GFDL climate models would not be able to run with the latest FMS due to updates needed in FV3 and MOM6. All of the necessary changes need to be prepared at the same time, so we will update FMS when the other repositories are ready to update and the GFDL climate models will all be able to run with updated code.

[MinsukJi-NOAA]

@sanAkel and @MinsukJi-NOAA The merge NOAA-GFDL/FMS#898 was reverted because it needs to be coordinated with updates to MOM6 and GFDL_atmos_cubed_sphere.

pray @thomas-robinson, in that case, how should we be exercising the proposed changes in this PR?

We need to come up with a strategy for this. In FMS, I did

git revert 6c3d531c809238ae002c6daac15ea4cb905a7e78

But this created some conflicts that need to be resolved. I think we need an issue in FMS to discuss how to move forward in FMS. Then probably @MinsukJi-NOAA will need do the git revert above and bring the branch up to date with main.

I will look into reverting and bringing the mixed FMS up to date with GFDL main.
However, as @junwang-noaa pointed out, this is an issue that is separate from this MOM6 PR.

[junwang-noaa]

@thomas-robinson Thanks for the information. The changes in this PR are actually different from the original changes proposed for fms 2022.01 previously planned, which had dependency on the fms library. The changes here allow MOM6 to work with current fms versions and the fms version with fix mode updates. So MOM6 changes can be updated without updating fms.

[klindsay28]

It seems like this PR introduces some unneeded duplication of code, with multiple calls to send_data_fms that only differ in whether or not certain optional arguments are passed. It looks like these calls can be collapsed into a single call where the arguments are passed, relying on Fortran's feature of passing optional arguments through to subroutines and/or functions where they are optional, whether or not they are present. Or is there some reason to have the separate calls that I'm not seeing?

[MinsukJi-NOAA]

It seems like this PR introduces some unneeded duplication of code, with multiple calls to send_data_fms that only differ in whether or not certain optional arguments are passed. It looks like these calls can be collapsed into a single call where the arguments are passed, relying on Fortran's feature of passing optional arguments through to subroutines and/or functions where they are optional, whether or not they are present. Or is there some reason to have the separate calls that I'm not seeing?

These were due to compiler bugs (both intel and gnu) which were documented here:

• https://stackoverflow.com/questions/69690287/pass-fortran-unlilmited-class-optional-argument-down-multiple-subroutines-in-a-m
• https://stackoverflow.com/questions/69840797/pass-fortran-unlilmited-class-optional-array-argument-down-multiple-subroutines

[junwang-noaa]

@sanAkel @marshallward @kshedstrom @abozec @gustavo-marques May I ask if you have any question with this PR and when it can be committed? The UFS mix-mode project is waiting for the code changes to be committed in MOM6 so that we can move on with the FMS mixed mode PR. Thank you very much!

[marshallward]

@junwang-noaa Sorry for the long delay, we have no issue with the PR. We are still waiting on regression testing, but we will approve it after it passes (as we expect).

We were a bit concerned about the commit history but have decided today to accept it as-is, in order to allow EMC to preserve the history of its dev/emc branch.

However, we would like to follow up in the near future about potential strategies for management of commit histories across the groups. I will reach out soon to the repo maintainers with more information.

[abozec]

COAPS approves

[alperaltuntas]

NCAR test are passing.

[marshallward]

@gustavo-marques Just FYI that we only need one approval per group.

Note to maintainers that we still need approval from @sanAkel before merging.

[gustavo-marques]

Thanks, @marshallward. I approved because I am listed as one of the reviewers, but good to know.

[sanAkel]

@gustavo-marques Just FYI that we only need one approval per group.

Note to maintainers that we still need approval from @sanAkel before merging.

Thanks for your patience! I will try to get back by Monday next week.

[sanAkel]

This preserves answers for main on GEOSgcm; used FMS1. Thanks for your patience!

[marshallward]

This has been approved by everyone, so I will merge this on behalf of @jiandewang.

Thanks to everyone, and remember to update your branches!

[jiandewang]

thanks for everybody's time and effects to have this done.

[junwang-noaa]

Thank you all!