WRF运行过程中遇到的各种报错记录

做了hpc技术支持，免不了运行wrf模式。开个帖子记录自己运行模式的时候遇到的各种报错。

2022.5.27 多云低级错误

运行ungrid.exe遇到了以下报错

Subroutine DATINT: Interpolating 3-d files to fill in any missing
data… Looking for data at time 2019-01-01_06 Found file:
FILE:2019-01-01_06 Looking for data at time 2019-01-01_12 Found file:
FILE:2019-01-01_12 Looking for data at time 2019-01-01_18 Found file:
FILE:2019-01-01_18 Looking for data at time 2019-01-02_00 Found file:
FILE:2019-01-02_00 Looking for data at time 2019-01-02_06
ERROR: Data not found: 2019-01-02_06:00:00.0000

ungrid.exe前一步是链接fnl再分析资料，我后面运行的时候改了模拟时间，增加了六个小时，FNL目录里也包括新加时间的fnl文件。问题出在哪呢？在于我没有重新链接fnl，因为我觉得前面已经链接过了，在我的WPS目录下面也有了link_grib.csh，所以直接运行是没问题的。但是啊，我们仔细看下这个命令：

./link_grib.csh /public/home/xxx/wrftest/FNL/fnl*

是链接到具体文件的，所以改了模拟时间，旧的link_grib.csh只包括旧的fnl数据，要再次链接才行。

2022.5.27 理解WPS目录里的每个文件的用处

运行metgrid.exe遇到了以下报错:

ERROR: Could not open file METGRID.TBL

这里就涉及到METGRID.TBL，和namelist.wps里的一些设置问题了。编译的WPS-4.3目录里并没有这个METGRID.TBL。
METGRID.TBL文件是用来控制如何把气象要素场进行插值的。METGRID.TBL文件为每个要素场都提供了一个区间，在这个区间里，可能会确定诸如要素场的插值方式、作为标记插值以及要素场所要插值的网格（如ARW的U，V；NMM的H，V）。
为了解决这个问题我们看一下namelist.wps里的关于metgrid的内容：

opt_output_from_metgrid_path = ‘./’ 代表允许客户在metgrid里写出插值数据文件。
opt_metgrid_tbl_path = ‘./’ 给出METGRID.TBL所在路径。
看来那么从哪里可以找到METGRID.TBL文件呢，就在WPS/metgrid目录下面，将它链接到WPS（或者修改namelist.wps里的路径）就可以解决这个问题了：

另外博主曾经在运行geogrid.exe的时候遇到过类似的问题：找不到GEOGRID.TBL。namelist.wps里关于geogrid也有相关的内容，但是当时博主直接简单粗暴地删掉了opt_geogrid_tbl_path = ‘./’ ，以后也成功运行了geogrid.exe。所以我简单粗暴删除namelist.wps里的opt_output_from_metgrid_path = ‘./’ 、opt_metgrid_tbl_path = ‘./’，也解决了上述问题。

虽然前面我们已经说了这些GEOGRID.TBL、METGRID.TBL文件的用处，但是更切实地讲，这些TBL文件到底用什么用处呢？或者说删掉namelist.wps里它们的内容对于WPS的运行有影响吗？以后解答这个问题。

2022.5.27 一些导致的问题

提交作业跑了十七秒，作业中断，vim rsl.error.0000：

没有具体报错，只有一句像报错： Tile Strategy is not specified. 未指定Tile策略。（后面发现不是报错，很多成功的例子里都有这句话）
这种没有具体报错的wrf日志，应该就和wrf本身的一些设置没有关系，可能是提交作业的脚本问题。查看sbatch脚本输出，vim log.err.825428：

有些节点没有csh解释器，把提交脚本改成bash， log.err.825428里就没有：命令找不到了。
但是rsl.error.0000还是一样的报错，这时我才发现Tile Strategy is not specified。并不是重点，重点是rsl.error.0000里有一串很奇怪的数字：

INPUT LandUse = “MODIFIED_IGBP_MODIS_NOAH”
LANDUSE TYPE = “MODIFIED_IGBP_MODIS_NOAH” FOUND 41 CATEGORIES 2 SEASONS WATER CATEGORY = 17 SNOW CATEGORY = 15
INITIALIZE THREE Noah LSM RELATED TABLES
Skipping over LUTYPE = USGS
LANDUSE TYPE = MODIFIED_IGBP_MODIS_NOAH FOUND 20 CATEGORIES
INPUT SOIL TEXTURE CLASSIFICATION = STAS
SOIL TEXTURE CLASSIFICATION = STAS FOUND 19 CATEGORIES
Sample of Urban settings
…
QC_URB2D 9.9999998E-03
XXXR_URB2D 0.0000000E+00
SH_URB2D 0.0000000E+00
LH_URB2D 0.0000000E+00
G_URB2D 0.0000000E+00
RN_URB2D 0.0000000E+00
TS_URB2D 280.0785
LF_AC_URB3D 0.0000000E+00
SF_AC_URB3D 0.0000000E+00
CM_AC_URB3D 0.0000000E+00
SFVENT_URB3D 0.0000000E+00
LFVENT_URB3D 0.0000000E+00
FRC_URB2D 0.0000000E+00
UTYPE_URB2D 0
I 3 J 22
num_urban_hi 15
USING DEFAULT URBAN MORPHOLOGY
Timing for Writing wrfout_d01_2019-01-01_06:00:00 for domain 1: 0.64514 elapsed seconds
d01 2019-01-01_06:00:00 Input data is acceptable to use: wrfbdy_d01
[b]Timing for processing lateral boundary for domain 1: 0.17918 elapsed seconds
Tile Strategy is not specified. Assuming 1D-Y[/b]
WRF TILE 1 IS 1 IE 36 JS 1 JE 27
WRF NUMBER OF TILES = 1

这么小的数字真的很奇怪，并且这里的Urban settings让我想到了namelist.input里的一个物理参数设置——sf_urban_physical：activate urban canopy model (in Noah LSM only). The same value should be used for all domains.）——激活城市冠层模型（仅在Noah LSM中）。所有域都应使用相同的值。
好像是Noah LSM的一个参数，这个例子的namelist是之前帮一个顾客解决问题的时候，我将他的namelist复制到自己账号下面帮他测试，不知道是不是漏了什么输入文件，不是很清楚这个Noah LSM。
总之删了，就能跑起来了。也不清楚有没有影响，仅提供一个解决问题的思路。