Need to ramp benefit by day of year as well as flow value

[nickrsan]

We should ramp benefit up and down by day of year and flow value. Flow value code already exists, but time code doesn't. If we establish a day of year window (a week?) or a per-component day of year window to ramp with, then we can make a benefit multiplier based on that.

If we refactor the code a bit, the same calculations can be used, but with the qs being class variables, we'd need to think about how to repurpose the ramping code. Might also not want to center the slope on the day of year values, but have it ramp up and be at 1 at the beginning of the time window and ramp down starting after the time window is over. Consider best way to reuse code and include both and multiply them together.

Also would then need to add it to the thesis LaTeX

[nickrsan]

Still need to:

• Determine if we want the interaction between the time window and the flow window to be averaged (add them and divide by two) or multiplicative. For example, a time benefit of 50% (at the end of the window, eg) and flow benefit of 100% currently yield a benefit of 50%. Not sure if we want that. A averaged benefit would give us 75%.
• Test the rollovers and confirm the behavior with Sarah and Jay. If we have a time window that is valid for almost the whole year, then the rampdowns might interfere with the rampups, but not actually be correctly considered. The current math doesn't handle this situation well. The key thing is it probably doesn't need to, but maybe we'd want a flag detecting it and warning people if their rampdown or ramp up goes outside the time window? We might have flow components that cross the water year though, even if they're not whole year items, so maybe a fall flushing flow actually has a rampup at the end of the last water year. I need to figure out how I want to handle that.
• Fix the plots so the labeled points are in the correct spots and add a title indicating the flow and time window
• Add the ability to generate a surface (x:flow combinations, y: date, z: benefit) - can store it as a numpy array and just visualize it. The surface could be the most computationally efficient usage if we actually plan to use the whole water year!
• Add color scale to surface plots
• Figure out ledge behavior (see later comments) related to narrow windows and wider margins

[nickrsan]

Sample image 1 - flow benefit for a time in middle of time window

Sample image 2 - flow benefit for time at the edge of the time window

[nickrsan]

Decided to keep the benefit as a multiplicative combination - an average would mean that a time benefit of zero and a flow benefit of 100 was still 50% benefit, and even bounds checking wouldn't help because 1% and 100% produce a similar result. The multiplication method seems like it can produce more swings, but incentivizes both timing and flows together, where previously, a decent result could be had with only one of the two, and that's not how the system actually behaves

[nickrsan]

Sample new graphic

[nickrsan]

Title indicates the flow bounds for the component (200-400 CFS) and the days of the water year that it represents (day 50 to day 80), as well as the day that benefit is calculated for.

[nickrsan]

Can generate surfaces now - they're a bit computationally slow, but if used well, could be a great way to just get the values once, then move on. It's generated on demand, so we can see how it goes and switch between the entire year's benefit and a single day's as needed.

Y is day of water year, X is flow. We'll want to set some kind of color scaling that tops out 0 to 1, since right now, if it wasn't 1 as the max value, it'd still get that color.

[nickrsan]

New image for annual benefit

I did explicitly set the color scale min and max, but realized it's not necessary, I think - as planned, there should almost always be something that has a benefit of 1. But narrow flow component windows with large margins could change that.

[nickrsan]

Here's the benefit with a date margin of 0.8 - points to some behavior specific to how I order the checks for which portion of the q ranges something is in:

Might be worth figuring out a better way to handle this - do I want to max out where the sloped lines intersect in cases like this? Is this moot? I believe that theoretically, it could make q3 < q2, which should mean we don't hit the max, but still get a ledge like this

[nickrsan]

Notes on this from meeting with Sarah

• bump the feathering out so that it tapers from the edge. Ted has median and quartile range. Range of values could be the min and the max, could be the 80th percentile range from 10th percentile range to 90th percentile. Edge would be at this 10th or 90th percentile range. Should we taper more slowly for items with more statistical uncertainty?
• multiplicative OK
• rollover components

1950-2015 based on precip - 65 points where summer baseflow has a start and end date - ranges are based on those points and he gives the boxplot for the range. Data is by water year type, but worth merging for thesis at least.

Need to handle dry season base flow that crosses water year boundaries. Easiest way to program it might be to construct a three year window and pull the middle year, but that's computationally expensive. Could also do something like constructing a year and a half and replace the first half of the first year with the first half of the second year.

[nickrsan]

I'm trying to think of approaches where we actually use negative values and then bump everything to the positive space (or vice versa - where we bump everything to positive, calculate it, then shift the water year back and invert the negative values) - All of those rely on some kind of line of demarcation where we still have to not cross over zero though. Seems easier to overcalculate and then pull what we need, but slower.

[nickrsan]

Ended up using modulos to compute the wraparound values, and then a second set where if we detect that the end values are less than the starting values, we re-extend it back to values that go beyond the water year, but we also bump the current date to that location as well. This was committed in fb48792

Here's how it looks on the box we're using for testing, which is specified the classic way (provide hard cutoffs and have it compute the fuzzy edges):

And here's how it's looks the way we'll be using where we calculate the boxes based on the actual statistics of the stream segment: