Fail on MOM6 test "test-macos-stencil" for recent code change to MOM_coupler_types.F90.

[chrisb13]

Context: We’ve got a few MOM6 changes that we are looking to ‘release internally’ soon. Some of the changes will likely be a mom-ocean PR. Currently, some of the changes fail on the MOM6 tests (we are however able to compile this on our system*). @dougiesquire's one for allowing generic tracers in NUOPC cap is failing (code changes to our fork here; failing result [1]).

After some forensics (i.e. brute force), there are two relevant files:

1. config_src\infra\FMS2\MOM_couplertype_infra.F90 – has “use coupler_types_mod” statements
2. src\framework\MOM_coupler_types.F90 – has “use MOM_couplertype_infra” statements

Basically, 1 above imports selected variables from here (coupler_types.F90 FMS library hash f61416f; further details [2]), and then 2 uses imports from 1. In many cases this works fine but for some reason, some variables do not work.

tl;dr
As a distilled example, we have these two cases where A passes and B fails:
A: passes because “ind_kw” is imported via coupler_types.F90;
B: fails [3] because “ind_kw” is imported via MOM_couplertype_infra.F90.
(Thanks to @micaeljtoliveira for the help to sort this out!)

@marshallward / all, any ideas?

*probably due to a different FMS version/build environment.

[1]

mpifort -DPACKAGE_NAME=\"MOM6\" -DPACKAGE_TARNAME=\"mom6\" -DPACKAGE_VERSION=\"\" -DPACKAGE_STRING=\"MOM6\" -DPACKAGE_BUGREPORT=\[https://github.com/NOAA-GFDL/MOM6/issues\](https://github.com/NOAA-GFDL/MOM6/issues/) -DPACKAGE_URL=\[https://github.com/NOAA-GFDL/MOM6\](https://github.com/NOAA-GFDL/MOM6/) -DHAVE_MPI=1 -DSETJMP_NAME=\"setjmp\" -DLONGJMP_NAME=\"longjmp\" -DSIGSETJMP_NAME=\"sigsetjmp\" -DSIGLONGJMP_NAME=\"siglongjmp\" -DHAVE_MPI=1 -DSIZEOF_JMP_BUF=192 -DSIZEOF_SIGJMP_BUF=196 -g -O0 -Wextra -Wno-compare-reals -fbacktrace -fcheck=bounds -finit-real=snan -finit-integer=2147483647 -finit-derived -I/Users/runner/work/MOM6/MOM6/.testing/build/deps/include -I/opt/homebrew/Cellar/netcdf-fortran/4.6.1_1/include -fdefault-real-8 -fdefault-double-8  -c /Users/runner/work/MOM6/MOM6/src/framework/MOM_coupler_types.F90 
  /Users/runner/work/MOM6/MOM6/src/framework/MOM_coupler_types.F90:14:33:
  
     14 | use MOM_couplertype_infra, only : ind_runoff, ind_deposition
        |                                 1
  Error: Symbol 'ind_runoff' referenced at (1) not found in module 'mom_couplertype_infra'

[2]
Looking at ‘Run /./.github/actions/testing-setup’ > ‘Compile FMS library’ > HEAD is now at f61416fe Merge pull request #529 from NOAA-GFDL/2019.01.03-release-in-progress, i.e., HERE.

[3]

mpifort -DPACKAGE_NAME=\"MOM6\" -DPACKAGE_TARNAME=\"mom6\" -DPACKAGE_VERSION=\"\" -DPACKAGE_STRING=\"MOM6\" -DPACKAGE_BUGREPORT=\"[https://github.com/NOAA-GFDL/MOM6/issues\](https://github.com/NOAA-GFDL/MOM6/issues/)" -DPACKAGE_URL=\"[https://github.com/NOAA-GFDL/MOM6\](https://github.com/NOAA-GFDL/MOM6/)" -DHAVE_MPI=1 -DSETJMP_NAME=\"setjmp\" -DLONGJMP_NAME=\"longjmp\" -DSIGSETJMP_NAME=\"sigsetjmp\" -DSIGLONGJMP_NAME=\"siglongjmp\" -DHAVE_MPI=1 -DSIZEOF_JMP_BUF=192 -DSIZEOF_SIGJMP_BUF=196 -g -O0 -Wextra -Wno-compare-reals -fbacktrace -fcheck=bounds -finit-real=snan -finit-integer=2147483647 -finit-derived -I/Users/runner/work/MOM6/MOM6/.testing/build/deps/include -I/opt/homebrew/Cellar/netcdf-fortran/4.6.1_1/include -fdefault-real-8 -fdefault-double-8  -c /Users/runner/work/MOM6/MOM6/src/framework/MOM_coupler_types.F90 
  /Users/runner/work/MOM6/MOM6/src/framework/MOM_coupler_types.F90:12:33:
  
     12 | use MOM_couplertype_infra, only : ind_kw
        |                                 1
  Error: Symbol 'ind_kw' referenced at (1) not found in module 'mom_couplertype_infra'
  /Users/runner/work/MOM6/MOM6/src/framework/MOM_coupler_types.F90:27:16:
  
     27 | public :: ind_kw
        |                1
  Error: Symbol 'ind_kw' at (1) has no IMPLICIT type; did you mean 'ind_flux'?

[marshallward]

I tried to replicate in 9af8a78, but I got a very different error in the generic tracers:

/home/marshall/gfdl/mom6/src/tracer/MOM_generic_tracer.F90:24:62:

   24 |   use generic_tracer, only: generic_tracer_coupler_accumulate, generic_tracer_update_from_coupler
      |                                                              1
Error: Symbol 'generic_tracer_update_from_coupler' referenced at (1) not found in module 'generic_tracer'

I have a feeling that you guys have a patch somewhere to get around this one.

---

I then tried 06501d1 and was able to build locally. Some of the tests did fail, but we can talk about that later.

Is this the one which fails on the GitHub CI?

The GitHub Actions CI is set to use FMS 2023.03 with the FMS2 API. I noticed that you updated the FMS2 infra but not the FMS1 infra. But I also see a lot of references to 2019.01.03, which was usually the version we used to test the FMS1 infra. Could there be an FMS1/FMS2 mixup here?

[anton-seaice]

I have a feeling that you guys have a patch somewhere to get around this one.

Yes - thats in our generic tracers. See NOAA-GFDL/ocean_BGC@main...ACCESS-NRI:GFDL-generic-tracers:main

The GitHub Actions CI is set to use FMS 2023.03 with the FMS2 API. I noticed that you updated the FMS2 infra but not the FMS1 infra. But I also see a lot of references to 2019.01.03, which was usually the version we used to test the FMS1 infra. Could there be an FMS1/FMS2 mixup here?

Thanks @marshallward - sounds like that is at least part of the problem. The MacOS tests use FMS1 which maybe hasn't been implemented for the changes to generic tracers.

[chrisb13]

Thanks @marshallward, @anton-seaice.

I then tried 06501d1 and was able to build locally. Some of the tests did fail, but we can talk about that later.

Is this the one which fails on the GitHub CI?

Yes, 06501d1 is the commit I was looking to fix. a34bd62 is the commit that highlighted the problem with a toy problem.

The GitHub Actions CI is set to use FMS 2023.03 with the FMS2 API. I noticed that you updated the FMS2 infra but not the FMS1 infra. But I also see a lot of references to 2019.01.03, which was usually the version we used to test the FMS1 infra. Could there be an FMS1/FMS2 mixup here?

Good thought! That is the problem. Swapping over FMS to 2023.03 in the toy problem works, as does the whole commit here. As such, this closes my 'issue'.

So the question then... I've readjusted the MacOS test to use a different FMS version. Is that a problem? In other words, do we need to keep FMS 2019.01.03 compatibility?

[anton-seaice]

It looks like it was set intentionally, see NOAA-GFDL#642

Maybe it has be resolved in the interim ? Saying that, I think the real question is does the generic tracers implementation need to work with FMS1 to get merged into MOM-ocean ? (I vaguely recall @dougiesquire mentioning this at some point, I feel like we didn't think it was a priority).

[marshallward]

I had forgotten about that! We might be able to revert it back to an FMS2-compatible version, if the underlying problem has been fixed in GCC 14.2.

However, we do expect config_src/infra/FMS1 and config_src/infra/FMS2 to implement the same API, so the PR would still be expected to duplicate the changes in config_src/infra/FMS1.

The implementation does not need to be fully featured. It only needs to be enough to ensure that the code compiles and legacy FMS1-based tests continue to run. It might be OK to add a "not yet implemented" MOM_error call if it makes sense.

Is it important to continue supporting the FMS1 API? Well, that is a discussion for the Monday dev call, and ACCESS is welcome to make its case 😁.

[dougiesquire]

Note I've fixed these issues in the PRcandidate-202502-gtracer-nuopc branch. I never bothered to change the FMS1 API in our build using patch files, but our MOM_couplertype_infra.F90 patch should be applied to both config_src/infra/FMS1 and config_src/infra/FMS2.