After several posts about compiling and debugging SWAT with GFortran and Eclipse, I think it would be good to compile all the posts into an single document as a guide on this topic. So I create a google doc here and would like invite all of you to give some comments.
What happened when the “Import Files to Database” button is clicked?
- Copy SWATOutput.mdb from C:\swat\ArcSWAT\Databases\SWATOutput.mdb to [ArcSWAT Project]\Scenarios\Default\TablesOut. The previous database will be overwritten.
- Copy Schema.ini from C:\swat\ArcSWAT\Databases\Schema.ini to [ArcSWAT Project]\Scenarios\Default\txtinout. This file defines the data columns in text files generated in step 3. More information could be found from MSDN.
- Read SWAT output files (output.rch, output.sub, etc.) and generate corresponding text files (outputsub.txt, outputRch.txt, outputSed.txt, outputHru.txt, outputRsv.txt, outputPst.txt) in [ArcSWAT Project]\Scenarios\Default\txtinout. The result files would be read line by line and string parser is used to extract data values for each column, which would be slightly different for different SWAT version.
- Copy the data from the generated text files to tables in SWATOutput.mdb though “Select INTO” statement.
- Delete all the text files generated in step 3.
Most of the time would be spent at step 3 and step 4, where the data format is converted twice: one from SWAT format to text format and the second from text format to mdb format, where the first conversion would probably cost more.
So, question is why doesn’t SWAT just generate the results in text format required in step 3. Are there any advantage the current result format over text format? What’s no doubt is generating results in text format would greatly save time on this import function.
The result format would also have impact on SWAT_CUP, which would read the specific results from result files after each simulation to calculate the objective functions. From my experience, sometimes the time spent on result reading is even longer than the simulation time!
For SWAT result analysis, I would usually want outputs for a specific element (hru, subbasin or reach, etc.) in a specific time period. It’s a query process and would gain the best performance in a database, e.g. mdb. This may be the thought under the “Import Files to Database” function. It’s also true for SWAT_CUP. So, why not just generate the outputs in a database format directly in SWAT model? Thus, we don’t need to spend extra time to convert the format and it would be a lot easier to do the result analysis, especially for daily outputs.
The Makefile is updated again. Main changes are:
- Don’t compile modparm.f any more to keep SWAT codes unchange.
- Don’t generate separated Makefiles for debug and release any more. A single Makefile is generated instead to include four make targets: debug32, debug64, rel32 and rel64, which matches the four official SWAT executables.
- 64-bit build added to the Makefile.
No Need to Modify main.f any more
In previous version of Makefile, to compile SWAT successfully, the first line of main.f (include ‘modparm.f’) must be comment/deleted, which is not so convenient but not so bad.
It has been found that the problem is in the compilation of modparm.f and main.f. The parm.mod would be generated when either modparm.f or main.f is compiled. The key here is the effect of include statement., which could be found in gnu website.
The effect of the INCLUDE directive is as if the included text directly replaced the directive in the source file prior to interpretation of the program.
So, include ‘modparm.f’ means adding all the contents of modparm.f to main.f, i.e. all the variables are also defined in main.f. If both of modparm.f and main.f are compiled to object files and used to in the link operation, all the variables would be defined twice and the linker would give error message shown below.
Solution is just very simple: don’t compile modparm.f at all. Thus, all the variable would be just defined in main.f and include ‘modparm.f’ doesn’t need to be comment/deleted.
A Single Makefile
The new Makefile would be put in the source codes folder rather than the debug and release folder. Sub-folders (debug32, debug64, rel32 and rel64) would be created to hold all the object files and mod file. The final executable files will be in the source codes folder and given different name similar as official SWAT executables. More details are list in the following table.
|Command||32-bit or 64-bit||debug or release||executable name||Comment|
|make debug64||64||debug||swat_debug64||Doesn’t support by MinGW|
|make rel64||64||release||swat_rel64||Doesn’t support by MinGW|
64-bit build is added to the Makefile though flag -m64, although MinGW doesn’t support it. To compile 6-bit SWAT, either use MinGW-w64 or Rtools instead. More details would be published shortly in an integrated document.
The SWAT Makefile is updated again. Underflow flag is removed to get same results as official SWAT.
In an attempt to run SWAT (rev 615) in Eclipse and compare with official SWAT, although official SWAT could run to end without problems, Eclipse-SWAT stops running due to underflow (erroneous arithmetic operation).
The underflow happens in subwq.f Line 88.
wtmp = 5.0 + 0.75 * tmpav(j)
tmpav is average air temperature on current day in HRU
From the Expression window, the value of tmpav(j) is 4.6281851e-038. The underflow should happen when 0.75 * tmpav(j) is calculated.
The fact that official SWAT could run to end means underflow is ignored, i.e. the compilation flag for underflow is turned off. As mentioned in previous post SWAT Makefile Updated – Stop running when overflow happens, following flag is used to stop SWAT running when invalid, zero, overflow or underflow happens.
To run Eclipse-SWAT successfully, only need to remove underflow flag and re-compile the source codes, which will be become as following format.
After that, Eclipse-SWAT could run to end and get exactly the same results as official SWAT.