Decision Tables

Decision tables are a precise yet compact way to model complex rule sets and their corresponding actions. Decision tables, like flowcharts and if-then-else and switch-case statements, associate conditions with actions to perform, but in many cases do so in a more elegant way (see Wikipedia article on decision tables).

Structure of decision tables:

  1. Conditions

  2. Condition alternatives

  3. Actions

  4. Action entries

Each decision corresponds to a variable, relation or predicate whose possible values are listed among the condition alternatives. Each action is a procedure or operation to perform, and the entries specify whether (or in what order) the action is to be performed for the set of condition alternatives the entry corresponds to. Many decision tables include in their condition alternatives the "don’t care" symbol, a hyphen. Using "don’t cares" can simplify decision tables, especially when a given condition has little influence on the actions to be performed. In some cases, entire conditions thought to be important initially are found to be irrelevant when none of the conditions influence which actions are performed.

Usage in SWAT+

There are four decision table sections in SWAT+: land use management, reservoir release, scenario land use, and flow conditions.

See the land use management documentation, under management schedules for how to choose a decision table for your HRUs.

pageLand Use Management

Reservoir release decision tables are assigned from the reservoir properties section under connections in SWAT+ Editor.

Modifying Decision Tables in SWAT+ Editor

In the current version of SWAT+ editor, we do not have a GUI available for editing decision tables, however we have provided the ability to export the decision table file. You may then make changes to it in a text editor, and upload back into SWAT+ Editor.

Table Definitions

SWAT+ Input File

Database Table

lum.dtl, res_rel.dtl, scen_lu.dtl, flo_con.dtl

d_table_dtl

d_table_dtl_cond

d_table_dtl_cond_alt

d_table_dtl_act

d_table_dtl_act_out

d_table_dtl

Field

Type

Description

id

int

Auto-assigned identifier

name

text

Name of the decision table

file_name

text

File name denoting type of decision table: lum.dtl, res_rel.dtl, scen_lu.dtl, flo_con.dtl

d_table_dtl_cond

Field

Type

Description

Related Table

id

int

Auto-assigned identifier

d_table_id

int

ID of decision table

d_table_dtl

var

text

Condition variable

obj

text

Object variable (res, hru, etc)

obj_num

int

Object number

lim_var

text

Limit variable (evol, pvol, fc, etc)

lim_op

text

Limit operator (*, +, -)

lim_const

real

Limit constant

d_table_dtl_cond_alt

Field

Type

Description

Related Table

id

int

Auto-assigned identifier

cond_id

int

ID of condition

d_table_dtl_cond

alt

text

Condition alternatives (>, <, =)

d_table_dtl_act

Field

Type

Description

Related Table

id

int

Auto-assigned identifier

d_table_id

int

ID of decision table

d_table_dtl

act_typ

text

Type of action (reservoir, irrigate, etc)

obj

text

Object variable (res, hru, etc)

obj_num

int

Object number

name

text

Name of action

option

text

Action option-specific to type of action (e.g., for reservoir, option to input rate, days of draw-down, weir equation pointer, etc)

const

real

Constant used for rate, days, etc

const2

real

fp

text

Pointer for option (e.g., weir equation pointer)

d_table_dtl_act_out

Field

Type

Description

Related Table

id

int

Auto-assigned identifier

act_id

int

ID of action

d_table_dtl_act

outcome

bool

Perform action (1 or true), or don't perform action (0 or false)

Text File Example and Explanation

The following is an example of a decision table in the lum.dtl input file. It is a table for warm season annual crops, using continuous corn.

In the above table, there are 6 conditions, 4 alternatives and 3 actions.

Description of the conditions

  1. soil_water – if soil water is too high (> 1.50*field capacity), it will be too wet to operate machinery

  2. plant_gro – (“n”) Planting allowed if plant is not growing.

  3. phu_base0 – (0.15) when the sum base zero heat units for the year (starting Jan 1) exceeds 0.15, indicating it’s warm enough to plant

  4. phu_plant – (1.15) harvest is scheduled when the sum of the heat units for the crop exceed 1.15 (if the heat units to maturity for the crop = 1500, then harvest would be scheduled at 1.15 * 1500 = 1725).

  5. year_rot – needed to identify the current year of rotation. In this example, corn is grown in year 1.

  6. days_plant – days since last plant (200) to ensure harvest occurs before next crop is planted.

Description of the alternatives

If all of the conditions for each alternative are met, outcomes are checked for ‘y’ to take action. Alternatives with dash (‘-‘) are not checked.

  1. plant corn based on heat units: if soil water < 1.50*fc and if phubase0 > 0.15*phu_mat and if year_rot = 1 then check outcomes for ‘y’ and if ‘y’, take that action (plant)

  2. Harvest corn based on crop accumulated heat units: if soil_water < 1.50*fc and if phu_plant > 1.15*phu_mat and if year_rot = 1 and then check outcomes for ‘y’ and if ‘y’, take that action (plant)

  3. Harvest corn based on days since planting: if year_rot = 1 and if days_plant =200 then check outcomes for ‘y’ and if ‘y’, take that action (harvest)

  4. Reset rotation year: if year_rot > 1 then check outcomes for ‘y’ and if ‘y’, take that action (rot_reset)

Description of the actions

  1. plant: corn – cross walked to plant name in plants.plt file

  2. harvest_kill: corn – cross walked to plant name in plants.plt file grain – relates to harvest type in harv.ops file

  3. rot_reset: rotation reset – for continuous corn (1 year rotation). The rotation year is reset to 1 at the end of every year.

Last updated