WRF讲解——CFL 错误、SIGSEGV 段错误以及挂起或停止

原文是由 Kevin Matthew Nuss 所写，本文仅摘取原文部分内容做了简要的翻译，如有不妥之处，还望大家及时指正。点击阅读原文即可跳转至英文版原文界面。

2012 年 7 月写这篇文章，我已经有大约一年没有运行 WRF了。或许我在本文中所写的内容已过时，它只包含当 WRF 不运行时可以尝试的方法。我感觉到你的痛苦，但我无法让它消失。对不起，我希望我能知道更多，以便我可以给你提供帮助。

CFL 错误

从代码可以看出，CFL 错误通常是由垂直风速太快，导致 WRF 无法对其进行处理。就我的经验而言，它们通常发生在较高的山峰上。

尽管与水平风相比，垂直风速较小，但与水平分辨率相比，网格单元的垂直分辨率非常短。所以首先尝试减少时间步长。较短的时间步长保证了风不会在一个时间步长的迭代中穿过一整个网格单元。(这过于简化了 WRF 处理此类事情的真实方式，但这个想法大致正确。)

另一个简单尝试是更改 WRF 的 namelist.input 文件的 dynamics 部分中的epssm 值，但其原理并不是十分清楚 。WRF 中的每个时间步都分为三个较小的子时间步。这允许使用更长的时间步长求解方程。三个子时间步长并不完全相等。epssm 值控制子时间步长的轻微偏移。所以尝试不同的 epssm 值，默认值为 0.1，因此请尝试使用 0.3 或其他几个值。我忘记了允许的范围。

显然对于很长的运行，你不能使用很短的时间步长，否则需要很长时间才能完成。我本人没有亲自尝试过，但对于长时间的气候降尺度的模式运行，有些人使用更长的时间步长但较短的“restart”时间间隔。当 CFL 错误发生时，WRF 停止，在最近一次正常运行且保存的restart进行重启，但时间步要缩短。一段时间后，在短时间步保存一次或多次正常的restart文件后，将模式断掉，时间步增加回正常值，并继续运行。基本上，只针对相对较少的有错误的时间段减少时间步长。这需要仔细观察，但您可以自己决定是否值得为获得更短的整体运行时间而增加额外的人员时间。

对我来说，CFL 错误在模式刚开始运行时更为常见。有些人建议您不要使用模式最开始前 8 小时或 12 小时的模拟结果，因为 WRF 正在“spin-up”，即用于初始化 WRF 的低分辨率天气数据需要一段时间才能平滑。云在模式中形成并成为天气影响因素也需要时间。在那段时间里，波动多次穿越网格造成不稳定现象。如果在运行的刚开始就出现错误，请尝试在从稍早的时间开始运行；前面的时间可能没有导致错误出现的条件，并且可能会在到达您的研究时间段之前初始场就变得足够平滑。

如果您多次运行相同的网格，这里有一些方法可以减少在其运行期间出现 CFL 错误的次数。首先，消除靠近网格边缘的高峰，包括内部和外部网格。山峰的陡峭会导致模型内有更多的垂直风。由于分辨率的变化，有时会出现网格边缘的气象值“反射”。这主要是一种数值现象，但随着波反射回自身，会导致靠近网格边界的值略有增加或减少。在那里有一个高峰值会触发额外的极端情况，从而导致 CFL 错误。并且由于角有两条边，所以在网格的边角要避免出现高峰。其次，增加网格单元的高度。垂直风穿过一个高大的网格单元需要更多的时间，所以不太可能导致 CFL 错误。三是加大垂直阻尼。WRF 有几种方法可以做到这一点。您可以通过阅读 WRF 用户指南了解以及使用它们。该方法会减慢垂直风的速度，也许您不希望那样，但它有助于解决 CFL 错误。第四，平滑峰值。WPS 处理过程中有一个选项和多个通道来平滑地形。WRF 也有一些 namelist 选项可以实现这种目的，可以了解一下。

SIGSEGV 分段错误和停止或挂起

抱歉，我不知道是什么原因导致即使运行没有出错并结束，WRF 也会挂起或停止输出。有时 WRF 只是停止输出，运行它的处理器有时会显示正处在忙碌中；有时不是，程序会因"segmentation fault," SIGSEGV message而停止。segmentation fault是指程序尝试访问不受程序控制的内存位置时，操作系统发送“SIGSEGV”信号，杀死程序。使用一些修复 CFL 错误的技巧有时也会修复这些错误。

这里有一些其他的方法有时对我有用。首先，尽量不要使用多线程编译选项，即编译前的 smpar 选项。如果您在一个节点上有多个核心，请使用dmpar 选项。你的 mpirun -np 或 mpiexec -np 命令可以实现跨节点上启动多个 WRF。对我来说，如果我在一个节点上使用所有内核，WRF 的效率会降低。是的，这是一种资源浪费，但总比没有好。其次，更改使用的节点数。我不知道为什么这很重要，但它对我让某些东西运行或不运行产生了影响(就小编个人经验来看，通过该方法更改节点数目或者核心数，本质就是改变了使用到的内存。具体可以见slurm作业调度系统(四)中的问题7进行理解)。第三，尝试改变options。做一些大的改变，直到有效果。然后使用它来确定哪些较小的更改可能起作用。让我再说一遍，修复 CFL 错误的一些方法有时也有助于解决段错误和其他程序停止。更改时间步长、开始时间或网格大小/位置最有可能有所帮助。

我自己还没有尝试过，但如果您在编译（共享式内存/smpar）中使用多线程选项，将环境变量OMP_STACKSIZE 设置为 4G 可能会有所帮助。我最近在发给 wrf 用户的一封电子邮件中读到了这一点。也许 4G 以外的值可能会起作用，这取决于每个节点有多少内存。您可能必须将它放在作业脚本中，因为我认为它是在运行时而不是编译时发挥作用。