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

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

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 obj. If obj_num > 0, the condition will be checked for the object with the specified ID (in the object's connect 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 object types for all possible condition variables are listed in the table below.

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

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.

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.