参考自Wrf Errors - CFL Errors, SIGSEGV Segmentation Errors, and Hanging or Stopping - Nusculus
CFL Errors
CFL errors 通常是由于垂直风太快了，WRF无法处理的原因所致。有时候，通常发生在高山山顶的部分。尽管垂直风速相比水平风速很小，网格单元的垂直尺寸相比于水平尺寸非常小。所以，首先尝试减少时间步长。更短的时间步长意味着，风不会在一个时间步长迭代中，一路穿过网格单元。（这可能过于简化了WRF实际处理此类情况的方式，但是这个想法是正确的）。
另一个简单的解决方法是，改变WRF namelist.input中dynamics部分中的epssm值，但原因相对不明。WRF中每一个时间步分成了三个较小的sub-时间步。这使得求解方程需要使用更长的时间步。三个sub-时间步并不完全相等。如果是完全相等的话，则重复的数值模态结果看起来像是在声音频率下的波动。一个较小的时间步长偏移有助于防止这种情况。epssm控制了这个偏移。但是，有时候，默认值并不能足以抑制形态/波动，波动中的极值会导致CFL错误。所以，使用一个不同的epssm。默认值是0.1,因此请尝试0.3或者其他几个值。我忘记了允许的范围。（注：任何低于1.0的值，见http://mailman.ucar.edu/pipermail/wrf-users/2016/004160.html）
显然，对于很长的时间的模拟，您不能使用非常短的时间步长，否则完成时间太长。没有亲自尝试过，但是对于长时间的降尺度运行，有些人会使用较长积分步长，但是使用较短的"restart"时间间隔。当发生CFL错误时，WRF停止，这时使用最近一次正常的，保存好的restart进行重启，但使用的积分步长要缩短。过一会儿，在短积分步长保存一次或多次良好的restart文件后，再次停止模式，将时间步长恢复为正常值，并继续运行。基本上，仅在相对较短的时间段内减少时间步长。这需要一些密切的监视，但是您可以自己决定是否值得花更多的时间，来使总体的运行时间更短。
对我来说，CFL错误在运行开始时更常见。有些人建议您不要使用前8或12个小时的运行结果，因为WRF正在"spin up"。用于初始化WRF的低分辨率天气数据需要一段时间才能平滑。云在模式中发展并影响天气也需要时间。在这段时间里，变化的波会多次穿过网格，造成不现实的现象。如果在运行的一开始就出现错误，请尝试设置更早的模拟起始时间；否则，请执行以下步骤。
如果您多次运行同一个网格，这里有几点可以减少在某些运行期间出现CFL错误的可能性。首先，消除网格边缘附近的高峰，包括内部网格和外部网格。在模型中，山峰的陡峭会导致更多的垂直风。由于分辨率的变化，有时会有气象值在网格边缘的“反射”(reflection)。这主要是一种数值现象，但当波反射回自身时，会导致网格边界附近的值略微增加或减少。在山峰峰顶可能会触发额外的极值，从而导致CFL errors。因为一个角点有两条边，所以在网格的角落不适合有高峰（大地形）。其次，增加网格细胞的高度。垂直风穿过高的网格细胞需要更多的时间，因此不太可能导致CFL错误。第三，增加垂直阻尼vertical dampening。根据选择的其他选项，WRF有两种方法可以做到这一点。阅读 WRF User Guide，了解是否以及如何使用它们。这会减缓垂直风的速度；也许你不希望这样，但它有助于解决CFL错误。第四，对山峰进行平滑。WPS程序有一个option和多个passes来平滑地形。WRF还有一些namelist选项。找哪些是可以的，然后使用它们。
SIGSEGV段错误和停止，或者挂起 SIGSEGV Segmentation Faults and Stopping or Hanging
抱歉，即使运行没有error就结束，我也不知道是什么导致WRF挂起或停止产生输出。有时WRF只是停止输出。在其上运行的处理器有时显示处于忙碌状态；有时不是。有时程序会因"segmentation fault," SIGSEGV message。段错误（segmentation fault）是指程序尝试访问不受程序控制的内存位置时的情况。操作系统发送"SIGSEGV"信号，该信号会终止程序。使用一些解决CFL错误的技巧有时也可以解决这些问题。
以下是一些有时对我有用的东西。他们都不是总是有效的。而且，即使我具有相同的网格和初始化数据，一些方法也只是对一些是有效的，而对另一些无效。
首先，尝试*不要**使用多线程编译选项。就是在编译之前，configure部分中的smpar选项。此外，如果一个节点上有多个核心，请使用dmpar选项，并运行WRF的其他副本。你的mpirun -np或mpiexec -np命令可以设置成超过您拥有的节点数，这样它们将在每个节点上启动多个WRF。对我来说，如果我使用节点上的所有核，WRF的效率就会降低。是的，这是浪费资源，但是总比没有好。其次，更改使用的节点数。我不知道为什么这很重要，但是这让我可以运行或不运行某些东西。第三，就是尝试更改options。进行一些大的更改，直到某些方法起作用。然后使用它来找出较小的更改可能起作用。让我再说一遍，修复CFL错误的某些方法有时也有助于解决段错误和其他程序终止问题。更改时间步长，模拟起始时间或网格大小/位置最有帮助。
尚未尝试过，但是如果您在编译（共享内存shared memory/ smpar）中使用多线程选项，则将环境变量OMP_STACKSIZE设置为4G可能会有所帮助。我最近在发给wrf用户的电子邮件中看到了这一点。也许4G以外的值可能会起作用，这取决于每个节点的内存量。您可能必须将其放在作业脚本中，因为我认为这个设置在运行时而不是编译时指定的。