- Support Us
- About Us
Useful Tools for SWAT Modeling
SWAT requires large amounts of input, and produces large amounts of output. The GIS interfaces (AVSWAT and AVSWAT-X) do a great job of setting up the input files. And, the output files are well-organized—but large and cumbersome at times. Much of the useful output is summarized in the output.std file. However, we've found that we often need very specific summary data from selected points in the watershed, and at different points along the flow path from the uplands, down the channel, and finally at the watershed outlet. For this, we've found that some additional skills in programming and data base manipulation have been needed to efficiently extract the most useful data for specific needs. So the following is a list of auxiliary software that we have found useful. Reference to trade names is not meant as a specific endorsement; there may be better software out there, but this is what we have used:
Basic data analysis and manipulation
It's also useful to learn enough Visual Basic for Applications (VBA for Excel) to make some of your own functions—such as the Nash-Sutcliffe Coefficient of Efficiency, for example. I bought a small introductory guide from a local bookstore; perhaps the online help for VBA will be enough for you, but I found the information just a bit over my head to start with.
Excel quirk—Changing the number of rows and columns in a dbf file is not so simple.
If you read a dbf file into Excel, and add a row or column, and then save the file again as a dbf, Excel will ignore the added (appended) rows and columns. This is because when Excel reads a dbf file, it gives the data range a name ("Database") and extent (number of rows and columns) for the original data. If you want to add a row or column, you'll need go to the menu and select "insert," "name," "define," select "Database", and then increase the range extent for the new data range. If instead you insert rows or columns within the original range, then Excel will expand the data base range automatically. But appending rows and columns outside the original range require the extra step of manually increasing the named range's size.
NotePad, WordPad, or other text editor (including Microsoft Word)
We also use Access to modify the input dbf files as well. We might want to modify the CNOPs for just selected crops or rotations in the management files. With Access we can update the specific HRUs we desire, efficiently. (Some of this might be possible to do as well with the field calculator from within ArcView.)
Finally, Access seems to write "cleaner" dbfs than does Excel. For whatever reason, sometimes Excel-generated dbfs are not readable by ArcView (though this is generally uncommon); we've had very good luck with Access-generated dbfs, which seem to be always readable.
My biggest complaint about Access is that if you write your queries directly in SQL (which I enjoy trying to learn), Access will not let you comment your code. Commenting code is how I preserve things I have finally figured out; without comments I waste time re-solving problems and trying to remember why I had done things a certain way.
ArcGIS and ArcView3
I realize there is an effort to develop a GIS interface for SWAT using open-source GIS software, which is an extremely valuable contribution given the annual fees associated with the ESRI products.
We haven't done more than write simple one or two page programs that read a selected SWAT output file, store the desired variables in an array, process or summarize those data, and produce output. Sometimes the output is just a written to the command console (which can be directed to a text file), and sometimes the output is a data file we can import into Excel.
We use such programs to summarize output that otherwise would take forever in something like Excel. Commonly we summarize monthly or daily output data with these programs. (As mentioned above, we often use Access to summarize annual output files. Access could probably be used for monthly or daily data as well, but AVSWAT takes so long to write these output dbfs that we just don't like waiting.)
Writing simple FORTRAN programs is pretty easy, and that's all you need for most tasks. You'll need to learn how to open files, read lines from those files (skipping the lines you don't care about), read and store selected variables in the lines of interest, process those variables to produce the desired summary data, and then write the results either to the command console (stdout) or to a text file. One or two example source-code files that exemplify these commands, along with a small test data set, should get you well on your way. To that end, here is a tiny FORTRAN source code file and data file as an example of how to extract selected data out of a SWAT output file:
Certainly other programming languages could be used to do the same thing (see below). I suspect that PERL and perhaps Python are also good at these things. But SWAT output tends to be well-organized in column format, which is exactly what FORTRAN expects (this is not surprising, since SWAT is a FORTRAN program itself!). Plus, learning a little FORTRAN can go a long way in helping you understand how SWAT works, if you venture into reading the source code files.
Other FORTRAN compilers
Statistics and graphics
HOWEVER, if command line programming is something that turns you off; if you don't have the passion and patience to learn yet another programming language—then you're probably better off going with a commercial statistics and/or plotting software package. I still use SigmaPlot or DeltaGraph for most of my plotting needs. Perhaps someday I'll get good enough at R to give them up—but not quite yet.