Wrf 错误 Wrf Errors - CFL Errors, SIGSEGV Segmentation Errors, and Hanging or Stopping - Nusculus
参考自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以外的值可能会起作用，这取决于每个节点的内存量。您可能必须将其放在作业脚本中，因为我认为这个设置在运行时而不是编译时指定的。
WRF论坛中关于CFL错误的一些讨论 （forrtl: error (78): process killed (SIGTERM)）。
问：我正在尝试使用嵌套区域运行WRF一天。当运行它时，它会工作一段时间，并且我会在第一个时间步骤中为这两个域获取OutputFile。但后来它崩溃了。对于错误文件，它显示"forrtl: error (78): process killed (SIGTERM)" , 而slurm文件显示 "srun: error: c9-5: task 91: Exited with exit code 174"。namelist, slurm, rsl.error和rsl.out随附。有谁知道是怎么回事吗？
答复：在rsl.error*文件中发现几个CFL错误。这说明模式变得不稳定——通常是由于强烈的上升运动 或者复杂地形。当这种情况出现是，我们通常建议缩短time_step（积分步长）。可以小于4xDX的长度。另外一些额外的建议（见下）
造成段错误(segmentantion fault)的主要原因是什么？
段错误难以追溯。由于通常没有清晰的错误信息，需要进行反复试验来找到可能的问题。
- 段错误通常是使用太多或者太少的处理器，或者进行错误的分解。关于选取恰当的处理器数目，这主要是根据模拟域的大小，参见常见问题。
- 同时可能是磁盘空间不足导致。检查还有多少剩余空间，如果网格区域非常大或者非常高的分辨率，输出文件通常会非常大（有时候会达到数G）。
- 如果模式的段错误就发生在刚开始运行阶段，这通常意味着输入数据有错误。一定要检查你的met_em*文件，看看你是否注意到各种变量中有什么异常。检查所有变量和所有层次。
- 很多情况下，段错误可能意味着这里有一个CFL错误，这意味着模式不稳定，通常是由于陡峭地形，或者非常强的对流。要检查这种错误，输入以下下命令
grep cfl rsl*
如果你发下了几个CFL的通知，这说明这就是造成模式崩溃的可能原因。首先，尝试缩短时间步长。时间步长的标准建议为6xDX（例如，如果DX=30000，则不应将时间步长设置为大于180的任何值）。然而，如果你还是得到CFL错误，你可以尝试减少到4xDX或者3xDX。有时候这个起作用，但并不会总是起作用。另外，如果CFL错误发生在边界区域，可以尝试的方法是在运行real前在namelist中的&domain部分添加smooth_cg_topo = .true.。这个选项将会对粗网格的外层行/列进行平滑，用以匹配随驱动数据提供的低分辨率的地形。如果CFL错误发生在复杂地形附近，可以尝试设置epssm = 0.2 (最高可以到0.5) 查看是否起作用.这个选项主要是对垂直气压梯度（或者声波）中心向前微调，从而缓冲3维散度。你还可以尝试设置w_damping = 1。- 一个段错误可能是由于内存原因。尝试以下方法看看是否有用：
a. 设置MP_STACK_SIZE。setenv MP_STACK_SIZE 64000000 (OMP_STACKSIZE)
b. 如果使用的是csh或tcsh，使用这个语句：limit stacksize unlimited
c. 如果使用sh或bash，使用这个语句：ulimit -s unlimited
这可能无法解决您的问题，但默认堆栈大小通常非常小，并且可能由于内存不足而导致段错误。
另外，还有一些更多建议，可以先试试。你的区域没有以一个理想的方式进行设置。基于我看到的，有以下建议：
- 你的d01大小比d02大得多。我们一般建议嵌套的网格应当约为外层区域的大约1/3。这可能不会造成问题，但却可能会有问题，你科研尝试让内层区域大一点。
- 你使用了2:1的比例，并且将feedback打开了。当使用feedback时，使用偶数的比例并不是一个好的选择。你可以在这个文件中找到相关信息。 我建议使用3:1的比例。你可以让外层区域分辨率是3 km，但是让嵌套区域为1 km。但是，再次，你需要将这些区域的大小重新调整。
看一下我们的最佳实践，他们讨论了WPS namelist，并且提供了关于区域设置的建议（为了未来的参考，这个也是namelist.input文件中的一部分）。这将帮助你合理的设置区域。
