How to use multiple data sources(srtm_3s+default) to perform geogrid on topography data?

[lyg]

Hello, WRF Forum!
The problem I encountered is the same as the post ( SRTM_3S), but this problem seems not to have been resolved. Therefore, to facilitate my direct adoption of his statement, I proceeded accordingly.
I have successfully imported the srtm 3s data as static topography data and used it in my setup.
Since the srtm 3s data does not cover the entire model area, when I used namelist.wps and set "geog_data_res = 'srtm_3s+default'", the following occurred:
The output of HGT_M was displayed as 0 in all other places in the model area where the srtm_3s data did not exist. I originally thought that in the case of a single or multiple sources in the geographic grid not covering the entire area, it would fill the remaining area with the "default" source. However, it seems that the geogrid checks whether the specified source has any data in the model area and then only uses that source.

Please refer to the following attached figure:


My WPS version is 4.6.0.

The relevant entries for srtm_3s in my "GEOGRID.TBL" file:
interp_option = srtm_3s:average_gcell(4.0)+four_pt+average_4pt rel_path = srtm_3s:srtm_3s/
rel_path = topo_srtm_3s:topo_srtm_3s/

Please refer to the following namelist.wps:
&share
wrf_core = 'ARW'
max_dom = 3
start_date = '2025-07-26_00:00:00', '2025-07-26_00:00:00', '2025-07-26_00:00:00'
end_date = '2025-07-27_00:00:00', '2025-07-27_00:00:00', '2025-07-27_00:00:00'
interval_seconds = 3600
io_form_geogrid = 2
debug_level = 0
/

&geogrid
parent_id = 1, 1, 2
parent_grid_ratio = 1, 3, 3
i_parent_start = 1, 330, 260
j_parent_start = 1, 125, 520
e_we = 901, 922, 922
e_sn = 601, 982, 982
geog_data_res = 'srtm_3s+default', srtm_3s+default', srtm_3s+default'
dx = 9000
dy = 9000
map_proj = 'lambert'
ref_lat = 35
ref_lon = 115
truelat1 = 30
truelat2 = 60
pole_lat = 90
pole_lon = 0
stand_lon = 115
geog_data_path = '/public/home/gly/wrf/GEOG/WPS_GEOG'
opt_geogrid_tbl_path = './geogrid/'
/

&ungrib
out_format = 'WPS'
prefix = 'PRE'
/

&metgrid
fg_name = 'PRE', 'SUF'
io_form_metgrid = 2
opt_metgrid_tbl_path = './metgrid'
/

 

[kwerner]

Hi, Many apologies for the delay in response to your question. Have you managed to solve the problem yet, or are you still experiencing the issue?

 

[lyg]

Hi, thank you for following up. Unfortunately, the problem has not been solved yet, and for the time being I have given up on using high-resolution terrain data.

The core of the issue is that I tried to fill the nested domains d02 and d03 with high-resolution topography, but the terrain height is only correct where the high-resolution data is available. In areas where I do not have high-resolution data, I expected geogrid to fall back to the default terrain data and fill those regions automatically — but it doesn't seem to do that.

Could you help clarify whether this behavior can be fixed, or whether it is simply a fixed limitation that only one set of terrain height data can be used? I've attached a reference image below.


Thank you for your help.

 

[Tanjona Fanantenana]

Hello !
I came across your post ,,,, the SRTM_3S data coverage and the "zero-filling" issue in geogrid. I think I might have identified why the fallback to "default" data isn't working as expected in your setup.

In your GEOGRID.TBL, check the HGT_M section for the following line:
fill_missing = 0.

If this line is present, geogrid will treat any missing high-resolution tile as a fixed elevation of 0 meters instead of looking for the next available source in your geog_data_res list. Try to :

1)Comment out or remove fill_missing = 0. from the HGT_M section in your GEOGRID.TBL.

2=Ensure your index file (inside your srtm_3s data folder) correctly defines a missing_value (e.g., -32768.) that is not 0.
This should force geogrid to properly trigger the fallback to the default GMTED2010/GTOPO data where SRTM tiles are missing.

Hope this helps you get those nested domains working!

 

[lyg]

Thank you for your thoughts and reply. However, your speculation seems to be incorrect, because I have tested this before. To avoid any misjudgment due to memory confusion, I re‑ran the tests, and the results are consistent with my memory: this treatment leads to extremely abnormal terrain height values.

Below are the results with fill_missing = 0. and geog_data_res = 'default':

Min/Max: 0.00 / 6312.71

The maximum terrain height in d01 seems problematic, considering that the highest point of the Tibetan Plateau is around 8000 m.


Below are the results with fill_missing = 0. and geog_data_res = 'srtm+default':

Min/Max: 0.00 / 6314.73

The maximum terrain height still appears problematic.


Below are the results with # fill_missing = 0. and geog_data_res = 'srtm_code+default' (note: missing_value = -32768 was already set in the index file; fill_missing = 0. was commented out):
Plotting fails.

Min/Max: 0.00 / 108547517437488136192.00

The maximum terrain height is extremely abnormal.
Code error:
shapely.errors.GEOSException: TopologyException: side location conflict at 134.92306518554688 33.535152435302734. This can occur if the input geometry is invalid.

One more issue worth noting:
When fill_missing = 0. and geog_data_res = 'srtm_code+default' are set in namelist.wps, and the default file for LANDUSEF (the 1 default) is replaced with new land use data, a series of similar errors appear during geogrid. One of them is:
point (10001, 11131) has an invalid category of 0.