SWAT Output Viewer – Export Annual Result to CSV File

Some research focus on the nutrient load at the outlet. An annual load table would be helpful. With SWAT Output Viewer, the table could be exported to a CSV file.

The Export button is located in the toolbar besides the help button.

Export Annual Button

To export the annual TP load, select the most downstream reach in the reach view and select TOT_Pkg in the variable list.

ExportAnnualSelection

Click the Export Annual button and select the destination folder, the annual data will be exported to a csv file. An example file is shown below.

Export Annual Result

Advertisement

SWAT Output Viewer – Switch Time for Thematic Map

The thematic map in SWAT Output Viewer is able to show data of three summary types: single time step, annual and average annual. For single time step, it could be each day, each month and each year depending out the configuration of the outputs.

Thematic Map Summary

When the single time step option is selected, the time could be switched by double-clicking on the data record in chart table as shown below where monthly result is used. The time is also shown in the in the status bar on the bottom left corner. Note that, this only affect the thematic map. The chart would be affected.

Switch Time

An Interface to Quickly View SWAT Ouputs

User ManualSWATOutputViewerManual_v0.1

Installation Package: Download from Google Drive

SWAT Output Viewer is a Windows application designed to quickly extract data from SWAT outputs and display them on thematic map or/and in time series graph. The main features includes:

  • Thematic map for subbasins and reaches to show spatial distribution;
  • Time series graph with ability to compare to observed data;
  • Quick performance statistics against observed data;
  • Quick comparison to observed data and/or outputs from other model engine and scenario;
  • Selecting SWAT components on map;
  • Ability to work with ArcSWAT projects;
  • Help functions to run simulation and check model files.

The main interface is shown below.

SWAT Output Viewer.png

Quickly Check SWAT Model Performance with SWAT Output Viewer

During SWAT model calibration, the simulated flow, sediment, nitrogen and phosphorus results are frequently compared with observed values to evaluate the model performance. SWAT Output Viewer has the ability to quickly calculate several model performance indicators on-the-fly (as shown below) once the model simulation is done. Performance View - SWAT Output Viewer

To be able to compare with observed data, the observed data needs to be imported first, which could be done in project view. Take flow data as the example. Observed flow data is available for reach 5. Then the observed flow data needs to be associated with the simulated flow from reach 5. To do this, select reach 5 on the map and chose flow (m3/s) from the Observation drop down list (as shown below). Then click the the Load button to load the observed data from selected file. The loaded data is then associated with the flow from reach 5. This process only needs to be done once.

Import Observed Data - SWAT Output Viewer

Once the observed data is loaded, it could be used to calculate the performance indicators. These indicators are automatically calculated and displayed in a table when entering the performance view as shown below. The default performance indicator is NSE. It can be change to R2, RMSE, Bias, etc. If observed data is available at more than one location or for more than one variable (flow, sediment, N and P), the performance indicator would be calculated for all the locations and variables and list in a table. The table could be sorted by any columns.

Performance Indictors - SWAT Output Viewer

Furthermore, the performance indicator of each year is also calculated when one row is selected in the table above, with which the “best” and “worst” year could be identified.

Yearly Performance Indictors - SWAT Output Viewer.png

For each year, the simulated and observed data is also plotted as shown below, where the simulated data is in read and the observed data is in green.

Simulated Observed Plot - SWAT Output Viewer.png

In SWAT Output Viewer, the performance indicators are available simply by clicking once without generating any additional files. It’s quite useful when the model is calibrated manually.

 

ArcSWAT Error – Try inserting or pasting less data: IN, mWriteInputFiles.sol

If you get error messages like below, you come to the right place.

ArcSWAT_2016-01-18_20-12-36

It means you are trying to write more data than the data table can hold. For example, you will get this message if trying to write string “I’m a long string” to a text field that could be 4 letter long.

It seems ArcSWAT don’t check the length of the data against the maximum length of the field when writing those data tables. Whenever you have a longer string, you will get this error message.

Solution is simple: either make your string shorter or increase the length of those fields. As we don’t want to change our data, the latter is better. But how?

The secret is in SWAT2012.mdb. It has tables with name like ***rng, e.g. solrng and hrurng. These tables defines the structure of those data tables we need in our project database, including the maximum length of a text field. Take table solrng as example as shown below. Each row defines one column in table sol. Amost of all these columns, SOIL is defined as TEXT(4) which means it’s a text column and could have maximum length of 4 letters. The column SOIL, SLOPE_CD and SNAM is similar.

Access_-_SWAT2012__Database-_CdevswatVivienT_2016-01-18_20-30-36

Below is a list of these template tables and the corresponding table in project database. As you could see, most of the tables in project database is generated based on their template tables.

Template Table in SWAT 2012 Corresponding Data Table in Project Database
ciorng cio
croprng crop
dpdrng dpd
fertrng fert
gwrng gw
hrurng hru
mgt1rng mgt1
mgt2rng mgt2
opsrng ops
ovnrng ovn
pestrng pest
pndrng pnd
PPIrng PPI
PPrng PP
resrng res
ribrng rib
rterng rte
seprng sep
septwqrng sept
sfbrng sfb
solrng sol
subrng sub
swqrng swq
tillrng till
urbanrng urban
wgnrng wgn
wpdrng wpd
wusrng wus
wwqrng wwq

You may have know the solution of the error. Yes, we could increase the length of the text fields by changing their definition, i.e. change TEXT(4) to TEXT(n) where n is a number that big enough to hold all possible strings, say 100. We could usually get which table has problem, like the one we give at the beginning. It says the sol table has problem. So we go to the solrng table and increase the length limitation of all possible text columns and then try to write the data table again. If you don’t want to guess which column should be changed, just change all of them to 100. It should be good enough for most of the case.

Hope you find this helpful and happy SWAT modelling.

SWAT Bug in Reading CHM file

SWAT Bug in Reading CHM fileIf you are dealing with more than 6 soil layers, be cautious on the water quality outputs. A bug in SWAT would have impact on the initial N/P in soil and in turn would have impact on water quality in the main channel.

Description

Initial soil N/P could be set in CHM files for up to 10 soil layers. By default, NO3, organic N and organic P is set as 0 mg/kg, which means SWAT would calculate the initial concentration based on organic carbon and depth. Soluble P is set as 5 mg/kg by default.

 Soil Layer               :           1           2           3           4           5           6           7           8           9          10

 Soil NO3 [mg/kg]         :        0.00        0.00        0.00        0.00        0.00        0.00        0.00        0.00        0.00        0.00

 Soil organic N [mg/kg]   :        0.00        0.00        0.00        0.00        0.00        0.00        0.00        0.00        0.00        0.00

 Soil labile P [mg/kg]    :        5.00        5.00        5.00        5.00        5.00        5.00        5.00        5.00        5.00        5.00

 Soil organic P [mg/kg]   :        0.00        0.00        0.00        0.00        0.00        0.00        0.00        0.00        0.00        0.00

 Phosphorus perc coef     :       10.00       10.00       10.00       10.00       10.00       10.00       10.00       10.00       10.00       10.00 

Following codes are used to read above values in readchm.f, where mlyr is the maximum number of soil layers.

      read (106,5100,iostat=eof) (sol_no3(j,ihru), j = 1, mlyr)

      read (106,5100,iostat=eof) (sol_orgn(j,ihru), j = 1, mlyr)

      read (106,5100,iostat=eof) (sol_solp(j,ihru), j = 1, mlyr)

      read (106,5100,iostat=eof) (sol_orgp(j,ihru), j = 1, mlyr)

      read (106,5100,iostat=eof) (pperco_sub(j,ihru), j = 1, mlyr)

      ………………………

      5100 format (27x,10f12.2) 

The problem is on mlyr. It’s not the actual number of soil layers, which is sol_nly. It’s value could exceed 10 since SWAT adds 4 on top of it in getallo.f shown below.

!!    septic change 1-28-09 gsm

      mlyr = mlyr + 4

!!    septic change 1-28-09 gsm

For my case, the mlyr is 14 and SWAT would try to read 14 values from CHM file for initial soil N/P. As there are only 10 values in each record, SWAT would go to next record to get additional 4 values. Thus, one read function would read 2 data records in CHM file. The values it’s reading are not the values they are set. Organic N would be 5 mg/kg rather than 0 mg/kg. This will cause much less organic N compared to the one calculated from organic carbon.

Solution

The solution would be simple: replace mlyr with sol_nly. sol_nly is the actual number of soil layers and has been used in read soil parameters from SOL files (readsol.f). It never exceeds 10.

Web-GIS for Water Distribution System Using ArcGIS for Server, .NET, Flex and SQL Server

Copyright: I have got the permission from project partners to publish these information. The copyrights of the data and related software are hold by all project partners. All the information here is for demonstration purpose only. It can’t be used for any other purpose. For any concerns, please don’t hesitate to contact me.

This is an ongoing project I have been working on for 7 years staring from 2007 when I was a PhD student in Tianjin University, Tianjin, China. The project kept evolving along with the development of web technologies and ArcGIS for Server. From Web ADF for .NET to ArcGIS API for Flex, we are trying to make the web GIS powerful and easy to use.

PROJECT OVERVIEW

When: 2007-present

Where: A provincial capital city in Northern China

Team: School of Environmental Science and Engineering, Tianjin University, China

Objective: Create an online GIS system for staffs located in various offices to manage water distribution system data and real-time monitoring data

Phases: Phase I: 2007~2009, Phase II: 2010~2012, Phase III: 2013~present

ROLES AND RESPONSIBILITIES

  1. Team leader, system designer and developer
  2. Communicate with client for detailed user requirement analysis
  3. Design the web GIS application architecture and develop most of the system with .NET and Flex
  4. Purchase, assemble and setup the IBM server to host map services and web services
  5. Design Geodatabase and configure SQL Server and ArcSDE
  6. Create and manage map services with ArcGIS for Server
  7. Deploy and test the system
  8. Customer support and system maintenance

BACKGROUND

Reclaimed water, as the less expensive alternative to portable water, has been introduced to many cities in China. Unlike the water distribution system for tap water built 100 years ago, the water distribution system for reclaimed water is constructed in digital era and its information (geospatial and non-spatial) could be established when it’s being constructed. The city recognized the advantage and needs of a distributed GIS system when they are building the water distribution system and started the project from 2007.

TECHNOLOGIES USED AND THREE PHASES

As staffs are located in different offices around the city, a distributed web-GIS system is more suitable for data management. ArcGIS for Server has been around for a year that time and was chosen as the main platform for the system.

The Geodatabase was created first to meet the data management requirements. Geometric network was utilized to simulate the network connection and help further analysis. GPS units were purchased to help field data collection. All data were stored in a SQL Server database through ArcSDE. Map services were created using ArcGIS for Server and a customized application was developed as the main interface to the GIS data for all staffs.

The project has gone through three phases. Web ADF for .NET was the framework used in phase I and was replaced with ArcGIS API for Flex in phase II. It’s going to the third phase from 2013 and more analysis functions would be added. With Web ADF for .NET, most of the functions were implemented through customized tasks using ASP.NET. After transferring to ArcGIS API for Flex, all previous functions were re-wrote as ASP.NET web services. Note that the client application was built with Flex(actionscript) directly rather than utilizing ArcGIS Viewer for Flex. It took more efforts but would give more flexibility on interface design and functionalities.

The system architecture is shown below. The client application was built with Flex(actionscript). Some basic GIS functions were implemented with ArcGIS API for Flex, e.g. identify and query. Other more complicated analysis requests would be given the ASP.NET web service in the service side, where ArcObjects was used to manipulate geospatial data residing in map services provided by ArcGIS for Server. There are two SQL Server databases for geospatial data and real-time monitoring data respectively. With limited budgets, the web service and map service was in one IBM server but could be distributed in different servers in the future.

SCREENSHOTS

Main Interface

The main interface includes menus, toolbar, table of content, express location list, status bar and the map area.

Valve Search (Network Analysis)

Valve search interface is shown below with just two buttons: the first one is used to choose the location where the burst happens and the second one is the submit button to start analysis.

The network analysis is utilized in this process to make sure no water could flow into the affected area when the chosen valves are closed.

It would give all the values that needs to be closed for emergency maintenance and all the residences affected to be notified through phone call or text message. The valve list would be sent to field workers.

The affected area is also shown with highlight color to be printed out and taken to field.

Real-time Data (Customized Graphics)

It will display real-time monitoring data on map and/or in a movable window with customizable setting.

To display the real-time data on top of the feature, a dedicated graphic layer is added and customized graphics
are added for each feature where the real-time monitoring data generates. The background and text color, refresh frequency could be configured through the setting window and the config file.

Click the graphic on map or list item to open following operation window to see real-time and historical data in table/chart, checkout warning information and perform some analysis.

Checkout historical data in chart and table

Query with Spatial and Attribute Condition

The main interface for query is shown below to define the spatial and attribute condition.

Define a rectangle area (green) as the search area

Define the attribute condition: Pipe Diameter = 200mm

Display the results in a table with the ability to export to Excel file

Summarize Features on Attributes

This functions summarizes features on attributes, which is similar as the summarize function in ArcMap (shown below) but with more flexibility.

The main interface for summarize function is shown below, where user has chance to choose layer, more than one summary fields, field group method (one value one group, range group and free group for numerical fields) and summary statistics option (count or summation of a numerical field). In following example, choose pipe layer to analyze and select two fields to summarize (diameter and material). One value one group method is used for pipe material field as it’s a text field, i.e. one material will be one group.

Three groups are defined for pipe diameter: 0~500mm, 500~1000mm and 1000~2000mm.

All the pipes would be grouped by diameter and material and the total length of pipes in each group would be calculated and given in the following results window, where summary information would be given in table and different types of chart (line, column and pie).

Clipe and Export

This function would generate an output file for given part of the map with given scale. The main interface is shown below, where user has the chance to define a rectangle area, the scale and the output file format. The file could be downloaded as soon as it’s generated successfully.

Measure

The measure function would give the total length of a user-defined polyline and the area of a user-defined polygon.

An Interface for Watershed Evaluating of Agricultural BMPs Using SWAT, C#, DotSpatial and SQLite

Copyright: I have got the permission from project partners to publish these information. The copyrights of the data and related software are hold by all project partners. All the information here is for demonstration purpose only. It can’t be used for any other purpose. For any concerns, please don’t hesitate to contact me.

I have been working on various projects and have developed several interesting products. I guess they could be part of my “portfolio”. From today, I would try to summarize some of them and post here. The very first one is an interface developed in 2012 when I was a post-doctoral in University of Guelph, Ontario, Canada.

Click here to download a PPT for this project

OVERVIEW

When: 2012

Where: South Tobacco Creek watershed near Miami, MB

Team: Watershed Evaluation Group, University of Guelph

Project: Watershed Evaluation of Beneficial Management Practices (WEBs), AAFC

Objective: Develop an interface to create and evaluate what-if agricultural BMP scenarios to help conservation districts/authorities gain understanding on water quantity and quality effects and allocate limited resources for BMP implementation

BACKGROUND

Agricultural best management practices (BMPs) has been applied in Canada to help reduce nitrogen and phosphorus coming from farm fields. With limited budget and clear water quality goal, conservation districts/authorities need to choose the most cost-effective BMPs and their locations. Managers needs a decision support system (DSS) to help them understand the impact of various available BMPs on hydrology and economy, i.e. what-if scenarios, and then make proper decisions.

The Watershed Evaluation of Beneficial Management Practices (WEBs) program was a successful nine-year Government of Canada initiative to determine the economic and water quality impacts of selected agricultural beneficial management practices (BMPs) at nine watershed sites across Canada. The interface was developed as part of the program for the South Tobacco Creek watershed located near Miami, Manitoba.

FUNCTIONS

  1. Create scenarios to add, remove and configure various BMPs
  2. Run SWAT and economic model for each scenario
  3. Display SWAT, economic and integrated results on field, farm, subbasin and watershed level with map and chart

TECHNOLOGIES USED

The interface is a Windows form application developed using C#. The main part of the interface is the map area implemented with DotSpatial map control. Microsoft chart controls are used for all charts.

In model side, to enable fast access to SWAT results, SQLite is added to SWAT source codes to write all results into a SQLite database with fixed structure including tables, views and indexes. A scenario definition file is also generated as the bridge between the interface and SWAT model to exchange data. Mix-language compilation (C and Fortran) is required to compile the modified SWAT codes.

The system architecture is show below.

ROLES AND RESPONSIBILITIES

  1. Design the main architecture and choose required technologies
  2. Design the GUI and code with C#
  3. Design the interface between GUI and SWAT with the scenario definition file
  4. Modify SWAT sourced codes to support SQLite results and scenario definition file

SCREENSHOTS

Project tree on the left to navigate different views, including project, scenario, BMPs and results

Project View

A project represents a watershed. It includes the geospatial and model information.

Scenario View

A scenario is a combination of various BMPs including small dams, holding ponds, grazing, tillage and forage conversion. SWAT and economic model could be run for each scenario. Results could be viewed after the simulation is done.

Small Dam View

Select/deselect small dam on map or from the list on the right to enable/disable them in model

Tillage View, Field Level

Select/deselect fields on map or from the list on the right to apply tillage. Farm level and subbasin level is also supported.

Result View, SWAT Results

  • Display results with different colors for polygon and different sizes for point
  • Select a feature to view time series in chart at the bottom
  • Control result display using the right panel

Result View, Economic Results

Result View, Integrated Results

  • Cost-effectiveness, i.e. the amount of reduction (on water, sediment, N or P) per $1000 between two scenarios.
  • Most valuable for conservation districts and authorities

Result View, Off-site Integrated Results

Off-side is for the result at the watershed outlet and is good for whole watershed evaluation.