pyVPRM predictions模块解析：从数据准备到WRF-Chem接入的完整指南

跑WRF-Chem的人应该都有过这种经历：模式跑着跑着，突然发现近地面的CO₂浓度场出现一块莫名其妙的异常高值，或者O₃模拟结果对某个时次特别离谱，查来查去最后定位到植被排放输入上。VPRM（Vegetation Photosynthesis and Respiration Model）就是给WRF-Chem提供这类生物圈通量的常用工具，而pyVPRM_examples仓库里的vprm_predictions模块，是整套流程中最核心、也最容易让人卡壳的一环。

这篇我会直接把vprm_predictions从数据准备、单点预测、区域批量到接入WRF-Chem的完整链路拆开讲，包括每个环节为什么要这么做、哪些参数是可以根据自己研究区调整的、哪些是绝对不能乱动的。如果你正准备用pyVPRM跑自己的研究区，或者已经在跑但结果总是不对劲，这篇应该能帮你省下不少排查时间。

1. vprm_predictions是干什么的：先搞懂VPRM在WRF-Chem里扮演什么角色

1.1 WRF-Chem的植被排放缺口

WRF-Chem本身带有一些生物源排放方案，比如MEGAN，但很多人实际使用中会碰到一个问题：MEGAN的默认排放因子和植被分布数据比较老，对于特定区域、特定年份的模拟，不确定性很大。VPRM的优势在于它直接使用卫星反演的植被指数（EVI、LSWI）来动态刻画植被的光合活性和水分状态，而不是依赖静态排放因子表。这意味着它能捕捉到植被的季节变化、干旱胁迫、甚至火灾后的植被恢复过程——这些是传统排放清单很难体现的。

vprm_predictions就是这套VPRM流程里负责“预测”的模块。它读入气象驱动和遥感植被指数，计算出一组生物圈通量：总初级生产力GPP、生态系统呼吸ER、净生态系统交换NEE。这三个量是WRF-Chem生物圈CO₂反馈的核心输入。

1.2 VPRM的计算逻辑一句话版本

VPRM不是一个复杂的过程模型，它的核心思想可以用一个很简洁的框架概括：

NEE = ER + GPP

其中GPP由光能利用效率公式计算，ER由温度和呼吸基准速率决定。

GPP = FAPAR × LUE × PAR

PAR（光合有效辐射）来自气象驱动；FAPAR（光合有效辐射吸收比例）由EVI线性关系估算；LUE（光能利用效率）受温度和水分胁迫因子调节。ER则是基于一个与温度相关的指数函数计算，参考呼吸速率会根据不同植被功能型（PFT）取不同值。

所以vprm_predictions实际上就是把这个公式实现成可运行的代码，并且处理了各种输入数据的读入、时间对齐、空间匹配问题。

1.3 为什么叫“predictions”而不叫“emissions”

这一点值得先说明白。VPRM输出的GPP/ER/NEE在严格意义上说是“通量预测”，不是传统排放清单里的那种“排放量”。它反映的是生态系统和大气之间的CO₂交换速率，单位通常是μmol CO₂ m⁻² s⁻¹。WRF-Chem里面有一个专门的VPRM模块（wrfchemvprm）负责读取这些通量，然后耦合到传输和化学过程中。

很多初学者在这里会犯一个概念性错误：把VPRM输出的NEE直接当排放源项填进anthro_emiss，或者反过来把GPP单独当作排放源，导致碳通量重复计算或者正负号搞反。后面第5章我会专门讲接入WRF-Chem时要注意的单位和符号问题。

2. 运行vprm_predictions之前：文件结构、数据约定和准备工作

2.1 pyVPRM_examples仓库里你会看到什么

虽然仓库名叫“examples”，但它的结构其实比大多数人想象的要完整。以我拿到手的版本为例，典型目录大概是这样：

text复制pyVPRM_examples/
├── data/
│   ├── met_drivers/           # 气象驱动
│   ├── satellite/             # EVI/LSWI，如MOD09A1-derived
│   ├── landcover/             # 土地覆盖类型（PFT）
│   └── params/                # VPRM参数表（不同PFT参数）
├── scripts/
│   ├── vprm_core.py           # VPRM核心计算函数
│   ├── vprm_predictions.py    # 主程序，单点/栅格预测入口
│   ├── prep_inputs.py         # 数据预处理，把原始数据转成统一格式
│   └── utils.py               # 时间、坐标、单位换算辅助函数
├── config/
│   └── example_config.yaml    # 配置文件模板
└── docs/
    └── vprm_predictions.md    # 使用说明

vprm_predictions在这套体系里是一个面向用户的入口，它的职责是：读配置、加载输入、调用vprm_core.py里的计算函数、输出NetCDF或文本结果。换句话说，你实际要改动的文件通常是配置文件，核心计算函数一般不用动。

2.2 输入数据格式约定

这个环节是很多人的第一个坑。VPRM需要的数据本身并不神秘，但格式要求很具体：

这里有个关键约定：VPRM计算时，EVI和LSWI通常是8天合成的。如果你准备用逐日或逐小时的EVI数据，需要确认来源是否做过时间插值，因为很多实践中的做法是把8天合成值在时间轴上线性插值到逐日，再在逐小时计算时保持当天值不变。

举例来说，读取气象驱动的典型代码：

python复制import xarray as xr
import numpy as np

def load_met(met_file):
    ds = xr.open_dataset(met_file)
    # 单位转换：K -> degC
    temp_c = ds['T2'] - 273.15
    # 短波辐射 W/m2，取正午附近时次用于光合计算
    swdown = ds['SWDOWN']
    return temp_c, swdown

2.3 配置文件里必须盯住的几个字段

example_config.yaml里的字段并不算多，但有几个直接决定运算结果是否合理。

yaml复制project:
  name: "my_study_area"
  start_time: "2021-06-01T00:00:00"
  end_time: "2021-06-30T23:00:00"
  time_step_min: 60

domain:
  lat_range: [30.0, 35.0]
  lon_range: [110.0, 120.0]
  grid_res_km: 10

vegetation:
  landcover_file: "data/landcover/MOD12Q1_2020.tif"
  pft_params_file: "data/params/vprm_params_MODIS.csv"

satellite:
  evi_files: "data/satellite/EVI_2021_*.tif"
  lswi_files: "data/satellite/LSWI_2021_*.tif"
  interpolation: "linear"

met_drivers:
  file: "data/met_drivers/era5_2021.nc"
  temp_var: "T2"
  swdown_var: "SWDOWN"
  par_factor: 0.45

output:
  format: "netcdf"
  variables: ["GPP", "ER", "NEE"]
  filename_prefix: "vprm_output"

par_factor这个字段容易忽略。VPRM公式里的PAR是光合有效辐射，不是总短波辐射。很多气象数据只提供总短波辐射SWDOWN，就需要乘一个系数把总辐射拆出PAR。不同文献取值略有差异，常见范围在0.45到0.5之间。这个因子的取值直接影响GPP绝对量，但如果你只关心相对变化或者季节对比，不同因子带来的差异可能没有你想象中大。

3. 单点预测代码拆解：从气象驱动到NEE/GPP/ER的完整计算链路

3.1 核心公式的代码表达

VPRM的光能利用效率公式看起来简单，但落实到代码里有一堆细节。我在这里给出一个简化但可运行的版本，展示vprm_core.py里的核心计算逻辑。

python复制def calculate_gpp(par, evi, lswi, tair_c, pft_params, landcover, t_opt=20.0):
    """
    VPRM GPP计算
    par: 光合有效辐射, umol/m2/s
    evi: 增强植被指数
    lswi: 陆地表面水分指数
    tair_c: 2m气温, degC
    pft_params: 参数DataFrame
    landcover: 土地覆盖类型(用于选参数)
    """
    # 温度胁迫因子
    tmin = pft_params.loc[landcover, 'Tmin']
    tmax = pft_params.loc[landcover, 'Tmax']

    # 光合有效辐射吸收比例 FAPAR 与EVI的关系
    fapar = 1.0 - np.exp(-0.5 * evi)   # 简化形式，实际可用线性关系

    # 温度限制因子（抛物线型响应）
    tscale = np.clip((tair_c - tmin) / (t_opt - tmin), 0, None) * \
             np.clip((tmax - tair_c) / (tmax - t_opt), 0, None)
    tscale = np.clip(tscale, 0, 1)

    # 水分胁迫因子，与LSWI相关
    wscale = (1.0 + lswi) / (1.0 + lswi_max)  # lswi_max 一般取0.5或最大值

    # 光能利用效率
    lue = pft_params.loc[landcover, 'LUE_max'] * tscale * wscale

    # GPP
    gpp = fapar * lue * par
    return gpp

这里我需要强调一个容易误解的点：VPRM里面FAPAR的处理方式在不同论文里有不同做法。有的直接使用FAPAR = a * EVI + b的线性关系，有的用指数饱和形式。pyVPRM里一般预置了默认的PFT参数，如果你修改了FAPAR关系，需要确认是否要把参数表一起改掉，否则会出现参数不自洽的问题。

3.2 生态系统呼吸ER的计算与温度敏感性

ER的计算也有一定灵活性。VPRM中最常用的形式是：

python复制def calculate_er(tair_c, gpp, pft_params, landcover, alpha=0.1, beta=0.1):
    """
    ER = alpha * T_scaled * GPP + beta * Q10温度函数
    简化形式：呼吸随温度指数增加
    """
    # 参考呼吸速率，在10度时的呼吸
    resp_ref = pft_params.loc[landcover, 'resp_ref']

    # Q10函数
    q10 = pft_params.loc[landcover, 'Q10']
    er = resp_ref * np.power(q10, (tair_c - 10.0) / 10.0)

    # 也可以加入GPP相关项，表示自养呼吸
    er += alpha * gpp * np.exp(beta * tair_c)
    return er

呼吸参数很多文献里会把resp_ref设定为每个PFT的常数，但实际模拟中发现它对NEE结果影响非常大，尤其是夜间。你现在看到的pyVPRM_examples里可能包含两套呼吸方案：一套是简单Q10温度函数，另一套是考虑GPP的自养呼吸分量。调试时建议先用简单方案跑通，再换复杂方案看差异。

3.3 从配置到输出：主程序调用链

vprm_predictions.py主程序的逻辑实际上很直白：

python复制def main(config):
    # 1. 读取配置
    cfg = load_config(config)

    # 2. 加载土地覆盖和PFT参数
    landcover = load_landcover(cfg.domain.landcover_file)
    pft_params = load_params(cfg.vegetation.pft_params_file)

    # 3. 遍历时间步
    times = pd.date_range(cfg.project.start_time, cfg.project.end_time,
                          freq=f"{cfg.project.time_step_min}min")

    results = {}
    for t in times:
        # 读取气象（插值到当前时刻）
        temp_c, swdown = load_met_at_time(cfg.met_drivers.file, t)

        # 读取当天的EVI和LSWI
        evi = load_evi(cfg.satellite.evi_files, t)
        lswi = load_lswi(cfg.satellite.lswi_files, t)

        # PAR换算
        par_umol = swdown * cfg.met_drivers.par_factor * 4.57

        # 调用核心函数
        gpp = calculate_gpp(par_umol, evi, lswi, temp_c, pft_params, landcover)
        er = calculate_er(temp_c, gpp, pft_params, landcover)
        nee = er + gpp   # 注意：VPRM里NEE = ER + GPP，GPP为负值

        results[t] = {'GPP': gpp, 'ER': er, 'NEE': nee}

    # 4. 输出
    write_output(results, cfg.output)

注意上面NEE的计算里GPP我写的是负值。在VPRM惯例中，GPP是碳吸收，通常为负（生态系统从大气吸收CO₂），ER是呼吸排放为正，NEE是二者之和。但WRF-Chem或者某些后处理工具可能使用相反的符号约定，这点在后面接入时会再次遇到。

3.4 为什么PAR单位换算总是被忽略

我看到太多人跑VPRM结果偏大一倍，最后发现是PAR单位错了。气象模型输出的短波辐射一般是W/m²，而VPRM核心公式里PAR需要的单位是μmol m⁻² s⁻¹（光合光子通量密度，PPFD）。这两者之间的换算系数不是1，而是大约4.57。

把W/m²转换成μmol m⁻² s⁻¹，需要先知道光子的能量。对于PAR波段（400-700nm），平均光子能量大约对应4.57 μmol/J。所以：

text复制PAR_umol = SWDOWN_W * 0.45 * 4.57

这个0.45是PAR占总短波辐射比例，4.57是W转μmol的系数。如果你的驱动数据本身就是PAR（比如来自WRF的PAR变量），就不要再多乘4.57，否则结果会大4倍多。

4. 从单点扩展到区域：批量预测、并行处理和NetCDF输出

4.1 为什么单点能跑通还不算完

单点预测的意义在于调试参数和验证算法，但WRF-Chem需要的是空间连续的二维通量场。把单点逻辑扩展到区域，除了循环每个网格格点之外，还会碰到几个单点模式没有的问题：

• 不同格点的土地覆盖类型不同，参数查表方式要按格点索引。
• 气象驱动的空间分辨率可能和植被指数不一致，需要重采样。
• 输出数据体积急剧膨胀，需要合理的数据结构和压缩策略。
• 计算耗时呈数量级增加，需要考虑并行。

pyVPRM_examples里给出了一个比较合理的做法：先用xarray把气象和植被数据统一到同一个网格上，然后对整个二维数组做向量化运算，而不是逐格点循环。

python复制def predict_grid(met_ds, evi_da, lswi_da, landcover_da, pft_params):
    """
    对整个二维网格一次性计算GPP/ER/NEE
    """
    # 气象场
    temp_c = met_ds['T2'] - 273.15
    swdown = met_ds['SWDOWN']
    par = swdown * 0.45 * 4.57

    # 分PFT取参数（准备一个与网格同形状的参数数组）
    pft_ids = np.unique(landcover_da.values)
    lue_grid = np.zeros_like(landcover_da.values, dtype=np.float32)
    for pft in pft_ids:
        mask = landcover_da.values == pft
        lue_grid[mask] = pft_params.loc[pft, 'LUE_max']

    # 向量化计算温度胁迫
    tmin_grid = ...  # 类似上面处理
    tscale = np.clip((temp_c - tmin_grid) / (t_opt - tmin_grid), 0, None) * \
             np.clip((tmax_grid - temp_c) / (tmax_grid - t_opt), 0, None)

    # GPP计算
    fapar = 1.0 - np.exp(-0.5 * evi_da.values)
    gpp = fapar * lue_grid * tscale * par.values

    return gpp

向量化运算在区域尺度上的性能提升是几十倍甚至上百倍。如果你发现自己写的循环在300×300的网格上跑了几个小时，大概率是你在一格一格地做标量运算。

4.2 并行处理策略：multiprocessing还是分块

pyVPRM_examples里通常没有内置MPI并行，但实际区域模拟中，并行是绕不开的需求。最简单可靠的做法是按“时间段”做任务划分：每个月（或者每一天）作为一个独立任务，用Python的multiprocessing.Pool并行执行，最后合并输出。

python复制from multiprocessing import Pool

def run_month(month_str):
    # 构造这个月的配置
    cfg_month = generate_month_config(month_str)
    output_file = f"vprm_output_{month_str}.nc"
    run_predictions(cfg_month, output_file)
    return output_file

if __name__ == "__main__":
    months = ["2021_06", "2021_07", "2021_08"]
    with Pool(3) as pool:
        results = pool.map(run_month, months)

这种策略的好处是每个进程的内存占用相对可控，互相没有依赖关系，而且如果某个月份任务失败，不影响其他月份的产出。相比之下，如果你试图把一个巨大数组分块并行，要处理边界重叠和数据拼接，复杂度高很多，收益反而不明显。

4.3 输出NetCDF的字段与压缩建议

vprm_predictions输出的NetCDF文件，我建议至少包含以下变量：

写入时使用netCDF4或xarray.to_netcdf，记得开启压缩（zlib=True, complevel=4），否则一个月的小时数据就可能达到几个GB。

python复制ds = xr.Dataset(
    {
        "GPP": (("time", "lat", "lon"), gpp_array),
        "ER": (("time", "lat", "lon"), er_array),
        "NEE": (("time", "lat", "lon"), nee_array),
    },
    coords={"time": times, "lat": lat, "lon": lon},
)
ds.to_netcdf("vprm_output.nc", encoding={"GPP": {"zlib": True, "complevel": 4}})

5. 把预测结果送进WRF-Chem：单位、时间对齐和格式转换

5.1 WRF-Chem里的VPRM模块期望什么格式

这是整个流程里最容易让人崩溃的一步。vprm_predictions输出的通量和WRF-Chem实际需要读入的通量，单位、坐标系、时间戳可能都不同。

WRF-Chem通过wrfchemvprm模块读取VPRM输出时，通常期望输入是一个NetCDF文件，里面包含逐小时的二维通量场，且：

• 水平网格需要和WRF-Chem的d01（或对应域）完全一致，或者允许WRF读入后自行插值，但强烈建议提前重采样。
• 时间应该是UTC小时，且最好整点对齐。
• 变量名需要和你WRF-Chem版本里的读取代码匹配。常见命名是GPP、ER、NEE，但不同版本可能有差异，务必检查你源码里的module_vprm.F或类似文件。

你可以用WRF的interp_emis工具来做通量场的水平插值，也可以直接用Python的xesmf或scipy.interpolate把VPRM结果的经纬度网格重采样到WRF投影的网格上。

5.2 单位转换的完整链条

VPRM输出的单位为μmol CO₂ m⁻² s⁻¹，但WRF-Chem里很多排放输入要求单位为mol km⁻² hr⁻¹，或者mol m⁻² s⁻¹，具体取决于你用的是哪个版本、哪个选项。单位转换本身不复杂，但要记清楚转换路径。

假设要把μmol m⁻² s⁻¹转成mol km⁻² hr⁻¹：

text复制1 μmol = 1e-6 mol
1 km² = 1e6 m²
1 hr = 3600 s

所以：
1 μmol m⁻² s⁻¹ = 1e-6 mol / 1 m² / 1 s
                = 1e-6 * 1e6 mol / 1 km² / 1 s
                = 1 mol km⁻² s⁻¹
                = 3600 mol km⁻² hr⁻¹

也就是说，从μmol m⁻² s⁻¹到mol km⁻² hr⁻¹需要乘以3600。很多人在这里会漏掉或者多乘，结果通量场数值差了3到4个数量级，模式里CO₂浓度直接爆表。

写一个通用转换函数：

python复制def convert_flux_units(data_umol_m2_s, target="mol_km2_hr"):
    if target == "mol_km2_hr":
        return data_umol_m2_s * 3600.0
    elif target == "mol_m2_s":
        return data_umol_m2_s * 1e-6
    elif target == "umol_m2_s":
        return data_umol_m2_s
    else:
        raise ValueError(f"Unknown target: {target}")

5.3 正负号和NEE的口径问题

VPRM里NEE = ER + GPP，其中GPP为负（吸收）、ER为正（排放）。但在WRF-Chem的化学传输框架里，排放源项默认是“正的源”。于是很多人会把VPRM输出的负数GPP直接填进排放数组，结果模式里变成一个负的排放（也就是沉降），看起来很奇怪。

实际的接入方式取决于你的科学目标：

• 如果模式要模拟CO₂浓度，应该使用NEE这个净通量，并且要确认WRF-Chem里对NEE的符号约定是正数代表进入大气（源）还是离开大气（汇）。
• 如果模式要分别处理光合和呼吸过程（比如耦合到生态模块），则需要GPP和ER各自单独的场。

我的建议是：无论哪种情况，都先在接入前做一次符号和量级的可视化检查。画出研究区平均通量的日变化曲线，确认白天NEE为负（碳汇）、夜间为正（碳源），并且量级在-20到+10 μmol m⁻² s⁻¹这个典型范围内，再对接模式。

5.4 时间对齐：8天植被指数与逐小时通量的矛盾

VPRM输入里面有8天合成的EVI/LSWI，但输出是逐小时通量。很多人会疑惑：既然EVI是8天的，那逐小时GPP的变化是不是都是气象驱动带来的？

答案是肯定的。在vprm_predictions的设计里，EVI/LSWI通常被当作在8天窗口内不变，但PAR、温度是逐小时变化的，所以GPP的日变化和天气尺度波动都来自气象驱动。EVI只调节植被光合能力的“底数”。

这就带来一个实际操作问题：如果你的气象驱动是从WRF输出里提取的，而WRF输出的短波辐射在雨天会显著减小，那么VPRM预测的GPP也会显著减小，这其实是合理且有价值的——因为它体现了云对光合作用的抑制。但如果你的EVI数据本身被云污染了（比如8天合成窗口内云太多，EVI偏低），而你又没有做质量过滤，那么VPRM会预测出一个系统性偏低的光合能力，结果连续几天GPP都不对。

这个问题的标准解法是：使用MOD09A1这种带质量标识的8天合成产品，在预处理时把云污染像元标记为缺失，然后在时间上做线性插值填补。pyVPRM_examples的prep_inputs.py里应该有类似逻辑，但我建议你务必检查一下自己对云掩膜的处理是否严格，尤其是夏季多云地区。

6. 实测中的常见坑和我的调试建议

6.1 坑一：EVI和LSWI的数值范围没统一

不同来源的EVI产品，数值范围可能差很大。MOD13A1的EVI通常在-0.2到0.8之间，但如果你用了别的产品，或者自己从反射率计算EVI，数值范围可能完全不同。VPRM公式里的FAPAR和水分胁迫因子都对EVI/LSWI的绝对值很敏感。

我遇到过最典型的案例：有人用哨兵2影像自己算EVI，得到的是0到1之间的浮点数，然后直接喂给VPRM，结果GPP比合理值大了将近一倍。后来发现他把MOD13A1的EVI（已经乘以10000存储的整型）和S2的浮点EVI混用了。

调试建议：

• 统一使用一体化的植被指数产品，不要混用。
• 如果是自己计算，务必先做归一化验证，确认与MODIS产品在同一量级。
• 在配置里可以设置evi_scale_factor，把输入数据统一换算到标准范围。

6.2 坑二：土地覆盖分类和PFT参数表对不上

VPRM参数表通常是按植被功能型（PFT）组织的，比如常绿针叶林、落叶阔叶林、混交林、灌木、草地等。但土地覆盖数据（如MOD12Q1）的IGBP分类有17类，两者并不是一一对应。如果prep_inputs.py没有把IGBP重分类到VPRM的PFT体系，或者重分类规则和你采用的参数表不匹配，就会出现大量格点落入“未定义”类型，计算时不是报错就是输出为0。

我自己用过的一个映射关系示例：

注意农田的处理要尤其小心。VPRM早期的参数表里没有专门的农田PFT，或者使用的是草地参数近似。但农田在生长季的光合能力远高于草地，如果你的研究区是农业区，用默认参数会显著低估GPP。我看到pyVPRM_examples的更新版本里有加入作物专用参数的尝试，但成熟度参差不齐，建议你针对自己研究区的主要作物类型查一下文献，手动调整LUE_max和呼吸参考速率。

6.3 坑三：PAR在日出日落附近出现不合理低值

短波辐射在日出日落附近很小，GPP也会相应趋近于零，这本身是对的。但如果你的气象驱动里夜间短波辐射没有严格清零，而是一个小正数（比如模式数值残留），VPRM会在夜间计算出正的GPP——也就是不该有光合作用的时候出现了光合作用。这个误差单独看每步很小，但积累到月尺度会污染NEE的日变化曲线，让夜间呼吸看起来偏低。

排查方法很简单：统计一下PAR大于0但短波辐射小于某个阈值（比如2 W/m²）的格点，看是不是集中在日出日落时段。如果是，就在预处理里加一个硬性判断：

python复制swdown = swdown.where(swdown > 5.0, 0.0)

我自己跑模拟时会把阈值设在5 W/m²，小于等于5的统统置零。这个操作对白天通量几乎没有影响，但能让夜间NEE干净很多。

6.4 坑四：与WRF-Chem耦合时的时间步长不一致

VPRM输出频率和WRF-Chem的耦合频率需要匹配。WRF-Chem通常每3小时或每小时读取一次VPRM通量，时间上要求是“当前时刻”的值，而不是某一时间段平均。如果你的VPRM输出时间戳是每个小时整点，而WRF-Chem在读入时用的是模式步长内的平均或者上一个时刻的值，就会引入时间滞后。

简单的解决方案是确保VPRM输出文件的时间坐标用的是严格整点UTC，并且在WRF-Chem的namelist.input里设置正确的io_form_vprm和读取间隔。如果模式步长是120秒，排放场每小时更新一次是可以接受的，但不要用6小时平均的GPP去驱动逐分钟的模式积分，那样光合作用的日变化会被抹平。

6.5 我的调试流程：从单站日变化到区域月总量

最后分享一个我自己的调试SOP，按这个顺序走下来，大部分问题都能在半小时内定位：

1. 选择一个有通量观测的站点（比如ChinaFlux或者AmeriFlux里的草地或森林站），提取VPRM预测的单点时间序列。
2. 对比观测的NEE日变化。重点看白天谷值出现的时刻、夜间呼吸的底噪、以及早晚转换的斜率。VPRM对PAR极其敏感，所以白天GPP峰值的时刻应该和太阳辐射峰值高度一致，如果差超过2小时，说明时间对齐有问题。
3. 看月总量。把GPP月总量和遥感产品（比如MOD17）对比，差异在30%以内属于正常，差异超过100%基本可以确定是EVI或PAR处理有问题。
4. 区域结果画图，检查土地覆盖边界上是否有明显的参数跳变。如果有，通常是PFT参数表映射问题，而不是气象驱动的问题。
5. 最后再接入WRF-Chem，跑一个48小时的短期测试，输出CO₂浓度看空间分布是否合理。城市或工业区附近的CO₂浓度应该明显高于森林区域，否则就是通量场符号或单位出了问题。

这套流程我已经用了很久，基本上每次换研究区、换数据源都能靠它快速定位问题。VPRM本身不难，难的是把一堆来源不同、格式各异的数据整理成它想要的输入，并在结果出来后做有效的质量检验。只要你能画出一张像样的GPP季节变化曲线，后面的WRF-Chem耦合其实只是个体力活。