Loading...
HomeMy WebLinkAbout02_TRBM_Modeling_the_Tar_River_Basin_Operations_with_OASIS1 Modeling the Tar River Basin Operations with OASIS Addendum to the User Manual for OASIS with OCLTM December 2011 Prepared for the North Carolina Division of Water Resources Advancing the management of water resources 2 Table of Contents Section Page 1 – Introduction 3 2 – Model Components 2.1 Schematic 5 2.2 Model Input 7 2.3 Run Configurations 14 2.4 Model Output 14 Appendices A - Model Static Input Data and Run Code B – Finalized Inflow Data Development C – Provisional Inflow Data Development D – Model Weighting Description 3 Section 1. Introduction This report describes how OASIS is used to model the operations of the Tar River Basin. This application of OASIS, known as the Tar River Basin Hydrologic Model (the model), extends geographically from the headwaters of the Tar River to where the river becomes tidally influenced near Greenville. This report is not intended to replace the User Manual for OASIS, which is available from the Help menu of the model. Rather, it is intended to document the data used in this application as well as the current operations of the basin. Information about the OASIS platform is included only to the extent necessary to provide context for the application-specific data. The model is available for registered users on the Division of Water Resources (DWR) server. The model can be used in two modes: (1) a simulation mode to evaluate system performance for a given set of demands, operating policies, and facilities over the historic inflow record; and (2) a position analysis mode for real-time management. In the latter mode, the model uses multiple ensemble forecasts to provide a probabilistic assessment of conditions up to one year in the future. Although it can be used for other purposes as well, this feature is particularly useful for drought management. The simulation mode contains two default runs, one for conditions today, and the second for conditions at the end of the 50-year planning horizon in 2060. The model uses an inflow data set that extends from January 1, 1929 through September 30, 2009. This data set was developed using a comprehensive approach that (1) relies on over ten streamflow gages in the basin; (2) accounts explicitly for upstream alterations, or impairments, from reservoir regulation and net water consumption; and (3) uses statistical techniques to complete missing records for these gages. Real-time drought management depends upon having current forecasts of inflow. As noted below, the generation of such forecasts is dependent upon having inflows through the present day. Updating the inflows requires the collection of impairment data, which can be time intensive. It is envisioned that these data will be collected every five years. In the interim (e.g., through 2014), the inflow data starting October 2009 will be based on a provisional inflow technique so that real-time updates can be made quickly and easily without the need to collect all the impairment data. The remainder of this document summarizes the components of the model and the major operations in the basin. Appendix A lists the static input data and run code used in the basecase simulation run that is based on today’s facilities, operations, and demands. Appendix B describes the approach used to establish the finalized inflow data set. Verification of inflows and operating rules was described in meetings with the Technical Review Committee and formalized in Powerpoint® presentations that are available on the DWR website. Appendix C describes the approach for generating provisional inflows. Appendix D describes the weighting assigned to the various nodes and arcs so that the model reflects the general priorities for water allocation in the basin. It is important to note how the OASIS model should and should not be used. OASIS is a generalized type of mass balance model used mainly in evaluating planning and management alternatives. 4 It is not intended for use in hydraulic routing nor flood management, although it can be linked to other models for those purposes. In addition, since modeling results are largely influenced by their accuracy, the user must be cautioned about the inflows. HydroLogics spent considerable effort in developing the inflow data. The methodology ensures that the monthly naturalized flows at the gage locations match, which assumes that any measurement error is embedded in the impairments and not the streamflow data. DWR agreed to this method, which, although imperfect, is the most reasonable given the available data. Further, it is important to note that we are not trying to replicate history in computing the OASIS inflows; rather, we are trying to build a data set of daily flows whose variation is representative of history while preserving monthly gaged flows as “ground truth”. Due partly to the inaccuracy of some of the impairment data and to time of travel, negative inflows may occur. These can lead to potential model infeasibility. The model code filters out negative inflows, particularly large ones, but preserves the total inflow volume over a short period by debiting those negative inflows from subsequent positive inflows. For example, if a rainstorm hits the upstream part of the reach but not the downstream part, the gaged flow data may indicate a large negative inflow (gain) between the upstream and downstream ends of a stream reach. When the flow attenuates upstream and peaks downstream, the inflow becomes positive, and the negative gain from the day(s) before is (are) debited from the positive inflows the day(s) after to ensure that the average inflow over that period is preserved. The occurrence of negative inflows is reduced in the main-stem of the Tar by incorporating time-of-travel equations recommended by DWR. These equations are provided in Appendix B. 5 Section 2. Model Components 2.1 Schematic The model uses a map-based schematic that includes nodes for withdrawals (agricultural, municipal, and industrial), discharges (municipal and industrial), reservoirs, and inflows, and arcs that represent means of water conveyance between nodes. The model schematic is shown on the following page and is sized to show the full system. (To make the schematic more legible, the user can adjust the schematic size from the model’s graphical user interface (GUI)). The schematic and associated physical data were developed with input from basin stakeholders at numerous model review meetings. In total, the model has approximately 65 nodes and 80 connecting arcs. There are 8 reservoir nodes (four actual reservoirs and four artificial storage nodes used for time-of- travel flow routing). There are approximately 10 irrigation nodes, 10 municipal and industrial demand nodes, 5 independent discharge nodes, 13 natural inflow nodes (including the reservoir nodes), and other miscellaneous nodes to account for minimum flow requirements, interconnections, interbasin transfers (primarily around Greenville), and instream flow assessment for ecological needs. 6 7 The user can click on any node or connecting arc to access specific information, like reservoir elevation-storage-area data or minimum streamflow requirements. These data are also contained in tables contained on other tabs of the model. 2.2 Model Input Input data for the model is stored in three forms: static and pattern data, timeseries data, and user-defined data using operations control language (OCL). The timeseries data are stored outside the model run. The other data are embedded in the run and copy over automatically when creating a new run. Static and pattern data are contained in the GUI and represent data that do not change during the model simulation (such as physical data like reservoir elevation-storage-area relationships) or repeating data that occurs every year in the simulation (like monthly demand patterns or seasonal minimum release patterns). Timeseries data change with each day in the simulation record and typically consist of inflows and reservoir net evaporation. OCL allows the user to define more elaborate operating rules than are permitted from the GUI. Static and Pattern Data Tables containing the model’s static and pattern data can be found in Appendix A. Reservoir information includes elevation-storage-area relationships, minimum and maximum allowable storage, and any rule curves which dictate the preferred operating elevation throughout the year. Minimum flows and reservoir releases are defined by minimum flow patterns on arcs. Water treatment plant and transmission constraints are defined by maximum capacities on arcs. Municipal and industrial demand nodes use an annual average demand subject to a monthly pattern, and an associated wastewater discharge based on a fraction of the monthly demand. Wastewater discharges not associated with demand nodes are modeled using an annual average return subject to a monthly pattern. The model allows the user to systematically adjust all municipal and industrial demands in the basin by invoking the demand multiplier option on the Setup tab. This is useful when doing sensitivity analyses on the impact of demand growth in the basin. Note that irrigation demands and independent wastewater returns are not adjusted using this multiplier but can be updated using the procedure described in the next section. The few independent wastewater returns in the model can be adjusted manually in the pattern tables. 8 Timeseries Data The timeseries data are stored in a basedata timeseries file (basedata.dss), which contains all the inflow and net evaporation (evaporation less precipitation) data. The sources for these data are provided in Appendix B along with a more detailed description of how the inflows were developed. As noted, updating the timeseries data can be done in two ways: (1) using the comprehensive approach described in Appendix B; or (2) using the provisional approach for facilitating real-time drought management described in Appendix C. The provisional approach relies on data from select gaging and precipitation stations throughout the basin. The provisional updates can be done directly from the interface by selecting the Update Record tab, inputting the data, and clicking on the Update Record button. The update record algorithm will calculate the inflows to all the OASIS inflow nodes and net evaporation for all reservoir nodes and write them to the basedata.dss file automatically. Agricultural water use is modeled as a timeseries over the historic hydrologic record. It is broken out by county and depends on livestock count, crop usage, livestock and crop water consumption, and rainfall. Evapotranspiration equations for each crop are used in conjunction with the timeseries precipitation record so that crops are only irrigated when necessary. The water use can be easily adjusted from the model interface by opening the Edit Irrigation Data dialog box on the Setup tab. The model automatically converts the input data on crop acreage and livestock count into water use values. The agricultural demand nodes are a summation of the agricultural water usage in a particular reach of interest. Operating Rules As described in more detail in Appendix D, most of the water allocation priorities are set by the user in the GUI by applying weights to nodes and arcs. The most common operating rules are for storing water in reservoirs versus releasing the water to meet local demands or minimum releases, and these are reflected by the weighting scheme. Simply stated, if a minimum flow in a river is more important than meeting the local water supply demand, a higher weight on the minimum flow means water supply deliveries will be scaled back in order to meet the minimum flow. The Operations Control Language (OCL) allows the user to model more complex operating rules, such as tying demand reductions to reservoir levels or river flows that are common in drought management. These files are accessible from the model interface. The OCL files associated with the basecase simulation run that uses year 2010 demands are included in Appendix A. The key OCL files include main.ocl, which initializes the run and refers to all the other OCL files; inflows.ocl, which filters the inflows for any negative gains in the provisional record; return_flows.ocl which sets the wastewater returns; routing.ocl, which routes water to account for time of travel; and drought_plans.ocl which codes the Water Shortage Response Plans submitted by utilities to DWR. 9 A flowchart is provided below summarizing the overall operations of the basin as captured in the model. Additional detail on Rocky Mount’s operations are provided further below. Additional detail for all systems is provided in the OCL files in Appendix A and in the weighting description in Appendix D. 10 Flow Chart of Major Nodes in the Upper Tar BasinNew City PondOld City PondLouisburg DemandFlow dow n to Mi ddle BasinRe ser vo ir NodeDemand NodeJunc tion NodeFlow ArcWithdrawal ArcWW Return ArcTransfer ArcTar R. GageFranklinton DemandCedar CreekTa r RiverThe model weighting for upper basin reservoirs allows for demand to be met, but not to re le ase water for any ne ed s do w nstrea m of ea ch re ser vo irAll basins demands are modeled as an annual averag e daily de man d with a monthly pattern.All basin wastewater returns associated with a demand are modeled as fraction of the withdrawal; the return fraction use s a monthly pattern.Frankl in Co. DemandLouisburgGageKerr IBTOxford WWFranklinton withdra ws water from do wn stre am of their primary (New City Pond) and emergency (Old Cit y Pond) reservoirs.Franklin Co . buys water from three so u r ces ; Kerr Lake RWS, Franklinton, and Louisburg.Franklin Co . treats their own wa ste wa te r, as well as Frankl inton’ s 11 Flow Chart of Major Nodes in the Middle Tar BasinTar River ReservoirFlow down to Lower BasinRocky Mount DemandEnfiel d DemandLittle Fishing Cre ekFlow from the Upper BasinThe model weighting for the Tar River Re ser vo ir allows the minimum release re q uir e men t and demand to be met, bu t not to release wa te r for any needs do wn stre am of Rocky Mount.QuarryFi shing CreekSwift CreekRocky Mount Sunset IntakeRe servo ir NodeDemand NodeJunc tion NodeFlow ArcWithdrawal ArcWW Return ArcTransfer ArcEmergency Tra nsfer with WilsonRocky Mount’s primary source is the Tar River Reservoir, and an intake downstream on the Tar River at th ei r Sunset WT P.  They generall y use th e Sunset plant to capacity whe n the reservoir is dra wn do w n.During a drought, the city can reduce their minimum flow re q uir e men t from the reservoir, and augment flows down to the Sunset intake by releasing water from a supplemental quarry. 12 Flow Chart of Major Nodes in the Lower Tar BasinModel TerminusTarboro DemandConetoeCreekFlow from the Middl e BasinRe ser vo ir NodeDemand NodeJunc tion NodeFlow ArcWithdrawal ArcWW Return ArcTransfer ArcGreenvill e DemandGreenvill e GageTarboroGageGreenville IBT’s to  Farmville, Greene Co. and Wintervil le.Currently modeled as fi xed values; additional detail about Capacity Use Area banking may be added as more information becomes available. 13 Rocky Mount Operations: Rocky Mount has the only reservoir on the main stem of the Tar River. The operation of this reservoir is very important to the low flow management in the basin and therefore deserves special mention. In the 1990s, in response to a significant drought event, HydroLogics developed an OASIS application of Rocky Mount’s system to craft a drought management plan for the city using probability-based drought triggers. The advantage of such triggers is that they provide the best balance between the risks of water supply shortages and the hardships of imposing water use restrictions. Subsequent updates to the triggers occurred based on the extreme drought of 2007, followed by the development of this model, which extended the geographic scope to include the entire basin. As described in the run configuration options below, these triggers were developed by simulating the performance of these triggers over the historic inflow record and are implemented by running the model in a real-time (position analysis) mode. As detailed in the Rocky_Mt_Ops.ocl file, the updated drought plan triggers call for the following: (a) Voluntary reduction in the Tar River Reservoir’s minimum release (normally 80 cfs) to 70 cfs from June to October. (b) Probability-based trigger 1: if there is a 10 percent chance of the reservoir reaching 120 feet in 12 weeks, and today’s elevation is below 124 feet, set the minimum release to 70 cfs. This trigger will be lifted when the elevation reaches 124 feet. (c) Probability-based trigger 2: if there is a 15 percent chance of reaching 118 feet in 8 weeks, and two weeks have elapsed since trigger 1 activation, lower the minimum release to 60 cfs and reduce Rocky Mount demand by 10 percent. In addition, release 10 cfs from the city’s quarry to supplement flow in the Tar River. This trigger will be lifted when the elevation reaches 124 feet. (d) Probability-based trigger 3: if there is a 20 percent chance of reaching 116 feet in 6 weeks, and one week has elapsed since trigger 2 activation, lower the minimum release to 50 cfs and reduce Rocky Mount demand by a total of 18 percent. In addition, continue releasing 10 cfs from the city’s quarry. This trigger will be lifted when the elevation reaches 124 feet. 14 2.3 Run Configurations The model can be used in two modes: (1) a simulation mode to evaluate system performance for a given set of demands, operating policies, and facilities over the historic inflow record; and (2) a position analysis mode for real-time management. General information on creating, modifying, and executing runs is provided in the User Manual for OASIS, which is available from the Help menu of the model. Simulation: In simulation mode, on the Setup tab, the user can select from three radio buttons: No Forecasts, Conditional Forecasts, and Non-conditional Forecasts. The latter two enable the user to evaluate forecast-based operating policies (although none are used in the basecase scenario), with inflow forecasts generated for each week in the historical inflow record. Conditional forecasts account for antecedent flow conditions while non- conditional forecasts are made independent of how wet or dry the basin is. The forecasts for the simulation mode are generated outside the GUI and stored in the basedata folder. The current forecast file is developed from the timeseries basedata.dss file that extends through September 2009. The forecast file should only be updated in conjunction with the comprehensive inflow updates (anticipated every five years with the first update in 2014). Position Analysis: In position analysis mode, the user can select from Conditional or Non-Conditional Forecasts on the Setup tab. By executing a run, the model will produce a forecast (typically of river flows or reservoir elevations) for up to the next 365 days. A forecast can be made on any date in the historic inflow record or no more than one day after the end of the inflow record. Typically it will be used starting the day after the last update of the inflow and net evaporation record. For example, if these records end September 30, 2009, the user can run a forecast for October 1, 2009. If a month has passed, and the user wants to run a forecast for November 1, 2009, the user would update the inflows and net evaporation for October using the Update Record tab and then start the position analysis run on November 1. For a reservoir, or locations affected by the operation of a reservoir upstream, the forecast is dependent on the starting elevation of the reservoir. On the Setup tab, the user simply inputs the starting elevation (or storage), the starting date of the forecast run, and clicks Run. 2.4 Model Output The model allows the user to customize output files (tables or plots) and save them for routine use. Alternatively, the user can click on any node or arc in the schematic or go to the Setup tab and select Quick View to access and save tabular or plotted output. The balance sheet can also serve as a useful tool for tracking water through the system. 15 Included in the model output tables is a file called xQy_Tarboro_ClimaticYear.1v. This file allows the user to compute instream flow statistics, such as 7Q10, for a specific site, in this case the Tarboro gage. To generate statistics for a different site, the user would copy and rename the file, then change the name and associated arc listed in the file. When viewing the generated output, the default layout shows two columns, for 7- and 30-day low flows (these periods can be changed in the .1v file). Scrolling to the bottom of the output file shows Log Pearson percentiles for each column. If the user is interested in the 7Q10 (7-day low flow, 10th percentile) flow, the user would look at the first column, and the row labeled LPrs.100. In addition, the model is capable of automatically determining the safe yield for a specific demand node, in this case the demand from Tar River Reservoir. To generate statistics for a different site, the user would copy and rename the file (currently called SafeYield_TarRes.1v), then change the name and associated demand node listed in the file. The safe yield can be determined for each year in the historic inflow record (annual safe yield analysis) or for the entire period of record. The user inputs the adjustment criteria by selecting the Run Safe Yield Analysis button on the Setup tab. The safe yield routine works by tracking demand shortages for the chosen demand node, and iteratively works towards the maximum demand that produces no shortages from the supply source (in this example, Tar River Reservoir). Note that the drought plans cannot be activated when using the safe yield routine, as the demand reductions resulting from drought restrictions inherently produce a ‘shortage’ from the normal demand.