Modeling the French Broad River Basin Operations with OASIS

1

Modeling the French Broad
River Basin Operations with OASIS

February 2021
Prepared for the North Carolina Division of Water Resources

2
Table of Contents

Section Page
1 – Introduction 3 2 – Model Components 2.1 Schematic 5
2.2 Model Input 10
2.3 Run Configurations 12 2.4 Model Output 13
Appendices
A - Model Static Input Data and Run Code B – Finalized Inflow Data Development C – Provisional Inflow Data Development
3
Section 1. Introduction
This report describes how OASIS is used to model the surface water operations of the French Broad River basin spanning North Carolina and Tennessee. This model extends geographically from the headwaters of the subbasins (Upper French Broad, Pigeon, and Nolichucky) to their respective crossings into Tennessee. 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 summary of the model development process was provided to the Technical Review Committee and broader stakeholder group as a slide deck (FB_Nolichucky_Pigeon OASIS Modeling Mtg#3 10dec2019 final.pptx, Dec. 2019).

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. The
simulation mode contains the basecase run representing today’s conditions. In the position analysis 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 model uses an inflow data set that extends from October 1, 1929 through September 30, 2017. This data set was developed using a comprehensive approach that (1) relies on over 35 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 requires forecasts of inflow and, as noted below, the forecasts are generated based on 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 2022), the inflow data starting October 2017 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.
Appendix C describes the approach for generating provisional inflows.
4
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. 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 sensitive to inflows, the user must be cautioned about accuracy of the inflows. Hazen 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. When the flow attenuates upstream and
peaks downstream, the inflow becomes positive, and the negative gains from the days before are debited from the positive inflows in the days after to ensure that the average inflow over that period is preserved.
5
Section 2. Model Components
2.1 Schematic
The model uses a map-based schematic that includes nodes for surface water withdrawals (agricultural, municipal, and industrial), discharges (municipal and industrial), reservoirs, gage locations, and points along the rivers where flows are of interest. Arcs represent
means of water conveyance between nodes. The model schematic is shown on the
following pages in Figure 1. The schematic and associated physical data were developed with data and maps provided by DWR and also from basin stakeholders at model review meetings.
In total, the model has over 200 nodes and over 250 connecting arcs. There are 15
reservoir nodes (including one used for time-of-travel flow routing), 20 municipal and industrial demand nodes, 28 agricultural demand nodes, 3 fisheries demand nodes, 17 independent wastewater discharge nodes (i.e., not tied into a water withdrawal node), 49 natural inflow nodes (including the reservoir nodes and 23 USGS gages), and other
miscellaneous nodes to account for minimum flow requirements, interconnections, and
instream flow assessment for ecological needs. Interconnections capture regular and emergency use.

6
Figure 1a. French Broad OASIS Model Schematic
7
Figure 1b. Schematic Detail – Upper ?? French Broad and Pigeon
8
Figure 1c. Schematic Detail – French Broad down into Tennessee
9
Figure 1d. Schematic Detail – Nolichucky

10
The user can click on any node or connecting arc on the schematic to access specific
information, like reservoir elevation-storage-area data or minimum streamflow requirements. These data are also contained in tables which can be accessed via data queries in the model. 2.2 Model Input
Input data for the model comes in three forms: static and pattern data, timeseries data, and user-
defined data using operations control language (OCL). All datasets are stored in a SQL Server
database. While data tables can be accessed via SQL queries, the easiest way for most users to view data is through the OASIS GUI using “Find Data” queries. 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, or by OCL for more complex minimum flow protocols.
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 for the run. This is useful when doing sensitivity analyses on the impact of demand growth in the basin. Note that agricultural
demands and independent wastewater returns are not adjusted using this multiplier. The
agricultural demand can be adjusted as described below, and the independent wastewater returns can be adjusted manually in the pattern tables.

11
Timeseries Data
The timeseries data contain 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 History tab. First the user presses the Download button, and once confirming the dates to download, clicks
Download. Once the data has downloaded the user needs to check for any blanks or erroneous values – the download log will flag any missing values, and data can be manually entered by selecting a variable (or multiple variables) and clicking the Plot Window button. After verifying the data, the inflows can be updated by pressing the Compute 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 database automatically. Agricultural surface 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 certain crops are used in
conjunction with the timeseries precipitation record so that the crops are only irrigated when necessary. The water use can be easily adjusted from the model interface by opening the Edit Agricultural Data dialog box on the Setup tab. The model automatically converts the input data on crop acreage (irrigated by surface water as opposed to ground water) 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

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, if necessary, to meet the minimum flow (usually in a drought). Weights are shown in the OCL files as part of targets on flow and storage, but also in the static tables as they relate to demands, minimum releases, and reservoir storage (see Appendix A).
The Operations Control Language (OCL) allows the user to model more complex operating
rules, such as hydropower production or drought management protocols that tie demand

12
reductions to reservoir levels or river flows. These files are accessible from the model interface. The OCL files associated with the basecase simulation run that represents current conditions is
included in Appendix A. The key OCL files include main.ocl, which initializes the run and refers to all the other OCL files; udef_ops_Asheville, which provide the coding for Asheville’s reservoirs; Misc_Operations.ocl; interconnections.ocl, which provide coding on the interconnections between utilities; drought_plans.ocl, which provides the coding for the utility water shortage response plans (WSRPs); and return_flows.ocl which sets the wastewater
returns. The OCL files are provided with detailed commentary for background information on the system operations. 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 tutorial PowerPoint presentations for OASIS, which provides screenshots of setting up and modifying OASIS runs, along with supplemental information in the User Manual for OASIS, which has more detail on using OCL.

Simulation: To enable all utility drought plans in a run, set the Drought Plans On variable in the OCL Constants Table to 1. A value of 0 will turn all drought plans off.

The GUI allows for all municipal and industrial demands in the model to be uniformly increased or decreased by a user-specified fraction. To enable the demand multiplier, check the Use Multiplier box on the Setup tab, and enter a number in the Multiplier Value box. For example, setting the value to 0.9 will decrease all M&I demands by 10%, and setting it to 1.1 will increase
them by 10%.
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, 2017, the user can run a forecast for October 1,
2017. If a month has passed, and the user wants to run a forecast for November 1, 2017, 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

13
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 on the schematic or go to the Setup tab
and select Quick View to access and save tabular or plotted output. A number of tables and plots
have been provided for points of interest in the basin. The balance sheet can also serve as a useful tool for tracking water through the system. Included in the model output tables is a sample file called xQy.1v. This file allows the user to
compute instream flow statistics, such as 7Q10, for a specific site, by following the comments in
the file. 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. To generate statistics for a different site, the user would copy and rename the file
(currently called SafeYield_Sample.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. Note under the current
output file configuration, the drought plans should be turned off when using the safe yield routine, as the demand reductions resulting from drought restrictions inherently produce a ‘shortage’ from the normal demand. The output file configuration can be modified if needed for the specific drought plan of each system.