The RiverWare Policy Language language is composed of seven data types, such as numeric values, datetimes, text strings, and slots. The data types are the building blocks of RPL. They are the only types of data which expressions and functions are allowed to evaluate to and are the structure controlling what information can be entered in different parts of the RPL. The structure editor uses expression data types to enforce block and function validity as they are constructed. Attempting to enter an expression of one type where another type is expected, immediately results in an error.

Unspecified expressions are pieces of the RPL which have not yet been defined when creating a RPL set. Unspecified expressions are shown in the Rule and Function Editor as the name of the expression type, colored blue (by default), and surrounded by small angle braces (< expr >). An unspecified expression may be filled in directly with the appropriate data, or it may be replaced with a function which will evaluate to the appropriate data type. In most cases, unspecified expressions can be completed by using Palette buttons. This is the recommended approach. The complexity and syntactical requirements of some expression types, particularly object and slot, behooves you to use the built-in tools for formatting a correct expression.

Table 3.1 lists the expression data types. More complete descriptions follow.

The numeric expression data type is comprised of a number and its units. Numeric expressions may be typed directly into a block or function by double-clicking the unspecified <numeric expr> and typing a value and units into the textfield. As in Simulation, numbers are stored and evaluated internally with twelve significant figures of precision. When a numeric expression is typed directly into a block or function, the default display precision is two digits beyond the decimal point. The precision of displayed numbers can be modified in two ways:

Units for numeric expressions must follow the value, separated by a single space. If no units are specified, the value is considered to be of a dimensionless unit type with units of NONE. When a numeric expression is typed directly into a block or function, the units may be entered without quotes if the unit name contains no special punctuation characters such as hyphens or forward slashes. When quotes are omitted, they will be filled in automatically.

The boolean expression data type can be either true or false. The expressions may be entered directly in the editor by double-clicking the unspecified <boolean expr>, and typing into the textfield. The editor accepts lowercase, uppercase and capitalized spellings, but automatically converts these entries into an uppercase format.

The datetime expression type is used to represent moments in time. Datetimes may be entered directly by double-clicking an unspecified <datetime expr>, and typing into the resulting textfield. All datetime expressions begin with an @ symbol and are followed by the datetime specification in double quotes (“ and ”).

Datetime expressions may be specified symbolically. Symbolic representations of points in time are common in everyday language, but rare in programming languages. Symbolic representations include such datetimes as “next week,” “20th day of month,” and “April, next year.” These types of datetime specifications are allowed in the RiverWare Policy Language. They facilitate the writing of RPL expressions by using date conventions to which you are more accustomed. They are evaluated by the RPL language, in the context in which they are used, to determine an exact moment in time. Slot access is still performed internally with exact datetime specification in number of seconds since New Year’s, 1700 C.E.

Datetime expressions fall into two categories and each may be used in the following instances or contexts:

Fully specified datetimes are those which can be mapped directly to an instant in time, such as @“t” or @“June 4, 1986.” Fully specified datetimes are required for all slot lookups, slot assignments and predefined function arguments.

Partially specified datetimes are those which cannot be mapped to a specific instant in time, such as @“Current Month” or @“Tuesday.” Partially specified datetimes are used in boolean comparisons. For example, a check for whether the current timestep is a Tuesday could be done with a fully specified datetime, @“t”, and a partially specified datetime, @“Tuesday”:

IF ( @“t” == @“Tuesday” ) THEN ...

If you have a partially specified datetime that you want to convert into a fully specified datetime, use the CompletePartialDate predefined function; see CompletePartialDate for details.

There are four general datetime formats. Within each format, there are specific components which the user can specify. Table 3.2 lists the four formats and components, which you can specify separately.

Thus, for the first format, you can specify almost any component. For the second format, you can only specify the timestep and nothing else. So you cannot specify @“Timestep 12, Year 1997”; an error would return.

As you specify components, you only specify as much as is needed to uniquely reference the date. So, if in a boolean comparison you are comparing a date to see it is in 1997, you would enter (date == @“Year 1997”). But, if you want to compare if it is March of 1997, you enter @“March 1997” but do not include the word “Year” before 1997.

The list of symbolic specifiers include the following: Min, Max, Start, Finish, Previous, Current, and Next. Any of these specifiers can be used in the examples above.

If no time (hours, minutes, seconds) is specified at all, it defaults to 24:00:00. If a time is specified, it may appear either before or after the specification of the Month, Day, and Year. Times may be specified with or without seconds, if they are not specified then they default to 0 (e.g., both 17:23 and 17:23:00 refer to the same time of day).

Mixing of symbolic datetime elements results in an almost infinite number of datetime specifications. Table 3.3 lists examples for some of these acceptable fully specified expressions and their interpretations. The symbolic datetime elements shown can be combined into other forms not explicitly enumerated.

Table 3.4 lists partially specified datetime expressions.

When performing addition or subtraction math on datetime values (for example, adding three timesteps to the current timestep), there are three approaches that can be used.

Within a datetime literal, it is possible to add or subtract integral values from a base time. Thus, possible specifications for a datetime value three timesteps beyond the current timestep include the following:

The list of time units that are available in this context are (case insensitive):

This approach to datetime math is probably the easiest to read, but is of course only useful when literal specification is possible. For example, when one would like to increment a base datetime by a number of timesteps which is itself the result of expression evaluation, then one of the alternative approaches to datetime math is required.

A numeric value can be added to or subtracted from a datetime value. Continuing the example from above, the following expressions would evaluate to three timesteps beyond the current timestep in a model with a 1 Day timestep:

The list of time units that are available in this context are (case sensitive):

Here are the math operations supported for datetime values:

In such expressions, the numeric value must have units of type Time.

The following operations are not supported as the result is undefined:

The OffsetDate predefined function allows you to specify the increment and length of timestep to use for the addition or subtraction; see OffsetDate for details. Thus, you could enter the following:

This function is most useful for variable length timesteps (1 Month, 1 Year).

The string expression data type is any text surrounded by double quotes (“ and”). An unspecified string expression may be entered directly in expression by double-clicking the <string expr>, and typing in the string surrounded by double quotes. String expressions may contain any combination of letters, numbers and punctuation except double quotes.

The object expression data type is used to reference objects in the currently loaded model. An unspecified object expression may be completed by double-clicking the <object expr> and typing in the object name in double quotes and preceded by a percent symbol. When an object expression is typed directly into a block or function, the object name may be entered without quotes if the object name contains no spaces or special punctuation characters. When quotes are omitted, they will be filled in automatically.

It is highly recommended that you do not type object names directly into blocks and functions. The potential for error is great. An extra space or an incorrectly capitalized letter will invalidate the object expression. There is, however, a convenient and foolproof way to enter this data. Most commonly, an unspecified object expression is completed by using the Object Selector in the RPL Palette or by typing in a variable name whose type is an object expression.

Table 3.5 lists examples of object expressions entered directly into the Editor.

In contexts where an object expression is used as part of a complete slot specification, the object expression must be followed by a <string expression> indicating the slot.

The slot expression data type is used to specify a specific slot on an object of the currently-loaded model. The expression must include the object on which the slot resides as well as the slot name itself. An unspecified slot expression may be completed by double-clicking the <slot expr>, typing in the object name, a dot, and the slot name, all in double quotes and preceded by a dollar symbol. When a slot expression is typed directly into a block or function, the object.slot name may be entered without quotes if neither of the names contain spaces or special punctuation characters. Regardless of how a slot expression is entered, the dollar sign and quotes are automatically omitted in the resulting display.

Again, it is highly recommended that you do not type object.slot names directly into blocks and functions. The same convenient and foolproof way to enter object data is available to enter object.slot data. An unspecified slot expression may be completed by using the Slot Selector in the RPL Palette or by typing in a variable name whose type is a slot expression. The Slot Selector is an interface similar to the one used elsewhere in RiverWare, which formats a selected object and slot correctly and inserts it into the slot expression.

Table 3.6 lists examples of slot expressions entered directly into the editor.

List expressions are ordered collections of other expression data types. Lists can contain zero or more elements. Elements may be of different types, and lists may even contain other lists. An unspecified list expression may be completed by double-clicking the <list expr> and typing in a comma-separated list of other expressions enclosed in curly braces ({ and }). As with object and slot expressions, it is highly recommended that you do not type list expressions directly into the Editor. The Palette contains a multitude of functions for creating and retrieving information from lists. Examples of valid lists expressions, before the expression language expands their elements, include:

When an element of a list is read, its expression type must match the type expected by the reading function. If a function finds an object where a datetime is expected, the run is halted and an error is posted. The flexibility of lists is an advantage as long as the types of their contents are known, and they are used properly within blocks and functions. Because of their flexibility, however, the types of their elements cannot always be determined prior to a model run. For this reason, list type-checking is only done during execution, and errors in configuration are not caught until a run is in progress.