Fms mixedmode update

[MinsukJi-NOAA]

Description
This PR includes code changes to allow a single FMS library to handle running 32-bit FV3 and 64-bit MOM6 for the coupled UFS weather model. The approach taken to minimize the code changes is to assume FMS is compiled in 64 bit, and to only modify the interfaces to FV3.

How Has This Been Tested?

• Code changes pass the FMS CI tests (GNU) on GitHub Actions.
• UFS weather model regression tests have been successfully done using code changes in the previous PR Fms mixedmode #857
  • UFS weather model regression tests will be performed using the updated code changes in this PR

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

[thomas-robinson]

@ngs333 (and to some extent @uramirez8707 ), this is going to conflict with your development, especially in send_data. Do you think:

1. These updates can coexist with your updates? or
2. These updates will be replaced by your updates?
3. @ngs333 you deleted a lot of what this code updates. Do you foresee adding that code back in to maintain/support old behavior, or do you think what you've done will supersede these updates?

[thomas-robinson]

There are two merge conflicts with the current dmUpdate specifically in diag_manager.F90

git remote add gfdl https://github.com/NOAA-GFDL/FMS.git
git remote add emc https://github.com/NOAA-EMC/FMS.git
git fetch gfdl
git fetch emc
git checkout gfdl/dmUpdate
git merge emc/fms_mixedmode

There will be more conflicts when the send_data work is merged in
#979

[MinsukJi-NOAA]

There are two merge conflicts with the current dmUpdate specifically in diag_manager.F90

git remote add gfdl https://github.com/NOAA-GFDL/FMS.git
git remote add emc https://github.com/NOAA-EMC/FMS.git
git fetch gfdl
git fetch emc
git checkout gfdl/dmUpdate
git merge emc/fms_mixedmode

There will be more conflicts when the send_data work is merged in #979

Conflicts are in register_diag_field_scalar and register_diag_field_array functions. It seems that new functions register_diag_field_scalar_modern and register_diag_field_array_modern are being used. Maybe one way to move forward is to have the register_diag_field_scalar_old and register_diag_field_array_old in sync with emc fms_mixedmode register_diag_field_scalar and register_diag_field_array, respectively?

What are GFDL's plans are for *_modern and *_old functions down the road?

[thomas-robinson]

@MinsukJi-NOAA we should be able to resolve these conflicts because they seem relatively straight forward. The "old" and "modern" routines are going to co-exist for some time. We will move forward with our development based off of your updates.

[thomas-robinson]

@rem1776 We will merge in main and then merge this PR. We will tag this 2022.03-alpha1 and run testing.

[MinsukJi-NOAA]

@rem1776 @thomas-robinson I verified that functions register_diag_field_scalar_old and register_diag_field_array_old are the same as emc mixedmode register_diag_field_scalar and register_difag_field_array, respectively.

It also looks like send_data_3d is identical to the emc mixedmode send_data_3d.

[thomas-robinson]

@MinsukJi-NOAA We had a few more updates, but they should be minor. The check for range being size 2 was moved and there were some typos. Otherwise I think we are good

[thomas-robinson]

The changes to the diag manager are now in line with our diag manager development, and I think we can merge this.

[bensonr]

@binli2337 @MinsukJi-NOAA @junwang-noaa - as part of the 2022.02 FMS release, constants handling was rewritten to isolate the individual constants groups by laboratory/use. Please look at the new structure and propose a way to introduce the desired constant behavior/handling.

[MinsukJi-NOAA]

@binli2337 @MinsukJi-NOAA @junwang-noaa - as part of the 2022.02 FMS release, constants handling was rewritten to isolate the individual constants groups by laboratory/use. Please look at the new structure and propose a way to introduce the desired constant behavior/handling.

@bensonr Could you point out the hash where these changes to constants were made?

[bensonr]

@MinsukJi-NOAA - 16003bb

[junwang-noaa]

@bensonr I want to double check with you, my understanding is that in GFDL applications FMS will be compiled along with model code with corresponding compile options. So the mixed mode changes for constantsR4 have no impact on GFDL/GOES applications.

The constantR4 will only be added for the prebuilt FMS library in UFS. When running in mixed mode, dycore compiled with 32BIT=Y can still use the r4 constants. Will GFDL applications run in mixed mode coupled applications? What are the compile options for FMS you are going to use in this mixed mode runs?

[bensonr]

@junwang-noaa - the bottom line is it doesn't conform to the current programming and macros for constants within FMS. Being that FMS is a community library, it is not in our best interest to have conflicting approaches which could cause confusion and future issues. In my opinion, leaving all the constants in full precision and casting them to the appropriate precision in the various components would be the correct solution.

GEOS does have the desire (and I believe the capability) of running mixed-mode. GFDL's SHiELD model has always run with mixed-mode and the climate researchers have expressed interest in exploring the capability, but have concerns about conservation that need to be satisfied.

[junwang-noaa]

@bensonr Thanks for the explanation. Bin will update the constantR4 to follow the same structure. But in general when mixed model FMS is used in the mixed model coupled runs (fms is compiled in R8, dycore runs in 32BIT/mom6 runs on 64BIT), we will need the hard coded R4 constantsR4 module used in dycore. Constants module can be used in all other configurations (fms compiled in r4 (r8) and dycore runs in r4 (r8), or fms compiled in r8 and mom6/dycore run in r8).

[bensonr]

@binli2337 - you're still overcomplicated things here. You do not need to make copies of *_constants.h and hardcode them to use r4_kind. All you needed to do was set the definition of RKIND in fms_constants4.F90 and when it included *_constants.h, it would have the correct typing of the constants.

#define RKIND r4_kind