need to implement IFR ramping rate constraints system-wide

[drheinheimer]

Currently, some IFR locations, as modeled with optimization, exhibit very flashy rates of change, as below Donnells Reservoir, below. Ramping rate constraints in fact exist in many IFR locations such as this, but are not yet implemented.

Note that for this example gauge data is relatively recent, and does not extend back to 2009.

[drheinheimer]

From @alanccai:

Josh suggested a long time ago that we could calculate daily change in flow for historical streamflows, cut off some percentage off the top of the distribution (which represent spilled, uncontrolled releases) and then set the 90% percentile for example as the maximum allowed daily change

That would work. @alanccai Is this something you could work on? i.e., 90% percentile of max up/down ramp rate. Should be quick.

[drheinheimer]

I see telltale signs of hydropeaking in the following IFRs (those with ramp rate constraints in bold):

• IFR at Murphys Park (there are other issues here though)
• IFR below Beardsley Afterbay
• [x] IFR below Beaver Creek Diversion Dam (#60)
• IFR bl Angels Div
• [ ] IFR bl Donnells Reservoir
• [ ] IFR bl McKays Point Div
• [x] IFR bl New Spicer Meadow Reservoir (#52)
• IFR bl confluence of NF Stanislaus and Beaver Creek
• [x] IFR below NF Stanislaus Div Res (not much sign of hydropeaking, but with RR constraint)
• [x] IFR bl Collierville PH discharge (there is only a RR requirement here) (#46)

i.e. most IFRs have some hydropeaking. Other locations have hints, but not much. Only IFRs below headwater reservoirs need these constraints, as constraints should propagate to lower IFRs. IFRs with RR constraints are seen here:

[drheinheimer]

Note to self: any restriction in hydropeaking must be accompanied by an ongoing accounting of hydropower released to-date. I.e., the monthly allocation for a facility must be considered as a kind of water account that the facility can draw from, and daily allocations adjusted accounting for the amount remaining. Unfortunately, this will necessarily slow the model down, unless we are clever.

[drheinheimer]

@alanccai Note that I've moved your facility-specific comments here to separate issues (#48 and #49). This was really to note the issue generally - those facility-specific issues can now be tackled in bite-sized chunks.

[alanccai]

I uploaded the results of my ramping rate IFR search to Box. Search for "Ramping Rate IFRs". Almost all of the IFRs are in terms of hourly changes. The two that actually have potentially programmable hard numbers have "$" at the end of the file name. Also added the new ones I found to the spreadsheet

[drheinheimer]

@alanccai I find it odd that there is no ramping below Beardsley Afterbay. Can you please double check? Does it fall into one of the project-based ramping rate constraints?

Here are simulated results (also note that IFR is well above actual releases; there may need to be some adjustment here that would actually take care of the ramping rate):