參考自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以外的值可能會起作用，這取決於每個節點的內存量。您可能必須將其放在作業腳本中，因為我認為這個設置在運行時而不是編譯時指定的。