CESM地球系统模式从入门到实战：架构解析、环境配置与故障排查指南

接手CESM的第一天，我盯着屏幕上一串串create_newcase、case.build、xmlchange的命令，完全不知道这些像暗号一样的东西会把实验带向哪里。文档是厚厚一摞，但真正跑起来之后的心得，往往是那些没有写的坑里爬出来的。这篇不是官方手册的复读，而是把这套地球系统模式从架构理解、环境搭建、实验配置到故障排查的完整链路，按照我实际操作的顺序重新讲一遍。不管你是第一次接触CESM的新手，还是准备把实验从大气模式扩展到全耦合的老手，这里面的经验都可以直接拿去做参考。

1. 地球系统模式CESM的定位：从单学科模式到全耦合的跨越

1.1 CESM到底是什么，和大气环流模式的区别

很多刚入门的人会有个误会，觉得CESM只是“更大一号的天气模式”。实际上，地球系统模式（Earth System Model，ESM）和大气的通用环流模型（AGCM）之间有本质的区别：AGCM只算大气，海温、海冰、陆面状态都是“给定边界条件”，也就是外强迫数据；而CESM是把大气、海洋、陆面、海冰、径流、冰盖这些圈层全部耦合在一起，让它们在同一段模拟时间轴里互相交换通量、彼此反馈。

简单说，大气模式的输出里，海洋可能只是一个随季节变化的固定温度场；而在CESM里，海温是海洋模式自己算出来的，然后反哺给大气做感热、潜热交换，同时大气给海洋风应力、淡水通量和辐射，两边边算边互相影响。这个“动态反馈”是“地球系统”四个字的核心价值所在。

CESM的全称是Community Earth System Model，由美国国家大气研究中心（NCAR）主导开发，社区属性非常强。从早期的CCSM3/CCSM4一路迭代到现在的CESM2系列，每一个组件都有独立的开发社区和维护版本，再通过统一的框架集成在一起。所以你下载的CESM不是一个“软”，而是一整套组件代码加脚本框架的集合体。

1.2 六大组件和各自动力学核心

这套模式的组件结构，我习惯用一支乐队来打比方：每个声部都有自己的乐谱和演奏技法，但合奏时必须由指挥统一节奏，否则各吹各的，整首曲子就垮了。CESM里的“声部”和“指挥”分别是：

这些组件之间的“指挥”是耦合器CPL7。它负责把各组件的网格场插值到其他组件需要的网格上，统一交换时间基准，并保证能量和淡水通量守恒。后面第4章我会专门展开。

如果到这里你还不太理解为什么需要这么复杂的组件拆分，可以反过来想：如果只算大气，那么陆面蒸发怎么来？海冰覆盖面积怎么定？径流注入海洋的淡水怎么给？这些一旦全部外包给“固定强迫数据”，模式的内部一致性就没有了，你也就无法研究海冰-大气反馈这类核心问题。CESM的价值，正是把这个多圈层反馈链在代码层面完整地搭起来。

2. 从零搭起一套CESM运行环境：安装与配置中的关键抉择

2.1 硬件选型：先想清楚你要跑多长、跑多细

我第一次配机器时犯过一个错误：只盯着“核数多不多”，忽略了内存、磁盘和I/O，结果编译倒是成功了，跑起来之后输出文件把家目录整个写爆。

CESM的硬件需求取决于你的实验方案，但有一组比较稳妥的起步配置：

• CPU：至少64物理核。跑f09_g17（1度大气，1度海洋）这类常用网格，64~128核能把单核负载控制稳定，避免每个进程内存超限。
• 内存：每核2GB起步。CESM各组件对内存的消耗不均匀。比如CAM6在SE动力核心下，谱元网格需要额外的数组空间，内存小了容易直接崩。128核的话，256GB内存是相对安心的线。
• 磁盘：这是最容易被低估的。输入数据一套低分辨率大约几十GB，但长期模拟的历史输出会轻松超过输入数据一个量级。建议预留实验输出目录至少2TB，并用独立挂载点，不要和系统盘抢空间。
• 网络与I/O：集群环境下，运行目录尽量放在本地高速盘，或者并行文件系统，不要放在普通NFS网络盘上跑，否则历史输出的写入瓶颈会让几百核等你一个磁盘。

实测下来，f09_g17配置下用240核跑一个百年全耦合实验，大约需要几倍的墙钟时间，这取决于编译器优化和硬件。计算前先小规模试跑1年，用测出来的时间反推总时长，比盲目提交百年级任务靠谱得多。

2.2 依赖库的版本搭配：netcdf/mpi/pio的组合拳

CESM的运行依赖一套底层库，最核心的三个是NetCDF、MPI和PIO（Parallel I/O）。这三个库的版本关系，是新手在安装阶段最容易翻车的地方。

NetCDF需要分别安装C接口和Fortran接口，而且两者的版本要配套。比如用NetCDF-C 4.9.2，Fortran接口最好用4.6.0这一代。版本错位最常见的报错是编译阶段找不到netcdf.mod，或者链接阶段报一堆undefined reference to 'nf_create_'。

MPI方面，OpenMPI 4.x和Intel MPI都有社区实践成功的案例。关键是编译整个CESM时，所有组件和依赖库必须用同一个MPI。如果NetCDF是用OpenMPI编出来的，后面跑CESM却用Intel MPI，运行时就会因为ABI不一致出现莫名其妙的错误。所以我的习惯是：先定MPI，再编NetCDF，最后再编CESM，全程记录版本号和安装路径。

PIO2虽然由CIME框架自动管理，但它依赖NetCDF和MPI，本质上是对底层I/O的封装。你不需要手编PIO，只要保证前面两个库路径清晰、环境变量干净即可。另外CIME还依赖CMake和Python 3（高版本CESM已不再支持Python 2），这些基础工具也建议提前装齐。

注意：不要在同一台机器上同时加载多套MPI环境变量。跑CESM之前，先module list看一下当前环境，确保编译环境和运行环境完全一致。

2.3 输入数据下载与机器端口配置

CESM需要一套庞大的输入数据（inputdata），包括地形、海温、温室气体浓度、太阳常数、陆面植被类型等。在创建case之前，就必须先保证输入数据可用。下载方式通常是运行./manage_case --download inputdata，或者手动从官方数据服务器同步，但无论哪种方式，都需要先配置好机器端口（machine port）。

端口配置是CIME框架里一个很关键的步骤：你要在config_machines.xml里定义本机的名称、操作系统、编译器、作业提交系统和队列设置。这个文件位于cime/config/cesm/machines/下。如果你是单机，可以仿照其中的generic_Linux模板改一个自己的machine条目。

我第一次没配置端口就直接create_newcase，结果脚本找不到对应的机器配置，直接退出。后来才明白，CIME的整套逻辑是“先有机器定义，后有case实例”——机器端口是CIME和你本机间的翻译层，它告诉框架用哪个编译器、怎么提交作业、在哪找数据，没有这个定义，框架连编译命令都拼不出来。

这里我再补充一个经验：输入数据尽量不要放在home目录下。很多新手配置路径时会顺手用~/inputdata，但模拟一天天跑，日志和临时文件会不断增长，home的配额很快被耗尽。我一般单独建/data/cesm_inputdata这样的目录，并且在配置里用绝对路径写死，这样即使跑完一个case，下一个case也能复用同一套输入数据，避免重复下载几十GB。

3. case生命周期：CESM实验管理的一整套规则

3.1 compset与网格：命名规则里藏着实验设计

在CESM中，一次实验被称为一个case。创建case的命令是./create_newcase，但真正考验理解力的是--compset和--res这两个参数。compset是“组件集合”的缩写，它决定实验里哪些组件被激活、使用哪种强迫年限配置。

以最常见的F2000为例：F代表只跑大气CAM+陆面CLM（有时带海冰数据），2000代表温室气体、气溶胶、太阳常数这些外强迫固定在2000年附近。这种AMIP型的配置因为不含海洋和海冰动态，计算量小、稳定度高，适合跑模式调优、快速验证物理参数化。

而B1850里的B代表“fully coupled”，即所有主动组件都打开，1850表示工业化前期强迫。如果要研究气候变率、海冰反馈、全球变暖响应，就需要B类compset。全耦合的计算量比F大很多，每个时间步都要等最慢的组件，所以不要一上来就跑B类百年实验，先把F类流程走通。

网格参数--res同样有命名规则。f09_g17表示大气使用1度网格（约110km），海洋使用名义1度网格（g17）；f19_g17则是大气2度（约220km），海洋仍是1度。分辨率越高，可分辨的天气尺度过程越细，但计算量和输出量同步上涨，起步阶段建议用低分辨率跑通，再用目标分辨率做正式实验。

3.2 XML配置系统：环境变量、构建选项与运行选项

创建case之后，目录里会生成一堆env_*.xml文件，这是CESM的配置中枢。你不需要直接编辑这些XML，而是用./xmlchange命令修改，用./xmlquery查询。

几个高频修改项：

• 运行长度：./xmlchange STOP_OPTION=nyears,STOP_N=10表示连续运行10年；如果只想跑30天，就改成STOP_OPTION=ndays,STOP_N=30。
• 输出频率：./xmlchange HIST_OPTION=ndays,HIST_N=1控制历史文件按天输出。默认是月平均，如果你的分析需要日数据，再改成按天输出，但这会让输出体积膨胀很多，建议先确认磁盘够。
• 作业队列：./xmlchange JOB_QUEUE=regular适配本机集群的队列策略。没有设置好队列，提交作业时会被调度系统拒绝。

还有一种更隐蔽的配置方式是通过user_nl_cam、user_nl_clm这些“user namelist”文件，给组件传入额外的物理参数。比如想修改CAM的辐射步长，可以在user_nl_cam里加iradsw = 1。这些namelist文件在case运行前必须确认存在并写对，否则组件会使用默认值，你的实验设计就悄悄失真了。

3.3 构建与提交：case.build和case.submit之前必须检查的几件事

整个case流程通常四步：create_newcase->case.setup->case.build->case.submit。很多人以为这只是机械地敲四条命令，其实每一步背后都有必须确认的细节。

case.setup会生成运行时目录和配置文件。执行之前，一定要确认env_mach_specific.xml里的模块加载命令和你的实际环境一致。我经历过一次：脚本里加载的是Intel 19.0，但机器上module默认是Intel 2021，结果case.build编译出一堆internal compiler error，查了半天才发现是版本漂移。

case.build是编译组件库和生成可执行文件的过程。这一步耗时较长，低分辨率全组件编译在普通集群上可能要30分钟到1小时。如果编译中途失败，不要慌，先看bld/目录下的编译日志，最常见的失败是找不到某个依赖库的路径，改好环境变量后不用全部重来，直接重新执行case.build即可。

case.submit提交后，实验进入运行阶段。提交前建议随手执行一次./check_input_data，这个命令会帮你检查输入数据是否完整，能省下运行时因缺数据而崩溃的等待时间。

4. 一次完整运行的幕后：耦合器CPL7与控制流

4.1 耦合器CPL7：组件之间到底怎么对话

CESM组件之间不是简单地把各自的输出文件拼在一起，而是通过CPL7耦合器以设定好的频率进行在线交换。CPL7基于ESMF框架开发，它做的事情可以分三层理解。

第一层是网格映射。大气和海洋的网格点并不重合，大气的一个网格可能覆盖海洋的多个网格。CPL7预先计算好稀疏矩阵插值权重（比如双线性映射、保守映射），每次耦合时用矩阵乘法完成数据转移。这个映射不是“文学式地近似一下”，它有严格的守恒约束，尤其是热量和淡水通量，必须在映射过程中保持不变，否则模拟几十年后全球平均温度会缓慢漂移。

第二层是通量计算。有些交换字段如感热、潜热、长波辐射，由大气算出来交给海洋；而海表温度、海冰覆盖率等则从海洋/海冰传回大气。CPL7还负责部分通量的合成，比如把径流、冰盖融水、降水的淡水通量合并后交给海洋。

第三层是同步控制。地球系统模式里各组件的时间步长不一样：大气可能10分钟一个物理步，海洋可能30分钟一个动力步。CPL7在规定的耦合周期（通常模拟时长里的若干分钟）内，等所有组件推进到同一时刻的耦合点，再统一交换数据。这样每一轮耦合都严格同步，不存在某个组件“跑在前面”或“落后”的情况。

理解CPL7的意义在于排查问题。当你看到某个模拟年份后海洋温度异常，第一反应不应是“海洋模式有bug”，而应该先去查耦合器日志里是否有持续的通量丢失或者映射权重缺失。这类问题往往比组件内部bug更隐蔽。

4.2 运行目录会生成什么：日志与输出文件的读法

运行提交后，case目录下的run/会变成最热闹的地方。熟悉这些文件的含义，能让你在排错时节省大量时间。

每个组件会分别写自己的日志：atm.log、lnd.log、ocn.log、ice.log、cpl.log。其中cpl.log是总控日志，记录每次耦合的时间推进和通量交换；组件日志则记录各自内部的运行状态。我的排错顺序永远是：先看cpl.log最后几十行，确认模式推进到哪一天崩的，再去看那个时间点对应的组件日志。

rpointer文件是一组文本指针，记录重启文件（restart files）的位置和名称。续跑时模式根据rpointer.atm等文件找到重启数据。如果这些指针对应的文件被你误删了，续跑会直接失败。所以任何时候都不要手动删run/里的文件，除非你非常确定它在后续运行中不再需要。

历史输出文件通常以h0、h1标识区分：

• h0：默认频率的历史文件，通常是月平均，包含长期分析所需的主要变量。
• h1：更高频率输出，如日平均或6小时平均，用于分析天气尺度变率。
• h2等：极少用，一般对应瞬时快照。

文件格式是NetCDF，变量名和坐标名遵循各组件约定。分析时我习惯先用ncdump -h快速查看变量列表，再用CDO或NCO做变量提取、区域平均和时间拼接。如果你处理的是多年代月平均数据，cdo monmean和ncks的组合基本能覆盖大多数需求。

4.3 三种启动方式：initial、hybrid、branch怎么选

一个常被忽视但极其重要的选择，出现在env_run.xml的RUN_TYPE变量里。

• initial：从初始条件文件冷启动。所有组件从各自的初值出发，通常前期需要一段“spin-up”让模式内部各圈层达到平衡。
• hybrid：从其他case的重启文件启动，但允许修改某些配置。比如你想用1850年的海洋重启文件来跑2000年强迫实验，或者想换一个参数化方案后继续跑，就选hybrid。
• branch：严格接续某个运行状态的“分支”，物理过程和重启文件必须完全一致，适合做集合实验的不同扰动分支。

三种方式的关键区别在于“能否改配置”。branch的约束最强，最能保证和母实验的连续性；hybrid最灵活，但引入的偏差需要自己评估；initial适合全新实验。我遇到过同学为了省spin-up时间，从一个case的hybrid启动做了完全不同的参数化修改，结果前100年模拟出现明显的模式漂移，和母实验对不上。这提醒我们：hybrid启动后要留出足够的平衡时间，不是你想要的物理状态立刻就能得到。

5. 我在CESM运行中踩过的坑：故障排查实战记录

5.1 编译失败：netcdf与mpi库不一致

这是出现率最高的失败类型。我第一次自己搭环境时，按网上教程分别编译了NetCDF-C、NetCDF-Fortran和OpenMPI，但教程里的版本号和我机器上的不完全一致。编译CAM时，报错信息是一堆undefined reference to 'nf90_create'。

我心里明白这不是代码问题，而是链接时找不到Fortran接口的符号。查了bld/cmake的日志后发现，NetCDF-Fortran是用OpenMPI 3编译的，而我给CIME配置的MPI是OpenMPI 4，两者运行时库路径冲突，Fortran接口没有正确链接。

解决方式很直接：把NetCDF-C、NetCDF-Fortran全部用同一个OpenMPI版本重新编译一遍，再清掉bld目录重新build。此后再也没出现这类链接错误。这个坑给我的教训是：环境里的“小版本差异”在平台类代码里根本不小，务必逐库统一MPI版本。

5.2 运行中期崩溃：NaN、SIGSEGV与磁盘空间

运行到第17年突然崩溃，是比编译失败更吓人的场景。日志最后一行显示NaN detected in atm，看起来像大气模式算出了非法浮点数。

排查过程是一层层剥的。先看atm.log，NaN出现的时间点对应模式中的某次对流调整。再看cpl.log，确认该时刻陆地-大气通量交换是否有异常淡水输入，因为淡水通量异常可能破坏边界层热力结构，进而触发对流参数化里的非法数值。最后定位到陆面模式某个网格的径流变量在连续数天里出现异常峰值，根因是那个网格的植被类型在输入数据里被标记为“城市”，城市网格的水力传导率设置极端，导致数据异常。

这种隐藏在输入数据里的脏数据问题，比模式本身的bug更难发现。建议大型实验前先做一个“输入数据体检”：单独运行模式前两三年，按月尺度检查关键变量（如降水、海表温度、径流）的最大值是否在物理合理范围内。

SIGSEGV则通常是内存或栈溢出。遇到过在集群上因为ulimit -s（栈大小）被系统默认限制为8MB，而SE动力核心需要更大的栈空间。在env_mach_specific.xml里加上ulimit -s unlimited之后问题消失。

磁盘满这个坑不算技术问题，但它最容易埋雷。f09_g17输出在日频率下，每年历史文件可能达到几百GB。如果实验计划跑30年，磁盘就要先准备至少这个规模的几倍空间。我习惯在每个case里配一个磁盘检测脚本，定期检查输出目录占用，超过阈值自动告警。

5.3 一个隐蔽的坑：续跑后模型状态不一致

有一次我中断了一个100年实验，做了一些代码改进（只是修改了输出频率的namelist），然后用branch方式续跑。结果续跑后的第一个月，某些变量的输出值出现了不连续跳跃。

我没急着改物理配置，先检查了rpointer里记录的重启时间。发现问题出在中断方式上：上一次运行是在模拟年2023年6月30日输出时被作业系统杀掉，但部分组件已经写完了下一个小时的状态。重启后模式从6月30日0时开始，而输出文件却记录到了7月1日，新旧数据出现了重叠。

这类时间不连续问题，通常肉眼不容易发现，但对后期统计有隐性影响。经验是：中断实验后不要直接续跑，先检查rpointer和各组件日志末尾的时间是否完全一致，若有微小不一致，把不完整的输出文件先移走，再让模式重建该时段，确保输出序列是干净的。

6. 给新手的三条实战建议

第一，从最简配置跑通全流程。很多同学第一次就想跑B1850全耦合百年实验，结果被计算量、崩溃频率和数据量三重打击。我的建议是先建一个F2000、f19_g17、模拟1年的case，从create_newcase到后处理完整走一遍，理解每一步的控制文件和后端逻辑，再逐步上复杂配置。

第二，实验记录要“过度”而非“不足”。系统性的实验管理比纠结某个物理参数更影响你的科研效率。我给每个case建一个文本日记，记录创建时间、compset、分辨率、改了哪些XML、哪个namelist、跑了多久、崩在哪个文件、后续怎么处理。等到写论文存档或追溯问题时，这套日记的价值比任何代码管理工具都大。

第三，不要用黑客心态硬碰问题。CESM的报错信息大多有明确指向，花5分钟读日志最顶部的ERROR行和最尾部的时间信息，往往就能定位问题。遇到不确定的报错，先./xmlquery确认关键配置是否符合预期，别急着重编。依靠“先想后动”，比盲目更换库版本更有效率。

最后分享一点个人体会：地球系统模式规模庞大，很多时候我们容易陷进技术细节里不能自拔。但退一步想，模式本身是工具，真正值得投入的是用工具去逼近“圈层如何协同演变”这个物理问题。CESM的学习曲线确实陡峭，但当你第一次看到自己配置的耦合实验，跑出完整的大气环流和海洋环流同步演变的漂亮结果时，前面那些编译报错、磁盘告警和NaN排查，都会变成值得回看的旧事。