ArcSWAT模型Error 63输出转换错误：成因解析与系统化解决方案

2026/6/16 2:58:13

1. 项目概述：当ArcSWAT模型运行遭遇“拦路虎”

如果你正在使用ArcSWAT进行流域水文模拟，并且模型运行到一半突然弹出一个令人头疼的“forrtl: error (63): output conversion error”，那么你找对地方了。这个报错是ArcSWAT用户，尤其是处理大流域或复杂气象数据时，经常遇到的一个经典“坑”。它不会在模型设置阶段出现，而是在你满怀期待点击运行，模拟进行了一段时间后突然中断，所有的进度戛然而止，只留下这个含义模糊的错误代码。

简单来说，Error (63) 是一个“输出转换错误”，根源在于SWAT模型（ArcSWAT是其ArcGIS界面）的Fortran核心在尝试将计算出的数据写入结果文件时，遇到了它无法理解或格式不符的数据。想象一下，你让一个只懂英文的秘书去抄写一份中文文件，当ta遇到不认识的汉字时，工作就会卡住并报错。Error (63) 就是SWAT的Fortran程序在“书写”结果时，碰到了那个它不认识的“汉字”。

这个错误之所以棘手，是因为它指向的是模型内部运行过程，而非我们直观的GIS操作。错误信息通常伴随着一个文件单元号（如unit 28, file = output.hru），这是我们排查的关键线索。它告诉我们错误发生在写入哪个输出文件时。本文将彻底拆解这个问题的成因，并提供一套从快速排查到根治的完整解决方案，涵盖从数据预处理、模型配置到调试技巧的全流程。无论你是水文专业的学生，还是从事流域管理的工程师，这套方法都能帮你高效扫清这个障碍，让模型顺利跑起来。

2. 错误根源深度解析：为什么是“输出转换”？

要解决问题，必须先理解其根源。Error (63) 不是一个随机的bug，而是SWAT模型严格数据格式要求与输入数据质量之间矛盾的集中体现。

2.1 Fortran 格式化写入的“洁癖”

SWAT模型的核心计算模块由Fortran语言编写。Fortran在进行文件写入（WRITE语句）时，如果使用了格式说明符（FORMAT），就会对数据的格式有极其严格的要求。这个格式在模型代码中预先定义好了，规定了每个数据应该占多少字符宽度、是整数还是浮点数、小数点位置在哪。

当模型计算出一个值，比如某个HRU（水文响应单元）的土壤含水量为-0.099，并试图按照格式(F10.3)（表示一个总长10字符、含3位小数的浮点数）写入文件时，程序会检查-0.099这个值能否被完美地放入这个“10字符的盒子”里。大部分情况下没问题。但是，如果计算出的值超出了格式的容纳范围，例如：

数值太大或太小，导致字符串长度超过10位（如-12345.6789）。
产生了非数字的异常值，如NaN（非数）或Inf（无穷大）。
一个非常常见的情况：数值本应是整数（如天气发生器的状态码），但格式要求是浮点，或者反之，导致类型不匹配。

此时，Fortran运行时就会抛出error (63): output conversion error，意为“输出转换失败”。

2.2 错误触发器：问题数据的来源

那么，是什么导致了这些“不合规”的数据产生呢？根源通常在上游：

气象输入文件（.pcp, .tmp, .slr, .wnd, .hmd）格式错误：这是导致Error (63)的最常见原因。SWAT要求气象数据文件是严格的空格分隔或固定宽度的文本格式。
- 缺失值处理不当：SWAT使用特定数值（如-99或-99.0）表示缺失数据。如果你的数据中缺失值标记为-099、-99.、-99.000或NaN，而模型代码预期的是-99，就会在后续计算中引发问题。
- 数据列错位：一个空格多了或少了，会导致整列数据被误读。例如，降水量列的数据被读成了温度，可能产生极不合理的大数值。
- 科学计数法：某些软件导出数据可能使用-9.9E-03这样的科学计数法，而SWAT的Fortran读取格式可能未预设这种形式。
模型参数极端化：在模型校准或手动调整时，如果将某些参数（如CN2、SOL_K）设置得极其不合理，可能导致模型计算出的水文过程量（如径流、蒸散发）在物理意义上异常，产生巨大或极小的数值，超出输出格式的承载范围。
土地利用/土壤/坡度数据重分类错误：在创建HRU时，如果土地利用、土壤或坡度类别的编码或面积数据存在异常，可能导致某些HRU的面积计算为0或负值，进而在后续计算中引发连锁错误。
模型初始状态不稳定：在模型“预热期”（Warm-up Period）内，模型的水文状态（如土壤水、地下水储量）还未达到动态平衡。如果预热期太短，模型带着不稳定的初始状态进入正式模拟期，可能会在初期产生剧烈的数值震荡，触发错误。

注意：错误信息中提到的文件（如output.hru）是错误发生地，不一定是错误源。问题可能早在读取气象数据、进行汇流计算时就已种下，直到程序要将这个错误结果写入报告文件时才暴露。

3. 系统化诊断与排查流程

面对Error (63)，不要盲目尝试。遵循一个系统的排查流程，可以事半功倍。下图清晰地展示了从错误出发，逐步定位问题根源的完整路径：

flowchart TD A[遭遇 Error(63) 报错] --> B{解析错误信息<br>定位出错文件}; B --> C[检查对应输出文件<br>的写入格式与数据]; C --> D{发现异常数据?}; D -- 是 --> E[溯源异常数据<br>至源头输入文件]; D -- 否 --> F[检查模型参数与<br>初始条件合理性]; E --> G[修正输入文件格式<br>（如 -099 改为 -99）]; F --> H[调整极端参数<br>或延长预热期]; G --> I[使用文本编辑器与<br>脚本工具验证修正]; H --> I; I --> J[重新运行模型验证]; J --> K{问题是否解决?}; K -- 是 --> L[✅ 问题解决]; K -- 否 --> M[启用模型调试输出<br>（Print.prt）进行深度诊断]; M --> N[分析调试日志<br>定位计算异常步骤]; N --> O[修正核心计算逻辑<br>或数据问题]; O --> J;

3.1 第一步：精准定位错误现场

首先，仔细阅读完整的错误信息。它通常长这样：

forrtl: error (63): output conversion error, unit 28, file D:\Swat_Project\Scenarios\Default\TxtInOut\output.hru

关键信息是unit 28和file ...\output.hru。这说明错误发生在尝试写入output.hru文件时。SWAT有多个输出文件，每个对应一个单元号，常见的有：

output.rch: 河段输出
output.sub: 子流域输出
output.hru: HRU输出
output.pcp: 降水摘要（如果开启）

记下这个文件名，它是我们调查的起点。

3.2 第二步：检查与修正输入数据（最常见解决方案）

根据流程图，绝大多数Error (63)源于输入数据，尤其是气象数据。

1. 检查气象数据文件（.pcp, .tmp等）：这是排查的重中之重。前往你的项目TxtInOut目录，用纯文本编辑器（如Notepad++、VS Code、UltraEdit）打开.pcp文件。绝对不要用Excel直接打开保存，Excel会破坏格式。

查找格式错误：检查文件头部描述行之后的数据部分。确保数据是空格分隔，并且每行的列数一致。特别留意负号和小数点。
修正缺失值：搜索-099、-99.、-99.000等变体，统一替换为-99（对于降水、温度等文件）。这正是网络资料中提到的核心解决方法。在Notepad++中，你可以使用“查找替换”功能（Ctrl+H），选择“查找模式”为“普通”，将-099替换为-99。务必注意，有些行可能因为对齐问题，负号和数字间有空格（如- 99），也需要修正。
验证数据范围：快速浏览数据，看是否有明显超出合理范围的值，例如日降水量超过2000mm，日温超过60°C等。

2. 检查其他输入文件：

.fig（子流域连接）文件：确保编码连续，无重复。
soils.sol和plants.plt等数据库文件：确保参数列格式正确，没有非数字字符。

实操心得：

我强烈建议在将外部数据导入SWAT前，先用Python或R写一个小脚本进行数据清洗和格式验证。脚本可以检查缺失值标记、数值范围、日期连续性等。这能从根本上杜绝大部分格式错误。例如，一个简单的Python pandas检查：df.replace(-099, -99, inplace=True)和df.to_csv('fixed.pcp', sep=' ', index=False, header=False, float_format='%.3f')可以标准化格式。

3.3 第三步：审查模型参数与设置

如果数据文件无误，问题可能出在模型内部。

检查HRU定义：在ArcSWAT中，重新运行“HRU分析”步骤，确保没有HRU的面积为零或极小。可以导出HRU报告进行检查。
审查敏感参数：回顾你修改过哪些参数。特别是：
- CN2（径流曲线数）：是否设置得过低（<35）或过高（>98）？
- SOL_K（土壤饱和导水率）：单位是mm/hr，是否出现了不合理的极大值（如>1000）？
- ESCO（土壤蒸发补偿系数）、EPCO（植物吸收补偿系数）是否在0-1之间？
延长预热期：在SWAT模拟设置中，将“预热期”（Warm-up Period）延长至2-3年。这给模型足够的时间从初始的默认状态调整到与实际气候条件相适应的平衡状态，可以避免初期计算震荡导致的错误。

4. 高级调试与根治方法

当上述常规方法都无效时，我们需要更深入的调试手段。

4.1 启用模型详细输出（Print.prt文件）

SWAT模型有一个强大的调试功能，即生成print.prt文件。这个文件记录了模型运行每一步的关键变量状态。

在TxtInOut目录下，找到名为file.cio的文件。
用文本编辑器打开它，找到其中一行，控制着打印输出的详细程度。通常该行数字为0（不打印）或1（基本打印）。为了调试，将其改为一个较大的数字，例如50或100。这会让模型输出极其详细的计算日志。
重新运行模型。虽然会因为Error (63)再次中断，但此时会生成或更新print.prt文件。
打开print.prt，从文件末尾开始向上看。错误发生前最后几行打印的信息，就是导致崩溃的“案发现场”。你会看到具体的子流域、HRU编号、以及计算出的问题数值。这能帮你将错误范围从整个流域缩小到某个特定的水文过程或空间单元。

4.2 隔离法与二分法定位

如果模型很大，运行一次耗时很长，可以采用“二分法”快速定位：

时间二分：在file.cio中，将模拟总天数减少到原来的1/4或1/2。如果错误消失，说明问题出现在模拟后期；如果错误依旧，说明问题在模拟前期。逐步缩小时间范围，定位出错的具体时间段。
空间二分：创建一个极简的测试项目。只保留一个子流域、一种土地利用和一种土壤类型。如果简单模型能跑通，再逐步添加复杂性（更多子流域、HRU），直到错误复现，从而定位是哪个地理单元或数据组合引发了问题。

4.3 处理特殊案例：太阳辐射数据问题

网络热词中提到了“arcswat太阳辐射量计算公式”，这指向了一个特定场景。太阳辐射数据（.slr文件）的缺失值处理不当也是常见诱因。

SWAT模型可以使用实测太阳辐射数据，也可以通过公式（如Hargreaves公式）从日最高/最低温度计算。如果你使用实测数据，务必检查.slr文件中的缺失值标记，同样应使用-99。
如果你让SWAT自动计算太阳辐射，请确保.tmp（温度）文件的数据质量。异常的温度值会导致计算出的辐射值异常巨大或微小，进而触发错误。

常见问题速查表

问题现象	可能原因	排查步骤	解决方法
错误指向`output.hru`	某个HRU的产出计算异常	1. 检查该HRU对应的土壤、土地利用参数。 2. 检查流入该HRU的气象数据。	修正异常参数；检查并清洗气象输入文件。
错误指向`output.rch`	河道汇流或水质计算异常	1. 检查河道参数（CH_K2, CH_N等）。 2. 检查从上游HRU/子流域汇入的负荷。	调整不合理的河道参数；回溯上游单元的输出。
模型在特定日期报错	输入数据在该日期存在异常	1. 定位报错时间点。 2. 检查所有气象文件在该日期的数值。	修正该日期错误或异常的气象数据。
仅在使用自备气象数据时报错	数据格式或内容不符	1. 对比SWAT自带天气生成器数据格式。 2. 检查自备数据的单位、分隔符、缺失值标记。	严格按照SWAT手册要求格式化数据。
延长预热期后错误消失	模型初始状态不稳定	检查模型初始含水量等设置。	确保预热期足够长（通常2-3年）。

5. 预防措施与最佳实践

与其在报错后耗费时间调试，不如在项目开始时就建立规范，防患于未然。

建立数据预处理流水线：
- 对所有输入气象数据，在导入ArcSWAT前，先用脚本进行标准化清洗：统一缺失值为-99，确保小数点格式一致，剔除超出物理范围的值。
- 使用awk、sed或Python脚本批量处理数据文件，效率远高于手动编辑。
参数调整采用“小步快跑”策略：
- 在校准模型参数时，避免一次性对大量参数做剧烈调整。每次调整后，先进行短期（如1年）的试运行，确认模型稳定后再进行长期模拟。
项目文件管理：
- 为每个重要的模型修改版本创建独立的项目文件夹或使用版本控制（如Git）的标签功能。一旦出现错误，可以快速回退到上一个能正常运行的版本。
善用ArcSWAT的验证工具：
- 在运行完整模拟前，充分利用ArcSWAT界面中的“写入输入表”和“查看输入摘要”功能。这些摘要报告有时能提前暴露出一些明显的输入问题。

我个人在处理了数十次Error (63)后最大的体会是：这个错误几乎总是“数据清洁度”问题的体现，而非模型本身的缺陷。它强迫建模者以更严谨的态度对待输入数据。每次解决它，都让我对SWAT模型的数据流和内部逻辑有了更深一层的理解。养成好的数据准备习惯，这个“拦路虎”将不再可怕，反而会成为你模型构建工作流程是否规范的一块试金石。最后一个小技巧：在团队协作中，建立一个共享的、经过验证的“干净”气象数据库，能从源头上为所有成员省去大量调试时间。