企业官网建设流程全解析

简介：本资源是一套可直接运行的SWAT-CUP小时尺度水文模型率定完整配置包，面向水文水资源、环境科学及农业面源污染模拟领域的科研人员与研究生，解决SWAT模型 hourly 输入构建难、CUP参数率定配置复杂、多文件类型协同易出错等实操痛点。压缩包含2000个文件，总大小41.69MB，涵盖281个子流域排水文件（sdr）、260个地下水模块（gw）、257个水文响应单元（hru）与土壤（sol）、242个化学过程（chm）、239个管理措施（mgt）等核心SWAT输入类型，并包含bat批处理脚本、ini配置文件、sqlite数据库及关键输出模板，结构严格匹配SWAT-CUP SUFI2工作流。已有414人学习下载，用户可开箱即用：一键执行率定流程、复现标准hourly模拟结果、快速理解TxtInOut目录组织逻辑，并基于现有配置开展本地化参数优化与敏感性分析。 做SWAT模型小时尺度模拟的人，迟早会在SWAT-CUP-Hourly这一步卡一下。这不是说SWAT-CUP本身有多难，难的是你既要会配TxtInOut文件，又要懂cup配置里的每一个参数到底在干什么。最近我拿到一套可以成功运行的SWAT-CUP-Hourly示例TxtInOut文件及cup配置，花了两天时间从头到尾把它跑通、跑明白，这篇文章就把整套流程里的关键环节捋一遍，顺便把容易踩坑的地方标出来。不管你是刚接触SWAT模型的新手，还是已经跑过日尺度、正想往小时尺度过渡的人，这套示例配置都能帮你省掉大量摸索时间。

1. 示例配置的整体逻辑：TxtInOut、cup配置和率定之间是什么关系

1.1 三者的角色划分

先理清一个基础问题：SWAT-CUP-Hourly、TxtInOut文件和cup配置，这三样东西各自负责什么。

TxtInOut文件夹是SWAT模型真正的“输入输出工作台”，里面装的是流域划分结果、HRU属性、气象驱动数据、土壤参数、管理措施，以及模型运行后的输出文件。说白了，SWAT计算引擎读的就是这个文件夹里的文本文件。你做的所有参数修改、率定调整，最终都要落到这里面的某些文件上。

SWAT-CUP-Hourly是SWAT-CUP针对小时尺度模型推出的独立版本。它做的事情可以概括为：接管TxtInOut文件夹，批量修改参数，反复调用SWAT计算引擎，然后把模拟结果和实测数据做统计对比，最终帮你找到一组让模拟值最接近实测值的参数组合。它支持SUFI-2、GLUE、ParaSol、MCMC等多种算法，其中SUFI-2因为迭代效率高、对新手友好，是绝大多数人入门的选择，这套示例配置用的也是SUFI-2。

cup配置指的是SWAT-CUP运行所需要的整套设置文件，包括参数定义文件、观测数据文件、目标函数设置、迭代次数、算法参数等。这些配置和TxtInOut一起工作：配置负责“怎么调”，TxtInOut负责“被调”。

这样解释之后，你就明白为什么标题里“示例TxtInOut文件及cup配置”能连在一起说了——这两样是SWAT-CUP-Hourly能跑通的两个必要条件，缺一个，程序要么报错，要么调了半天参数根本不生效。

1.2 为什么hourly版本比日尺度更容易“跑不动”

很多人在日尺度SWAT模型上跑得挺顺，一换到SWAT-CUP-Hourly就四处碰壁，这不是软件问题，而是小时尺度模拟对整个数据链的要求上了一个台阶。

首先是气象数据。日尺度模型需要的是日降水量、日最高最低气温，这些数据相对容易获取，很多公开数据集都能直接下载。但小时尺度模型需要的是逐小时降水、逐小时温度，甚至需要小时风速和相对湿度。数据量变大只是其一，数据质量才是关键——小时尺度降水数据的缺测、异常峰值会被模型放大，直接影响径流模拟效果。

其次是计算耗时。同样的模拟时段，hourly版本的计算量是日尺度的24倍，SWAT-CUP一次迭代要跑几百次模型调用，时间成本肉眼可见地上升。用这套示例配置跑的时候，我测过一次迭代500组参数、模拟3年的数据，耗时大约是日尺度模型的6到8倍。这个成本决定了你必须先确认TxtInOut文件和cup配置完全正确，再开始率定，否则一次错误的配置可能浪费你半天时间。

再次是参数敏感性变化。小时尺度的产汇流过程对土壤水力参数、河道曼宁系数、基流退水系数等参数的响应更加敏感，峰值的模拟难度远高于日尺度。这就导致率定过程中更容易出现“总水量对得上，但洪峰完全不对”的情况。

1.3 拿到示例文件后第一件事：不要双击运行，先做静态检查

这是我最想强调的一点。这套示例TxtInOut文件虽然被验证过可以成功运行，但不代表你下载解压后直接运行就能得到理想结果。每台电脑的路径不同、SWAT版本不同、甚至操作系统语言不同，都可能导致运行失败。

正确做法是先把示例文件夹完整看一遍，检查三件事：文件夹路径是否包含中文或空格、TxtInOut内部文件是否齐全、cup配置里的路径是否指向正确的TxtInOut位置。这三项看着简单，但80%的“跑不通”问题都出在这里。后面我详细拆解每一步怎么做。

2. TxtInOut示例文件详解：目录结构、核心文件和气象数据检查

2.1 一份能正常运行的TxtInOut应该包含哪些文件

这套示例TxtInOut文件是在ArcSWAT或QSWAT完成流域模拟后自动生成的标准结构。打开文件夹，你会看到十几类文本文件，我按功能把它们分成四组：

第一组是全局控制文件，核心是file.cio。它是整个模型的“总指挥”，SWAT引擎运行时第一个读的就是它。里面记录了模拟起止时间、气象站点数量、输出文件选项、各输入文件的文件名和路径索引。如果file.cio里的配置和实际文件对不上，模型直接报错退出。

第二组是静态参数文件，包括流域级参数文件（.bsn）、土壤属性文件（.sol）、HRU属性文件（.hru）、管理措施文件（.mgt）、地下水文件（.gw）、河道文件（.rte）、水质文件（.swq）等。这些文件在率定过程中是SWAT-CUP主要的“改造对象”。比如你要调CN2（径流曲线数），改的就是.bsn文件；要调SOL_AWC（土壤有效含水量），改的是.sol文件。

第三组是气象驱动数据。示例中可以看到降水、温度等数据文件，日尺度模型一般是.dbf格式或文本格式，hourly模型则会有专门的逐小时数据文件。这一组文件不参与参数率定，但它们的数据完整性和格式正确性直接决定模型能不能算下去。

第四组是输出文件，比如output.rch（河道输出）、output.hru（HRU输出）、output.sub（子流域输出）、output.std（运行状态日志）。SWAT-CUP做率定时，读取的就是output.rch里的模拟径流数据。

拿到示例后，建议按这个分组核对一遍。缺了哪个静态参数文件，模型跑几步就会中断；缺了气象数据文件，file.cio一读取就会报错。

2.2 file.cio是所有配置的起点：关键行要逐项核对

file.cio虽然是一堆看起来杂乱的数据行，但每行都有固定含义。我建议你用记事本或Sublime打开，对照下表逐项核对：

在hourly版本中，最关键的还有时间步长设置。你需要在file.cio中确认模型的时间步长与气象数据的步长一致，否则SWAT会把小时数据当作日数据处理，结果完全失真。示例配置里时间步长已经设好，但如果你要移植到自己的流域，这一点最容易忽略。

2.3 气象数据子文件夹和数据格式检查

hourly模型的TxtInOut通常会在气象数据相关位置标明每个文件的路径，你需要在file.cio中确认这些路径指向的文件夹确实存在，并且里面的数据文件格式完全符合SWAT对hourly数据的定义。示例中提供的是整理好的格式，字段顺序建议不要随意改动。

一个小技巧：把file.cio里指向的第一个降水站文件用记事本打开，看前20行数据。SWAT对气象数据的读取是固定格式的，年份、月份、日期、小时、降水量必须按列排好。如果日期格式是“2020/1/1”而不是“20200101”，读数据时很容易出现错位，而且这种错位不会立即报错，会让你的模拟结果曲线整体偏移。

2.4 输出文件是率定的“原材料”，必须确认生成正常

SWAT-CUP做率定，靠的是读取TxtInOut运行后生成的output.rch。如果output.rch没有正常生成，或者里面的河段编号和观测数据对不上，后面全白搭。

你可以在第一次手动运行SWAT引擎后，打开output.std文件检查是否有“successfully run”之类的结束提示。output.std保留了模型运行过程中的所有警告和错误信息，这是排查问题的一手资料。示例TxtInOut之所以“能成功运行”，就是因为它的output.std里没有致命错误，各项输出文件都能完整生成。

3. SWAT-CUP-Hourly的cup配置实操：从目录规划到参数文件填写

3.1 配置前先做好目录规划，别把TxtInOut和cup目录搞混

SWAT-CUP运行时会自动生成一个工作目录，里面会放置一份TxtInOut的副本用于参数修改。这意味着你原始的TxtInOut文件可以保持不动，SWAT-CUP每次会在副本上做“实验”。这一点对新手来说特别重要：很多人直接在原始TxtInOut上操作，参数被改乱了之后，想恢复只能重新跑一遍SWAT模型。

我推荐的目录布局是这样的：

D:\SWAT_Project\ ├── TxtInOut\ # 原始TxtInOut，保持只读 ├── SWAT_CUP_Hourly\ # SWAT-CUP-Hourly程序目录 │ ├── SUFI2.def │ ├── par_inf.txt │ ├── observed.txt │ └── ...

SWAT-CUP-Hourly程序目录下的TxtInOut子文件夹，不是手动创建的，而是由程序在第一次运行时自动从你指定的路径复制生成的路径。你只需要在cup配置里告诉程序“原始TxtInOut在哪里”。示例配置中已经写好了这一项，你把它改成你自己电脑上的实际路径即可。

3.2 SUFI2.def和par_inf.txt：参数范围是率定的灵魂

在cup配置里，两个文件决定了率定的正确性和效率：SUFI2.def和par_inf.txt。

par_inf.txt是参数定义文件，每一行定义一个待率定参数。标准格式是：

参数序号 参数名.文件名 参数所在文件缩写 取值范围下限 上限 调整方式

比如：

p1 R_CN2.bsn rcn .bsn 35 98 Replace p2 V_ALPHA_BF.gw gw .gw 0.0 0.5 Replace p3 A_SOL_AWC().sol sol .sol 0.0 0.4 Replace

这里R_表示相对调整，适合CN2这种受初始值影响大的参数；V_表示直接替换，适合基流退水系数这种直接用新值覆盖的参数；A_表示在原有值上加一个量，适合土壤属性这类已经有物理意义初值的参数。示例配置里已经选好了适合hourly模型的一组参数，你可以直接沿用，也可以根据自己流域的特点增删。

SUFI2.def文件里包含的是算法层面的配置，比如迭代次数、模拟组数、目标函数选择、95PPU计算设置等。示例中的配置是经过验证的合理参数：单次迭代500组、目标函数默认NSE，这个配置对大多数流域都能在3到5轮迭代内收敛。如果你觉得计算太慢，可以把迭代组数降到300；如果模拟时段很长，也可以降到200，但精度的稳定性会略微下降。

3.3 observed.txt：观测数据的格式和单位决定拟合质量

observed.txt是实测数据文件，格式是：日期、时间步长、观测值、权重、河段编号。hourly模型的观测数据必须是逐小时尺度的径流值，单位建议和模型输出单位保持一致。

我的建议是先看示例里的observed.txt，理解它的格式，再替换成你自己的观测数据。特别注意三点：

第一，时间分辨率必须严格逐小时，有缺测的行要么补全，要么整段删除。SWAT-CUP按行号读取观测数据，中间出现缺行不会报错，但会导致时间错位。

第二，河段编号要和output.rch里的河道编号一致。你可以在TxtInOut的output.rch文件里查看模拟输出的河道编号，然后在observed.txt里写上对应的编号。编号对不上，哪怕模拟结果很准，拟合指标也一塌糊涂。

第三，单位统一。SWAT输出径流默认单位是m3/s，如果你的观测数据是m3/h，需要先换算再填进去，不然率定出来的参数会系统偏移。

3.4 程序调用关系确认：SWAT-CUP怎么调用SWAT引擎

SWAT-CUP-Hourly本身不包含SWAT计算引擎，它需要调用TxtInOut文件夹里配套的可执行程序（通常是swat.exe或swat2012.exe）。在cup配置中，有一个设置项专门指定这个可执行文件的位置。示例配置已经把这一步做好了，但如果你换了一台电脑、或者SWAT版本不同，需要确保可执行文件存在于指定路径。

有个很隐蔽的坑：SWAT-CUP在Linux和Windows上调用可执行文件的方式不同。Windows下如果你用的是ArcSWAT配套生成的swat.exe，注意看是不是32位程序。如果系统是64位而程序是32位，一般也能运行，但个别情况下会报内存分配错误。示例配置里如果卡在“calling swat.exe”这步，优先检查这个。

4. 从启动到率定完成：完整运行流程与结果判读方法

4.1 第一次运行：看日志，别只看界面

在SWAT-CUP-Hourly的主界面上，点“Run”开始迭代之后，程序会按顺序做三件事：复制TxtInOut到工作目录，修改参数文件，调用SWAT引擎计算。每次调用结束，都会生成新的output.rch文件。

新手最容易犯的错是盯着界面进度条看，却忽略输出日志。我建议第一次运行时，直接把工作目录下的输出日志文件打开，实时观察错误信息。如果某次模拟因为参数越界导致计算崩溃，日志里会留下明确记录，而不是只显示“模拟失败”之类的笼统提示。

另外，第一次运行可以先把迭代组数调小一点，比如50组，主要目的是验证整个链路是否打通。50组跑通了，再改成500组做正式率定。这个验证步骤能帮你省下大量时间。

4.2 读懂敏感性分析结果：t-stat和p-value怎么用

SUFI-2算法跑完一轮迭代后，SWAT-CUP会输出敏感性分析结果，核心指标是t-stat和p-value。t-stat的绝对值越大，说明这个参数对模拟结果的影响越显著；p-value越小（通常小于0.05），说明这个影响在统计上显著。

实际操作中我一般这样判断：

示例配置里选的参数基本都在“中等到强敏感”区间，如果你换上自己的流域后某个参数变成了完全不敏感，别急着加大范围，先确认是不是参数本身在该流域就不起主要作用。

4.3 拟合效果指标：NSE、R2、PBIAS、RSR怎么看

率定效果好不好，最终要看几个统计指标。SWAT-CUP会根据目标函数设置输出NSE（Nash-Sutcliffe效率系数）、R2、PBIAS和RSR等，我列一下常用判断标准：

hourly模型的率定难度比日尺度高，NSE能稳定在0.7以上已经算相当不错。如果你的指标一直上不去，先别急着继续迭代，回头看看是不是气象数据质量问题，或者观测数据和模拟数据的河道编号对不上。

4.4 多轮迭代与验证集验证：率定不是一轮的事

SUFI-2算法的核心思想是“逐步缩小参数范围”。第一轮迭代得到的参数可行区间往往很宽，你需要根据敏感性分析结果和拟合指标，手动调整每个参数的上下限，然后进行第二轮、第三轮迭代。一般来说，当NSE提升幅度小于0.02，或者参数范围已经收敛到初始范围的20%以内，就可以认为率定完成了。

率定完成后，一定要用验证期的数据做一次独立验证。把率定期得到的最终参数固定住，让SWAT-CUP调用TxtInOut在验证期运行，看验证期的NSE和PBIAS是否仍在可接受范围内。如果率定期效果很好但验证期很差，说明模型过拟合了，要回到参数选择环节，减少参数数量或缩小范围。

5. 常见问题速查表与独门避坑经验

5.1 高频问题速查

5.2 我踩过的三个真坑

第一个坑是路径问题。我一开始把工程放在带中文的目录下，SWAT-CUP每次运行到一半就无故中断，日志里没有任何明确错误，后来把整个工程移到D盘英文路径下才解决。这不是SWAT-CUP独有的问题，很多水文模型对路径编码都很敏感。

第二个坑是气象数据时间错位。我的降水数据里有一个月的时间和日期列写错了，导致自动替换时把某天的降水记为前一天的数据。这个错误在日尺度模拟里可能只是让峰值偏差几天，影响不算大，但在hourly模拟里直接让洪峰时间偏移了好几个小时，NSE直接跌到0.3以下。后来我写了一个小脚本自动校验时间序列的连续性，才避免再发生这种问题。

第三个坑是忽略了output.rch里河段编号的对应关系。我有一次率定某个小流域，观测数据用的是2号监测站，但output.rch里对应的河道编号是5，结果率定了5轮都没收敛，最后偶然翻开output.rch才发现编号对不上。这个小问题浪费了我整整两天时间。

5.3 一个提升效率的检查脚本思路

如果你准备长期做SWAT率定，建议写一个简单的批量检查脚本，自动检查TxtInOut文件夹的完整性和气象数据的时间连续性。不需要多复杂，能完成两件事就行：一是列出缺失的文件名，二是检查气象数据文件里的时间序列是否连续、是否有重复值。这套配置里也可以用，每次新建工程时先跑一遍，能避免大量低级错误。

6. 这套配置的迁移价值：从示例流域到你自己的研究区

6.1 如何把示例配置复用到自己的流域

示例TxtInOut和cup配置最值钱的地方，是给你提供了一套“已验证的配置模板”。换到自己的流域时，你需要做的是保留cup配置的框架，替换TxtInOut里的流域相关文件。

具体步骤是：先在自己的SWAT模型里完成流域划分、HRU生成、气象数据输入，得到一份新的TxtInOut文件夹并确认能独立运行；然后把示例TxtInOut里的file.cio替换为新流域的file.cio，同时删除旧流域的静态参数文件，放入新流域的对应文件；最后在cup配置里指向新的TxtInOut路径，重新设置观测数据即可。

需要注意，示例配置中的参数初值和范围是基于示例流域的，换到自己流域后一定要结合当地水文特征重新设定，不能直接照抄。

6.2 小时尺度SWAT模型适合做什么

小时尺度（hourly）SWAT模型主要面向短历时强降水过程，特别适合以下场景：中小流域的洪水预报研究、城市洪涝风险评估、极端暴雨事件的水文响应分析、梯级水库入库流量模拟等。这些场景的共同特点是过程时间短、峰值流量大、对时间分辨率要求高，日尺度模型无法准确捕捉关键过程。

如果你是从日尺度切换到小时尺度，建议先从降雨比较集中的湿季数据入手，先确认模型在该时段内峰值模拟是否合理，再扩展到全年连续模拟。

6.3 新手学习路线建议

如果你刚接触SWAT模型，我的建议是不要一上来就碰hourly版本。先花一到两周把日尺度模型的完整流程跑通：从DEM处理、流域划分、HRU生成到气象数据输入、模型运行、结果导出，这个过程能让你对整个数据流有直观认识。然后，再把自己跑通的TxtInOut接入SWAT-CUP，用这套示例的cup配置做第一次率定。日尺度率定熟练之后，再切换到hourly版本，你会发现很多概念是相通的，真正需要额外学的只是数据格式和时间步长配置。

最后再分享一个小技巧：每次率定迭代结束时，都保留一份当时的参数文件和结果指标截图。率定是一个反复试错的过程，记录下每一轮的参数改了什么、指标变化了多少，能让你在后续分析中少走很多弯路。我自己每次新建工程都会同步建一个“实验记录”文档，跑了几轮、每轮改了哪些参数、结果如何，全部记清楚。看起来麻烦，实际坚持下来，比任何教程都管用。

本文还有配套的精品资源，点击获取