RiverWare Policy Language (RPL)
RPL Language Structure
One of the main goals of the RiverWare modeling system is to provide a way to express operating policy separate from the physical process model. Many older basin management models were dedicated software—they integrated complex operating policies into the code, intermingled with the code for the physical processes. This allowed ultimate flexibility and detail for the operations. Typically, general modeling tools allow only the specification of simple policies like guide curves.
RiverWare allows complex policies to be expressed in a general modeling framework. That is achieved by providing a programming language within RiverWare with which the modeler can express policy—this is the RiverWare Policy Language (RPL). The policy statements are interpreted at runtime, and the policies interact with the simulation to drive the solution.
RPL Requirements
The requirements for the RiverWare Policy Language (RPL) are as follows:
• Must be rich enough to express even the most complex operating policies,
• Must be an interpreted language, and
• Must be able to interact with RiverWare, primarily in being able to read and set slots in the model.
In the prototype development, Tcl (Tool Command Language) was used as the rule language. Tcl is a complete interpreted programming language that meets the requirements above (an interface was developed to allow Tcl to access model values, timesteps, etc.). Through observation of the use of that language, requirements for a more user-friendly language were developed. These include the following:
• Language must be easy to read, so that interested parties can look at the logic and understand the policy relatively easily,
• Language must be relatively easy to formulate, so the modeler does not have to learn a new complex programming language,
• The modeler does not have to debug spelling and similar syntax issues, i.e., that a syntax-directed editor is provided to ensure creation of valid expressions, and
• Performance of the interpretation and application of the language must be fast enough for acceptable run times.
Based on these needs, RPL was then developed. One of the primary design decisions for RPL was that it be, to a large extent, a functional programming language. This section describes the main characteristics of functional languages, how they differ from imperative languages like FORTRAN or C, and takes you through some exercises in formulating logic using this approach.