初学WRF，总是遇到各种报错。对模型和服务器的不了解导致初学者们不知道WRF停止运行的真正原因，于是很多人可能会去检索这样的错误：
forrtl: error (78): process killed (SIGTERM)
STOP: activate before 48000
BAD TERMINATION OF ONE OF YOUR APPLICATION PROCESSES
这些不是真正的错误。
WRF运行会输出很多rsl.error.0XXX文件。如果提交的任务日志能够输出具体哪个节点出错会更好，例如这样：
error: (节点编号): task 29: Exited with exit code 1
这时只需要查找rsl.error.0029中呈现的错误即可。该报错可能不止一行，例如：
error: (节点编号): task 29: Exited with exit code 1
error: (节点编号): task 37: Exited with exit code 1
...
那么就需要将出现问题的节点对应的rsl.error.0XXX文件都看一下，具体的错误会在这些文件里。
如果提交的任务日志没有这样的输出，逐一排查每个rsl.error.0XXX文件也是可行的。
grep error rsl.*这个命令能够帮助输出所有rsl.error.0XXX文件的错误。
通过这种方法，我在rsl.error.0029文件中找到了具体的错误在于：
WARNING: Large total sw optical depth of XX
然后再检索这个错误的解决办法即可。
20261017更新：
内存堆结构损坏崩溃是WRF-Chem模拟中的常见报错。
当模拟跑通几个小时后，因内存堆结构损坏报错停止，调试dx dy dt chemdt 以及mpi数，都是有效的方法，但试错非常耗时。本次解决该问题有如下心得：
- 修改dt chemdt不需要重新执行real.exe，所以调试起来会更快。
- 固定dt调chemdt更合适，因为dt有明确的6倍限制，而模式对chemdt的设置范围更加灵活。
- 固定dt后，将chemdt从复合模拟需要的最大值开始尝试，并逐渐缩小。
- chemdt尝试时，随domain的梯度缩小是一个有效的选择，即外层稍大，内层稍小。
- 有时，dt chemdt跑通后，但在跑到下一个restart前又因为其他namelist设置原因断掉时，修改后重新提交任务，会反复出现内存堆结构损坏崩溃的情况，因此要重新执行上述步骤。
- 这就很奇怪，明明是同样的dt chemdt 和mpi数量，但上次能跑通，下次跑不通，经测试，上次跑通的案例无法在紧跟的下次跑通。
- 这种跑不通的可能原因是，上次的运行在当前文件夹中留下了不完整的文件。这种情况无法使用删除文件的方式解决（因为不知道是哪些文件），经测试，修改chemdt能够再次跑通，外层chemdt不变，仅修改内层chemdt也同样可再次跑通。
关于mpi的数量：
- 不在namelist里设置的话，一般会自动分配给dx & dy, 例如40=5*8；36=6*6。
- 由于mpi的数量也是引起内存堆结构损坏崩溃的原因，修改mpi数也能解决该问题。
- 修改mpi数的重点在于修改分配给dx & dy的mpi数，例如mpi=32/40/48/56/64/80=4/5/6/7/8/10*8->dx*dy; mpi=30/36/42/48/54/60=5/6/7/8/9/10*6->dx*dy。
- 基于上述原理，对于dx dy对应的mpi数，可考虑控制二者其一，修改另一个，直至跑通。
注：以上观点仅为经验性总结。
