Over the past 20 years, the Soil and Water Assessment Tool (SWAT) has become widely used across the globe. Various applications of the model have revealed limitations and identified model development needs. Numerous additions and modifications of the model and its individual components have made the code increasingly difficult to manage and maintain. In response to these issues and in order to face present and future challenges in water resources modeling, the SWAT code has undergone major modifications over the past few years, resulting in SWAT+, a completely restructured version of the model. Even though the basic algorithms used to calculate the processes in the model have not changed, the structure and organization of both the code (object based) and the input files (relational based) have been modified significantly. This is expected to facilitate model maintenance, future code modifications, and foster collaboration with other researchers to integrate new science into SWAT modules. Additionally, SWAT+ provides a more flexible spatial representation of interactions and processes within a watershed.

SWAT was developed by USDA-ARS and Texas A&M scientists.

SWAT+ offers considerable flexibility with regard to the configuration of a watershed. The elements of a watershed are defined as spatial objects:

• Landscape Unit

• Routing Unit

• HRU

• Aquifer

• Channel

• Reservoir

Gravity-based exchange of water between spatial objects is defined in so-called connect files.

Arnold et al. 1998

Bieger et al. 2017

Bieger et al. 2019

Arnold et al. 2018

CARD database

Landscape Unit

A landscape unit is a collection of HRUs. A landscape units can be equivalent to a subbasin, a floodplain or upland unit, or a grid cell with multiple HRUs. Landscape units are only used for output. The landscape unit output files (water balance, nutrient balance, losses, and plant and weather) are output for HRUs, landscape units, and for the basin. Two input files are required: 1) landscape elements and, 2) landscape define. The elements file includes HRUs and their corresponding LSU fraction and basin fractions. The define file specifies which HRUs are contained in each LSU.

Routing Unit

The routing unit is the spatial unit in SWAT+ that allows us to lump outputs and route them to any other spatial object. The routing unit can be configured as a subbasin, then total flow (surface, lateral and tile flow) from the routing unit can be sent to a channel and all recharge from the routing unit sent to an aquifer. This is analogous to the current approach in SWAT. However, SWAT+ gives us much more flexibility in configuring a routing unit. For example, in CEAP, we are routing each HRU (field) through a small channel (gully or grass waterway) before it reaches the main channel. In this case, the routing unit is a collection of flow from the small channels. We also envision simulating multiple representative hillslopes to define a routing unit. Also, we are setting up scenarios that define a routing unit using tile flow from multiple fields and sending that flow to a wetland. Routing units will continue to be a convenient way of spatial lumping until we can simulate individual fields or cells in each basin.

Calculating the basin water balance without upland/floodplain routing

Calculating the basin water balance with upland/floodplain routing

Seibert and McDonnell (2002) suggested the use of “hard” and “soft” data for multi-criteria model calibration. Hard data are defined as measured time series, typically at a point (e.g., streamflow, groundwater levels, or soil moisture) that is commonly used in regression-based calibration techniques. Soft data are defined as information on individual processes within a balance that may not be directly measured in the study area, may be an average annual estimate, and may entail considerable uncertainty. Examples of soft data include regional estimates of baseflow ratios or ET, average depths of groundwater tables, average annual runoff coefficients for various land uses, annual rates of denitrification from research plots found in the literature, event mean concentrations, nutrient/sediment export coefficients, sediment deposition from reservoir sedimentation studies, average crop/vegetation LAI, and county crop yields (Arnold et al., 2015).

Soft calibration procedure

Seibert and McDonnell (2002) argued that soft data represent a new dimension to the model calibration process that could: (1) enable dialog between experimentalists and modelers, (2) be a formal check on the reasonableness and consistency of internal model structures and simulations, and (3) specify realistic parameter ranges often ignored in today’s automatic calibration routines.

Misrepresented processes (water balance, nutrient balance, sediment source/sinks) within a watershed can cause errors when running management scenarios (Arnold et al., 2015). To ensure proper process representation, a soft calibration routine for water balance was added to SWAT+ code. The processes calibrated are surface runoff, lateral soil flow, percolation, and ET. Tile flow variables are not adjusted, if subsurface tiles are present, tile flow is simulated as the remainder of the water balance when all other processes are calibrated. The processes are input as the ratio to precipitation, thus minimizing the impact of different periods of record or different sources of precipitation. The procedure is a simple, heuristic approach with one variable for each process. The variables, associated process, change type, change limits, and total limits are shown in the table below.

The algorithm uses one variable at a time in the following order: 1) esco, 2) petco, 3) cn3_swf, 4) latq_co, 5) perco, and 6) cn3_swf is calibrated again to ensure surface runoff is accurate. The first iteration with each variable is an initial guess calculated as shown in the table below. In each case, the initial change in each variable is a function of the difference (mm) in the soft ratio multiplied by precipitation minus the modeled process output. For example, if the surface runoff ratio input by the user is 0.2 and the simulated precipitation and surface runoff are 800 mm and 120 mm, respectively, the difference is 0.2*800 – 120 = 40 mm.

After the initial variable change, two additional iterations are performed using linear interpolation between the previous two simulations. Although the process response to the variable change is nonlinear, as the model iterates and approaches the soft data value, the linear interpolation is able it reasonably approximate the soft data. For the surface runoff example, with an initial difference of 40 mm, the next value of cn3_swf used in the calibration would be set to cn3_swf –0.4.

After the soft calibration is complete, the hard calibration of streamflow should only require some adjustments of the peaks and recessions.

All SWAT+ input files are free format and space delimited.

The first line in each input file is reserved for a title. If the files were written using the SWAT+ Editor, the title will specify the name of the file, the version of the SWAT+ Editor, and the date and time the file was written. While this line is required, it is not read in by SWAT+ and may be modified or left blank. The title is limited to 80 spaces.

The second line in all SWAT+ input files except for file.cio is reserved for the header, i.e. the names of the variables listed in the file. Some files will have additional header lines (e.g., print.prt).

There are three files that control the settings for a simulation run:

• object.cnt specifies the land area and the total area (including ponds and reservoirs) of the watershed and the counts of all spatial objects in a simulation,

• time.sim controls the simulation time period and time step, and

• print.prt controls which output files will be printed for a simulation.

An additional, optional file, object.prt, allows the user to print selected output for individual spatial objects.

This file lists the names of all input files used in a simulation run. The files are grouped in different categories and there is one line for each category. The first column lists the names of the categories. The number of columns per line depends on the number of files in a category. Most files are required for all SWAT+ runs, i.e. they have to be listed in file.cio and the corresponding file has to be present in the TxtInOut folder of the SWAT+ project. There are also some optional files that are only required for specific SWAT+ applications. The category names and their files are listed below.

Simulation

1. time.sim

2. print.prt

3. object.prt

4. object.cnt

5. constituents.cs

Basin

1. codes.bsn

2. parameters.bsn

Climate

1. weather-sta.cli

2. weather-wgn.cli

3. wind-dir.cli (currently not used)

4. pcp.cli

5. tmp.cli

6. slr.cli

7. hmd.cli

8. wnd.cli

9. atmo.cli

Connect

1. hru.con

2. hru-lte.con

3. rout_unit.con

4. gwflow.con (a description of the gwflow module and all related input files will be added asap)

5. aquifer.con

6. aquifer2d.con (currently not used)

7. channel.con (currently not used)

8. reservoir.con

9. recall.con

10. exco.con

11. delratio.con

12. outlet.con

13. chandeg.con

Channel

1. initial.cha

2. channel.cha (currently not used)

3. hydrology.cha (currently not used)

4. sediment.cha (currently not used)

5. nutrients.cha

6. channel-lte.cha

7. hyd-sed-lte.cha

8. temperature.cha

Reservoir

1. initial.res

2. reservoir.res

3. hydrology.res

4. sediment.res

5. nutrients.res

6. weir.res

7. wetland.wet

8. hydrology.wet

Routing Unit

1. rout_unit.def

2. rout_unit.ele

3. rout_unit.rtu

4. rout_unit.dr (currently not used)

HRU

1. hru-data.hru

2. hru-lte.hru

Export Coefficient

1. exco.exc

2. exco_om.exc

3. exco_pest.exc (currently not used)

4. exco_path.exc (currently not used)

5. exco_hmet.exc (currently not used)

6. exco_salt.exc (currently not used)

Recall

1. recall.rec

Delivery Ratio

1. del_ratio.del (currently not used)

2. dr_om.del (currently not used)

3. dr_pest.del (currently not used)

4. dr_path.del (currently not used)

5. dr_hmet.del (currently not used)

6. dr_salt.del (currently not used)

Aquifer

1. initial.aqu

2. aquifer.aqu

Herd

1. animal.hrd (currently not used)

2. herd.hrd (currently not used)

3. ranch.hrd (currently not used)

Water Rights

1. water_allocation.wro

Link

1. chan-surf.lin

2. aqu_cha.lin

Hydrology

1. hydrology.hyd

2. topography.hyd

3. field.fld

Structural

1. tiledrain.str

2. septic.str

3. filterstrip.str

4. grassedww.str

5. bmpuser.str

HRU Databases

1. plants.plt

2. fertilizer.frt

3. tillage.til

4. pesticide.pes

5. pathogens.pth (currently not used)

6. metals.mtl (currently not used)

7. salt.slt (currently not used)

8. urban.urb

9. septic.sep

10. snow.sno

Operation Scheduling

1. harv.ops

2. graze.ops

3. irr.ops

4. chem_app.ops

5. fire.ops

6. sweep.ops

Land Use Management

1. landuse.lum

2. management.sch

3. cntable.lum

4. cons_practice.lum

5. ovn_table.lum

Change

1. cal_parms.cal

2. calibration.cal

3. codes.sft

4. wb_parms.sft

5. water_balance.sft

6. ch_sed_budget.sft (currently not used)

7. ch_sed_parms.sft (currently not used)

8. plant_parms.sft

9. plant_gro.sft

Initial

1. plant.ini

2. soil_plant.ini

3. om_water.ini

4. pest_hru.ini

5. pest_water.ini

6. path_hru.ini (currently not used)

7. path_water.ini (currently not used)

8. hmet_hru.ini (currently not used)

9. hmet_water.ini (currently not used)

10. salt_hru.ini (currently not used)

11. salt_water.ini (currently not used)

Soils

1. soils.sol

2. nutrients.sol

3. soils_lte.sol (currently not used)

Conditional

1. lum.dtl

2. res_rel.dtl

3. scen_lu.dtl

4. flo_con.dtl

Regions

1. ls_unit.ele

2. ls_unit.def

3. ls_reg.ele

4. ls_reg.def

5. ls_cal.reg

6. ch_catunit.ele

7. ch_catunit.def

8. ch_reg.def

9. aqu_catunit.ele

10. aqu_catunit.def

11. aqu_reg.def

12. res_catunit.ele

13. res_catunit.def

14. res_reg.def

15. rec_catunit.ele

16. rec_catunit.def

17. rec_reg.def

The last five rows in file.cio are used to specify the climate file directories if these are stored in a folder other than the project TxtInOut folder.

SWAT+ is able to end a simulation at any day of the year. This option can for example be useful, if the user wishes to simulate hydrological years instead of calendar years.

SWAT+ is able to begin a simulation at any day of the year. This option can for example be useful, if the user wishes to simulate hydrological years instead of calendar years.

Some simulations will need a warm-up or equilibration period. The use of a warm-up period becomes more important as the simulation period of interest shortens. For 30-year simulations, a warm-up period is optional. For a simulation covering 5 years or less, a warm-up period is recommended.

The print.prt file is formatted differently than most other SWAT+ input files (see figure below). In line three, there are several variables for controlling the time period to be printed. In line five, the user can specify the number of print intervals for average annual output. In line seven, the user can select to have output files printed in a specific file format (in addition to the default *.txt output files). In line 9, the user can control the printing of outputs for soils and management as well as flow duration curves. In lines 11 to 90, there is a list of outputs for different spatial levels and objects that can be printed at daily, monthly, yearly, and average annual time steps. A description of the output files is provided in the SWAT+ Output Files section.

This parameter specifies the interval within the specified printing period.

The table below lists the objects that are listed in the first column of this section of the print.prt file. For each of these objects, output can be printed at daily, monthly, yearly, and average annual time steps by entering y (=yes) or n (=no) in the following four columns.

If aa_int_cnt = 0, the model will print average annual output for the entire period. If aa_int_cnt > 0, the end years of the print intervals have to be specified by the user by listing them in chronological order in the same line as aa_int_cnt.

SWAT+ is able to run at the following time steps:

The name of the weather station is a primary key referenced by wst in 'object'.con.

SWAT+ requires daily data for precipitation, maximum and minimum air temperature, solar radiation, relative humidity, and wind speed. The model can read in observed weather data or generate values using the weather generator. Climate data will be generated in two instances: when the user specifies that simulated weather data will be used or when there are missing values in the observed weather data. A Global Weather Generator Database containing weather generator datasets in SWAT+ format for almost 180,000 stations across the globe can be downloaded from the SWAT website: https://swat.tamu.edu/data/.

If observed data is used, one data file has to be provided for each station and variable. The data files for precipitation, temperature, solar radiation, relative humidity, and wind speed should have the file extensions .pcp, .tem, .slr, .hmd, and .wnd, respectively. The names of all available data files for precipitation, temperature, solar radiation, relative humidity, and wind speed will be listed in pcp.cli, tmp.cli, slr.cli, hmd.cli, and wnd.cli, respectively.

Each spatial object in a SWAT+ setup will be assigned the weather stations that are closest to its centroid. Because the precipitation, temperature, solar radiation, relative humidity, and wind speed stations might be at different locations, several combinations of weather stations might be needed for a SWAT+ setup. These combinations will be listed as a record in weather-sta.cli. Each of them will be given a unique name, which is referenced by the connect files for the different spatial objects. In addition, the name of the closest weather generator station will be specified, which points to weather-wgn.cli. Finally, the user has the option to specify the name of an atmospheric deposition record, which points to atmo.cli.

The flowchart below illustrates the relationships between the different SWAT+ climate files.

The name of the precipitation station is a foreign key referencing the filenames listed in pcp.cli.

The name of the solar radiation station is a foreign key referencing the filenames listed in slr.cli.

Output can be printed for the following types of objects:

The name of the weather generator station is a foreign key referencing the primary key name in weather-wgn.cli.

The following hydrographs can be printed:

The name of the temperature station is a foreign key referencing the filenames listed in tmp.cli.

Soil water contents of the soil layers can be printed for all HRUs in the same file by setting obj_typ_no = 0. For all other outputs, a separate object print record with a unique name has to be defined for each object.

The name of the atmospheric deposition station is a foreign key referencing the station names in atmo.cli.

The object.prt file is commonly used to:

• Print daily channel outflow to compare to observed streamflow a stream gage

• Print daily flow to a file that can be read in as a point source from another SWAT+ simulation

The only timestep output can be printed at using this file is daily. A description of the output files is provided in the SWAT+ Output Files section.

The name of the weather generator station is a primary key referenced by wgn in weather-sta.cli.

The weather generator file contains weather generator data for any number of stations. For each weather generator station, there will be one line specifying the name of the station, its latitude, longitude, and elevation, and the number of years of maximum monthly 0.5 h rainfall data used to define values for pcp_hhr. There are no headers for this line. These variables are listed in the first table below. The second line for each weather generator station contains the headers for the following 12 lines, which list the weather generator data for each month of the year. An overview of the weather generator data variables is given in the second table below.

The name of the wind speed station is a foreign key referencing the filenames listed in wnd.cli.

This variable is used to calculate values for pcp_hhr.

This parameter quantifies the variability in maximum temperature for each month. The standard deviation is calculated as

where $σmx_{mon}$is the standard deviation for daily maximum temperature in month $mon$ (ºC), $T_{mx,mon}$ is the daily maximum temperature on day $d$ in month $mon$ (ºC), $μmx_{mon}$ is the average daily maximum temperature for the month $mon$ (ºC), and $N$ is the total number of daily maximum temperature records for month $mon$.

This value is calculated by summing the maximum air temperature for every day in the month for all years of record and dividing the sum by the number of days:

where $μmx_{mon}$is the mean daily maximum temperature for the month $mon$ (ºC), $T_{mx,mon}$ is the daily maximum temperature on day $d$ in month $mon$ (ºC), and $N$is the total number of daily maximum temperature records for month $mon$.

This parameter quantifies the variability in precipitation for each month. The standard deviation is calculated as

where $σ_{mon}$ is the standard deviation for daily precipitation in month $mon$ (mm H2O), $R_{day,mon}$ is the amount of precipitation for day $d$ in month $mon$ (mm H2O), $R_{mon}$ is the average precipitation for the month (mm H2O), and $N$ is the total number of daily precipitation records for month $mon$. Daily precipitation values of 0 mm are included in the standard deviation calculation.

This parameter quantifies the variability in minimum temperature for each month. The standard deviation is calculated as

where $σmn_{mon}$is the standard deviation for daily minimum temperature in month $mon$ (ºC), $T_{mn,mon}$ is the daily minimum temperature on day $d$ in month $mon$ (ºC), $μmn_{mon}$ is the average daily minimum temperature for the month $mon$ (ºC), and $N$ is the total number of daily minimum temperature records for month $mon$.

This value is calculated by summing the minimum air temperature for every day in the month for all years of record and dividing the sum by the number of days:

where $μmn_{mon}$is the mean daily minimum temperature for the month $mon$ (ºC), $T_{mn,mon}$ is the daily minimum temperature on day $d$ in month $mon$ (ºC), and $N$is the total number of daily minimum temperature records for month $mon$.

The probability is calculated as

where $P_i(W⁄W)$ is the probability of a wet day following a wet day in month $i$, $days_{W⁄W,i}$ is the number of times a wet day followed a wet day in month $i$ for the entire period of record, and $days_{wet,i}$ is the number of wet days in month $i$ during the entire period of record. A wet day is a day with > 0 mm precipitation.

This parameter quantifies the symmetry of the precipitation distribution around the monthly mean. The skew coefficient is calculated as

where $g_{mon}$ is the skew coefficient for precipitation in the month, $N$ is the total number of daily precipitation records for month $mon$, $R_{day,mon}$ is the amount of precipitation for day $d$ in month $mon$ (mm H2O), $R_{mon}$ is the average precipitation for the month (mm H2O), and $σ_{mon}$ is the standard deviation for daily precipitation in month $mon$ (mm H2O). Daily precipitation values of 0 mm are included in the skew coefficient calculation.

The average or mean total monthly precipitation is calculated as

where $R_{mon}$ is the mean monthly precipitation (mm H2O), $R_{day,mon}$ is the daily precipitation for day $d$ in month $mon$ (mm H2O), $N$ is the total number of records in month $mon$ used to calculate the average, and $yrs$ is the number of years of daily precipitation records used in calculation.

This parameter is calculated as

where $d_{wet,i}$ is the average number of days of precipitation in month $i$, $days_{wet,i}$ is the number of wet days in month $i$ during the entire period of record, and $yrs$ is the number of years of record.

This value represents the most extreme 30-minute rainfall intensity recorded in the entire period of record.

This value is calculated by summing the total solar radiation for every day in the month for all years of record and dividing the sum by the number of days:

where $μrad_{mon}$ is the mean daily solar radiation for the month (MJ/m2/day), $H_{day,mon}$ is the total solar radiation reaching the earth’s surface on day $d$ in month $mon$ (MJ/m2/day), and $N$ is the total number of daily solar radiation records for month $mon$.

This value is calculated by summing the average or mean wind speed values for every day in the month for all years of record and dividing the sum by the number of days:

where $μwnd_{mon}$ is the mean daily wind speed for the month (m/s), $T_{wnd,mon}$ is the average wind speed for day $d$ in month $mon$ (ºC), and N is the total number of daily wind speed records for month $mon$.

The probability is calculated as

where $P_i(W⁄D)$ is the probability of a wet day following a dry day in month $i$, $days_{W⁄D,i}$ is the number of times a wet day followed a dry day in month $i$ for the entire period of record, and $days_{dry,i}$ is the number of dry days in month $i$ during the entire period of record. A dry day is a day with 0 mm of precipitation. A wet day is a day with > 0 mm precipitation.

If all twelve months are < 1.0, the model assumes the data provided is relative humidity. Relative humidity is defined as the amount of water vapor in the air as a fraction of saturation humidity. If any month has a value > 1.0, the model assumes the data provided is dewpoint temperature.

Dew point temperature is the temperature at which the actual vapor pressure present in the atmosphere is equal to the saturation vapor pressure. This value is calculated by summing the dew point temperature for every day in the month for all years of record and dividing the sum by the number of days:

where $μdew_{mon}$ is the mean daily dew point temperature for the month (ºC), $T_{dew,mon}$ is the dew point temperature for day $d$ in month $mon$ (ºC), and $N$is the total number of daily dew point records for month $mon$. Please refer to the SWAT+ Theoretical Documentation for the equations used to convert dew point to relative humidity.

The relative humidity data files contain the observed relative humidity input data. They are named by the user and must have the file ending *.hmd. There must be one file per station used in the simulation. As in all SWAT+ input files, the first line in the relative humidity data files is reserved for user comments. The second line contains the column headers for the third line, which lists basic information about the station.

Starting in the fourth line, the year, Julian day, and the relative humidity are listed. There are no headers for these columns.

The hmd.cli file lists the names of the relative humidity data files used in the simulation. The first line is reserved for user comments. The second line is reserved for the column header "filename". The user can list as many relative humidity data file names as needed for the simulation. Only one file name should be listed per line. All file names listed in weather-sta.cli must be listed here. For every file name listed in hmd.cli, a file with that name must be provided by the user that contains the relative humidity data measured at the station.

The wind speed data files contain the observed precipitation input data. They are named by the user and must have the file ending *.wnd. There must be one file per station used in the simulation. As in all SWAT+ input files, the first line in the wind speed data files is reserved for user comments. The second line contains the column headers for the third line, which lists basic information about the station.

Starting in the fourth line, the year, Julian day, and wind speed are listed. There are no headers for these columns.

The wnd.cli file lists the names of the wind speed data files used in the simulation. The first line is reserved for user comments. The second line is reserved for the column header "filename". The user can list as many wind speed data file names as needed for the simulation. Only one file name should be listed per line. All file names listed in weather-sta.cli must be listed here. For every file name listed in wnd.cli, a file with that name must be provided by the user that contains the wind speed data measured at the station.

The precipitation data files contain the observed precipitation input data. They are named by the user and must have the file ending *.pcp. There must be one file per station used in the simulation. As in all SWAT+ input files, the first line in the precipitation data files is reserved for user comments. The second line contains the column headers for the third line, which lists basic information about the station.

Starting in the fourth line, the year, Julian day, and precipitation amount are listed. There are no headers for these columns.

If the user wishes to run simulations at a sub-daily time step, precipitation data has to be provided at the simulation time step. Currently, the model is able to run at an hourly time step. Smaller time steps have not been tested yet. Three additional columns need to be included in the hourly precipitation files:

The pcp.cli file lists the names of the precipitation data files used in the simulation. The first line is reserved for user comments. The second line is reserved for the column header "filename". The user can list as many precipitation data file names as needed for the simulation. Only one file name should be listed per line. All file names listed in weather-sta.cli must be listed here. For every file name listed in pcp.cli, a file with that name must be provided by the user that contains the precipitation data measured at the station.

The solar radiation data files contain the observed precipitation input data. They are named by the user and must have the file ending *.slr. There must be one file per station used in the simulation. As in all SWAT+ input files, the first line in the solar radiation data files is reserved for user comments. The second line contains the column headers for the third line, which lists basic information about the station.

Starting in the fourth line, the year, Julian day, and solar radiation are listed. There are no headers for these columns.

The slr.cli file lists the names of the solar radiation data files used in the simulation. The first line is reserved for user comments. The second line is reserved for the column header "filename". The user can list as many solar radiation data file names as needed for the simulation. Only one file name should be listed per line. All file names listed in weather-sta.cli must be listed here. For every file name listed in slr.cli, a file with that name must be provided by the user that contains the solar radiation data measured at the station.

The temperature data files contain the observed temperature input data. They are named by the user and must have the file ending *.tmp. There must be one file per station used in the simulation. As in all SWAT+ input files, the first line in the temperature data files is reserved for user comments. The second line contains the column headers for the third line, which lists basic information about the station.

Starting in the fourth line, the year, Julian day, and the maximum and minimum temperatures are listed. There are no headers for these columns.

The tmp.cli file lists the names of the temperature data files used in the simulation. The first line is reserved for user comments. The second line is reserved for the column header "filename". The user can list as many temperature data file names as needed for the simulation. Only one file name should be listed per line. All file names listed in weather-sta.cli must be listed here. For every file name listed in tmp.cli, a file with that name must be provided by the user that contains the temperature data measured at the station.

SWAT+ is able to read in monthly, yearly, and average annual atmospheric deposition values. Reading in daily values is currently not an option in SWAT+. The time step of the atmospheric deposition data has to be specified by the user in codes.bsn and the time step of the data in atmo.cli has to match the specified time step.

The structure of the file atmo.cli varies slightly depending on the time step of the data. As in all SWAT+ input files, the first line is reserved for user comments. The second line contains the column headers for the third line, which lists basic information about the atmospheric deposition stations.

Below, there will be 5 lines for each station included in the atmospheric deposition file. In the first of these, the name of the station will be specified. It is followed by 4 lines of data:

1. Wet deposition of ammonia nitrogen

2. Wet deposition of nitrate nitrogen

3. Dry deposition of ammonia nitrogen

4. Dry deposition of nitrate nitrogen

The number of values listed in the data lines depends on the number of months or years data is available for.

If crack = 1, the crack volume potential is controlled by perc_crk in soils.sol.

General watershed attributes are defined in two basin input files, codes.bsn and parameters.bsn. These attributes control a diversity of physical processes at the watershed level. Users can use the default values set by the interfaces or change them to better reflect what is happening in a given watershed.

Papers Xuesong, Armen

Numerous methods exist to calculate potential evapotranspiration. Three of the most widely-used ones are included in SWAT+, the Priestley-Taylor, Penman/Monteith, and Hargreaves equations. The codes for the three methods are listed in the table below. If a method other than Priestley-Taylor, Penman/Monteith, or Hargreaves is recommended for the area, in which the watershed is located, the user can calculate daily PET values with the recommended method and import them into SWAT+ (using pet in weather-sta.cli).

Vadas & White (2010)

The Unit Hydrograph method is only relevant when simulating at a sub-daily timestep and gampt = 0.

In large routing units with a time of concentration greater than 1 day, only a portion of the surface runoff will reach the main channel on the day it is generated. SWAT+ incorporates a surface runoff storage feature to lag a portion of the surface runoff release to the main channel.

This parameter controls the fraction of the total available water that will be allowed to enter the reach on any one day. For a given time of concentration, as surq_lag decreases in value more water is held in storage. The delay in release of surface runoff will smooth the streamflow hydrograph simulated in the reach.

Sediment routing is a function of peak flow rate and mean daily flow. Because SWAT originally could not directly calculate the sub-daily hydrograph, this variable was incorporated to allow adjustment for the effect of the peak flow rate on sediment routing. This variable impacts channel degradation.

Sediment routing is a function of peak flow rate and mean daily flow. Because SWAT originally could not directly calculate the sub-daily hydrograph due to the use of precipitation summarized on a daily basis, this variable was incorporated to allow adjustment for the effect of the peak flow rate on sediment routing. This factor is used in the MUSLE equation and impacts the amount of erosion generated in the HRUs.

All soils in the watershed will be initialized to the same fraction. If sw_init = 0.0, the model will calculate it as a function of average annual precipitation.

This parameter controls plant uptake of phosphorus from the different soil horizons in the same way that n_uptake controls nitrogen uptake.

Phosphorus removed from the soil by plants is taken from the solution phosphorus pool. The importance of the phosphorus uptake distribution parameter lies in its control over the maximum amount of solution P removed from the upper layers. Because the top 10 mm of the soil profile interacts with surface runoff, the phosphorus uptake distribution parameter will influence the amount of labile phosphorus available for transport in surface runoff. The model allows lower layers in the root zone to fully compensate for lack of solution P in the upper layers, so there should not be significant changes in phosphorus stress with variation in the value used for p_uptake.

The name of the relative humidity station is a foreign key referencing the filenames listed in hmd.cli.

Papers Daniel, Tássia

The phosphorus soil partitioning coefficient p_soil is the ratio of the soluble phosphorus concentration in the top 10 mm of soil to the concentration of soluble phosphorus in surface runoff.

The primary mechanism of phosphorus movement in the soil is by diffusion. Diffusion is the migration of ions over small distances (1-2 mm) in the soil solution in response to a concentration gradient. Due to the low mobility of solution phosphorus, surface runoff will only partially interact with the solution P stored in the top 10 mm of soil.

Root density is greatest near the surface, and plant nitrogen uptake in the upper portion of the soil will be greater than in the lower portion. The depth distribution of nitrogen uptake is controlled by n_uptake, the nitrogen uptake distribution parameter.

The importance of the nitrogen uptake distribution parameter lies in its control over the maximum amount of nitrate removed from the upper layers. Because the top 10 mm of the soil profile interacts with surface runoff, the nitrogen uptake distribution parameter will influence the amount of nitrate available for transport in surface runoff. The model allows lower layers in the root zone to fully compensate for lack of nitrate in the upper layers, so there should not be significant changes in nitrogen stress with variation in the value used for n_uptake.

The phosphorus percolation coefficient is the ratio of the solution phosphorus concentration in the top 10 mm of soil to the concentration of phosphorus in the percolate.

The fraction of residue that will decompose in a day assuming optimal moisture, temperature, C:N ratio, and C:P ratio.

Many studies have shown that after an application of soluble P fertilizer, solution P concentration decreases rapidly with time due to reaction with the soil. This initial "fast" reaction is followed by a much slower decrease in solution P that may continue for several years (Barrow and Shaw, 1975; Munns and Fox, 1976; Rajan and Fox, 1972; Sharpley, 1982). In order to account for the initial rapid decrease in solution P, SWAT+ assumes a rapid equilibrium exists between solution P and an "active" mineral pool. The subsequent slow reaction is simulated by the slow equilibrium assumed to exist between the "active" and "stable" mineral pools. The algorithms governing movement of inorganic phosphorus between these three pools are taken from Jones et al. (1984).

Equilibration between the solution and active mineral pool is governed by the phosphorus availability index. This index specifies the fraction of fertilizer P which is in solution after an incubation period, i.e. after the rapid reaction period.

A number of methods have been developed to measure the phosphorus availability index. Jones et al. (1984) recommends a method outlined by Sharpley et al. (1984) in which various amounts of phosphorus are added in solution to the soil as K2HPO4. The soil is wetted to field capacity and then dried slowly at 25°C. When dry, the soil is rewetted with deionized water. The soil is exposed to several wetting and drying cycles over a 6-month incubation period. At the end of the incubation period, solution phosphorus is determined by extraction with anion exchange resin.

The P availability index is then calculated as:

where pai is the phosphorus availability index, $P_{solution,f}$ is the amount of phosphorus in solution after fertilization and incubation, $P_{solution,i}$ is the amount of phosphorus in solution before fertilization, and $fert_{minP}$ is the amount of soluble P fertilizer added to the sample.

References