Difficult Run Model Vs. Observed Comparisons

[rburghol]

Data Sets:

1. Raw model output from the CBP Phase 5.32 model performs in Difficult Run. (raw = HSPF channel routing output).
2. OM model of Difficult Run with only 1 channel, using Muskingum routing
3. OM model of Difficult Run with multiple channels, but no impoundments
4. OM model of Difficult Run with select impoudments added to network

With this data, then we can look at:

• how well does the "raw" model meet the Difficult Run gage (even though DRun was NOT used in calibration)
• What difference does the detailed routing model provide?
• What effect does the addition of small impoundments have on calibration?

Run IDs

• Run 1000 = Full Time Series (1984-2005), no impoundments, Difficult Run
• Run 6000 = NO Impoundments, 2000/01/01 - 2005/12/31,
• Run 7000 = NO Impoundments, wet year, 1989/01/01 - 1989/12/31,
• Run 7100 = All Impoundments, wet year, 1989/01/01 - 1989/12/31,
• Run 8000 = NO impoundments, event 1987-05-01 to 1987-05-15
• Runid 8100 = All impoundments, event 1987-05-01 to 1987-05-15
• Runid 9100 = Sensitivity analysis impoundments event 1987-05-01 to 1987-05-15

[connorb5]

Certainly. I'll get started on this as soon as I can (probably going to be tomorrow or the weekend though). Two quick questions:

1. How is the raw HSPF output different from our model with 0 channels and 0 impoundments? Shouldn't cbp_runoff_Runit * local_channel_area give us the HSPF output?
2. Do I just scale HSPF output using drainage area?

[rburghol]

1. HSPF output ~ our model with 1 channels and 0 impoundments (NOT ZERO channels - see #2 above)
2. HSPF INFLOW = cbp_runoff_Runit * local_channel_area
3. HSPF output = HSPF OUTFLOW ( cbp_runoff_Runit * local_channel_area routed through an FTABLE )
4. Do I just scale HSPF output using drainage area -- to compare to the gage? Yes.

[rburghol]

Super important note: set any object to run-mode = 0 will make Qout = local_channel_Qout, so effectively removing all impoundments (they still run, but their outflow doesn't affect the simulation). The simulation should force the run_mode from the top-most impoundment down to all tributaries, so if you run all of Difficjult Run, everything should inherit the Difficult Run setting, regardless of their local setting. But we should verify this since we have done a bunch of editing of subcomps.

[rburghol]

Note: All elements have had their Qout matrix restored to defaults.

Note to self when batch editing submatrices,

a single one: php batchedit_submatrix.php 104 Qout "0=local_channel_Qout" 340114

all of type custom1 = cova_ws_subnodal

php batchedit_submatrix.php 104 Qout "0=local_channel_Qout" "" "" cova_ws_subnodal 
php batchedit_submatrix.php 104 Qout "1=impoundment_Qout" "" "" cova_ws_subnodal 
php batchedit_submatrix.php 104 Qout "3=impoundment_Qout" "" "" cova_ws_subnodal 
php batchedit_submatrix.php 104 Qout "4=impoundment_Qout" "" "" cova_ws_subnodal 
php batchedit_submatrix.php 104 Qout "100=impoundment_Qout" "" "" cova_ws_subnodal 

[connorb5]

To be clear, I should be running the river segment that the data falls in correct? My results don't look anything like the gauge data (timing is completely off, ignore magnitude since I haven't scaled by DA yet) HSPF:

Our Gauge:

Old Model data:

[rburghol]

I can't tell a thing from that graph. Maybe a month or two?

On Tue, Feb 20, 2018 at 3:54 PM, connorb5 notifications@github.com wrote:

To be clear, I should be running the river segment that the data falls in correct? My results don't look anything like the gauge data (timing is completely off, ignore magnitude since I haven't scaled by DA yet) HSPF: [image: image] https://user-images.githubusercontent.com/31970347/36448466-b9e5fdbc-1655-11e8-899e-266deda6ca0c.png

Our Gauge: [image: image] https://user-images.githubusercontent.com/31970347/36448650-3d34f196-1656-11e8-8945-5662171a3b01.png

Old Model data: [image: image] https://user-images.githubusercontent.com/31970347/36448641-35aef002-1656-11e8-80dc-5c3f843adc4f.png

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/HARPgroup/cbp_wsm/issues/14#issuecomment-367115650, or mute the thread https://github.com/notifications/unsubscribe-auth/AEXAIn8Ujp_CM3Tb6s4S610kN6TNNEQ4ks5tWzDwgaJpZM4SHCSN .

--

Robert W. Burgholzer 'Making the simple complicated is commonplace; making the complicated simple, awesomely simple, that's creativity.' - Charles Mingus Athletics: http://athleticalgorithm.wordpress.com/ Science: http://robertwb.wordpress.com/ Wine: http://reesvineyard.wordpress.com/

[rburghol]

But you shouldn't have to scale it, if you are doing data set #1 listed above And, what script/command are you using to access the HSPF data?,

[rburghol]

To your first question, yes, the segment that the gage falls in is what is needed. But, if the segment is part of the Potomac main stem we need to change our expectations -- I haven't the faintest idea if this segment is simulating Potomac river AFTER Difficult Run comes in,or Difficult Run BEFORE it's confluence with the Potomac River -- you are the expert on this location so I defer to you to lay out the why's and wherefores of which model location to use -- then we can figure out the best strategy for evaluation if it's not simulating the Diff Run channel (i.e. Potomac).

We should also assemble a map to tell us what is going on here.

On Tue, Feb 20, 2018 at 5:10 PM, Robert Burgholzer rburghol@vt.edu wrote:

I can't tell a thing from that graph. Maybe a month or two?

On Tue, Feb 20, 2018 at 3:54 PM, connorb5 notifications@github.com wrote:

To be clear, I should be running the river segment that the data falls in correct? My results don't look anything like the gauge data (timing is completely off, ignore magnitude since I haven't scaled by DA yet) HSPF: [image: image] https://user-images.githubusercontent.com/31970347/36448466-b9e5fdbc-1655-11e8-899e-266deda6ca0c.png

Our Gauge: [image: image] https://user-images.githubusercontent.com/31970347/36448650-3d34f196-1656-11e8-8945-5662171a3b01.png

Old Model data: [image: image] https://user-images.githubusercontent.com/31970347/36448641-35aef002-1656-11e8-80dc-5c3f843adc4f.png

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/HARPgroup/cbp_wsm/issues/14#issuecomment-367115650, or mute the thread https://github.com/notifications/unsubscribe-auth/AEXAIn8Ujp_CM3Tb6s4S610kN6TNNEQ4ks5tWzDwgaJpZM4SHCSN .

--

Robert W. Burgholzer 'Making the simple complicated is commonplace; making the complicated simple, awesomely simple, that's creativity.' - Charles Mingus Athletics: http://athleticalgorithm.wordpress.com/ Science: http://robertwb.wordpress.com/ Wine: http://reesvineyard.wordpress.com/

--

Robert W. Burgholzer 'Making the simple complicated is commonplace; making the complicated simple, awesomely simple, that's creativity.' - Charles Mingus Athletics: http://athleticalgorithm.wordpress.com/ Science: http://robertwb.wordpress.com/ Wine: http://reesvineyard.wordpress.com/

[connorb5]

All right so here are some more explanatory graphs showing the wet month of May in 1989 (we've been using this for testing now for a while). See how HSPF is clearly predicting something differently: HSPF output (both in timing and magnitude): Previous Model Output (no impoundments, multiple channels): Gauge Output:

In the map below, you can see Difficult Run clearly falls in PM7_4580_4820 which is one of the downstream segments of the Potomac River:

So my guess here is that it is simulating Difficult Run after it enters the Potomac? My understanding was the OM model draws in this data and scales it by drainage area, but these graphs make it hard to believe due to the differences in timing. And this is why I'm confused. Because if our model was drawing data from this river segment, I don't see how we could have altered flow that much just with a couple channels. It seems more like I'm simulating the wrong segment, but I don't know which other one would be correct.

For reference, I generated the HSPF data using:

cd /opt/model/p53/p532c-sova/run/standard
run_all.csh  p532cal_062211 PM7_4580_4820
cd /opt/model/p53/p532c-sova/tmp/wdm/river/p532cal_062211/stream
/opt/model/p53/p532c-sova/code/bin/quick_wdm_2_txt_hour_2_hour
and entered PM7_4580_4820.wdm, 1984, 2005, 111

[rburghol]

OK - that's much clearer. For clarity, OM brings in runoff, multiplies it by area, and then routes it through a channel. What we are showing here is that this CBP segment is indeed modeling the main stem of the Potomac. Thus, there is no analogous output from the CBP model for our study area -- so this means no. 1 is out. We should have assembled this image beforehand, and we would have gotten this straight ahead of time.

So now, it seems we need to go on to item no. 2.

[connorb5]

Okay, so runoff is different then channel flow. It looks like I need to go back and read some of the documentation in the CBP model. I knew our model used the Runit from the CBP model, but I had originally assumed that was also driving the HSPF flow. So, I need to go back and look at that while I start running step 2.

[rburghol]

Runit IS driving the flow in HSPF, but HSPF has it's own channel simulation as well. (that's where the run_river.csh program in CBP/HSPF coms into play).

On Wed, Feb 21, 2018 at 12:26 PM, connorb5 notifications@github.com wrote:

Okay, so runoff is different then channel flow. It looks like I need to go back and read some of the documentation in the CBP model. I knew our model used the Runit from the CBP model, but I had originally assumed that was also driving the HSPF flow. So, I need to go back and look at that while I start running step 2.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/HARPgroup/cbp_wsm/issues/14#issuecomment-367404253, or mute the thread https://github.com/notifications/unsubscribe-auth/AEXAIoxM_s7rJyr44XaMksd9wJycQjCHks5tXFHagaJpZM4SHCSN .

--

Robert W. Burgholzer 'Making the simple complicated is commonplace; making the complicated simple, awesomely simple, that's creativity.' - Charles Mingus Athletics: http://athleticalgorithm.wordpress.com/ Science: http://robertwb.wordpress.com/ Wine: http://reesvineyard.wordpress.com/

[rburghol]

To expand -- in the CBP/HSPF it goes like this:

• run_land.csh -- does the runoff simulation which results in a unit area flow (what we call Runit in OM).
• run_etm.csh -- does some output formatting and aggregation of unit area flows, multiplying them by their respective land use areas to get a volumentric flow rate (aka cfs)
• run_river.csh -- does the river channel simulation using the runoff values that were generated in run_land.csh and scaled and reformatted in run_etm.csh
• IN OM, we just harvest the data from run_land.csh, do our own land use area multiplying (so we can reflect our version of the land use), and then do our own channel routing routine.

On Wed, Feb 21, 2018 at 12:53 PM, Robert Burgholzer rburghol@vt.edu wrote:

Runit IS driving the flow in HSPF, but HSPF has it's own channel simulation as well. (that's where the run_river.csh program in CBP/HSPF coms into play).

On Wed, Feb 21, 2018 at 12:26 PM, connorb5 notifications@github.com wrote:

Okay, so runoff is different then channel flow. It looks like I need to go back and read some of the documentation in the CBP model. I knew our model used the Runit from the CBP model, but I had originally assumed that was also driving the HSPF flow. So, I need to go back and look at that while I start running step 2.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/HARPgroup/cbp_wsm/issues/14#issuecomment-367404253, or mute the thread https://github.com/notifications/unsubscribe-auth/AEXAIoxM_s7rJyr44XaMksd9wJycQjCHks5tXFHagaJpZM4SHCSN .

--

Robert W. Burgholzer 'Making the simple complicated is commonplace; making the complicated simple, awesomely simple, that's creativity.' - Charles Mingus Athletics: http://athleticalgorithm.wordpress.com/ Science: http://robertwb.wordpress.com/ Wine: http://reesvineyard.wordpress.com/

--

Robert W. Burgholzer 'Making the simple complicated is commonplace; making the complicated simple, awesomely simple, that's creativity.' - Charles Mingus Athletics: http://athleticalgorithm.wordpress.com/ Science: http://robertwb.wordpress.com/ Wine: http://reesvineyard.wordpress.com/

[rburghol]

I have created an element for doing comparison #2, that is, a single channel with runoff routed through an OM channel object representing the entirety of Difficult Run. Since there is no impoundment at the outlet of Difficult Run, this is always modeled as a simple channel (Qout =local_channel_Qout always). Info is (obtained from NHD routine):

• elementid = 340268
• local area: 58.3 sqmi
• watershed area: 58.3 sqmi
• channel length = 77,502.3 ft

[connorb5]

I started running comparison two, using run ids representative of the dates I ran them. One thing to note is that I shrank the channel length to 50052.5 ft as this represents the longest combined channel length in our impoundment model (aka the length of the outlet to the highest modeled channel). The number 77502.3 represents the longest possible flow length in Difficult Run. It should not have been in either model, so that's my bad for leaving that in there. This long path includes portions of the stream that are completely unimpounded (or at least by our 10 or so impoundmnets right now). Using this length would account for stream lengths not present in channel three. The picture below shows the longest modeled path as a hihglighted blue channel and the 77502.3 path circled.

[connorb5]

Sorry, actual flow path is 46068.1 ft. I forgot the gauge wasn't at the watershed outlet and I want to model up to the gauge and not beyond....

[rburghol]

The 77,000 flow path was not a left over from your earlier entries. I created this model element entirely from scratch and I populated the flow path from the NHD plus estimation routine that I use. I’m not saying it’s the right one, I’m just saying it wasn’t from some mistake that you made. Now why do you feel like the flow path should be 46,000? I’m not saying that It should or it shouldn’t be, I just don’t understand how you arrived at that number. He even more important of course is, what does changing the channel length impact?

[connorb5]

Oh okay, cool. Glad that wasn't something I left in. So I think it should be 46,000 because it is the longest flow path that is currently modeled by our impoundments. We can change this, but if you were to add up all the channel lengths that is the longest path you'd arrive at. The circled path above (which is 77000 ft from the outlet) is not populated by any impoundments currently in the system with upstream lengths. Hopefully that makes more sense, otherwise I can demonstrate at tomorrow's meeting. The only reason I believe it to be important is that it better represents what we're trying to prove (I think). That the addition of a more detailed flow network (eventually with impoundments) improve model flows as compared to gauge data. If we were to use the larger path, we'd have to route all of our impounded flow in the circled branch which doesn't seem realistic to me at all (unless I'm still looking at this analysis in the wrong way)

[rburghol]

OK -- if I understand you correctly, you are saying that in order to have an apples to apples comparison between Scenarios 2, 3 and 4 we should have a uniform maximum flow path? That makes sense to me, though our normal process is to use the NHD routine defaults, which apparently captures the longest flow path -- so we are deviating from that path -- scenario #2 shows us our "downscaling business as usual". It will be important for us to understand the impact of that flow length variable --and also, why WOULDN'T we choose to model the longest flow path? My sense is that a longer channel length will attenuate peak flows -- but I don't know by how much.

In the end, I think our objective is to understand:

1. What happens when we add impoundments to a flow network and how these impoundments affect the pre-existing ecosystem services.
2. What happens when we calibrate a model (successfully) without representing all of the small impoundments in the landscape (this is business as usual for EVERYONE since no project tackles this).
3. By inference, how adding new impoundments to the landscape in the future (for stormwater control for example) might affect the instream flows and eco-system services.

For runids, let's stick with the one defined at the top of this issue (and expand that list as needed). Thus we will always know that, run 1000 will always be a no impoundment, full time series run, regardless of when we ran it -- we will know that is what it represents (otherwise, how am I to know that you ran what on which dates?). Similarly run 7000 will be 1 year no imps, 7100 will be 1-year WITH imps, etc.

[rburghol]

Run 7000, element 340268 versus USGS gage, May 5-10 1989:

Stats for calendar year 1989:

quantile(round(dat$Qout)) 0% 25% 50% 75% 100% 0 15 33 67 2498 quantile(dat$Qusgs) 0% 25% 50% 75% 100% 10 27 38 60 2310

[rburghol]

So what were you just trying to run? Seems like it died?

[rburghol]

Just kicked off run 6000 - from 2000-2005

[connorb5]

Yeah that was what I was trying to get at with the channel lengths. I figured if we want to explore channel length alteration we can play around with it while testing scenario 3 (create identical impoundments but change channel lengths). Oops totally missed the naming scheme. Yeah I can follow that, it'll make it easier than having to share our collective notes and definitions. Except I may break run 1000 into 4 (runids 1001-1004) because I've had trouble running models for greater than 5 years (they can't load for some reason or sometimes they die). And yeah my run died. I finally figured out it was because I was trying to run them on deq2 and not deq1 so they weren't working. Easy fix, I'll redo it for some of the earlier runs once 6000 finishes

Last thing to note: We eventually have to test the point source data. It might be best to do this as an intermediate b/t scenarios 2 and 3.

[rburghol]

OK - I think your reasoning on the channel lengths makes a lot of sense. I propose that the line that you circled represents the "main stem" of difficult run, and that we should include that in the full channel length of the outlet segment.

my run died. I finally figured out it was because I was trying to run them on deq2 and not deq1

Great -- that was really bothering me!! Maybe that's why longer runs were failing? deq2 should be capable of running the model (though I haven't tested it, it's just there as a backup copy), the likely reason they are dying is that while deq2 has the same modeling code as deq1, I have not set the server up to allow processes to run for several minutes -- default is to kill anything that runs over 1 minute in duration, so I think you should be OK running 5 years, even 20 -- let's try it out and see.

Last thing to note: We eventually have to test the point source data. It might be best to do this as an intermediate b/t scenarios 2 and 3.

Thanks for remembering -- this is critical, and also, we need to make sure that we have withdrawal as well (if they are surface water withdrawals.

[connorb5]

I tried the long run of 1984 - 2005 for the stand alone object (run id 1000). It ran as normal, but it is not showing up in the data analysis tab so it must have died. I had this problem in the past too and found it easier to just break up the timeseries into 4 and combine them later. If at all possible, I'd like to do this tomorrow or on Monday. I want to begin compiling statistics and graphs for these runs to compare against scenario 3 and 4. I've almost fixed all of the impoundments so I can begin running the outlined scenarios within the next few days

[rburghol]

There should be no need to break it up into 4 runs. If it dies it means there is an error somewhere, or you are querying variables in the analysis window that no longer exist. Maybe the 1 hour timestep is causing issues I have not encountered before but I am doubtful.

Regardless, we should first work out the kinks in small runs before we even think of attempting a 20 year run. We also need to agree on what the main channel length will be.

On Sun, Feb 25, 2018 at 1:45 AM connorb5 notifications@github.com wrote:

I tried the long run of 1984 - 2005 for the stand alone object (run id 1000). It ran as normal, but it is not showing up in the data analysis tab so it must have died. I had this problem in the past too and found it easier to just break up the timeseries into 4 and combine them later. If at all possible, I'd like to do this tomorrow or on Monday. I want to begin compiling statistics and graphs for these runs to compare against scenario 3 and 4. I've almost fixed all of the impoundments so I can begin running the outlined scenarios within the next few days

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/HARPgroup/cbp_wsm/issues/14#issuecomment-368287793, or mute the thread https://github.com/notifications/unsubscribe-auth/AEXAIlc9VBWYCsEsWkrA0L2eDE2-ldpvks5tYQGAgaJpZM4SHCSN .

--

Robert W. Burgholzer 'Making the simple complicated is commonplace; making the complicated simple, awesomely simple, that's creativity.' - Charles Mingus Athletics: http://athleticalgorithm.wordpress.com/ Science: http://robertwb.wordpress.com/ Wine: http://reesvineyard.wordpress.com/

[rburghol]

I will look to see if we have issues with memory for a 20 year run — but if we have to split up into chunks then we’ll be limited in our ability to analyze them as a whole. So first let me see what I can do with looking into this.

[rburghol]

Running a 20 year test now with expanded memory settings. But I will figure out whatever it is. First thiugh lets get the bugs and the sensitivity analysis sorted.

[rburghol]

This runs fine — loading the data into the analysis tables was glitching but seems to be OK now. But still, we are a long way off from needing to think about 20 year runs — until we really understand whats happening at the event and 1-year level we can keep pur powder dry on the long term ones (5-20).

[connorb5]

Okay, well thanks for looking into that! Down the road I'm sure it'll help to run the 20 years at once rather than having to break it up and deal with four separate phases of warm-up. As for the sensitivity analysis and these 1 - 5 year events, I want to be clear I'm preceeding down the right path. When you get the chance, please review the files I've placed in the following Drive folder. This contains the statistics I'm tracking between runs as well as the images showing scenario 2 vs. 3. To me, it appears the statistics I'm tracking are doing a decent job of capturing the changes in flow but I want to make sure I'm not missing anything before I move forward with scenario 4 i.e. impounded runs https://drive.google.com/drive/u/0/folders/1zr7lHPqdAo4bScgTgQFdzzSYq4_7YGtt

[rburghol]

As for the stats, those are good, but things like ALF, DoR and 7Q10 won't have much relevance for the sensitivity analysis and short term analysis. For the 1 year analysis, we can at least calculate ALF and DoR but they are just a summary of the minimum daily value in August and the minimum 90 day flow. What about the 1,3 and 7 day high and low flows? Also, do you have an idea for how long we should make our warmup period? If say it's 1 month, then we will want to make these runs start a month earlier.

Three more things :

1. Can you put a spreadsheet in there to list our impoundments and the calculations that you made (or point me to where one is)
2. Have you looked at the bundle of docs that I sent with lake designs for one of those lakes? Wondering if there is outlet geometry in there, if so, that would be at least 1 calibration point for the estimation procedure you are developing.
3. Quick question -- what's the difference between scenario 2 and 3?

On Mon, Feb 26, 2018 at 1:51 PM, connorb5 notifications@github.com wrote:

Okay, well thanks for looking into that! Down the road I'm sure it'll help to run the 20 years at once rather than having to break it up and deal with four separate phases of warm-up. As for the sensitivity analysis and these 1 - 5 year events, I want to be clear I'm preceeding down the right path. When you get the chance, please review the files I've placed in the following Drive folder. This contains the statistics I'm tracking between runs as well as the images showing scenario 2 vs. 3. To me, it appears the statistics I'm tracking are doing a decent job of capturing the changes in flow but I want to make sure I'm not missing anything before I move forward with scenario 4 i.e. impounded runs https://drive.google.com/drive/u/0/folders/1zr7lHPqdAo4bScgTgQFdzzSYq4_ 7YGtt

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/HARPgroup/cbp_wsm/issues/14#issuecomment-368607366, or mute the thread https://github.com/notifications/unsubscribe-auth/AEXAIid-MyxyOtHljhLynI60hqPXgNyDks5tYv0ugaJpZM4SHCSN .

--

Robert W. Burgholzer 'Making the simple complicated is commonplace; making the complicated simple, awesomely simple, that's creativity.' - Charles Mingus Athletics: http://athleticalgorithm.wordpress.com/ Science: http://robertwb.wordpress.com/ Wine: http://reesvineyard.wordpress.com/

[connorb5]

Yeah, I can go ahead and include the 1, 3, and 7 day flows in my script.

1. If you check the folder again you will find a new excel sheet with all of my bathymetry 'calculations'. This is in quotations because we regress maximum and normal volume (calculations included) but then iterativley solve for stage and surface area using solver. My methods are included within the spreadsheet, but you won't be able to just click a cell and see how it was calculated. I've additionally placed two scripts in there: FlowStat.R and DesignStorms.R These contain the remaining calculations. DesignStorms.R calculates outlet from USGS regressions and delineations while FlowStat.R comes up with all the statistics I've been calculating. Compilation into a single excel sheet would take a long time and I'm not fully sure it would be worthwhile as most of the source data would be generated externally.
2. I looked through the Lake Anne documentation a while back. The only thing of value in the reports was rough estimates for lake depth. There was no information pertaining to the outlet, as the study was primarily focused on water withdraw below normal stage.
3. Scenario refers to the datasets listed in this issue queue at the beginning. 1) HSPF (can't do this) 2) One channel, no impoundments 3) multiple channels 4) impoundments. I'm moving into scenario 4 soon.

have much relevance for the sensitivity analysis and short term analysis

Now I think I'm still confused. I thought this whole process was the sensitivity analysis. At the top, you've reserved runid 9000 for the sensitivity analysis. What does this mean? All of the other runids make sense to me and I can follow along, but I thought the sensitivity analysis was the act of slowly introducing each of these model components and assessing effects i.e. I thought the comparison of runids 7000 with 7100 was a sensitivity analysis.

[rburghol]

Sensitivity would be a very limited analysis with varying impoundment sizes and outlet dimensions. We began it, and I thought you outlined several scenarios for outlet length (2 through 128’?), and I think we said those would be scenarios 9000-9006 or so (but if I failed to communicate 900x scenarios in that threadnI apologize).

We need those sensitivity analysis outlet dimensions to encompass the range of impoundment sizes and drainage areas that you find in your method of calculating outlets. But then you can iterate through the 3-dimensional grid of DA/outlet/volume in a set of scenarios run over a short, wet period for only a single test impoundment, and maybe a 2nd set of especially dry conditions. Then we will know how the assumptions that you put into your outlet estimation affect the reality of our landscape.

And then, armed with that info we can proceed into these full drainage runs. Knowing full well what to expect and thus, when our model is giving counterintuitive output. Without the SA it becomes very difficult to say “these impoundments don’t really change the flows” or “these imps DO change the flows”, or “these imps change certain flows but not others”. Also, we can say “if we double the # of impoundments that are less than xx drainage area we might see an additional alteration of yy”.

And perhaps most importantly, we can say if the estimation process you used exposes the analysis to bias or is particularly vulnerable to specific errors in the input process. In other words, which inputs are most sensitive?

On Mon, Feb 26, 2018 at 5:57 PM connorb5 notifications@github.com wrote:

Yeah, I can go ahead and include the 1, 3, and 7 day flows in my script.

1. If you check the folder again you will find a new excel sheet with all of my bathymetry 'calculations'. This is in quotations because we regress maximum and normal volume (calculations included) but then iterativley solve for stage and surface area using solver. My methods are included within the spreadsheet, but you won't be able to just click a cell and see how it was calculated. I've additionally placed two scripts in there: FlowStat.R and DesignStorms.R These contain the remaining calculations. DesignStorms.R calculates outlet from USGS regressions and delineations while FlowStat.R comes up with all the statistics I've been calculating. Compilation into a single excel sheet would take a long time and I'm not fully sure it would be worthwhile as most of the source data would be generated externally.
2. I looked through the Lake Anne documentation a while back. The only thing of value in the reports was rough estimates for lake depth. There was no information pertaining to the outlet, as the study was primarily focused on water withdraw below normal stage.
3. Scenario refers to the datasets listed in this issue queue at the beginning. 1) HSPF (can't do this) 2) One channel, no impoundments 3) multiple channels 4) impoundments. I'm moving into scenario 4 soon.

have much relevance for the sensitivity analysis and short term analysis

Now I think I'm still confused. I thought this whole process was the sensitivity analysis. At the top, you've reserved runid 9000 for the sensitivity analysis. What does this mean? All of the other runids make sense to me and I can follow along, but I thought the sensitivity analysis was the act of slowly introducing each of these model components and assessing effects i.e. I thought the comparison of runids 7000 with 7100 was a sensitivity analysis.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/HARPgroup/cbp_wsm/issues/14#issuecomment-368681197, or mute the thread https://github.com/notifications/unsubscribe-auth/AEXAIrzqXQi6KttTX6x61bC3HN16xd8qks5tYza5gaJpZM4SHCSN .

--

Robert W. Burgholzer 'Making the simple complicated is commonplace; making the complicated simple, awesomely simple, that's creativity.' - Charles Mingus Athletics: http://athleticalgorithm.wordpress.com/ Science: http://robertwb.wordpress.com/ Wine: http://reesvineyard.wordpress.com/

[connorb5]

Okay, that makes sense. I wasn't sure exactly what we were doing here but this lays it out a little better. I can use the same outlet strategy, and then I can iterativley decrease/increase volume by fixed percentages or some set increase of volume. I need to get moving on this, so I'll be starting today and hopefully have some results before the end of the week (there is a USGS meeting on March 8th and I would like some prelim results again).

But then you can iterate through the 3-dimensional grid of DA/outlet/volume in a set of scenarios

Does this imply I should create some runs where I change all three variables at once? I believe the first step is to change each variable one at a time, but is this the second? Trying to set up a few scenarios that I can describe based on what I learn from the one-at-a-time testing? Sorry for all the questions, I just want to make sure I can document this well in the future.

[rburghol]

Ah good question, I think the strategy that you mention of one at a time first is the right way to go. Then you can look at those results and decide how many of the combined iterations you need to describe the space.

On Tue, Feb 27, 2018 at 8:18 AM connorb5 notifications@github.com wrote:

Okay, that makes sense. I wasn't sure exactly what we were doing here but this lays it out a little better. I can use the same outlet strategy, and then I can iterativley decrease/increase volume by fixed percentages or some set increase of volume. I need to get moving on this, so I'll be starting today and hopefully have some results before the end of the week (there is a USGS meeting on March 8th and I would like some prelim results again).

But then you can iterate through the 3-dimensional grid of DA/outlet/volume in a set of scenarios

Does this imply I should create some runs where I change all three variables at once? I believe the first step is to change each variable one at a time, but is this the second? Trying to set up a few scenarios that I can describe based on what I learn from the one-at-a-time testing? Sorry for all the questions, I just want to make sure I can document this well in the future.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/HARPgroup/cbp_wsm/issues/14#issuecomment-368869963, or mute the thread https://github.com/notifications/unsubscribe-auth/AEXAImOv7i-DK3JjGPkp2y-yTH6zUomAks5tZACFgaJpZM4SHCSN .

--

Robert W. Burgholzer 'Making the simple complicated is commonplace; making the complicated simple, awesomely simple, that's creativity.' - Charles Mingus Athletics: http://athleticalgorithm.wordpress.com/ Science: http://robertwb.wordpress.com/ Wine: http://reesvineyard.wordpress.com/

[connorb5]

Okay, thanks Rob! I think I have my path forward then.

[connorb5]

For the sensitivity testing, did you mean the 1989 storm we've been looking at? This one in 1987 is only about 10 cfs for a 1 square mile drainage area (as opposed to 100 cfs we were looking at)

[rburghol]

Sorry if I goofed that — you tell me the best single event to look at and I shall! If we have time we might want to do a mass balance on That 100 cfs storm, seems like about a 3” runoff event? Just for sanity checks.

On Tue, Feb 27, 2018 at 4:27 PM connorb5 notifications@github.com wrote:

For the sensitivity testing, did you mean the 1989 storm we've been looking at? This one in 1987 is only about 10 cfs for a 1 square mile drainage area (as opposed to 100 cfs we were looking at)—

You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/HARPgroup/cbp_wsm/issues/14#issuecomment-369032015, or mute the thread https://github.com/notifications/unsubscribe-auth/AEXAIkneldXG0qZYgwliYJxh-N8xCsLeks5tZHNCgaJpZM4SHCSN .

--

Robert W. Burgholzer 'Making the simple complicated is commonplace; making the complicated simple, awesomely simple, that's creativity.' - Charles Mingus Athletics: http://athleticalgorithm.wordpress.com/ Science: http://robertwb.wordpress.com/ Wine: http://reesvineyard.wordpress.com/

[connorb5]

Okay, well then maybe this 1987 period serves as good reference for a dryer period with lower flows. Attached is a spreadsheet (see sheet 2) showing how our flow metrics change as I iterativley and individually change outlet, drainage area, floodplain side slope, normal storage, and maximum storage. Storage has basically no effect by itself on flow alteration and this should be expected; unless the impoundment overtops, added storage can be basically considered as dead storage as it is never activated. They affect riser diameter in my calculations, but ultimatley that is shown by the flow alteration caused by changes in outlet structure. Drainage area obviously plays a large role in flow alteration, setting how much water enter the impoundment. Side slope played minor changes here, but may play a bigger role under larger storm conditions. I'll recreate this spreadsheet tomorrow using the larger 1989 storm. Should be interesting to look at. I'd expect storage to still play a small role by itself, so I may do less iterations of that (as it takes forever to manually enter some of the larger stage storage tables). There is an r code in this folder that will allow you to compare any two run if you wish to see the alteration for yourself: https://drive.google.com/open?id=14Hj0aaEPaKkK6FFhF-htu5vQpeE0JXaT sensitivity.xlsx

[rburghol]

Good stuff -- just a caution, I wouldn't be so quick to decide that the storage effect (or lack thereof) is sensible. Storage should affect head, and head should affect outflow. So our method of estimation of the stage/storage may be at play here. Also, during droughts (if we have evap properly included) levels may draw down below full, resulting in a great effect during refill.

On Tue, Feb 27, 2018 at 10:23 PM, connorb5 notifications@github.com wrote:

Okay, well then maybe this 1987 period serves as good reference for a dryer period with lower flows. Attached is a spreadsheet (see sheet 2) showing how our flow metrics change as I iterativley and individually change outlet, drainage area, floodplain side slope, normal storage, and maximum storage. Storage has basically no effect by itself on flow alteration and this should be expected; unless the impoundment overtops, added storage can be basically considered as dead storage as it is never activated. They affect riser diameter in my calculations, but ultimatley that is shown by the flow alteration caused by changes in outlet structure. Drainage area obviously plays a large role in flow alteration, setting how much water enter the impoundment. Side slope played minor changes here, but may play a bigger role under larger storm conditions. I'll recreate this spreadsheet tomorrow using the larger 1989 storm. Should be interesting to look at. I'd expect storage to still play a small role by itself, so I may do less iterations of that (as it takes forever to manually enter some of the larger stage storage tables). There is an r code in this folder that will allow you to compare any two run if you wish to see the alteration for yourself: https://drive.google.com/open?id=14Hj0aaEPaKkK6FFhF- htu5vQpeE0JXaT sensitivity.xlsx https://github.com/HARPgroup/cbp_wsm/files/1765483/sensitivity.xlsx

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/HARPgroup/cbp_wsm/issues/14#issuecomment-369108845, or mute the thread https://github.com/notifications/unsubscribe-auth/AEXAInl2lQqqglOLXS6sDdY3uXMouXJfks5tZMbAgaJpZM4SHCSN .

--

Robert W. Burgholzer 'Making the simple complicated is commonplace; making the complicated simple, awesomely simple, that's creativity.' - Charles Mingus Athletics: http://athleticalgorithm.wordpress.com/ Science: http://robertwb.wordpress.com/ Wine: http://reesvineyard.wordpress.com/

[connorb5]

I'll keep testing storage, but I think the more important factor is side slope which determines how quickly storage changes relative to stage. Storage itself will play a lesser role, but we'll see what the data shows!

Do we have evap included? I think I opened a pull request on Git but I don't think it had been resolved yet (basically just lumped et and precip in with Qin).

[rburghol]

Working on evap/precip now!

On Wed, Feb 28, 2018 at 11:28 AM, connorb5 notifications@github.com wrote:

I'll keep testing storage, but I think the more important factor is side slope which determines how quickly storage changes relative to stage. Storage itself will play a lesser role, but we'll see what the data shows!

Do we have evap included? I think I opened a pull request on Git but I don't think it had been resolved yet (basically just lumped et and precip in with Qin).

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/HARPgroup/cbp_wsm/issues/14#issuecomment-369292874, or mute the thread https://github.com/notifications/unsubscribe-auth/AEXAIjvWXjOKjR9MX_ne_CpCaXQZf1m2ks5tZXxvgaJpZM4SHCSN .

--

Robert W. Burgholzer 'Making the simple complicated is commonplace; making the complicated simple, awesomely simple, that's creativity.' - Charles Mingus Athletics: http://athleticalgorithm.wordpress.com/ Science: http://robertwb.wordpress.com/ Wine: http://reesvineyard.wordpress.com/

[rburghol]

Evap and precip good to go. Run 8000 and 8100 have been rerun for entire watershed.

[connorb5]

Finished my sensitivity testing for a wetter period. You can see storage by itself still has little effect. Main contributors to alteration are outlet width and drainage area. You can see that the alteration from inflow is nearly similar to that where just outlet width changes. There are some slight differences, but it's largely the same. Channel length, maximum storage, normal storage, and floodplain side-slope played little impact; however, this may not always be the case. These short term runs are useful in quick checks, but may not capture, say, long term low flow alteration due to storage built up after several storms or a longer than usual wet season. At the bottom of the spreadsheet, I've included two runs where I change both storage and outlet width. Any thoughts on how I should proceed? I feel like I have a very good grasp of what is causing our alteration, but I still expect trends I haven't seen yet (i.e. changing pond side-slope should change flow alteration, but this has not been the case). Maybe do a couple of longer runs for my test pond? sensitivity.xlsx

Thanks for getting the evap working! That will definitely add some realism during the summer

[rburghol]

• I can't ascertain much from those tables and charts. What do the events look like? Some of the comparison overlaid hydrographs that you did earlier could be useful.
• It strikes me as odd that run 9506 looks more like something halfway between run 9502 and 9503 (are you using R to retrieve these? You absolutely should be -- we should meet and share scripts on this).
• As for the volume, the 90% flow seems to change by 20% with a volume change from 150 to 250, that's a pretty significant change in my opinion. I am not saying you are wrong that these are not important, but , to make your case that it isn't you will need more insightful graphs and/or metrics.
• The big one that is missing , to me, is how does DA affect your methods riser length? We need to know that.

Also, we have to be on the look out for whether or not our metrics are up to the task -- and without looking at detailed hydrographs how can we know what metrics to test? Better summary tables of the ranges that you see would help.

On Thu, Mar 1, 2018 at 9:21 AM, connorb5 notifications@github.com wrote:

Finished my sensitivity testing for a wetter period. You can see storage by itself still has little effect. Main contributors to alteration are outlet width and drainage area. You can see that the alteration from inflow is nearly similar to that where just outlet width changes. There are some slight differences, but it's largely the same. Channel length, maximum storage, normal storage, and floodplain side-slope played little impact; however, this may not always be the case. These short term runs are useful in quick checks, but may not capture, say, long term low flow alteration due to storage built up after several storms or a longer than usual wet season. At the bottom of the spreadsheet, I've included two runs where I change both storage and outlet width. Any thoughts on how I should proceed? I feel like I have a very good grasp of what is causing our alteration, but I still expect trends I haven't seen yet (i.e. changing pond side-slope should change flow alteration, but this has not been the case). Maybe do a couple of longer runs for my test pond? sensitivity.xlsx https://github.com/HARPgroup/cbp_wsm/files/1771455/sensitivity.xlsx

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/HARPgroup/cbp_wsm/issues/14#issuecomment-369606118, or mute the thread https://github.com/notifications/unsubscribe-auth/AEXAIqnT9cyP8RbVK2LutALVH4HJPkgOks5taAPZgaJpZM4SHCSN .

--

Robert W. Burgholzer 'Making the simple complicated is commonplace; making the complicated simple, awesomely simple, that's creativity.' - Charles Mingus Athletics: http://athleticalgorithm.wordpress.com/ Science: http://robertwb.wordpress.com/ Wine: http://reesvineyard.wordpress.com/

[connorb5]

I'll see what I can spin-up tonight! Should be easy enough to recreate all the hydrographs

Quick comments:

1. I am using R, the code is linked above if you'd like to see some of the data (it will generate all stats for two runs and plot them against each other)

2. High volume flow estimates have been acting weirdly. We saw this in my analysis on Lake Anne and Lake Thoreau a while back. It's one of the primary things I want your opinion on once I plot these hydrographs bc it has been confusing me why they act so randomly with larger orifices. 9506 is shown in blue below, 9507 in red. You can see 9506 is just very tall and narrow compared to 9507 (note that this is captured in the flow transient rise/fall stats)

3. DA directly affects my riser length calculations. Risers are designed from regressions that use DA. However, I thought the purpose of this analysis was to change one variable at a time, not show the outputs of my methods for various watershed locations? If we want to show the latter, the easiest way is to just run all 11 impoundments and look at their hydrographs.

[rburghol]

1. Checked it -- you should be good getting the data, so it must be something else.
2. I would not suspect that high flows are acting weird, rather I would think you have 1 run that is erroneous, likely not parameterized like you think (maybe "run mode" setting was 0 for that run?).
3. That would change too many variables IMO (channel, riser, upstream inflows), a few well thought out runs should get you where you want to go.

[connorb5]

Hydrographs can be found in the folder below. Darker lines imply small values of whatever attribute is in the title. NormStoHydrograph.png for instance shows how changing normal storage affects flow. Drainage area and outlet are the key contributors here, with storage playing small effects overall. In some instances, storage can affect flow, but not to the same degree as outlet width and da. I'll keep working towards creating some runs that show all of what we're looking at https://drive.google.com/open?id=1zsdKGL1N_AaclEWoWjldg8enwws94ICv

[rburghol]

Connor -- food for thought re: the role that aggregation at a daily timestep does to the hydrograph, and I think we aggregate to daily for all of our flow metrics? Low flows may not be altered much with this, but peaks certainly will be.

• yellow/green is modeled hourly with and without impoundments
• blue is USGS daily
• red is modeled aggregated to daily

[connorb5]

Metrics are calculated at the daily timestep. I plotted the hydrographs at an hourly point because I want to make sure we're capturing the overall alteration and it doens't necessarily show up at a daily timestep. They might blur with daily aggregation, but we will certainly capture long term trends if we can describe short term changes. As a heads up, Tyler and I are running the overall model for 20 years. We both want some preliminary results for our meetings and we're interested to see the trends in ET. Look for some new figures and stats at the next HARP meeting