跑WRF的兄弟多少都有这种经验模式积分了一多半眼看d01区域的数据都快写完了日志还在正常输出突然屏幕一黑rsl.error尾部没有FATAL系统直接丢给你一句Segmentation fault (signal 11)。我第一次遇到时以为是编译环境的问题把源码从头配了一遍折腾三个小时才发现问题根本不在编译上。WRF积分d01区域数据快结束时报这个错几乎是每个跑业务模拟的人迟早要撞上的坑但它其实没那么玄多数情况下靠日志、文件大小、系统限制和输入数据就能锁定根因。这篇文章就围绕Segmentation fault (signal 11)这个信号展开适合两种人看一是刚接触WRF、跑嵌套模拟时经常遇到段错误但不知道怎么下手的新手二是已经在长期积分时反复踩类似问题、却被“换核数”、“换编译器”这类方法带偏的老手。我会按真实排障顺序来写先解释段错误是什么再讲现场保护和常见元凶最后用几个脱敏案例把整套排查逻辑串起来。1. 先弄明白Segmentation fault到底杀死了什么1.1 段错误不是“数值崩了”而是“内存访问被系统制止了”Segmentation fault的本质是程序访问了非法内存地址操作系统出于保护机制直接终止进程。它跟WRF里常见的浮点溢出、CFL条件失稳、NaN传播不是一回事。后者通常表现为结果越来越离谱或者rsl.error里出现FATAL字符串而段错误经常是一句话不留地退出杀你个措手不及。打个比方程序像一个在自家厨房做饭的人段错误是他突然伸手去敲邻居家的墙保安直接把他架出去了。并不是菜谱出了问题而是动作范围出了问题。所以排查方向应该是程序为什么访问了非法内存。非法内存不会随机出现它一定对应着某段确定的代码路径和一个确定的数据状态。这也是为什么“快结束时报错”这个信息非常有价值——它说明崩溃不是发生在初始化阶段更大概率发生在某一类周期性任务上面写文件、读输入、调物理方案、做边界更新。这三个字的定位价值比一堆日志还高。1.2 “快结束时报错”这个时间特征非常关键如果把崩溃点放在整个时间轴上看d01区域积分快结束时崩溃能列出来的原因其实不超过五个方向输出文件写爆了栈空间在某个深层调用时不够了驱动数据或者SST在末尾时次出现了坏点物理方案在极端气象状态下触发数组访问越界以及并行环境里某个进程提前退出导致其他进程收不到消息也跟着挂掉。这些原因的特征各不相同处理方式也不一样如果一上来就盲目重编译等于把这些线索全扔了。我身边遇到过的所有“准点崩溃”案例几乎都能在日志尾部、输出文件大小、资源限制、输入时次数据这四样东西里找到直接证据。先做现场保护再动手查比上来就重编要省一天时间。下面这个章节就按这个排查顺序来写你可以直接照着做。2. 排查前先做现场保护日志、文件、系统状态一个都不能少2.1 rsl.error.xxxx才是找线索的主角WRF并行跑起来以后运行目录会出现一堆rsl.error.0000、rsl.error.0001这类文件同时还有rsl.out.0000这一类。很多人习惯看rsl.out因为它打到屏幕上的内容更完整。但我的经验是真正要盯的是rsl.error。rsl.error虽然大部分时间只在模式崩溃前记录最后几步内部打印但它尾部那几十行往往能告诉你崩溃时模式正运行到哪一类调用。用命令查tail -100 rsl.error.0000。注意不要光看0000可以把所有进程的日志都看一遍tail -100 rsl.error.*。因为如果某个MPI进程先崩它的error文件最后几行常常和其他进程不一样。我之前遇到过某进程最后停在“Computing wrfout”就断了而其他进程还在继续干别的那大概率是文件写入环节出了问题。反之如果所有文件都在同一个位置断掉问题更大概率出在物理方案、边界更新这类全局同步模块里。这一步不看全后面容易误判。2.2 三个命令先跑一遍多数问题能缩小到四个方向进入运行目录后我会同时执行下面这一组命令基本不花时间但能快速排除或锁定一批原因# 1. 看内核日志里有没有段错误或内存溢出记录 dmesg | tail -20 # 2. 看输出文件的大小和最后修改时间 ls -lh wrfout_d01_* # 3. 看当前shell的所有资源限制 ulimit -admesg那条命令是看内核日志。如果崩溃是内存越界触发的内核常常会记录一条类似“segfault at ... ip ...”的信息虽然给不出代码堆栈但能告诉你触发的时刻和大概地址。文件大小检查为什么重要看后面专门一节。ulimit那条则直接暴露栈空间限制很多段错误就是这里引起的我见过太多集群默认的stack大小只有8MB或者提交脚本里被限制到64MB的情况。这三条命令不需要你懂底层原理只需要对照结果判断有没有OOM记录wrfout是不是已经接近2GB或4GB栈空间是不是小得离谱。如果三个都正常再往下查代码级的问题。2.3 这些“环境变量”特别值得留意除了ulimit还有几个环境选项在段错误现场经常扮演关键角色。比如OMP_STACKSIZE如果你用的是OpenMP线程化版本编译时选smpar或dmsm线程的私有栈大小往往不是继承自进程栈而是由这个变量控制。很多人在跑嵌套大区域时设置OMP_NUM_THREADS8甚至更高但从不设置OMP_STACKSIZE结果线程一深入到某些深递归物理过程就直接把栈顶穿。另一个值得在提交脚本里主动加的是ulimit -s unlimited。虽然名字叫“无限”在大部分任务调度机上只是把栈空间限制放开到物理内存可用的大小不会真把机器搞出问题。除非集群管理员明确禁用了这个设置否则我建议每次WRF作业前都加上。多线程栈问题导致的段错误有个很迷惑的特征同样的配置换个核数跑崩溃时间点就变了。下面第4节会详细展开。这里先有个概念段错误经常不是WRF真正的bug而是运行环境与模式调用深度不匹配。3. 最容易被漏掉的元凶wrfout文件大小和netCDF格式3.1 经典netCDF格式的单文件上限有多坑WRF默认通过netCDF库把结果写到wrfout_d01_YYYY-MM-DD_HH:MM:SS这种文件里。很多版本和编译环境下底层创建的还是传统的netCDF classic格式。这个格式对单个变量和整个文件都有2GB到4GB级别的硬限制实践中经常是文件写到接近2GB就出问题。d01虽然是粗网格但水平范围大、垂直层数多、变量数量又多如果再把几天积分的高频输出都堆到一个wrfout文件里结果就是跑到末尾某一个时次时新数据一写入文件直接突破格式上限程序当场段错误。我处理过一个模拟实验wrfout_d01文件长期稳定在1.8GB左右每次都在差不多同一个位置崩。当时所有人都怀疑物理方案最后发现文件大小到了1.6GB后每多写一个时次就越过内存映射边界一次。这种问题用gdb去查代码通常很难看明白因为崩溃点往往落在netCDF底层的写数据接口里。但用ls -lh一看文件大小几秒钟就能锁定。3.2 怎么确认是不是文件大小问题有一个比较直接的确认方法崩溃前看最后一个成功写出的wrfout文件有多大。如果在2GiB附近有时是4GiB概率就很高。更严谨一点可以用ncdump -k wrfout_d01_*查看文件格式。如果返回的是classic或者64-bit offset而文件大小又接近格式上限那基本可以坐实了。解决思路有两个方向。一是换用支持更大文件的netCDF配置重新编译模式或者在configure时选到支持large file的选项二是干脆调整输出策略别让一个wrfout文件越写越大。第二个方案更通用也更容易在不停机的状态下解决。比如在time_control里把frames_per_outfile设小甚至设成1让每个时次一个文件。对于业务化长时间积分我很喜欢“一个文件一个时次”的方式既避开了格式限制后续画图、截取时段也省事。3.3 输出策略调整别让一个文件背太多数据做长时间模拟时我建议把输出节奏拆开高频细节输出用auxhist放到单独的流里降低每个文件的数据量主输出wrfout保持较低频率用于后处理分析。比如主输出6小时一个时次辅助输出每1小时一个时次并把辅助输出写到wrfout_auxhist_d01_*这样单个文件根本不会接近格式上限。这类设置都在time_control里改完以后重新跑之前先确认是不是触发了restart机制别把已有进度丢掉。另外如果觉得换格式麻烦还有一个“土办法”在崩溃前把历史输出间隔调大等于让文件在快接近上限前少写几个时次。这个方法只适合临时救急不适合正式跑长期业务因为在文件上限旁边跳舞永远不是长久之计。4. 并行环境的锅栈空间、MPI绑定、OpenMP线程4.1 ulimit -s和OMP_STACKSIZE为什么致命WRF里面一些物理过程比如长波辐射、云微物理调用链非常深函数嵌套多每个函数都有自己的临时数组。当进程的栈空间限制太小时模式不一定开局就挂而是会在某个计算量最大、调用深度最深的时次蹭到栈顶。为什么“快结束”容易踩到因为积分到末尾时边界层发展、对流活动往往更剧烈某些方案内部会分配更大的数组或者进入更深的分支本来正好卡在线上的栈空间被多压了一截段错误就来了。所以排障时第一件事就是看ulimit -a输出里的stack size如果显示的是8MB、64MB这类数字先改成ulimit -s unlimited再重跑。用了OpenMP线程的情况下再补一个export OMP_STACKSIZE512M或更高。这些改动成本低到可以忽略但能解决一大批“换了机器就崩”“换了核数就崩”的玄学问题。4.2 进程绑定、超线程和“换核数就崩”的诡异现象并行跑WRF的时候MPI进程和CPU核的绑定很重要。有些调度系统会把进程随机撒在物理核和超线程核上超线程核共享执行单元导致某些进程计算变慢MPI通信等待时间拉长。更严重的场景是嵌套的OpenMP线程数乘以每节点的MPI进程数超过了物理核数线程切换频繁栈和缓存的压力一起上来偶尔就会在某个时刻崩溃。如果出现“同样的namelist这次用40核崩上次用32核没事”大概率不是模式问题而是并行映射问题。排查方法很简单重跑前先看节点拓扑比如numactl --hardware看看核数分配确认MPI进程数乘以线程数不超过物理核心数如果机器用了超线程最好通过任务的cpu绑定参数把进程固定到物理核上。这属于作业脚本的细节但非常常见。另外一个比较隐蔽的情况是跑在容器或者某些虚拟化环境里宿主机限制不了但容器内部的ulimit和CPU亲和可能跟物理机不一致导致同样的作业脚本在裸机上没事在容器里就段错误。4.3 用单进程复现来区分“环境问题”和“模式问题”我在排障时会用“降维打击”的方法构造一个小区域、短积分的算例用mpirun -np 1跑单个进程把崩溃点复现出来。单进程跑还是有段错误那模式本身或输入数据出问题的可能性就大单进程跑得好好的多进程一上就崩那基本可以断定是并行环境、通信、绑定的毛病。这个方法特别适合区分两类问题省得在并行debug的泥潭里浪费时间。5. 特定时间点的输入数据与物理方案副作用5.1 驱动数据在个别时次的坏点怎么酿成段错误如果崩溃时间离积分结束不太远而且每次重启到那个时间点附近都崩我建议回头查一遍用于驱动模式的数据。WRF并不是等到积分结束才读所有时次的数据像侧边界条件里面的时间插值、高层风速、位势高度场会在积分到达对应时间段时逐步读取。如果某个时次的数据文件里存了-9999、NaN这类坏值或者某个高度层的数值异常大在插值到模式格点时就会产生极端值某些物理方案拿到极端值后可能换成句柄、越界数组最终表现为段错误而不是简单的数值警告。怎么查可以在崩溃时刻前后用ncdump或专门的检查脚本把几个关键变量水平风U/V、温度T、位势高度GHT、比湿Q的极值打出来和前后时次做对比。我做过一个准点崩溃的排查最后就是发现某驱动数据在特定时次北侧有一个格点风速异常大导致积云方案内部数组越界。你不查输入只在模式代码里挖挖一个月也找不到头。5.2 和后台更新相关的选项SST更新、观测驰豫等还有一类特别容易伪装成“快结束”问题的情况来自周期性后台更新任务。比如physics里的sst_update .true.模式会按interval_seconds周期性地重新读取SST数据并更新海温场fdda里的分析驰豫和观测驰豫也是在特定时间窗口内反复读入观测数据。如果这些后台文件只在积分末段包含了某个坏时次或者坏格点崩溃就会非常精准地落在更新时刻附近而不是累计演化到那一步。这类问题的特点是把模式和物理方案换掉都没用还是到那个时钟点就崩但如果你把SST更新关掉或者FDDA关掉重跑同一个时间步可能就过了。当然关掉物理过程只是定位手段真正修还是要把对应数据源修好或者把更新间隔调大避开坏时次。定位的时候我会在namelist里临时把相应更新间隔改大比如从1小时改成6小时如果崩溃时次也跟着变说明问题就在这个更新源上。5.3 数值越界导致崩溃的现场特征除了外部数据坏点模式内部也可能因为地形、物理方案组合在某个极端天气区域产生异常值进而走到数组越界。这种内部数值膨胀导致的段错误往往在rsl.error尾部能看到一些不正常的打印比如某个变量的极小/极大值打印中出现NaN、Inf或干脆某一行被打印到一半。碰到这种情况我的经验是先别急着改代码把物理方案组合换回更稳定的搭配试跑一段。比如某些云微物理参数化方案对极端上升气流特别敏感在d01粗网格快到积分末尾时对流活动的累计效果把局地垂直速度推到异常值模块内部某个临时数组按正常范围预分配直接越界。这种情况换一个相对稳定的微物理方案或做时间步长微调常常就能过。说到底段错误不是一个单一故障它更像是很多上游异常共同指向的一种“出口”。6. 两个必会手段gdb回溯崩溃位置 断点重启定位6.1 用gdb把段错误卡在具体的代码行日志和系统信息都查完还是摸不着头脑那就只能上调试器。做法是在configure阶段或者在configure.wrf里给编译加-g调试标志重新编译模式至少要编译wrf.exe和它依赖的模块。然后在单进程复现的算例上用gdb --args ./wrf.exe启动run跑崩溃后输入bt查看调用栈。调用栈会直接告诉你段错误发生在哪个模块、哪个函数附近。比如看到停在辐射驱动例程或某个SST更新例程里排查方向立刻就窄了很多。6.2 断点重启法一段时间后再崩本质完全不同如果连gdb也编译麻烦用重启法也能定位。把积分任务分成两段先在崩溃前一个输出时次把模式停下来生成wrfrst_d01_*重启文件然后在namelist里设置restart .true.从那个时次继续往前跑。如果重启后依然在同一时刻崩溃说明问题强烈关联到该时刻的外部数据或模式状态如果重启后跑过了原来崩溃的时刻却在新的更晚时刻崩这通常说明是长时间积分累积出的数值问题比如某个变量慢慢漂移到边界。这两种结果的处理路径完全不同。前者要检查数据源和该时次的物理量后者要调时间步长、检查方案稳定性、考虑加滤波或限制。很多人问我为什么不直接在原任务里改输出频率定位其实重启法等价于一个“可重复实验”能帮你判断偶发还是必然非常好用只要别把wrfrst文件删了就行。6.3 把输出间隔临时加密让“案发现场”更清晰还有一个低成本做法把崩溃前一段时间的frames_per_outfile或history_interval临时设小让模式在崩溃前多留几个输出时次。这样即使段错误发生了你手里也有崩溃前几分钟、前半小时的完整状态用ncdump或画图工具对比这几个时次的变量极值就能看到异常是从哪个变量、哪个区域开始萌发的。这个方法特别适合排查“第36小时必崩”这类案件。把输出从每小时改成每10分钟崩溃前最后几个时次会留下一条清晰的数值恶化轨迹比如看到某一区域的海温插值先是出现一个尖峰然后扩散最后崩溃。相比之下每小时一个时次可能只留下崩溃前“一切正常”的假象。多做一步输出排查成本低很多。7. 三个真实排障实录细节脱敏7.1 准点崩在第36小时坏在驱动数据的一个时次某次沿海风场模拟项目d01区域积分到36小时附近几乎必崩。rsl.error里没有FATALdmesg也没OOMwrfout文件不到1GB一开始怀疑是地形参数化有问题。后来用重启法从第30小时重跑崩的时间点还是第36小时附近。接着把输出间隔加密发现在第35.5小时的输出里某个高层U风场在边界附近出现了一个异常大值区域来源正是第36小时的驱动数据在该区域存在一个坏格点。修复数据后整个模拟一口气跑完。这个案例说明输入数据的坏点不总是显而易见的但它的影响一定会通过输出变量的演变曲线暴露出来。7.2 文件快到1.8GB就崩netCDF格式背锅另一个某高校课题组的批量模拟每次跑到第9天前后就段错误非常规律。第一次遇到时团队花了大量时间检查物理方案还重新编译了两次结果都一样。后来我在运行目录里执行了ls -lh wrfout_d01_*发现每次崩溃时wrfout文件正好停在1.8GB附近而输出频率再往前推一点下一个时次就会撞上文件的单文件上限。把输出策略改成每3小时一个文件并确认netCDF库支持大文件格式后现象彻底消失。这类问题不发生在每个模拟里只发生在输出变量多、频率高、时长长的批处理里所以非常容易漏。7.3 重跑后崩溃时次漂移栈空间不足还有一次是某科研小组做区域气候长积分同一个算例不同批次重跑有时崩在第20天有时崩在第30天时次不固定。一开始以为是硬件故障后来我在作业脚本里看到一行默认的栈限制没被覆盖加上模式用了大量嵌套并行线程栈压力很大。把提交脚本改成ulimit -s unlimited并设置OMP_STACKSIZE之后同样的任务池再跑一个多月都没有再出现段错误。这个案例让我坚定了一个习惯不管程序看起来多么“玄学”每次提交作业前一定要确认资源限制不是隐患。我个人在实际操作中的体会是遇到Segmentation fault (signal 11)最忌讳的就是上手重编译、换编译器、换netCDF版本。先把日志尾部、文件大小、内核日志、栈空间、输入数据时次这五件事快速过一遍再决定要不要上gdb或者重启法大部分问题在动手改代码之前就已经能找到答案。这套固定顺序帮我处理过很多个看似无解的崩溃现场也让我少走了不少弯路。