2. 检查轨迹文件格式（.xtc, .trr, .gro, .pdb等）

轨迹文件读不进去，第一反应别急着怀疑GROMACS坏了。我遇到过好多次，用户急匆匆跑来说“我的轨迹读不了”，结果一问，拿了个.gro当轨迹传进去了。其实，文件格式错了，一切努力都是白费。

咱们先把家底摸清楚——你到底拿的是什么格式？

2.1 认清你的文件格式

GROMACS常见的轨迹/结构文件，说白了就这几种：

  • .xtc —— 压缩的二进制轨迹，只存坐标，丢了速度和能量。
  • .trr —— 完整二进制轨迹，坐标、速度、力都有，但体积大。
  • .gro —— 结构文件（单帧），不是轨迹。
  • .pdb —— 结构文件（单帧），来自PDB数据库，也不是轨迹。
  • .cpt —— 检查点文件，恢复用的，别当轨迹读。

我把它们放一起对比，你一眼就能看明白：

格式 内容 是否可作轨迹 读取工具
.xtc 压缩坐标（无速度/能量） 是 gmx traj, MDTraj, VMD
.trr 完整坐标+速度+力 是 gmx dump, GROMACS内置
.gro 单帧原子坐标+盒子 否（只能做初始结构） gmx editconf, VMD
.pdb 单帧原子坐标（含残基信息） 否（通常做参考） gmx editconf, PyMOL
.cpt 二进制检查点（状态快照） 否 gmx mdrun -cpi

关键点：.gro 和 .pdb 只有一帧。你用 gmx traj -f 读一个 .gro，GROMACS会直接报错——它期望的是一个多帧轨迹，而不是单个结构。

2.2 .xtc 格式——压缩的轨迹

我个人习惯用 .xtc 存大模拟的轨迹。为啥？省空间啊。一个 100 ns 的模拟，.trr 能到几十 GB，.xtc 可能只有几 GB。但它用了有损压缩，坐标精度从双精度降到了单精度（甚至更低）。

你想想看，如果你要做自由能插值或者精细的氢键分析，用 .xtc 就会出问题——小到 0.001 nm 的差异被压缩掉了。我以前遇到过一位做蛋白折叠的用户，用 .xtc 跑RMSD，结果死活得不到正确折叠态，换成 .trr 立马就好了。所以，需要高精度的时候，别省那点硬盘。

怎么确认你手里的 .xtc 是否完整？我最常用的命令是：

gmx check -f traj.xtc

它会打印出帧数、步长、时间范围。如果输出里出现 WARNING: short read 或 Unexpected end of file，说明轨迹写入不完整——可能模拟被强行终止了。

小技巧：如果只想看文件头，用 head -c 100 traj.xtc | xxd 可以看魔数。.xtc 的前四个字节固定是 \x31\x32\x33\x34（十进制 0x34333231），这是 XTC 魔术数。

2.3 .trr 格式——完整的轨迹

.trr 是“真真切切”的轨迹记录器。坐标、速度、力——所有信息都在里面。代价就是硬盘占用大。我一般只在需要分析动力学性质（比如速度自相关函数、扩散系数）时才用 .trr，平时跑完模拟后会把 .trr 删掉，只保留 .xtc 做常规分析。

注意一点：如果你用 gmx mdrun -x traj.xtc 同时输出 .trr 和 .xtc，它们的时间步是同步的。但 .trr 默认不输出每一帧的原子速度（除非你在 .mdp 里设 compressed-x-precision 之类的参数？其实不对，速度在 .trr 里是直接存储的）。

读 .trr 的命令：

gmx dump -f traj.trr

这个命令会把 .trr 的头部和第一帧的内容打印出来。如果打印出乱码或提示 Error reading frame，八成是文件损坏了。

2.4 .gro 和 .pdb——结构文件不是轨迹

这是最容易踩的坑。很多新手把 .gro 当轨迹传进 gmx trjconv，然后报错。我强调一遍：.gro 和 .pdb 只有一帧。你没法从一个单帧文件里提取时间序列。

那 .gro 做什么用？初始结构、参考结构、单帧快照。比如你想看模拟结束时某个构象，可以用 gmx trjconv -f traj.xtc -o frame.gro -dump 1000 导出一帧。

检查 .gro 是不是轨迹？看行数。一般 .gro 文件的结构是：

Header line
Number of atoms（整数一行）
原子坐标行（每行一个原子）
盒边界行（3个或9个浮点数）

如果中间出现多组原子坐标，那可能是错误的“多帧 .gro”——这其实不是标准 .gro，而是一个被错误拼接的文件。我曾经处理过一个用户，他把多个 .gro 文件 cat 到一起当作轨迹读，结果当然失败了。

2.5 快速识别文件格式的方法

你不确定文件是啥格式？Linux 下最直接的是用 file 命令：

file traj.xtc
file traj.trr
file conf.gro
file ref.pdb

输出大概长这样：

traj.xtc: GROMACS XTC compressed trajectory
traj.trr: GROMACS TRR trajectory (full precision)
conf.gro: GROMACS GRO coordinate file
ref.pdb: Protein Data Bank file

如果 file 说“data”或“ASCII text”，那就可能是文件头损坏了。我建议你再检查一下文件的魔数（Magic number）：

格式 魔数（前4字节，十六进制）
.xtc 31 32 33 34
.trr AB AB AB AB（不是固定值，但通常以 0xab 开头）
.gro ASCII 文本，无固定魔数
.pdb ASCII 文本，以 "HEADER" 或 "ATOM" 等开头

用 xxd 看一眼就行：

xxd -l 4 traj.xtc
xxd -l 8 traj.trr

2.6 错误格式的常见表现

当你用 GROMACS 工具读轨迹时，日志里会出现一些典型报错。我把常见的列出来：

  • Fatal error: File input/output error —— 文件损坏或不存在。检查路径和磁盘。
  • Read error on trajectory file —— 一般是 .xtc 被截断了。用 gmx check 看看。
  • Could not determine file format —— 文件扩展名不对或没有扩展名。用 file 命令识别。
  • Number of atoms mismatch —— 轨迹中的原子数与拓扑不匹配。可能是模拟过程中跑飞了（水盒子蒸发？），或者导错了结构。

千万不要 手动修改二进制轨迹文件（.xtc / .trr）的字节内容来“修复”它。我见过有人用十六进制编辑器把文件头改成像样，结果读出来全是乱码。正确的做法是：如果模拟突然中断，用 gmx mdrun -cpi state.cpt 续跑，生成完整的轨迹；或者用 gmx trjconv -f truncated.xtc -o fixed.xtc -skip 0 尝试重写截断后的部分（但可能不成功）。

2.7 轨迹格式诊断流程图

下面这张图可以帮助你快速排查：文件到底能不能读、是什么格式。我画的这个决策树，你一步一步走就行。

轨迹文件格式诊断流程 拿到文件 看文件扩展名（.xtc/.trr/.gro/.pdb） 扩展名明确 扩展名不明确或没有 用 file 命令确认 输出：GROMACS XTC / TRR 等 用 gmx check -f 检查完整性 用 file 命令识别 输出：GRO / PDB / data 警告：这不是轨迹文件 如果 file 命令输出 "data" 或 "ASCII text" 很可能文件头已损坏或根本不是 GROMACS 格式 可用 gmx dump / trjconv 读取

这张图从左到右走一遍。先看扩展名，再用 file 命令确认，最后用 GROMACS 工具检验。如果中间任何一步出现 File I/O 错误，那就是文件物理损坏了，需要重新生成。

2.8 总结几种容易混淆的情况

  • 明明写了 .xtc，但读不了？ 先确认文件大小：如果只有几百字节，可能是空文件或头部损坏。用 ls -lh 看看。
  • .gro 文件有几万行？ 那可能是把多个 .gro 拼在了一起。用 wc -l 看看总行数，正常情况下应该是 2 + 原子数 + 1。超出太多就是多帧伪编码。
  • .pdb 文件里有很多 END 和 MODEL？ 那是多模型 PDB（比如 NMR 结构集合），不是轨迹。GROMACS 的 gmx trjconv 读不了，要用 gmx pdb2gmx 转成 .gro 再处理。

我的经验：如果你要批量处理大量轨迹文件，建议写个脚本：先用 file 过滤出是 GROMACS 格式的，再用 gmx check 读帧数，最后用 gmx trjconv 统一转成 .xtc 格式。这样能排除掉 90% 的格式问题。

文件格式检查是调试轨迹读取失败的第一步。你走完这套流程，基本能定位九成的问题。剩下的就是拓扑不匹配、时间戳错乱之类的细节，咱们后面章节慢慢聊。

← 上一章 📖 返回目录 下一章 →