Skip to content.
SWAT2000 Tips and Quirks

SWAT2000 Tips and Quirks

You can follow all the examples given in the SWAT manual and get the model to run successfully—yet this doesn't really explain how SWAT is working in the background. The following is a list of miscellaneous things that we've learned that helped us understand what SWAT was doing. My goal here is to offer some basic background information to beginning modelers about things that may not be obvious. Apologies if some of these things are too obvious. When I started with SWAT several years ago, virtually nothing was obvious to me. (Apologies also to those using SWAT2005—perhaps some of the following information is out of date. But we only have experience with SWAT2000 at the present time.)

The following is not a discussion of potential problems or bugs within SWAT—for that, see the Suggested Revisions PDF.

The basic relation between the AVSWAT interface and SWAT engine
By SWAT engine, I mean the compiled executable program, SWAT2000.exe, located in the AvSwatPr directory. The AVSWAT interface is used to create most of the necessary input files, at least the ones with spatial referencing. Some of these files are written to dbf files in the tablesin directory, and during the project creation the data in these files are decomposed into many text files in the txtinout directory. These input text files in the txtinout directory commonly don't look much like the dbf files in the tablesin directory. You'll need to create other input files, such as your rainfall and temperature files in either Excel or a text editor. When you set up your SWAT run, the interface then writes some additional files to the txtinout directory that are specific to that model run (whether you want annual, monthly, or daily output; the time period of the simulation, etc.). The interface also goes back to the AvSwatDB directory to get information on fertilizer, tillage, and crops to update some of the text files in the txtinout directory as well (see below—this happens immediately before executing the actual model run).

At this point, all of the input that SWAT needs is written, somewhere, in the text files in the txtinout folder. If you hit the run button in the AVSWAT interface, then the SWAT engine is invoked, the program runs, and produces output files, all of which end up in the txtinout directory as well. After a successful model run, if you choose to write output tables as well, then dbfs are written to the tablesout directory.

Running SWAT directly from the txtinout directory
Once the input files are created and residing in the txtinout directory, you don't need to run the model from the interface. There are times when it's useful to run the model (i.e., the SWAT engine) directly. The simplest way to do this is to copy the SWAT2000.exe file from the AvSwatPr directory to the txtinout directory. Open the command console (Run > Cmd), change your directory to the txtinout folder (commonly "cd C:\ AVSWAT2000\ yourProjectName\ scenarios\ default\ txtinout"). Then just type SWAT2000 on the command line to run the executable. The most common reason to do this is because SWAT is crashing for some reason, and this way the error messages will pop up in the command window. (Sometimes this is helpful, though often the messages are hard to understand.)

You would think that running the SWAT engine from the interface would be exactly the same as running it directly in the txtinout directory via the command line interface. But this isn't exactly true. When you run SWAT from the txtinout folder, then the ONLY files it uses comes from that directory. When you run SWAT from the interface—even if you don't change anything or set up anything—when you hit the "run" button, SWAT first goes back to the AvSwatDB directory to read in the crop.dat, fert.dat, and till.dat files, and then it re-writes this information to the appropriate text files in the txtinout directory, thereby "clobbering" (over-writing) the files that were there just seconds before. Hence, if you want to change something in your crop, tillage, or fertilizer data bases, you should change the .dat files in the AvSwatDB folder—because the interface will overwrite any changes you make in these files in the txtinout directory. (If you run SWAT directly from the txtinout directory, then fine, you can change the .dat files there, if you're changing anything. But the next time you run SWAT from the AVSWAT interface, these files will be overwritten with the information from the .dat files in the AvSwatDB folder.)

Changing data in the dbf files in the tablesin directory
Within the AVSWAT interface, you can open various tables, which refer to the dbf files in the tablesin directory (the table names in ArcView are slightly different than the dbf file names, but the correspondence is pretty obvious). We often use the field calculator in ArcView to change (edit) values in a selected field in one of these tables. Or alternatively, we sometimes alter these files in MS Access, for more complicated tasks that aren't easy to do within ArcView.

In order for these changes to be effective, when you set up your next SWAT run, you will need to respond "yes" to the question about whether you have modified any of the input database (dbf) files. Click on the file you modified, and then AVSWAT will write the appropriate input text files to the txtinout directory—this is the only way the SWAT engine will "see" the changes you just made. Remember, the SWAT engine sees ONLY the files in the txtinout directory when it runs.

LANDUSE in sbs.dbf not the same as LULC in
If you want to examine loads of nutrients and sediment from selected crop types, you'll need to examine the massive sbs file output (perhaps this file name has changed in SWAT2005). There are two sources of this information—most basically it's in the text file in the txtinout directory. But if you chose to write out the dbf output files at the end of a successful SWAT run, then the information is also in the sbs.dbf file in the tablesout directory—or it should be, but isn't quite (see below). (We generally only choose to write the output dbf files for runs with annual output, because monthly and daily output take too long to write.)

The dbf output files are convenient to analyze with MS Access. HOWEVER, the LANDUSE listed in the sbs.dbf file isn't necessarily the actual crop growing in that HRU—it is instead the designated "land use" that was originally input into AVSWAT. For vegetation types that do not change during the course of the simulation, then this is not a problem. However, for HRUs that have a crop rotation, then you need to know which crop is actually growing on that HRU for each year of the simulation. The text file does list the actual crop under the LULC column, but this can be a cumbersome file to manipulate. If you want to use Access to analyze annual output data by crop cover in the dbf file, you'll need to create a separate file with the actual crop for each HRU for each year of the simulation, which you can join to the sbs.dbf within Access, in order to properly extract the desired data for a selected crop. We would prefer that the LANDUSE in the sbs.dbf file be the actual crop being grown each year in an HRU.