Baseflow Event Identification Against Modeled Stream Flow

[rburghol]

@willprokopik

• Run our existing event identification scripts against the baseflow detection routines.
• Initial priority is Strasburg, followed by Mount Jackson, then Coote's Store.
• Run baseflow detection against a single land segment/landuse outflow. N51165 is good candidate
  • File: https://deq1.bse.vt.edu/p6/out/land/subsheds/eos/N51165_0111-0211-0411.csv
  • Use columns for_agwo + for_ifwo + for_suro (note: these are in units of inches per day, verify with @ilonah22 if any conversion are needed)
  • Maybe repeat with pas_agwo + ...

Ben's Baseline Trimming Function
My Alternate Trimming Function

Implementing Ben's Trimming Function

The following resulting tables, figures, graphs, etc. are based on datasets produced by Ben's Trimming Function
Using the files Ben produced (before/after trimming function), I created scatterplots for each of the sites of interest. I standardized the scaling on the plots to help us visually inspect similarities/differences between the sites (note: the x-axis extends to 1200 cfs but this number is partially cut off on the visual... I will continue to try to fix this). I did not highlight any particular study events in color like I previously had (just to give a very raw visual representation), but if we have any that we want to display at any point, this can be very easily done in the scatterplot function.

Cootes Store

Mount Jackson

Strasburg

Site	Mean Flow (cfs) — Original	Mean Flow (cfs) — Trimmed	AGWR — Original	AGWR — Trimmed
CS	78.1	67.6	0.938	0.951
MJ	234.7	207.4	0.952	0.963
S	411.2	362.0	0.958	0.969

None of the R-squared values are strong, but it is interesting to note that Cootes Store's data follows a positive trend relative to the other two sites. Strasburg's average cfs was by far the highest (to be expected).

Trimming reduced mean flow at each site (drops of ~10–15%), suggesting this procedure is cutting the higher peaks but not drastically changing the central tendency. AGWR values are already in a pretty solid range, but the trimming function improves these numbers slightly. We do see changes in the R-squared values when looking at before/after trimming, but these numbers are already quite weak (all occurrences < 0.3).

[willprokopik]

Quick Observations (for 9/2 meeting)

I didn't get the chance to dive super in-depth yet, and my code is very messy and needs a lot of cleaning up. But here are some interesting initial findings from running the baseflow ID against modeled stream flow.

Strasburg Event 14

Strasburg Event 31

Strasburg Event 65 (not good/clean)

Strasburg Event 94 (not good/clean)

[rburghol]

@willprokopik - Thanks for pushing this forward! Looking forward to discussing.

[willprokopik]

Updates

I cleaned up all of my code that deals with integrating dataframes (now USGS and model can be run interchangeably) with the Review App. Right now, these two scripts are located: AnalysisSetup and AppSetup. I also ran the Strasburg events that I put in the above comment from last week through the scatterplot visualization (got this code fully functional, just needs some cleaning and condensing).

[willprokopik]

Updates (9/16)

I fixed some bugs in the App Setup. I also finalized the Event Plotting script (scatterplots): EventScatterplots. Differences in the scale of these plots (comparing last weeks to previous scatterplots from a few weeks ago) was a minor issue that we talked about last week, and should be addressed in this script.

I also started brainstorming some ways to implement meteorological data into these analyses (adding precipitation data) as we discussed a couple weeks ago. I haven't gone too in-depth yet, but here's an idea of the general direction I was thinking in:

Add storm flags & dry-spell logic to event detection:
This could be just flagging things, or be used as a new "deciding" parameter...

flow_csv <- flow_csv %>%
  mutate(
    Rain = P_mm >= 1.0,                               #>=1 mm (~0.04") rain day
    DrySpell = if_else(Rain, 0L, 1L),                 #1 for dry
    DryRun = accumulate(DrySpell, ~ ifelse(.y==1, .x+1L, 0L), .init = 0L)[-1],
    P3  = slide_dbl(P_mm, ~ sum(.x, na.rm = TRUE), .before = 2, .complete = TRUE),
    P7  = slide_dbl(P_mm, ~ sum(.x, na.rm = TRUE), .before = 6, .complete = TRUE),
    P14 = slide_dbl(P_mm, ~ sum(.x, na.rm = TRUE), .before = 13, .complete = TRUE)
  )

[willprokopik]

Comparing non-"Post Processed" data to "Post Processed" data (implementing Ben's work)

To investigate the implications of Ben's Post-Processing function, I conducted a trial run on Strasburg scatterplots. I've reworked some of my original scatterplot code to provide some descriptive statistics for added context. The events highlighted in color are completely arbitrary, just wanted to display that some events do get dropped once they go through "post processing."

Non-Post Processed Plots

Post Processed Plots

[willprokopik]

Updates from 9/23 work session

I polished up the changes I made to the EventScatterplots script and pushed that script up. I didn't merge it, just wanted to keep it in this isolated branch for now just in case.

I will continue to investigate why we aren't seeing any variation in "Mean AGWR" in the plots I posted this morning that we discussed in the meeting.

[rburghol]

@willprokopik - Connor and I were discussing the fact that all points ended up being the same after Bens trend analysis filter was applied. We had a recollection that @benhdye may be storing these revised AGWRC(and R/p/dAGWRC) values in new columns on the dataframe, and there may be a good reason for that. If you can coordinate with Ben to sort that out we should be in business. The alternative is that Ben's script is not updating the data frames to have these new columns or revised stat analysis, if so, that needs to be done, and it needs to be saved in the CSV. Thanks!