以下文章来源于气象备忘录 ,作者夏九
感谢夏子涵同学分享学习经验
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值,如果不同,可以对数据进行替换,基本可以解决该报错!
最后总结一句话:碰到问题先从最简单的解决方案开始排查,如排查数据而非模式,切不可钻牛角尖。