Move to NHD network?

[jsadler2]

I would like for us to think seriously about moving from the PRMS to the NHD network.

Pros:

• much finer spatial resolution
• won't have to do a cross-walk from PRMS to NHD for the static attributes (Gather additional static input variables for baseline LSTM v2 #51); the work for this has already been done by @lekoenig, but it does add a bit of complexity
• maybe more easily portable to another region
• more widely used/available

Cons:

• We'd need to gather our own met drivers on the NHD network
• diverges from other projects like Inland Salinity

[jsadler2]

In my mind, the spatial resolution is the one of (if not the) most important aspects. We'd be increasing the resolution by a factor of 20+: there are 456 PRMS segments in the full DRB and 12,970 NHD segments (28x). I think this would allow us to include more training points. The models would be able to see the spatial granularity that would presumably come out in the static attributes data and that would be lost in the spatial averaging that happens when using the PRMS network.

[lekoenig]

Thanks, Jeff. I agree with all of the pros/cons listed above, and think it makes sense to revisit this decision based on what's best for our project.

In terms of the pros, using NHD makes our task of gathering static features considerably more straightforward since, as you mention, we wouldn't need to cross-walk between the fabrics or wait on remaining processing steps in other projects. Maybe that's more or less balanced out by the time spent to gather met drivers referenced to the NHDv2 catchments.

Perhaps more importantly - in theory, the finer resolution of NHD would give us some more separation between input features that would hopefully improve the accuracy of DO predictions at our individual sites. Within our current list of well-observed sites, there are 10 unique PRMS segments represented versus 12 unique NHD segments (COMIDs). To try to visualize these differences, I plotted a few attributes at the NHD and PRMS scales (below). It looks like using NHD over PRMS would give us some more separation/continuous variation for catchment land cover, although the differences are not too drastic.

Other questions that come to mind:

• What other considerations (if any) would we want to make if we were aiming for a network model?
• To what extent do we want to keep PRMS calibration parameters that would be hard to downscale or gather by another method (e.g. soil_moist_max, covden_sum, covden_win)?

# A tibble: 14 x 5
   name                       Min     Mean       Max       Sd
   <chr>                    <dbl>    <dbl>     <dbl>    <dbl>
 1 cat_area_nhd           0.0765   6.49     16.4      5.89   
 2 cat_area_prms          2.02    76.8     158.      62.4    
 3 clay_nhd               5.74    19.5      28.1      5.22   
 4 clay_prms              5.73    19.9      23.5      4.51   
 5 pct_forest_2011_nhd    7.79    30.3      76.2     22.0    
 6 pct_forest_2011_prms   5.73    27.3      76.5     19.5    
 7 pct_urb_2011_nhd       3.1     38.5      67.5     24.2    
 8 pct_urb_2011_prms      6.33    51.0      85.2     22.5    
 9 pct_wetland_2011_nhd   0.41     3.46     14.9      4.13   
10 pct_wetland_2011_prms  0.19     2.61     15.8      4.04   
11 sand_nhd              19.5     32.6      79.1     15.8    
12 sand_prms             24.6     31.1      79.3     14.6    
13 stream_slope_nhd       0.00001  0.00128   0.00686  0.00200
14 stream_slope_prms      0        0.00989   0.0289   0.00735

[lekoenig]

The team agreed that moving to the NHD network makes sense for our project objectives (see 6/9/22 notes). This issue now includes the following tasks:

• Compile met drivers (gridmet) for the DRB NHDv2 catchments
• Add target(s)/bring NHD-scale met drivers into the DO pipeline
• Add target for NHD flowlines (Load NHDv2 flowlines #120)
• Snap DO site locations to NHD flowlines (Match DO sites to NHDv2 flowlines #121)
• Bring in static attributes aggregated at the NHDv2 scale, using comments in Gather additional static input variables for baseline LSTM v2 #51 as a guide.