Support for diversions in SFRmaker

[emorway-usgs]

This issue is opening a discussion that seeks to add support for diversions within SFRmaker. The attached shapefiles correspond to the grid and linework used in a hypothetical model first published in 2016. There are several attributes within both shapefiles, this is left over from an attempt by the NVWSC to write a python script that would generate SFR input. That effort wilted years ago.

In the grid shapefile, there are three attributes that are pertinent to SFRmaker (I think). The first is "Elevation," which defines the altitude of land surface for every cell. The second is "Reservoir" which is a flag indicated which cells are lake cells. This may not be needed at the moment, but might help guide support for establishing SFR/LAK connections? The third attribute is "Active_cell" which is essentially Ibound.

Regarding the linework representing the river, tributaries, and canals, there is an attribute titled "StreamType" which can take on an integer value between 1 and 4:

1. River
2. Tributary
3. Diversion
4. Thalweg of lake

One other attribute of note is "StrTop_Off." This was an attempt at defining how much incision to apply to the segment (where "segment" fits with the old SFR2 paradigm. Having not used SFRmaker in the past, I suspect these two shapefiles may need to be supplemented with additional data to explore what it might take to get diversions into SFRmaker. I would be happy to work on that.

All of the other attributes present in the files likely can be ignored.

Here is what the grid & linework look like (flow is from left to right):

I'm hopeful these example shapefiles could serve as a small test case for incorporating diversions into SFRmaker, particularly for generating MODFLOW 6-compatible input? While this example is small, many (most?) western US basins have diversions of some form, and so I think this would be a popular addition.

example_grid.zip
example_linework.zip

[langevin-usgs]

@aleaf how does SFRMaker determine the stream to stream connections? Can or does it use vertex ordering in the line work? Or should this be attributed somehow?

[langevin-usgs]

Would it make sense to get it working for something like this first?

[aleaf]

Hey @langevin-usgs, at the segment/LineString level, SFRmaker relies on a routing attribute column in the input hydrography shapefile (of downstream line ID connections). Then within each original LineString, routing is established between the reaches (line fragments resulting from intersection with the grid) based on vertex order.

It would be pretty straightforward to add a function to establish routing between LineStrings based on Vertex order (last to first) and proximity; I just haven't done this yet because routing information is already included in NHDPlus, or the model is small enough that routing can be easily specified manually. @emorway-usgs thoughts on this? Do you typically have routing information for your input linework?

For a first cut at diversions functionality, I would suggest simply specifying the routing in the input, unless that wouldn't be a typical case. Routing connections could be specified in a separate CSV table or dictionary (NHDPlus uses a .dbf attribute table). That way, you can have multiple entries for the upstream line, each with a different downstream connection, and the portion of flow that goes to that connection. @emorway-usgs thoughts? This shapefile is great for the conceptualization, but it would help to have a better understanding of what the input data are like for a typical diversion case.

[emorway-usgs]

@langevin-usgs Yes, I do think your 3x3 example is a more appropriate place to start. I will endeavor to draft a flopy script that would create a simple 3x3 model. I can contrive the accompanying .shp files that SFRmaker would need as well and then we could assign attributes as needed.

On that note, and to respond to @aleaf, I'm not aware if NHDPlus currently hosts linework associated with diversions (irrigation or otherwise). In my experience, albeit limited to CO and NV, is that the GIS datasets containing diversion linework come from state-level sources; sources like the Colorado State Engineer's office, or the Nevada State Engineer's office. Thus, I'm not sure there is a standardized format for this kind of information.

In response to your second question, @aleaf, our initial attempt at developing a python script to do what SFRmaker now does, we used the line "direction" attribute that is implicit in the .shp file. There was (and probably is) a way to plot the line direction in ArcGIS. This approach required that the user go through their hydrography dataset and ensure proper line direction (which of course reflects flow direction). Where line directions were found to be backward, one could easily fix the issue by right-clicking on the GIS line segment and selecting "reverse line direction," or something to that effect. As you suggest, we did have to specify routing connections in the attribute table of the line work. In other words, one of the attributes in the linework attached to the first msg in this thread is "iupseg," which of course harkens back to the SFR2 paradigm. If pressed, I think I could track down the python that we used to take a stab at doing what is being requested in this thread, but I'm fairly certain it relied on arcpy libraries, and certainly wasn't a generalized script.

Perhaps the next logical step is for me to draft the 3x3 test model and accompanying linework for SFRmaker. After that, we could assign/discuss attributes after appraising what type of information is in NHD+. Does that seem reasonable?

[emorway-usgs]

@aleaf @langevin-usgs I'm attaching what I think is a minimal example for further development on SFRmaker for supporting diversions. The attached notebook starts by generating a 5x5 grid and then adds a river from 2 pts. Plots of the grid and location of the River can be seen in the notebook. If/when SFRmaker can build a MF6-style SFR input file from just two points representing the river, the notebook then adds a diversion - and like the river uses only points to define the location of the river. Here again, the notebook plots the location of diversion in the context of the grid and river.

If/when that is supported by SFRmaker, the notebook then uses gridgen to refine the underlying numerical grid using a quadtree approach. I think it would be a powerful feature if SFRmaker could be used with non-standard grids, and it is my hope that this notebook helps facilitate that.

I should add that additional data may be needed, like elevation of the starting and ending point of the river/diversion. Other ancillary data required by SFRmaker can be contrived as needed - the main goal of this notebook is to hopefully provide a simple, FloPy-based launch pad for getting started on this stuff. The notebook includes one figure that also is attached to this post. As long as the figure is placed in the same directory as the notebook, everything should run (though you'll need GridGen in your path variable to run the quadtree refinement.

Diversion_Example.zip