wrf--运行real.exe时报错:“Could not find level above ground“ error

简介: 在修改wrf初始场资料时,如果做了带通滤波处理,会发现在运行real.exe时报错:“Could not find level above ground” error 。

在修改wrf初始场资料时,如果做了带通滤波处理,会发现在运行real.exe时报错:“Could not find level above ground” error 。


这是为什么呢?根据提示,报错的原因是找不到地面以上的高度?

后来发现PSFC variable等变量具有负的值。


原因如下:


  • 当使用带通滤波会产生负的结果。这对于pressure、relative humidity等变量是不符合物理意义的。


因此 ,需要进一步做处理。具体如何解决呢?


  • 很简单,将其带通滤波后的结果加上平均场即可。
  • 对于单层和pressure中的变量处理一些本身具有负值的变量,其他本没有负值的都需要加上平均态以避免负值的出现

这里需要改的变量:

  • 2m露点温度、2m气温、表面压强、海表面平均压强、(single level)
  • 相对湿度、气温、比湿 (pressure level)
  • 同时,相对湿度的带通滤波结果需要通过带通滤波后的气温、压强和比湿计算而来。原本era5下载的相对湿度可能是存在问题的
  • 计算得到的相对湿度的空间水平分布应该与比湿的空间分布类似,如果不一样差的很多的话说明计算有问题


包括下面出现的这个问题,原因是你的met_d01文件损坏导致的,可以试着使用ncview看看能不能打开met.nc文件,如果不可以说明这个文件损坏,需要重新计算,并行计算在WPS中的计算速度有时不一定有串行速度快。

b2095cc8a0cb43b9adfd34225c9fc99d.jpg


顺便提一句,如果对初始场进行带通滤波希望捕捉尺度信号的话,对于位势高度应该也可以不进行滤波,直接将初始场扔到模式中,位势高度在海平面上可能本身是有负值的。如果非要计算的话,可能需要使用梯度风平衡重新诊断位势,这就比较复杂了。理论上来说,位势应该由风场调整获取,不管它应该问题不大。


总之,以后修改WPS初始场文件时,需要谨慎处理。特别是计算设计到变量会出现负值,在运行wrf之前,最好检查一下met_d01*文件,能否正常使用ncview打开,相关的气压场变量的范围是否正常。毕竟如果模拟时间较长的话,进行一次WPS前处理还是毕竟浪费时间和资源的。


这样,避免出现的莫名其妙的问题!!!


此外,记录一下关于全球模式和区域模式的思考:


这两种的差别:


  • 1、分辨率。区域模式的分辨率应该是更精细一点。毕竟全球的分辨率计算资源耗费更多。同时,当区域模式和全球模式的分辨率如果一致时,理论上模拟的结果、特征应该是比较一致的。如果不一致,那应该认可哪个,这是个以后可以关注的问题。

2、边界条件。区域模式需要给定初始条件以及侧边界条件,一般这两种数据有两种方法给定:

  • 1、给的是各种通量fllux,相当于将这个区域的侧边界净的各种温度、湿度等直接给定,然后扔到模式里给他自己转
  • 2、给的是一般下载的ERA5再分析资料
  • 而全球模式的好处在于不怎么需要侧边界,像是一个圆一样,循环起来。
  • 对于模拟,一般就是模拟过去的时间内发生的现象,大部分资料是已经有了
  • 对于预测,就是模拟未来时间发生的现象,但是限制在于基本给定的边界条件只能给出15天的资料。所以预报越往后越不准。
  • 但是预报目前有一个改善的方法是,刚开始正常给定边界资料,但是当今天的观测资料观测结束,立刻传输下来,作为新的边界条件对原本的预报进行一点修正,相当于同化,将预测值拉的靠近观测值。这样,预报的结果就相对准一点。

对于预测来说,关键就是初始的边界条件,所以可预测的时间持续性不长。

相关文章
|
IDE PyTorch 网络安全
|
19天前
No rule to make target ‘.xxxxxxxx‘, needed by ‘debug/xxxx.cpp‘. Stop.
No rule to make target ‘.xxxxxxxx‘, needed by ‘debug/xxxx.cpp‘. Stop.
13 5
|
28天前
|
人工智能 C++ Windows
[NextJs] 解决 Failed to load SWC binary for win32/64
快速解决 Next.js 在 Windows 下运行时 SWC Binary 报错的方法,包括安装 Microsoft Visual C++ Redistributable 和确认处理器架构。
|
Ubuntu Unix Linux
成功解决ERROR: Unable to find the development tool `cc` in your path; please make sure that you have the
成功解决ERROR: Unable to find the development tool `cc` in your path; please make sure that you have the
成功解决ERROR: Unable to find the development tool `cc` in your path; please make sure that you have the
|
2月前
MTK在编译10A的target时报错:make: *** [mmi_feature_check]
MTK在编译10A的target时报错:make: *** [mmi_feature_check]
15 0
|
2月前
解决运行qmake:Project ERROR: Cannot run compiler ‘cl‘. Output:
解决运行qmake:Project ERROR: Cannot run compiler ‘cl‘. Output:
317 0
|
TensorFlow 算法框架/工具 Python
成功解决File "frozen importlib._bootstrap", line 219, in _call_with_frames_removed ImportError: DLL lo
成功解决File "frozen importlib._bootstrap", line 219, in _call_with_frames_removed ImportError: DLL lo
成功解决File "frozen importlib._bootstrap", line 219, in _call_with_frames_removed ImportError: DLL lo
安装 xgboost 报错ERROR: Command "python setup.py egg_info" failed with error code 1 in /private/var/fold
安装 xgboost 报错ERROR: Command "python setup.py egg_info" failed with error code 1 in /private/var/fold
安装 xgboost 报错ERROR: Command "python setup.py egg_info" failed with error code 1 in /private/var/fold
WRF模式报错:traj_opt is zero, but num_traj is not zero; setting num_traj to zero
最近,在跑WRF模式时遇到一个奇怪的问题,从WPS一直到WRF中运行./real.exe,全都没有问题,直到提交作业到集群上时发现,很短的时间内作业就结束了,而且只生成了一个时刻的数据,通过将debug_level调整到999发现,产生以下问题:
WRF模式报错:traj_opt is zero, but num_traj is not zero; setting num_traj to zero
编译OpenJDK11:configure: error: Target CPU mismatch. We are building for x86_64 but CL is for “版“; exp
编译OpenJDK11:configure: error: Target CPU mismatch. We are building for x86_64 but CL is for “版“; exp
144 0