The limit constant is the value the limit variable (lim_var) is multiplied or divided by or that is added to or subtracted from the limit variable (depending on lim_op).

The structure of the decision table files is different than that of most other SWAT+ input files. As usual, the first line is reserved for a title. The second line in the file specifies the total number of decision tables included in the file.

Each decision table has three parts, which all have their own headers. First, the name of the decision table and the number of conditions, alternatives, and actions are specified.

Next, the conditions and alternatives are defined. The number of lines used for this part of the decision table depends on the number of conditions.

Finally, the outcomes and actions are defined. The number of lines used for this part of the decision table depends on the number of actions.

The following condition variables are currently coded in SWAT+. If a condition field is not listed in 'Additional fields used', you may leave it as null if field type is string or 0.0000 if field type is double/real.

The condition variables, for which a limit variable must be specified, are listed in the table below. Some limit variables must be used in combination with a limit operator (see lim_op).

The alternative is the final piece to construct the “if” statement needed to implement the associated rule. One of the alternative operators listed in the table below must be specified for each condition defined in the Decision Table. The user can define as many alternatives as needed by adding the required number of alt columns and numbering them sequentially (alt1, alt2,...).

The model checks if the condition is met by:

1. comparing the condition variable to lim_const (if the condition variable has a limit constant but no limit variable and operator),

2. comparing the condition variable to lim_var (if the condition variable has a limit variable but no limit operator and constant),

3. comparing the condition variable to lim_var multiplied by/plus/minus/divided by lim_const (if the condition variable has a limit variable, operator, and constant), or

4. checking if the conditional variable is true (plant_gro, tile_drained, and plant_com).

How the condition variable is compared to 1., 2., or 3. or checked for 4. is controlled by the alternative operator:

The limit operators available and the limit and condition variables they are used for are listed in the table below.

If obj_num = 0, the condition will be checked for the current object of the type specified by . If obj_num > 0, the condition will be checked for the object with the specified ID (in the object's file) only.

Exception: prob_unif where obj_num is the first day of the period.

If obj_num = 0, the action will be performed for all objects of the type specified by . If obj_num > 0, the action will be performed for the object with the specified ID only.

The name of the action is defined by the user. It is not used by the model.

The outcome determines whether or not an action will be triggered when the condition alternative is met. There has to be an outcome defined for each alternative.

The only options for action entries are yes ("y") and no ("n").

• If all conditions specified by an alternative are met and the outcome is "y", then the associated action will be performed.

• If all conditions specified by an alternative are met but the outcome is "n", the associated action will not be performed.

• If not all conditions specified by an alternative are met, the associated action will not be performed, even if the outcome is "y".

Decision tables are a precise yet compact way to model complex rule sets and their corresponding actions and have been used for many years in data processing and business applications. 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.

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.

Quadrant I: Conditions

Quadrant I contains condition variables and condition limits. 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 ID in the current simulation must be defined. For some condition variables, the limits are defined using a limit variable, limit operator, and limit constant. Using reservoir volume as an example, the principle and emergency volumes could be used as limit variables. An example input would be “emergency volume * 0.8”. Some condition variables do not have limit variables, e.g., month and Julian day.

Quadrant II: Alternatives

There are six possible alternative operators: ">", "<", ">=", "<=", "=", and "-". The alternative is the final piece to construct the “if” statement needed to implement the associated rule. For the symbols ">", "<", and "=", the model will determine if the simulated value of the conditional variable is greater than, smaller than, or equal to the condition limit defined in quadrant I, respectively. The "-" symbol is used if the condition is not relevant for a specific alternative.

Quadrant III: Action Entries or Outcomes

Action entries or outcomes specify whether or not an action is triggered. The only options for action entries are yes ("y") and no ("n"). If all conditions specified by an alternative are true and the outcome is "y", then the associated action will be performed. If all conditions specified by an alternative are true but the outcome is "n", the associated action will not be performed.

Quadrant IV: Actions

The action type and associated information needed to perform the action are input in quadrant IV. The model must know which watershed object the action is supposed to be performed on. For some actions, there are multiple options to execute the action. Also, further information may need to be specified depending on the action.

There are currently four different types of decision tables available:

• lum.dtl: Land use and management decision tables

• scen_lu.dtl: Land use change decision tables

• res_rel.dtl: Reservoir and wetland release decision tables

• flo_con.dtl: Flow condition decision tables

The object types for all possible condition variables are listed in the table below.

The actions that can be triggered using the lum.dtl file are defined in the SWAT+ code. For each action, the type and ID of the object it is applied to, and a user-defined name have to be specified. Certain actions require additional information, which has to be specified in the fields option, const, const2, and fp. The use of these four fields depends on the action. The table below lists the actions implemented in the SWAT+ code, a short description, and the additional fields needed.

The file pointer is only needed for certain actions. The file that is referenced by the file pointer depends on the action. The table below lists the actions that use the file pointer and which file it points to.