【WRF报错-ungrib】你以为把数据打包上传就万无一失了嘛？实例

以下文章来源于气象备忘录 ，作者夏九

感谢夏子涵同学分享学习经验

Hello!大家好，今天给大家分享一个解决跑ungrib时遇到“End-of-record mark (7777) not found”报错的小方法。

问题情景描述

最近一段时间换了一个新的服务器，想在上面测试一下WRF-CHEM能否正常运行。于是就把老服务器上跑成功的case下面的一些基础数据打成tar包上传到新服务器上，打算重跑一遍看看。WPS和WRF的编译都没有问题，但在执行ungrib.exe时遇到如下图所示的报错：

由此，开始了漫长的找寻之路！

解决之路

首先在ucar的学习网址上，有人针对该问题给出了如下图的解决办法：

我根据该方法一顿操作后，发现原本可以跑一段时间再出现该报错的情况，变成了刚开始就报错。于是该方案被我无情抛弃。但如果各位小伙伴遇到这种报错，还是可以先尝试一下这种方法的。

接着，我在学习交流群中请教前辈们(在此衷心感谢小吕老师、zhengkun老师、蓝胖老师等前辈)，他们指出，很有可能是数据存在问题，并建议用hash值进行检验。我根据网上学来的hash值检验方法(Linux系统命令：md5sum filename; sha256 filename等，该命令通过计算给出文件的唯一hash值，可以比较两个文件是否完全相同)，对断了的这一时刻(2018060600)数据(即GRIBFILE指向的原文件，在我的case中是ECMWF数据)进行检验，发现完全一样。

这表示前辈们的思路错了吗？并不！我们前辈依旧是我们的前辈！我经过多次试验，终于发现，存在问题的数据不是断了这一时刻(2018060600)的数据，而是后一时刻(2018060606)的数据。

最后我将存在问题的数据替换掉之后，ungrib.exe可以正常运行！

心得总结

首先ungrib.exe是跑了一段时间以后断掉的，所以遇到这种情况，基本可以排除是环境的问题。其次，你还以为打包上传就能万无一失嘛？“End-of-record mark (7777) not found”告诉我们，即使打包也可能由于断点续传或者网络原因存在数据不全的问题，如果跑不通，可以考虑一下数据是否损坏。最后，如果出现了如本case的报错，可以尝试检验报错时刻的后一时刻数据文件的hash值，如果不同，可以对数据进行替换，基本可以解决该报错！

最后总结一句话：碰到问题先从最简单的解决方案开始排查，如排查数据而非模式，切不可钻牛角尖。