ENABLING REAL-TIME WATER DECISION SUPPORT SERVICES USING MODEL AS A SERVICE
BY
TINGTING ZHAO
THESIS
Submitted in partial fulfillment of the requirements
for the degree of Master of Science in Environmental Engineering in Civil Engineering in the Graduate College of the
University of Illinois at Urbana-Champaign, 2014
Urbana, Illinois Advisor:
ii
ABSTRACT
Through application of computational methods and an integrated information system, real-time data and river modeling systems can help decision makers identify more effective actions for management practice. The purpose of this study is to develop real-time water decision support services for decision makers during droughts and floods. To enable ease of use and re-use, the workflows (i.e., analysis and model steps) of the real-time decision support model are published as Web services delivered through an internet browser, including model inputs, a published workflow service, and visualized outputs. The RAPID model, which is a river routing model developed at University of Texas Austin for parallel computation of river discharge, is applied to predict real-time river flow rates. A workflow to predict river flow using the RAPID model has been built and published as a Web application that allows non-technical users to remotely execute the model and visualize results as a service through a simple Web interface. The model service is prototyped in the San Antonio and Guadalupe River Basin in Texas. In the future, optimization model workflows will be developed to link with the RAPID model
iii
ACKNOWLEDGEMENTS
I would like to express my great appreciation to my advisor, Professor Barbara Minsker for supporting me to finish this exciting project. The inspiration, guidance and encouragement from my advisor lit the road to complete my master study. I would like to thank Jong Lee from NCSA who helped me a lot in programming and computer science technologies for the project. I would also like to express my gratitude to Professor Maidment’s research group and Tim
Whiteaker at University of Texas, Austin for helping me with the RAPID implementation. Thanks to Kathy Alexander, Cindy Hooper and others from the Texas Commission on Environmental Quality (TCEQ) for providing data. Furthermore, I acknowledge a gift from Microsoft Research that provided funding support. Finally, I would like to express my deepest thanks to my parents for their encouragement and love, and my friends for their great support.
iv
TABLE OF CONTENTS
CHAPTER 1: INTRODUCTION ... 1
CHAPTER 2: CASE STUDY ON MANAGING DROUGHTS IN TEXAS ... 4
CHAPTER 3: METHODOLOGY ... 8
3.1 Model as a Service Architecture ... 9
3.2 Web Application ... 15
3.3 Scenario Analysis ... 19
CHAPTER 4 CASE STUDY IMPLEMENTATION ... 21
4.1 RAPID Model Implementation as a Workflow ... 21
4.2 Scenario-based Application ... 23
CHAPTER 5 CONCLUSIONS ... 30
REFERENCES ... 32
APPENDIX A ... 37
1
CHAPTER 1: INTRODUCTION
Water shortage and flooding have become serious issues in many areas that can cause large loss of property and endanger lives. The importance of effective water management is magnified during these events and rapid and informed responses are needed. One of the main challenges faced by decision makers during droughts and floods is reliable and immediate information collection [Whilhite et al., 1986]. The water decision making process needs to incorporate meteorological information, river network information, and other information. It also requires assistance from multiple models such as weather models, runoff models, hydrologic models, economic models, and so on [Yang et al., 2013]. The process of information collection, transforming data into appropriate model formats, integration of disparate models, and model execution is time consuming and challenging [Granell et al., 2010, Liu et al., 2008, Denzer, 2005].
Another challenge is to interoperate different models in a whole system. Existing disciplinary models can be written with different configurations and in different programming languages that may have difficulty communicating. For scientific modeling communities, increasing interoperability and access to models has become a crucial factor for long-term improvement of model performance [Goodall et al., 2013]. Therefore, a structure to organize heterogeneous information and apply it to different models to rapidly solve environment problems is critical for decision makers [Laniak et al., 2013]. Model as a service (MaaS) has recently emerged as an efficient tool to solve the above challenges.
Model as a Service (MaaS) originates as a merging of Software as a Service (SaaS) and the Model Web [Roman et al., 2009]. SaaS involves creating services that deliver a software application through Web browsers, allowing users to easily access the software, share data, and improve interoperability [Roman et al., 2009]. Each model is still run in its own configuration environment and the functionality of each model is published on the Web [Goodall et al., 2011]. Model Web is an open-ended system for interoperating models and data with access to machines and the Internet through Web services [Geller & Turner, 2007]. MaaS merges the two
2
visulization through the Web, using standard data formats for data interoperability[Roman et al., 2009]. The model execution does not require specific skills and the output can be viewed directly on the Web through visualizaton tools.
To implement MaaS, workflows (i.e., sequences of analysis and modeling steps) are developed as a collection of tasks to accomplish interoperable model processes [Diimitrios et al., 1995]. The service sharing of workflows allow users (researchers, decision-makers, and other non-technical users) to have easy access to model outputs. MaaS also allows model developers to share code and access other models from different communities. Groups can easily manage models and maintain control using the Web services [Goodall et al., 2011].
The application of MaaS has emerged in recent years and most previous applications have focused on one single step of a model application, such as data processing or model execution. Goodall et al. [2008] implemented a standard protocol for accessing disparate hydrologic data sources. Their aim was to reduce the time of data ingestion into the model application by providing data interoperability. Horsburgh et al. [2009] demonstrated the application of Web services for data transmission across different data sources to reduce the syntactic and semantic heterogeneity in the data. Granell et al. [2010] employed a service-oriented architecture (SOA) to build Web services for data processing of environmental models and service interoperability. The services were discovered, integrated, published, and reused independent of the specific technology for each single service.
MaaS can integrate different model components and incorporate model components into a system which can be published through Web services. Goodall et al. [2011] addressed service-oriented computing for loosely-coupled independent conponents of heterogenous water models and data exchange across the network using Web services. Their approach considers only simple execution of hydrological models and does not consider data transfers between services and the integration of heteogeneous models. Feng et al. [2011] proposed an approach to publish models through the Open Geospatial Consortium (OGC) and Web Processing Services (WPS) standards. Dubois et al. [2013] addressed model integration for the purpose of answering multi-disciplinary questions through Web services. They emphasized the integration and publishing of models beyond simple data sharing, but the modeling system was not developed to integrate with existing systems and data systems. These previous studies focus on separate components of
3
model applications and did not consider the whole process of model application including data processing, model execution and results visualization.
The purpose of this study is to illustrate how a more comprehensive integration of data processing, model execution, and output visualization using workflows and MaaS can enable real-time water decision support, as well as other model-based decisions. The workflows are published as Web services delivered through an internet browser, including model inputs, a published workflow service, and visualized outputs.
To illustrate this process, a workflow using the Routing Application for Parallel
computatIon of Discharge (RAPID) model has been built and published as a Web application that allows non-technical users to remotely execute the model, visualize results, and explore impacts of plausible weather scenarios as a service through a simple Web interface. A coupled
optimization model workflow system for recommending optimal curtailments during water shortages for decision makers will be built in the future.
4
CHAPTER 2: CASE STUDY ON MANAGING DROUGHTS IN TEXAS
During summer 2011, Texas experienced the most serious drought since rainfall
recording was available in 1895 during the hottest summer of any state in the history of the U.S. The rainfall from October 2010 to September 2011 dropped far below the historical rainfall record set in 1959 and the average temperature during that summer (June to August 2011) was 2 degrees F higher than the historical Texas record [Nielsen-Gammon, 2012]. Water loss during this period reached nearly 100 km3 [David Maidment, 2012]. The devastating drought caused
large losses of property and degraded human life. The Texas AgriLife Extension Service estimated $5.2 billion in losses in Texas agriculture by the end of the drought [Susan Combos, 2012].
The Texas Commision on Environmental Quality (TCEQ), the environmental agency for Texas, employs water masters in certain rivers basins to provide active water management, particularly during droughts. The Priority Doctrine serves as a foundation for TCEQ’s water management policies. Domestic and livestock users have priority water rights over any permitted surface water rights holders. The permitted surface water rights holders are divided into senior water rights holders, who were granted early water rights, and junior water rights holders, who have obtained water rights more recently. Senior water rights holders have higher priority to withdraw water than junior water rights holders, except when health and safety is involved. During water shortages, if all authorized water users’ needs cannot be satisfied, water rights holders can call TCEQ to carry out water allocation based on the Priority Doctrine [L’Oreal Stepney, 2012]. During this process, the amount of water available in the river, both now and in the next few weeks, is one critical factor for TCEQ watermasters to allocate water. River
forecasting models such as RAPID can predict river streamflow, running these models typically requires technical skills that would be difficult for TCEQ watermasters to rapidly perform. Therefore, model as a service (MaaS) is proposed to run the model on the Web. End users do not need technical skills and results can be directly retrieved on the Web.
The case study area where MaaS was implemented is the San Antonio and Guadalupe River Basin, which is located in South Central Texas (Figure 1). The drainage area of the Guadalupe River Basin is 6,700 square miles, and that of the San Antonio River Basin is 4,180
5
square miles. The limited water supply and how to allocate water effectively and fairly in the river basin have become contentious issues in the river basin, particularly during droughts.
Figure 1. The San Antonio and Guadalupe River Basin
Currently, water rights holders are required to call TCEQ to request the amount of water they wish to use. During a severe drought, daily calls are required. After receiving a water request, TCEQ decision makers will check the amount of available water in the river by
collecting information from USGS streamflow gauges. Then they allocate available water to each water user, respecting water users’ priority, based on their subjective judgment as to the impacts of these allocations. The process is repeated each day as the impacts of the previous days’
allocations become apparent in the river levels, but no forecasting is currently used. This process requires a large amount of time and the response of TCEQ decision makers is not immediate, nor is it based on best available forecasts.
A real-time Web application can improve this real-time water allocation process by automating collection of information and use of state-of-the-art forecasting models. TCEQ decision makers can then utilize the Web application to allocate water in a more scientific approach to assist subjective judgment.
6
To provide this type of support, the MaaS approach was implemented with the RAPID model, which is a river routing model developed at the University of Texas Austin for parallel computation of river discharge. Given the river network and network connectivity information, and fed with predicted water inflows (i.e., runoff) into the river network, RAPID can be run on any river network to compute river streamflow. River connectivity information is provided by NHDPlus, which describes all river networks and water bodies in the United States [David et al., 2011].
The flow calculation in RAPID is based on the matrix-based Muskingum method [McCarthy, 1939]. The two important parameters k (a storage constant with dimension of time) and x (a dimensionless weighting factor characterizing the relative influence of the inflow and the outflow on the volume of the reach) in the Muskingum method are calculated based on the work of Cunge [Cunge et al., 1969]. The parameter k is a constant value with dimension of time, and x is a dimensionless weighting factor influenced by the inflow and outflow of one specific river reach [David et al., 2011]. These parameters are calibrated using any USGS gauges located in the river basin.
The basic expression for calculating river streamflow is given in Equation (1) from David et al. [2013]:
𝑄𝑗(𝑡 + ∆𝑡) = 𝐶1𝑗∙ [𝑄𝑗𝑢𝑝(𝑡 + ∆𝑡) + 𝑄𝑗𝑒(𝑡 + ∆𝑡)] + 𝐶
2𝑗 ∙ [𝑄𝑗𝑢𝑝(𝑡) + 𝑄𝑗𝑒(𝑡)] + 𝐶3𝑗 ∙ 𝑄𝑗(𝑡) (1)
where t is time, 𝑄𝑗𝑢𝑝 is the upstream flow, 𝑄𝑗𝑒 includes lateral flows to the river network (e.g., runoff and groundwater seepage), 𝑄𝑗 is the streamflow in the exiting river reach j. 𝐶1𝑗, 𝐶2𝑗, and 𝐶3𝑗, constant parameters, are computed using Equations (2), (3), and (4):
𝐶1𝑗 = ∆𝑡 2 − 𝑘𝑗∙ 𝑥𝑗 𝑘𝑗 ∙ (1 − 𝑥𝑗) +∆𝑡2 , (2) 𝐶2𝑗 = ∆𝑡 2 + 𝑘𝑗 ∙ 𝑥𝑗 𝑘𝑗∙ (1 − 𝑥𝑗) +∆𝑡2 , (3) 𝐶3𝑗 = 𝑘𝑗∙ (1 − 𝑥𝑗) −∆𝑡2 𝑘𝑗∙ (1 − 𝑥𝑗) +∆𝑡2 (4)
where 𝑘𝑗 and 𝑥𝑗 are parameters in the Muskingum method [Cunge, 1969].
Land surface models (LSMs) with meteorological forcing can be used to compute surface and subsurface inflow as river inflows [𝑄𝑗𝑒 in Equation (1)] into the NHDPlus river network for
7
the RAPID model [David et al., 2011]. The land surface model used in this study is the National Weather Service (NWS) Sacramento Soil Moisture Accounting (SAC-SMA) model, which is based on a soil moisture and energy balance model that estimates the runoff production for each grid cell based on radiation, precipitation and surface climate [Shultz & Corby, 2006]. Hourly gridded radar-based precipitation from Multisensor Precipitation Estimator (MPE) [Seo & BreidnBach, 2002] is fed into the 4km by 4km gridded river basin using SAC-SMA method [Shultz & Corby, 2006]. The SAC-SMA model is run every hour to generate a time series of runoff values that are fed into the RAPID model to compute river streamflow. The river routing time step is 15 minutes, providing an estimate of the river streamflow rate (cubic meters per second) every 15 minutes. For the purposes of drought decision making, with water allocations made on a daily time scale, these time resolutions are sufficiently close to real time to enable effective management.
8
CHAPTER 3: METHODOLOGY
Figure 2 presents the general framework for MaaS to support rapid model-based decision making. There are three main components to the framework: Model as a Service Architecture,
Web Application, and Scenario Analysis. Cyberintegrator, a desktop exploratory workflow system, is used to generate and publish workflows (sequences of data and model execution steps)
as services. Workflows are published to the Cyberintegrator server, which is a sharing center that allows users to upload and access shared workflows as well as generate RESTful services which can communicate with Web applications through Uniform Resource Locators (URLs). Users can retrieve data and check job status from the Cyberintegrator server via the Web. They can also send model execution commands using URLs to the Cyberintegrator server. A semantic content
server is used to keep track of data products, workflows, metadata, and so on [Myers et al., 2009]. Scenario analysis can be used to generate alternative future options to explore with the
Web application. The ultimate aim is to implement the entire process of the real-time water decision support system as a Web application, including Web inputs, a published workflow service, and visualized outputs. Each of these components is described in more detail below.
9
3.1 Model as a Service Architecture
The framework of MaaS is composed of workflow desktop and Web applications. The first step to building the MaaS is to construct a workflow system to perform the required modeling steps (Section 3.1.1). Once the workflow system is completed, it is published to a workflow server (Section 3.1.2) and metadata are stored in a semantic content store server (Section 3.1.3).
3.1.1 Workflow System
The design of the workflow disseminates the model application into several disciplinary steps and links these steps into a pathway [Villa et al., 2009]. For instance, hydrologic model applications can be divided into three main steps – data downloading, model execution and results visualization. For each step, one or more specific tools can be built in the workflow system. Given the input file(s), the output can be generated using the built tool(s). Using data transfer through intermediate storage in a database, each component of the workflow system is connected until a desired result is achieved. Therefore, the workflow system achieves integration and interoperability of heterogeneous components in a loosely coupled environment
[Georgakopoulos et al., 1995]. This allows each heterogeneous component to be built using independent platforms and developers. Different data formats, programming languages, compilers and development environments for each component will not affect interactivity. Technology-based software barriers among different components are solved. However, saving interim results to a database between components can require some computational time, and users will need to balance how finely to break execution steps into independent components. In this application, a coarse set of steps are used, as shown in Chapter 4, to enable ease of initial implementation and minimal effects on computation time.
In this work, the Cyberintegrator desktop workflow system is used to build the MaaS. Cyberintegrator is an exploratory scientific workflow system developed by the National Center for Supercomputing Application (NCSA) that can be used to generate and publish workflows as services. Compared to other workflow tools, such as Taverna [Oinn et al., 2004] and Bio-STEER [Lee et al., 2007], Cyberintegrator has several advantages. Instead of creating a one-time full workflow and executing, Cyberintegrator allow users to take small exploratory steps to create a
10
workflow as they explore the data. In addition, Cyberintegrator wraps modules (fragments of code) into Web services [Bajcsy et al., 2005]. The structure of software and semantics is hidden behind Web services. Hence users do not require programming expertise to build a workflow.
Furthermore, instead of using a system-specific data structure like most workflow systems, the Open Geospatial Consortium standards (OGC) used for storing data in
Cyberintegrator are platform independent and are easy to extend to new types of data [Marini et al., 2007]. This allows external applications to easily query and analyze data in the system [Marini et al., 2007]. Cyberintegrator also provides the function of provenance recording that tracks and stores the parameter settings, the details of each step, and intermediate data products [Ludascher et al, 2006]. Hence, the user’s activities within the workflow environment are automatically recorded without the user spending time logging metadata from their experiments [Marini et al., 2010]. This capability provides an automated record for decision makers to understand and archive how the information on which they based a decision was created.
The Cyberintegrator workflow system also allows the user to create a workflow through step-by-step exploration, setting up and executing each step in turn through a user-friendly interface (Figure 3). Users can assemble the workflow by connecting the data nodes and linking the results to storage or visualization facilities, providing seamless access to resources and services. Users can access database(s) and execute model(s) remotely by making service calls.
11
Figure 3. User interface for Cyberintegrator workflow system Once the workflow is completed, it can be published to the Cyberintegrator server as described in Section 3.1.2.The workflow is executed in the background on a remote server in the Cloud (i.e., elsewhere on the internet), which enables easy use of supercomputing or parallel resources. . It is not necessary for users to keep a long-term connection to the server. Instead, users receive notification when the job is completed and then can view or download the results. After publication, the completed workflow can be shared with other users or groups through a shared library of Web services. End users can execute the workflow and download the results through the Web application [Bajcsy et al., 2009].
In addition, the workflow system allows users to inspect intermediate results and re-implement only the previous step with a changed parameter or new component instead of
executing the entire workflow from the initial step. For instance, if end users want to run RAPID for a new river basin, they only need to update the input file in the model execution step and the RAPID workflow can be executed for the new basin, without changing the visualization step.
12
The archive system in the workflow also provides data provenance, which records all generated data, workflow tools and execution step [Ludascher et al., 2006]. Using this provenance,
decision makers can know how the information on which they based decisions was created. After the workflow system is built, the Web application can then be implemented to provide user-friendly access to the workflow and Web services, as illustrated in Chapter 4.
To illustrate the workflow creation process, consider the implementation of RAPID as a MaaS using Cyberintegrator. The RAPID model application is divided into three steps. The first step is to download the data from external data sources and prepare it for the RAPID input file. The second step is to execute the RAPID model with the RAPID input files from the first step. The final step is to visualize the RAPID output.
For each step, Cyberintegrator is used to build a tool with input data and parameters. For example, the command line wizard shown in Figure 4 gives users instructions about how to build the command line tool in Cyberintegrator to execute the RAPID model. The RAPID input
parameters of start-year, start-day, end-year, and end-day are then set in the Cyberintegrator interface. An executable shell script is prepared to run each step. Given an input zip file from an external data source, each step can be executed with the set parameters and an output file is generated. Figure 5 shows all of the defined steps of the RAPID model application built in Cyberintegrator.
13
Figure 4. The command line wizard in Cyberintegrator
14
Once the three steps are implemented, Cyberintegrator provides connecting tools to link each step. The output from the first step can be used as the input file for the second step. The output from the second step can be used as the input file for the third step, as shown in Figure 6 for the RAPID MaaS application.
Figure 6. The connecting tools in Cyberintegrator that are used to link the RAPID MaaS steps
3.1.2 Cyberintegrator server
Once the MaaS workflow(s) are created in Cyberintegrator, they are published to the Cyberintegrator server. The Cyberintegrator server makes desktop software available in a simple and consistent manner using a RESTful interface [McHenry et al., 2011], which utilizes URLs to access the software, its inputs, and its outputs. Hence the software functionality can be accessed by many programming languages and Web browsers using traditional Web standards of HTTP [Florain et al., 2008, McHenry et al., 2011]. For instance, to determine which workflow is available to call on the host (the name or Internet Protocol [IP] address of the host running the Cyberintegrator server), one can access:
http://<hostname>/workflows/{id}
where the hostname is the name of the server executing the workflow and the “{id}” represents the task number that is being executed. To carry out an execution task, one can access:
15
where {executions} represents the available execution tasks on the host and {id} represents the execution task number. To access the available dataset, one can access:
http://<hostname>/datasets/{id}
where {datasets} represent the available datasets on the host and {id} determines which dataset will be accessed.
3.1.3 Semantic content store server
The data and metadata including data products, workflows, steps in workflows, tools used in Cyberintegrator, and Web publishing information are automatically saved in a platform-independent format in the semantic content store server [Marini et al., 2010]. The format used is the resource description framework (RDF), which is a general method for conceptual description or modeling of information in Web services using Open Geospatial Consortium standards [OGC, 2009], The RDF format is managed by the Tupelo semantic content repository [Myers et al., 2008]. By using URLs and RDF format, distributed heterogeneous content and relationships can be uniformly accessed using the Tupelo semantic content store server, which facilitates easy communication among each component in the MaaS framework.
3.2 Web Application
Figure 7. Publishing workflow as a service
16
to the Cyberintegrator server. Users can access the shared workflow in Cyberintegrator server via the RESTful service using the URL of each workflow. For instance, clients can access the shared workflow on the Web browser by calling the URL. The workflow execution status can be
checked on Web browsers. Through sharing the model and its output as services, the models become accessible to users anywhere in the world, and this sharing dramatically expands their usability. Figure 7 shows the framework for publishing the workflow as a service.
A Web application can then be designed as a user-friendly interface for executing the workflows, retrieving data, checking the execution status, and sharing the workflow results using service calls to the Cyberintegrator server [Marini et al., 2010]. The built Web application for MaaS allows users to assign workflow parameters, create alternative scenarios (Figure 9), and visualize the model results (Figure 10). A simple wizard guides users to create a new scenario and trigger the workflow execution from the Web. The created scenarios can also be saved on the Web, which facilitates future scenario analysis by users. Decision makers who are not familiar with a specific model or the workflow management system can still easily execute the workflow and view results using geospatial maps such as Bing Map through the Web interface.
The create scenario section (Figure 9) allows users to select parameters for the model execution. For executing RAPID, only prediction with historic NLDAS data (i.e., hindcast) or 5-day forecast NWS data can be specified through the Web application, but other model parameters can easily be added to the interface as desired. Once the parameters are selected (box in Figures 8 and 9), clicking the “RUN” button triggers execution of the model on the remote server. The results section shows the output for each scenario executed, including the streamflow under the wetter (blue) and drier (tan) scenarios, shown in more detail in Figure 10. By clicking any red USGS gauge point, the location-specific view in Figure 18 will pop up. This view is desiged to provide guidance to the user in selecting plausible scenarios to test based on the variability in historical data. The new forecast runoff is presented as a green point in the figure. Two scenarios related to the new forecast – one is wetter (the blue point) and the other is drier (the tan point) - can then be set using the figure. Then the model can be executed for these three different
scenarios and the results are also shown in the Web interface (Figure 10). In Figure 10, the most recent results are historical; the user’s earlier runs are summarized in the boxes underneath and can be easily selected and viewed in more detail. More information on the statistics provided in
17 these views are given in Chapter 4.
18
19
Figure 10. The RESULTS section of the Web application
3.3 Scenario Analysis
The third component of the MaaS framework is a scenario analysis tool. All models have uncertainty, and the scenario analysis tool allows decision makers to modify input parameters and compare results side by side. Employing scenario analysis can assist with evaluating possible future events based on different assumptions [Kepner et al., 2004]. For example, for river
streamflow prediction, scenario analysis can be conducted with different levels of rainfall/runoff. Users can assign different percentages to be added or subtracted from the original data values as the parameters for multiple scenarios. This allows the resilience of the predictions to be
investigated under various future conditions.
For river streamflow prediction and other spatially-distributed models, two approaches to scenario analysis have been implemented in the MaaS framework. The first approach is simply to
20
allow the user to vary an input parameter (in this case runoff levels) by a specified percentage at every location and in every time period during the desired modeling period. The second approach involves using historical data to fit a distribution of the input parameter at each individual
location (in this case, runoff computed by the National Weather Service in each watershed). The user is then shown the distribution at each location and invited to vary the input runoff at any one location. Alternatively, the user can assess variability at all locations and then select a single percentage to vary the parameter at all locations as in the first approach. These options are shown in the sensitivity analysis Web application in Figure 18.
21
CHAPTER 4 CASE STUDY IMPLEMENTATION
This chapter describes the implementation of MaaS in the San Antonio and Guadalupe River basins for drought management. First, it introduces how the RAPID model was
implemented as a workflow using the Cyberintegrator tool. Then a workflow case example is given to demonstrate the application of the RAPID workflow. Finally, the Web interface based on the RAPID model and the scenario analysis implementation is presented.
4.1 RAPID Model Implementation as a Workflow
The MaaS provides an easy approach for non-technical users to run RAPID through a Web application. Traditionally, users need technical skills to set the running environment for complex numerical models such as RAPID. RAPID runs in the Linux operating system, which requires basic programming skills and an understanding of how to update and link the execution and input files. The MaaS framework described in Chapter 3 provides an automated request system for the model runs and online visualization to shift environmental modeling from stand-alone applications to services running in the remote server or cloud.
To implement the RAPID model in the MaaS system, the first step was to build the RAPID workflow (Figure 11) using Cyberintegrator tools. The RAPID workflow includes three main components: 1) Prepare the surface and sub-surface inflow of water to the river network (downloading and transforming NWS data), 2) Run RAPID, and 3) Animate RAPID results. This workflow was then published to the Cyberintegrator server. The Web application clients (Figures 10) can then access the shared workflow in the Cyberintegrator server through Web browsers.
22
Figure 11. The workflow of the RAPID model
The implemented workflows are composed of two parts:1) forecast river streamflow using national weather service (NWS) data and 2) check the influence of water diversion on the river streamflow. Once the service is built, the decision makers can easily operate the model, download the output file to the desktop and view the output on the Web map. The workflow framework is shown in Figure 12.
Figure 12. The workflow framework for forecasting river streamflow Workflow 1 prepares NWS surface runoff data for the RAPID input file. The runoff data was downloaded from NWS and prepared to correspond to the RAPID connectivity file and written with the RAPID input file format.
Workflow 2 downloads TCEQ diversion data and transformed it into the RAPID input format. The historical diversion data can be downloaded from the TCEQ server and formatted into the RAPID input file. The RAPID input file was generated using the output from Workflow 1 minus the output from Workflow 2.
23
Workflow 3 implements RAPID. Applying the RAPID input file computed from
Workflow 1 and Workflow 2, the RAPID model can generate the river streamflow. Two options can be achieved here. If Workflow 1 forecasts surface runoff, Workflow 3 can forecast river streamflow. Decision makers can judge the change in future river streamflow and manage water efficiently. If Workflow 1 gives the historical surface runoff and the diversion data from
Workflow 2 is available, Workflow 3 can predict the river streamflow values affected by water diversion. In the future, the output of Workflow 3 will be fed into an optimization model to optimize the water allocation for each water user.
4.2 Scenario-based Application
Using the RAPID workflow, users can create the desired scenarios and launch the streamflow model execution through the MaaS Web application. To provide more detailed information to the user on typical runoff estimates at the streamflow gauges that could be used to guide scenario selection (as in Figures 18 and 19), five USGS gauges corresponding to the five catchments in the Upper Guadalupe river basin were selected for statistical analysis, shown in Figure 13. To illustrate how the analysis was conducted, consider gauge USGS 08165500. The results for other gauges are given in Appendix B.
Figure 13. The location of USGS gauges used in the Upper Guadalupe River Basin scenario analysis
24
The second phase of the North American Land Data Assimilation System (NLDAS2) provides runoff estimates from four land surface models [David et al., 2013]. NLDAS data from 1993 to 2011 (relatively recent data with sufficient length to be reasonably representative) was used to analyze the distribution of runoff data (Figure 14). From Figure 14, we can see that there is no long-term trend or seasonal trend for the historical runoff estimates. Hence we use the same probability distribution to represent any day of the year.
Figure 14. Estimated runoff at USGS gauge 08165500 for each day of the year from 1993 to 2011
Figure 14 shows that there are many runoff values of zero, when there was no rainfall. The user can first implement this case and then use the scenario analysis section to identify plausible alternative scenarios if the precipitation does occur. When the new runoff forecast is not zero, the histogram of non-zero values is close to the exponential distribution as shown in Figure 15. Using the method of moments [Hansen, 1982], the lambda parameter for the exponential distribution is estimated. The bootstrapping method, which measures the accuracy of estimators using a resampling method, was applied to show that the exponential distribution fits the non-zero values [Efron & Tibshirani, 1994, Varian, 2005].
25
Exploratory data analysis (EDA) techniques proposed by John W. Tukey were then applied for historical data analysis [Tukey, 1977]. The first quartile, median, mean, and third quartile values can be computed from the historical data using lambda (as shown in Figure 17). When a new runoff forecast is obtained, the user can view where the new forecast falls within the historical exponential distribution and choose appropriate bounds for sensitivity analysis.
26
Figure 16. Tukey criteria
Using the historical data range considered in this work, the lambda estimate for the selected gauge is 0.001434, which is close to the lambda median of 0.001442 from the
bootstrapping method. This shows that the lambda estimate is reliable. Then based on the lambda estimate, the parameter values Q1, Median, Mean and Q3 were calculated and displayed in the user interface shown in Figure 19. These values can easily be updated in the future as new NWS runoff estimates are obtained. Figure 19 also provides a boxplot to show the user a summary of the variability over all USGS gauges; users can then select a single percentage to vary the runoff in all locations across the watershed, if desired.
27
28
29
30
CHAPTER 5 CONCLUSIONS
This study introduces MaaS and a framework for its application in water resources management. Compared with previous work, the framework provides a more comprehensive system for model application including downloading data, executing models, and visualizing results. Most previous studies only focused on a single aspect of model application.
This work demonstrates the application of MaaS for a hydrological model (RAPID) using Cyberintegrator workflow systems. The Web applications and model services can be
implemented with any model on the Web and help non-technical users to easily run state-of-the-art models through Web browsers, providing rapid support for both real-time and longer-term decision making. The modeling service can also be coupled with other data services. The prototype implementation can be accessed through the Web at
http://rapid.ncsa.illinois.edu:8080/rapid2/.
Using the prototype system, TCEQ water managers can easily select an input data period to run RAPID and view the results on the Web. A statistical analysis of the model input data provides guidance to end users in identifying and evaluating plausible scenarios, comparing river streamflow values under multiple scenarios. This will allow water managers to be more informed about how much water is available during a drought and make rapid decisions about potential impacts of water allocation strategies. The final version of the prototype decision support system will also allow water managers to incorporate real-time optimization services for water allocation in the river basin.
The main advantage of MaaS is to enable easier integration of data and model services and break down the barriers of model execution for non-technical users, as well as technical users who may not be familiar with the model development. The original application of RAPID brings multiple challenges for new users, such as setting up the execution environment, learning the programming skills to execute RAPID, obtaining data in the correct format and resolution, etc. The MaaS application provides an easy interface for these tasks. In addition, the service application is more reusable and easily replicated [Goodall et al., 2011], allowing services created by one group to be shared with other groups. For instance, other research groups are accessing the RAPID implementation at Illinois through direct calls to the model service URL or
31
through workflows. This also enables easier application to other river basins.
Furthermore, since the development environment for each service in the service-oriented architecture is independent, different services can be integrated more easily. For instance, the RAPID MaaS has been integrated with NWS data retrieving services developed at the University of Texas. Moreover, the service applications can be implemented remotely on supercomputers with parallel computing, which can effectively reduce the solution time and enable more accurate modeling for real-time applications.
However, MaaS still poses some challenges to service developers and water managers. With model services executed on a remote server, if the remote server is temporarily down then the client application will be unavailable [Goodall et al., 2011]. Maintenance and back-up servers for operational MaaS systems will be essential. The loosely-coupled service-oriented architecture could also expose some security risks. How to prohibit improper use of the service is a critical challenge. In addition, large-scale data transfer from remote servers can be challenging for an MaaS application. Careful design to provide local copies of frequently-used data sources can alleviate these difficulties.
32
REFERENCES
[1] D. P. Ames, J. S. Horsburgh, Y. Cao, J. Kadlec, T. Whiteaker and D. Valentine,
"HydroDesktop: Web services-based software for hydrologic data discovery, download, visualization, and analysis,"Environmental Modelling & Software, vol. 37, pp. 146-156, 11, 2012.
[2] A. -. E. Ausseil, J. R. Dymond, M. U. F. Kirschbaum, R. M. Andrew and R. L. Parfitt,
"Assessment of multiple ecosystem services in New Zealand at the catchment scale," Environmental
Modelling & Software,vol. 43, pp. 37-48, 05, 2013.
[3] P. Bajcsy, R. Kooper, L. Marini, B. Minsker and J. Myers, "A meta-workflow cyber-infrastructure system designed for environmental observatories,"
2010-04-
30].Http://isda.Ncsa.Uiuc.edu/peter/publications/techreports/2005/meta-Workflow-Approaches.Pdf, 2005.
[4] K. K. Benke, K. E. Lowell and A. J. Hamilton, "Parameter uncertainty, sensitivity analysis and prediction error in a water-balance hydrological model," Math. Comput. Model., vol. 47, pp. 1134-1149, 6, 2008.
[5] D. R. Brillinger and H. K. Preisler, "An exploratory analysis of the Joyner-Boore attenuation data," Bulletin of the Seismological Society of America, vol. 74, pp. 1441-1450, 1984.
[6] A. M. Castronova, J. L. Goodall and M. M. Elag, "Models as web services using the Open Geospatial Consortium (OGC) Web Processing Service (WPS) standard," Environmental Modelling &
Software, vol. 41, pp. 72-83, 3, 2013.
[7] S. Combs, "The impact of the 2011 drought and beyond," Texas Comptroller of Public
Accounts, 2012.
[8] J. A. Cunge, "On the subject of a flood propagation computation method (Musklngum method)," Journal of Hydraulic Research, vol. 7, pp. 205-230, 1969.
[9] J. A. Cunge, "On the subject of a flood propagation computation method (Musklngum method)," Journal of Hydraulic Research, vol. 7, pp. 205-230, 1969.
[10] F. Curbera, M. Duftler, R. Khalaf, W. Nagy, N. Mukhi and S. Weerawarana, "Unraveling the Web services web: an introduction to SOAP, WSDL, and UDDI," Internet Computing, IEEE, vol. 6, pp. 86-93, 2002.
[11] C. H. David, D. R. Maidment, G. Niu, Z. Yang, F. Habets and V. Eijkhout, "River network routing on the NHDPlus dataset," J. Hydrometeorol., vol. 12, pp. 913-934, 2011.
[12] C. H. David, Z. Yang and S. Hong, "Regional-scale river flow modeling using off-the-shelf runoff products, thousands of mapped rivers and hundreds of stream flow gauges," Environmental
Modelling & Software, vol. 42, pp. 6e132, 2013.
[13] R. Denzer, "Generic integration of environmental decision support systems–state-of-the-art," Environmental Modelling & Software, vol. 20, pp. 1217-1223, 2005.
33
Processing Service for ecological modeling," Environmental Modelling & Software, vol. 41, pp. 123-133, 3, 2013.
[15] P. N. Duinker and L. A. Greig, "Scenario analysis in environmental impact assessment: Improving explorations of the future," Environ. Impact Assess. Rev., vol. 27, pp. 206-219, 4, 2007.
[16] R. Dymond, B. Regmi, V. Lohani and R. Dietz, "Interdisciplinary web-enabled spatial decision support system for watershed management," J. Water Resour. Plann. Manage., vol. 130, pp. 290-300, 2004.
[17] B. Efron and R. J. Tibshirani, An Introduction to the Bootstrap. CRC press, 1994.
[18] M. Feng, S. Liu, N. H. Euliss Jr., C. Young and D. M. Mushet, "Prototyping an online wetland ecosystem services model using open model sharing standards," Environmental Modelling &
Software, vol. 26, pp. 458-468, 4, 2011.
[19] I. Foster, "Service-oriented science," Science, vol. 308, pp. 814-817, 2005.
[20] A. Francos, F. J. Elorza, F. Bouraoui, G. Bidoglio and L. Galbiati, "Sensitivity analysis of distributed environmental simulation models: understanding the model behaviour in hydrological studies at the catchment scale," Reliab. Eng. Syst. Saf., vol. 79, pp. 205-218, 2, 2003.
[21] R. H. Gardner, R. V. O'Neill, J. B. Mankin and J. H. Carney, "A comparison of sensitivity analysis and error analysis based on a stream ecosystem model," Ecol. Model., vol. 12, pp. 173-190, 4, 1981.
[22] G. N. Geller and F. Melton, "Looking forward: Applying an ecological model web to assess impacts of climate change," Biodiversity, vol. 9, pp. 79-83, 2008.
[23] G. N. Geller and W. Turner, "The model web: A concept for ecological forecasting," in Geoscience and Remote Sensing Symposium, 2007. IGARSS 2007. IEEE International, 2007, pp. 2469-2472.
[24] G. N. Geller and W. Turner, "The model web: A concept for ecological forecasting," in Geoscience and Remote Sensing Symposium, 2007. IGARSS 2007. IEEE International, 2007, pp. 2469-2472.
[25] D. Georgakopoulos, M. Hornick and A. Sheth, "An overview of workflow management: From process modeling to workflow automation infrastructure," Distributed and Parallel Databases, vol. 3, pp. 119-153, 1995.
[26] J. L. Goodall, J. S. Horsburgh, T. L. Whiteaker, D. R. Maidment and I. Zaslavsky, "A first approach to web services for the National Water Information System," Environmental Modelling &
Software, vol. 23, pp. 404-411, 4, 2008.
[27] J. L. Goodall, B. F. Robinson and A. M. Castronova, "Modeling water resource systems using a service-oriented computing paradigm," Environmental Modelling & Software, vol. 26, pp. 573-582, 5, 2011.
[28] J. L. Goodall, K. D. Saint, M. B. Ercan, L. J. Briley, S. Murphy, H. You, C. DeLuca and R. B. Rood, "Coupling climate and hydrological models: Interoperability through Web
34
[29] C. Granell, L. Díaz and M. Gould, "Service-oriented applications for environmental models: Reusable geospatial services," Environmental Modelling & Software, vol. 25, pp. 182-198, 2, 2010.
[30] C. Gualtieri, "Urban Hydroinformatics. Data, Models and Decision Support for Integrated Urban Water Management," Environmental Modelling & Software, vol. 26, pp. 1158-1159, 9, 2011.
[31] D. Hamby, "A review of techniques for parameter sensitivity analysis of environmental models," Environ. Monit. Assess., vol. 32, pp. 135-154, 1994.
[32] L. P. Hansen, "Large sample properties of generalized method of moments estimators," Econometrica: Journal of the Econometric Society, pp. 1029-1054, 1982.
[33] J. S. Horsburgh, D. G. Tarboton, M. Piasecki, D. R. Maidment, I. Zaslavsky, D. Valentine and T. Whitenack, "An integrated system for publishing environmental observations data," Environmental
Modelling & Software, vol. 24, pp. 879-888, 2009.
[34] M. N. Huhns and M. P. Singh, "Service-oriented computing: Key concepts and principles," Internet Computing, IEEE, vol. 9, pp. 75-81, 2005.
[35] L. E. Johnson, "Water resource management decision support systems," J. Water Resour.
Plann. Manage., vol. 112, pp. 308-325, 1986.
[36] W. G. Kepner, D. J. Semmens, S. D. Bassett, D. A. Mouat and D. C. Goodrich, "Scenario analysis for the San Pedro River, analyzing hydrological consequences of a future
environment," Environ. Monit. Assess., vol. 94, pp. 115-127, 2004.
[37] R. Kooper, L. Marini, B. Minsker, J. Myers and P. Bajcsy, "CyberIntegrator: A highly interactive scientific process management environment to support earth observatories," in Proc.
Geoinformatics Conference, 2007, .
[38] G. F. Laniak, G. Olchin, J. Goodall, A. Voinov, M. Hill, P. Glynn, G. Whelan, G. Geller, N. Quinn, M. Blind, S. Peckham, S. Reaney, N. Gaber, R. Kennedy and A. Hughes, "Integrated environmental modeling: A vision and roadmap for the future," Environmental Modelling &
Software, vol. 39, pp. 3-23, 1, 2013.
[39] S. Lee, T. D. Wang, N. Hashmi and M. P. Cummings, "Bio-STEER: A Semantic Web workflow tool for Grid computing in the life sciences," Future Generation Comput. Syst., vol. 23, pp. 497-509, 2007.
[40] T. Lenhart, K. Eckhardt, N. Fohrer and H. -. Frede, "Comparison of two different approaches of sensitivity analysis," Physics and Chemistry of the Earth, Parts A/B/C, vol. 27, pp. 645-654, 2002.
[41] Y. Liu, H. Gupta, E. Springer and T. Wagener, "Linking science with environmental decision making: Experiences from an integrated modeling approach to supporting sustainable water resources management," Environmental Modelling & Software, vol. 23, pp. 846-858, 2008.
[42] B. Ludäscher, I. Altintas, C. Berkley, D. Higgins, E. Jaeger, M. Jones, E. A. Lee, J. Tao and Y. Zhao, "Scientific workflow management and the Kepler system," Concurrency and Computation:
Practice and Experience, vol. 18, pp. 1039-1065, 2006.
[43] D. R. Maidment, "Bringing water data together," J. Water Resour. Plann. Manage., vol. 134, pp. 95-96, 2008.
35
[44] N. Malleron, F. Zaoui, N. Goutal and T. Morel, "On the use of a high-performance framework for efficient model coupling in hydroinformatics," Environmental Modelling & Software, vol. 26, pp. 1747-1758, 12, 2011.
[45] L. Marini, R. Kooper, P. Bajcsy and J. Myers, "Supporting exploration and collaboration in scientific workflow systems," in AGU Fall Meeting Abstracts, 2007, pp. 07.
[46] L. Marini, R. Kooper, J. Myers and P. Bajcsy, "Dynamic publishing in digital catchments," Proceedings of the ICE-Water Management, vol. 163, pp. 27-38, 2010.
[47] G. T. McCarthy, "unit hydrograph and flood routing," 1939.
[48] K. McHenry, R. Kooper and P. Bajcsy, "Towards a universal, quantifiable, and scalable file format converter," in E-Science, 2009. e-Science'09. Fifth IEEE International Conference on, 2009, pp. 140-147.
[49] K. McHenry, R. Kooper, M. Ondrejcek, L. Marini and P. Bajcsy, "A mosaic of software," in
E-Science (e-E-Science), 2011 IEEE 7th International Conference on, 2011, pp. 279-286.
[50] W. P. Miller, R. A. Butler, T. Piechota, J. Prairie, K. Grantz and G. DeRosa, "Water Management Decisions Using Multiple Hydrologic Models within the San Juan River Basin under Changing Climate Conditions," Journal of Water Resources Planning & Management, vol. 138, pp. 412-420, 09, 2012.
[51] M. K. Muleta and J. W. Nicklow, "Sensitivity and uncertainty analysis coupled with
automatic calibration for a distributed watershed model," Journal of Hydrology, vol. 306, pp. 127-145, 5/9, 2005.
[52] M. V. Muste, D. A. Bennett, S. Secchi, J. L. Schnoor, A. Kusiak, N. J. Arnold, S. K. Mishra, D. Ding and U. Rapolu, "End-To-End Cyberinfrastructure for Decision-Making Support in Watershed Management,"J. Water Resour. Plann. Manage., 2012.
[53] J. D. Myers, J. Futrelle, J. Gaynor, J. Plutchak, P. Bajcsy, J. Kastner, K. Kotwani, J. S. Lee, L. Marini and R. Kooper, "Embedding data within knowledge spaces," ArXiv Preprint
arXiv:0902.0744, 2009.
[54] J. W. Nielsen-Gammon, "The 2011 Texas Drought," Texas Water Journal, vol. 3, pp. 59-95, 2012.
[55] T. Oinn, M. Greenwood, M. Addis, M. N. Alpdemir, J. Ferris, K. Glover, C. Goble, A. Goderis, D. Hull and D. Marvin, "Taverna: lessons in creating a workflow environment for the life
sciences," Concurrency and Computation: Practice and Experience, vol. 18, pp. 1067-1100, 2006. [56] T. Oinn, M. Addis, J. Ferris, D. Marvin, M. Senger, M. Greenwood, T. Carver, K. Glover, M. R. Pocock, A. Wipat and P. Li, "Taverna: a tool for the composition and enactment of bioinformatics workflows,"Bioinformatics, vol. 20, pp. 3045-3054, Nov 22, 2004.
[57] D. Roman, S. Schade, A. Berre, N. R. Bodsberg and J. Langlois, "Model as a service (MaaS)," in AGILE Workshop: Grid Technologies for Geospatial Applications, Hannover,
Germany, 2009, .
36
collaborative workflows: A lightweight approach," Internet Computing, IEEE, vol. 12, pp. 24-31, 2008. [59] D. Seo and J. Breidenbach, "Real-time correction of spatially nonuniform bias in radar rainfall data using rain gauge measurements." J. Hydrometeorol., vol. 3, 2002.
[60] D. J. Sheskin, Handbook of Parametric and Nonparametric Statistical Procedures. crc Press, 2003.
[61] M. J. Shultz and R. Corby, "Development, calibration, and implementation of a distributed hydrologic model for use in real-time river forecasting," in Proceedings of 3rd Federal Interagency
Hydrologic Modeling Conference, 2006, .
[62] J. W. Tukey, "Exploratory data analysis," 1977.
[63] T. Usländer, P. Jacques, I. Simonis and K. Watson, "Designing environmental software applications based upon an open sensor service architecture," Environmental Modelling &
Software, vol. 25, pp. 977-987, 9, 2010.
[64] K. M. van Hee, Workflow Management: Models, Methods, and Systems. The MIT press, 2004.
[65] H. Varian, "Bootstrap tutorial," Mathematica Journal, vol. 9, pp. 768-775, 2005. [66] F. Villa, I. N. Athanasiadis and A. E. Rizzoli, "Modelling with knowledge: A review of
emerging semantic approaches to environmental modelling," Environmental Modelling & Software, vol. 24, pp. 577-587, 5, 2009.
[67] S. Wallis, "Binomial confidence intervals and contingency tests: mathematical fundamentals and the evaluation of alternative methods," Journal of Quantitative Linguistics, vol. 20, pp. 178-208, 2013.
[68] D. A. Wilhite, N. J. Rosenberg and M. H. Glantz, "Improving federal response to drought," Journal of Climate and Applied Meteorology, vol. 25, pp. 332-342, 1986.
[69] Z. Yang, D. Maidment, J. Smith and B. Brown, "Water Forum III: Droughts and Other Extreme Weather Events October 14–15, 2013," 2013.
37
APPENDIX A
The RAPID input/output (I/O) files are listed in Table 1.
Table 1. The list of the RAPID I/O files
I/O files Description Simulation or Optimization
rapid_connect_file A list of unique IDs of all river reaches in a basin Simulation & Optimization M3_nc_file The inflow of water (as volume in m3) for each
river reach and for each 3-hourly time step
Simulation & Optimization
Basin_id_file A list of IDs of river reaches used when the model runs
Simulation & Optimization
Forcingtot_id_file A list of IDs where the modeler can use observations
Simulation & Optimization
Qfor_file The daily observed flow rates (in m3/s) corresponding to forcingtot_id_file
Simulation & Optimization
Forcinguse_id_file This is a file where the modeler wants to use observations instead of upstream flow
Simulation & Optimization
K_file A vector of parameter k in Muskingum method; it is a time
Simulation
I/O files Description Simulation or Optimization
X_file A vector of parameter k in Muskingum method; it is dimentionless
Simulation
Gauge_id_file A list of river reaches where observations are available
Optimization
Qobs_file The daily observed flow rates (in m3/s) corresponding to gage_id_file
Optimization
Kfac_file A vector of first guesses for the parameters k Optimization Qout_nc_file A netCDF file to store the flow rate (in m3/s)
with two dimensions: reach ID and time
Simulation
Most of the input files for the RAPID model are in the format of comma-separated-variable (.csv) files. The largest input file is the m3_nc_file which is a netCDF (.nc) file. The
38
rapid_connect_file, m3_nc_file, k_file and x_file which are crucial input files for the RAPID model and Qout_nc_file are described in detailed here.
The rapid_connect_file identifies the river connecting information. There are seven fields. The first field is a list of IDs for all river reaches in a basin. The second field is the ID of the unique river reach located downstream in the river network. The third field is the number of the upstream reaches, with a maximum of four. The remaining four files are the IDs of the upstream river reaches. The ordering of all the fields must correspond to the first field.
The m3_nc_file is river runoff file which is computed from a land surface model. The values of water inflow is stored in netCDF file with two dimensions – ID and time. The ordering of the reach IDs should correspond to the rapid_connect_file.
The k_file and x_file are really important for regular simulation. They can be computed outside of the RAPID model or from the optimization procedures.
The Qout_nc_file is the RAPID running results. It gives the values of flow rate in a netCDF file. The ordering of the Qout_nc_file corresponds to the basin_id_file.
Two sources of LSM - the second phase of North American Land Data Assimilation System (NLDAS2) and the National Weather Service (NWS), can be used to compute the river runoff and obtain the m3_nc_file. In the initial stage, NLDAS2 was used to feed near real-time water inflows into the RAPID model to estimate river streamflow. But in the current version of RAPID application, NWS was used to feed real-time water inflows and predicted water inflows into the RAPID model to predict river streamflow. In addition, the water withdrawal by the TCEQ water users can be considered into the water inflows. The updated water inflows into the RAPID model are calculated by subtracting the water inflows from NLDAS2 by the water diversion rate by the TCEQ water users.
39
APPENDIX B
If the observation is zero, the data summary for USGS gauges is shown in Table 2. The lambda estimate is demonstrated in Table 3. Table 4 shows the analysis results from Tukey criteria if the new observation is not zero. The Tukey figures for each USGS gauge are given in Figures 20 to 23.
Table 2. The analysis results if the new observation is zero USGS gauge No. of Zeros No. of Total
numbers 95%CI 90%CI 08166200 5543 6935 (0.7896550, 0.8086507) (0.7912031, 0.8071684 ) 08167000 5299 6935 (0.7539209, 0.7740469 ) (0.7555559, 0.7724700) 08167500 4739 6935 (0.6722498, 0.6942866 ) (0.6740294, 0.6925472) 08167800 4915 6935 (0.6978722, 0.7193998) (0.6996137, 0.7177041 )
Table 3. The lambda estimate
USGS gauge Lambda estimate Lambda median 2.5% 97.5%
08166200 0.0004714201 0.0004803921 0.0003537131 0.0006460017
08167000 0.0001058608 0.0001068631 0.00007982009 0.0001488737
08167500 0.0002085616 0.0002098986 0.0001725345 0.0002582704
40
Table 4. The analysis results from Tukey criteria if the new observation is not zero
USGS gauge Q1 Median Mean Q3
08166200 610.2457 1470.339 2121.25 2940.677
08167000 2717.55 6547.721 9446.364 13095.44
08167500 1379.362 3323.465 4794.746 6646.929
08167800 2200.591 5302.15 7649.386 10604.3
41
42
43
