An Object-Oriented Framework for Water Resource Planning.

An Object-Oriented Framework for Water Resource Planning.Knut AlfredsenDepartment of Hydraulic and Environmental Engineering The Norwegian University of Science and Technology E-mail: Knut.Alfredsen@bygg.ntnu.noBjørn SætherWater ResourcesSINTEF Civil and Environmental Engineering.E-mail: Bjorn.Sather@civil.sintef.noAbstractThis paper presents an object-oriented toolkit for building computer models for water resource planning. The focus is on building a program for flood calculations in river systems with several reservoirs and water transfer structures. The foundation for the flood model is a framework for building hydrologic models. The general framework provides the user with tools for describing the structural components of the hydrological system, their relation in the system topology and controlling the behaviour of the system during simulation. Hydrological models are often data intensive, and the framework is equipped with tools to handle both time series and spatially-distributed data in an efficient way. During development, effort has been put into supporting future changes and extensions to the model system, as well as creating sound reusable components that will benefit future development and maintenance. A flood modelling application in the Norwegian river Gudbrandsdalslågen in described to illustrate the use of the toolkit.1. INTRODUCTIONComputer models have been used as planning tools in water resources management for over three decades. The fields of computational hydraulics and hydrology are well researched, and many models and algorithms are already implemented to solve different aspects of the hydrological system (e.g. [3], [2]). For a broader water resource planning situation it is necessary to combine and interact with several of these process models to create a program system that covers all water uses in the river system. This approach requires a modular structure in the system, allowing different sub-models to be interconnected depending on the natural system at hand. Another important aspect that must be considered in new developments is creating software elements that can be reused in future projects. The use of reusable components gives benefits both regarding development time and reliability of the software produced [12]. This also will reduce development and maintenance cost for the project.A common tool for obtaining the desired modularity and reuse in software development is the application of object-oriented analysis and design methods. Object-oriented methods are also gaining more use as a complete modelling tool in hydrology and hydraulics (e.g. [20], [21], [19], [14], [15]). Considering the object-oriented structure of the hydrological system and the increasing level of integration needed in a modern hydroinformatics system, this approach should give clear advantages in this field.Many of the rivers in Norway are regulated for hydropower production. The typical Norwegian hydropower system consists of reservoirs for water collection and storage combined with tunnel systems leading the water to a power plant, which often is located several kilometres away from the reservoir. In many cases, reservoirs are located in the headwaters of a river system. The operation of the reservoirs therefore plays an important role in the water distribution in the system, both for flood operation and for the flow regime in the regulated river.This paper presents a combined flood routing, production and impact assessment model implemented as a set of modules (classes) that can be combined to closely represent the natural system. The model is designed using an object-oriented methodology and implemented using the C++ programming language. The important consideration has been to create a system that easily can incorporate new developments and changes in modelling strategy. A design based on reusable components and frameworks has been used to provide a foundation for this work and for our future developments in this field.The important processes that needed attention in this modelling system were:•Runoff calculations•Routing calculations in rivers, lakes and reservoirs •Water transfer and capacity calculations•Power production•Reservoir operation.T he processes are either implemented in the scope of this project, or earlier developments have been incorporated in the flood model to solve one of thesetasks.2. MODEL REQUIREMENTS2.1. Flood model functionalityThe objective of the model is to route water through a system of rivers, lakes and reservoirs. The model should be capable of using both hydraulic and hydrologic routing methods [17] dependent on the characteristics of the reach. In addition to the routing calculations, the model should be able to handle the water transfer and reservoir operations that are connected with a hydropower system, since both control and operation of the regulation arrangements are important for flood propagation in a regulated watershed.The main requirement for the model itself and the main objective for the selected design was to create a system that as closely as possible represents the river system that is to be analysed. The model should be able to represent all elements in the river system and connect these together to represent the water flow in the system. The structure of the model should easily permit the user to create a more detailed model of parts of the river system, or if needed aggregate parts into larger units if that is desirable.Another requirement for the model was that it should be possible to use various calculation methods in different reaches depending on the availability of data and the physical characteristics of the reach. In a routing model the question of using a full dynamic equation or simplified forms of the equation must be addressed [8]. In many cases there will be a need for both approaches due to the limitations of detailed data in some reaches. We therefore want to be able to define reaches with detailed hydraulic simulation methods installed, while other reaches may have simpler calculation methods.Models in hydrology and hydraulics are data intensive, and an efficient data handling system is needed. The routing procedures needed require both spatial data in the form of geometry information and temporal data structures during operation.The variables transported between the components should be user controlled. It should be possible to define which of the calculated quantities that is to be transferred between the objects in the model. In the case of the flood model this will be discharge and water level, but for future application we may want to include other variables in the transport process.2.2. System design requirementsA set of requirements for the design was defined based on the proposed functionality of the model. The basic requirements for the model construction were as follows:•Strongly modular structure.•Reusability of existing tools and providing reusable components for future developments.•Adaptability to user needs regarding data and methods.•Easy extendible with future algorithms or methodologies•Connectivity to existing models and systems To be able to build a system model that would represent the real world system as closely as possible, the model must have a strongly modular structure. Each of the modules must contain necessary information and operations in the internal structure. The modules must have a simple interface to access the information. The encapsulation of information in an hydroinformatics system is described by Abbott [1] and is handled by using the encapsulation mechanism in the object-oriented design. By building on defined interfaces and using inheritance, the user can integrate new modules into the existing hierarchy. Another important feature in the modular system approach in this project is the separation of calculation methods (the actual hydrologic and hydraulic processes) from the components that describe the structure of the system. This allows us to change the calculation method used without any code changes inside the structural components themselves.An important consideration in any software project is the ability to reuse components during development. Reuse was a very important consideration in this project, and effort has been put into the creation of components that could be reused in new projects. Experience with earlier projects such as using the data containers for time series and curves, shows that reuse gives a significant reduction in development time and also in the time spent on correcting errors. Both these factors contribute to a reduction in overall project costs. One of the goals in this project was to make sure that new classes would add to our library of reusable components.Experience with earlier developments led us to put emphasis on user configurability. This was stressed during development, mainly by allowing the user to define data, computational methods (processes) and transported parameters without requiring changes in the base structures of the program. To facilitate this, the base structures will support data containers that can accommodate a variety of user-defined data structures and data types without any changes being required in the base component itself.By separating the implementation of computational methods from the structural components we allow both the additions of the user’s own developments and externally developed algorithms as computational methods in the flood model. Taking the amount of work done incomputational hydraulics into account, it is important tobe able to consider the existing tools for inclusion into the model.The need for future extensions of the model is maintained in two main ways. Inheritance hierarchies are used throughout the code when this was applicable, and most of the storage classes are defined with generic interfaces through the use of templates. In the class hierarchies, key functions are defined as pure virtual requiring re-implementation before use. The combination of this with an abstract base class prevents the user from developing classes that will not function in the context of the model.To take advantage of previously developed program systems, the model design allows for inclusion of these both as internal methods and as external data providers in the system. If an external program is to be used, an interface method must be derived from the method hierarchy that encapsulates the external program system. This interface will make sure that data is retrieved from the structure components and placed on the format required by the external program, and it will control the execution inside the model system. In some cases it has been necessary to alter the simulation strategy to accommodate the external program. This is done by altering the simulation control system.The model was designed in two steps, first a basic framework for hydrological modelling was designed and implemented [4]. This will work as a foundation for the flood model and also for future projects in this field of model development. The framework design supports both reuse of objects and a strongly modular design [7]. The flood model was created partly by using components of the framework directly and partly by developing new components in the framework scope that was particular to the flood model project.2.3. Related workSeveral program systems exist for flood routing, e.g. NWS Dambrk [17] and MIKE11 [10]. These are mostly based on solving the full St.Venant equations. The most advanced of these models can handle river networks, reservoirs and flooding over areas adjacent to the river channel. Most lack support for catchments, water transfer systems and hydropower-plants. By utilising the process separation of the flood model, it is possible to integrate one of these systems into the flood model if needed. Through the River System Simulator project [16] a common data exchange was developed for a selection of well-known models, thereby providing an integration platform. Compared to the flood model, this approach still operates with separate models, lacking the seamless integration over a common river system description. Several approaches have been made to utilise object-oriented methods to create flexible models for river system analysis. Shane et al. [21] present a system for reservoir and power plant modelling. Through the use of specialised controller objects this system can simulate the power system both through optimisation and rule-based control. Some routing methods are also available for the river reaches. The HEC-HMS system [9], a successor to the HEC-1 model from the US Army Corps of Engineers Hydrologic Engineering Center, is a precipitation-runoff model based on a detailed basin description. The HEC-HMS model provides the structural elements to build the basin model and a set of hydrologic methods for computations in each element. The Process Integrating Network (PINE) model [19] models precipitation-runoff in catchments using a node network representation of the hydrologic system. PINE supports inclusion of user defined methods, and through a semi-distributed approach to modelling it provides opportunities to model different types of land use. PINE also has been used for runoff calculations in urban areas. Changes in land use and urbanisation can be important factors in flood calculations, and plans are made to integrate PINE into the flood model to handle sub-catchment processes. Jamieson and Fedra [14],[15] present the WaterWare system that uses objects to describe the real world system in a similar way as the flood model. Through the use of ModelScenarioObjects, data can be retrieved from the general model and be prepared for use in a simulation system. This procedure resembles the River System Simulator model integration and also the external program integration used in the flood model. The WaterWare system provides a comprehensive GIS and database support. Compared with these, the flood model will offer precipitation-runoff modelling, routing methods and hydropower system operation in one package. The ability to define the computational methods and the transported matter freely, gives us a powerful platform for future model extensions.3. MODEL COMPONENTS3.1. OverviewThe components of the flood model are presented in the following sections. This includes both relevant parts of the underlying framework and the derivations that were made when the flood model was created. The underlying framework structure is divided into four main parts:•Structural components and system topology – defines the elements of the hydrological system that is to be modelled, e.g. rivers, lakes and catchments. The basic framework structure contains the most common elements, in actual applications it may be necessary toderive application specific elements.•Computational methods – contains the foundations for defining the mathematical models used to represent the processes in the system. The base framework defines the interface to the computational methods.• Data containers – a set of classes for data storage andhandling. This set of components also contains special data containers made for some of the mathematical models used in the framework, e.g.finite element grids.• Simulation control – the overlying system that definesthe simulation strategy and controls the execution of the model.The flood model itself is created partly by using components of the framework directly and partly by extending it to create the necessary computational methods and special structural components needed in this model.3.2. Structural componentsThe structural components are the core of the modelling system. The structural component describes the elements of the real world hydrological system with their state, structure and behaviour. In object oriented terms the state and structure are defined by the internal variables,the behaviour is defined by the computational methods that are related to the component. In addition, the structural components can be related to each other in a network that describes the topology of the hydrological system.The structural components are defined in a hierarchy with a common base (Figure 1). The Hydcomp (base)class is the common node for insertion into the network structure, and as an abstract base for deriving new structural components. The abstract definition of this class prevents the user from using it directly, it is merely a foundation for the development of classes that represents anatural element in the hydrological system. A similar constraint is set on the Waterway class, which is a common base for all transport reaches.A set of functions are defined as virtual in Hydcomp ,these can be implemented in each of the derived classes to reflect the actual behaviour. The functionality for transport of matter between components is defined and given a default implementation, but the components are also defined as virtual so that they can be redefined if special cases arise. The Hydcomp class also stores links to its upstream and downstream neighbours and the storage and retrieval system for data connected to the object.Data can be added to the structural components as required data that can either be part of the physical category (e.g. cross-sections for river reach) or state parameters (e.g. discharge or waterlevel). The state parameters are designed to hold the data that is updated during the computations. The data containers are defined in a template structure and they can store both aggregated data in the form of classes and ordinary data types.All computational methods are separated from the structural components and can be added at need by the user. This feature is described more closely Section 3.3.When data and computational methods are added to the structural component, we have a complete computational element that can be inserted into the network. Figure 2shows the structure of a computational element.The transport of matter between components is defined in functions found in Hydcomp . As mentioned, these functions have a default implementation but it is also possible to redefine them if necessary. A special control system makes sure that the exported item from the upstream component is correctly transferred to the receiving item in the downstream component. The mapping is user defined and any structure can be transported as long as it has equality and addition operators properly defined. Control functions can beLink to upstream elementLink to downstream elementFigure 2 Computational elementFigure 1 Hierarchy of structural components.Notation after Booch [6].added to verify the transport. This is specially needed in the case of a downstream division (a downstream branch), or if the values should be balanced during a computational procedure. A similar control object handles a mapping between each component and the corresponding legal data types for this component. This is invoked each time a new data element is inserted, and if this is not a legal data type the insertion will be aborted. The export and mapping controls are implemented as global objects using the singleton pattern[11].One of the main considerations in the design of the structural components was to create a system that could define a river system with data and interactions without being linked to any specific computational application. The structural hierarchy can therefore form a basis for different applications in water resource planning. In addition, the structural elements and the topological information can be used as a tool for visualisation of the river system and as a front end to data. One of the future plans for this system is to investigate the possibility to store the system in an object-oriented database.When the computational elements are defined for the river system they are inserted into a network structure that defines the natural topology of the river. This is implemented in the form of a directed graph structure where each node represents an element in the hydrological system. An iterator is made to traverse the structure during calculation. The traversal procedure establishes a list of nodes with nodes without upstream dependencies first. This is done by executing a topological sorting algorithm in the iterator. The resulting list of elements is traversed and the calculation methods for each element are invoked. Special considerations must be taken in cases where a downstream element is influencing the upstream neighbour (e.g. in cases of backwater effects during a routing calculation) or cases where the default flow direction is changing in flat areas during a simulation. 3.3. MethodsDuring the model design phase we specified a system with separation between the computational methods and the classes that describe the structural components in the system. The main reason was to find a way to remove the code of the calculation methods from the classes that describes the structural components. This gives the user the opportunity to add new methods to the model without changes in the component source code. Another benefit is the possibility to have an array of methods to choose from, providing the user with the opportunity to build a model with computations that match the detail needed and data available for each reach.The flexible method connection is achieved by building a separate hierarchy of computational methods and connecting these to the structural hierarchy through their base classes. The user can derive new computational classes from the hierarchy and automatically have them ready for inclusion into the structural components. The separation method we selected closely resembles the Strategy pattern defined in [11]. All the details about the connection and operation are hidden inside the base classes out of view from the user of the system. Figure 3 shows a part of the hierarchy and the relation to the structural componentsWhen developing a new computational method, a set of virtual functions defined in the base class for computational objects (CompObject) must be implemented. These functions include the calculation function, the verification function and data retrieval function. The data retrieval function is called when the method is connected. If the data needed is not present in the structural component, the user gets a message back either to add the needed data or select a method with a reduced data requirements.Parameters that are specific to the mathematical method that is implemented will be transferred in a method specific data block.This approach has proved to be a very effective way of building applications with a flexible number and types of computational methods available. Methods can be added depending on the characteristics of the reach that is to be computed, the available data and the needed degree of output.3.4. DataOne of the most important data types in hydrological models is time series. Hydrologic simulation models use time series both as input and output. An example is the discharge series produced by the flood model for selected points along a river, or the input series of precipitationand temperature to a catchment model.Figure 3A part of the computational method hierarchy with link to the base component of thestructural hierarchy.In order to obtain modularity and reuse of software components, classes for time series have been developed, providing the user with a consistent interface to time series data. These classes have been developed in accordance to the same principles as the String and SubString classes in the National Institute of Health (NIH) class library [13]. Generally, there are two main types of time series, one having constant time interval (regular series) and the other having time stamped event data.Template versions of regular and irregular time series classes have also been made in order to keep time series of user defined data. For example, pictures are collected with regular intervals and stored in a specialised image class. Then, each individual image is being inserted into a regular time serie of image data. The time attribute of the image is used to find its position in the time series.The main time series classes are RegulerTimeSerie and IrregularTimeSerie which keeps the time series data and its attributes for time series having regular time interval and series having irregular spaced or event data respectively. They share a common abstract base class, enabling both types of time series to be inserted into collection classes like lists and stacks.The time series data classes inherit from a base class that allows them to be part of a model-view controller structure. This conforms to the “observer” pattern [11]. This facility opens the way for dynamic presentation of results during a simulation, as well as a dynamic presentation of environmental data recorded by an automatic data acquisition system.Specialised classes for time series transformations have been developed. They take one or more time series data classes as input, either directly or through a Model-View-Controller relationship. Several transformation classes have been developed:•Functional transformations. This transformation function uses an (x,y) curve to produce a new time series from the original one.• A time series calculator which has been created to support simple arithmetic transformations of regular time series.•Sorting and creation of duration curves.•Time series statistics.A time series collector is developed in order to store and manage time series that are being generated by the model.A hierarchy of input/output classes has been developed in order to read and write time series data from different databases and file formats. No input or output functions have been implemented in the data classes themselves, this ensures that no data classes have to be modified or extended when new file formats are developed.In hydrological models, two-dimensional and three-dimensional curves are frequently used. A set of classes for these types of data has been developed, giving the user a consistent interface to this type of information.Curve and surface data classes have similar properties as the time series classes regarding dynamic presentation through a Model-View-Controller interface. Curves and Surface data classes are equipped with the same type of separate I/O structure as the time series classes.Similar data structures exist in the system to handle the spatial data needed to describe the structure of the components. These include cross sectional data from rivers, triangular grid structures and some other grid structures made for numerical modelling.3.5. Input/Output systemData for the simulation models can be handled by several file systems and relational databases. In order to give flexibility, and a possibility for the end user to choose storage format, each individual component in the entire model may be able to read from and save itself to a variety of file formats and database systems. The problem is that every file format or database will need a unique piece of source code for the structural objects, computational objects and container objects in order to save and restore them. This leads to a huge amount of source code in the model only for the purpose of reading and writing objects to external storage.The solution is to separate the input / output code from the classes of the model. Every data class type in the application will have one member function for reading, and one member function for writing.A global object named ApplicationSetup keeps information about which input / output system that is in use at the moment. Another utility class named IoFactory, being developed after the factory principle [11], is responsible for the instantiation of the storage class that matches the storage system in use. After having created the storage class which both matches the actual data class and the selected file system, the IoFactory returns that class.A consequence of this approach is that every data class type must have a standalone input / output class hierarchy. This class hierarchy has an abstract base class which holds the input / output interface. For every file system and database we need a concrete class being derived from the abstract base class. This concrete class keeps an implementation of the read and write functions for a specific data class and a specific file system. The advantage is that there will be a consistent interface for external storage that is the same for all file systems and databases, and there will be no need for modification in the data classes when new storage systems are incorporated. The problem is that there will be a need fora new class hierarchy which serves input / output every。