1. Project Team and Focal Points

Office of Hydrologic Development (OHD) - Lee Cajina
Apex Digital Systems, Inc. (Apex) - Stephanie Liu
Arkansas/Red River Basin River Forecast Center (ABRFC) - Billy Olsen
West Gulf River Forecast Center (WGRFC) - Jerry Nunn

2. Background

The OHD- Hydrologic Science and Modeling Branch (HSMB) proved there are potentially large benefits in river forecasts from distributed modeling. The results from using the Hydrology Laboratory Research Modeling System (HL-RMS), a distributed modeling system prototype developed at OHD, were very positive during the Distributed Modeling Intercomparison Project (DMIP). To build on this work, OHD management has identified implementing an operational distributed river forecasting model as one of its priorities.

Although the hydrologic aspects of distributed modeling have been researched for several years, the software engineering challenges of implementing a nationally supported distributed modeling river forecasting system have only recently been considered. Implementing this system presents a big challenge because the software and system architecture of the National Weather Service River Forecasting System (NWSRFS) was not originally designed for distributed modeling, and although there have been significant enhancements to NWSRFS over the last 20 years, the basic underlying architecture is still the same. Implementing an efficient and robust distributed modeling system will require significant changes to the current software and system architecture.

To assist OHD in engineering a distributed model river forecasting system we have teamed with Apex Digital Systems, Inc. Apex has been designing custom, scientific software systems for over four years, and has expertise in all phases of software engineering. To ensure we deliver a system that is scientifically sound and useful for operational river forecasting, we will also solicit feedback and participation from RFCs. We have asked the ABRFC and WGRFC to be a part of our team. The collective expertise of each team member will help engineer a useful system.

3. Goal and Current Scope

The end goal of this project is to develop a software system that will support the distributed modeling requirements of a wide range of users. Ultimately, this will include tools to support RFC forecasters and developers, WFO forecasters, and research scientists. By working through a formal software design process and identifying the needs for modernizing the software and system architectures currently used for river forecasting, the system that results from this project should be capable of supporting existing scientific algorithms for distributed modeling and, perhaps more importantly, be flexible enough to accommodate evolving scientific capabilities and user needs.

Since initial successes with the HL-RMS prototype have been in the research setting, an important part of the design process will be to identify the improvements required for effectively using the model in an operational setting. Thus, gathering feedback from forecasters is a critical component of the design process. After some initial requirements gathering work and discussions with ABRFC forecasters who have begun testing the HL-RMS prototype, the project team has concluded that without short term enhancements to the existing HL-RMS prototype, it is not possible to understand the benefits and limitation of the current system in an operational environment and to properly define longer term requirements. Given this, the Distributed Modeling System (DMS) development project has been divided into two phases. DMS 1.0, which does not include any system architecture changes, will be a short term project designed simply to enhance the current HL-RMS prototype to facilitate testing and more meaningful requirements gathering for DMS 2.0. Efforts for DMS 1.0 will focus on improving the HL-RMS prototype so both RFCs testing the software can help us determine some of the science and system related requirements needed to deploy an operational distributed modeling system. At the end of DMS 1.0, the DMS team and OHD/HL management will decide whether it is best to address some of the RFCs science and/or system related concerns through another version of the prototype (DMS 1.X), or whether moving into DMS 2.0 is a better alternative. Efforts for DMS 2.0 and beyond will focus more on software architecture changes required to deliver a more robust and flexible distributed modeling framework.

4. Design Approach

Apex has designed a requirements development approach that reflects the unique nature of this project. The general tasks in the requirements definition process are:

• Technical review
• Define user classes
• Define high-level use cases
• Develop high-level current state functional diagrams
• Develop high-level future state functional diagrams
• Field Review
• Define detailed use cases
• Document current data model and data flows
• Design future state data model and data flows
• Design interface mockups, where applicable
• Design test plans

The deliverable at the end of DMS 2.0 will be software integrated into AWIPS, including documentation, which will allow all the identified users use distributed modeling for river forecasting. For DMS 1.0, we will deliver an enhanced prototype to two RFCs.

6. Success Criteria

The final indicator of success is the capability to generate river forecasts using distributed modeling within AWIPS. As intermediate indicators we have identified milestones as part of a detailed project schedule. 

7. Project Schedule Details

DMS 1.0

The current project schedule for DMS 1.0 consists of tasks in the areas of project planning, requirements development, implementation, testing, and project summary.

DMS 1.0: Project Planning

This phase of the project, which ends in late May 2003, is where we clearly define the objectives and scope of the project using guidance from OHD management. As part of project planning, we have already gathered comments about the existing HL-RMS prototype and potential enhancements from ABRFC, currently the only RFC with experience using HL-RMS. The information was collected during a two-day discovery session at ABRFC on April 15 and 16, where we discussed software engineering issues related to implementing a distributed modeling system. Another reason for our visit to ABRFC was to develop a better understanding of the workflows at an RFC. We feel in order to produce an operational system, it's necessary to have a basic understanding of what daily operations consists of for an RFC forecaster. During project planning we will also be selecting a second RFC to test the enhanced prototype (DMS 1.0) and gather feedback from. A second RFC will give us a better representation of future users. 

As part of project planning, we have also been planning on how to execute the project by creating a detailed project schedule and this document (the project plan). The project schedule and plan will help the team coordinate our activities and make sure everyone has consistent expectations.

DMS 1.0: Requirements Development

For the initial phase of distributed modeling development, requirements will be defined and documented on three levels, each of which is described in more detail below:

Prototype Data Management and Performance
Initial indications are that an important area for prototype enhancement is its data management processes. Due to the very large volume of data, these processes require extremely long timelines, which makes calibrating the system a difficult task. Initially, Apex will review in detail the data structures, the current data management processes, and other features that affect performance in the prototype. Subsequently, Apex will define specific architectural modifications that will improve the performance and reduce the times required for prototype calibration and operation.

Prototype User Interfaces
Currently, the prototype does not provide any user interfaces, requiring users to edit batch input files according to documented specifications. Requirements definition for prototype user interfaces will focus on basic capabilities required to enable effective testing and initial production use. Some of the user interface requirements will correlate with requirements defined under the "Prototype Data Management" section described above.

Tools
To evaluate and use the HL-RMS prototype effectively, users will require additional visualization tools. Currently, it appears that the only primary required tool is an adapted version of XNAV. Requirements definition will focus on specific features of this tool.

DMS 1.0: Implementation

Implementing the mutually agreed upon requirements, will consist of software developers designing, reviewing the design with HSEB leadership and building/coding the software. The HSEB leadership reviews will keep them informed and give them an opportunity to tell us about potential problems. In the area of data management, Apex will be a key contributor to designing enhancements to the existing HL-RMS code and HSEB resources will focus on coding and testing those enhancements. Apex will also work with ABRFC to design and build the HL-RMS input interfaces, while ABRFC will lead designing and building of the enhanced prototype tool. The tasks in system integration and testing and writing documentation will be shared among the three groups with each group assigning a focal point for their respective areas of development. After presenting OHD/HL leadership a summary of the implementation phase, DMS 1.0 will be deployed to ABRFC in mid September 2003 for more testing and use.

DMS 1.0: Testing

The DMS 1.0 testing phase is about a three month period starting in September 2003 where ABRFC and the second RFC about one month later (in early October 2003) will evaluate DMS 1.0. As part of testing, both RFCs will go through scenarios to determine the value of existing DMS 1.0 features and define others needed. We will combine the RFCs' feedback into monthly status reviews for OHD/HL management. 

DMS 1.0: Summary

The last phase of DMS 1.0 is summarizing the project. OHD and Apex will gather the comments and feedback from the RFCs, and then ask them to collaborate with us to write a report to distribute to the other RFCs. The report should be complete in early January 2004. After summarizing DMS 1.0 we will be ready to focus on DMS 2.0.

DMS 2.0

The project schedule for DMS 2.0 has not been finalized. The details of DMS 2.0 will be clearer as DMS 1.0 concludes.

8. Issues and Unknowns

Operational distributed river forecasting is a new concept for OHD, therefore, a detailed requirements analysis is necessary. At this time, we do not know what new features we will submit to AWIPS.

The ideal solution for implementing a distributed river forecasting model may require some updates to the AWIPS baseline architecture. Therefore, the full-featured implementation of an operational distributed river forecasting may not be in place until AWIPS OB-5 and beyond.

Project Schedule (PDF format)

  (A full version of the project plan is availble in Microsoft Word Format)