StateTL - noise in WC routing particularly with multiple linearization

[kelleythompson]

The j349 multiple linearization method (with multiple celerity/dispersion "URFs") conceptually should be a better method than single linearization to represent changing flow rates (and therefore changing celerity/dispersion) over longer timer series such as for a calendar year. See Keefer, T. N., and McQuivey, R. S., 1974. At high river flow and release rates, the method seems to be working well. However, when utilized at lower river flow rates and smaller water class release rates (especially when approaching or exceeding zero river flow), the method as currently employed through StateTL creates significant noise in hourly data (see fig1 - multiple in blue, single in red - 2018 W151408). There is also noise when using single linearization, but the noise with multiple is higher and when averaged to a daily timestep (see fig2 - multiple in blue, single in orange). At least with multiple linearization, the noise can even "create" water at rates above the original release rate (see fig2 and fig3 2018 W151415). That said, for the same WC shown in figure 3, both the single and multiple linearization are creating artificial spikes at times well before the release (see fig 4 - original release in red) - this might be a different but related issue (although this hasn't been observed in alot of instances, once is too many). The root cause of this needs to be identified and addressed. However also, in the capture loop, hydrographs are "cleaned" to remove noise prior to the start of the release and after a certain portion of the release reaches the headgate. Currently this cleaning is only applied to the final hydrograph at the receiving structure, but could be applied at all intervening structures and subreaches to remove noise before and after the release.

So some tasks are:

• further evaluate the source of the noise at low flow/release rates
• identify why the peaks shown in figure 4 where caused
• apply the capture loop cleaning to intermediate subreaches

[kelleythompson]

In figure 4 above, what is causing the erroneous early spikes is bad gage data - at Arkansas River at Catlin Dam (top of reach 5). See figure 5 which shows gage along with upstream/downstream gage data. That data gets pushed back into reach 4 due to the gain/loss/error correction term. Haven't logically worked out why the gain/loss/error correction isn't taking care of it, but leads to need for data QC in addition to filling. QC of gage data is seeming tough - as need to know what hydros know ifs its ice cover or if its a big rain storm - for historical could use published daily "station" data (vs hourly uncorrected "telemetry" data) but that may not help us for current years..

[kelleythompson]

The issue related to the last comment was resolved in Issue #9. The remaining tasks are:

1. further evaluate the source of the noise at low flow/release rates particularly with multiple linearization
2. apply the capture loop cleaning to intermediate subreaches
3. potentially find an alternate solution to vary celerity/dispersion with flow rate besides the multiple linearization method - perhaps use a different total celerity/dispersion for each time step (when flow rates increase this will cause downstream flow 'gaps' but maybe its OK when averaged to a daily timestep) which would require a big change in the fortran and passing back and forth of double or triple the data.

[kelleythompson]

In relation to noise at particularly caused by the multiple linearization method, the problem specifically occurs at low flow and release rates or when the larger release causes estimated Qpartial (ie Qriver - Qrelease) to approach zero (ie wouldn't be much in the river if the release wasnt there). A solution was implemented to define a 'urfthreshold' flow. For flows below this threshold, both celerity and dispersion were calculated using the threshold flow rate in order to calculate the Q vs C and D tables (10 value pairs) used in the multiple URF option. More particularly, when the river flow loop is run, it records the Qmin and Qmax; and this same Qmin and Qmax is used to calculate Qpartial (ie Qriver - Qrelease) so that URFs are identical between the two runs. In both cases, if Qmin is below the urfthreshold, then Q for the URF table is taken as [1 urfthreshold Qmin : (6 intermediate values) : Qmax] while for the C and D for the first two values of this table is taken as the C and D calculated using the urfthreshold amount. The following figure shows calculated noise for the release previously shown as figure 1 (2018 W151408) at urfthreshold amounts of 250(blue)/500(red)/750(purple)/1000(green). A 500cfs threshold had moderate improvements with a bigger improvement at 750cfs. As far as simulation of overall river river amounts in WD17 for 2018, use of multiple urfs still showed slightly worse calibration statistics than with single urf, but results were slightly better for 500cfs than for 750cfs.

For WD17, Livingston did use variable celerity and dispersion rates but based on steady state river conditions for short periods. In WD67, Livingston was not able to calibrate using variable celerity and dispersion and instead just used constant values of 3 ft/s and 200 ft2/s, respectively, at all flow rates. In WD17, a celerity of 3ft/s is approximately 500cfs - and most releases in the reach are approximately less than 500cfs. Therefore, as an initial value, a 500cfs urfthreshold was applied; this value will still be evaluated and potentially refined. In the input data table, a column was added for these values so it could be changed on a reach or subreach basis. A threshold of approximately 500cfs might be applicable in the mainstem but wouldn't be on smaller tributaries etc.

As river calibration where very slightly worse with multiple urf, this maintains a question of if multiple URFs should be used. However, conceptually and physically, higher flow rates have higher velocities so using multiple URFs seems like the right thing to do; and use of the threshold does reduce noise at lower rates. So - I think - the recommendation is to use multiple URFs with the threshold - but still will want to evaluate potentially ways to reduce noise and improve calibration.

[kelleythompson]

Closing issue as addressed majority of issue. However, remaining secondary task items include:

1. apply the capture loop cleaning to intermediate subreaches
2. continue to evaluate the source of the noise at low flow/release rates particularly with multiple linearization