简介本资源是一套可直接运行的SWAT-CUP小时尺度水文模型率定完整配置包面向水文水资源、环境科学及农业面源污染模拟领域的科研人员与研究生解决SWAT模型 hourly 输入构建难、CUP参数率定配置复杂、多模块文件协同易出错等实操痛点。压缩包含2000个文件总大小41.69MB涵盖281个子流域排水sdr、260个地下水gw、257个水文响应单元hru及土壤sol、气象wgn、管理mgt、化学chm等核心模块文件并包含SUFI2_Run.bat批处理脚本、ATMO.ATM气象驱动文件、sqlite数据库及watout_hr_12等关键输出支持文件目录结构严格遵循SWAT-CUP hourly标准流程。已有414人学习下载提供开箱即用的TxtInOut输入体系与已调通的cup配置显著降低SWAT hourly建模门槛节省从零搭建与调试所需数日时间。 做水文模型的人十个里有八个会在SWAT和SWAT-CUP这对组合上栽过跟头。尤其是当你好不容易把日尺度的TxtInOut跑通导师或者项目甲方突然丢来一句“我们需要小时尺度的模拟结果”时那种从数据到代码再到工具的全面重构感简直让人头皮发麻。这篇文章就是踩过一遍坑之后直接把能跑的SWAT-CUP-Hourly示例TxtInOut文件、cup配置和完整的率定流程给你拆开揉碎讲清楚让你少走两个月的弯路。这个内容适合谁呢正在做SWAT小时尺度模拟、被SWAT-CUP反复报错劝退、或者已经能跑通日尺度但不知道如何切换到小时尺度的研究生和工程师。我会从文件骨架、配置逻辑、实测操作、常见坑点四个维度展开全部是基于我自己在项目里实际跑通后的经验总结。1. 先说清楚SWAT-CUP-Hourly到底是来解决什么问题的1.1 为什么从日步长切到小时步长是个分水岭很多人第一次接触SWAT-CUP用的是日尺度的数据感觉还挺顺利加载TxtInOut选参数跑敏感性分析看P-factor和R-factor一套流程下来模型性能也说得过去。但切换到小时尺度之后一切都变得不一样了。SWAT模型本身是基于物理过程的分布式水文模型它的核心计算单元是水文响应单元HRU日尺度下很多过程比如土壤水再分配、基流退水、融雪都被简化成了日累计量。可一旦把时间步长压缩到小时模型对降雨过程的响应、对土壤入渗的模拟、对洪峰的刻画都会变得敏感得多。这意味着两件事第一你的输入气象数据必须细化到小时不能再用日值插值糊弄过去第二率定的时候需要调整的参数集合、参数取值范围、以及目标函数的定义都和日尺度完全不同。SWAT-CUP-Hourly其实就是SWAT-CUP针对这种小时尺度模拟场景的一个变体它在算法上仍然支持SUFI2、GLUE、ParaSol等常用率定方法但在时间控制、观测数据匹配、目标函数计算这些方面专门适配了小时级的观测序列。很多人在这个环节出错根本原因不是不会操作SWAT-CUP而是没有理解它是怎么把小时观测数据和SWAT的小时输出对应起来的。1.2 这套示例的适用范围与适用人群我下面要讲的这套“SWAT-CUP-Hourly示例TxtInOut文件及cup配置”本质上是一个已经组织好的、可以直接跑通的小型案例。它的TxtInOut文件夹是完整的包含了SWAT模型运行所需要的全部输入输出文件cup配置则已经把SUFI2算法的基本参数、迭代次数、目标变量都设置好了。这套示例的典型适用范围有三个你的研究流域已经完成了SWAT模型构建但还在日尺度阶段需要快速切换到小时尺度。你手头有小时尺度的降雨、气温等气象观测数据但不知道如何把这些数据组织成SWAT-CUP-Hourly能识别的格式。你已经被SWAT-CUP的报错折磨到崩溃需要一个“至少能跑通”的参考模板在此基础上替换成自己的数据。它不是万能的但它是你从零到一最需要的那个“脚手架”。我自己在实际项目中就是靠类似的一套模板把某个山区小流域的时尺度洪水模拟从完全跑不通硬生生调到了纳什系数0.75以上的水平。2. 拿到示例文件后先搞懂TxtInOut和CUP配置的骨架2.1 TxtInOut文件夹里的每个核心文件是干什么的SWAT的TxtInOut文件夹是模型运行时的“工作目录”里面包含了几百个文件新手一看就头大。但你不必每个文件都理解关键的核心文件就那几类。首先是file.cio这是总控制文件。它定义了整个模型运行的主控信息比如模拟开始时间、结束时间、降雨和气温数据的时间步长、输出文件的打印选项等。小时尺度模拟的时候file.cio里的print code必须设置成小时输出这一点很多人会漏掉。如果你跑出来还是日输出SWAT-CUP-Hourly在率定的时候会因为找不到小时序列而直接报错或者匹配错位。其次是气象输入文件。包括降水文件.pcp、气温文件.tmp、相对湿度文件.hmd、风速文件.wnd、太阳辐射文件.slr等。小时尺度下这些文件的行数会爆炸式增长比如日尺度一年365行小时尺度一年就是8760行。而且每一行的时间戳格式、数值精度SWAT都有一套严格定义。这套示例里特意给出了标准的文件名和格式就是为了让你对照着修改。再往下是子流域和水文响应单元文件夹包含.sub子流域文件、.hruHRU文件、.rch河道文件、.swq水质文件等。这些文件里记录了各个空间单元的参数初始值SWAT-CUP在率定过程中会不断修改其中某些参数然后重新调用SWAT做模拟所以这些文件是SWAT-CUP的“操作对象”。最后还有output.rch、output.hru这样的输出结果文件。虽然它们是SWAT模型运行后生成的但SWAT-CUP的读取逻辑是先在TxtInOut里启动SWAT跑完之后去读output.rch或output.hru里面的模拟值再和观测值做比对。所以如果你的file.cio输出设置有问题导致结果文件格式不对SWAT-CUP读不到数据后面全白搭。2.2 SWAT-CUP-Hourly需要的观测数据准备这个环节是很多人的噩梦。SWAT-CUP-Hourly需要两种观测数据一种是时间序列数据比如小时降雨、小时流量存放在observed文件夹或者直接在CUP项目里指定另一种是参数初始值存放在上面说的TxtInOut文件里。观测数据要注意格式第一列时间戳第二列观测值。时间戳的格式必须和你CUP项目里的时间设置完全一致否则会出现“时间段不匹配”的错误。我之前遇到过一种情况流域出口的流量观测数据是UTC时间而模型用的是本地时间结果率定出来的参数完全荒谬后来排查了一个星期才发现是时间偏移的问题。在这套示例里观测数据文件是按照“每小时一行列名清晰”的方式整理的。我建议你在准备自己的观测数据时也统一采用这种格式同时用脚本比如Python的pandas先做一次时间戳对齐和异常值剔除这能省去后面很多麻烦。2.3 文件夹组织的关键思路一个项目对应一个完整TxtInOutSWAT-CUP在实际使用中每个率定项目比如SUFI2.0这个文件夹里都应该放一份完整的TxtInOut副本而不是多个项目共享一个TxtInOut文件夹。为什么因为SWAT-CUP在每次迭代时都会修改TxtInOut里的参数文件如果多个项目共用一份后运行的项目会覆盖掉前一个项目的参数修改结果导致率定结果完全混乱。而且当你需要并行跑多个项目的敏感性分析时各自的TxtInOut独立是最基本的安全保障。所以我通常的做法是先维护一份“干净的基线TxtInOut”专门用来复制分发。每新建一个率定项目就从基线复制一份完整的TxtInOut进去然后再在CUP配置里指定这个新路径。这套示例里的目录结构就是把这一逻辑固化下来了。3. 实操从配置CUP到第一次成功运行SWAT3.1 创建CUP项目并绑定TxtInOut安装好SWAT-CUP之后打开程序选择File-New Project然后输入项目名称。注意项目名称不要带空格和中文否则后面调用的路径解析容易出问题。项目目录选择你准备存放率定文件的地方。关键一步程序会问你SWAT Project也就是TxtInOut文件夹的路径这时候一定要选准。如果你手头有现成的TxtInOut直接指向它的上一级目录让SWAT-CUP自动识别TxtInOut如果你是照着我这套示例的目录结构来的那路径选择应该非常顺手。接下来选择时间设置。这里要特别注意“Warm-up Period”和“Simulation Period”的区分。Warm-up期是为了让模型状态变量比如土壤水含量、蓄水层水位达到平衡一般建议设置至少1年的预热期哪怕你的观测数据只有半年。预热期不会参与率定计算但会影响初始条件。小时尺度下预热期的计算量会非常大所以也需要在预热期长度和计算耗时之间找一个平衡点。然后就是指定观测数据文件。在Observed Data选项卡里加载你的小时流量观测文件。SWAT-CUP-Hourly会要求你选择观测数据的变量类型流量、泥沙、水质等以及模拟结果对应的输出文件类型。流量一般对应output.rch指标选FLOW_OUT。3.2 SUFI2算法的核心参数设置SWAT-CUP-Hourly里最常用的率定算法是SUFI2Sequential Uncertainty Fitting version 2。它的核心思想不是寻找一组最优参数而是通过多次迭代逐步缩小参数的不确定性区间让模型模拟的95%预测不确定带95PPU尽可能覆盖尽可能多的观测数据。第一次打开CUP.ini配置文件你会看到几个关键参数ObjectiveFunctionType目标函数类型一般选择NSENash-Sutcliffe Efficiency如果你更关注洪水过程也可以选logNSE或者KGE。NumberIterations迭代次数。日尺度模拟建议200-500次小时尺度模拟因为计算量大建议一开始设置50-100次先看看参数敏感性和趋势再逐步增加。NumberSimulations每次迭代的模拟次数即拉丁超立方采样次数。默认是500但小时尺度跑一次SWAT非常耗时你可以先降低到100-200跑通流程后再增加。PValue和RValue这两个是判断参数敏感性时用的统计阈值一般保持默认即可。提示小时尺度下SWAT的单次运行时间可能是日尺度的数十倍。我实测一个中型流域约20个子流域100多个HRU日尺度跑一次只要几秒小时尺度跑一次可能要一两分钟甚至更久。如果你设置500次模拟、5次迭代总耗时可能会达到几十个小时。所以建议先用小模拟次数跑通再慢慢加大。3.3 参数选择别把所有参数都一股脑丢进去SWAT-CUP最吸引人的地方在于它可以自动调整几十个参数。但真正有经验的人都知道参数不是越多越好。小时尺度率定的时候我建议重点关注这几类参数地表径流类CN2SCS径流曲线数、SURLAG地表径流滞后系数土壤类SOL_AWC土壤有效含水量、SOL_K饱和导水率地下水类ALPHA_BF基流退水系数、GW_DELAY地下水滞后时间河道类CH_N2曼宁糙率、CH_K2河道有效导水率小时尺度和日尺度在参数敏感性上有一些明显差异。比如SURLAG日尺度下影响不大但小时尺度下它直接影响洪峰的峰值和时间非常敏感。再比如ALPHA_BF它决定了基流的消退速度小时尺度下基流过程线会更细碎这个参数的表现也更加复杂。在这套示例的cup配置里我预置了12个参数每个参数都给出了合理的上下限。你可以直接照用也可以根据自己的流域特点调整。记住一个原则第一次率定参数宁少勿多。跑完一轮敏感性分析之后把那些p值大于0.5、敏感性极低的参数冻结掉只保留真正敏感的参数继续优化。3.4 运行SWAT与第一次迭代的全过程记录配置完成之后点击RunSWAT-CUP会开始每一次迭代的循环调用SWAT模型读取输出结果计算目标函数值更新参数区间。我这里记录一次典型的小时尺度迭代过程以示例项目为例迭代次数100次第1-20次模拟此时参数搜索空间较大目标函数值NSE起伏明显甚至可能出现负值。这是正常的因为SUFI2在第一轮会用较大的参数范围去采样。第21-50次模拟随着采样点的增加目标函数值开始稳定部分参数表现出明显的敏感性。如果某个参数在50次模拟后仍然毫无影响说明它要么不敏感要么初始范围设置太小。第51-100次模拟SUFI2算法会根据前50次的结果重新计算参数范围下一轮迭代会在新的范围内采样。第一次迭代跑完之后SWAT-CUP会自动生成summary.out和goal.out文件。goal.out里有每次模拟的目标函数值summary.out里有参数敏感性分析结果。我第一次跑完小时尺度的100次模拟看到NSE只有0.2左右心里凉了半截但实际不用慌SUFI2的魅力就在于多轮迭代后会逐步收敛。我最终在第4次迭代之后NSE稳定在了0.75以上P-factor和R-factor也达到了较理想的水平。4. 常见问题与排查技巧实录4.1 经典报错模型运行失败或者生成文件缺失这个报错太常见了几乎每个人都会遇到。出现这个错误SWAT-CUP通常会在log文件里写清楚原因但很多人不看log直接百度浪费时间。排查思路如下先查看TxtInOut目录下是否有input.std和output.std文件。input.std是SWAT的标准输入文件output.std是标准输出文件。如果output.std存在打开它最后几行通常会写清楚报错原因比如某个气象数据文件缺失、某个参数越界、时间设置不对。检查file.cio里的时间设置是否和CUP配置一致。尤其是小时尺度下file.cio里的print code和print interval设置错误会导致输出文件缺失。检查TxtInOut文件夹里的气象数据文件是否完整。小时尺度的气象数据文件非常大经常有人在复制过程中漏掉几个文件或者文件名大小写不一致导致SWAT找不到。注意SWAT对中文路径非常不友好。如果你把项目放在D:\我的项目\流域模拟这类包含中文的路径下SWAT-CUP十有八九会报错。建议所有路径都使用纯英文。4.2 目标函数值始终是负数模型模拟结果完全对不上这个问题比较棘手。目标函数为负说明模拟值连观测值的平均水平都没达到基本上等于模型完全没有捕捉到降雨-径流过程。我遇到这种情况优先检查三件事时间格式是否对齐。小时尺度下观测数据的时间步长是不是和模型输出完全一致比如模型输出的是UTC8时间而你的观测数据是UTC时间差了8小时洪峰完全错位NSE自然为负。雨量数据是否进入模型。打开output.rch看模拟的流量值是否出现了“滴水不漏”的情况即全为0或者极小值。如果是多半是降水数据没有正确读取或者降水文件的时间格式错了。参数范围是否合理。比如CN2设成了20-30但你的流域实际是典型的农业区CN2应该在70以上。这种情况下模型始终低流量率定永远不收敛。4.3 敏感性分析结果非常奇怪理论敏感的参数反而不敏感这种情况在小时尺度模型中比较常见。比如CN2在日尺度下极其敏感但小时尺度下却显得无关紧要。原因往往是参数之间存在相关性。比如CN2和SOL_AWC在小时尺度下对洪峰形成的影响存在重叠导致SUFI2的敏感性分析无法区分它们的独立贡献。解决办法有两个检查参数相关矩阵SWAT-CUP的par_corr.txt文件如果两个参数的相关系数超过0.7考虑将其中一个冻结。分组率定。先率定地表径流相关的参数组固定它们之后再率定地下水参数组最后再联合微调。这样能有效避免参数之间的干扰。4.4 常见问题速查表问题现象可能原因解决思路model execution failedTxtInOut路径错误、气象文件缺失、file.cio时间设置问题检查input.std和output.std定位具体报错行模拟结果全为0降水数据未正确读取、file.cio中降雨文件指向错误打开降水文件检查行数、时间范围和数值范围目标函数始终为负时间错位、CN2范围太小、流量单位不统一核对时间戳检查模拟流量与观测流量量级是否一致参数敏感性低参数范围过小、参数间相关性高扩大参数范围检查相关矩阵考虑分组率定多站点模拟结果倒挂不同站点的观测时段不一致为每个站点单独配置观测数据时段率定结果收敛但P-factor极低参数不确定性区间过小95PPU覆盖太少适当扩大关键参数的取值范围增加迭代次数5. 率定结果的判读与收尾5.1 P-factor、R-factor这些指标到底怎么理解SUFI2算法率定完之后判断模型好坏主要看两组指标P-factor和R-factor以及目标函数值NSE、R²、KGE等。P-factor指的是观测数据被95PPU95%预测不确定带覆盖的比例。理想情况下P-factor越接近1越好意味着模型模拟的95%不确定性区间覆盖了几乎全部观测数据。但你别天真地以为P-factor越高就是模型越好因为P-factor是可以靠扩大参数范围来“刷”上去的。R-factor是95PPU带的平均宽度与观测数据标准差之比。R-factor越小说明不确定性带越窄模拟结果越精确。一般建议R-factor小于1但实际操作中R-factor在1-1.5之间也可以接受。这两个指标是相互制约的。参数范围调得过大P-factor会上升但R-factor也会恶化范围太小R-factor倒是好看了但P-factor就会下降。我的经验是先保证P-factor不低于0.6再尽量压缩R-factor。如果两者实在平衡不了优先保P-factor因为从工程应用角度模拟结果覆盖住实测过程比窄区间里的高精度更有意义。NSE方面小时尺度模型的NSE达到0.6以上就算合格0.75以上属于优秀。但注意小时尺度和日尺度的NSE不具备直接可比性因为时间步长越短洪峰误差被放大的程度越高。所以如果你看到日尺度的NSE是0.85小时尺度调了半天停在0.7别沮丧这已经是比较理想的结果了。5.2 小时尺度率定的一些独特策略最后分享几个小时尺度率定独有的策略都是从实际项目里磨出来的经验。第一目标函数选择上如果洪水过程是你的重点优先选择logNSE或者包含洪峰权重系数的目标函数不要让基流段的“高分”掩盖了洪峰段的“低分”。小时尺度下基流起伏不大很容易让NSE虚高但洪峰处误差依然很大。第二分时段率定。把观测序列分成湿润期和干旱期两段分别查看模拟效果。如果湿润期洪峰偏低重点调整CN2和SURLAG如果干旱期退水过程对不上重点调ALPHA_BF和GW_DELAY。这种“分症状给药”的策略比盲目调参高效得多。第三利用SWAT-CUP的并行计算功能。如果你的电脑是多核的在CUP.ini里把并行核数调大。小时尺度模型计算量巨大并行与否对时间成本的影响非常显著。实测下来4核并行比单核运行能节省70%以上时间。第四一定要保留率定过程中的中间结果。每跑完一轮迭代把TxtInOut和CUP项目整个复制一份。这样即使后面某个实验方案把参数调坏了也能快速回滚到上一个稳定状态不至于重新开始。5.3 示例配置的终极使用建议这套SWAT-CUP-Hourly示例TxtInOut文件和cup配置最大的价值不是直接给你一套“完美的”参数结果因为每个流域的物理特性不同而是给你一个“保证能跑通”的起点。我建议你把它的目录结构、配置文件格式、数据组织方式当做一个模板然后逐步替换成你自己的流域数据。具体步骤如下先保留示例的原有数据完整跑一遍确认SWAT-CUP-Hourly在你的电脑上能运转。在示例基础上把自己的小时尺度气象数据替换进TxtInOut先不换流域参数看看模型是否还能运行模拟值是否在合理范围内。再替换掉空间数据子流域、HRU文件这时候大概率会出现各种报错用我在第4部分总结的排查表逐个解决。最后替换观测数据开始你自己的率定迭代。这个过程下来你就不是“照抄配置”而是真正理解了SWAT-CUP-Hourly的运作机制。我个人在实际操作中的体会是很多工具不是难在概念而是难在“从零到一”这个初始环节。只要第一个完整流程能稳定跑通后续所有的调参、优化、策略升级都只是工作量的问题。希望这套示例和这份实操记录能帮你把最痛苦的“跑通”这一步跨过去。本文还有配套的精品资源点击获取 SWAT-CUP-Hourly小时尺度模拟：TxtInOut配置与率定全攻略
简介本资源是一套可直接运行的SWAT-CUP小时尺度水文模型率定完整配置包面向水文水资源、环境科学及农业面源污染模拟领域的科研人员与研究生解决SWAT模型 hourly 输入构建难、CUP参数率定配置复杂、多模块文件协同易出错等实操痛点。压缩包含2000个文件总大小41.69MB涵盖281个子流域排水sdr、260个地下水gw、257个水文响应单元hru及土壤sol、气象wgn、管理mgt、化学chm等核心模块文件并包含SUFI2_Run.bat批处理脚本、ATMO.ATM气象驱动文件、sqlite数据库及watout_hr_12等关键输出支持文件目录结构严格遵循SWAT-CUP hourly标准流程。已有414人学习下载提供开箱即用的TxtInOut输入体系与已调通的cup配置显著降低SWAT hourly建模门槛节省从零搭建与调试所需数日时间。 做水文模型的人十个里有八个会在SWAT和SWAT-CUP这对组合上栽过跟头。尤其是当你好不容易把日尺度的TxtInOut跑通导师或者项目甲方突然丢来一句“我们需要小时尺度的模拟结果”时那种从数据到代码再到工具的全面重构感简直让人头皮发麻。这篇文章就是踩过一遍坑之后直接把能跑的SWAT-CUP-Hourly示例TxtInOut文件、cup配置和完整的率定流程给你拆开揉碎讲清楚让你少走两个月的弯路。这个内容适合谁呢正在做SWAT小时尺度模拟、被SWAT-CUP反复报错劝退、或者已经能跑通日尺度但不知道如何切换到小时尺度的研究生和工程师。我会从文件骨架、配置逻辑、实测操作、常见坑点四个维度展开全部是基于我自己在项目里实际跑通后的经验总结。1. 先说清楚SWAT-CUP-Hourly到底是来解决什么问题的1.1 为什么从日步长切到小时步长是个分水岭很多人第一次接触SWAT-CUP用的是日尺度的数据感觉还挺顺利加载TxtInOut选参数跑敏感性分析看P-factor和R-factor一套流程下来模型性能也说得过去。但切换到小时尺度之后一切都变得不一样了。SWAT模型本身是基于物理过程的分布式水文模型它的核心计算单元是水文响应单元HRU日尺度下很多过程比如土壤水再分配、基流退水、融雪都被简化成了日累计量。可一旦把时间步长压缩到小时模型对降雨过程的响应、对土壤入渗的模拟、对洪峰的刻画都会变得敏感得多。这意味着两件事第一你的输入气象数据必须细化到小时不能再用日值插值糊弄过去第二率定的时候需要调整的参数集合、参数取值范围、以及目标函数的定义都和日尺度完全不同。SWAT-CUP-Hourly其实就是SWAT-CUP针对这种小时尺度模拟场景的一个变体它在算法上仍然支持SUFI2、GLUE、ParaSol等常用率定方法但在时间控制、观测数据匹配、目标函数计算这些方面专门适配了小时级的观测序列。很多人在这个环节出错根本原因不是不会操作SWAT-CUP而是没有理解它是怎么把小时观测数据和SWAT的小时输出对应起来的。1.2 这套示例的适用范围与适用人群我下面要讲的这套“SWAT-CUP-Hourly示例TxtInOut文件及cup配置”本质上是一个已经组织好的、可以直接跑通的小型案例。它的TxtInOut文件夹是完整的包含了SWAT模型运行所需要的全部输入输出文件cup配置则已经把SUFI2算法的基本参数、迭代次数、目标变量都设置好了。这套示例的典型适用范围有三个你的研究流域已经完成了SWAT模型构建但还在日尺度阶段需要快速切换到小时尺度。你手头有小时尺度的降雨、气温等气象观测数据但不知道如何把这些数据组织成SWAT-CUP-Hourly能识别的格式。你已经被SWAT-CUP的报错折磨到崩溃需要一个“至少能跑通”的参考模板在此基础上替换成自己的数据。它不是万能的但它是你从零到一最需要的那个“脚手架”。我自己在实际项目中就是靠类似的一套模板把某个山区小流域的时尺度洪水模拟从完全跑不通硬生生调到了纳什系数0.75以上的水平。2. 拿到示例文件后先搞懂TxtInOut和CUP配置的骨架2.1 TxtInOut文件夹里的每个核心文件是干什么的SWAT的TxtInOut文件夹是模型运行时的“工作目录”里面包含了几百个文件新手一看就头大。但你不必每个文件都理解关键的核心文件就那几类。首先是file.cio这是总控制文件。它定义了整个模型运行的主控信息比如模拟开始时间、结束时间、降雨和气温数据的时间步长、输出文件的打印选项等。小时尺度模拟的时候file.cio里的print code必须设置成小时输出这一点很多人会漏掉。如果你跑出来还是日输出SWAT-CUP-Hourly在率定的时候会因为找不到小时序列而直接报错或者匹配错位。其次是气象输入文件。包括降水文件.pcp、气温文件.tmp、相对湿度文件.hmd、风速文件.wnd、太阳辐射文件.slr等。小时尺度下这些文件的行数会爆炸式增长比如日尺度一年365行小时尺度一年就是8760行。而且每一行的时间戳格式、数值精度SWAT都有一套严格定义。这套示例里特意给出了标准的文件名和格式就是为了让你对照着修改。再往下是子流域和水文响应单元文件夹包含.sub子流域文件、.hruHRU文件、.rch河道文件、.swq水质文件等。这些文件里记录了各个空间单元的参数初始值SWAT-CUP在率定过程中会不断修改其中某些参数然后重新调用SWAT做模拟所以这些文件是SWAT-CUP的“操作对象”。最后还有output.rch、output.hru这样的输出结果文件。虽然它们是SWAT模型运行后生成的但SWAT-CUP的读取逻辑是先在TxtInOut里启动SWAT跑完之后去读output.rch或output.hru里面的模拟值再和观测值做比对。所以如果你的file.cio输出设置有问题导致结果文件格式不对SWAT-CUP读不到数据后面全白搭。2.2 SWAT-CUP-Hourly需要的观测数据准备这个环节是很多人的噩梦。SWAT-CUP-Hourly需要两种观测数据一种是时间序列数据比如小时降雨、小时流量存放在observed文件夹或者直接在CUP项目里指定另一种是参数初始值存放在上面说的TxtInOut文件里。观测数据要注意格式第一列时间戳第二列观测值。时间戳的格式必须和你CUP项目里的时间设置完全一致否则会出现“时间段不匹配”的错误。我之前遇到过一种情况流域出口的流量观测数据是UTC时间而模型用的是本地时间结果率定出来的参数完全荒谬后来排查了一个星期才发现是时间偏移的问题。在这套示例里观测数据文件是按照“每小时一行列名清晰”的方式整理的。我建议你在准备自己的观测数据时也统一采用这种格式同时用脚本比如Python的pandas先做一次时间戳对齐和异常值剔除这能省去后面很多麻烦。2.3 文件夹组织的关键思路一个项目对应一个完整TxtInOutSWAT-CUP在实际使用中每个率定项目比如SUFI2.0这个文件夹里都应该放一份完整的TxtInOut副本而不是多个项目共享一个TxtInOut文件夹。为什么因为SWAT-CUP在每次迭代时都会修改TxtInOut里的参数文件如果多个项目共用一份后运行的项目会覆盖掉前一个项目的参数修改结果导致率定结果完全混乱。而且当你需要并行跑多个项目的敏感性分析时各自的TxtInOut独立是最基本的安全保障。所以我通常的做法是先维护一份“干净的基线TxtInOut”专门用来复制分发。每新建一个率定项目就从基线复制一份完整的TxtInOut进去然后再在CUP配置里指定这个新路径。这套示例里的目录结构就是把这一逻辑固化下来了。3. 实操从配置CUP到第一次成功运行SWAT3.1 创建CUP项目并绑定TxtInOut安装好SWAT-CUP之后打开程序选择File-New Project然后输入项目名称。注意项目名称不要带空格和中文否则后面调用的路径解析容易出问题。项目目录选择你准备存放率定文件的地方。关键一步程序会问你SWAT Project也就是TxtInOut文件夹的路径这时候一定要选准。如果你手头有现成的TxtInOut直接指向它的上一级目录让SWAT-CUP自动识别TxtInOut如果你是照着我这套示例的目录结构来的那路径选择应该非常顺手。接下来选择时间设置。这里要特别注意“Warm-up Period”和“Simulation Period”的区分。Warm-up期是为了让模型状态变量比如土壤水含量、蓄水层水位达到平衡一般建议设置至少1年的预热期哪怕你的观测数据只有半年。预热期不会参与率定计算但会影响初始条件。小时尺度下预热期的计算量会非常大所以也需要在预热期长度和计算耗时之间找一个平衡点。然后就是指定观测数据文件。在Observed Data选项卡里加载你的小时流量观测文件。SWAT-CUP-Hourly会要求你选择观测数据的变量类型流量、泥沙、水质等以及模拟结果对应的输出文件类型。流量一般对应output.rch指标选FLOW_OUT。3.2 SUFI2算法的核心参数设置SWAT-CUP-Hourly里最常用的率定算法是SUFI2Sequential Uncertainty Fitting version 2。它的核心思想不是寻找一组最优参数而是通过多次迭代逐步缩小参数的不确定性区间让模型模拟的95%预测不确定带95PPU尽可能覆盖尽可能多的观测数据。第一次打开CUP.ini配置文件你会看到几个关键参数ObjectiveFunctionType目标函数类型一般选择NSENash-Sutcliffe Efficiency如果你更关注洪水过程也可以选logNSE或者KGE。NumberIterations迭代次数。日尺度模拟建议200-500次小时尺度模拟因为计算量大建议一开始设置50-100次先看看参数敏感性和趋势再逐步增加。NumberSimulations每次迭代的模拟次数即拉丁超立方采样次数。默认是500但小时尺度跑一次SWAT非常耗时你可以先降低到100-200跑通流程后再增加。PValue和RValue这两个是判断参数敏感性时用的统计阈值一般保持默认即可。提示小时尺度下SWAT的单次运行时间可能是日尺度的数十倍。我实测一个中型流域约20个子流域100多个HRU日尺度跑一次只要几秒小时尺度跑一次可能要一两分钟甚至更久。如果你设置500次模拟、5次迭代总耗时可能会达到几十个小时。所以建议先用小模拟次数跑通再慢慢加大。3.3 参数选择别把所有参数都一股脑丢进去SWAT-CUP最吸引人的地方在于它可以自动调整几十个参数。但真正有经验的人都知道参数不是越多越好。小时尺度率定的时候我建议重点关注这几类参数地表径流类CN2SCS径流曲线数、SURLAG地表径流滞后系数土壤类SOL_AWC土壤有效含水量、SOL_K饱和导水率地下水类ALPHA_BF基流退水系数、GW_DELAY地下水滞后时间河道类CH_N2曼宁糙率、CH_K2河道有效导水率小时尺度和日尺度在参数敏感性上有一些明显差异。比如SURLAG日尺度下影响不大但小时尺度下它直接影响洪峰的峰值和时间非常敏感。再比如ALPHA_BF它决定了基流的消退速度小时尺度下基流过程线会更细碎这个参数的表现也更加复杂。在这套示例的cup配置里我预置了12个参数每个参数都给出了合理的上下限。你可以直接照用也可以根据自己的流域特点调整。记住一个原则第一次率定参数宁少勿多。跑完一轮敏感性分析之后把那些p值大于0.5、敏感性极低的参数冻结掉只保留真正敏感的参数继续优化。3.4 运行SWAT与第一次迭代的全过程记录配置完成之后点击RunSWAT-CUP会开始每一次迭代的循环调用SWAT模型读取输出结果计算目标函数值更新参数区间。我这里记录一次典型的小时尺度迭代过程以示例项目为例迭代次数100次第1-20次模拟此时参数搜索空间较大目标函数值NSE起伏明显甚至可能出现负值。这是正常的因为SUFI2在第一轮会用较大的参数范围去采样。第21-50次模拟随着采样点的增加目标函数值开始稳定部分参数表现出明显的敏感性。如果某个参数在50次模拟后仍然毫无影响说明它要么不敏感要么初始范围设置太小。第51-100次模拟SUFI2算法会根据前50次的结果重新计算参数范围下一轮迭代会在新的范围内采样。第一次迭代跑完之后SWAT-CUP会自动生成summary.out和goal.out文件。goal.out里有每次模拟的目标函数值summary.out里有参数敏感性分析结果。我第一次跑完小时尺度的100次模拟看到NSE只有0.2左右心里凉了半截但实际不用慌SUFI2的魅力就在于多轮迭代后会逐步收敛。我最终在第4次迭代之后NSE稳定在了0.75以上P-factor和R-factor也达到了较理想的水平。4. 常见问题与排查技巧实录4.1 经典报错模型运行失败或者生成文件缺失这个报错太常见了几乎每个人都会遇到。出现这个错误SWAT-CUP通常会在log文件里写清楚原因但很多人不看log直接百度浪费时间。排查思路如下先查看TxtInOut目录下是否有input.std和output.std文件。input.std是SWAT的标准输入文件output.std是标准输出文件。如果output.std存在打开它最后几行通常会写清楚报错原因比如某个气象数据文件缺失、某个参数越界、时间设置不对。检查file.cio里的时间设置是否和CUP配置一致。尤其是小时尺度下file.cio里的print code和print interval设置错误会导致输出文件缺失。检查TxtInOut文件夹里的气象数据文件是否完整。小时尺度的气象数据文件非常大经常有人在复制过程中漏掉几个文件或者文件名大小写不一致导致SWAT找不到。注意SWAT对中文路径非常不友好。如果你把项目放在D:\我的项目\流域模拟这类包含中文的路径下SWAT-CUP十有八九会报错。建议所有路径都使用纯英文。4.2 目标函数值始终是负数模型模拟结果完全对不上这个问题比较棘手。目标函数为负说明模拟值连观测值的平均水平都没达到基本上等于模型完全没有捕捉到降雨-径流过程。我遇到这种情况优先检查三件事时间格式是否对齐。小时尺度下观测数据的时间步长是不是和模型输出完全一致比如模型输出的是UTC8时间而你的观测数据是UTC时间差了8小时洪峰完全错位NSE自然为负。雨量数据是否进入模型。打开output.rch看模拟的流量值是否出现了“滴水不漏”的情况即全为0或者极小值。如果是多半是降水数据没有正确读取或者降水文件的时间格式错了。参数范围是否合理。比如CN2设成了20-30但你的流域实际是典型的农业区CN2应该在70以上。这种情况下模型始终低流量率定永远不收敛。4.3 敏感性分析结果非常奇怪理论敏感的参数反而不敏感这种情况在小时尺度模型中比较常见。比如CN2在日尺度下极其敏感但小时尺度下却显得无关紧要。原因往往是参数之间存在相关性。比如CN2和SOL_AWC在小时尺度下对洪峰形成的影响存在重叠导致SUFI2的敏感性分析无法区分它们的独立贡献。解决办法有两个检查参数相关矩阵SWAT-CUP的par_corr.txt文件如果两个参数的相关系数超过0.7考虑将其中一个冻结。分组率定。先率定地表径流相关的参数组固定它们之后再率定地下水参数组最后再联合微调。这样能有效避免参数之间的干扰。4.4 常见问题速查表问题现象可能原因解决思路model execution failedTxtInOut路径错误、气象文件缺失、file.cio时间设置问题检查input.std和output.std定位具体报错行模拟结果全为0降水数据未正确读取、file.cio中降雨文件指向错误打开降水文件检查行数、时间范围和数值范围目标函数始终为负时间错位、CN2范围太小、流量单位不统一核对时间戳检查模拟流量与观测流量量级是否一致参数敏感性低参数范围过小、参数间相关性高扩大参数范围检查相关矩阵考虑分组率定多站点模拟结果倒挂不同站点的观测时段不一致为每个站点单独配置观测数据时段率定结果收敛但P-factor极低参数不确定性区间过小95PPU覆盖太少适当扩大关键参数的取值范围增加迭代次数5. 率定结果的判读与收尾5.1 P-factor、R-factor这些指标到底怎么理解SUFI2算法率定完之后判断模型好坏主要看两组指标P-factor和R-factor以及目标函数值NSE、R²、KGE等。P-factor指的是观测数据被95PPU95%预测不确定带覆盖的比例。理想情况下P-factor越接近1越好意味着模型模拟的95%不确定性区间覆盖了几乎全部观测数据。但你别天真地以为P-factor越高就是模型越好因为P-factor是可以靠扩大参数范围来“刷”上去的。R-factor是95PPU带的平均宽度与观测数据标准差之比。R-factor越小说明不确定性带越窄模拟结果越精确。一般建议R-factor小于1但实际操作中R-factor在1-1.5之间也可以接受。这两个指标是相互制约的。参数范围调得过大P-factor会上升但R-factor也会恶化范围太小R-factor倒是好看了但P-factor就会下降。我的经验是先保证P-factor不低于0.6再尽量压缩R-factor。如果两者实在平衡不了优先保P-factor因为从工程应用角度模拟结果覆盖住实测过程比窄区间里的高精度更有意义。NSE方面小时尺度模型的NSE达到0.6以上就算合格0.75以上属于优秀。但注意小时尺度和日尺度的NSE不具备直接可比性因为时间步长越短洪峰误差被放大的程度越高。所以如果你看到日尺度的NSE是0.85小时尺度调了半天停在0.7别沮丧这已经是比较理想的结果了。5.2 小时尺度率定的一些独特策略最后分享几个小时尺度率定独有的策略都是从实际项目里磨出来的经验。第一目标函数选择上如果洪水过程是你的重点优先选择logNSE或者包含洪峰权重系数的目标函数不要让基流段的“高分”掩盖了洪峰段的“低分”。小时尺度下基流起伏不大很容易让NSE虚高但洪峰处误差依然很大。第二分时段率定。把观测序列分成湿润期和干旱期两段分别查看模拟效果。如果湿润期洪峰偏低重点调整CN2和SURLAG如果干旱期退水过程对不上重点调ALPHA_BF和GW_DELAY。这种“分症状给药”的策略比盲目调参高效得多。第三利用SWAT-CUP的并行计算功能。如果你的电脑是多核的在CUP.ini里把并行核数调大。小时尺度模型计算量巨大并行与否对时间成本的影响非常显著。实测下来4核并行比单核运行能节省70%以上时间。第四一定要保留率定过程中的中间结果。每跑完一轮迭代把TxtInOut和CUP项目整个复制一份。这样即使后面某个实验方案把参数调坏了也能快速回滚到上一个稳定状态不至于重新开始。5.3 示例配置的终极使用建议这套SWAT-CUP-Hourly示例TxtInOut文件和cup配置最大的价值不是直接给你一套“完美的”参数结果因为每个流域的物理特性不同而是给你一个“保证能跑通”的起点。我建议你把它的目录结构、配置文件格式、数据组织方式当做一个模板然后逐步替换成你自己的流域数据。具体步骤如下先保留示例的原有数据完整跑一遍确认SWAT-CUP-Hourly在你的电脑上能运转。在示例基础上把自己的小时尺度气象数据替换进TxtInOut先不换流域参数看看模型是否还能运行模拟值是否在合理范围内。再替换掉空间数据子流域、HRU文件这时候大概率会出现各种报错用我在第4部分总结的排查表逐个解决。最后替换观测数据开始你自己的率定迭代。这个过程下来你就不是“照抄配置”而是真正理解了SWAT-CUP-Hourly的运作机制。我个人在实际操作中的体会是很多工具不是难在概念而是难在“从零到一”这个初始环节。只要第一个完整流程能稳定跑通后续所有的调参、优化、策略升级都只是工作量的问题。希望这套示例和这份实操记录能帮你把最痛苦的“跑通”这一步跨过去。本文还有配套的精品资源点击获取