C-SWAT: The Soil and Water Assessment Tool with consolidated inputfiles in alleviating computational burden of recursive simulations$

Haw Yen a,c,n, Mehdi Ahmadi b, Michael J. White c, Xiuying Wang a, Jeffrey G. Arnold c

a Blackland Research & Extension Center, Texas A&M Agrilife Research, 720 East Blackland Road, Temple, TX 76504, USAb Spatial Science Laboratory, Texas A&M University, 1500 Research Plaza, College Station, TX 77843, USAc Grassland, Soil & Water Research Laboratory, USDA-ARS, 808 East Blackland Road, Temple, TX 76502, USA

a r t i c l e i n f o

Article history:Received 17 March 2014Received in revised form15 May 2014Accepted 31 July 2014Available online 8 August 2014

Keywords:SWATAuto-calibrationConsolidated inputsParallel processingShuffled complex evolution

a b s t r a c t

The temptation to include model parameters and high resolution input data together with theavailability of powerful optimization and uncertainty analysis algorithms has significantly enhancedthe complexity of hydrologic and water quality modeling. However, the ability to take advantage ofsophisticated models is hindered in those models that need a large number of input files, such as the Soiland Water Assessment Tool (SWAT). The process of reading large amount of input files containing spatialand computational units used in SWAT is cumbersome and time-consuming. In this study, theConsolidated SWAT (C-SWAT) was developed to consolidate 13 groups of SWAT input files from subbasinand Hydrologic Response Unit (HRU) levels into a single file for each category. The utility of theconsolidated inputs of model is exhibited for auto-calibration of the Little Washita River Basin (611 km2).The results of this study show that the runtime of the SWAT model could be reduced considerably withconsolidating input files. The advantage of the proposed method was further promoted with applicationof the optimization method using a parallel computing technique. The concept is transferrable to othermodels that store input data in hundreds or thousands of files.

& 2014 Elsevier Ltd. All rights reserved.

1. Introduction

The Soil and Water Assessment Tool (SWAT) (Arnold et al.,1993) is a continuous-time, daily-based and semi-distributedwatershed simulation model developed in prediction of hydrologicand water quality processes. The SWAT model formulates thenatural watershed system by constructing the stream network,categorizing soil types, and dividing land cover into groups byapplying the concept of Hydrologic Response Units (HRUs)(Neitsch et al., 2011). SWAT is being used extensively in a widerange of water use and water quality applications in the UnitedStates and around the world. These include total maximum dailyloads (TMDL) analysis (Borah et al., 2006; Harmel et al., 2010;Moriasi et al., 2012), assessment of conservation practices (Liewet al., 2007; Osorio et al., 2014), and impact analysis of climate andland use changes (Chiang et al., 2010; Daggupati et al., 2011). Inaddition, spatial scale of the SWAT model applications ranges from

regional scales (Bosch et al., 2011) to continental scales (Pagliero etal., 2012) and other relevant studies can be found in literature(Hoque et al., 2012; Seo et al., 2014).

The ever increasing interest in developing models with largerspatial scales using high resolution input data usually comes atthe expense of a higher computational demand (Tolson andShoemaker, 2007; Yen, 2012). With the need to incorporate moreparameters in the SWAT model to represent a broader range ofhydrologic and water quality processes, complexity of the modelstructures has also increased (Yen et al., 2014a; Yen et al., 2014b).Most parameters in the SWAT model cannot be determined byfield measurements directly (Arnold et al., 2012). Consequently,according to the past observations of hydrologic and water fluxes,the performance validity of the highly nonlinear and potentiallynon-unique solutions in the SWAT model usually requires compu-tationally intensive and iterative processes, including sensitivityanalysis, parameter estimation, and uncertainty analysis (Ahmadi etal., 2014). Iterative processes usually require a large number ofsimulations, a prohibitively long computational time, and a largeamount of computational resources (Schuol et al., 2008).

In SWAT, all model inputs and outputs are contained in a singledirectory, referred to as TxtInOut hereafter, in easily accessible,well documented text based formats. This directory contains ahierarchy of files pertinent to various spatial and computationalunits used in SWAT, including the basin, subbasins, and HRUs. The

Contents lists available at ScienceDirect

journal homepage: www.elsevier.com/locate/cageo

Computers & Geosciences

http://dx.doi.org/10.1016/j.cageo.2014.07.0170098-3004/& 2014 Elsevier Ltd. All rights reserved.

☆Software availability: Haw Yen, scientist & model developer at the BlacklandResearch and Extension Center, Texas AgriLife Research, completed the develop-ment in FORTRAN. The open-source code is available from Haw Yen, 720 E.Blackland Research Road, Temple, TX 76502, USA. Windows 7 or XP and anyFORTRAN complier are required.

n Corresponding author. Tel.: þ1 254 774 6004.E-mail address: hyen@brc.tamus.edu (H. Yen).

Computers & Geosciences 72 (2014) 221–232

majority of files in the TxtInOut are associated with the smallestcomputational units of the SWAT model, the HRUs. Physical andgeochemical characteristics of each HRU are included in severalseparate input files, thus when the watershed model is delineatedin a finer resolution, the number of HRUs and, accordingly, thenumber of files increases proportionately. The consecutive process ofthe opening–reading–closing of files is a time-consuming procedureduring the parameter estimation, sensitivity and/or uncertaintyanalysis, and SWAT simulations. In addition, there is a certain amountof overhead to locate each file within the computers file system, andto reposition the mechanical components within a hard disk to readthat file. This overhead time increases considerably as the number ofHRUs increases. Therefore, a SWAT model with a large spatial extentand fine simulation units can be very large and may contain manyfiles. Bosch et al. (2011) reported 94,000 SWAT input files forsimulating the Western Lake Erie Basin for flow and nutrientpredictions. National scale SWAT models, e.g., the Conservation EffectAssessment Project (CEAP)-National Cropland Assessment (Durianciket al., 2008; USDA-NRCS, 2009), have employed more than 1 millionfiles. Combined with the use of iterative calibration techniques,which may require hundreds or thousands of simulations, the filestorage paradigm can be unmanageable. In order to conduct auto-calibration for a 10,000 HRUs model, which requires approximately2 hours per simulation, with 1000 iterations would take more than80 days. Moreover, it is likely that the auto-calibration may not beable to reach completion/convergence within 1000 iterations. There-fore any iterative algorithms, which require a large number ofsimulations, are considered impractical for spatially high resolutionSWAT model applications. Joseph and Guillaume (2013) pointed outthat the ability to use advanced approaches, such as the BayesianMarkov chain Monte Carlo (MCMC) framework, is hindered inmodels with a large number of input files, such as SWAT.

A number of research efforts have sought to reduce computa-tional time requirements associated with large scale environmen-tal modeling (Duan et al., 1992; Tolson and Shoemaker, 2007;Vrugt et al., 2009; Yen, 2012). Despite the fact that commonly useddistributed models have had two decades of development efforts,most efforts to reduce computational time have either beendirected toward using metamodels (Johnson, 2013) or runningmodels in parallel (Vrugt et al., 2009). The trained artificial neuralnetworks (ANNs) and a support vector machine (SVM) weredeveloped as surrogate models to approximate SWAT predictions,saved 20–50% in computational time. Other efforts in applicationof parallel processing for calibration and uncertainty analysis tothe SWAT model include (Rouholahnejad et al., 2012; Whittaker,2004; Yalew et al., 2013; Zhang et al., 2013). In application of theparallel computing, iterative process is split into multiple sub-processes, which can run simultaneously on different computa-tional nodes, greatly reducing computational time. Growth ofparallel computing systems and programming techniques sparkedresearch on efficiently solving complex, high dimensional compu-tational problems (Brazier et al., 2000; Freer et al., 2004).

The core software architecture and inputs structure used in SWAThas largely remained unchanged in the last decade. Although, theavailability of highly detailed input data has dramatically increased,spurring the development of very large SWAT models. Researchersare seeking to utilize these detailed data with the applications ofSWAT in conjunction with auto-calibration optimization techniquesunder more affordable computational effort (Yen, 2012; Yen et al.,2014a). Therefore, the primary goal of this paper is to present aconceptually simple, robust method for enhancing the computationalspeed of the SWAT model, using tools to which modelers haveimmediate access. With the proposed work presented in this study,we expect to reduce barriers to the use of potentially prohibitivealgorithms/analyses for model applications with spatially high reso-lution details. Specifically, the objectives of this study are to

(1) modify SWAT input structure so that all HRU and subbasin levelinput files were consolidated into a single file for each category (e.g.chemical, ground water, soil) for the modified SWAT, referred to as C-SWAT hereafter, and (2) test the utility of re-structured inputs incombination with a parallelized Shuffled Complex Evolution (SCE)optimization algorithm. The parallelized SCE algorithm was alsocoded for the original SWAT model and the efficiency of C-SWATwas compared with the original SWAT through a computationallyintensive auto-calibration of streamflow for the Little Washita RiverBasin (LWRB) in Oklahoma, USA.

2. Methods and materials

2.1. Watershed model description: Soil and Water Assessment Tool

The Soil and Water Assessment Tool (SWAT) (Arnold et al.,2012) is a process based, distributed parameter, continuous time,and long-term watershed model that runs on a daily time step. Itsubdivides a watershed into subbasins connected by a streamnetwork, and further delineates HRUs consisting of unique com-binations of land cover and soils in each sub-basin. Watershedprocesses simulated by SWAT include snow accumulation, snowmelt, evapotranspiration, infiltration, percolation losses, surfacerunoff, and groundwater flows (Arnold et al., 2012). SWAT cansimulate major nutrient processes within a watershed. Nutrientsand sediment are introduced into the main channel throughsurface runoff and lateral flow and transported downstream withchannel flow. Nutrient transformations in the stream are con-trolled by the in-stream water quality component of the modelthat is adapted from the QUAL2E in-stream water quality model(Brown and Barnwell, 1987). More detailed description of thehydrologic sediment and nutrient components of SWAT can befound in Arnold et al. (2012).

2.2. Consolidating HRU and subbasin level input Files

SWAT users normally use ArcSWAT (Winchell et al., 2008), theArcGIS-based user interface, to automate generation of therequired inputs of SWAT model. ArcSWAT utilizes ArcGIS (ESRI,Redlands, California) to calculate all the GIS-based input data suchas soil, land use, and topographic characteristics of the studywatershed. These data together with user-defined managementand other inputs are stored in the Access database file Watershed.mdb. The Watershed.mdb file generated by ArcSWAT contains allessential SWAT input data, which are eventually written intoSWAT required input files. In Table 1, seven categories (n.chm, n.gw, n.hru, n.sep, n.mgt, n.ops, and n.sol) for each HRU and sixcategories (n.pnd, n.rte, n.subn. swq, n.wgn, and n.wus) are attrib-uted for each subbasin.

To represent the multitude of HRUs in the subbasins, the 13categories in HRU and subbasin levels may result in enormousnumber of input files for the original SWAT model. In this study,the Consolidated SWAT, referred to as C-SWAT hereafter, wasdeveloped to reduce hundreds or thousands of input files corre-sponding in each HRU or subbasin levels. The cumbersome processis simplified in C-SWAT, where the original SWAT code wasmodified to read only 13 consolidated files at the HRU andsubbasin level. Therefore, the adjustment at the HRU and subbasinlevel only needs to handle a maximum of 13 files during auto-calibration. The 13 files can be easily created directly from theWatershed.mdb file described above by simply copying and past-ing data (see Appendix A). In addition, MATLAB (Mathworks, 2013)codes was also developed to automatically convert inputs fromoriginal SWAT format to the C-SWAT structure (available uponrequest). The source code applied in this study was based on

H. Yen et al. / Computers & Geosciences 72 (2014) 221–232222

SWAT2009 (rev477); however it can be integrated into the latestSWAT2012 code (rev610) with no major issues because the basicstructure in opening/reading/closing major input files remainedthe same. In this study, four major structures of TxtInOut aredescribed as follows. The details of consolidating the input files atthe HRU and subbasin levels can be found in Appendix A.

2.2.1. Structure IStructure I is associated with ten consolidated files (n.gw, n.hru,

n.sep, n.sol, n.pnd, n.rte, n.sub, n.swq, n.wgn, and n.mgt files exceptthe operation management section). As shown in Fig. 1 (illustratedfrom a n.hru file), the format of Structure I is that each row of aninput file contains only one representative parameter value. For

parameters in some HRU and subbasin level files, a matrix for thespecific parameter in the original source code is a one-dimensionmatrix since at least one parameter value will be assigned to asingle file.

2.2.2. Structure IIStructure II can be found in six consolidated files (n.chm, n.sol, n.

rte, n.sub, n.wgn, and n.wus). As shown in Fig. 2 (illustrated from an.chm file), the format of Structure II is that each row of an inputfile contains more than one representative parameter values. Forparameters in HRU level files, a matrix for the specific parameterin the source code is a two-dimension matrix.

2.2.3. Structure IIIStructure III can be only found in the lower part (operations) of

n.mgt files where the upper part of n.mgt files is in Structure I. Asshown in Fig. 3 (illustrated from a n.mgt file), the format ofStructure III is that each location has specific variables assigned,and the file has no fixed length. More detailed format of n.mgt filesis shown in Table 2. The operations section of the n.mgt uses thefirst four columns to schedule and define operations, the 5th to13th columns share 37 parameters in these nine columns to defineparameters associated with differing operation types (seeAppendix A). In the Watershed.mdb file, these 37 parameters formanagement practices are stored in 37 columns respectively.However, the parameter value will be zero or null if a specificparameter is not required for the row defining each operation.

2.2.4. Structure IVStructure IV can be only found only in n.ops files. As shown in

Fig. 4 (illustrated from a n.ops file), the format of Structure IV isthat each location has a specific variable assigned. The detailformat of n.ops files is shown in Table 3. The first four columnsare month (MON), day (DAY), year (IYEAR), and managementoperation number (MGT_OP). The 5–11th columns share 28

Table 1SWAT input files in HRU and subbasin levels.

SWAT input files

Structure Group

HRU level filen.chm IIn.gw In.hru In.mgt I/IIIn.ops IVn.sep In.sol I/II

Subbasin level filen.pnd In.rte I/IIn.sub I/IIn.swq In.wgn I/IIn.wus II

It is possible that a single SWAT input file withmore than one structure.

Fig. 1. Structure I: each row contains only one parameter value.

Fig. 2. Structure II: each row contains more than one parameter values.

H. Yen et al. / Computers & Geosciences 72 (2014) 221–232 223

parameters in these seven locations (see Appendix A). In theWatershed.mdb file, 28 parameters for management practices areavailable in 28 columns respectively.

2.3. Case study

The Little Washita River Basin (LWRB) (611 km2) is located insouthwestern Oklahoma (Fig. 5). The elevation of the basin ranges

between about 300–500 m. The bedrock exposed in the watershedconsists of Permian age sedimentary rocks and soil textures rangefrom fine sand to silty loam. The main land cover in LWRB is range,pasture, forest and cropland. The climate is characterized as moistand sub-humid with a spatially average, annual precipitation of760 mm and temperature of 16 1C.

A SWAT model was developed using a 10-m resolution digitalelevation model (DEM) (USGS, 2013), Cropland Data Layer 2012

Fig. 3. Structure III: MGT files.

Table 2Structure III: fixed locations for multiple parameters in *.mgt files (Neitsch et al., 2011).

MON DAY HUSC MGT_OP mgt1 mgt2 mgt3 mgt4 mgt5 mgt6 mgt7 mgt8 mgt9

Plant/begingrowingseason

– – 1 PLANT_ID – CURYR_-MAT

HEAT_UNITS

LAI_INIT BIO_INIT HI_TARG BIO_TARG CNOP

Irrigate – – – 2 – – – IRR_AMT – – – – –

Fertilizerapplication

– – – 3 FERT_ID – – FRT_KG FRT_SURFACE

– – – –

Pesticideapplication

– – – 4 PEST_ID – – PST_KG – – – – –

Harvest/killoperation

– – – 5 – – – CNOP – – – – –

Tillage operation – – – 6 TILL_ID – – CNOP – – – – –

Harvest operation – – – 7 – – – HARVEFF HI_OVR – – – –

Kill/end growingseason

– – – 8 – – – – – – – – –

Grazing – – – 9 GRZ_DAYS MANUR-E_ID

– BIO_EAT BIO_TRMP MANUR-E_KG

– – –

Auto irrigation – – – 10 WSTRS_ID – – AUTO_WSTRS

– – – – –

Auto fertilization – – – 11 AFERT_ID – – AUTO_NSTRS

AUTO_-NAPP

AUTO_NYR AUTO_EFF AFRT_SURFACE

–

Sweep operation – – – 12 - – – SWEEPEFF FR_CURB – – – –

Release/impound – – – 13 IMP_TRIG – – – – – – – –

Continuousfertilization

– – – 14 FERT_DAYS CFRT_ID IFRT_FREQ CFRT_KG – – – – –

H. Yen et al. / Computers & Geosciences 72 (2014) 221–232224

(USDA NASS, 2012), and Soil Survey Geographic database(SSURGO) (USDA NRCS, 2012). The watershed was subdivided into75 sub-basins and a total of 1109 hydrologic HRUs. Temperatureand precipitation data from 20 weather data stations were used.Overall, 20 SWAT parameters were selected that are relevant inregard to their ability to affect hydrologic fluxes and are typicallyused in model calibration of the SWAT models (Table 4). Dailystreamflow data was available at the watershed outlet from aUSGS gaging station (USGS gauge no. 07327550). In case study,simulations were done for daily streamflow calibration startingfrom 2006 through 2010 (5 years), including 1 year of warm-up.

2.3.1. Parameter estimation techniqueThe Shuffled Complex Evolution (SCE) method (Duan et al.,

1992, 1994) was used for parameter estimation for this C-SWATmodel. SCE is a global optimization algorithm that synthesizes the

concepts of deterministic and probabilistic, controlled randomsearch, competitive evolution, and complex shuffling approaches.SCE has been successfully used for calibration of the SWAT model(Sharma et al., 2006; Zhang et al., 2009). A general description ofthe steps for SCE method with n parameters, p complexes, and mpoints in each complex is given as follows (Duan et al., 1992; Duanet al., 1994): (1) generate sample: randomly sample s (¼ pm)initial population of parameter sets θ from the feasible parameterspace Θ and compute the criterion value at each point, (2) rankpoints: sort the s points with increasing criterion value, (3) parti-tion into complexes: partition the s points into p complexes; eachcontaining m points, (4) complex evolution: evolve each complexaccording to the competitive complex evolution (CCE), (5) shufflecomplexes: combine the points in the evolved complexes into asingle sample population, sort the sample population in order ofincreasing criterion value and shuffle the sample population into pcomplexes according to the procedure specified in Step (3), and

Fig. 4. Structure IV: OPS files.

Table 3Structure IV: fixed locations for multiple parameters in *.ops files (Neitsch et al., 2011).

MON DAY IYEAR MGT_OP P1 P2 P3 P4 P5 P6 P7

Terracing operation – – – 1 TERR_P TERR_CN TERR_SL – – – –

Tile drainage operation – – – 2 DRAIN_D DRAIN_T DRAIN_G DRAIN_IDEP – – –

Contouring operation – – – 3 CONT_CN CONT_P – – – – –

Filter strip operation – – – 4 FILTER_I FILTER_RATIO FILTER_CON FILTER_CH – – –

Strip cropping operation – – – 5 STRIP_N STRIP_CN STRIP_C STRIP_P – – –

Fire operation – – – 6 FIRE_CN – – – – – –

Grassed waterways operation – – – 7 GWATI GWATN GWATSPCON GWATD GWATW GWATL GWATSPlant parameter update – – – 8 CROPNO_UPD HI_UPD LAIMX_UPD – – – –

Fig. 5. Location of the Little Washita River Basin.

H. Yen et al. / Computers & Geosciences 72 (2014) 221–232 225

(6) Check convergence: if any of the pre-specified convergencecriteria are satisfied, stop the process; otherwise, return to Step(4). Given the current developments of parallel and distributedcomputing technologies, overall runtime can be reduced consider-ably for optimization methods that can utilize individual parallelprocessing units. The SCE method is inherently well suited forparallelization within each individual complex.

Schematic diagram of the calibration procedure of SWAT modelis depicted in Fig. 6. For consistency, 5000 model parameter setswere evaluated for all optimization configurations.

2.3.2. Objective functionsThe Nash–Sutcliff Efficiency (NSE) (Nash and Sutcliffe, 1970)

was used as the objective function during auto-calibration whereit measures the relative magnitude of the residual variancecompared to the observed data variance. It indicates how wellthe plot of observed versus simulated values fits a 1:1 line. Thecoefficient can range from �1 to a perfect match of þ1:

NSE¼ 1�∑ni ¼ 1ðyi�yiÞ2

∑ni ¼ 1Σyi�y2

ð1Þ

where yi and yi denote, respectively, the simulated and observedresponses for time step i, n is the number of observations, and ydenotes the mean of observed responses. NSE has been recom-mended for use by the American Society of Civil Engineers (ASCE)(ASCE, 1993) and is a commonly used statistical measure forcalibration of watershed models. Servat and Dezetter (1991) alsofound NSE to be the best objective function for reflecting theoverall fit of a hydrograph.

2.3.3. Implementation of the C-SWAT and parallel SCEIn case study, four major steps are conducted to implement

C-SWAT. Firstly, the SWAT project was created through ArcSWAT,which subdivided the watershed into 75 subbasins and a total of394 HRUs. This resulted in a total of 3148 (394�7þ65�6¼3148)files at the HRU and subbasin level for the original SWAT modelsaved in the TxtInOut project directory.

Secondly, the source data file watershed.mdb is opened andcreated input files for C-SWAT. This results in a total of 7 files at the

Table 4Selected SWAT parameters used in Morris sampling including lower bounds (LB) and upper bounds (UB).

Parameter number Parameter name Input file Description Unit Lower bound Upper bound

1 ALPHA_BF .gw Base flow alpha factor for recession constant 1/days 0 12 CH_KII .rte Fraction change in hydraulic conductivity in the main channel mm/h �0.01 5003 CH_NII .rte Manning's n value for the main channels – 0.01 0.34 CH_SII .rte Average slope of main channel along the channel length % �55 CN_F .mgt Fraction change in SCS runoff curve number % �10 106 FILTERW .mgt Width of edge-of-field filter strip m 0 1007 GW_DELAY .gw Groundwater delay time day 0 608 OV_N .hru Manning's n value for overland flow – 0.01 0.69 SFTMP .bsn Snow melt base temperature 1C �5 5

10 SLOPE .hru Average slope steepness % �10 1011 SLSUBBSN .hru Average slope length m 10 15012 SMFMN .bsn Minimum melt rate for snow mm/1C-day 0 1013 SMFMX .bsn Maximum melt rate for snow mm/1C-day 0 1014 SMTMP .bsn Snow melt base temperature 1C �5 515 SNO50COV .bsn Snow water equivalent that correspond to 50% snow cover mm 0 116 SNOCOVMX .bsn Minimum snow water content that corresponds to 100% snow cover mm 0 65017 SOL_K .sol Fraction change in saturated hydraulic conductivity % �50 5018 SURLAG .bsn Surface runoff lag time day 1 1219 TIMP .bsn Snow pack temperature lag factor – 0.01 120 DEP_IMP .hru Depth to impervious layer mm 1500 2500

StartT

Initialization

Initial Model Parameter Set

Statistics Calculation

Compare Simulated/Observed Data

Parameter Estimation Techniques

Termination No

Assign Model Parameters into TxtInOut

Open/Read/Write/Close Input Files

Conduct SWAT Model Runs

Open/Read/Close Input Files

Open/ Write/Close Output Files

Matching Simulation/Observation Data

Stop

Yes

Fig. 6. Schematic chart of calibration processes.

H. Yen et al. / Computers & Geosciences 72 (2014) 221–232226

HRU and 6 files at subbasin level for C-SWAT. Therefore, theC-SWAT project contained 98% fewer files than the original SWATproject (43 input files for C-SWAT and 3171 input files for originalversion of SWAT).

Third, 20 SWAT parameters relevant to hydrologic fluxes andtypically used for SWAT calibration (Arnold et al., 2012) wereselected for daily streamflow calibration. A good practice beforesubmission for auto-calibration is to conduct reasonable manualcalibration and/or use SWAT-Check (White et al., 2014), which canbe downloaded from the SWAT home page (http://swat.tamu.edu/)to investigate potential model inputs or setup issues.

And the last, SCE was configured to run on 1, 2, 4, 6, 8, 10, and12 parallel nodes (each model evaluation is assigned to a specificcore of CPU in computer) using both original and C-SWAT modelsto compare their computational efficiencies. The single programmultiple data (SPMD) construct was used to implement parallelcomputation of the SCE calibration algorithm. The SPMD constructdefines a block of code that runs in parallel on all the CPU cores(Mathworks, 2013). Speedup of each configuration was computedbased on its overall runtime and runtime of the calibration on asingle core of original SWAT model. Each of the parallel calibrationruns was repeated two times on the same machine (a total of2�7¼14 trials) and the average values were reported in thisstudy. For consistency, the runtime for a total number of 5000simulations was evaluated for each of the original SWAT andC-SWAT optimization configuration. Note that global optimizationalgorithms, such as SCE, may require a very high number ofsimulations for convergence and our purpose here was not topursue calibration results rather than to compare the computa-tional speed of C-SWAT vs. original SWAT.

2.4. Hardware configuration and implementation

The parallel algorithm implementation for SCE was configuredon a multicore server with two 6-core, Intels Xeons E5645 CPUswith overall 24 threats and 24 GB of RAM. The server was runninga 64 bit Windows Server 2008 R2 Enterprise. Both the originalSWAT (rev477) and C-SWAT models were run in parallel with theSCE optimization. The source code applied in this study can beintegrated into the latest SWAT code with no major issues. Inaddition, the parallelization can be used on a single machine withmultiple threads or processors. Therefore, anyone having a desk-top with multiple threads or processors has opportunities toconduct otherwise prohibitive high numbers of simulations byusing C-SWAT in parallel. The basic structure in opening–reading–closing major input files remained the same

3. Results and discussion

In average, calibration of the LWRB using C-SWAT model wasapproximately 30% faster than calibration using original SWAT. Fig. 7depicts the speedup obtained by a combined use of C-SWAT andparallel computing for calibration of the LWRB model. In all single andparallel configurations, C-SWAT improved overall runtime of thecalibration by 28–35%. As the number of parallel processors increased,calibration speedup also increased (Fig. 7); however, the observedspeedup was not linear. Comparison of calibration speedup usingoriginal SWAT model with 1:1 line, that is the ideal speedup showsthat calibration runs with more than 4 parallel processes tend todeviate from ideal line. For example, calibration with 8 and 12processes resulted in 6.8 and 8.9 times speedup, which are 14% and26% lower than the ideal speedup line, respectively. This loss ofspeedup may be attributed to the limited shared memory and limitedhard disk drive I/O workload limitation. In addition, adding moreprocessors resulted in increased idle time for processor cycles as they

wait for other parallel runs within each generation. Increasingprocessors will excessively degrade the parallel runs from its expectedideal speedup.

However, use of C-SWAT compensated for the loss of speedup.Observed speedup in all C-SWAT parallel runs was on or above theideal speedup line. Similar to the application of original SWAT,speedup of the calibration degraded from the ideal with more than4 parallel processes. The highest speedup rate was seen for singleserial run, with 34% speedup. The highest deviation from idealspeed line was observed for calibration with 4 parallel processors.Using 12 parallel processors, the actual performance of C-SWATwas compared with the ideal performance of standard SWAT.

Profiling a single simulation of original and C-SWAT showed thatconsolidated inputs reduced runtime for three major steps of calibra-tion, including (i) file copying, (ii) modifying parameters, and (iii)running SWATmodel, bymore than 36% (Fig. 8). The highest reductionwas seen in modifying parameter values in consolidated inputs whereruntime was reduced by 76% from 22 s to less than 5.5 s. SWATruntime was also reduced by less than 7%. Copying files during eachiteration was also faster in C-SWAT by 60%. Faster copying andparameter alteration was directly related to the consolidated inputsthat reduced the number of files for copying and reading/writingduring the calibration process. Faster C-SWAT run was also due to thelimited number of inputs. Depending on the size of the project andsimulation period, these results can be different.

Fig. 7. SWAT simulation speedup using C-SWAT and parallel computing. Speedupof each configuration was computed based on its overall runtime and runtime ofthe calibration on a single core of original SWAT.

Fig. 8. Comparison of runtime spent on each step of calibration for both originaland consolidated SWAT models.

H. Yen et al. / Computers & Geosciences 72 (2014) 221–232 227

4. Conclusion and future development of SWAT

Inputs of the SWAT were consolidated in C-SWAT and modelstructure was modified to reduce number of HRU and subbasinlevel files to only 13 files. Improvement of the modified structurewas presented in calibration of the streamflow data in the LittleWashita River Basin, Oklahoma, USA, using a parallelized ShuffledComplex Evolutionary algorithm. The calibration was examined ondifferent parallel processes ranging from 1 to 12 pools. The resultsshowed that a single simulation using C-SWAT was 30% faster thanthe original SWAT model in this specific case study. However,the computation effort can be further reduced in larger casestudies with higher number of input files. Application of C-SWATin a parallel computing platform decreased the runtime of thecalibration considerably. In addition, the proposed changes arepotentially beneficial to large scale studies, web-based technolo-gies and iterative computation in reducing the computationalburden.

The SWAT model is currently being restructured into a moremodular format to improve maintainability and to allow develop-ment by multiple scientists. The main data module used totransfer all data between all subroutines has been replaced byindividual modules for each spatial object including subbasins,HRUs, channels, and reservoirs. The only data passed betweenspatial object modules are data structures for: (1) flow, sediment,and related transport constituents, (2) weather, and (3) time. Amajor change in model structure is the separation of the HRU intoaquifer and soil/plant modules. In addition to the new spatialmodule structure, inputs are being transformed into a relationaldatabase format. To define HRUs, a new HRU data file points toweather, soils, and management information that defines the HRU.For example, all soils are appended to a single file and each HRUpoints to the appropriate soil within that file. We are alsorestructuring the process routines into subroutines with all inputand output variables defined as call arguments. This will facilitatemultiple developers working together in the same library ofsubroutines and facilitate parallelization.

Acknowledgments

The development of C-SWAT started from an independentresearch work conducted at the Colorado State University by Dr .Haw Yen. By knowing the motivation of Dr. Yen’s idea, Dr. Larry ARoesner, the founder of the SWMM model has supported theCompaq Visual FORTRAN 6.6 license with no hesitation. In addi-tion, contributions were made by Dr. John W Labadie and Dr.Mazdak Arabi with accommodating suggestions. Without all thehelping hands above, the manuscript will never be published.Later on, the development of C-SWAT was further supported bythe funding from the USDA-NRCS through the Conservation EffectsAssessment Project (CEAP). This study was also jointly supportedby the International S&T Cooperation Program from the Ministryof Science and Technology of China (2012DFA91530), the NationalNatural Science Foundation of China (41161140353, 91325302), theFirst Youth Excellent Talents Program of the Organization Depart-ment of the Central Committee of the CPC, and the FundamentalResearch Funds for the Central Universities (TD-JC-2013-2). Theauthors gratefully appreciate the constructive comments from thereviewers and associate editor that improved the presentation ofthe study. Thanks a lot!

Appendix A

Parameters included in each SWAT input files mentioned in Table 1are listed as follows.

I. [HRU Level Files] There are seven major HRU level files in theTxtInOut directory (see Table 1). The structure of open/read/close in the FORTRAN source code is very similar in n.chm, n.gw, n.hru, n.sep, and n.sol. On the other hand, the codingroutine it is quite different in n.mgt and n.ops where theoperation practices require specific loops in order to proceedthe simulation processes.

1. [HRU Level] CHM Files (n.chm) – Structure II[Subroutine Added] – allocate_allsystem.f/readallchm.f[Subroutine Modified] – main.f/hruallo.f/modparm.f/readsub.f/readchm.f

(1) Physical groupSOL_NO3(1–10), SOL_ORGN(1–10), SOL_SOLP(1–10), SOL_ORGP(1–10)

(2) Chemical groupPESTNUM(1–10), PLTPST(1–10), SOLPST(1–10), PSTENR(1–10)Parameters in n.chm files can be categorized into two groups:physical and chemical characteristics (Arnold et al., 2011).There are 40 inputs (4 parameters with 10 layers each) inthe first group and 40 (4 parameters with 10 differentpesticide if assigned) in the second. In the first group, eachparameter has 10 values according to the layer number (soillayer from 1 to 10). In the second group, each parameter mayhave more than one value according to the pesticide applied(the maximum is ten types of pesticide). In this case, total 80parameters (see Appendix A) in the n.chm files are allocated inthe “chm” table of the Watershed.mdb file by the order of HRUnumber. In C-SWAT, parameter information of CHM files isread from a single file named allchm.txt with inclusion of allinformation from the “chm” table of the Watershed.mdb.Parameter information will be first read by subroutine read-allchm.f and saved in a single matrix. Next, parameter infor-mation originally read in the subroutine readchm.f will besubstituted by passing values from the newly generated matrixinstead of open/read/close each n.chm file.

2. [HRU Level] GW files (n.gw) – Structure I[Subroutine Added] – allocate_allsystem.f readallgw.f[Subroutine Modified] –modparm.f/readsub.f/readgw.fSHALLST, DEEPST, GW_DELAY, ALPHA_BF, GWQMN, GW_RE-VAP, REVAPMN, RCHRG_DP, GWHT, GW_SPYLD, SHALLST_N,GWSOLP, HLIFE_NGWParameters in n.gw can be categorized into unconfined andconfined aquifer (Arnold et al., 2011). A total of 13 parameters(see Appendix A) located in the n.gw files are allocated in the “gw”

table of the Watershed.mdb file by the order of HRU number. InC-SWAT, parameter information of GW files is read from a singlefile named allgw.txt with inclusion of all information from the“gw” table of the Watershed.mdb. Parameter information will befirst read by subroutine readallgw.f and saved in a single matrix.Next, parameter information originally read in the subroutinereadgw.f will be substituted from passing values from the newlygenerated matrix instead of open/read/close each n.gw file.

3. [HRU Level] HRU files (n.hru) – Structure I[Subroutine Added] – allocate_allsystem.f/readallhru.f[Subroutine Modified] – modparm.f/readsub.f/readhru.fHRU_FR, SLSUBBSN, HRU_SLP, OV_N, LAT_TTIME, LAT_SED,SLSOIL, CANMX, ESCO, EPCO, RSDIN, ERORGN, ERORGP,POT_FR, FLD_FR, RIP_FR, POT_TILE, POT_VOLX, POT_VOL,POT_NSED, POT_NO3L, DEP_IMP, EVPOT, DIS_STREAMParameters in n.hru files can be categorized into five groups:topographic characteristics, water flow, erosion, land cover,and digressional storage areas (Arnold et al., 2011). A total of24 parameters (see Appendix A) located in the n.hru files areallocated in the “hru” table of the Watershed.mdb file by theorder of HRU number. In C-SWAT, parameter information forthe HRU files is read from a single file named allhru.txt with

H. Yen et al. / Computers & Geosciences 72 (2014) 221–232228

inclusion of all information from the “hru” table of theWatershed.mdb. Parameter information will be first read bysubroutine readallhru.f and saved in a single matrix. Next,parameter information originally read in the subroutine read-hru.f will be substituted by passing values from the newlygenerated matrix instead of open/read/close each n.hru file.

4. [HRU Level] MGT files (n.mgt) – Structure I & III[Subroutine Added] – allocate_allsystem.f/readallmgt01.f/read-allmgt02.f[Subroutine Modified] – main.f/hruallo.f/modparm.f/readsub.f/readmgt.f

(1) Initialization inputsNMGT, IGRO, PLANT_ID, LAI_INIT, BIO_INIT, PHU_PLT, BIOMIX,CN2, USLE_P, BIOMIN, FILTERW, IURBAN, URBLU, IRRSC, IRRNO,FLOWMIN, DIVMAX, FLOWFR, DDRAIN, TDRAIN, GDRAIN,NROT

(2) Management operation schedules(i) Basic information

MONTH, DAY, HUSC, MGT_OP(ii) Operational practices

PLANT_ID, FERT_ID, PEST_ID, TILL_ID, GRZ_DAYS, WSTRS_ID,AFERT_ID, IMP_TRIG, FERT_DAYS, MANURE_ID, CFRT_ID, CUR-YR_MAT, IFRT_FREQ, HEAT_UNITS, IRR_AMT, FRT_KG, PST_KG,CNOP, HARVEFF, BIO_EAT, AUTO_WSTRS, AUTO_NSTRS, SWEE-PEFF, CFRT_KG, LAI_INIT, FRT_SURFACE, HI_OVR, BIO_TRMP,AUTO_NAPP, FR_CURB, BIO_INIT, MANURE_KG, AUTO_NYR,HI_TARG, AUTO_EFF, BIO_TARG, AFRT_SURFACEParameters in n.mgt files can be categorized into two groups:initialization inputs and management operation schedules(Arnold et al., 2011). In the first group, each HRU has onlyone input item (e.g. CN2: 83.00). A total of 22 parameters (seeAppendix A) located in the n.mgt files are allocated in the“mgt1” table of the Watershed.mdb file by the order of HRUnumber. In the second group of the n.mgt file, there are 13fixed length locations for 13 parameter inputs and the first4 are specifically for single input (MONTH, DAY, HUSC,MGT_OP). However, there are 37 parameters sharing 9 loca-tions (from location number 5 to 13). Therefore, total (4þ37)parameters (see Appendix A) in the n.mgt files are allocated inthe “mgt2” table of the Watershed.mdb file by the order ofHRU number. In addition, more rows will be added in the“mgt2” Table if the number of rotation years is more than one.In C-SWAT, parameter information of MGT files is read fromtwo separate files named allmgt01.txt and allmgt02.txt withinclusion of all information from the “mgt1” and “mgt2” tablesof the Watershed.mdb. Parameter information will be firstread by subroutine readallmgt1.f and readallmgt2.f, and thensaved in two matrices. Next, parameter information originallyread in the subroutine readmgt.f will be substituted by passingvalues from the newly generated matrix instead of open/read/close each n.mgt file.

5. [HRU Level] OPS files (n.ops) – Structure IV[Subroutine Added] – allocate_allsystem.f/readallops.f[Subroutine Modified] – modparm.f/readsub.f/readops.f

(1) Basic informationMONTH, DAY, IYEAR, MGT_OP.

(2) Operational practicesTerracing operation: TERR_P, TERR_CN, TERR_SL.Tile drainage operation: DRAIN_D, DRAIN_T, DRAIN_G, DRAI-N_IDEP.Contouring operation: CONT_CN, CONT_P.Filter strip operation: FILTER_I, FILTER_RATIO, FILTER_CON,FILTER_CH.Strip cropping operation: STRIP_N, STRIP_CN, STRIP_C, STRIP_P.Fire operation: FIRE_CN.

Grassed waterways operation: GWATI, GWATN, GWATSPCON,GWATD, GWATW, GWATL, GWATS.Plant parameter update: CROPNO_UPD, HI_UPD, LAIMX_UPD.The scheduled management operations (n.ops) are developed tosimulated eight types of structural practices which includeterracing operation, title drainage, contouring, filter strip, stripcropping, fire, grassed waterways, and plant parameter update(Arnold et al., 2011). There are 11 fixed length locations for 11parameter inputs. The first 4 locations are specifically for singleinput (MONTH, DAY, IYEAR, MGT_OP). The following 7 locationsare for different operation practices and not all locations arefilled in every operation (e.g. 7 parameters are required for grasswaterways operation but only one for fire operation). Therefore,total (4þ28) parameters (see Appendix A) in the n.ops files areallocated in the “ops” Table of the Watershed.mdb file by theorder of HRU number. In addition, more rows will be added inthe “ops” table if the number of operation practices is more thanone. In C-SWAT, parameter information of OPS files is read froma single file named allops.txt with inclusion of all informa-tion from the “ops” table of the Watershed.mdb. Parameterinformation will be first read by subroutine readallops.f, andthen saved in a single matrix. Next, parameter informationoriginally read in the subroutine readops.f will be substituted bypassing values from the newly generated matrix instead ofopen/read/close each n.ops file.

6. [HRU Level] SEP files (n.sep) – Structure I[Subroutine Added] – allocate_allsystem.f/readallsep.f[Subroutine Modified] – modparm.f/readsub.f/readsepticbz.fIPOP_SEP, ISEP_TYP, BZ_Z, BZ_THK, BZ_AREA, BIO_BD, COEFF_BOD_DC, COEFF_BOD_CONV, COEFF_FC1, COEFF_FC2, COEFF_-FECAL.COEFF_PLQ, COEFF_MRT, COEFF_RSP, COEFF_SLG1, COEFF_SLG2, COEFF_NITR, COEFF_DENITR.Parameters in n.sep files can be categorized into four groups:septic system types, biozone geometry, biomass characteris-tics, and coefficients of bio-physical reaction (Arnold et al.,2011). A total of 18 parameters (see Appendix A) located in then.sep files are allocated in the “sep” table of the Watershed.mdb file by the order of HRU number. In C-SWAT, parameterinformation of SEP files is read from a single file named allsep.txt with inclusion of all information from the “sep” table of theWatershed.mdb. Parameter information will be first read bysubroutine readallsep.f and saved in a single matrix. Next,parameter information originally read in the subroutine read-sep.f will be substituted by passing values from the newlygenerated matrix instead of open/read/close each n.sep file.

7. [HRU Level] SOL files (n.sol) – Structures I and II[Subroutine Added] – allocate_allsystem.f/readallsol.f[Subroutine Modified] – main.f/hruallo.f/modparm.f/readsub.f/readsol.f

(1) Physical groupSNAM, HYDGRP, SOL_ZMX, ANION_EXCL, SOL_CRK, TEXTURE.

(2) Chemical groupSOL_Z, SOL_BD, SOL_AWC, SOL_K, SOL_CBN, SOL_CLAY, SOL_-SILT, SOL_SAND, SOL_ROCK, SOL_ALB, USLE_K, SOL_EC.Parameters in n.sol files can be categorized into two groups:physical and chemical characteristics (Arnold et al., 2011).There are 6 inputs in the first group and 12 in the second. Inthe first group, each HRU has only one input item (e.g. soilhydrologic group: B). In the second group, each parametermay have more than one value according to how many layersare existed in the soil body (e.g. SOL_Z[mm]: 430.00 710.002030.00). In this case, the following 11 parameters are alsocarrying the same number of values depending on the layer.Assume there are N soil layers, total (6þ12�N) parameters (see

H. Yen et al. / Computers & Geosciences 72 (2014) 221–232 229

Appendix A) in the n.hru files are allocated in the “sol” table ofthe Watershed.mdb file by the order of HRU number. In C-SWAT,parameter information of SOL files is read from a single filenamed allsol.txt with inclusion of all information from the “sol”table of the Watershed.mdb. Parameter information will be firstread by subroutine readallsol.f and saved in a single matrix. Next,parameter information originally read in the subroutine readsol.fwill be substituted by passing values from the newly generatedmatrix instead of open/read/close each n.sol file.

II. [Subbasin Level Files]. In addition to HRU level files, there aresix major subbasin level files in the TxtInOut directory (seeTable 1). The structure of open/read/close in the FORTRANsource code is very similar in n.chm, n.gw, n.hru, n.sep, and n.sol. On the other hand, the coding routine it is quite differentin n.mgt and n.ops where the operation practices requirespecific loops in order to proceed the simulation processes.

1. [Subbasin Level] PND files (n.pnd) – Structure I[Subroutine Added] – allocate_allsystem.f/readallpnd.f[Subroutine Modified] – modparm.f/readsub.f/readpnd.f

(1) Pond groupPND_FR, PND_PSA, PND_PVOL, PND_ESA, PND_EVOL,PND_VOL, PND_SED, PND_NSED, PND_K, IFLOD1, IFLOD2,NDTARG, PSETLP1, PSETLP2, NSETLP1, NSETLP2, CHLAP, SECCIP,PND_NO3, PND_SOLP, PND_ORGN, PND_ORGP, PND_D50,IPND1, IPND2.

(2) Wetland groupWET_FR, WET_NSA, WET_NVOL, WET_MXSA, WET_MXVOL,WET_VOL, WET_SED, WET_NSED, WET_K, PSETLW1, PSETLW2,NSETLW1, NSETLW2, CHLAW, SECCIW, WET_NO3, WET_SOLP,WET_ORGN, WET_ORGP, PNDEVCOEFF, WETEVCOEFF.Parameters in n.pnd files can be categorized into two groups:pond and wetland (Arnold et al., 2011). A total of (25þ21)parameters (see Appendix A) locates in the n.pnd files areallocated in the “pnd” table of the Watershed.mdb file by theorder of HRU number. In C-SWAT, parameter information ofPND files is read from a single file named allpnd.txt withinclusion of all information from the “pnd” table of theWatershed.mdb. Parameter information will be first read bysubroutine readallpnd.f and saved in a single matrix. Next,parameter information originally read in the subroutinereadpnd.f will be substituted by passing values from thenewly generated matrix instead of open/read/close each n.pnd file.

2. [Subbasin Level] RTE Files (n.rte) – Structures I and II[Subroutine Added] – allocate_allsystem.f/readallrte.f[Subroutine Modified] – modparm.f/readsub.f/readrte.fCHW2, CHD, CH_S2, CH_L2, CH_N2, CH_K2, CH_COV1, CH_COV2, CH_WDR, ALPHA_BNK, ICANAL, CH_ONCO, CH_OPCO,CH_SIDE, CH_BNK_BD, CH_BED_BD, CH_BNK_KD, CH_BED_KD,CH_BNK_D50, CH_BED_D50, CH_BNK_TC, CH_BED_TC, CH_ER-ODMO(1–10), CH_EQN.Parameters in n.rte files can be categorized into three groups:sediment, nutrient, and pesticide (Arnold et al., 2011). A totalof (23þ10) parameters (see Appendix A) located in the n.rtefiles are allocated in the “rte” table of the Watershed.mdb fileby the order of HRU number. In C-SWAT, parameter informa-tion of RTE files is read from a single file named allrte.txt withinclusion of all information from the “rte” table of theWatershed.mdb. Parameter information will be first read bysubroutine readallrte.f and saved in a single matrix. Next,parameter information originally read in the subroutine read-rte.f will be substituted by passing values from the newlygenerated matrix instead of open/read/close each n.rte file.

3. [Subbasin Level] SUB files (n.sub) – Structures I and II[Subroutine Added] – allocate_allsystem.f/readallsub.f[Subroutine Modified] – modparm.f/readsub.f/readsub.f

(1) Climate in subbasinSUB_KM, SUB_LAT, SUB_ELEV, IRGAGE, ITGAGE, ISGAGE,IHGAGE, IWGAGE, FCST_REG.

(2) Elevation bandsELEVB(1–10), ELEVB_FR(1–10), SNOEB(1–10).

(3) Precipitation/temperature and channelsPLAPS, TLAPS, SNO_SUB, CH_L1, CH_S1, CH_W1, CH_K1, CH_N1,CO2.

(4) Climate change informationRFINC(1–12), TMPRFINC(1–12), RADRFINC(1–12), HUMRFINC(1–12).

(5) Total number of HRUs modeled in subbasinHRUTOTParameters in n.sub files can be categorized into six groups:subbasin size/location, climate data specified in subbasin,topographic relief within subbasin, tributary details withinsubbasin, climate change variables, names of HRU input files(Arnold et al., 2011). There are five parts in the n.sub file: atotal of 9 parameters in the first part, 30 inputs (3 parameterswith 10 values of each) in the second part, 9 parameters in thethird part, 48 inputs (4 parameters with 12 values of each) inthe fourth part and one parameter in the last part. A total of 96parameters (see Appendix A) located in the n.sub files areallocated in the “sub” table of the Watershed.mdb file by theorder of HRU number. In C-SWAT, parameter information ofSUB files is read from a single file named allsub.txt withinclusion of all information from the “sub” table of theWatershed.mdb. Parameter information will be first read bysubroutine readallsub.f and saved in a single matrix. Next,parameter information originally read in the subroutine read-sub.f will be substituted by passing values from the newlygenerated matrix instead of open/read/close each n.sub file. Atthe end of n.sub one can find a number of file names such as n.hru, n.wgn, n.pnd, and n.wus. These files names do not have tobe included in the C-SWAT input files because there is no needto designate individual file names anymore. All 13 HRU andsubbasin level input files are being read from consolidate filessuch as allhru.txt, allsol.txt, and allchm.txt.

4. [Subbasin Level] SWQ Files (n.swq) – Structure I[Subroutine Added] – allocate_allsystem.f/readallswq.f[Subroutine Modified] – modparm.f/readsub.f/readswq.f

(1) Nutrient groupRS1, RS2, RS3, RS4, RS5, RS6, RS7, RK1, RK2, RK3, RK4, RK5,RK6, BC1, BC2, BC3, BC4.

(2) Pesticide groupCHPST_REA, CHPST_VOL, CHPST_KOC, CHPST_STL, CHPST_RSP,CHPST_MIX, SEDPST_CONC, SEDPST_REA, SEDPST_BRY, SEDP-ST_ACT.Parameters in n.swq files can be categorized into three groups:nutrient and pesticide for in-stream water quality processes(Arnold et al. 2011). A total of (17þ10) parameters (seeAppendix A) located in the n.swq files are allocated in the“swq” table of the Watershed.mdb file by the order of HRUnumber. In C-SWAT, parameter information of SWQ files isread from a single file named allswq.txt with inclusion of allinformation from the “swq” table of the Watershed.mdb.Parameter information will be first read by subroutine read-allswq.f and saved in a single matrix. Next, parameter infor-mation originally read in the subroutine readswq.f will besubstituted by passing values from the newly generated matrixinstead of open/read/close each n.swq file.

5. [Subbasin Level] WGN Files (n.wgn) – Structures I and II[Subroutine Added] – allocate_allsystem.f/readallwgn.f[Subroutine Modified] – modparm.f/readsub.f/readwgn.f

(1) Basic informationWLATITUDE, WLONGITUDE, WELEV, RAIN_YRS.

H. Yen et al. / Computers & Geosciences 72 (2014) 221–232230

(2) Monthly dataTMPMX(1–12), TMPMN(1–12), TMPSTDMX(1–12), TMPSTDMN(1–12), PCPMN(1–12), PCPSTD(1–12), PCPSKW(1–12), PR_W1(1–12), PR_W2(1–12), PCPD(1–12), RAINHHMX(1–12),SOLARAV(1–12), DEWPT(1–12), WNDAV(1–12).Parameters in n.wgn files can be categorized into two groups:basic information and monthly climate data (Arnold et al.,2011). A total of (4þ14�12) parameters (see Appendix A)located in the n.wgn files are allocated in the “wgn” table of theWatershed.mdb file by the order of HRU number. The first4 parameters are basic information such as latitude and longitude.The second part of inputs is 14 parameters with 12 different valuesin corresponding to 12 months of a year. In C-SWAT, parameterinformation of WGN files is read from a single file named allwgn.txt with inclusion of all information from the “wgn” table of theWatershed.mdb. Parameter information will be first read bysubroutine readallwgn.f and saved in a single matrix. Next,parameter information originally read in the subroutinereadwgn.f will be substituted by passing values from the newlygenerated matrix instead of open/read/close each n.wgn file.

6. [Subbasin Level] WUS Files (n.wus) – Structure II[Subroutine Added] – allocate_allsystem.f/readallwus.f[Subroutine Modified] – modparm.f/readsub.f/readwus.fWUPND(1–12), WURCH(1–12), WUSHAL(1–12), WUDEEP(1–12)Parameters in n.wus files are used to simulate consumptive waterusage (Arnold et al., 2011). A total of (4�12) parameters (seeAppendix A) located in the n.wus files are allocated in the “wus”table of the Watershed.mdb file by the order of HRU number.Each parameter includes12 values in corresponding to 12 monthsof a year. In C-SWAT, parameter information of WUS files is readfrom a single file named allwus.txt with inclusion of all informa-tion from the “wus” table of the Watershed.mdb. Parameterinformation will be first read by subroutine readallwus.f andsaved in a single matrix. Next, parameter information originallyread in the subroutine readwus.f will be substituted by passingvalues from the newly generated matrix instead of open/read/close each n.wus file.

Appendix B. Supporting information

Supplementary data associated with this article can be found inthe online version at http://dx.doi.org/10.1016/j.cageo.2014.07.017.

References

Ahmadi, M., Ascough II, J.C., DeJonge, K.C., Arabi, M., 2014. Multisite-multivariablesensitivity analysis of distributed watershed models: enhancing the perceptionsfrom computationally frugal methods. Ecol. Model. 279, 54–67.

Arnold, J.G., Allen, P.M., Bernhardt, G., 1993. A comprehensive surface-groundwaterflow model. J. Hydrol. 142, 47–69.

Arnold, J.G., Kiniry, J.R., Srinivasan, R., Williams, J.R., Haney, E.B., Neitsch, S.L., 2011.Soil and Water Assessment Tool Input/Output File Documentation Version2009. Texas Water Resources Institute Technical Report No. 365, Texas A&MUniversity System.

Arnold, J.G., Moriasi, D.N., Gassman, P.W., Abbaspour, K.C., White, M.J., Srinivasan, R.,Santhi, C., Harmel, R.D., Griensven, A.V., Van Liew, M.W., Kannon, N.,Jha, M.K., 2012. SWAT: model use, calibration, and validation. Trans. ASABE 55,1491–1508.

ASCE, 1993. Criteria for evaluation of watershed models, ASCE task committee ondefinition of criteria for evaluation of watershed models of the watershedmanagement, irrigation, and drainage division. J. Irrig. Drain. Eng. 119, 429.

Brown, L.C., Barnwell, T.O., 1987. The enhanced stream water quality modelsQUAL2E and QUAL2E-UNCAS: documentation and user manual. EnvironmentalResearch Laboratory. US EPA, EPA /600/3-87/007, Athens, GA, 189.

Borah, D.K., Yagow, G., Saleh, A., Barnes, P.L., Rosenthal, W., Krug, E.C., Hauck, L.M.,2006. Sediment and nutrient modeling for TMDL development and implemen-tation. Trans. ASABE 49, 967–986.

Bosch, N.S., Allan, J.D., Dolan, D.M., Han, H., Richards, R.P., 2011. Application of theSoil and Water Assessment Tool for six watersheds of Lake Erie: modelparameterization and calibration. J. Great Lakes Res. 37, 263–271.

Brazier, R.E., Beven, K.J., Freer, J., Rowan, J.S., 2000. Equifinality and uncertainty inphysically based soil erosion models: application of the glue methodology toWEPP—the water erosion prediction project- for sites in the UK and USA. EarthSurf. Process. Landforms 25, 825–845.

Chiang, L., Chaubey, I., Gitau, M.W., Arnold, J.G., 2010. Differentiating impacts ofland use changes from pasture management in a CEAP watershed using theSWAT model. Trans. ASABE 53, 1569–1584.

Daggupati, P., Douglas-Mankin, K.R., Sheshukov, A.Y., Barnes, P.L., Devlin, D.L., 2011.Field-level targeting using SWAT: mapping output from HRUs to fields andassessing limitations of GIS input data. Trans. ASBE 54 (2), 501–514.

Duan, Q., Sorooshian, S., Gupta, V., 1992. Effective and efficient global optimizationfor conceptual rainfall-runoff models. Water Resour. Res. 28, 1015–1031.

Duan, Q., Sorooshian, S., Gupta, V.K., 1994. Optimal use of the SCE-UA globaloptimization method for calibrating watershed models. J. Hydrol. 158, 265–284.

Duriancik, L.F., Bucks, D., Dobrowolski, J.P., Drewes, T., Eckles, S.D., Jolley, L., Kellogg,R.L., Lund, D., Makuch, J.R., O'Neill, M.P., Rewa, C.A., Walbridge, M.R., Parry, R.,Weltz, M.A., 2008. The first five years of the Conservation Effects AssessmentProject. J. Soil Water Conserv. 63 (6), 185A–197A.

Freer, J.E., McMillan, H., McDonnell, J.J., Beven, K.J., 2004. Constraining dynamicTOPMODEL responses for imprecise water table information using fuzzy rulebased performance measures. J. Hydrol. 291, 254–277.

Harmel, R.D., Smith, P.K., Migliaccio, K.W., 2010. Modifying goodness-of-fit inindicators to incorporate both measurement and model uncertainty in calibra-tion and validation. Trans. ASABE 53, 55–63.

Hoque, Y.M., Tripathi, S., Hantush, M.M., Govindaraju, R.S., 2012. Watershedreliability, resilience and vulnerability analysis under uncertainty using waterquality data. J. Environ. Manag. 109, 101–112. http://dx.doi.org/10.1016/j/jenvman.2012.05.010.

Johnson, A., 2013. A Regression Metamodel to Replace SWAT in Crop YieldPrediction for Big Creek Watershed (Master thesis). Southern Illinois University.

Joseph, J.F., Guillaume, J.H.A., 2013. Using a parallelized MCMC algorithm in R toidentify appropriate likelihood functions for SWAT. Environ. Model. Softw 46,292–298.

Liew, M.W. Van, Veith, T.L., Bosch, D.D., Arnold, J.G., 2007. Suitability of SWAT forthe Conservation Effects Assessment Project: Comparison on USDA AgriculturalResearch Service Watersheds. J. Hydrol. Eng., 173–189.

Mathworks, T., 2013. MATLAB 2013b. Natick, MA. Available at: ⟨http://www.mathworks.com⟩.

Moriasi, D.N., Wilson, B.N., Douglas-Mankin, K.R., Arnold, J.G., Gowda, P.H., 2012.Hydrologic and water quality models: use, calibration. Trans. ASABE 55,1241–1247.

Nash, J.E., Sutcliffe, J.V., 1970. River flow forecasting through conceptual models:part I. A discussion of principles. J. Hydrol. 10 (3), 282–290.

Osorio, J., Jeong, J., Arnold, J.G., Beiger, B., 2014. Influence of potential evapotran-spiration on the water balance of sugarcane fields in Maui, Hawaii - specialissue: evapotranspiration. J. Water Res. Prot. 6, 852–868.

Neitsch, S.L., Arnold, J.G., Kiniry, J.R., R, W.J., 2011. Soil & Water Assessment ToolTheoretical Documentation Version 2009. Texas Water Resource InstituteTechnical Report No. 406, Texas A&M University System.

USDA NASS, 2012. USDA-National Agricultural Statistics Service, Cropland DataLayer.

USDA NRCS, 2009. Conservation Effects Assessment Project (CEAP). USDA NationalResources Conservation Service ⟨http://www.nrcs.usda.gov/technical/NRI/ceap/⟩.

USDA NRCS, 2012. Soil Data Mart, Washington D.C., Available online: ⟨http://soildatamart.nrcs.usda.gov⟩.

Pagliero, L., Bouraoui, F., Willems, P., Diels, J., 2012. Large-scale hydrologicalsimulations using the Soil Water Assessment Tool, protocol development, andapplication in the Danube Basin. J. Environ. Qual 43 (1), 145–154.

Rouholahnejad, E., Abbaspour, K.C., Vejdani, M., Srinivasan, R., Schulin, R., Lehmann, A.,2012. A parallelization framework for calibration of hydrological models. Environ.Model. Softw. 31, 28–36.

Schuol, J., Abbaspour, K.C., Srinivasan, R., Yang, H., 2008. Estimation of freshwateravailability in the West African sub-continent using the SWAT hydrologicmodel. J. Hydrol. 352, 30–49.

Seo, M., Yen, H., Jeong, J., 2014. Transferability of input parameters between SWAT2009 and SWAT 2012. J. Environ. Qual. 43 (3), 869–880. http://dx.doi.org/10.2134/jeq2013.11.0450.

Servat, E., Dezetter, A., 1991. Selection of calibration objective functions in thecontext of rainfall-runoff modeling in a Sudanese savannah area. Hydrol. Sci. J36, 307–330.

Sharma, V., Swayne, D.A., Lam, D., Schertzer, W., 2006. Parallel Shuffled ComplexEvolution Algorithm for calibration of hydrological models. In: Proceedings ofthe 20th International Symposium on High-Performance Computing in anAdvanced Collaborative Environment (HPCS'06), IEEE.

Tolson, B.A., Shoemaker, C.A., 2007. Dynamically dimensioned search algorithm forcomputationally efficient watershed model calibration. Water Resour. Res. 43,1–16.

USGS NED, 2013. 1/3″ Digital Elevation Model. URL ⟨http://seamless.usgs.gov/⟩(accessed May 2013).

Vrugt, J.A., Braak, C.J.F., Diks, C.G.H., Robinson, B.A., Hyman, J.M., Higdon, D., 2009.Accelerating Markov Chain Monte Carlo Simulation by differential evolutionwith self-adaptive randomized subspace sampling. Int. J. Nonlinear Sci. Numer.Simul. 10, 271–288.

H. Yen et al. / Computers & Geosciences 72 (2014) 221–232 231

White, M.J., Harmel, R.D., Arnold, J.G., Williams, J.R., 2014. SWAT check: A screeningtool to assist users in the identification of potential model applicationproblems. J. Environ. Qual. 43, 208–214. http://dx.doi.org/10.2134/jeq2012.0039.

Winchell, M., Srinivasan, R., Di Luzio, M., Arnold, J.G., 2008. ArcSWAT 2.1 Interfacefor SWAT 2005: User's Guide. Blackland Research Center, Temple, Texas.

Whittaker, G., 2004. Use of a Beowulf cluster for estimation of risk using SWAT.Agron. J. 96, 1495–1497.

Yalew, S., van Griensven, A., Ray, N., Kokoszkiewicz, L., Betrie, G.D., 2013.Distributed computation of large scale SWAT models on the grid. Environ.Model. Softw. 41, 223–230.

Yen, H., 2012. Confronting input, parameter, structural, and measurement uncer-tainty in multi-site multiple responses watershed modeling using Bayesianinferences (Ph.D. Dissertation). Colorado State University.

Yen, H., Wang, X., Fontane, D.G., Harmel, R.D., Arabi, M., 2014a. A framework forpropagation of uncertainty contributed by parameterization, input data, modelstructure, and calibration/validation data in watershed modeling. Environ.Model. Softw. 54, 211–221.

Yen, H., Bailey, R.T., Arabi, M., Ahmadi, M., White, M.J., Arnold, J.G., 2014b. The Roleof interior watershed processes in Improving parameter estimation andperformance of watershed models. J. Environ. Qual. , http://dx.doi.org/10.2134/jeq2013.03.0110.

Zhang, X., Beeson, P., Link, R., Manowitz, D., Izaurralde, R.C., Sadeghi, A., Thomson,A.M., Sahajpal, R., Srinivasan, R., Arnold, J.G., 2013. Efficient multi-objectivecalibration of a computationally intensive hydrologic model with parallelcomputing software in Python. Environ. Model. Softw. 46, 208–218.

Zhang, X., Srinivasan, R., Bosch, D., 2009. Calibration and uncertainty analysis of theSWAT model using Genetic Algorithms and Bayesian Model Averaging. J.Hydrol. 374, 307–317.

H. Yen et al. / Computers & Geosciences 72 (2014) 221–232232