add seg_tave_water to PRMS outputs at NHD resolution

[janetrbarclay]

To be able to pretrain at the NHD resolution, we need to have seg_tave_water added to the sntemp outputs that are compiled at the NHD resolution (what becomes nhdv2_inputs_io.zarr)

[lekoenig]

OK, gotcha! Should we retain all of the dynamic PRMS-SNTemp variables, or just stick with seginc_potet and seg_tave_water?

#> "seg_rain"            "seg_tave_air"        "seg_tave_water"      "seg_outflow"         "seg_tave_gw"        
#> "seg_tave_sroff"      "seg_tave_ss"         "seg_tave_upstream"   "seg_upstream_inflow" "seginc_gwflow"       
#> "seginc_potet"       "seginc_sroff"        "seginc_ssflow"       "seginc_swrad"        "seg_humid"          
#> "seg_shade"           "seg_ccov"           "seg_width"

[janetrbarclay]

Do we have the other dynamic ones that we currently use as river-dl inputs? (seg_rain, seg_tave_air, seginc_potet, seginc_swrad, seg_width) If not, it's worth keeping those.

[lekoenig]

Do we have the other dynamic ones that we currently use as river-dl inputs? (seg_rain, seg_tave_air, seginc_potet, seginc_swrad, seg_width) If not, it's worth keeping those.

No, we currently only retain seginc_potet but we can save and include all of these in the zarr data store.

[janetrbarclay]

I think maybe we're talking about different zarr's? Here's the current contents of the one I'm looking at:

[lekoenig]

This is admittedly pretty confusing and I had to remind myself that 1) we're currently only pulling seginc_potet from the dynamic PRMS-SNTemp drivers; and 2) the other variables you show are actually coming from gridmet, but we renamed them here to match the PRMS-SNTemp variable naming scheme. I'm not sure what our original justification was for matching the names, but we could certainly change that on the data-prep side of things to avoid confusion down the line.

[lekoenig]

I think to add seg_tave_water to the NHD-resolution outputs we would make the assumption that those water temperatures apply to all COMIDs along the PRMS/NHM river segment (like we do with seg_potet). Does that sound OK, at least as a starting point?