2.1. Decision Table Structure
Decision tables, like flowcharts and if-then-else and switch-case statements, associate conditions with actions to perform, but can do so in a more compact and intuitive way. They are divided into four quadrants: I. Conditions, II. Condition Alternatives, III. Action Entries or Outcomes, and IV. Actions (Table 1
Quadrant I: Conditions. For application of the decision table to SWAT+ management, quadrant I contains condition variables and condition limits. A listing of current SWAT+ variables coded for use in the decision table is given in Table 2
. The variables relate to time of year, soil and plant status, reservoir volumes, and flow in channels. In addition to the conditional variable, the model must also know its associated watershed object. For example, if reservoir volume is used as the conditional variable, the reservoir number in the current simulation must be defined. The model would read the conditional variable as “vol res 1”. This example uses the volume of reservoir 1. To develop more generic rules that can be used by multiple reservoirs, res 0 is used to designate the current reservoir being simulated. For reservoirs in series, the outflow from res 1 could be conditioned on volumes of res 2, 3, etc. The condition limits are defined using a limit variable, limit operator, and limit constant. If reservoir volume is again used as the conditional variable, the principle and emergency volumes may be used as limit variables for setting condition limits for reservoir volume. An example input would be “evol × 0.8”, thus setting the limits when determining alternatives. For soil water, there are currently three limit variables, wilting point (wp), field capacity (fc), and total porosity (ul). In the example, the user could input “fc × 0.7”. The alternatives are compared to this limit threshold. Other variables do not have operators and limit variables. For example, using month as the conditional variable, a potential limit could be “5-null” and the alternatives are based on comparing the current month to 5.
Quadrant II: Alternatives. There are four possible alternative operators: >, <, =, and -. The alternative is the final piece to construct the “if” statement needed to implement the associated rule.
|“soil_water hru 1 fc × 0.7”||>|
The model will determine if the soil water in hru (hydrologic response unit) 1 is greater than 0.7 × fc. The “-” symbol is used if the condition is not relevant for a specific alternative.
Quadrant III: Action Entries. Action entries or outcomes are either yes or no and specify whether or not an action is triggered. Each condition within an alternative must be true. If all conditions specified by an alternative are true, and the outcome is “y”, then the associated action will be performed. The only options for action entries are “y” and “n”.
Quadrant IV: Actions. The action type and associated information needed to perform the action are input in quadrant IV. The actions currently coded in SWAT+ are listed in Table 3
. Most of the actions are related to land management, including planting, harvesting, tillage, fertilizer applications, and drainage water management. There are also currently actions for reservoir release and land use change. For some actions, there are multiple options to execute the action. For the reservoir release action, the user can input a release rate, a weir equation, or drawdown days. The decision table contains a constant and file pointer for all the management actions. The file pointer corresponds to the application type in the associated data file. The plant action points to plant growth parameters, the harvest operation points to data for the method of harvest, and the tillage action points to the tillage implement. Fertilizer and irrigation use the constant to specify the amount of fertilizer or water applied and the file pointer corresponds to the data needed for the application method (e.g., sprinkler irrigation or broadcast fertilizer). For the land-use change actions, the file pointer corresponds to the updated land use.
2.2. Integration of Decision Table Code with SWAT+
SWAT+ is written in FORTRAN using F90 constructs and currently compiled using Visual Studio 2015. The decision table code consists of three subroutines and is relatively simple and robust.
Dtable_read Subroutine. This subroutine reads from an input file containing all decision tables. The decision table consists of three objects (types in FORTRAN): (1) conditional variables; (2) action variables; and (3) decision table variables. The decision table variables include the conditional and action objects and also the alternative and outcome (action entries) variables. All variables needed for each quadrant are included in the decision table variables and are defined in Table 4
Conditions Subroutine. This subroutine loops through all conditions and checks all alternatives for each condition. Since all conditions must be met for an alternative to be positive, we start with the alternative being positive and set it to negative if any condition is not met. Inside the conditions loop, a case statement is used to identify the appropriate conditional variable. Then, appropriate SWAT+ variables are used relative to each conditional variable.
Actions Subroutine. This subroutine loops through all actions and if one (or more) of the alternatives is “y” the action will be performed. SWAT+ variables are updated for each action using the constant and file pointer. When the variables are set for the specified action, the corresponding SWAT+ subroutine is called as shown in Table 3