Use of decision tables to simulate management in ecohydrological models 1 2

J.G. Arnold1*, K. Bieger2, M.J. White3, R. Srinivasan4, J.A. Dunbar5, and P.M. Allen6 3 1 Grassland Soil and Water Res. Lab, USDA-ARS, Temple, Texas; jeff.arnold@ars.usda.gov 4 2 Texas A&M AgriLife, Temple, Texas; kbieger@brc.tamus.edu 5 3 Grassland Soil and Water Res. Lab, USDA-ARS, Temple, Texas; mike.white@ars.usda.gov 6 4 Texas A&M AgriLife, College Station, Texas; r-srinivasan@tamu.edu 7 5 Baylor University, Waco, Texas; John_Dunbar@baylor.edu 8


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 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.

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 useful in water resources planning.However, each lacks 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.

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 1980's 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, developed by the RAND Corporation in the 1980's [16].Many of the capabilities of CLIPS and FORTAB are now easily programmable in the current C and FORTAN languages.

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.

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 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 99 variables for setting condition limits for reservoir volume.An example 100 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: >, <, =, -.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  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.

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.1Auto 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 Figure 2. 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 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 certain crop in the rotation, only irrigate during a certain growth stage, or when reservoirs or aquifers are at specified level.The decision table allows the addition of conditions and actions in a simple and robust structure.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 3).This resulted in fewer applications, more total water applied each year (25 mm), and slightly higher corn yields (0.1 t/ha).This is a relatively simple example focusing on flood control.More complex rules can easily be added to simulate reservoirs managed in series by including conditions for other reservoirs and river flow.
Watershed conditions including irrigation demand, plant conditions, and soil water can be added to the conditions.Also, weir outflow as a function of storage can replace the constant outflow shown in this example.

Management optimization.
The use of a decision table as an external control on SWAT+ model runs also makes it possible to find decision tables that optimize certain SWAT+ model outputs.Some choices of condition variable limits and the actions they trigger will result in more favorable outcomes from the SWAT+ model, such as increased crop yield or reductions in contaminant outputs.Other choices of 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 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.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, state and transition of natural ecosystems, and management of animal herds.

3. 1 . 2
Auto Irrigation Application.The SWAT+ model was parameterized to simulate continuous corn with the Houston Black soil series from 2007-2016.Daily precipitation and maximum and minimum temperatures were input from the USDA-ARS station in Temple, Texas.The auto irrigation decision table as shown in Figure 2 was used in this example, with a stress trigger of 0.8 and 25 mm applied at each irrigation.Figure 3 shows soil moisture, precipitation and irrigation applications from 2014-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,

Figure 3 .
Figure 3. Soil moisture, precipitation, and irrigation of continuous corn at Temple, Texas using: 1) a plant stress trigger of 0.8 and application of 25 mm and 2) a plant stress trigger of 0.6 and application of 50 mm.

Table 1 .
).The four quadrants of a decision table.

Table 2 .
Conditional variables currently coded in SWAT+ for use in the decision tables.

Preprints (www.preprints.org) | NOT PEER-REVIEWED | Posted: 10 May 2018 doi:10.20944/preprints201805.0156.v1
Peer-reviewed version available at Water 2018, 10, 713; doi:10.3390/w10060713actions 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 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 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.

preprints.org) | NOT PEER-REVIEWED | Posted: 10 May 2018 doi:10.20944/preprints201805.0156.v1
Peer-reviewed version available at Water 2018, 10, 713; doi:10.3390/w100607132.2Integration 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 Figure1.

Preprints (www.preprints.org) | NOT PEER-REVIEWED | Posted: 10 May 2018 doi:10.20944/preprints201805.0156.v1
Decision table theory was developed in the 1960's 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: