3. 使用 gmx check 验证轨迹文件完整性

说实话，我见过太多因为轨迹文件损坏而浪费几周算力的案例。我自己也翻过车——有一次跑完200ns的模拟，一读轨迹就崩，最后发现是磁盘空间不足导致.xtc文件在写入时被截断了。从那以后，gmx check就成了我的例行检查工具。

这章咱们就把gmx check怎么用来验证轨迹完整性讲透。你会学到它的命令行用法、输出解读、常见错误以及如何跟后续排查联动。说白了，就是给你的轨迹文件做个“体检”。

3.1 gmx check 命令基础

gmx check 是GROMACS自带的文件完整性检查工具。它能读入结构、轨迹、拓扑等多种格式，并报告潜在问题。

基本用法很简单：

gmx check -f traj.xtc

如果你想同时检查结构和轨迹：

gmx check -f traj.xtc -s topol.tpr

我个人习惯加-quiet选项，让输出更干净，只看关键信息：

gmx check -f traj.xtc -quiet

为什么用-s提供 .tpr 文件？因为gmx check会根据 .tpr 里的拓扑信息校验原子数、残基编号等是否匹配。这在排查轨迹错位时特别有用。我曾经遇到轨迹的原子顺序跟拓扑不一致，就是靠这个组合发现的。

3.2 检查轨迹文件（.xtc / .trr）

对于最常遇到的.xtc和.trr文件，gmx check会输出帧数、时间窗口、是否有NaN等。来看个典型输出：

Reading frame       0 time    0.000
Reading frame      10 time  100.000
...
Last frame         99 time 1000.000

  Reading timestep ... 10.000
  Total number of frames: 100
  Number of atoms:    10000
  Box size:  6.0   6.0   6.0
  Trajectory seems OK.

看到“Trajectory seems OK.”你可以松一口气。但如果没有这句话，或者输出中断，那就得警惕了。

一个容易忽略的细节：gmx check默认只检查前1000帧。如果你的轨迹很大，要加上-nframe参数：

gmx check -f big_traj.xtc -nframe 100000

为什么不直接设成最大的？因为读取全部帧可能很慢。我建议先读前百分之一看看，没问题再全检。嗯，这里有个权衡。

3.3 常见错误及含义

gmx check输出的错误信息有时比较隐晦。下面这张表总结了最常见的情况：

3.4 修复与预处理

验证出了问题怎么办？gmx check本身能修复一些简单问题：用-fix选项。

gmx check -f traj.xtc -fix broken_fix.xtc

这个命令会尝试修复缺失坐标（比如用上一次帧填充）和NaN。但你要知道，修复后的文件可能已失真。我的建议是：仅当你能接受数据近似值时使用。否则，优先从原始模拟重新提取。

更通用的修复手法是用gmx trjconv配合-skip或-dt参数跳过坏帧。先通过gmx check定位坏帧索引，然后：

gmx trjconv -f traj.xtc -o clean.xtc -s topol.tpr -skip 0 -b 0 -e 500 -only

注意：gmx check不是万能的。对于更深层的逻辑错误（比如水分子乱飞但坐标数值正常），它发现不了。这时需要结合RDF、MSD等分析结果来判断。我在做蛋白-配体模拟时，就遇到过轨迹看起来完整但配体姿态完全不对的情况，最后还是靠人眼判断出来的。

3.5 自动化检查脚本思路

如果你经常跑大量模拟，写个脚本批量检查会省很多事。我的个人脚本大概长这样：

#!/bin/bash
for traj in simulations/*/traj.xtc; do
    echo "Checking $traj"
    gmx check -f "$traj" -quiet 2>&1 | tail -1
    if [ $? -ne 0 ]; then
        echo "ERROR in $traj" >> check_fail.log
    fi
done

这只是一个骨架。实际上我还会加上帧数、时间范围的验证。你可以根据自己的需求扩展。

接下来，我们用一张流程图理清整个检查流程。