If withdr = ave_day, the amount needs to be specified here. If using a Decision Table or a recall file, amount should be set to 0, because the amount will be controlled by the DT or recall file.

The user needs to specify the limit for each month.

Depending on the demand object type, different withdrawal types can be used. For irrigation or transfer decision tables, the name of the table should be entered in this column, for a recall file, the name of the file should be entered, and for average daily withdrawal, "ave_day" should be entered .

The receiving object can be specified by entering "cha" for channels, "res" for reservoirs, or "aqu" for aquifers. If non of these three options is entered, SWAT+ assumes that the water is transferred to an object outside the modeled watershed and thus lost from the system. By entering a name in this column, the user can make sure that the receiving object is included in the water allocation output file.

The structure of the water allocation file 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 water allocation tables included in the file.

Each water allocation table has three parts, which all have their own headers. First, the name of the water allocation table, the rule type, the number of source and demand objects, and whether or not one of the source objects is a channel are specified.

Next, the source objects and their monthly limits are defined. Source objects can be channels, reservoirs, aquifers, or an unlimited source. There needs to be one line per source object.

Finally, the demand objects are defined. Demand can be irrigation demand from an HRU, municipal demand, or demand to transfer to another object.There needs to be one line per demand object.

The sources are listed in order of selection and the fraction from each source is input. The other input is compensation – if other sources are not available, the current source may be allowed to compensate for the demand. The model goes through all sources in the order listed and allocates based on the fractions. The model loops through the sources again, checking to see if compensation is allowed.

There cannot be more than one channel object per water allocation table.

If one of the source objects is a channel, the water allocation module is called from the channel control subroutine when the simulation reaches the ID of the source channel. Otherwise, the water allocation module is called from the time control subroutine. This is important, because during a model run, there is more variability in the availability of water in a channel than in a reservoir or aquifer. Therefore, the model needs to know the current availability of water in the source channel on the day a demand is triggered.