Long time taken to run the SWAT+ toolbox

[Dessalegn Worku]

Dear experts

I am a beginner with SWAT+ and the SWAT+ Toolbox. I ran the SWAT+ model and began the sensitivity analysis yesterday; however, the process is taking longer than expected, even though the catchment is relatively small (about 1,600 km²). My computer has 16 GB of RAM and a Core i7 processor, which I assumed would be sufficient to complete the analysis in a reasonable amount of time. Could anyone explain what might be causing the slow performance?

I am also preparing to work on a much larger watershed of approximately 65,000 km². For those with experience, what level of computing power is typically required to efficiently perform calibration and validation for a watershed of that size?

Additionally, I suspect that part of the slow runtime may be related to the fact that I used daily streamflow input data. I am now considering shifting to monthly data, but I am unsure how to properly prepare the monthly input dataset. Any guidance or shared examples would be greatly appreciated.

I look forward to hearing back from you soon. 

[Celray James]

How many HRUs do you have? did you set the model up using high resolution data (e.g. 30m)?

[Dessalegn Worku]

Dear Celray James

Thank you for the response and my apologies for the late response. My watershed has about 25,000 HRUs and the resolution of the spatial data are 30m by 30m. Note, the original resolution of the some data for instance land cover map was 300m by 300m but I resampled to 30m by 3m for all the data to have the same resolution to the DEM.

But, now I am using comparatively faster higher performance computing than my computer but it is still slow (1 iteration in 1 hr and about 24 iteration in a Day).

I have also another issue to ask you for assistance. I am following a multi-site calibration approach that includes the main outlet of the basin (approximately 65,000 km²) and two nested sub-catchments with areas of about 1,600 km² and 1,300 km². However, my preliminary calibration results show inconsistencies among stations: as the statistical performance metrics (e.g., NSE, KGE) improve at one station, they tend to deteriorate at the others. I would therefore kindly ask for your guidance on how to address the issue of increasing/decreasing statistical metrics across multiple calibration sites.

I would greatly appreciate your help, as I can resolve this challenge for my ongoing work. Thank you very much for your time and support.

[Celray James]

25K HRUs is quite a lot of HRUs, and if you are running like 20 years in your sensitivity analysis, that will take very long especially if you are printing daily outputs which can grow to several gigabytes. You could try to reduce the number of years used for sensitivity simulation.

Also, HPCs do not run things faster than PCs. the advantage in using HPCs is in highly parallelised tasks requring upwards of 32 cores, but most of them run at about 3.0 GHz or less where as modern laptops often go beyond 4.5 or even 5.0 GHz, so unless you can use more than 15 or 20 processes on HPC you may be better in terms of speed on a 12 core laptop.

[Dessalegn Worku]

Thank you very much for your feedback.

I am currently using 12 years of monthly data. I completed the sensitivity analysis with a slower process; however, as you pointed out, the processing time decreases substantially when the data length is reduced from 20 years to 12 years for the sensitivity analysis. As you correctly noted, the main challenge appears to be the large number of HRUs. The HPC resource is also not as fast as expected, but it allow up to 18 parallel processes, and an additional advantage is that the system can run 24/7.

Despite the slow processing time, I am trying to manage the calibration. I would also like to request your guidance on two related issues:

1. Multi-site calibration issue
   I attempted a multi-site calibration approach that includes the main basin outlet (approximately 65,000 km²) and two nested sub-catchments with areas of about 1,600 km² and 1,300 km². However, the preliminary results show inconsistencies among the stations: when the statistical performance metrics (e.g., NSE, KGE) improve at one station, they tend to deteriorate at the others.
   I would therefore appreciate your advice on how best to address this trade-off in performance across multiple calibration sites. Would a sequential calibration strategy be more appropriate in this case? Please note that my primary target is the main outlet, as I will simulate future water balance components only at this location. The purpose of including the two nested sub-catchments is to improve model parameterisation, not to conduct separate future simulations for those sub-watersheds.

2. Continuation of calibration from the previous best results
   I also tried performing calibration at the main outlet only and achieved good results by 25 iterations. I wanted to continue the calibration to further improve the performance metrics by starting from the best parameter values obtained so far. However, I could not find the option “Include current parameter values” in the SWAT+ Toolbox version (v3.1) that I am using. I understand that this option is available in version 3.2.
   Could you please clarify whether the toolbox in version 3.1 automatically uses the best parameter values from the previous calibration run when continuing with an additional round (e.g., 40 more iterations), or whether the calibration restarts from scratch?

I would greatly appreciate your guidance on these issues, as resolving them is important for my ongoing work. Thank you very much for your time and support.

--
You received this message because you are subscribed to the Google Groups "SWAT+ Toolbox" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sptoolbox+...@googlegroups.com.
To view this discussion, visit https://groups.google.com/d/msgid/sptoolbox/72cf32e9-94f6-4efe-b8ea-4140b55632f4n%40googlegroups.com.

--

--

With Best Regards,

Dessalegn Worku Ayalew

Doctoral Student

Bonn International Graduate School for Development Research (BIGS-DR)

Institute of Center for Development Research (ZEF) at University of Bonn

Genscherallee 3; 53113 Bonn, Germany

Cell Phone: +49-15 21 24 26 710
Alternative emails: s98d...@uni-bonn.de; desuw...@gmail.com

 Lecturer and Researcher, Woldia University, Ethiopia; BSc in Soil Resources and Watershed Management; MSc in Water Engineering; MSc in Mediterranean Forestry and Natural Resources Management.  

[Celray James]

1. This is typical when you have many stations. what I usually do is to decide parameter regions upstream of each station, starting upstream going downstream, set parameters for each region assigned to those specific HRUs, Aquifers and Channels, then run calibration for that station, then use the freeze parameters button in auto calibration section. move to next region, add parameters and assign to specific HRUs etc for that region, and calibrate to corresponding station...
2. Calibration will ignore previous values in 3.1, with 3.2 you can save parameters and test other combinations and can always load them back (even from calibration.cal). if you need to improve upon previous efforts and try different saved parameter sets as starting points, I recommend you update, you also get resume support (and latest executable if you need it) and stable sensitivity analysis (prevents random crashes resulting from ifx compiled exe)

[Dessalegn Worku]

Dear Celray James

Thank you very much for the constructive comments. It is really appreciated! I will shift to new version of SWAT+ toolbox (v3.2) and start calibration from the upstream sub-catchment to downstream based on your suggestion. Thank you again and will reach out you in case of any questions. 

To view this discussion, visit https://groups.google.com/d/msgid/sptoolbox/de40d3f0-bdca-4b22-a957-99a72f4f281dn%40googlegroups.com.