StateTL - for simulation/calibration add running average for GLE term and stats output

[kelleythompson]

The gain/loss/error (GLE) term is produced within the State model engine and is currently DWR’s responsibility, but some background is important for calibration. In StateTL, the primary river/gage loop is used to develop an hourly gain/loss/error (GLE) correction term to correct calculated flow amounts to known flow amounts at the river gages (ie this is what makes the flow at gage 2 equal the flow at gage 2) and the correction is distributed within the reach using the subreach portions. This GLE correction accounts for unmeasured gains and losses (ie baseflow gains and losses and unmeasured return flows from ditches/field) but also corrects for errors in the calculation method or bad calibration. However, when the WC/release loop is run, the GLE correction no longer applies and the release routing is governed by the calculation - so calibration is critical for the WC release amounts (ie the colors of water). For calibration, we will need to apply GLE amounts that hopefully reflect real unmeasured gains and losses but don't include corrections for the calibration being off, etc. We been using the mean of the GLE for simulation/calibration over short time periods to reflect average gain/losses but remove calibration corrections. However, for longer time periods, a running average might better reflect that return flows can be change over time. Also, some calibration stats produced by the StateTL model would both better enable development and evaluation of these type of terms, as well as potentially being something that would be valuable to the python calibration tool. The model already has a function that can easily do least squares (or regular) regression between simulated and actual gage amounts

[porterma]

It appears that GLE is an unknown parameter. Are you suggesting it could be a calibration parameter in the Python script?

[kelleythompson]

Mark, No. The gain/loss/error (GLE) correction is produced within the model engine and on an hourly basis, beyond expected gains and losses, an errors corrected for in the term are a 'result' of the calculation method and the calibration accuracy. There is something to play with - the period of the moving average used in the simulation that is then used for calibration - but I wasn't expecting B&C to really look at that as part of the calibration process. There's more info on the GLE term in the CoW task document.

Thanks, Kelley

Kelley L. Thompson, P.E. Senior Lead Modeler - Modeling and DSS / Water Information Team

P 303.866.3581 ext 8261 | C 719.480.3423 1313 Sherman St., Suite 818, Denver, CO 80203 @.*** | www.water.state.co.us

On Thu, Nov 11, 2021 at 12:37 PM Mark L Porter @.***> wrote:

It appears that GLE is an unknown parameter. Are you suggesting it could be a calibration parameter in the Python script?

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_OpenCDSS_ArkDSS-2DColors-2Dof-2DWater_issues_15-23issuecomment-2D966571769&d=DwMCaQ&c=sdnEM9SRGFuMt5z5w3AhsPNahmNicq64TgF1JwNR0cs&r=v8IOejxniM24GGbuf52hAajizwligqp4dTwlVwvfpSs&m=nrbEgcz1bzVV-t1d0LriDyFL6dUff-CxOVEcNdON6qI&s=OI20fFoSbpJThiRby7-CzEOKAggWbPNMnsgwhBjqT8I&e=, or unsubscribe https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_AC4LFGCUG4WXSPNOGPAQXADULQLODANCNFSM5H3EGUGA&d=DwMCaQ&c=sdnEM9SRGFuMt5z5w3AhsPNahmNicq64TgF1JwNR0cs&r=v8IOejxniM24GGbuf52hAajizwligqp4dTwlVwvfpSs&m=nrbEgcz1bzVV-t1d0LriDyFL6dUff-CxOVEcNdON6qI&s=tKIcDndvRMvZAqIU8Vc3JKWMsN3ghdXAAZRAv7XNh54&e= . Triage notifications on the go with GitHub Mobile for iOS https://urldefense.proofpoint.com/v2/url?u=https-3A__apps.apple.com_app_apple-2Dstore_id1477376905-3Fct-3Dnotification-2Demail-26mt-3D8-26pt-3D524675&d=DwMCaQ&c=sdnEM9SRGFuMt5z5w3AhsPNahmNicq64TgF1JwNR0cs&r=v8IOejxniM24GGbuf52hAajizwligqp4dTwlVwvfpSs&m=nrbEgcz1bzVV-t1d0LriDyFL6dUff-CxOVEcNdON6qI&s=-8L09NBMyPz4Tjojv9CNBO4yjOSqTOGMDMxRbVZkcJc&e= or Android https://urldefense.proofpoint.com/v2/url?u=https-3A__play.google.com_store_apps_details-3Fid-3Dcom.github.android-26referrer-3Dutm-5Fcampaign-253Dnotification-2Demail-2526utm-5Fmedium-253Demail-2526utm-5Fsource-253Dgithub&d=DwMCaQ&c=sdnEM9SRGFuMt5z5w3AhsPNahmNicq64TgF1JwNR0cs&r=v8IOejxniM24GGbuf52hAajizwligqp4dTwlVwvfpSs&m=nrbEgcz1bzVV-t1d0LriDyFL6dUff-CxOVEcNdON6qI&s=KxAV2bDrUJi6dNfzQUTPWgUJasYwv7pHCneiYm0q55k&e=.

[kelleythompson]

Production of an additional 'StateTL_out_calstats.csv' output table was added to the calibration output routine. The least squares method in the regression function is used to compare observed flow (x value) to simulated flow (y value) at gages using the y=mx (simulated = m * observed) least squares model. The output file shows, for each gage location in a calibration water district, the m, R2, and SEE values. The R2 value in particular can be used to just the calibration fit. On very initial evaluation, the SEE (standard error of estimates) doesn't seem to be making as much sense as R2 (although it may be more representative of the error amount).

As had these in a different script, also added some plotting functions to evaluation calibrations. The plotting is initiated by the plotcalib=1 variable in the control file. I assume we would normally keep this off in the control file especially for automated calibration, but it could also be triggered on during calibration with a '-p' command line argument. Several example plots are included at the end. Also a small note that since I am often testing and doing something else while waiting for the program to run, I put a musical clip when the script terminates. This will turn off when deployed, but could be triggered on with a '-m' command line argument (would be fun to hear what 30 running instances would do to your speakers).

Added a 'movingavg' option to establish gain/loss/error term for the simulation/calibration loop. The method is currently hardwired in the script to calculate a centered 2-week running average for every point within the calibration period (ie average one week before and one week after the hour in question). A 2-week average generally seemed to smooth at short term jumps in the GLE term that could have been related to problems in the routing etc but still retain longer term gradual changes in the GLE term that might be expected for changing return/unmeasured flows or baseflow conditions. Additional evaluations might indicate revising the 2-week period. As expected, the use of the running average significantly improved calibration statistics as observed through R2 values in the new cal stat table.

Current calibrations plots of 2018 data at Arkansas River gage at Catlin Canal Dam (using 2-week running average for GLE term) as produced by plotcalib=1: