Questions on Preparing Nudging Input Files: Watershed SHP Selection and GWBUCKPARM Dimension Issue

[zed li]

Hello everyone,

I hope this message finds you well. I am currently working on preparing the input files for nudging and have encountered a few questions that I would greatly appreciate your insights on.

Firstly, regarding the generation of the spatialweights.nc file using the WRF_Hydro_Regridding_Spatial_Weights.py script: a watershed Shapefile (SHP) is required for this process. I have three stations based on which the watershed needs to be delineated, but I am uncertain which SHP file would be most appropriate to use. For instance, should I follow the approach similar to Figure 1 or Figure 2, or would neither be suitable? I would be truly grateful for any advice or suggestions regarding this matter.

Secondly, while attempting to run the nudging process on my own watershed, I encountered the following error:
The job is stopped due to the fatal error. Failed read GBUCKETPARM - nf90_inq_dimid: BasinDim.
Upon investigation, I noticed that the dimension in my GWBUCKPARM.nc file is feature_id (this file was generated using the official wrf_hydro_arcgis_preprocessor in ArcGIS), whereas in the official NWM example case, the corresponding dimension is BasinDim. I suspect this discrepancy may be the cause of the error, and I would appreciate any guidance on how to resolve this issue.

Thank you all in advance for your time and assistance. Your expertise and support are immensely valuable to me.

Best regards,
Zed Li

[Kevin Sampson]

Zed,

I just want to clarify one thing with you regarding the use of spatial weights. Using the UDMP option (user-defined mapping) is a way of replacing the gridded conceptual groundwater buckets with user-defined polygons. For example, the user may wish to use an existing hydrography dataset (such as NHDPlus or MERIT_Basins), and the UDMP configuration allows this. The polygons provided to the WRF_Hydro_Regridding_Spatial_Weights.py script become an aggregation layer for flows that reach the channel cells (from CHANNELGRID) within each polygon. Note that if you only have 3 basin polygons (figure 1, above), then you should only have approximately 3 channels in your RouteLink file, although more are permitted. Even if you have more channels than polygons, only the reaches with a matching ID between the spatialweight file and RouteLink.nc will receive flow from the basin (groundwater, surface water). As such, you may wish to have a more dense vector network of catchments and flowlines, and you will want to ensure that the basin IDs match your channel reach IDs. 

Since your goal is to use the nudging functionality, the NCAR team may have additional guidance regarding the use of spatial weights for streamflow nudging.

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/0258a908-509f-4a87-829a-c6aed853914an%40ucar.edu.

[zed li]

Hi Kevin,

Thank you once  for your clear and helpful explanation. I am especially grateful that you emphasized the importance of ensuring consistency between the basin IDs in the spatial weights file and the reach IDs in the RouteLink.nc file.

In my case, both my RouteLink.nc and GWBUCKPARM.nc files were generated using the official wrf_hydro_arcgis_preprocessor tool in ArcGIS, so I believe these two files should be consistent with each other. However, I suspect that the issue may lie with the watershed Shapefile I used, as it  not correctly match the reach IDs in the RouteLink.nc file.

Additionally, while comparing my RouteLink.nc file with the one provided in the NWM example case, I noticed significant differences in the variables. For instance, the official example includes additional variables such as:

int ascendingIndex(feature_id); ascendingIndex:long_name = "Index to use for sorting IDs (ascending)";

My file, generated by the wrf_hydro_arcgis_preprocessor, lacks many of these variables. This makes me wonder whether the RouteLink.nc file produced by this tool is actually suitable for nudging applications.

I would greatly appreciate any further insights or suggestions you may have regarding this matter.

Thank you once again for your valuable time and assistance.

Best regards,
Zed Li

[zed li]

Hi everyone,

I have identified significant variable differences between the Route_Link.nc file generated using the wrf_hydro_arcgis_preprocessor tool and the official test case Route_Link.nc file:

Variables Exclusive to the wrf_hydro_arcgis_preprocessor Generated File:

• x(feature_id) - X-coordinate values

• y(feature_id) - Y-coordinate values

• crs - Coordinate reference system information

Variables Exclusive to the Official Test Case File:

• TopWdth(feature_id) - Top width parameter

• TopWdthCC(feature_id) - Composite channel top width parameter

• nCC(feature_id) - Composite channel Manning's coefficient

• ascendingIndex(feature_id) - Ascending index

The two files exhibit substantial differences in their variable composition. I would greatly appreciate your guidance on whether the Route_Link.nc file generated by wrf_hydro_arcgis_preprocessor can be properly used for nudging applications.

If this file is not suitable for nudging, could you please advise on the recommended approach? I have encountered several challenges when generating input files for nudging and would be grateful for your technical support to resolve these issues.

Thank you for your assistance.

Best regards,

Zed Li

[Arezoo RafieeiNasab]

Hi Zed, 

Thanks Kevin for the complete explanation! I would just add, you might want to consider having more detailed basins if there is finer granularity available for the domain when generating the river and GW. 

As for the nudging question, the items in the official test case are not required for running the model. The first three are specific to the compound channel option (https://wrf-hydro.readthedocs.io/en/latest/model-physics.html#compound-channel-limited-configuration). If you do not have these, you could turn off the compound channel in the hydro.namelists. The nudging is independent, and will work with a case with no compound channel.  The ascendingIndex I believe is not required either. 

Again nudging files are independent of the river properties, so you should be fine moving forward with the current files you have. 

Thanks!

Arezoo

To view this discussion visit https://groups.google.com/a/ucar.edu/d/msgid/wrf-hydro_users/e2c21625-676e-4c21-8b58-defee79ab105n%40ucar.edu.

--

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

My working day may not be your working day. Please do not feel obliged to reply to this email outside of your normal working hours.

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

Arezoo Rafieei Nasab, Ph.D.

Project Scientist II

NCAR Research Applications Laboratory

are...@ucar.edu

[zed li]

Dear Arezoo,

Thank you for your detailed response. Through your and Kevin’s explanations, I believe I have gained a deeper understanding of the nudging input files. Specifically, I now recognize that the reach IDs in RouteLink.nc, the sub-basin IDs in GWBUCKPARM.nc, and the sub-basin IDs in spatialweight.nc must align.

I realized that the shapefile I previously used to create the spatialweight.nc file was based on the Station-based watershed (i.e., the basn_msk variable generated by the WRf-Hydro GIS Preprocessor), which was incorrect. After further investigation, I discovered that the basin variable generated by the WRf-Hydro GIS Preprocessor (using the "FullDom LINKID local basins" method) corresponds to the groundwater basins in GWBUCKPARM.nc.

However, I encountered a new issue: the basin data is in raster format. As shown in Fig. 1 (the original data), I converted it into a shapefile to generate the spatialweight.nc file. When I overlaid this with the river network generated from the linkid variable, the result appeared somewhat unreasonable, as shown in Fig. 2.

I am curious to understand why this inconsistency occurred and would appreciate your insights on how to resolve it. Thank you once again for your guidance and support.

Best regards,
Zed Li

[zed li]

Hi Arezoo,

I hope this message finds you well.

Thank you once again for your previous assistance. I am writing to follow up on the issue regarding the conversion of the basin raster data to a polygon-based shapefile. As I mentioned, during the conversion process, a few grid cells with the same value became separated from their main groups, resulting in some polygons—some containing only a single grid cell—being assigned the same gridcode but treated as distinct features.

My primary concern is whether the shapefile generated under these conditions is suitable for use in the nudging workflow. Specifically, I would like to confirm if such discrepancies (e.g., isolated grid cells or fragmented polygons) could potentially impact the alignment of sub-basin IDs across RouteLink.nc, GWBUCKPARM.nc, and spatialweight.nc, and whether this might introduce errors in the nudging process.

Your guidance on this matter would be greatly appreciated. Thank you very much for your time and support.

Best regards,
Zed Li

[Arezoo RafieeiNasab]

Hi Zed, 

This might be a question to our GIS folks. I have not done these steps myself in the past. You probably know this, for the NWM model the shapefile is not coming from GIS pre-processing, it is based on the NHDcatchments which its shapefile is available for use. Others could probably comment on your question. 

Thanks!

Arezoo

[aubrey]

Hi Zed:

Just to add a little context:

• The UDMP option was added because we had a request to implement WRF-Hydro on a specific trusted catchment/reach hydrofabric for the NOAA National Water Model. In this configuration, surface runoff reaching a channel cell in a given catchment is lumped and routed downstream its associated reach. Drainage from the soil column is also aggregated by catchment and then routed as baseflow discharge down the associated reach.
• Our standard hydrofabric methods will derive catchments and reaches based on topography and then the model will route based on those (consistent) layers.
• Streamflow nudging DA is applied to the individual reach. There is really nothing about UDMP that relates to nudging DA (at least that I am aware of), but it is really a matter of where (in the WRF-Hydro code) it was implemented specifically for the NOAA National Water Model. If someone had bandwidth, I think nudging could be added to our non-UDMP reach routing without too much effort.

So at this point you are sort of mixing and matching methods to use UDMP in this way. You are using our traditional geospatial tools to derive a gridded catchment/reach network based on topography, then creating polygons, deriving spatial weights mapping, and using that abstraction for routing. So you are sort of introducing polygon catchments when they are not really needed. UDMP was really intended for use when you have a trusted vector-based representation of hydrofabric that you want to adhere to (e.g., NHDPlus, MERIT hydro, etc.).

That being said, in theory you can still use these tools in this manner, just note that you may have to do a decent amount of manual testing and cleanup to figure out the right configuration that works.

Thanks!

Aubrey

[zed li]

Dear Arezoo, Kevin, and Aubrey,

I hope this message finds you well. I wanted to take a moment to sincerely thank you for the invaluable assistance you provided in my recent research work. With your guidance, I successfully created the nudging input files and ran a trial simulation period for my study area.

Upon reviewing the simulation results, I found that the simulated discharge outputs at the three stations align almost perfectly with the observed discharge data. Additionally, the CHRTOUT file and the nudgingLastObs file show three non-zero values for the nudge variable, corresponding to the three stations. These results lead me to believe that the nudging workflow is functioning correctly. However, to ensure thoroughness, I’d like to ask: are there other methods to further verify whether nudging is working as intended? If you have any suggestions or insights, I would greatly appreciate your advice.

Once again, thank you so much for your generous help and unwavering support. Your guidance has been crucial to the progress of my research. 

Thanks,

Zed Li