International Environmental Modelling and Software Society (iEMSs) 2010 International Congress on Environmental Modelling and Software Modelling for Environment’s Sake, Fifth Biennial Meeting, Ottawa, Canada David A. Swayne, Wanhong Yang, A. A. Voinov, A. Rizzoli, T. Filatova (Eds.) http://www.iemss.org/iemss2010/index.php?n=Main.Proceedings An open-source model platform for water management that links models to a generic user-interface and data-manager Julien J. Harou1, Didrik Pinte2, Amaury Tilmant3, David E. Rosenberg4, David E. Rheinheimer5, Kristiana Hansen6, Patrick M. Reed7, Arnaud Reynaud8, Josue Medellin-Azuara5, Manuel Pulido-Velazquez9, Evgenii Matrosov1, Silvia Padula1, Tingju Zhu10 1 University College London (UK) (firstname.lastname@example.org), 2 Enthought (BELGIUM), 3 IHE Delft (Holland) & ETH (Switzerland), 4 Utah State University (USA), 5 University of California, Davis (USA), 6 University of Wyoming (USA), 7 Pennsylvania State University (USA), 8 Toulouse School of Economics (INRA-LERNA) (France), 9 Polytechnic University of Valencia (Spain), 10 International Food Policy Institute (USA) Abstract: Water management models that lack a user interface, data management, reporting and visualization capabilities are less likely to make an impact on real world water systems. Model platforms can improve this situation; they allow researchers and model developers to link model codes to a generic user interface and data management system. We present an open-source model platform for network-based models called HydroPlatform. The platform links users and their data to water management models through generic import/export functions or custom add-ins. This paper focuses on export functionality, and specifically on a link to the Generalized Algebraic Modeling System (GAMS). HydroPlatform is currently being used for several large-scale modeling projects and add-ins have been built for two generic water management models. Benefits, limitations and future developments of the software are discussed. Keywords: water management models, modeling frameworks, decision support systems (DSS), simulation and optimization models, model platforms, open-source. 1. INTRODUCTION Although researchers propose and apply many innovative models to help manage water resources, only a few models are regularly used in practice. ‘Real-world’ modeling studies are data intensive and have time constraints. In addition to the software related to modeling water movement and allocations, real-world water studies require ways to efficiently create, manage and visualize model inputs, scenarios and results. In this paper we call this ‘user-software’, i.e. software that helps users apply a mathematical model to a real case study. To meet this need, practitioners increasingly use regularly–updated decision support system (DSS) software for water resources studies rather than models developed in research institutions which typically lack user interfaces, data management, reporting and visualization capabilities. State-of-the-art research models are less likely make a significant contribution to water management globally unless significant resources are applied to building user-friendly model interface. HydroPlatform provides water management model developers a generic user-interface and data management system. Any model with a network structure (node and links) can be linked to the platform regardless of the language or software used to create the model. HydroPlatform allows model developers to quickly and inexpensively link network models to a modular and flexible open-source platform. To better explain the context for why such a linkage is useful, we briefly describe the structure and objectives of water management models. We then list existing software Harou et al. / An open-source model platform for water management options, including model platforms, a term introduced here. We describe the structure and organization of the HydroPlatform software and show how the platform can be used to connect to commercial models and modeling systems such as the Generalized Algebraic Modeling system (GAMS). Finally, limitations, project structure and future developments are briefly discussed. 1.1 Water resource management models Since Maass et al. (1962), water resource systems have been modeled as networks to represent hydrology, infrastructure (storage, conveyance, treatment, etc.) and diverse water demands. The network structure is straightforward, flexible, parsimonious and works for both simulation and optimization models (Letcher et al. 2007). Management models use simulation or optimization methods to model the use, flow and storage of water throughout the system under different scenarios, infrastructures or policies. Simulation models predict system performance under a determined set of conditions and rules. Optimization models search through a range of alternatives to find which system solution best satisfies mathematically stated objectives taking into account various physical, environmental, social, political and institutional constraints. The purpose of management models is to support planning and management decisions for system design, expansion and operation. 2. SOFTWARE APPROACHES There are many software options currently available to run water management models. These options include dedicated water resource decision support systems (DSS), modeling frameworks, commercial modeling systems, and stand-alone software. The boundaries between these approaches sometimes overlap. We describe each type before introducing the model platform approach. 2.1 Water resource decision support systems (DSS) A DSS is a user-interface built around one or more custom models. The user-interface manages a particular model or modeling process and provides a system to enter, store, and retrieve model data, run the model(s), and view results. Disciplinary water resource DSS have been historically the most popular choice for water resources management studies; some systems have been in use for over 2 decades. Established water resource management DSS include WATHNET (Kuczera 1992), AQUATOOL (Andreu et al. 1996), OASIS (Randall et al. 1997), MISER (Fowler et al. 1999), MODSIM (Labadie and Baldo 2000), RIVERWARE (Zagona et al. 2001), MIKE BASIN (Jha and Das Gupta 2003), CALSIM (Draper et al. 2004), REALM (Perera et al. 2005), WEAP (Yates et al. 2005), WRAP (Wurbs 2005), HEC-ResSim (USACE 2007), WaterWare (Cetinkaya et al. 2008), RIBASIM (WL Deflt Hydraulics 2004), AQUATOR (Oxford Scientific Software 2008), and WARGI (Sechi and Sulis 2009). Advantages of this approach are its conceptual simplicity, the ability to accommodate popular legacy codes and full customization of the user experience around a specific model or set of models. However, this approach forces developers to build, maintain, and extend (as new models are included) the user interface to accommodate existing and new models. Only a handful of DSS exist because software development and maintenance costs are high. As more models or functionality are included to allow integrated assessment, it becomes more effective to use the component-based paradigm (next section). 2.2 Modeling and Component-based frameworks Modeling frameworks (Argent 2004) or application hosting systems (Rizzoli and Argent 2006) enable building environmental management systems by assembling different components. Such frameworks are designed to integrate models, where modular Harou et al. / An open-source model platform for water management components can be assembled to form a custom application. A component-based approach is ideal for building interdisciplinary models as it provides a structured way for different models to interact. Rizzoli and Argent (2006) and Argent et al. (2006) review modeling frameworks that can be used to build integrated water resource management tools. Examples include the Interactive Component Modeling System (ICMS) (Argent 2004), TIME, the Integrated Modeling Toolkit, TwoLe (Soncini-Sessa et al. 1999) and others. One potential disadvantage of using comprehensive modeling platforms is they may require that model components be substantially rebuilt to be compatible with the framework. This task has been simplified by the open modeling interface (OpenMI) that allows building wrappers around legacy codes allowing them to be connected to other models (Gregersen et al. 2007). If modelers are willing to adopt a modeling framework and learn the skills required to modify their existing tools for compatibility with a new platform, the rewards in terms of usability and future integration of other models can be large. 2.3 Commercial modeling systems When more model formulation customization is required than what is offered by existing water management DSS, another option is to use generic commercial modeling systems. Both simulation and optimization variants exist. Optimization modeling systems integrate model data, formulation, solution and results definition. These systems separate generically posed mathematical model formulation and the data related to a particular application or “instance” of the model. The ability to flexibly define the data sets for which model equations are applied enable relatively quick development of models. Examples include GAMS, AMPL, LINDO and AIMMS, each of which link model formulations written in high level languages to commercial optimization algorithms called solvers. These systems are flexible, transparent, self-documenting, provide simple links between model formulation and solver solution, and are widely used by researchers and systems analysis practitioners to build custom models. Simulation modeling systems (also referred to as ‘systems dynamics’ software) solve user-defined simulation models with a commercial solver engine. Examples of commercial systems with simulation capability include STELLA, Goldsim, Powersim, AnyLogic, MATLAB Simulink, and others. Some modeling systems allow building custom graphical user interfaces (GUI), while others (e.g. GAMS) do not. 2.4 Stand-alone programs Traditional stand-alone programs were intended for well conscribed analyses with predefined inputs and outputs. Alternatively the term ‘monolithic’ is used by Rizzoli and Argent (2006) to underline the static and less flexible nature of these programs, particularly when it comes to linking them to other programs. Many legacy stand-alone programs are prevalent and effective due to their simplicity and familiarity. Some common examples include MODFLOW, HSPF, SWAT, HEC-RAS, etc.... An effective software solution should be able to accommodate such programs. 2.5 Model Platforms Models built using commercial modeling systems, stand-alone programs and modeling frameworks often lack easy-to-use interfaces. Model platforms manage, store and display model input and output data. Unlike a modeling system, model platforms do not support model formulation and solution; models are external and built independently ( Figure 1). The goal is a software platform to enter, manage and visualize model inputs and results and exchange these with models through export/import functions or add-ins. The term ‘model’ rather than ‘modeling’ platform underscores that model coding does not occur within the platform. Rather the platform hosts existing, external models. The external model no longer requires its own user interface and data management software. If tighter coupling between the user-interface and model is preferred, platform ‘add-ins’ can provide seamless integration (the user need not know that several applications are running). Harou et al. / An open-source model platform for water management Interface Database Manages & displays model inputs & outputs Export/import functions or add-ins Models Open-source, freeware, or proprietary Figure 1: Model platform concept: user-software (interface and database) connect to external model(s) via generic functions or add-ins. The challenge of efficiently building effective but flexible user interfaces and data management systems for existing water management models is not new. Existing solutions include creating a custom interface from scratch for a specific model or using a modeling system that already has user-interface capabilities. An intermediate solution is using a Geographic Information System (GIS) to store and visualize data that is then passed on to a specific model. These approaches and others are reviewed by Argent (2004). All approaches have advantages and limitations but they all require significant investment by modelers beyond building the model itself. Most water management DSS create a specific user interface to link to a particular model This technique can be effective but costly. Below we describe HydroPlatform, a model platform software that allows modellers to link a generic user interface to various models thereby decreasing development costs.. 3 HYDROPLATFORM HydroPlatform is an open-source, generic model platform for water management networkbased models. The model platform manages and displays spatial and temporal model data. Models are run either independently, uncoupled from the platform’s user-interface and database, or from within the platform using add-ins. Project goals : Make research models easier to use for real problems Help modelers focus on model development, not data management Software objectives: Allow modelers to create, manage and visualize network model data efficiently Provide an intuitive graphical user interface (GUI) using object-oriented code Maintain generality and independence from any single model or modeling system Use open-source components for maintainability, transparency and lower costs HydroPlatform is an initiative by and for the water management community and its name has been selected for that audience. However, the tool itself is generic and can serve as an interface for any mathematical network model (transport, energy, trade, etc.). 3.1 Capabilities The completed first phase of HydroPlatform development focused on input, storage, display and export of model data. Node-link networks are built by dragging and dropping node and link objects over a map. The map can be a georeferenced raster or vector data or a non-georeferenced background image for spatial reference. Custom network objects (nodes or links) can be built by defining and adding custom data fields to the object. These fields include parameters, seasonal parameters, time-series, and tables of any dimension. Harou et al. / An open-source model platform for water management A database made for one model can be reused for a different model. Imagine an initial database was prepared for Model A but now needs to be used for a similar but different Model B. Model B possesses extra parameters and functions to represent desalination plants. In this case the user would save the Model A database as Model B (using 'Save As'), then go to the Object Type Editor and define a new Object Type called for example ‘DesalNode’. Then, new DesalNodes can be added to the existing network, populated with data, and the new dataset can be exported to Model B. Model data is stored in a database residing either on the analyst’s local computer or on a network. This flexibility enables collaborative model building over the internet so that modelers in different locations can work concurrently on a shared system. Export Functions allow networks defined and data entered in HydroPlatform to be easily exported to external models. Exported data also includes connectivity matrices showing how network nodes in a complex water system are linked. These matrices are automatically generated when the export function is run.. External models can be run on any system such as spreadsheets, optimization modeling systems (e.g. GAMS, AMPL, AIMMS, etc.), or custom applications built using programming languages (Fortran, C++, MATLAB, etc.). Extensions or ‘add-ins’ allow custom export functions (e.g. model-specific input data export functions) or to ‘host’ external models as modular add-ins. Add-ins enable tighter coupling between the platform and model if desired. Decision Support System features like special interfaces for managing model use or processing results can be developed as addins. This paper does not describe the use of add-ins but focuses on the loose coupling link which uses of export/import functions. 3.2 Projects, Networks, Scenarios, Object Types and Objects HydroPlatform’s organizational structure is based on Projects, Networks, Scenarios, Object Types and Objects. Upper-case letters denote words with specific meaning in HydroPlatform. A Project has characteristics such as modeled time horizon, time-step, preferred units, geographic projection, and set of Object Types. A Network is a collection of node Objects connected in a certain way by link Objects (topology). A Project may have more than one Network (e.g. hundreds). Scenarios share a Network but have different data values, i.e. one or more parameters, tables or time-series for one or more node or link Objects are unique. A Network may have any number of Scenarios. When HydroPlatform exports data to an external model, it exports the data content of a particular Scenario. Each Project has a group of Object Types available for use in that project; each Network is built of individual Objects. In object-oriented programming parlance Object Types are classes whereas Objects are instances of Object Type classes. For example in HydroPlatform ‘Reservoir’ is an Object Type, whereas ‘Reservoir A’ and ‘Reservoir b’ are Objects, i.e. ‘instances’ of the ‘Reservoir’ Object Type (class). The instances have the same data structure (data fields) but will differ from each other in their location in the network and possibly the data values in one or more fields. Object Types exist in two main categories (‘superclasses’): node (a point) or link (connection between 2 nodes). Custom definition of Object Types with an easy user-interface is HydroPlatform’s most essential contribution to modeling networks. Custom Object Types allows the user to define and HydroPlatform to store and manage data for any network model. Custom Object Types can include any number or grouping of data fields. Data fields can be either parameters, tables, time-series or node references. Figure 2 shows a simple network implemented in HydroPlatform. The network linking several Objects is drawn over a satellite image. Eight Node Object Types exist in this Project ( Figure 2). When new Object Types are deleted or created, they (dis)appear from the Object Type toolbar. Harou et al. / An open-source model platform for water management Custom Object Types Figure 2: HydroPlatform screenshot of a simple network including bi-directional links. The toolbar shows this Project has 7 custom Object Types in addition to the default node and link. 3.3 Software implementation HydroPlatform links an open-source interactive geographic data viewer called Thuban (extensible, multi-platform, multi-lingual) with an open-source database. It is programmed entirely in Python (an object-oriented, multi-platform, open-source scripting language). Data storage is implemented using proven open-source components. It uses SQLAlchemy, the Python SQL toolkit and Object Relational Mapper, and thus supports most database systems such as MySQL, PostgreSQL, SQLlite, …). HydroPlatform uses a set of powerful Python libraries such as Chaco, shapely, networkx, Enthought Traits, etc. for data management to ensure state-of-the-art data manipulation, organization and visualization. HydroPlatform is free and open-source available under a General Public License (GPL). Add-ins must also be GPL but external models can use any licensing scheme. 3.4 Working with a modeling system Here we describe how HydroPlatform exports model data to GAMS, one of several modeling systems. GAMS consists of a language compiler and numerous open-source and commercial optimization algorithms (‘solvers’). The user enters model equations defined over specified indices and data, then GAMS interprets the code and converts the model to matrix-form for solution by a user-selected solver. A GAMS model consists of 4 ‘classes’. A class in object oriented parlance is an abstract definition of a group of things with common characteristics. For example, the Object Types described in HydroPlatform (e.g. Desal nodes) could be considered a class. The GAMS classes are: SETS (the indices over which the model is defined, e.g. for a daily model there will be a set t of all days or a network will have a set of all nodes i), SCALARS (fixed constants), PARAMATERS (vector of fixed constants for a set), TABLES (matrices of fixed constants for multiple sets), VARIABLES (decision and state variables,that are unknown and whose values are determined by the solver), and EQUATIONS (mathematical expressions using sets, data and variables). These classes can have further nested subtypes. For example, the SET object type could include the index t for time and the index i for nodes, both of which are themselves sets. Harou et al. / An open-source model platform for water management These classes can have further subclasses, e.g. desal(i) denotes the subset of nodes i that are desalination nodes. Once subtypes are defined, the instances of subtypes needed for the model can be declared. For example, instances of sub-type t could be the years 1990 to 2000, or for the desal(i) subclass, the instances of subtype i could be desalination plants A, B and C. In a similar way, the SCALAR, PARAMETER, and TABLE object types can have instances declared for each data item the model requires. For example if an instance of node subclass junction(i) named ‘Junction A’ requires an inflow time-series, then Junction A will be associated with a table instance that accepts time-series data. VARIABLE class instances are variable declarations. Variables are defined using previously defined sets. For example if the model has a storage variable ‘Stor’ that represents the storage at node i during time period t, it could be defined using the i and t sets as indices, e.g. Stor(i,t):. The object-oriented structure of GAMS easily accommodates water resource network models, for example flow along a network link is defined as Q(i,j,t), the flow from node i to node j during time-step t. A network connectivity matrix summarizes the network topology (i.e. which nodes connect to each other) for use in model equations. HydroPlatform organizes and exports all relevant data in text files or Excel sheets readable by GAMS. The HydroPlatform export function turns all (i) node and link Objects, (ii) the data fields associated with each object, (iii) data for each instance of the objects, and (iv) the network connectivity matrix into forms available for use by GAMS: namely (i) SETS, (ii) PARAMETERS and TABLES indexed by those SETS, (iii) data values for each indexed element in a PARAMETER and TABLE, and (iv) a network connectivity matrix (i x i) who’s columns and rows are the SET of all model network nodes. A connectivity matrix value of 1 indicates the associated nodes are linked; 0 indicates other-wise. In summary, HydroPlatform allows users to build a database customized for the data needs of any network model. The custom HydroPlatform database content is then exported to GAMS using generic export functions where it is read-in, linked to a particular model, and run. The HydroPlatform GAMS export function is a good example of how HydroPlatform works with modeling systems in particular and external programs more generally. 4. BENEFITS AND LIMITATIONS There are benefits and limitations of the separation of models and interface in model platforms. One benefit of loose coupling is that the modeling and data management software can use different licenses. For example a commercial model (proprietary license) vendor can use HydroPlatform (open-source license) to commercialize a new model or prototype new model formulations. Generally modularity facilitates software project management; model and data manager can evolve separately. Disadvantages include a potentially less smooth user-experience than with tightly integrated DSS. If export functions are used, HydroPlatform and the external model must be used separately. With add-ins, the model can run from within HydroPlatform, but this setup requires python programming skills. Previously implemented add-ins can serve as templates. For models that are already tightly integrated into an existing proprietary DSS, options for linking to HydroPlatform will be limited unless the model can be isolated. 5. PROJECT STRUCTURE, CURRENT STATUS AND FUTURE The project is an open-source, international collaboration among numerous researchers and practicioners. We are developing and using HydroPlatform as the single user interface and data management system for our varied and diverse set of existing water management models and models under development. Harou et al. / An open-source model platform for water management A working version is available for early adopters. The software download will be distributed through www.hydroplatform.org. The project website contains documentation and will eventually work like an app store, showcasing the open-source, freeware, or proprietary water management models that link to HydroPlatform. The project is managed with an online subversion (SVN) repository that stores the wiki, code and bug reports. The completed phase 1 focused on building network data sets and exporting them to external models using export functions or add-ins. Two generic export functions exist, exporting to text files or to a single spreadsheet; both formats can be read by GAMS. Several GAMS models currently under development have been linked to HydroPlatform including a water supply infrastructure capacity expansion model (South England, UK), a hydro-ecological allocation model for a bird refuge (Utah, USA), a hydro-ecological model investigating hydropower impacts under climate change (California, USA) and a hydroeconomic model studying water trading (California, USA). Two add-ins have been completed, generating input files for IRAS-2010, a generalized water resource simulation model (Loucks et al. 1995; Loucks 2002; Matrosov 2009), and the AquaPlan hydroeconomic optimization model (Tilmant et al. 2008). Phase 2 will focus on two tasks: 1) importing model results back into HydroPlatform for storage, analysis and display and 2) upgrading data structure to accommodate stochastic data (i.e. ensembles of inputs and outputs including parameters, tables or time-series, performance measures, or resulting time-series). Phase 2 will also introduce Scenarios; the current proto-type uses only Projects and Networks. 6. CONCLUSIONS A model platform allows users to input, visualize and manage network model input data and results. Users can link their model to a generic user-interface and data management platform and easily apply a model to real systems. This setup contrasts with other prevalent water management software setups such as DSS, modeling systems, or stand-alone programs that typically either provide limited user-interface capabilities or have sophisticated user interfaces but force use of the built-in model. We have developed a generic model platform called HydroPlatform as an open-source, international collaborative effort. HydroPlatform can be used with any network-based model as formulating and solving models is done external to and independent of HydroPlatform. HydroPlatform uses standard data export functions or customized add-ins to send data entered in the platform to the external model. By helping to input, visualize, and manage network model data, HydroPlatform allows model developers to focus their time and effort on model rather than software development. References Andreu, J., Capilla, J., and Sanchis, E. (1996). "AQUATOOL, a generalized decisionsupport system for water-resources planning and operational management." Journal of Hydrology, 177(3-4), 269-291. Argent, R. M. (2004). "An overview of model integration for environmental application components, frameworks and semantics." Environmental Modelling & Software, 19(3), 219-234. Argent, R. M., Voinov, A., Maxwell, T., Cuddy, S. M., Rahman, J. M., Seaton, S., Vertessy, R. A., and Braddock, R. D. (2006). "Comparing modelling frameworks - A workshop approach." Environmental Modelling & Software, 21(7), 895-910. Cetinkaya, C. P., Fistikoglu, O., Fedra, K., and Harmancioglu, N. B. (2008). "Optimization methods applied for sustainable management of water-scarce basins." Journal of Hydroinformatics, 10, 69-95. Draper, A. J., Munevar, A., Arora, S. K., Reyes, E., Parker, N. L., Chung, F. I., and Peterson, L. E. (2004). "CalSim: Generalized model for reservoir system analysis." Journal of Water Resources Planning and Management, 130(6), 480-489. Harou et al. / An open-source model platform for water management Fowler, M. R., Cook, S. C., and Lumbers, J. P. (1999). "Practical experience in the successful implementation of optimisation systems for water supply management." Computing and Cotrol for the Water Industry, Tynemarch Ltd., Exeter, UK, 1999. Gregersen, J. B., Gijsbers, P. J. A., and Westen, S. J. P. (2007). "OpenMI: Open modelling interface." Journal of Hydroinformatics, 9(3), 175-191. Jha, M. K., and Das Gupta, A. (2003). "Application of Mike Basin for water management strategies in a watershed." Water International, 28(1), 27-35. Kuczera, G. (1992). "Water-Supply Headworks Simulation Using Network LinearProgramming." Advances in Engineering Software, 14(1), 55-60. Labadie, J. W., and Baldo, M. L. (2000). "MODSIM: Decision Support System for River Basin Management: Documentation and User Manual." Dept. of Civil Engrg., Colo.State Univ., Ft. Collins, Colo. Letcher, R. A., Croke, B. F. W., and Jakeman, A. J. (2007). "Integrated assessment modelling for water resource allocation and management: A generalised conceptual framework." Environmental Modelling & Software, 22(5), 733-742. Loucks, D. P. (2002). "IRAS – Interactive River-Aquifer Simulation for Policy Impact Prediction." Regional Water System Management: water Conservation, Water Supply and System Integration, Cabrera, Cobacho, and Lund, eds., A.A. Balkema Pub., Lisse. Loucks, D. P., Taylor, M. R., and French, P. N. (1995). "IRAS - Interactive river-aquifer simulation model, program description and operating manual." Cornell University, Ithaca, NY. Maass, A., M. Hufschmidt, R. Dorfman, H. Thomas, S. Marglin, and Fair, G. (1962). Design of Water-Resources Systems, Harvard University Press, Cambridge, Massachusetts. Matrosov, E. (2009). "Interactive River-Aquifer Simulation release 2010 (IRAS-2010) Application to the Thames Water Resource System," TU München, Munich, Germany. Oxford Scientific Software. (2008). "A Guide to Aquator, 1. Application, Version 3.0." Oxford Scientific Software, Oxford, UK. Perera, B. J. C., James, B., and Kularathna, M. D. U. (2005). "Computer software tool REALM for sustainable water allocation and management." Journal of Environmental Management, 77(4), 291-300. Randall, D., Cleland, L., Kuehne, C. S., Link, G. W., and Sheer, D. P. (1997). "Water supply planning simulation model wing mixed-integer linear programming ''engine''." Journal of Water Resources Planning and Management-Asce, 123(2), 116-124. Rizzoli, A. E., and Argent, R. M. (2006). "Software and Software Systems: Platforms and Issues for IWRM Problems." Sustainable management of water resources: an integrated approach, C. Giupponi, D. Karssenberg, A. Jakeman, and M. P. Hare, eds., Edward Elgar. Sechi, G. M., and Sulis, A. (2009). "Water System Management through a Mixed Optimization-Simulation Approach." Journal of Water Resources Planning and Management-Asce, 135(3), 160-170. Soncini-Sessa, R., Villa, L., Weber, E., and Rizzoli, A. E. (1999). "TwoLe: a software tool for planning and management of water reservoir networks." Hydrological Sciences Journal-Journal Des Sciences Hydrologiques, 44(4), 619-631. Tilmant, A., Pinte, D., and Goor, Q. (2008). "Assessing marginal water values in multipurpose multireservoir systems via stochastic programming." Water Resources Research, 44, W12431, doi:10.1029/2008WR007024. USACE. (2007). "HEC-ResSim Reservoir System Simulation User’s Manual Version 3.0." USACE. WL Deflt Hydraulics. (2004). "RIBASIM, Version 6.32." WL Deflt Hydraulics, Delft, Holland. Wurbs, R. A. (2005). "Modeling river/reservoir system management, water allocation, and supply reliability." Journal of Hydrology, 300(1-4), 100-113. Yates, D., Sieber, J., Purkey, D., and Huber-Lee, A. (2005). "WEAP21 - A demand-, priority-, and preference-driven water planning model Part 1: Model characteristics." Water International, 30(4), 487-500. Zagona, E., Fulp, T. J., Shane, R., Magee, T., and Goranflo, M. (2001). "RIVERWARE: A Generalized Tool for Complex Reservoir System Modeling." Journal of the American Water Resources Association, 37(4), 913-929.