missing values in SRTM_topo_3s on Cheyenne

Howdy,
I am working as tmazzett on the cheyenne system in
/glade/scratch/tmazzett/WPS/
we tried to use the /glade/work/wrfhelp/WPS_GEOG/SRTM_topo_3s data folder to increase the geographical dara resolution for a 100m WRF simulation.
We had to modify geogrid/GEOGRID.TBL.ARW to include the following lines in the name =HGT_M section
interp_option = 3s:average_gcel(4.0)+four_pt+average_4pt
rel_path = 3s:SRTM_topo_3s
and in namelist.wps set
geog_data_res = '3s','3s'

geogrid ran successfully, but.
when examining the output with
ncview geo_em.d01.nc
there are 2 anomalous "pits" in the terrain close to the west and east boundary and the northern part of the domain.
this propagated to cfl errors when executing wrf.exe on a 900m gridspacing.

Any ideas on how these "pits" got into the terrain data and how to fix them?
cheers,
Thomas

Hi Thomas,
I looked at your geo_em* files, but I don't see anything missing the terrain height fields, using ncview. Can you tell me exactly what you're looking at (you could attach images, if that helps). Thanks!

because no one had replied in a few days, we decided to write some python code to smooth over the holes.
geo_mod.py
the unmodified geo_em file geo_em.d02.nc_unmod has the pits in it near the top of the domain that are quire narrow and deep.




also the georeferencing on the SRTM dataset it off by 1 degree latitude to the north.

I'm glad you were able to find a way to smooth it over, and thanks for bringing this to our attention.
I'm still not sure I'm finding the problem with your geo_em.d02.nc_unmod file. Are you looking at the HGT_M variable? Do you know the exact grid points where I could see this? I definitely believe you, and I'm sure this is something I'm doing wrong. I just want to be able to understand it better.

yes looking at HGT_M with ncview on that file.
increase the magnification of ncview to M X1 the pits are quite small. only a few gridboxes acrost.
there are 4 pits at gridpoints (y,x): ~(1311,50), (1311,240),(1311,835),(1311,1022)

It might be worth trying to change
to
(i.e., change "gcel" to "gcell") in the GEOGRID.TBL file. I haven't verified this, but my guess would be that the geogrid program is not applying the grid cell-average method and instead applying a four-point bi-linear interpolation, which might fail for WRF grid cells that are nearly exactly along the boundary between tiles of SRTM data. Note that the following messages appear in the geogrid.log file:

2020-11-05 10:59:37.452 --- WARNING: Unrecognized interpolation method average_gcel(4.0).
2020-11-05 10:59:37.452 --- WARNING: Unrecognized interpolation method average_gcel(4.0).

Click to expand...

could this also be the source of the error that this datasets georeference is 1 degree latitude too far north?

I don't think the interpolation scheme could account for a 1-degree latitudinal shift. More likely, something went wrong in the preparation of the SRTM 3 arc-second dataset for use by the geogrid program. A quick test suggests that the shift is confined to the Southern Hemisphere, and there appears to be a discontinuity in the topography field at the equator.

If your domain is confined to the Southern Hemisphere, you could try the following:

1. Create a directory named "SRTM_topo_3s" in your own scratch or work directory;
2. symbolically link the binary files into that directory from /glade/work/wrfhelp/WPS_GEOG/SRTM_topo_3s ;
3. copy the "index" file from /glade/work/wrfhelp/WPS_GEOG/SRTM_topo_3s ;
4. edit the "known_lat" value in the index file to offset the latitudinal shift ;
5. edit your GEOGRID.TBL file to use an "abs_path" to your SRTM_topo_3s directory rather than a "rel_path" to the original SRTM_topo_3s directory.

This is of course a work-around until we can investigate the latitudinal shift in the SRTM 3" dataset in /glade/work/wrfhelp/WPS_GEOG/SRTM_topo_3s/ .