HARP Weekly 9/5/2022

[rburghol]

• [x] Catch-Up!
• [x] Decision point: should we use ROVOL or OVOL 1? OVOL 1, 2, 3,... are outlets from the reach, which analysts have already determined, but, it based on my read of the HSPF manual, it looks like OVOL 1 is regular stream flow, and OVOL 2, 3,... may represent water that leaves the reach for agricultural and municipal withdrawal... so this should NOT be in the water that we pass downstream with this function. So which one should we export? See #482 - likely we need to change the variable we are analyzing and re-run our batch analyses
• [x] FTABLES (#331) - given time constraints (and the fact that bay program will be doing an intensive GIS-based channel estimation procedure) we need to develop the rudimentary floodplain method using NHD+/NWM. GIS analysis can be used to validate/error-assess our work.
• [x] Examine withdrawal questions. #498
  • [ ] let's make sure that we have all alias columns in ourHYDR output files, wd_mgd, and Qout. #312
  • [ ] we will then use these outputs to develop our markdown templates for comparing model runs.
• [x] P6 river running in hsp2 is almost ready (maybe even done today?)
• [x] Begin running large scale models and analyze.
• [x] Begin migrating P5 to P6 segments (to learn the ropes for VAHydro subwatershed migration)
• [x] Fun things coming... Gopal & CBP have created a framework to integrate our models seamlessly with theirs when complex reservoir management is needed.

[juliabruneau]

• [ ] let's make sure that we have all alias columns in ourHYDR output files, wd_mgd, and Qout. Script to Export river h5s #312
• [ ] we will then use these outputs to develop our markdown templates for comparing model runs.

A couple questions regarding this @rburghol:

Previously we only had used hydr.csv files to extract Qout from OVOL3. wd_mgd and ps_flow were found from other csv files, paths below:

data_source_hydr=/RESULTS/RCHRES_R001/HYDR
data_source_divr=/TIMESERIES/TS3007
data_source_ps=/TIMESERIES/TS3000 

We have a conversion script 'hsp_hydr_conversion.R' set up already to convert all these values to either cfs or mgd.

• Do you want us to create individual csv files for each conversion, or should we combine them all?
• Another option is to first modify the hydr.csv, divr.csv, and psflow.csv to include the converted values, and how we are creating the ovol3.csv after that, we can include the two other columns in that singular csv??
  • ovol3.csv files are the ones in the wdm format (year, month, day, hour, ovol3)
  • Now we could have: year, month, day, hour, ovol3, wd, ps_flow
  • Are csv files in this format for wd and ps flow also needed?

Essentially I'm not sure how these values are going to be used in the future/when they are needed, so I don't know what would be the most efficient solution.

[rburghol]

These are good questions. The way we have run our summary scripts in the past, they relied on a single output file that had all the quantities of interest. So I would go with the first option add them to the_HYDR. The reason I would not want to combine them with other files (like _ovol.csv) is that those files are expected to have only 5 columns yr,mo,day,value when importing to a WDM – And that's exactly what we will be doing with the OVOL3 file, importing it into a WDM for the next downstream river segment to use.

I think you do bring up a good question about mixing domains, in other words it's quite sensible to think that _HYDR should only have those things in the HYDR table.

But I think for now we'll stick all out aliased and ps/wd data in _hydr.csv where we had already put Qout, and then if we decide later that we should split it out into a dedicated file for aliased data we can do so.

[glenncampagna]

Difference in Timestep for WD, PS tables vs HYDR

We realized that the point source and withdrawal data has a timestep of 1 day:

$ head OR1_7700_7980_psflow.csv
"index","values"
1984-01-01,0
1984-01-02,0
1984-01-03,0
1984-01-04,0
1984-01-05,0
1984-01-06,0
1984-01-07,0

but we know HYDR has a timestep of 1 hour. There are still ways to combine the data, but we don't know if we should anymore knowing this difference.

If we were to add WD and PS to the HYDR table we'd either have to change HYDR to have daily data or transform the other 2 tables to show made-up hourly data.. which I wouldn't think is a good idea?

[rburghol]

OK, good catch. We should definitely combine we just have to double-check that we understand the units so that when we convert points source to hourly data it doesn't inadvertently multiply it by 24. If it's a rate however, no worries.

so yes: – convert to hourly – we use SQLDF for this, See below

Something like: hydr <- sqldf( "select a.*, b.ps_mgd from hydr as a left outer join ps as b on ( a.year = b.year and a.month = b.month and a.day = b.day ) order by a.year,a.month,a.day,a.hour ")