- Support Us
- About Us
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
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
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
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 basins.sbs
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 basins.sbs 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.