每年都有人来问WRF怎么装，每年也都会有新的坑在等着。2025年做WRF服务器移植，和几年前最大的区别是：你很难再靠一篇老教程从头点到尾了。编译器版本更复杂、依赖库组合更多、服务器环境五花八门，照着两三年前的博客照抄，大概率卡在某个莫名其妙的编译错误上。
这篇文章我按自己最近一次在纯净Linux服务器上移植WRF的完整流程来写，从版本选型、依赖库编译，到WRF主程序、WPS编译，再到常见报错排查，全流程走一遍。适合两类人看：一是刚接触WRF、准备在实验室服务器上跑通又没装过的同学；二是换过新机器、打算迁移旧环境的老手。我会尽量把每个关键步骤的“为什么”讲清楚，而不是只丢命令。
1. 安装前的整体规划与版本选型
1.1 动手前先想清楚三个问题
WRF安装失败案例里，相当大比例的问题不是技术本身，而是装之前没想清楚目标。我在动手前一般会先过一遍三个问题，想清楚再开始，能省掉后面大量返工。
第一个问题：这台服务器跑WRF的目的到底是什么。如果是为了科研实验、跑个理想化算例，那标准单层嵌套、中等分辨率就够了；如果是要接业务预报流程，后面要跑真实资料同化、三维变分，那从最开始就要考虑并行IO、外部数据接口这些组件到底装到什么程度。这个决定直接会影响你编译时选哪种嵌套模式、要不要编译WPS以外的工具。
第二个问题：计算资源大概是什么体量。CPU核数、内存大小、磁盘IO能力，决定了你该选串行还是分布式内存并行（dmpar）。有的教程图省事，默认让你装串行版，真跑起业务来就是灾难。我看到不止一个人，装完WRF之后发现real.exe出结果要一整天，回头再重装并行版，白白折腾一遍。
第三个问题：你到底有没有sudo权限。很多服务器上你只是普通用户，装系统库和改系统环境变量都需要管理员权限。没有sudo也不用慌，WRF整套环境完全可以装在自己的家目录下，只是所有依赖库都得自己编译，流程反而更可控。这个我会在第2章详细展开。
这三个问题想清楚，接下来选版本、选编译器、选依赖库组合才有依据。
1.2 WRF版本选型：别在3.x上浪费时间
WRF官方现在主推4.x系列，4.6是目前我实际使用中最稳的一个版本。很多老教程还在用4.2、4.3甚至3.9，不是不能用，但新机器上的新编译器和新版依赖库对老版本的支持越来越差，编起来容易报一些“古早味”的兼容性错误。
我的建议是：新装环境直接选WRF 4.6.x，配套WPS 4.6.x。如果不确定具体小版本，去官方发布页面看最新稳定版即可。WRF 4.5之后编译系统变化不大，4.6的配置流程和4.5基本一致，网上资料也足够多，出了问题更容易查到解决方案。
关于3.x系列，除非你有特殊的科研复现需求，必须用老版本，否则真的不要碰。3.x的年代netCDF还是3.x/4.x混用，HDF5版本也老，编译器接口和现在主流工具链差别很大，我亲眼见过有人为了装WRF 3.9被迫去编译老版本gcc，最后又引入一堆系统兼容性问题，得不偿失。
1.3 编译器、MPI和依赖库的版本矩阵
WRF的编译工具链可以概括成一句话：选一套编译器，配一个MPI实现，再把netCDF、HDF5等依赖库统一编译到同一个前缀目录下。
编译器方面，我推荐gfortran，原因很简单：开源、免费、遇到问题搜索引擎一搜一大片解决方案。注意gfortran版本不要太老也不要太激进，GCC 10到13这个区间的兼容性表现都很稳。如果你要用商业编译器套件，也可以，但配置复杂度会高一些，尤其涉及到MPI绑定的时候容易出幺蛾子，新手不建议一上来就走这条线。
MPI实现我强烈推荐MPICH。不是OpenMPI不好，而是WRF官方测试里MPICH的兼容性记录更好，编译时踩坑概率低。版本选MPICH 4.x即可，4.0以后都对现代编译器支持得很好了。
依赖库部分，核心几个是zlib、libpng、jasper、HDF5、netCDF-C、netCDF-Fortran。它们之间还有依赖关系：netCDF-Fortran依赖netCDF-C，netCDF-C支持HDF5后端，HDF5又要用到zlib。所以编译顺序基本是固定的：
| 编译顺序 | 依赖库 | 主要用途 | 依赖关系 |
|---|---|---|---|
| 1 | zlib | 数据压缩基础库 | 无 |
| 2 | libpng | PNG图片支持 | 依赖zlib |
| 3 | jasper | WPS的ungrib读GRIB数据 | 依赖zlib（可静态） |
| 4 | HDF5 | 并行IO和netCDF4底层 | 依赖zlib |
| 5 | netCDF-C | WRF核心IO库 | 依赖HDF5、zlib |
| 6 | netCDF-Fortran | Fortran接口层 | 依赖netCDF-C |
还有一个隐藏的坑：WRF自带的WPS在ungrib阶段需要jasper来解码GRIB格式数据，而jasper的版本和编译方式会影响WPS能否正常读出数据。很多人WRF主程序装好了，WPS也能编完，结果ungrib报错说库版本不匹配，其实就是这里没做好。
我把这套版本组合整理成一张表，是我最近一次安装用的，实测下来很稳：
| 组件 | 推荐版本 | 备注 |
|---|---|---|
| 系统 | Ubuntu 22.04/24.04 或兼容Linux | 其他发行版也行的 |
| gcc/gfortran | GCC 12.x 或 13.x | 相对保守 |
| MPICH | 4.2.x | 建议用源码编译 |
| zlib | 1.3.1 | 按官方最新即可 |
| libpng | 1.6.43 | 保持最新 |
| jasper | 2.0.33 | 不要用老1.x |
| HDF5 | 1.14.x | 开parallel |
| netCDF-C | 4.9.2 | 关闭DAP，减少依赖 |
| netCDF-Fortran | 4.6.1 | 匹配netCDF-C |
这套组合我建议你直接照抄，版本太新或太旧都可能引发连锁问题。
2. 依赖库编译的完整流程
2.1 统一规划安装目录和环境变量
所有依赖库我建议安装在同一个顶层目录下，方便后面统一配置环境变量。我的习惯是建一个$HOME/wrf_install作为根目录，下面每个库单独子目录。这样即使后面要重装某一个库，也不会影响其他已经编好的组件。
export WRF_INSTALL=$HOME/wrf_install export DIR=$WRF_INSTALL mkdir -p $DIR把安装根目录固定下来之后，后续每一步都引用这个变量，避免路径写死。这也是移植性最好的做法：换一台新机器，只要把家目录这套环境迁移过去，重新设一下环境变量就能用，不用再从零编译。
接下来，确认你系统里有基础编译工具和SVN/wget/curl这些下载工具：
sudo apt update sudo apt install -y build-essential gfortran wget curl m4 cmake注意，如果你没有sudo权限，可以跳过这步，后续所有依赖库都用源码编译，放进自己的目录，一样能跑。
这里我强烈建议把m4和cmake装上，虽然编译这些依赖库时不一定直接用cmake，但后面有些附属组件的构建脚本会调用它，缺了很麻烦。
2.2 编译zlib、libpng、jasper
这三个库算是底层依赖，编译相对简单，但一定要按顺序来，并且要把前缀目录统一到$DIR下。
先编zlib：
cd $DIR wget https://zlib.net/zlib-1.3.1.tar.gz tar -xzf zlib-1.3.1.tar.gz cd zlib-1.3.1 ./configure --prefix=$DIR make -j$(nproc) make install注意--prefix=$DIR，让zlib直接安装在$DIR/lib、$DIR/include下，后面所有库默认去这里找头文件和库文件。有人习惯每个库单独子目录，也可以，但环境变量会多好几个，容易乱。
然后是libpng：
cd $DIR wget https://download.sourceforge.net/libpng/libpng-1.6.43.tar.gz tar -xzf libpng-1.6.43.tar.gz cd libpng-1.6.43 ./configure --prefix=$DIR CFLAGS="-I$DIR/include" LDFLAGS="-L$DIR/lib" make -j$(nproc) make installlibpng的configure脚本会自动探测zlib的位置，如果不加CFLAGS和LDFLAGS，有可能探测到系统自带的旧zlib，后面jasper会连带出问题。
最后是jasper。这里特别提醒：使用jasper 1.x老版本，还是2.x新版，选2.x。老版本虽然很多老教程里提到，但和现代编译器兼容性不太好，而且2.x API变化很大，WRF 4.6和WPS 4.6对新版支持是没问题的。
cd $DIR wget https://github.com/jasper-software/jasper/archive/refs/tags/version-2.0.33.tar.gz tar -xzf version-2.0.33.tar.gz cd jasper-version-2.0.33 mkdir build && cd build cmake .. -DCMAKE_INSTALL_PREFIX=$DIR -DCMAKE_C_FLAGS="-I$DIR/include" -DCMAKE_EXE_LINKER_FLAGS="-L$DIR/lib" make -j$(nproc) make installjasper用cmake构建，如果只认CMake，不认老式的autoconf流程。编译完检查一下$DIR/lib/libjasper.so有没有生成。
注意：这三个库最关键的是前缀统一。我见过有人把zlib装到系统默认目录、libpng装到家目录、jasper又装到另一个地方，结果连netCDF-C那一关都过不去，回头来返工。
2.3 编译HDF5并开启并行支持
HDF5是netCDF4底层存储格式的关键支撑，WRF需要它提供并行IO能力。我的经验是：无论你是否要跑大规模并行，都建议编译HDF5时打开--enable-parallel，因为netCDF-C在开启netCDF4支持时，如果对应的HDF5没有并行能力，后期WRF的分布式并行编译容易出问题。
编译HDF5的配置命令：
cd $DIR wget https://support.hdfgroup.org/ftp/HDF5/releases/hdf5-1.14/hdf5-1.14.3/src/hdf5-1.14.3.tar.gz tar -xzf hdf5-1.14.3.tar.gz cd hdf5-1.14.3 export CC=mpicc export CFLAGS="-fPIC" ./configure --prefix=$DIR --enable-fortran --enable-parallel --enable-shared make -j$(nproc) make install注意export CC=mpicc这行，要确保mpicc在PATH里。如果你按第1章的建议先编译了MPICH并设置了环境变量，那这步没问题。如果你还没装MPICH，先花10分钟把MPICH编了：
cd $DIR wget https://www.mpich.org/static/downloads/4.2.2/mpich-4.2.2.tar.gz tar -xzf mpich-4.2.2.tar.gz cd mpich-4.2.2 ./configure --prefix=$DIR --disable-fortran make -j$(nproc) make installMPICH我习惯用--disable-fortran，因为WRF编译时用的是自己的Fortran编译器，并不需要MPICH额外提供Fortran模块，这样可以减少一层依赖。
HDF5编译时CFLAGS="-fPIC"非常重要，不加的话，后面netCDF-C链接时大概率报“relocation R_X86_64_PC32 against symbol”之类的PIC错误，这是很典型的坑。
编译时间会稍微长一点，耐心等。结束后在$DIR/bin下应该有h5pcc等工具，这代表parallel编译成功。
2.4 编译netCDF-C与netCDF-Fortran
netCDF-C和netCDF-Fortran是WRF最核心的两个IO依赖。很多人在这一步翻车，主要是因为没注意版本匹配，或者环境变量指到了系统自带的netCDF上。
先编netCDF-C：
cd $DIR wget https://github.com/Unidata/netcdf-c/archive/refs/tags/v4.9.2.tar.gz tar -xzf v4.9.2.tar.gz cd netcdf-c-4.9.2 export CPPFLAGS="-I$DIR/include" export LDFLAGS="-L$DIR/lib" export CC=mpicc ./configure --prefix=$DIR --disable-dap --enable-netcdf4 --enable-parallel-tests make -j$(nproc) make install--disable-dap是为了把DAP client支持关掉，主要是为了少拉一堆外部依赖，对WRF毫无影响。如果你在局域网没法访问外网，这个选项还能避免潜在的网络请求超时。
再编netCDF-Fortran：
cd $DIR wget https://github.com/Unidata/netcdf-fortran/archive/refs/tags/v4.6.1.tar.gz tar -xzf v4.6.1.tar.gz cd netcdf-fortran-4.6.1 export LD_LIBRARY_PATH=$DIR/lib:$LD_LIBRARY_PATH export CPPFLAGS="-I$DIR/include" export LDFLAGS="-L$DIR/lib" export CC=mpicc export FC=mpifort export FCFLAGS="-m64" ./configure --prefix=$DIR make -j$(nproc) make install这里有个容易踩的坑：netCDF-Fortran目录下安装完成后，$DIR/bin会出现nf-config和nc-config。这俩命令分别对应Fortran和C接口信息，后面WRF的configure脚本就是用这两个命令去探测netCDF环境的。如果它们出现在系统中，那你which nc-config的结果必须是$DIR/bin/nc-config，否则WRF配置时会被引到错地方。
我建议用下面的检查方式确认：
$DIR/bin/nc-config --version $DIR/bin/nf-config --version $DIR/bin/nc-config --has-hdf5看到HDF5支持为yes，才说明netCDF-C正确链到了我们编译的HDF5。
2.5 环境变量配置：一次配好，避免反复
依赖库全部编译完成后，立即配置环境变量，这一步一定要做扎实。很多人是在WRF configure报错后才想起来回来配环境变量，结果反复折腾。
把下面内容追加到~/.bashrc：
export WRF_INSTALL=$HOME/wrf_install export DIR=$WRF_INSTALL export CC=mpicc export CXX=mpicxx export FC=mpifort export F77=mpifort export PATH=$DIR/bin:$PATH export LD_LIBRARY_PATH=$DIR/lib:$LD_LIBRARY_PATH export CPPFLAGS="-I$DIR/include" export LDFLAGS="-L$DIR/lib" export NETCDF=$DIR然后执行source ~/.bashrc。
这里重点解释几个变量的作用：
NETCDF=$DIR是WRF configure脚本读取的核心变量，它会在后面找$NETCDF/include和$NETCDF/lib。如果你把netCDF装到了其他位置，光配好PATH不够，必须显式写NETCDF。
CC/FC/F77设为MPI包装器，保证WRF编译时使用同一套MPI环境。如果你跳过这些设置，WRF的configure可能会识别成串行或smoke模式，或者更糟——用了不同版本的MPI包装器编译，运行时炸出奇怪的进程通信错误。
CPPFLAGS和LDFLAGS全局指向$DIR，这样后续任何需要编译的组件都能自动找到我们编译的头文件和库文件。
注意：
export NETCDF=$DIR不是让netCDF必须装在根目录，而是让WRF的configure脚本不要去找系统默认路径。如果你把netCDF装在了$DIR/netcdf这种子目录，那这里一定要写NETCDF=$DIR/netcdf，否则会报找不到netcdf.inc。
3. WRF主程序编译
3.1 下载源码并运行Configure
依赖库搞定后，WRF主程序编译是最激动人心也是最容易出意外的环节。下载WRF 4.6源码包，直接解压到工作目录：
cd $HOME wget https://github.com/wrf-model/WRF/releases/download/v4.6.0/v4.6.0.tar.gz tar -xzf v4.6.0.tar.gz mv v4.6.0 WRF-4.6 cd WRF-4.6强烈建议先清理环境变量再跑configure，因为服务器上可能残留其他项目配好的变量。我一般先env | grep -E 'NETCDF|HDF5|LD_LIBRARY_PATH'看一眼，确认没错之后直接运行：
./configureconfigure脚本会先检查环境，然后列出一大串编译选项。这个列表长什么样取决于它识别出的平台和编译器，通常会有类似下面的数字选项：
[...] 34. (dmpar) Linux x86_64 gfortran 35. (serial) Linux x86_64 gfortran 36. (smoke) Linux x86_64 gfortran [...]这里你要选34. (dmpar)这种带dmpar的项。dmpar指分布式内存并行，适合多节点、多核跑；如果你想省事，可以选带serial的串行版，但大规模算例性能会差很多。
选完之后，它会继续问嵌套模式：
1 = basic 2 = full一般选1（basic nesting）就够用了。full嵌套虽然支持更多嵌套层和移动嵌套，但配置复杂度更高、资源开销也更大。除非你有明确的移动嵌套或大范围高分辨率嵌套需求，否则选1。
configure结束会生成configure.wrf文件。我强烈建议打开这个文件确认几个关键项，因为configure脚本自动探测不一定完全准确：
grep -E '^SFC|^SCC|^DM_FC|^DM_CC' configure.wrf正常应该显示：
SFC = gfortran SCC = gcc DM_FC = mpifort DM_CC = mpicc如果DM_FC或DM_CC为空，说明MPI包装器没找对，需要手动改成mpifort和mpicc，否则后面compile会编出单机版。
3.2 处理gfortran新版本参数不兼容问题
如果你用的是GCC 10以上的gfortran，可能会在编译中段报出一堆类似Error: Type mismatch at (1) in argument 'a' to 'function'的错误。这是Fortran对参数类型检查更严格导致的，WRF老代码和部分新代码不兼容。
解决办法是在configure.wrf里的FCFLAGS和FFLAGS变量中加上-fallow-argument-mismatch参数。具体操作是，在configure.wrf里找到以FCFLAGS开头的行，在末尾追加这个参数。如果怕手抖改坏，直接搜索-fallow-argument-mismatch，没有的话就手动加：
sed -i 's/^FCFLAGS =/FCFLAGS = -fallow-argument-mismatch/' configure.wrf sed -i 's/^FFLAGS =/FFLAGS = -fallow-argument-mismatch/' configure.wrf这个坑在2023年之后的新版GCC上非常常见，因为GCC 10默认启用了更严格的参数检查。不加这个参数，编译大概率会失败，而且报错位置非常分散，看起来像天书。
另外，如果编译过程中提示找不到netcdf.mod或netcdf.inc，回头检查一下NETCDF环境变量的指向是否有效，以及netCDF-Fortran是否编译成功并生成了netcdf.mod。这个文件应该在$DIR/include下：
find $DIR -name 'netcdf.mod'找不到就说明netCDF-Fortran那一步有问题，需要回去检查。
3.3 编译并验证产物
configure配置无误后，开始编译：
./compile em_real 2>&1 | tee compile.log编译过程建议加上| tee compile.log，把完整输出存下来。因为WRF编译输出的信息量非常大，一旦报错，你不可能在终端滚动里找到头，日志文件才是排查的依据。
编译时间取决于服务器性能，一般是20分钟到1小时。中间CPU会跑满，这是正常的。编译完成后，检查是否生成了关键可执行文件：
ls -l main/*.exe你应该看到wrf.exe real.exe tc.exe ndown.exe这四个文件。其中wrf.exe是模式积分主程序，real.exe是理想化/真实数据初始化的前处理程序，tc.exe是热带气旋追踪工具，ndown.exe是单向嵌套降尺度工具。
如果main目录下只有wrf.exe或什么都没有，说明编译失败或不完整。这时不要慌，打开compile.log搜索Error，定位第一个错误位置。绝大多数情况要么是环境变量不对，要么是之前某个依赖库没编好。
还有一个常见验证方法：
./main/real.exe 2>&1 | head -20正常会显示用法说明并退出，因为它缺少 namelist.input。如果报缺少共享库libnetcdf.so之类的错误，说明运行时的LD_LIBRARY_PATH没配好，重新检查第2.5节的环境变量。
4. WPS编译与数据获取准备
4.1 WPS编译流程
WPS（Weather Preprocessing System）负责把外部数据源（GRIB格式的气象场、地理静态数据）转换成WRF能读的中间格式。 WRF 装好了，WPS 不装，等于发动机有了但没装油管。
WPS版本要和WRF匹配，4.6的WRF配4.6的WPS。下载解压：
cd $HOME wget https://github.com/wrf-model/WPS/releases/download/v4.6.0/v4.6.0.tar.gz tar -xzf v4.6.0.tar.gz mv v4.6.0 WPS-4.6 cd WPS-4.6先别急着configure，检查一下环境变量。WPS的configure脚本依赖NETCDF和依赖库路径，确保NETCDF指向正确：
./configure它会列出一堆编译器选项，和WRF configure类似，选择对比的平台编号（通常对应gfortran + dmpar）。之后执行：
./compileWPS编译比WRF快得多，几分钟就好。编译完检查：
ls -l geogrid.exe ungrib.exe metgrid.exe三个exe必须都存在。如果没有，看编译日志，最常见的原因是geogrid编译时报缺少netCDF Fortran接口，或者ungrib报库版本不匹配。
WPS编译有个细节：编译器设置要和WRF保持一致。如果你WRF用的gfortran+dmpar，WPS也选同样的组合。它们最终要在一个环境联动，编译器不一致容易运行时就出现诡异segmentation fault。
4.2 GEOG静态地理数据准备
WPS的geogrid步骤需要在模拟区域内提供地形、土地利用、土壤类型等静态地理信息。这些数据是WPS运行时必需的，不下载的话geogrid.exe跑不过去。
GEOG数据有几个不同分辨率版本：默认的geog_complete包，体积大但直接可用；也可以选更高分辨率的补充包。我个人的建议是：如果只是测试、验证环境，用相对简化的版本或官方示例数据就行；如果是要真正跑业务区域，再去下载完整的高分辨率数据集。
下载回来的压缩包解压后，需要修改WPS的namelist.wps里的geog_data_path，让它指向解压后的目录。例如：
geog_data_path = '/home/yourname/WPS_GEOG'注意：GEOG数据路径中不要包含中文、空格或特殊字符。这个问题看起来不起眼，但真的有人因为路径里带了个空格，卡了一下午排查geogrid报错。
4.3 WPS三个步骤的联动关系
WPS包含三个独立程序：
geogrid.exe：生成模拟区域的静态地理数据，依赖GEOG数据包。ungrib.exe：读取GRIB格式的气象场数据，转换成中间格式。metgrid.exe：把ungrib生成的气象数据和geogrid生成的静态数据合并，输出WRF可以直接读取的文件。
测试WPS是否安装正确的简单方法是，跑一遍官方测试用例，或者直接按某个教程准备好geogrid的namelist，执行：
./geogrid.exe如果顺利，会生成geo_em.d01.nc文件。这个文件能正常生成，就说明netCDF接口、GEOG路径都没问题，WRF环境基本没大毛病了。
5. 常见安装问题排查实录
5.1 编译报错速查表
整理一份我在实际安装中经常遇到的报错对照表，方便你快速定位问题：
| 报错特征 | 可能原因 | 解决方法 |
|---|---|---|
Error: Type mismatch/argument mismatch | GCC 10+严格参数检查 | 在configure.wrf加-fallow-argument-mismatch |
找不到netcdf.inc或netcdf.mod | NETCDF环境变量错误或netCDF-Fortran没装好 | 确认NETCDF=$DIR，重装netCDF-Fortran |
HDF5相关头文件找不到 | HDF5未编译或路径不对 | 检查LD_LIBRARY_PATH是否包含HDF5的lib目录 |
undefined reference to nf_相关 | netCDF-Fortran没编译成功 | 重新编译netCDF-Fortran，确认没漏错误 |
cannot find -lmpifort | MPI包装器路径不对 | 重新设置PATH，确保mpifort可见 |
| WPS的ungrib编译失败 | jasper版本不兼容 | 重装jasper 2.x，并确认前缀目录统一 |
relocation R_X86_64_PC32 | 编译HDF5时缺-fPIC | 重编HDF5，加上CFLAGS="-fPIC" |
File 'input.nml' does not exist运行错误 | namelist文件缺失 | 从test/em_real目录拷贝namelist.input |
SIGSEGV运行崩溃 | 依赖库路径不一致或MPI版本冲突 | 重新检查LD_LIBRARY_PATH，统一全链路库版本 |
这张表基本覆盖了90%的场景。剩下10%的冷门报错，按下面思路排查。
5.2 环境变量引发的诡异问题
环境变量问题是WRF安装里最“阴间”的一类bug。表面上看所有库都装好了，但编译总是失败，或者编译成功一运行就段错误。我有一次排查了整整一天，最后发现是服务器上系统自带的netCDF路径被提前加到了环境变量里，导致WRF的configure脚本优先找到了老版本netCDF。
排查环境变量问题，先跑这三条命令：
which mpifort which nc-config which nf-config三条命令的输出路径必须在同一个$DIR/bin下。任何一个指向了/usr/bin或其他系统路径，都代表你的环境变量顺序不对，需要调整。
还有一种情况：LD_LIBRARY_PATH里既有$DIR/lib又有系统的/usr/lib/x86_64-linux-gnu，而且系统里也有一个libnetcdf。运行时优先加载哪个库完全取决于路径顺序，很容易装完环境后一运行就版本冲突崩溃。
建议的做法是在.bashrc里把$DIR/lib放到最前面，并且优先确保它出现在任何系统库路径之前：
export LD_LIBRARY_PATH=$DIR/lib:$LD_LIBRARY_PATH另外，如果你在同一台服务器上要用多个版本的netCDF或编译器，更推荐用模块化工具（如environment-modules）来隔离环境，而不是把所有路径全堆在bashrc里。这个建议尤其适合实验室服务器，因为一台机器上可能有多个用户、多个项目，混用同一个环境变量表会很酸爽。
5.3 安装后运行自检清单
环境跑通过之后，不要急着放飞，花十分钟做一个系统性自检，能帮你省去后面数据跑吐的烦恼。
自检顺序如下：
- 运行
wrf.exe看是否能识别namelist：如果没有namelist，应提示缺少文件而不是报库错误。 - 运行
geogrid.exe加一个最小namelist测试，检查geo_em.d01.nc能否生成。 - 运行
ungrib.exe的-help，确认能正常启动，并且libjasper相关库没报错。 - 检查环境变量
NETCDF、HDF5是否正确（echo $NETCDF）。 - 用
ldd main/wrf.exe | grep netcdf确认链接的netCDF版本是预期的那一个。
清单里最后一条很重要。有时候你自以为用的是自己编译的netCDF，实际ldd一看还是系统的老版本。这就是运行时问题的根源。看到结果不对就立刻回查环境变量，别继续往下跑算例。
5.4 避坑经验：移植环境的几个心得
安装多了之后，我觉得WRF移植这件事，技术难度其实一般，难的是耐心和细节。几个经验分享给大家：
第一，始终保持“一套工具链”思维。编译器用gfortran，MPI用MPICH，从依赖库到WRF主程序再到WPS，所有组件必须由同一套工具链编译产生，千万别混搭。混搭OpenMPI编译的HDF5和MPICH编译的WRF，短时间能跑，真并行起来各种怪问题。
第二，依赖库一旦编译好，优先写一个环境配置脚本固定下来。我习惯在$DIR/env_wrf.sh里写全部环境变量，以后切换用户或迁移到新服务器，直接source这个文件就恢复环境，不用逐条手动配置。
第三，configure和compile的输出一定要保存日志。说实话，每一次安装我都会把日志存好，不是为了欣赏，而是报错时可以grep -n "Error" compile.log快速定位。没有日志就只能盯终端闪屏，心态很容易崩。
第四，别迷信版本全最新。WRF不是越新越稳，依赖库更不是。比如HDF5出了新版本，过新的时候可能和netCDF-C的兼容性还没跟上；netCDF-C同理。如果你的目标是稳定跑算例，就用成熟的、经过社区验证的版本组合，也就是我在第1章给的那套，而不是天天盯着官方更新。
最后，如果安装卡住了，别急着从头再来。先看日志，分析是环境问题还是编译问题，再决定是补装、重装还是改配置。WRF整套环境一旦跑通，后续大部分时间就在跑数据、调物理参数了，前期的麻烦会变成你最有经验的一部分——下次别人问你WRF怎么装，你也可以自信地说：照着我的方法，按这个版本组合来，基本不会踩坑。
