SFCLAY=1, add shallow water roughness calculation

[hawbecker]

TYPE: new feature

KEYWORDS: shallow water, roughness, bathymetry

SOURCE: Patrick Hawbecker, Pedro A. Jiménez, and Jimy Dudhia (NCAR)

DESCRIPTION OF CHANGES:
This incorporates the shallow water drag module into the revised M-O surface layer scheme for over-water roughness calculation.

The new scheme is meant to incorporate the effects of roughness increasing over shallower waters (less than 100 m deep), mostly near coastlines. In order to include the shallow water roughness parameterization from Jiménez and Dudhia (2018) into the revised M-O surface layer scheme, a bathymetry dataset was downloaded and converted to the WPS tiled format, new variables and flags for the bathymetry data and which scheme is to be used over the ocean are added, and the source code is included into a module with module_sf_sfclayrev.F.

The bathymetry data is open source from GEBCO Compilation Group (2021) GEBCO 2021 Grid (doi:10.5285/c6612cbe-50b3-0cff-e053-6c86abc09f8f). Several checks are included to ensure users without the bathymetry data can still run with this new scheme using a namelist-defined variable (shalwater_depth) to designate the bathymetry over all water cells. If users have bathymetry data, they can run with this scheme (shalwater_z0 = 1; shalwater_depth <=0) or overwrite the bathymetry data with a user-defined value (shalwater_depth > 0).

LIST OF MODIFIED FILES:
M Registry/Registry.EM_COMMON
M dyn_em/module_first_rk_step_part1.F
M dyn_em/module_initialize_real.F
M dyn_em/nest_init_utils.F
M dyn_em/start_em.F
M phys/module_physics_init.F
M phys/module_sf_sfclayrev.F
M phys/module_surface_driver.F
M run/README.namelist
M share/module_check_a_mundo.F
M share/module_optional_input.F
M test/em_real/namelist.examples

TESTS CONDUCTED:
Tests were conducted in 2 phases: within (1) real.exe and (2) wrf.exe.

1. Real.exe tests conducted:
   

For the case producing a warning (no bathymetry, shalwater_z0 = 1.0, shalwater_depth <= 0.0), the following
warning is presented in rsl.error.* files:

Warning: No bathymetry data found for shallow water roughness model.
Warning: shalwater_depth must be greater than 0.0 for WRF to run.

The tests all performed as expected producing the following results for the WATER_DEPTH variable:

With incorrect namelist settings (use shallow water roughness drag, sfclay scheme other than revised MO):

--- ERROR: The shallow water roughness drag only works with sfclay_physics = 1
             Turn off the shallow water option, or change the surface layer scheme
-------------- FATAL CALLED ---------------
FATAL CALLED FROM FILE:  <stdin>  LINE:    2513
NOTE:       1 namelist settings are wrong. Please check and reset these options

2. The tests performed for wrf.exe are as follows:
   
   The depth = 0.0 case produces the following error message:

No bathymetry data detected and shalwater_depth not greater than 0.0. Re-run WPS to get bathymetry data 
or set shalwater_depth > 0.0

The remaining cases produce WATER_DEPTH fields as follows:

After running these cases for 36 hours and discarding the first 12 hours as model-spinup. The averaged field
(output every 2 hours) for ZNT and wind speed can be seen to show the expected impacts from the new
scheme. When the true bathymetry is used, ZNT is higher for depths between 10 and 100 m (green lines).
However, when a constant shalwater_depth is used, the value is set over the whole domain and ZNT is
increased (in this case) over all water cells. Additionally, when shalwater_depth is set to a valid number, it will
overwrite the bathymetry data within wrf.exe and produce the same result as if you did not have bathymetry
data.

Additionally, in order to remain consistent with the lake model (sf_lake_physics > 0) we allow water_depth to
be overwritten by lake_depth if sf_lake_physics > 0:

3. The code passed bit-for-bit check and restart test.

RELEASE NOTE: The shallow-water roughness scheme from Jiménez and Dudhia (2018) is included for offshore roughness adjustment in water depths between 10 and 100 m. The bathymetry data is open source from GEBCO Compilation Group. Please acknowledge the following in presentations and publications: GEBCO Compilation Group (2021) GEBCO 2021 Grid (doi:10.5285/c6612cbe-50b3-0cff-e053-6c86abc09f8f).
Jiménez, P. A., & Dudhia, J. (2018). On the need to modify the sea surface roughness formulation over shallow waters. Journal of Applied Meteorology and Climatology, 57(5), 1101-1110, DOI: 10.1175/JAMC-D-17-0137.1

[dudhia]

Need @davegill to help identify regtest failures - likely NMM compilation.

[weiwangncar]

@phawbeck If you'd like to try to compile NMM, instructions are available from
https://www2.mmm.ucar.edu/wrf/users/supports/support.html. Look for 'Code Preparation and Testing Requirement' in the section for developers. Likely the new variables are either to be added to the NMM registry, passed along the 'pipeline', or declared optional in the code and used for ARW only.

[smileMchen]

@phawbeck
If we run a case with, for example shalwater_rough = 1 and shalwater_depth = 50, does this indicate that the water depth is 50m everywhere? Thanks.

[hawbecker]

@phawbeck If you'd like to try to compile NMM, instructions are available from
https://www2.mmm.ucar.edu/wrf/users/supports/support.html. Look for 'Code Preparation and Testing Requirement' in the section for developers. Likely the new variables are either to be added to the NMM registry, passed along the 'pipeline', or declared optional in the code and used for ARW only.

Perfect - I will go ahead and try to compile NMM and see what the issues are. Thanks!

[hawbecker]

@phawbeck
If we run a case with, for example shalwater_rough = 1 and shalwater_depth = 50, does this indicate that the water depth is 50m everywhere? Thanks.

That is correct - setting shalwater_rough = 1 tells WRF you want to run with this parameterization, then shalwater_depth = [some number greater than 0] will define the water depth over all water cells as this value. If you have shalwater_depth set to a value less than or equal to 0.0 and you have bathymetry data, then it will use the bathymetry data.

[smileMchen]

@phawbeck
Thanks for the clarification.

[hawbecker]

Hi - I am just checking to see what the status of this is. I noticed that the checks now say they have passed, but I was not able to compile NMM on my initial attempt but I can give it another go if needed. Thanks a lot!

[weiwangncar]

@phawbeck Not sure why it says the checks have passed. If no change has been made to the code since you submitted it a while back, it shouldn't. But we sometimes the automatic tests go haywire...

[weiwangncar]

@phawbeck No need to work on making the code to compile NMM. We will drop NMM support in 4.4.

[hawbecker]

@weiwangncar great - thanks a lot! So is there anything else I should do about this? Or am I good to just sit and wait :-)

[weiwangncar]

@phawbeck Basically, yes. But I do have a question: it seems that you have access to a bathymetry dataset. Can that be shared with the community? What is the resolution of the data?

[davegill]

@phawbeck @weiwangncar @dudhia

1. We probably need mods to share/module_check_a_mundo.F so that only the sfclay=1 tries to use these options. Do we want a stop, or a message that this is not being used? Opinions Wei and Jimy?
2. Since there are new namelist vars, let's put some descriptions in test/em_real/examples.namelist and run/README.namelist.
3. How does the namelist option for depth work? Is it an on/off flag, or do you set a depth?
4. Outside the scope of this PR ... what is the status of getting the bathymetry into the WPS static data tar files?
5. Would you add the DOI to the publication (I moved the reference to the RELEASE NOTES section).

[dudhia]

some of this was addressed as README.namelist is updated even though not listed in the PR.

…

On Tue, Sep 14, 2021 at 12:03 PM Dave Gill ***@***.***> wrote: @phawbeck <https://github.com/phawbeck> @weiwangncar <https://github.com/weiwangncar> @dudhia <https://github.com/dudhia> 1. We probably need mods to share/module_check_a_mundo.F so that only the sfclay=1 tries to use these options. Do we want a stop, or a message that this is not being used? Opinions Wei and Jimy? 2. Since there are new namelist vars, let's put some descriptions in test/em_real/examples.namelist and run/README.namelist. 3. How does the namelist option for depth work? Is it an on/off flag, or do you set a depth? 4. Outside the scope of this PR ... what is the status of getting the bathymetry into the WPS static data tar files? 5. Would you add the DOI to the publication (I moved the reference to the RELEASE NOTES section). — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1543 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEIZ77DBLVN44SJS32ZHVFDUB6E5ZANCNFSM5CM3UNMA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[weiwangncar]

@phawbeck We've got the data. No PR is needed for that. But to use that data, a section in WPS/geogrid/GEOGRID.TBL is needed which tells geogrid program where the data is and how the data is interpolated. That is the section we are interested.

[hawbecker]

@weiwangncar ahh got it! See attached! (I had to add ".txt" to the end for GitHub to allow it to upload)
GEOGRID.TBL.txt

[weiwangncar]

@phawbeck This is it! Thanks. We will make WPS PR to add this.

[hawbecker]

@davegill I just ran a restart from an old simulation with the shallow water roughness scheme and it failed because the bathymetry_flag is only assigned to the input files. I added it to restarts and outputs, recompiled, and ran the same test and it passed. I will work on the other tests in the coming days.

[davegill]

@phawbeck
Patrick,
Very nice indeed.

[hawbecker]

@davegill I ran the compile tests both with and without the "-d" option for GNU (32, 33, and 34). Comparing those ran with "-d", the return from diffwrf showed only column headers. The same result was shown for compiling without "-d" between each option.

The restart tests, however, are showing the files are different. I ran the test again turning off the shallow water roughness scheme and even that is showing that the files are different. Maybe this is something specific to my setup and having some physics options on that shouldn't be.

[davegill]

@phawbeck @weiwangncar
Patrick,
Can you pass along your namelist to me (gill@ucar.edu).

[davegill]

@phawbeck @weiwangncar
Patrick,
Take a look on cheyenne in the /glade/scratch/gill/WRF_shallow_water/test/em_real directory. There are two namelists: nml1 and nml2. These set shalwater_rough = 0,. Would you re-run this test with shalwater_rough = 1,.

set O = ORIG
set R = RESTART
set F = wrfout_d01_2019-07-30_00:10:15
set DIFF = ../../external/io_netcdf/diffwrf
mkdir $O
mkdir $R

Then the commands to run are:

rm $O/*
cp nml1 namelist.input
./wrf.exe > & print.out
mv print.out wrfo* $O

rm $R/*
cp nml2 namelist.input
./wrf.exe > & print.out
mv print.out wrfo* $R

The diffwrf command should just give the column headers

$DIFF $O/$F $R/$F

 Just plot  F
Diffing ORIG/wrfout_d01_2019-07-30_00:10:15 RESTART/wrfout_d01_2019-07-30_00:10:15
 Next Time 2019-07-30_00:10:15
     Field   Ndifs    Dims       RMS (1)            RMS (2)     DIGITS    RMSE     pntwise max

[hawbecker]

@davegill - I just finished running the test you asked for (shalwater_rough = 1) here:
/glade/scratch/hawbecke/WRF/MMC/sandbox/shalwater_rough_tests/GillTest/em_real

The output from diffwrf was just the headers, as expected:

cheyenne2:em_real➜ ./diffwrf ORIG/wrfout_d01_2019-07-30_00\:10\:15 RESTART/wrfout_d01_2019-07-30_00\:10\:15 
 Just plot  F
Diffing ORIG/wrfout_d01_2019-07-30_00:10:15 RESTART/wrfout_d01_2019-07-30_00:10:15
 Next Time 2019-07-30_00:10:15
     Field   Ndifs    Dims       RMS (1)            RMS (2)     DIGITS    RMSE     pntwise max

[davegill]

@weiwangncar @dudhia
Folks,

1. The PR provides demonstration that it behaves as it should.
2. There is no negative impact on the existing code - all the regtests pass.
3. The developer conducted the parallel tests and the restart tests.

This is ready for a review.

[weiwangncar]

I added '3. The code passed bit-for-bit check and restart test.' in the PR.

[weiwangncar]

This code has passed bit-for-bit and restart tests.

[hawbecker]

@phawbeck Thanks for removing optional variable declarations. One last comment I have is what you think about changing the namelist option shalwater_rough to shalwater_z0?

@weiwangncar @davegill - I forgot about this comment from a while back. I got the go-ahead to change the name from shalwater_rough to shalwater_z0 from the collaborators. Should I go ahead and make this change?

[weiwangncar]

@phawbeck Apparently I forgot about the variable name change too. Since you got an 'OK' from your collaborators, could you make the change, please? Thanks!

[hawbecker]

I've updated the name to shalwater_z0 everywhere. Thanks, @weiwangncar, for the suggestion!

[davegill]

@weiwangncar
Wei,
With the name modification, a re-review is required. :)

[davegill]

@phawbeck
Patrick,
Would you please update the PR commit message to reflect the name change? Thanks

[weiwangncar]

@phawbeck I've updated the PR message to reflect the name change. Please check though.

[hawbecker]

@weiwangncar Thanks a lot! Looks good to me.