Groundwater basins

[Yiannis]

Hello,

I am inspecting the output of the WRF-Hydro GIS Preprocessor  v5.1.1 and the GWBASINS.nc file doesn't contain the groundwater basins similar to the surface basins. It contains instead unique values for each grid cell.

 So I used the Build Groundwater Inputs utility in ArcGIS Pro and I chose the option of using the basin_msk variable for generating the groundwater basins.  The tool failed however very fast, but this was was not seen in the messages.

 The only output I got is an empty gw_scratchdir and an empty GroundwaterBasins.log file. 

The messages I got are:

Begining processing on Tue Nov 17 23:49:44 2020

Input parameters:

Parameter: Input FullDom File: C:\Users\i.sofokleous\Desktop\Work\Fulldom_hires.nc

Parameter: Input Geogrid File: C:\Users\i.sofokleous\Desktop\Work\geo_em.d03.nc

Parameter: Method for deriving groundwater basins: FullDom basn_msk variable

Parameter: Polygon feature class to define groundwater basins: None

Parameter: Output Directory: C:\Users\i.sofokleous\Desktop\Work\GroundWaterBasinsInput

Using existing scratch directory

Step 1: NetCDF Conversion initiated...

Map Projection: Mercator

Using MOAD_CEN_LAT for latitude of origin.

Step 1 completed without error.

Step 1: NetCDF Conversion initiated...

Map Projection: Mercator

Using MOAD_CEN_LAT for latitude of origin.

Step 1 completed without error.

GeoTransform: 11399469.517467083 100.0 0 3604951.3229832305 0 -100.0

Beginning to build 2D groundwater basin inputs

Building groundwater inputs using FullDom basn_msk variable

Finished building groundwater basin grids in 0.44 seconds

Succeeded at 17 November 2020 23:49:44 (Elapsed Time: 0.57 seconds)

Do you know what could go wrong?

Thanks,

Yiannis

[Kevin]

Yiannis,

If you are seeing a unique value for each coarse grid-cell in the groundwater grid, then this is likely because you have a dense channel network when compared to the LSM resolution. The default method for defining groundwater basins is to assign a unique ID (and thus, basin) to the contributing area for each reach, which is defined by the area between confluences on the channel grid. The failure you encountered is indeed strange, because the tool messages indicate that the tool completed successfully. Have you tried to close the application (ArcMap, ArcCatalog, ArcGIS Pro) and try again? Does your Fulldom_hires.nc file (C:\Users\i.sofokleous\Desktop\Work\Fulldom_hires.nc) contain valid values in the 'basn_msk' variable? You could also try converting that layer to polygons and use them as input as a polygon shapefile. 

If you are feeling adventurous, you could try these same tools in the open-source WRF-Hydro GIS Pre-processor: github.com/NCAR/wrf_hydro_gis_preprocessor/releases/tag/v0.1.0-beta

Cheers,

Kevin

[Yiannis]

Hi Kevin,

Thank you. Regarding the resolutions, I have resolutions at 1-km for the LSM and 100-m  for the routing grid.

I tried all options you gave, such as closing the applications and restarting, I checked the bsn_mask and it does contain valid values, I tried converting the bsn_mask layer to polygon and rerunning but still I got the same result.  (See my results for the open-source WRF-Hydro preprocessor after the maps.)

You can see below 1) the layer from the GWBASIN.nc file (with basin boundaries), 2) that my bsn_mask layer is valid and 3) that the basin polygons that I converted from the bsn_mask are also valid

I finally tried the open-source preprocessor with the python script on conda shell using:

python Build_Groundwater_Inputs.py -i data\in\geo_em.d03.nc -f data\in\Fulldom_hires.nc -m 'FullDom basn_msk variable' -o data\out

And I got:

usage: Build_Groundwater_Inputs.py [-h] [-i IN_NC] [-f IN_FULLDOM]

                                   [-m GWMETHOD] [-g IN_GWPOLYS] -o OUT_DIR

Build_Groundwater_Inputs.py: error: unrecognized arguments: basn_msk variable'

How do I give the argument in the command after -m for the basn_mask variable?

I skipped the -m, as the default GWMETHOD is the one that I actually want. And retried:

python Build_Groundwater_Inputs.py -i data\in\geo_em.d03.nc -f data\in\Fulldom_hires.nc -o data\out

And it worked.

I checked the output in ArcMap and I found that I get the GWBASINS the same as basn_mask.

The only problem is that the coordinate system of the layer BASINS in the output GWBASINS.nc (Mercator 1SP). It is not the same as the channel grid Fulldom_hires (Sphere Mercator) that I generated through the ArcMap pre-processor. 

I also noticed that the resolution of the layer BASINS in the output GWBASINS.nc has a 1000-m resolution, instead of 100-m. 

Can these be corrected through the python script I use in conda?

Cheers and thanks for all these useful scripts and tips,

Yiannis

[Kevin]

Yiannis,

Thank you for the detailed description. I will look into why the ArcGIS tool was not yielding any results, though I have not experienced this behavior in my tests. From your images, I see that the reason you were getting very small groundwater basins at the 1km resolution is indeed due to the density of your 100m channel network. These small groundwater basins are likely just 1-3 pixels (1-3km^2) in size, using the default method. 

To answer your first question, the appropriate inputs to the `-m` parameter in the Build_Groundwater_Inputs.py tool are the following: 'FullDom basn_msk variable', 'FullDom LINKID local basins', 'Polygon Shapefile or Feature Class'. You can use the `-h` or `--help` parameter to see the help information for each of these scripts. I think you want to use 'FullDom LINKID local basins' and use the Fulldom_hires.nc file, where your gaged basins have already been delineated during the GIS pre-processing step.

You noticed that the BASINS grid in GWBASINS.nc matches the resolution of your LSM grid. That is correct, as the groundwater basins are resolved on the LSM grid (1km in your case) and not the routing grid.

As far as the difference in coordinate systems, I imagine this is simply a difference in the representation or naming of the coordinate systems. Often, the open-source and ArcGIS will represent coordinate systems with different projection names and parameter names, but the coordinate system will be identical between them. Have you checked the parameters for any differences? "Mercator 1SP" and "Mercator" are the same projection type. Both should be represented on a sphere of radius 6370000m and share the same projection parameters. If not, please let me know.

Thanks,

Kevin

[Yiannis]

Hello Kevin,

Thank you.

Regarding the size of my basins, the smallest one has a size of 5 pixels. 

Regarding the inputs to the -m parameter I tried both  'FullDom basn_msk variable' and 'FullDom LINKID local basins'  and they are not recognized. Please see below:

For the difference in the coordinates I checked in the spatial reference of the open-source and the ArcGIS files (in ArcGIS):

They indeed have exactly the same coordinate system, they are both represented on a sphere of radius 6370000m and share the same projection parameters except the following:

(1) the open-source file has a 'latitude of origin' parameter that is not seen in the ArcGIS file. 

(2) the standard parallel is 0.0 in the open-source file and 32.2 in the ArcGIS file

I attach screenshots from the spatial reference information for the open-source and the ArcGIS files and the maps as I see them in ArcGIS.

Cheers,

Yiannis

[Yiannis]

Dear Kevin,

There is nothing wrong with the input arguments of the -m parameter for the python script Buld_Groundwater_Inputs.py of the open source gis package. I am sorry for that.

I should have enclosed in double quotes the 'FullDom basn_msk variable' and 'FullDom LINKID local basins' as "FullDom basn_msk variable" and "FullDom LINKID local basins".

Both options "FullDom basn_msk variable" and "FullDom LINKID local basins" generate the same BASINS layer in GWBASINS.nc with same size and extent. Should I expect any difference?

Thank you,

Yiannis

[Kevin]

Yiannis,

Yes, there should be a difference between the outputs when you select "FullDom LINKID local basins" versus "FullDom basn_msk variable". Have you downloaded or cloned the current master of the repository from GitHub (not the release version)?

https://github.com/NCAR/wrf_hydro_gis_preprocessor

 I recently discovered a bug that prevented any of the other methods from working. Let me know once you test the latest version if you are still seeing identical outputs from the different `-m` options.

As far as the coordinate system issue; can you please send your geo_em.nc file and your Fulldom_hires.nc file? I would like to test this on my system. I do have a comment: I see that you selected Mercator rather than Lambert Conformal Conic for this region (Greece). I think either would be fine, but we typically encourage the use of Lambert Conformal Conic in the mid-latitudes.

Kevin