Fms mixedmode

[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 run on Hera using Intel compiler with expected results
  • 64 bit tests all reproduce the baseline
  • 32 bit tests complete, but do not reproduce the baseline

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: make -k check resulted in no FAIL or ERROR on Hera platform with intel and impi 2020.2

[MinsukJi-NOAA]

I am looking into why additional file changes are showing up in the PR.

[MinsukJi-NOAA]

I am looking into why additional file changes are showing up in the PR.

This issue is resolved and the PR is ready for review.

[MinsukJi-NOAA]

Based on EMC's testing with the coupled UFS weather model, MOM6 requires the following one file changes in order to successfully call send_data routines in diag_manager: NOAA-EMC/MOM6#79

[MinsukJi-NOAA]

Dycore running in 32 bit requires the code changes made here: https://github.com/NOAA-EMC/GFDL_atmos_cubed_sphere/tree/fms_mixedmode

[rem1776]

I added some comments in the code that apply to routines throughout but the biggest thing is to have class default with error calls to make sure any invalid non-real types can't be passed in to any public routines, as well as checking the kind sizes match up when needed.

The new constants4 directory should probably be added to the autotools build system as well. You can probably just copy over the Makefile.am from the original constants folder to constants4 with a few minimal changes to the file/library names, and then just add them to the root Makefile.am and configure.ac.

[MinsukJi-NOAA]

Code changes (9242fe4) were made to address the reviewer's comments. Checking if all class(*) arguments are of the same real kind is done only if these arguments are used together (see sat_vapor_pres_k.F90). Otherwise, if each argument is used by itself, only case default is done for each argument.

[thomas-robinson]

There are 5 themes for my change requests (I used the *4 and *8 format for shorthand):

1. I am slightly worried about implicit casting generating warnings. Per the style guide, new code must not generate any new warnings. There is a lot of

real :: r
class(*) :: x
select type (x)
  type is (real*4)
    r = x
  type is (real*8)
    r = x
end select

What happens if these types don't match? Will there be a warning? Are these guaranteed to match, and will the compiler know that?
2. This should be 1.1 because it's basically the same thing. There is code that looks like

class(*) :: x
select type (x)
  type is (real*4)
    x = 100.
  type is (real*8)
    x = 100.
end select

I think you want to make sure your values are represented correctly. You either need to include the correct amount of digits after the decimal, use an e or d, or cast the number to the correct precision

class(*) :: x
select type (x)
  type is (real*4)
    x = 100.e0
  type is (real*8)
    x = 100.d0
end select

I think this should work
3. As someone who has had to deal with a vague "unsupported type" as an error, I am very impartial to using something that lacks detail as an error message. The error message should at a minimum say that the type of the variable is not real(kind=4) or real(kind=8) and it must be changed. You don't have to have the variable name like I added for each error message if you want to do a large replace, but please make the error messages more descriptive.
4. Where you check multiple variables to see if their types match, you need a different error message. Those variables could be supported kinds, but they are not matching which causes an error. Again, you don't need the variable names like I included, but you should have something that better explains the error.
5. All of the new variables need to be documented with doxygen. Most of the new variables is valid_types. I think I have a sed command you could use to add the comments for valid_types, but you should make sure it works.

sed -i 's/logical :: valid_types = .false./logical :: valid_types = .false. !< For checking if variable types match/g' *

[thomas-robinson]

There are 5 themes for my change requests (I used the *4 and *8 format for shorthand):

1. I am slightly worried about implicit casting generating warnings. Per the style guide, new code must not generate any new warnings. There is a lot of

real :: r
class(*) :: x
select type (x)
  type is (real*4)
    r = x
  type is (real*8)
    r = x
end select

What happens if these types don't match? Will there be a warning? Are these guaranteed to match, and will the compiler know that?
2. This should be 1.1 because it's basically the same thing. There is code that looks like

class(*) :: x
select type (x)
  type is (real*4)
    x = 100.
  type is (real*8)
    x = 100.
end select

I think you want to make sure your values are represented correctly. You either need to include the correct amount of digits after the decimal, use an e or d, or cast the number to the correct precision

class(*) :: x
select type (x)
  type is (real*4)
    x = 100.e0
  type is (real*8)
    x = 100.d0
end select

I think this should work
3. As someone who has had to deal with a vague "unsupported type" as an error, I am very impartial to using something that lacks detail as an error message. The error message should at a minimum say that the type of the variable is not real(kind=4) or real(kind=8) and it must be changed. You don't have to have the variable name like I added for each error message if you want to do a large replace, but please make the error messages more descriptive.
4. Where you check multiple variables to see if their types match, you need a different error message. Those variables could be supported kinds, but they are not matching which causes an error. Again, you don't need the variable names like I included, but you should have something that better explains the error.
5. All of the new variables need to be documented with doxygen. Most of the new variables is valid_types. I think I have a sed command you could use to add the comments for valid_types, but you should make sure it works.

sed -i 's/logical :: valid_types = .false./logical :: valid_types = .false. !< For checking if variable types match/g' *

[MinsukJi-NOAA]

@thomas-robinson I believe all raised issues have been addressed.

Regarding the r4-r8 conversion issue, the following approach has been taken.

When a real local variable is copied onto a class(*) dummy argument with intent(out):

subroutine test(x)
  class(*), intent(out) :: x
  real :: a
  ...
  select type (x)
  type is (real(4))
    x = real(a, kind=4)
  type is (real(8))
    x = a
  end select
  ...
end subroutine test

When a class(*) dummy argument with intent(in) is copied onto a real local variable:

subroutine test(x)
  class(*), intent(in) :: x
  real :: a
  ...
  select type (x)
  type is (real(4))
    a = x
  type is (real(8))
    a = real(x)
  end select
  ...
end subroutine test

[thomas-robinson]

@MinsukJi-NOAA please check the boxes at the top of the PR indicating at you have done a self check and performed all of the tasks. If a box is not applicable, please check it anyway. Once that's done, we can merge and begin testing.

[MinsukJi-NOAA]

@MinsukJi-NOAA please check the boxes at the top of the PR indicating at you have done a self check and performed all of the tasks. If a box is not applicable, please check it anyway. Once that's done, we can merge and begin testing.

@thomas-robinson Do I need to bring this branch up to date with GFDL's FMS main branch? Right now, this branch includes the changes up to Dec 13, 2021 (6b12cb5).

[rem1776]

@thomas-robinson Do I need to bring this branch up to date with GFDL's FMS main branch? Right now, this branch includes the changes up to Dec 13, 2021 (6b12cb5).

None of the current main's changes conflict with this PR, so you don't have to. I'll merge this in now.