Enabling WRF build with ESMF library

[negin513]

TYPE: Bug Fix / New Feature

KEYWORDS: ESMF library, WRF-ESMF coupling, Compiling WRF with ESMF library, Linking WRF with ESMF library, WRF ESMF time manager

SOURCE: Negin Sobhani (NCAR) with contributions from William Sacks (NCAR)

DESCRIPTION OF CHANGES:
Previously it was not possible to build WRF with a specific ESMF library due to the name conflicts between WRF internal ESMF interfaces with the intended ESMF library. This PR enables users to compile WRF to build and link against an intended ESMF library, without any collisions with WRF internal ESMF interfaces. In this PR we simply rename all WRF's ESMF interfaces to avoid the names conflicts. This PR is especially important for any user who wants to use WRF with ESMF for coupling.

The purpose of this modification is the eventual use of the new CTSM with WRF. Please see the CTSM github page for more information.

ISSUE: Fixes issue #1065 "Building WRF with ESMF library"

LIST OF MODIFIED FILES:
M external/esmf_time_f90/ESMF_Alarm.F90
M external/esmf_time_f90/ESMF_AlarmClock.F90
M external/esmf_time_f90/ESMF_Base.F90
M external/esmf_time_f90/ESMF_BaseTime.F90
M external/esmf_time_f90/ESMF_Calendar.F90
M external/esmf_time_f90/ESMF_Clock.F90
M external/esmf_time_f90/ESMF_Mod.F90
M external/esmf_time_f90/ESMF_Stubs.F90
M external/esmf_time_f90/ESMF_Time.F90
M external/esmf_time_f90/ESMF_TimeInterval.F90
M external/esmf_time_f90/Meat.F90

TESTS CONDUCTED:

• Demonstrate bit-wise identical results - NOT YET
• OK on jenkins reg test
• The developer of the COAWST modeling system has reviewed the
  proposed modifications. They do not cause any troubles for their coupled usage of WRF.

RELEASE NOTE: By changing the names of the older ESMF modules in the WRF source code (for example, from ESMF_AlarmMod to WRF_ESMF_AlarmMod), the WRF model may now be built with released ESMF library versions.

[negin513]

@billsacks This is the PR for renaming WRF ESMF internal interfaces to enable building and linking WRF with our ESMF library.

[davegill]

@negin513
Negin,
This is an engineering change that you are proposing, you should be able to get identical results with a before vs after test. We only need about 10 time steps. Use the external/io_netcdf/diffwrf utility on the respective model output files. We tend to find that we need to build the code with the debug switch (./configure -d) for this bit-wise comparison to work. If you use the GNU compiler, edit the configure.wrf file before issuing the ./compile em_real command (set the switch for FAST RRTMG from 1 to 0).

[davegill]

@negin513
Negin,
A ping. We are trying to wrap up the code for a release very soon. I am looking for a before vs after demonstration of bit-wise identical results.

[negin513]

@davegill I just tested the before and after of this PR for 10 timesteps and the results were bit-for-bit identical.

[davegill]

@kkeene44
Kelly,
This PR needs a review from basically you and only you.

I have done the regression testing (all is OK), Negin has verified bit-reproducible results before vs after the change, and the COAWST developer that uses WRF and ESMF for coupling has signed-off on this PR also.

When you look at the the mods, you will see that the entire set of changes is just to rename each of the WRF versions of the "pretend" ESMF module names with something other than the "real" ESMF names (which causes troubles with name space collision when using the actual ESMF library.

[milancurcic]

I applaud this PR because I've been running sed s/ ESMF_/ WRF_ESMF_/gi over esmf_time_f90/*.F90 on various WRF versions since 2011. Happy to see this is slated for the 4.2 release.

So I checked out the release-v4.2 branch as I saw that this commit made it in there. However, one issue still lingers for me. I use this program to confirm that I can import ESMF and WRF stuff into the same namespace:

program test_use_wrf_with_esmf
  use ESMF
  use module_wrf_top, only: wrf_init, wrf_run, wrf_finalize, head_grid
end program test_use_wrf_with_esmf

With ESMF 8.0.0, WRF release-v4.2, and gfortran-9.3.0, I get:

test_use_wrf_with_esmf.f90:3:6:

    3 |   use module_wrf_top, only: wrf_init, wrf_run, wrf_finalize, head_grid
      |      1
Fatal Error: Mismatch in components of derived type ‘esmf_fraction’ from ‘esmf_fractionmod’ at (1): expecting ‘shallowmemory’, but got ‘n’
compilation terminated.

This error comes up because there is still one remaining conflict, due to the ESMF_FractionMod in external/esmf_time_f90/ESMF_Fraction.F90 still being called that, and not namespaced to WRF_.

The fix is straightforward:

sed -i 's/ESMF_FractionMod/WRF_ESMF_FractionMod/gi' external/esmf_time_f90/{ESMF_Fraction,ESMF_Mod,ESMF_TimeInterval,Meat}.F90

Would you like a PR for it?

[davegill]

@milancurcic

Would you like a PR for it?

Milan,
YES!

Please clone the wrf-model/WRF fork, and checkout the release-v4.2 branch. Do a "checkout -b" to get to your own, new branch (but based from release-v4.2). Make the modification, and push it up to your fork. Issue a pull request.

We are trying to get a release out in a week or so, so please hurry if you can.