water

Article
Use of Decision Tables to Simulate Management
in SWAT+
Jeffrey G. Arnold 1, *, Katrin Bieger 2 , Michael J. White 1 ID
, Raghavan Srinivasan 3 ID
,
John A. Dunbar 4 and Peter M. Allen 4
1 Grassland Soil and Water Res. Lab, USDA-ARS, Temple, TX 76502, USA; [email protected]
2 Texas A&M AgriLife, Temple, TX 76502, USA; [email protected]
3 Texas A&M AgriLife, College Station, TX 77840, USA; [email protected]
4 1301 S University Parks Dr, Waco, TX 76706, USA; [email protected] (J.A.D.);
[email protected] (P.M.A.)
* Correspondence: [email protected]; Tel.: +1-254-770-6502




Received: 9 May 2018; Accepted: 28 May 2018; Published: 31 May 2018


Abstract: Decision tables have been used for many years in data processing and business applications
to simulate complex rule sets. Several computer languages have been developed based on rule
systems and they are easily programmed in several current languages. Land management and
river–reservoir models simulate complex land management operations and reservoir management
in highly regulated river systems. Decision tables are a precise yet compact way to model the rule
sets and corresponding actions found in these models. In this study, we discuss the suitability of
decision tables to simulate management in the river basin scale Soil and Water Assessment Tool
(SWAT+) model. Decision tables are developed to simulate automated irrigation and reservoir
releases. A simple auto irrigation application of decision tables was developed using plant water
stress as a condition for irrigating corn in Texas. Sensitivity of the water stress trigger and irrigation
application amounts were shown on soil moisture and corn yields. In addition, the Grapevine
Reservoir near Dallas, Texas was used to illustrate the use of decision tables to simulate reservoir
releases. The releases were conditioned on reservoir volumes and flood season. The release rules
as implemented by the decision table realistically simulated flood releases as evidenced by a daily
Nash–Sutcliffe Efficiency (NSE) of 0.52 and a percent bias of −1.1%. Using decision tables to simulate
management in land, river, and reservoir models was shown to have several advantages over
current approaches, including: (1) mature technology with considerable literature and applications;
(2) ability to accurately represent complex, real world decision-making; (3) code that is efficient,
modular, and easy to maintain; and (4) tables that are easy to maintain, support, and modify.

Keywords: rule-based system; reservoir management model; land management model;

SWAT (Soil and Water Assessment Tool)

1. Introduction

1.1. Land Management Models

Land management models are used to determine the impact of agricultural and urban
management on water quantity, quality, and agricultural productivity. Most agricultural land
management models have an operations file to schedule planting, harvest, tillage, irrigation,
and fertilizer and pesticide application by month and date. In some models, including EPIC
(Erosion Productivity Impact Calculator; [1]), APEX (Agricultural Policy Extender; [2,3]), and SWAT+
(Soil and Water Assessment Tool; [4,5]), land management operations can be “automatically” scheduled

Water 2018, 10, 713; doi:10.3390/w10060713 www.mdpi.com/journal/water

Water 2018, 10, 713 2 of 10

based on accumulated heat units. However, current algorithms in these models do not use modern
rule-based coding and do not use structured decision tables to input the conditions and action.
For example, EPIC, APEX, and SWAT+ currently have automated irrigation scheduling that is based
solely on a plant stress or water deficit trigger. Decision tables will allow us to easily add complex
conditions for scheduling the irrigation application (e.g., crop type, phenological stage, or water
availability in reservoirs) which is not possible in the current models.

1.2. River and Reservoir Management Models

River–reservoir models are designed to simulate the distribution of water within a highly
regulated river system with multiple objectives. Hydrologists use river–reservoir models to understand
the impact of operational changes to the system that result in changes in water deliveries, reservoir
storage, in-stream flows, and power production [6,7]. Operational changes include water transfers
and changes in reservoir operation rules. Some of the more commonly used models for river basin
management include MODSIM [8], RiverWare [9], MIKEBASIN [10], RIBASIM [11], and WEAP [12].
All of these models have been successfully applied around the world and have proven to be
useful in water resources planning. However, each lacks an effective customization capability,
which limits their applicability to unique river basin conditions and complex rules and policy [8].
RiverWare is customized using the RiverWare Policy Language (RPL) for developing operational
policy. A rule editor allows users to enter expressions in RPL and relationships between river basin
objects. RPL is computationally inefficient and unable to adequately simulate conjunctive use of
surface and groundwater resources [8]. MODSIM contains a Custom Code Editor that can interface
with MODSIM and access all public variables and object classes. This allows for specific operating
rules to be customized for specific river basins. As with RiverWare, the language has to be easily
understandable and computational efficiency is sacrificed.

1.3. Decision Table Theory

Decision tables are a precise yet compact way to model complex rule sets and their corresponding
actions. Decision tables were originally used in business to represent conditional logic by creating
a list of tasks depicting business-level rules. They are widely used in data processing applications and
have an extensively developed literature [13]. Several computer languages have been developed based
on rule systems that use decision trees that can be derived from decision tables. CLIPS (C Language
Integrated Production System) was developed at NASA in the 1980s as a tool to define expert
systems [14,15]. CLIPS is a non-procedural declarative and rule-based programming language.
FORTAB is a decision table language designed to be embedded in FORTRAN, which was developed
by the RAND Corporation in the 1980s [16]. Many of the capabilities of CLIPS and FORTAB are now
easily programmable in the current C and FORTAN languages.

1.4. Objectives
The aim of this study is to develop a robust and efficient methodology to simulate land and
water management in ecohydrologic models. Specific objectives are: (1) to discuss the suitability of
decision tables to simulate management in the river basin scale Soil and Water Assessment Tool [4,17]
model; and (2) to describe an enhanced SWAT+ framework which incorporates decision tables for
management and reservoir operations.

2. Materials and Methods

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
Water 2018, 10, 713 3 of 10

four quadrants: I. Conditions, II. Condition Alternatives, III. Action Entries or Outcomes, and IV.
Actions (Table 1).
Water 2018, 10, x FOR PEER REVIEW 3 of 10
Water 2018, 10, x FOR PEER REVIEW 3 of 10
Water 2018, 10, x FOR PEER REVIEW
Table 1. The four quadrants of a decision table. 3 of 10
Table 1. The four quadrants of a decision table.
Table 1. The four quadrants of a decision table.
Table 1. The four quadrants of a decision table.
I.I.Conditions
Conditions II.Condition
II. ConditionAlternatives
Alternatives
I. Conditions II. Condition Alternatives
I. Conditions II. Condition Alternatives

IV. Actions III. Action Entries

IV. Actions III. Action Entries
Entries
IV.Actions
IV. Actions III.Action
III. Action Entries
Quadrant I: Conditions. For application of the decision table to SWAT+ management, quadrant
Quadrant I: Conditions. For application of the decision table to SWAT+ management, quadrant
Quadrant
I contains conditionI: Conditions.
variablesFor and application
condition of the decision
limits. A listing table
of to to SWAT+
current SWAT+ management,
variables coded quadrant for
Quadrant
I contains I: Conditions.
condition variablesFor and application
conditionof the decision
limits. A listing table
of currentSWAT+ SWAT+ management,
variables quadrant
coded for
Iuse
contains condition
in the decision variables variables
table is given and condition limits. A listing of current SWAT+ variables coded for
Iuse
contains
in the condition
decision table is given andinin Table 2.limits.
condition
Table 2. The
The variables
A listing
variables
relate
relate
to timeSWAT+
of current
to time of
of year,variables
soil and plant
year, soil and plant coded status,
for
status,
use in the volumes,
reservoir decision table and is given
flow in in Table In
channels. 2. The variables
addition to the relate to time variable,
conditional of year, soil the and
model plant
muststatus,
also
use in the decision table is given in Table 2. The variables relate
reservoir volumes, and flow in channels. In addition to the conditional variable, the model must also to time of year, soil and plant status,
reservoir volumes,
know its associated and flow
watershed in channels.
object. In In addition
Foraddition to the
example, if reservoir conditional volume variable,
is used the model
as the must must also
conditional
reservoir
know itsvolumes,associated and flow in channels.
watershed object. For example,toifthe conditional
reservoir volume variable,
is used theas model
the conditional also
know
variable, its the
associated
reservoir watershed
number inobject.
the For example,
current simulation if reservoir
must be volume is
defined. The used
model as thewouldconditional
read the
know its associated watershed object. For example, if reservoir
variable, the reservoir number in the current simulation must be defined. The model would read the volume is used as the conditional
variable,
conditional the variable
reservoirasnumber “vol in resin 1”.
theThis
current simulation
example uses the must be defined.
volume The model
of reservoir Towould
1. would developreadmore
the
variable,
conditional the variable
reservoiras number
“vol res the This
1”. current simulation
example uses must
the volume be defined. The model
of reservoir 1. To developreadmore
the
conditional
generic rules variable as
that can “vol “vol
be used res 1”. This
by multiple example
reservoirs, uses the
res volume volume of reservoir
0 is usedoftoreservoir
designate the 1. To develop
current more
reservoir
conditional
generic rules variable
that canasbe used resby 1”. This example
multiple reservoirs, usesres the 0 is used to designate 1. theTo develop
current more
reservoir
generic
being rules thatFor
simulated. canreservoirs
be used by in multiple
series, the reservoirs,
outflow res res
from 0 is1used
could tobedesignate
conditioned the on current reservoir
volumes of res
generic rules that can be used by multiple reservoirs, res 0 is
being simulated. For reservoirs in series, the outflow from res 1 could be conditioned on volumes of resused to designate the current reservoir
being
2, 3, simulated.
etc. The For reservoirs
condition limits in series,
are definedtheusing
outflow a fromvariable,
limit res 1 could beoperator,
limit conditioned and on volumes
limit of res
constant. If
being simulated.
2, 3, etc. The condition For reservoirs
limits are in defined
series, the outflow
using a limitfrom res 1 could
variable, limit be conditioned
operator, and limit on volumes
constant.ofIf
2, 3, etc.
reservoir The
volume condition limits
is againlimits are
used are defined using
as the conditional a limit variable, limit operator, and limit constant. If
res 2, 3, etc.
reservoir The condition
volume is again used as thedefined
conditional avariable,
usingvariable, the principle
limit variable,
the principle limitand and emergency
operator,
emergencyand limit volumes
constant.
volumes
may
may
reservoir
be used volume
as limit is again for
variables used as thecondition
setting conditional variable,
limits for the principle
reservoir volume. andAn emergency
example volumes
input would maybe
Ifbereservoir
used as volume
limit variablesis againfor used as the
setting conditional
condition limits variable, the principle
for reservoir volume. andAnemergency
example input volumeswould maybe
be used
“evol as
× 0.8”, limit thusvariables
setting the for setting condition
limits when determining limits for reservoir
alternatives. volume.
For An An example
soilexample
water, there input would
are currently be
be used× as
“evol limit
0.8”, thusvariables
settingfor thesetting
limits condition limits for reservoir
when determining alternatives. volume.For soil water, there input arewould be
currently
“evol
three ×limit0.8”,variables,
thus setting wilting the limits
point (wp),whenfield
determining
capacity alternatives.
(fc), and totalFor soil water,
porosity (ul). Intheretheare currently
example, the
“evol × 0.8”, thus setting the limits when determining alternatives.
three limit variables, wilting point (wp), field capacity (fc), and total porosity (ul). In the example, the For soil water, there are currently
three limit variables,
user could input “fc ×wilting 0.7”. The point (wp), field
alternatives arecapacity
compared (fc),toand thistotal
limitporosity
threshold. (ul). In the
Other example,
variables do the
not
three limit variables,
user could input “fc ×wilting 0.7”. The point (wp), field
alternatives capacity (fc),
are compared to thisandlimit
totalthreshold.
porosity Other(ul). In the example,
variables do not
user
havecould inputand
operators “fc ×limit
0.7”.variables.
The alternatives are compared
For example, using month to this as limitthethreshold.
conditional Other variables
variable, do not
a potential
the
have user could input
operators and “fc limit×variables.
0.7”. The alternatives
For example,are compared
using monthto asthis
the limit threshold.
conditional Otheravariables
variable, potential
have
limit operators
could be “5-null” and limit and variables. For example,
the alternatives are based using onmonth
comparing as thethe conditional
current month variable,to 5. a potential
do
limitnotcould
havebe operators
“5-null” and and the limit variables.are
alternatives For example,
based using month
on comparing as themonth
the current conditionalto 5. variable,
limit could be “5-null” and the alternatives are based on comparing the current month to 5.
a potential limit could be “5-null” and the alternatives are based on comparing the current month to 5.
Table 2. Conditional variables currently coded in the Soil and Water Assessment Tool (SWAT+) for
Table 2. Conditional variables currently coded in the Soil and Water Assessment Tool (SWAT+) for
Table
use in 2. theConditional variables currently coded in the Soil and Water Assessment Tool (SWAT+) for
decision tables.
Table
use in2.the Conditional variables currently coded in the Soil and Water Assessment Tool (SWAT+) for use
decision tables.
use in the decision tables.
in the decision
SWAT+ Variabletables.Object Type Description Units
SWAT+ Variable Object Type Description Units
SWAT+ Variable
soil_water Object Type
soil Description
total soil water in soil profile Units
mm
soil_water
SWAT+ Variable Object soilType total soil water in soil profile
Description Unitsmm
soil_water
w_stress soil
plant totalwater
soil water
stressinon soil profile
plant mm
0–1
w_stress plant water stress on plant 0–1
w_stress
month
soil_water plant
time
soil total soil water
current
water stress
month onof
in soil plant
year
profile 0–1
mm0–12
month time current month of year 0–12
month
w_stressjday time
planttime current
current
water month
julian
stress onday of of
plant year
year 0–12
0–10–366
jday
month time
time current
current julian
month day
of of
year year 0–366
0–12
jday
hu_plant time
plant heat units current julian
of plant day
since of year
start of growth 0–366
°C
hu_plant
jday plant
time heat units currentof plant since start of growth °C
hu_plant
hu_base0 plant
plant heat unitsheatfrom units of julian
January plant day
since
1 with of yeartemperature
start
base of growth of zero 0–366 ◦ C°C
°C
°C
hu_base0
hu_plant plant
plant heat unitsheatfromunits January
of plant 1 since
with basestart of temperature
growth of zero
hu_base0
year_rot plant
time heat units from January current 1year withofbase temperature of zero ◦ °C
rotation -
hu_base0
year_rot plant
time heat units from January current1year withof base temperature of zero
rotation C-
year_rot
year_cal
year_rot time
timetime current
current
current yearyear of
calendar rotation
of rotation year - -- -
year_cal time current calendar year
year_cal
year_seq
year_cal time
timetime sequential current
current calendar
yearcalendar
from start
year year
of simulation - --
year_seq time sequential year from start of simulation -
year_seq
year_seqprob time
time - sequential
sequential yearyear from
probability
from startstart of simulation
of simulation - 0–1 -
prob
prob -
- - probability
probability 0–1
0–1 0–1
prob
land_use management land use probability
and management -
land_use
land_use management
management landuse
land useand andmanagement
management - - --
land_use
ch_use management
management land land useuse and andcovermanagement
near channel
ch_use
ch_use management
management landuse
land useand andcovercovernear near channel
channel - -
ch_use
n_stress management
plant land use and cover
nitrogen stressnear channel
of plant -
0–1
n_stress
n_stress plant
plant nitrogen
nitrogenstress stressofofplantplant 0–10–1
n_stress
soil_n
soil_n plant
soilsoil total
total nitrogen
nitrate stress
in the of
soilplant
profile 0–1
kg/ha
soil_n soil totalnitrate
nitrateininthe thesoil
soilprofile
profile kg/ha
kg/ha
soil_n
soil_p
soil_p soil
soilsoil total
total totalphosphorus
labile
labile nitrate
phosphorus in the soilthe
in
in the profile
soil soil profile
profile kg/hakg/ha
kg/ha
soil_p soil total labile phosphorus in the soil profile kg/ha
soil_p
n_applied
n_applied managementsoil
management total
total labile phosphorus
nitrogen
nitrogen applied
applied tointhe
to the thecurrent
currentsoilplant
profile
plant kg/hakg/ha
kg/ha
n_applied
biomass management
plant total
above nitrogen
ground applied
biomass toofthe current plant kg/ha
n_applied
biomass management
plant total
above nitrogen
ground applied
biomass to current
the
of currentplant
current plant
plant kg/hakg/ha
kg/ha
biomass
cover plant
plant totalabove
ground ground
cover biomass
(live biomassof current
and plant
residue) kg/ha
kg/ha
biomass
cover plant
plant totalabove
ground groundcover biomass of current
(live biomass andplant
residue) kg/ha
kg/ha
cover
lai plant
plant total ground cover leaf area (liveindex
biomass and residue) kg/ha
-
cover
lai plant
plant total ground cover leaf(live
areabiomass
index and residue) kg/ha-
vol
lai reservoir
plant reservoirleaf water
area indexvolume ha-m-
lai
vol plant
reservoir leaf area
reservoir water indexvolume -
ha-m
vol reservoir reservoir water volume ha-m
vol
flow reservoir
channel reservoir
average daily water
flowvolume
in channel ha-m
m3/s
flow channel average daily flow in channel m3/s
flow
lat channel
object averagelatitude daily flow in channel
of object m3-/s
lat object latitude of object -
lat
long object
object latitude ofofobject
longitude object --
long object longitude of object -
long
elev object
object longitude
elevation of object --
elev object elevation of object -
elev
day_len object
time/object elevation
day lengthof object -
hours
day_len time/object day length hours
day_len
plant time/object
plant plant species; i.e., corn, day length deciduous forest, etc.
soybeans, hours-
plant plant plant species; i.e., corn, soybeans, deciduous forest, etc. -
plant
plant_type plant
plant plantplant
species;
type;i.e.,i.e.,corn,
legume,soybeans,
cool seasondeciduous forest,
annual, etc. etc. --
Water 2018, 10, 713 4 of 10

Table 2. Cont.

SWAT+ Variable Object Type Description Units

flow channel average daily flow in channel m3 /s
lat object latitude of object -
long object longitude of object -
elev object elevation of object -
day_len time/object day length hours
plant plant plant species; i.e., corn, soybeans, deciduous forest, etc. -
plant_type plant plant type; i.e., legume, cool season annual, etc. -

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.

Condition Alternative
“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.

Table 3. Actions currently coded in SWAT+ for use in the decision tables.

Action Type of Action Description SWAT+ Subroutine

reservoir
release release of water from reservoir: ha-m per day res_hydro
operation
plant management plant the crop pl_plant
harvest management harvest the crop pl_harv
tillage management perform tillage operation mgt_tillmix
fertilize management add nitrogen and/or phosphorous to the soil pl_fert
irrigate management irrigate the crop pl_irrigate
drainage management adjust the depth of subsurface drainage mgt_dwm
fire land use burn the current plants pl_burnop
lu_change land use change land use pcom_set_parms and update land use
chan_change land use change cover near the channel banks update channel parameters
Water 2018, 10, 713 5 of 10

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.
Water 2018, 10, x FOR PEER REVIEW 5 of 10

Table 4. Decision table variables as coded in the SWAT+ model.

Table 4. Decision table variables as coded in the SWAT+ model.

type conditions_var !Condtional Object Variables

character(len=16) :: var ! condition variable (i.e., volume, flow, sw, time, etc)
character(len=16) :: ob ! object variable (i.e., res, hru, canal, etc)
integer :: ob_num ! object number
character(len=16) :: lim_var ! limit variable (i.e., evol, pvol, fc, ul, etc)
character(len=2) :: lim_op ! limit operator (*,+,-)
real :: lim_const ! limit constant
end type conditions_var

type actions_var !Action Object Variables

character(len=16) :: typ ! type of action (i.e., reservoir release, irrigate, fertilize, etc)
character(len=16) :: ob ! object variable (i.e., res, hru, canal, etc)
integer :: ob_num ! object number
character(len=16) :: name ! name of action
character(len=16) :: option ! action option - specific to type of action (i.e., for reservoir, option to
! input rate, days of drawdown, weir equation pointer, etc)
real :: const ! constant used for rate, days, etc
character(len=16) :: file_pointer ! pointer for option (i.e., weir equation pointer)
end type actions_var

type decision_table !All Decision Table Object Variables

character (len=16) :: name ! name of the decision table
integer :: conds ! number of conditions
integer :: alts ! number of alternatives
integer :: acts ! number of actions
type (conditions_var), dimension(:), allocatable :: cond ! conditions
character(len=16), dimension(:,:), allocatable :: alt ! condition alternatives
type (actions_var), dimension(:), allocatable :: act ! actions
character(len=1), dimension(:,:), allocatable :: act_outcomes ! action outcomes ('y' to perform action; 'n' to not perform)
character(len=1), dimension(:), allocatable :: act_hit ! 'y' if all condition alternatives (rules) are met; 'n' if not
integer, dimension(:), allocatable :: act_typ ! pointer to action type (i.e., plant, fert type, tillage implement, release type,
etc)
integer, dimension(:), allocatable :: act_app ! pointer to operation (i.e., harvest.ops, chem_app.ops, weir shape, etc)
end type decision_table
type (decision_table), dimension(:), allocatable :: d_tbl

Conditions Subroutine. This subroutine loops through all conditions and checks all alternatives
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
foralternative
each condition.
being Since alland
positive conditions must be if
set it to negative met
anyfor an alternative
condition to beInside
is not met. positive, we start with
the conditions loop,the
alternative being positive
a case statement is usedand set it tothe
to identify negative if anyconditional
appropriate condition isvariable.
not met.Then,
Inside the conditions
appropriate SWAT+loop,
a case statement is used to identify the appropriate
variables are used relative to each conditional variable. conditional variable. Then, appropriate SWAT+
variables are used
Actions relative toThis
Subroutine. eachsubroutine
conditional variable.
loops through all actions and if one (or more) of the
Actions Subroutine.
alternatives Thiswill
is “y” the action subroutine loops
be performed. through
SWAT+ all actions
variables and if for
are updated oneeach
(or action
more)using
of the
alternatives is “y” the action will be performed. SWAT+ variables are updated for each
the constant and file pointer. When the variables are set for the specified action, the corresponding action using
theSWAT+
constant and file pointer.
subroutine When
is called as shown theinvariables
Table 3. are set for the specified action, the corresponding
SWAT+ subroutine is called as shown in Table 3.
3. Results

3.1. Application of Decision Tables

Two examples of decision tables are presented: (1) automated (auto) irrigation; and (2) reservoir
release. Both are kept relatively simple to illustrate the concept. However, additional conditions and
actions can easily be added to perform more complex rule sets.

3.1.1. Auto Irrigation

Water 2018, 10, 713 6 of 10

3. Results

3.1. Application of Decision Tables

Two examples of decision tables are presented: (1) automated (auto) irrigation; and (2) reservoir
release. Both are kept relatively simple to illustrate the concept. However, additional conditions and
actions can easily be added to perform more complex rule sets.

3.1.1. Auto Irrigation

The EPIC, APEX, and SWAT+ models [18] include provisions for automatic irrigation. In many
agricultural areas, it is known that certain fields are irrigated; however, the timing and amount of
irrigation of each application is not readily available. In this case, algorithms were developed to
automatically trigger an irrigation application based on water stress on the plant or by soil water
deficit. This simplest form of a decision table for irrigation is shown in Table 5.

Table 5. Decision table for automated irrigation based on plant stress.

Name Conditions Alternatives Actions

auto_irr 1 1 1
VAR OBJ OB_NUM LIM_VAR LIM_OP LIM_CONST ALT1
w_stress hru 0 null - 0.8 <
ACT_TYP NAME OBJ OB_NUM TYPE CONST OUTCOME
irrigate stress_0.8 hru 0 sprinkler 25 y

The name of the decision table is “auto_irr” and it contains one condition, one alternative, and one
action. The logic flows clockwise from quadrant I to IV. In quadrant I, the conditional variable
(w_stress) for hru 0 is defined (0 specifies the current hru and thus can be used for any hru in the
simulation). The conditional limit is a constant (0.8). A limit variable and operator are not needed in
this case. Next, we use the alternative in quadrant II and determine if w_stress <0.8. If the outcome
is yes (“y” in quadrant III), we move clockwise to the action in quadrant IV. The action is to irrigate
25 mm using a sprinkler application (found in the irrigation data file).
This is the simplest case and could be input and coded without the use of a decision table.
However, users typically need to add additional conditions, i.e., only irrigate a certain crop in the
rotation, only irrigate during a certain growth stage, or only irrigate when reservoirs or aquifers are at
a specified level. The decision table allows for the addition of conditions and actions in a simple and
robust structure.

3.1.2. Auto Irrigation Application

The SWAT+ model was parameterized to simulate continuous corn with the Houston Black soil
series from 2007 to 2016. Daily precipitation and maximum and minimum temperatures were input
from the USDA-Agricultural Research Service station in Temple, Texas. The auto irrigation decision
table as shown in Table 5 was used in this example, with a stress trigger of 0.8 and 25 mm applied
at each irrigation. Figure 1 shows the soil moisture, precipitation, and irrigation applications from
2014 to 2016. In 2014 and 2015, typical dry spring and summer periods triggered 11 and 10 irrigation
applications, respectively. In 2016, adequate rainfall during critical growing periods only triggered
one irrigation application. Irrigation increased corn yields by 3.1, 5.1, and 0.1 t/ha in 2014, 2015,
and 2016, respectively. To assess the sensitivity of the decision table parameters, we increased the
irrigation amount per application to 50 mm and lowered the plant stress trigger to 0.6 (Figure 1).
This resulted in fewer applications, more total water applied each year (25 mm), and slightly higher
corn yields (0.1 t/ha).
Water 2018, 10, 713 7 of 10

3.1.3. Reservoir Release

Large reservoirs are managed for multiple uses, including irrigation, power generation,
flood control, recreation, and municipal use [19]. Operating rules can be extremely complex and
in this example, we focus on flood control as the primary use. The first step in developing the decision
table is deciding on the number of actions or release rates. We chose to divide releases based on three
storage volumes: (1) principal volume; (2) emergency volume; and (3) 1.3 × principal. The release
rate is also a function of flood and non-flood season, resulting in five alternatives and five outcomes.
The five conditions are used to determine the storage class and the flood season class. Alternative 1
only checks one condition: if the volume is less than that of the principal volume. If the outcome is yes,
the corresponding action is to release at the “below_principal” rate of 2 m3 /s. Alternatives 2 and 3
are in the non-flood season with reservoir volumes between principal and 1.3 × principal volumes.
Alternative 4 is during flood season at any volume between principal and emergency, while Alternative
5Water
is for volumes
2018, above
10, x FOR emergency, regardless of the season.
PEER REVIEW 7 of 10

Soilmoisture,
Figure 1. Soil moisture,precipitation,
precipitation,
andand irrigation
irrigation of continuous
of continuous corncorn at Temple,
at Temple, TexasTexas using:
using: (1) a
(1) a plant
plant stressstress
triggertrigger of 0.8
of 0.8 and and application
application of 25 mm;of and
25 mm;
(2) a and
plant(2) a plant
stress stress
trigger trigger
of 0.6 of 0.6 and
and application
application
of 50 mm. of 50 mm.

3.1.4. Reservoir Release Application

Grapevine Reservoir is a 2674 hectare impoundment constructed on Denton Creek near Dallas,
Trinity River by the U.S. Army Corps of Engineers in 1952 to provide flood control,
a tributary of the Trinity
industrial water,
municipal and industrial water, and
and recreation.
recreation. The
The reservoir
reservoir contains 22,626 ha-m of water at
illustrate the
conservation elevation and was used to illustrate the reservoir
reservoir release
release rules.
rules. The decision table is
Table 6.
shown in Table 6.

Table 6. Decision table for reservoir release focusing on flood control.

Name Conditions Alternates Actions

res_release 5 5 5
VAR OBJ OB_NUM LIM_VAR LIM_OP LIM_CONST ALT1 ALT2 ALT3 ALT4 ALT5
vol res 0 pvol * 0.8 < > - > -
vol res 0 pvol * 1.3 - < > - -
vol res 0 evol * 1 - - < < >
month null 0 null - 5 - > > < -
month null 0 null - 9 - < < > -
ACT_TYP OBJ OB_NUM NAME TYPE CONST OUTCOME
release res 0 below_principal days 150. y n n n n
release res 0 non-flood<1.3 days 100. n y n n n
release res 0 non-flood>1.3 days 50. n n y n n
release res 0 flood days 25. n n n y n
release res 0 over_emergency days 5. n n n n y
Water 2018, 10, 713 8 of 10

Table 6. Decision table for reservoir release focusing on flood control.

Name Conditions Alternates Actions

res_release 5 5 5
VAR OBJ OB_NUM LIM_VAR LIM_OP LIM_CONST ALT1 ALT2 ALT3 ALT4 ALT5
vol res 0 pvol * 0.8 < > - > -
vol res 0 pvol * 1.3 - < > - -
vol res 0 evol * 1 - - < < >
month null 0 null - 5 - > > < -
month null 0 null - 9 - < < > -
ACT_TYP OBJ OB_NUM NAME TYPE CONST OUTCOME
release res 0 below_principal days 150. y n n n n
release res 0 non-flood<1.3 days 100. n y n n n
release res 0 non-flood>1.3 days 50. n n y n n
release res 0 flood days 25. n n n y n
release res 0 over_emergency days 5. n n n n y

The release rules as implemented by the decision table realistically simulated flood releases
as evidenced by a daily Nash–Sutcliffe Efficiency (NSE) of 0.52 and a percent bias of −1.1% [20].
Measured and simulated daily flows are shown in Figure 2. However, low flow releases were difficult
to simulate accurately due to uncertainty in specific local conditions and without understanding
of reservoir-specific release rules. We are developing simple generic rules that can be applied to
reservoirs across the U.S. for national policy simulations. With local knowledge of individual reservoir
release rules, the decision table could be modified to simulate very specific rules and test and optimize
alternative rule set parameters.
Water 2018, 10, x FOR PEER REVIEW 8 of 10
This is a relatively simple example focusing on flood control. More complex rules can easily be
addedflows.
to simulate reservoirs
Watershed managed
conditions in seriesirrigation
including by including conditions
demand, plant for other reservoirs
conditions, and soiland rivercan be
water
flows.added to the conditions
Watershed conditions.including
Also, weirirrigation
outflow as a function
demand, of storage
plant can replace
conditions, and soilthe constant
water outflow
can be
addedshown
to the in this example.
conditions. Also, weir outflow as a function of storage can replace the constant outflow
shown in this example.

2000
1800
Reservoir Outflow (ha-m)

Measured Outflow
1600
Simulated Outflow
1400
1200
1000
800
600
400
200
0
1987 1988 1989 1990
Time (daily)

Figure 2. Measured and simulated daily reservoir releases for Grapevine Reservoir near Dallas, Texas.
Figure 2. Measured and simulated daily reservoir releases for Grapevine Reservoir near Dallas, Texas.
3.2. Management Optimization
3.2.use
The Management Optimization
of a decision table as an external control on SWAT+ model runs also makes it possible to
find decision tables that optimize
The use of a decision tablecertain SWAT+
as an model
external outputs.
control Some choices
on SWAT+ of condition
model runs variable
also makes it possible
limitsto
and thedecision
find actions they trigger
tables will resultcertain
that optimize in more favorable
SWAT+ outcomes
model from
outputs. the SWAT+
Some choices model,
of condition
such as increased
variable crop
limits andyield or reductions
the actions in contaminant
they trigger will result outputs. Other choices
in more favorable of decision
outcomes table
from the SWAT+
parameters
model, will
suchproduce less favorable
as increased outcomes.
crop yield Findingin
or reductions a set of decision outputs.
contaminant parameters thatchoices
Other optimize
ofthe
decision
table parameters will produce less favorable outcomes. Finding a set of decision parameters that
optimize the output of SWAT+ in a specified way has the form of a non-linear optimization problem.
In optimization problems, one formulates an objective function to be minimized that consists of a
combination of model outputs, with assigned weights to specify the relative importance placed on
the different outputs. For example, it would be possible to define an objective function that decreases
Water 2018, 10, 713 9 of 10

output of SWAT+ in a specified way has the form of a non-linear optimization problem. In optimization
problems, one formulates an objective function to be minimized that consists of a combination of model
outputs, with assigned weights to specify the relative importance placed on the different outputs.
For example, it would be possible to define an objective function that decreases in amplitude as
predicted crop yields increase and contaminant outputs decrease, with the two competing factors
weighted according to their relative importance. The solution of the optimization problem is the set
of free variables that produce the smallest possible objective function. In this case, the free variables
would be the decision table condition limits and their associated actions, such as conditions under
which crops are irrigated and fertilized and how much water and fertilizer are applied. Non-linear
optimization problems such as this, in which the derivatives of the objective function with respect to
the free variables are not easily computed, are commonly solved by the method of simulated annealing,
which requires only repeated calculation of the objective function for different sets of free variables [21].
Combining simulated annealing with decision table controlled SWAT+ simulations could be used to
optimize management practices to fit different competing performance criteria.

4. Summary and Conclusions

Decision table theory was developed in the 1960s for data processing and business level
rules. CLIPS and FORTAB were computer languages developed in C and FORTRAN, respectively,
to define expert systems using a decision table structure. Land, river, and reservoir management
models often use embedded expert systems to determine land management and operations (such as
plant/harvest, tillage, and fertilization), reservoir releases, and water transfer in canals. In this study,
we incorporated decision table data and algorithms into a river basin scale ecohydrologic model
(SWAT+). Using decision tables to simulate management in land, river, and reservoir models has
several advantages over current approaches, including:

(1) The structure of a decision table can be easily understood by model users. Decision tables were
developed over 50 years ago, and there is considerable literature and tutorials available on-line
related to developing decision tables.
(2) Decision tables accurately represent complex, real world decision-making.
(3) The code is more modular and easier to maintain than code to simulate management in existing
land management models.
(4) The code to implement decision tables is more efficient than languages developed for specific
river and reservoir models.
(5) Decision tables can be easily maintained and supported.
(6) It is relatively simple to add the decision tables approach to legacy land, river, and
reservoir models.

As incorporated into SWAT+, the decision table is a robust and efficient method to simulate
complex, rule-based management. Examples of automated irrigation and reservoir release were shown
and other management operations simulated with decision tables were listed. In addition, decision
tables have the potential for use in water rights and water transfers, states and transition of natural
ecosystems, and the management of animal herds.

Author Contributions: Conceptualization, J.G.A. and P.M.A.; Data curation, M.J.W.; Formal analysis, R.S.;
Investigation, J.G.A. and M.J.W.; Methodology, J.A.D.; Validation, K.B.; Writing (original draft), J.G.A.; Writing
(review and editing), K.B., M.J.W., R.S., J.A.D., and P.M.A.
Conflicts of Interest: The authors declare no conflict of interest.
Water 2018, 10, 713 10 of 10

References
1. Williams, J.R.; Jones, C.A.; Dyke, P.T. A modeling approach to determining the relationship between erosion
and soil productivity. Trans. ASAE 1984, 27, 129–144. [CrossRef]
2. Williams, J.R.; Izaurralde, R.C.; Williams, C.; Steglich, E.M. Agricultural Policy/Environmental Extender
Model—Theoretical Documentation Version 0806. Texas A&M AgriLife Research. Available online:
http://epicapex.tamu.edu/files/2017/03/THE-APEX0806-theoretical-documentation-Oct-2015.pdf
(accessed on 15 May 2015).
3. Tuppad, P.; Winchell, P.M.; Wang, X.; Srinivasan, R.; Williams, J.R. ArcAPEX: ArcGIS interface for agricultural
policy environmental extender (APEX) hydrology/water quality model. Int. Agric. Eng. J. 2009, 18, 59–71.
4. Bieger, K.; Arnold, J.G.; Rathjens, H.; White, M.J.; Bosch, D.D.; Allen, P.M.; Volk, M.; Srinivasan, R.
Introduction to SWAT+, a completely revised version of the Soil and Water Assessment Tool. J. Am. Water
Resour. Assoc. 2017, 53, 115–130. [CrossRef]
5. Arnold, J.G.; Moriasi, D.; Gassman, P.W.; Abbaspour, K.C.; White, M.J.; Srinivasan, R.; Santhi, C.;
Harmel, R.D.; van Griensven, A.; Van Liew, M.W.; et al. SWAT: Model use, calibration, and validation.
Trans. ASABE 2012, 55, 1491–1508. [CrossRef]
6. Wurbs, R.A. Reservoir/river systems management models. Texas Water J. 2012, 3, 26–41.
7. Wurbs, R.A. Modeling and Analysis of Reservoir System Operations; Prentice-Hall: Upper Saddle River, NJ, USA,
1996; ISBN 0-13-605924-4.
8. Labadie, J.W. MODSIM: Decision support system for integrated river basin management. In Proceedings
of the iEMS International Congress on Environmental Modelling and Software, Burlington, VT, USA,
24-28 June 2006.
9. Zagona, E.A.; Fulp, T.J.; Shane, R.; Magee, T.; Goranflo, H.M. RiverWare: A generalized tool for complex
reservoir system modeling. J. Am. Water Resour. Assoc. 2001, 37, 913–929. [CrossRef]
10. DHI. MIKE BASIN User’s Manual; DHI Water and Environment: Copenhagen, Denmark, 2006.
11. Sulis, A.; Sechi, G.M. Comparison of generic simulation models for water resource systems.
Environ. Model. Softw. 2013, 40, 214–225. [CrossRef]
12. Yates, D.; Sieber, J.; Purkey, D.; Huber-Lee, A. WEAP21—A demand-, priority-, and preference-driven water
planning model. Water Int. 2005, 30, 487–500. [CrossRef]
13. Gildersleeve, T.R. Decision Tables and Their Practical Application in Data Processing; Prentice Hall: Upper Saddle
River, NJ, USA, 1970; ISBN-13: 978-0131973763.
14. Giarratano, J.C.; Riley, G. Expert Systems, 3rd ed.; PWS Publishing Co.: Boston, MA, USA, 1998;
ISBN 0534950531.
15. Giarratano, J.C. CLIPS User’s Guide: Volume 1, Rules, CLIPS version 5.0; Software Technology Branch, Lyndon
B. Johnson Space Center: Houston, TX, USA, 1991.
16. Amerding, G.W. FORTAB: A Decision Table Language for Scientific Computing Applications; TR RM-3306-PR;
RAND Corporation: Pittsburgh, PA, USA, 1962.
17. Arnold, J.G.; Srinivasan, R.; Muttiah, R.S.; Williams, J.R. Large area hydrologic modeling and assessment
part I: Model development. J. Am. Water Resour. Assoc. 1998, 34, 73–89. [CrossRef]
18. Williams, J.R.; Arnold, J.G.; Kiniry, J.R.; Gassman, P.W.; Green, G.J. History of model development at Temple,
Texas. Hydrol. Sci. 2008, 53, 948–960. [CrossRef]
19. U.S. Army Corps of Engineers. Developing Seasonal and Long-Term Reservoir System Operation Plans Using
HEC-PRM; Report RD-40; Hydrologic Engineering Center: Davis, CA, USA, 1996; 445p.
20. Moriasi, D.N.; Arnold, J.G.; Van Liew, M.W.; Bingner, R.L.; Harmel, R.D.; Veith, T. Model evaluation
guidelines for systematic quantification of accuracy of watershed simulations. Trans. ASABE 2007, 50,
885–900. [CrossRef]
21. Sen, M.K.; Stoffa, P.L. Nonlinear one-dimensional seismic waveform inversion using simulated annealing.
Geophysics 1991, 56, 1624–1638. [CrossRef]

© 2018 by the authors. Licensee MDPI, Basel, Switzerland. This article is an open access
article distributed under the terms and conditions of the Creative Commons Attribution
(CC BY) license (http://creativecommons.org/licenses/by/4.0/).