Seeking Help with Nudging Experiment Issue

[zed li]

Hello everyone,

I am encountering an issue with my nudging experiment in my study area and would appreciate your insights. I have observation data from three stations for assimilation. When I use all three stations for nudging, the results are excellent—the simulated discharge closely matches the observed discharge at all three stations.

However, when I exclude one upstream station (by adding an "X" before its station ID in the nudgingTimeSliceObs file), the simulated discharge at that station drops to less than 10 m³/s. Similarly, when I exclude all three stations, the simulated discharge at all three stations falls below 10 m³/s. This is abnormal because, when I run the simulation with the executable configured as WRF_HYDRO_NUDGING=0 and UDMP=0, the peak discharge at all three stations exceeds 3000 m³/s.

I have carefully checked the polyid variable in the spatialweights.nc file and confirmed that it corresponds to the ComID variable in GWBUCKPARM.nc and the link variable in Route_Link.nc. Despite this, I am unable to identify the source of the problem.

I have packaged all the relevant files and would be grateful if you could try running the experiment to help pinpoint the issue. Please let me know if you need any additional information or details.

https://drive.google.com/file/d/16qHgsIMX35TlqEE8zRGL7yirYMsavCto/view?usp=drive_link

Thank you in advance for your time and assistance!

Best regards,

Zed Li

[Kevin Sampson]

Zed,

Thank you for the detailed description and the domain files. I think I may have found the issue. You have a variable "LINKID" in Fulldom_hires.nc. This variable is used in reach based, but non-UDMP, configurations of WRF-Hydro. Could you remove LINKID from your routing parameter file and re-try with the no-nudging simulation?

Kevin

--
You received this message because you are subscribed to the Google Groups "wrf-hydro_users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to wrf-hydro_use...@ucar.edu.
To view this discussion visit https://groups.google.com/a/ucar.edu/d/msgid/wrf-hydro_users/a0aab62b-7e0e-46c4-99ba-acf152e51c8dn%40ucar.edu.

[zed li]

Hi Kevin,

Thank you for your response and suggestion. I have carefully checked the basin IDs and flowline reach IDs, and confirmed that they are consistent across all sub-basins. Following your advice, I removed the LINKID variable from the Fulldom_hires.nc routing parameter file and re-ran the no-nudging simulation. However, the results remain unchanged: the simulated flow at all three stations is still below 10 m³/s.

I appreciate your continued support and look forward to further suggestions or insights you might have to resolve this issue.

Best regards,
Zed Li

[zed li]

Hi Kevin,

To facilitate a more efficient diagnosis of the low-flow simulation issue, I have uploaded my complete work folder. You should be able to download and run it directly.

https://drive.google.com/file/d/1adYHhM18-7gMvKUOgpBePaiaoO-t1PqC/view?usp=drive_link

Additionally, I am providing the arcgis folder(r4n1000.rar), which was generated using the "Examine Outputs of GIS Preprocessor" function within the wrf_hydro_arcgis_preprocessor tool. This folder contains the key GIS outputs and will allow you to conveniently check the match between the basin IDs and flowline reach IDs.

Within this arcgis folder, please pay special attention to the shapefile basin_n1000_muti.shp. This is my modified version of the subbasin file, which was used to generate the spatialweights.nc file. Correspondingly, the GWBUCKPARM.nc file has also been updated to reflect these changes.

The reason for this modification: I discovered a misalignment issue in the original files produced by the wrf_hydro_arcgis_preprocessor. Specifically, link28 was not assigned to any subbasin. This caused a consistent offset of 1 between the basin ID and the link ID for all entries after sequence number 28. The modified files correct this misalignment.

I hope that these materials will be instrumental in helping you diagnose the root cause of the problem.

I look forward to your further insights.

Best regards,
Zed

[aubrey]

Hi Zed:

Since the spatial weights workflow is not officially supported, there may be some inconsistencies with the other tools that you might need to work through. One thing you could do is check the "NWM" configuration in the Croton test case. This is a cutout from the NOAA National Water Model that uses the UDMP=1 option. Check how the dimensions and IDs of the various components (Fulldom_hires.nc, Route_Link.nc, GWBUCKPARM.nc, spatial_weights.nc) line up and make sure your files follow a similar pattern. For example, I see that your spatial weights file is showing i_index and j_index values from 1 to 100, but your Fulldom file has dimensions 400 x 400. So it doesn't look like the spatial weights file matches the dimensions from your Fulldom file.

The way the physics work in the UDMP configuration:

1) If you have terrain routing active, water is routed across the high-res routing grid until it reaches a channel cell as specified in the CHANNELGRID layer in Fulldom_hires.nc. Water that reaches a channel cell gets aggregated by basin based on the mapping in the spatial_weights.nc file (i_index, j_index grid ID mapped to a catchment ID). That water is then summed and routed downstream the reach whose ID matches the catchment ID.

2) Underground runoff from the LSM is regridded from the coarse LSM grid to the high-res routing grid, then the same spatial_weights.nc file is used to map from grid to catchment and sum by catchment. This water is then added to the catchment's baseflow bucket (with parameters specified in GWBUCKPARM.nc) where it can be stored and eventually released to the reach whose ID matches the catchment ID (added to the quickflow component above and routed downstream).

Let us know how it goes once you are able to get consistent dimensions across the files.

Thanks!

Aubrey

[zed li]

Hi Aubrey,

Thank you for your help. I carefully checked the file dimensions in the NWM example. I confirmed that the i_index and j_index variables in spatial_weights.nc must match the dimensions of Fulldom_hires.nc, not geo_em.d03.nc.

The script I used to generate spatial_weights.nc is the official WRF_Hydro_Regridding_Spatial_Weights.py. There is a variable called nest, which is the ratio of high-resolution grid cells to the GEOGRID resolution. I modified nest to 4, but the generated i_index and j_index in spatial_weights.nc still range from 1 to 100, not 1 to 400. I believe this may be a bug in the WRF_Hydro_Regridding_Spatial_Weights.py script.

I tried to debug it but made little progress. I would greatly appreciate your help with this. Thank you again for your continued support.

Best regards,

Zed Li

[Aubrey Dugger]

Hi Zed:

Yes, we had a few users requesting this workflow so we added it into the repository, but in a "use at your own risk" level of support. Since we are an almost fully soft funded team, we only have limited resources to support individual user requests. Most of our support is volunteer time. So just a heads-up some tools that are in development like this one may require some additional user ingenuity - why we (all) benefit from having such a great user community with savvy users like yourself!

I don't use python, but you might try generating the spatial weights from one of the variables in your Fulldom_hires.nc file, since this will be the correct grid resolution. I would just want to be careful that the right j-index ordering is being followed, since I believe the geogrid file uses south-to-north indexing and the Fulldom grids use north-to-south ordering. Let us know how that goes.

Thanks!

Aubrey

--

-----------------------------------------------------------

Aubrey Dugger

NCAR Research Applications Laboratory

Office: 303-497-8418, Cell: 310-663-5115

adu...@ucar.edu

[zed li]

Hi Aubrey,

Thank you so much for your detailed and helpful response. I truly appreciate the warm-hearted support from you and the entire WRF-Hydro team. This forum, maintained by your efforts, is incredibly active and vibrant. I have benefited immensely from it, and I want to express my sincere gratitude for your selfless help.

Returning to the nudging issue, I am happy to report that I have successfully managed to run the nudging workflow. The problem was indeed that the i_index and j_index in my spatial_weights.nc file did not match those in the Fulldom_hires.nc.

I modified the WRF_Hydro_Regridding_Spatial_Weights.py script to allow the nest parameter to take effect correctly. Initially, I had overcomplicated the problem – the solution was quite straightforward. Here are the specific changes I made:

python

ncols = OutRaster.RasterXSize nrows = OutRaster.RasterYSize # Modification: Adjust grid resolution based on the nest parameter if nest > 1: ncols = ncols * nest nrows = nrows * nest DX = DX / nest DY = DY / nest print('Raster will have nrows: %s and ncols: %s' %(nrows, ncols)) gridder_obj = Gridder_Layer(DX, DY, x00, y00, nrows, ncols)

I am sharing this in the hope that it might help other users who encounter the same issue in the future.

Let's continue to build this wonderful community together. Cheers!

Best regards,

Zed Li