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.

Landscape Unit

A Landscape Unit is a collection of HRUs. A Landscape Unit 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. Two input files are required to define which HRUs belong to which Landscape Unit: 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.

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

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.

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.

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 listed 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 to 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.

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

• 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,

• controls the simulation time period and time step, and

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

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

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.

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:

This parameter specifies the interval within the specified printing period.

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.

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.

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

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 , , , , and , 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 . 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 . Finally, the user has the option to specify the name of an atmospheric deposition record, which points to .

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

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.

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

The name of the precipitation station is a foreign key referencing the filenames listed in pcp.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 wind speed station is a foreign key referencing the filenames listed in wnd.cli.

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

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

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

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

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

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 is the mean daily minimum temperature for the month (ºC), is the daily minimum temperature on day in month (ºC), and is the total number of daily minimum temperature records for month .

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

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

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

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 value represents the most extreme 30-minute rainfall intensity recorded in the entire period of record.

This variable is used to calculate values for .

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

where is the skew coefficient for precipitation in the month, is the total number of daily precipitation records for month , is the amount of precipitation for day in month (mm H2O), is the average precipitation for the month (mm H2O), and is the standard deviation for daily precipitation in month (mm H2O). Daily precipitation values of 0 mm are included in the skew coefficient calculation.

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 is the mean daily maximum temperature for the month (ºC), is the daily maximum temperature on day in month (ºC), and is the total number of daily maximum temperature records for month .

The probability is calculated as

where is the probability of a wet day following a wet day in month , is the number of times a wet day followed a wet day in month for the entire period of record, and is the number of wet days in month during the entire period of record. A wet day is a day with > 0 mm precipitation.

The average or mean total monthly precipitation is calculated as

where is the mean monthly precipitation (mm H2O), is the daily precipitation for day in month (mm H2O), is the total number of records in month used to calculate the average, and is the number of years of daily precipitation records used in calculation.

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

where is the standard deviation for daily minimum temperature in month (ºC), is the daily minimum temperature on day in month (ºC), is the average daily minimum temperature for the month (ºC), and is the total number of daily minimum temperature records for month .

This parameter is calculated as

where is the average number of days of precipitation in month , is the number of wet days in month during the entire period of record, and is the number of years of record.

The probability is calculated as

where is the probability of a wet day following a dry day in month , is the number of times a wet day followed a dry day in month for the entire period of record, and is the number of dry days in month 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.

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

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

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.

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

Papers Daniel, Tássia

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.

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

Papers Xuesong, Armen

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.

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.

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.

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.

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

Barrow, N.J. and T.C. Shaw. 1975. The slow reactions between soil and anions. 2. Effect of time and temperature on the decrease in phosphate concentration in soil solution. Soil Science 119(2): 167-177. Link

Jones et al. 1984

Munns and Fox. 1976

Rajan and Fox. 1972

Sharpley. 1982

Sharpley et al. 1984

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.

This parameter controls the amount of nitrate removed from the surface layer in runoff relative to the amount removed via percolation.

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

The weighting factor is a function of the wedge storage. This parameter is only important if channel routing is simulated using the Muskingum routing method.

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.

The evaporation coefficient is a calibration parameter for the user that was created to allow reach evaporation to be dampened in arid regions. The original equation tends to overestimate evaporation in these areas.

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.

The following hydrographs can be printed:

Output can be printed for the following types of objects:

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

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.

There are two channel water routing methods available in SWAT+:

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

Vadas & White (2010)

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.

Please refer to the Theoretical Documentation for a description of the use of this parameter in the mineralization calculations.