干分子模拟这行，最不缺的就是格式搬运的活儿。前阵子我在 GROMACS 里跑完一个蛋白-配体体系的平衡模拟，合作方要把最后的平衡构象拿进 Materials Studio 做后续分析。GROMACS 这边随手一导就是 gro 格式，到了 Materials Studio 那边，最顺手的文本结构格式是 car。当时我以为“分子动力学模拟 gro 格式转换为 car”就是把坐标抄一遍，真动手才发现，单位、盒子、原子类型、命名规则，哪一环都能埋雷。

这篇文章把我实际用过的 gro 转 car 完整流程写出来，包括两种格式的底层差异、三种可选转换路线、可直接复用的 Python 脚本、实操中的坑以及转换后的验证方法。如果你正在搭 GROMACS 和 Materials Studio 的联合工作流，或者只是偶尔需要把结构在两个软件之间倒腾，这篇文章应该能帮你少走不少弯路。

1. 为什么会有 gro 转 car 这种需求

1.1 开源 MD 与商业建模的生态差异

GROMACS 和 Materials Studio 在分子模拟圈子里几乎是“标配”般的存在，但两者分工完全不同。GROMACS 开源免费、跑动力学效率高、分析工具链完善，大批课题组拿它做 MD 的主力引擎；Materials Studio 是商业软件，图形界面友好，建模、力场分配、材料性质预测这些场景用起来顺手。实际项目里常见的情况是：跑到后期或者跨组协作时，需要把 GROMACS 的模拟结果拿到 Materials Studio 里做进一步处理。于是结构文件的互通就成了绕不开的环节。

GROMACS 默认的结构输出是 gro，而 Materials Studio 的 ASCII 结构文件是 car，两者都是纯文本坐标文件，看起来都是“一行一个原子”，但内部规则差别很大。直接拿 gro 文件让 MS 去读，多半读不了；就算用第三方工具强行转成 car，如果不知道两边的格式约定，转出来的文件也常常是“看起来正常、一算就出问题”。

1.2 典型场景：GROMACS 平衡构象进入 Materials Studio

举个我自己遇到的例子。某次任务里，蛋白配体复合物在 GROMACS 里跑了两百纳秒平衡，我需要把终态构象交给合作方，用 Materials Studio 做力场参数核查和结合能分析。合作方要的文件就是 car。当时我第一反应是“这不是有手就行吗”，结果第一次转出来的文件在 MS 里打开，分子碎成一片，盒子信息也丢了，原子类型全是默认值，等于废文件。

后来我复盘才发现，整个过程至少有四个地方容易出问题：单位没换算、盒子参数没正确写入、原子命名重复、原子类型没有映射。这些问题单个看都不大，叠加起来就是灾难。所以别小看这个“简单”的格式转换，它其实是两个模拟生态之间的一座桥，桥搭得不稳，后面所有计算都白搭。

1.3 转换到底在转什么

gro 转 car 本质上不是“改个后缀”，而是做四件事：

• 坐标单位换算：gro 用纳米，car 用埃，一比十的关系。
• 盒子信息重建：gro 把晶胞写在文件最后一行（3 个或 9 个数值），car 需要的是晶格常数和角度。
• 原子命名与类型映射：gro 的原子名是给拓扑文件用的，car 需要唯一原子名和力场类型。
• 辅助信息补全：残基号、残基名、电荷、力场标识等。

把这四件事搞明白了，格式转换就不再是玄学。下面我先拆解两边的格式细节，再说怎么转。

2. GRO 与 CAR 格式拆解

2.1 GRO 的固定列宽与三位小数

gro 格式的经典结构是四部分：标题行、原子数行、原子坐标行、盒子行。原子坐标行是固定列宽格式，不能简单地按空格切割，因为原子名和残基名可能带空格或者贴得很近。标准列宽是这样分配的：

1MET N 1 0.800 1.200 1.500

• 第 1-5 字符：残基号或者原子序号（历史包袱，后面细说）
• 第 6-10 字符：残基名
• 第 11-15 字符：原子名
• 第 16-20 字符：原子序号
• 第 21-28、29-36、37-44 字符：x、y、z 坐标，单位纳米，三位小数

一个完整的 gro 文件长这样：

蛋白-配体平衡构象 4 1MET N 1 0.800 1.200 1.500 1MET CA 2 0.900 1.300 1.600 2SOL OW 3 1.000 1.000 1.000 2SOL HW1 4 1.050 1.050 1.000 2.000 2.000 2.000

注意坐标只有三位小数，也就是说 gro 文件的精度被量化到 0.001 纳米，也就是 0.01 埃。这在绝大多数场景下够用，但你要知道这个精度天花板是格式本身决定的，不是转换脚本能救回来的。

2.2 CAR 的头部信息与坐标块

car 是 Materials Studio 的 ASCII 结构格式，历史可以追溯到上世纪九十年代的 BIOSYM 格式，所以文件头总是带着!BIOSYM archive 3。一个标准的 car 文件长这样：

!BIOSYM archive 3 PBC=ON 20.000000 20.000000 20.000000 90.000000 90.000000 90.000000 !DATE Mon Feb 05 15:30:00 2024 !FORCEFIELD cvff !COORDINATES N1 8.000000 12.000000 15.000000 N.am 1 MET 0.0000 CA2 9.000000 13.000000 16.000000 C.3 1 MET 0.0000 C3 9.500000 14.200000 15.800000 C.c 1 MET 0.0000 ... end

坐标行用空格分隔，字段依次是：原子名、x、y、z、力场类型、残基号、残基名、电荷。注意原子名要求全局唯一，不能像 gro 那样每个残基里都叫 CA。

2.3 一张表看懂核心差异

这张表基本就是转换脚本的核心需求清单。接下来看走哪条路。

3. 三条转换路线怎么选

3.1 OpenBabel 极速通道

如果你只是临时看一眼结构，OpenBabel 是最快的。它同时支持 gro 和 car 的读写，理论上一条命令就能出结果：

obabel conf.gro -O conf.car

但 OpenBabel 的 car 输出有几个问题。首先它的原子类型走的是 OpenBabel 自己的内置规则，出来的类型名大概率不是 Materials Studio 力场里能直接识别的类型；其次它对残基边界和盒子信息的处理比较粗，尤其是在蛋白这种多残基体系里，残基信息可能丢失或错乱。所以 OpenBabel 适合“快速预览”，不适合作为正式工作流的转换工具。

3.2 先转 PDB 再转 CAR 的做法

很多人习惯先走一步 PDB：用 GROMACS 自带工具把 gro 转成 PDB，再在 Materials Studio 里导入 PDB、另存为 car。

gmx editconf -f conf.gro -o conf.pdb

这条路的问题在于 PDB 格式本身也是一堆坑：CRYST1 记录的盒子信息经常被忽略，坐标精度同样只有三位小数，最重要的是 PDB 导入 Materials Studio 时，程序会按自己的规则重新分配原子类型，很可能把你原本的力场信息全部覆盖掉。结果就是你在 MS 里拿到的结构，和你在 GROMACS 里的体系已经是两套“语言”了。

3.3 自写脚本是正式项目的最优解

折腾过上面两条路之后，我的结论是：正式项目老老实实写个转换脚本。Gro 转 car 这种确定性转换，纯文本解析加规则映射就能解决，脚本全流程可控、可复现，还能塞进批处理流程里。这比任何“万能转换器”都靠谱，因为只有你知道自己的体系里有哪些残基、哪些离子、用哪套力场。

下面就是我一直在用的 Python 脚本的完整思路。

4. 手写 gro2car 脚本的完整实现

4.1 解析 GRO 的固定列宽

解析 gro 的关键是“按列切片，不要按空格 split”。像CA这样的原子名在固定列里是左对齐补空格的，按空格 split 会把字段搞错。正确的切片方式是：

def parse_gro(path): with open(path) as f: lines = f.readlines() n = int(lines[1].split()[0]) atoms = [] for i in range(n): line = lines[2 + i] resnum = int(line[0:5]) resname = line[5:10].strip() atomname = line[10:15].strip() atomnum = int(line[15:20]) x = float(line[20:28]) y = float(line[28:36]) z = float(line[36:44]) atoms.append([resnum, resname, atomname, atomnum, x, y, z]) box_vals = [float(v) for v in lines[2 + n].split()] return atoms, box_vals

这里第一个字段我按“残基号”处理了，但在新版 GROMACS 里这个位置记录的是原子序号，这个历史遗留问题我放到第五章详细讲。

4.2 盒子向量与晶格参数计算

gro 的盒子行有 3 个数值和 9 个数值两种。3 个数值表示正交盒子，直接就是 a、b、c，三个角都是 90 度。9 个数值表示三斜盒子，按文档顺序是：a、b、c 三个对角长度，加上六个非对角分量：v1y、v1z、v2x、v2z、v3x、v3y。这里最容易被坑的就是有人只看前三个数，把三斜盒子当成正交盒子处理，结果晶胞完全变形。

计算思路是把盒向量还原出来，再算长度和夹角：

import math def box_params(vals): if len(vals) == 3: return [vals[0], vals[1], vals[2], 90.0, 90.0, 90.0] a, b, c = vals[0], vals[1], vals[2] v1 = [a, vals[3], vals[4]] v2 = [vals[5], b, vals[6]] v3 = [vals[7], vals[8], c] def norm(v): return math.sqrt(sum(x * x for x in v)) def angle(v, w): return math.degrees(math.acos( sum(i * j for i, j in zip(v, w)) / (norm(v) * norm(w)))) return [norm(v1), norm(v2), norm(v3), angle(v2, v3), angle(v1, v3), angle(v1, v2)]

注意9 个数值的顺序在不同文档里表述略有差异，最稳妥的做法是对照你手头 gro 文件的实际数值，拿一个已知正交体系的盒子和转出来的 a b c α β γ 做核对，一旦数值对得上就直接可复用。

4.3 坐标单位换算与原子命名

单位换算很简单，gro 的纳米坐标乘以 10 就是埃：

X, Y, Z = x * 10.0, y * 10.0, z * 10.0

原子命名稍微费点心思。gro 里同一个残基内原子名不同，但不同残基之间完全可能重名，比如每个氨基酸都有一个 CA。car 要求原子名全局唯一，否则导入 Materials Studio 时可能报错或者张冠李戴。我的处理方案是“不重复就不加后缀，有重复就加全局序号”：

def make_unique_names(atoms): counts = {} for i, at in enumerate(atoms, 1): counts.setdefault(at[2], []).append(i) names = [] for base, idxs in counts.items(): if len(idxs) == 1: names.append(base) else: for j in idxs: names.append(f"{base}{j}") return names

这样单个配体里的原子名保持不变，蛋白里重复出现的 CA、N、O 自动变成 CA2、CA5、O12 这种带序号的唯一名。

4.4 原子类型映射到底怎么处理

这是整个转换里最需要“人的判断”的地方。gro 文件本身不携带力场类型，类型信息在你的拓扑文件里；而 car 必须写一个类型字段。所以脚本需要一个猜测函数，把原子名和残基名映射到 Materials Studio 力场的类型名。

我的做法是给常见体系写一套启发式规则，核心是区分蛋白骨架、水、离子和通用元素：

AMINO_ACIDS = set( "ALA ARG ASN ASP CYS GLN GLU GLY HIS ILE LEU LYS MET PHE PRO SER THR TRP TYR VAL".split() ) def guess_type(resname, atomname): name = atomname.upper() res = resname.upper() # 离子：金属钙和蛋白 alpha 碳都叫 CA，用残基名区分 if res not in AMINO_ACIDS and name == "CA": return "Ca2+" if name == "NA": return "Na+" if name == "CL": return "Cl-" if name == "MG": return "Mg2+" # 水 if res in ("SOL", "HOH"): if name == "OW": return "O.3" if name.startswith("HW"): return "H" # 蛋白骨架 if name == "N": return "N.am" if res in AMINO_ACIDS and name == "CA": return "C.3" if name == "C": return "C.c" if name == "O": return "O.2" # 按元素符号兜底 if name[0] == "C": return "C.3" if name[0] == "N": return "N.am" if name[0] == "O": return "O.2" if name[0] == "S": return "S.3" if name[0] == "P": return "P.o" if name[0] == "H": return "H" return "Xx"

必须强调，这只是一个“够用”的启发式。你体系里的配体、辅因子、特殊残基，很可能需要手动补规则。比如配体里的芳香碳，按 cvff 可能该写 C.2 而不是 C.3，这种细节脚本猜不出来，需要你根据自己用的力场去扩展映射表。好在 Materials Studio 导入 car 之后还能重新做类型分配，所以脚本的类型映射只要保证“大概对、不产生严重错误”即可，这个伏笔第六章会讲。

4.5 写出 CAR 文件

写 car 的时候按固定模板输出即可，关键是把盒子和坐标的字段写齐：

from datetime import datetime def write_car(path, atoms, cell, forcefield="cvff", charge=0.0): names = make_unique_names(atoms) with open(path, "w") as f: f.write("!BIOSYM archive 3\n") f.write("PBC=ON %12.6f %12.6f %12.6f %9.4f %9.4f %9.4f\n" % tuple(cell)) f.write("!DATE %s\n" % datetime.now().strftime("%a %b %d %H:%M:%S %Y")) f.write("!FORCEFIELD %s\n" % forcefield) f.write("!COORDINATES\n") for idx, at in enumerate(atoms): resnum, resname, atomname, atomnum, x, y, z = at atype = guess_type(resname, atomname) X, Y, Z = x * 10.0, y * 10.0, z * 10.0 f.write("%-8s %12.6f %12.6f %12.6f %-6s %5d %-6s %8.4f\n" % ( names[idx], X, Y, Z, atype, resnum, resname, charge)) f.write("end\n")

再补一个主函数把它们串起来：

import argparse def main(): ap = argparse.ArgumentParser(description="gro2car") ap.add_argument("input") ap.add_argument("output") ap.add_argument("--forcefield", default="cvff") ap.add_argument("--charge", type=float, default=0.0) args = ap.parse_args() atoms, box_vals = parse_gro(args.input) cell = box_params(box_vals) write_car(args.output, atoms, cell, args.forcefield, args.charge) print(f"[ok] {len(atoms)} atoms -> {args.output}") print(f"[ok] cell: a={cell[0]:.3f} b={cell[1]:.3f} c={cell[2]:.3f} " f"alpha={cell[3]:.2f} beta={cell[4]:.2f} gamma={cell[5]:.2f}") if __name__ == "__main__": main()

用法：

python gro2car.py conf.gro conf.car --forcefield cvff

这样转出来的 car 文件，Materials Studio 能直接识别，坐标量级正确，盒子信息完整，原子名唯一，类型字段也有合理的默认值。

5. 实操中踩过的坑

5.1 坐标精度丢失

gro 的坐标只有三位小数，意味着你在 GROMACS 里跑出来的高精度坐标，一旦写成 gro，就已经被舍入到 0.001 纳米。这不是脚本的问题，是 gro 格式本身的精度上限。如果你后续要在 Materials Studio 里做高精度的单点能或者几何优化，建议导入后先跑一步 Forcite 的 Minimization 让结构松弛下来，再往下走。顺便说一句，导出单帧之前最好用gmx trjconv -pbc mol处理一下周期边界，否则你拿到的构象可能分子是断裂的。

5.2 新版 GROMACS 的原子序号字段

这是我踩过最深的一个坑。老版 gro 文件的第一个五字符字段是残基号，但新版 GROMACS 生成的文件里，这个位置已经被原子序号占用了，残基信息被弱化。这意味着同一段解析代码，放在不同版本的 gro 文件上可能得到完全不同的“残基号”。如果你的体系只有一个残基当然无所谓，多残基体系就要当心了。

我现在的习惯是：解析出来的第一个字段只用于展示，不把它当权威残基边界。真正需要残基信息的时候，我会对照原始拓扑文件确认。批量处理时，建议在脚本里加一个参数让你能选择“把这个字段当作残基号”还是“当作原子序号”，而不是写死在代码里。

5.3 水和离子的命名冲突

水的 gro 原子名一般是 OW、HW1、HW2，残基名 SOL。如果你不把它们映射到 Water 对应类型，Materials Studio 会把 OW 当成普通氧、HW 当成普通氢，你的 TIP3P 水模型就名存实亡了。离子就更微妙：钠离子在 gro 里叫 NA，氯离子叫 CL，这些大写缩写和某些元素符号撞车，特别是金属钙离子和蛋白 alpha 碳都叫 CA，不靠残基名做区分，类型必然猜错。这也是我上面映射函数里专门用残基名去判断“金属钙”还是“蛋白 CA”的原因。

5.4 盒子信息丢失导致结构断裂

用 PDB 中转或者手写脚本只读前三个盒子数值的，最容易出现这个问题。分子动力学模拟里的蛋白经常横跨周期性边界，盒子的作用是把原子正确“装”进去。如果 car 里没有 PBC=ON 行，或者盒子参数是错的，Materials Studio 会把体系当成一个真空中的孤岛，部分原子因为坐标表示的原因离得很远，视觉上就是“分子碎了”。所以写脚本时绝对不能跳过盒子解析，三斜盒子的 9 个数值更不能只取前三个。

5.5 常见问题速查表

6. 转完后怎么验证与后续怎么用

6.1 五步自检法

转出来的 car 别急着拿去算，先做五个检查：

第一，原子数一致。gro 第二行写的原子数和 car 里!COORDINATES到end之间的行数必须相同。

第二，坐标量级正确。蛋白体系转完以后，坐标数值应该在几十埃的量级，如果还是个位数，说明 nm 到埃的换算没做。

第三，抽查键长。找个你熟悉的共价键对，比如蛋白里的 N-CA，在 gro 中大约 0.145 纳米，转成 car 后应该约 1.45 埃。可以用几行 Python 快速验证：

def compute_distance(path, fmt, idx1, idx2): # 简易解析示例，gro 或 car 均可 pass # 关键：同一对原子在 gro 里是 0.145，在 car 里应是 1.45

第四，盒子参数。把转出来的格常数和gmx energy或自己在 GROMACS 里打印的盒长对比，差异只应该是小数点后几位的舍入误差。

第五，可视化。用 Materials Studio 打开 car，整体旋转一下，确认分子链完整、没有原子飞到盒子外面，再检查 PBC 格子是否正常显示。

6.2 从单帧转换到整条轨迹

实际项目里你很可能不只转一帧。比如你要把 GROMACS 的轨迹抽样交给 MS 做统计分析，这时候可以用 MDAnalysis 批量导出 gro 帧，再套用脚本批量转 car：

import MDAnalysis as mda u = mda.Universe("topol.tpr", "traj.xtc") for ts in u.trajectory[::10]: u.atoms.write(f"frame_{ts.frame}.gro")

然后在命令行里循环处理：

for f in frame_*.gro; do python gro2car.py "$f" "${f%.gro}.car" --forcefield cvff done

批量转换前先拿一帧测试，确认参数没问题再全量跑，别一股脑生成一堆废文件。

6.3 进入 Materials Studio 后的标准操作

car 文件导入 Materials Studio 后，我的固定流程是：先选中体系，跑一次 Forcite 的 Atom Assignment，让 MS 根据当前几何重新分配原子类型和电荷；然后做一步能量最小化，把 gro 精度舍入带来的细微应力释放掉。做完这两步，再往后做什么计算都稳了。

这里有个小经验：很多人觉得“脚本里类型猜不准就完蛋了”，其实不是。car 的类型字段是给导入用的初始值，MS 内部的类型分配工具会基于原子环境和成键信息重新判断。所以你脚本里的类型映射只要不引起严重错误，后续都有补救空间。真正不能含糊的是盒子和坐标，这两样错了，后面全是白算。

我个人这套 gro2car 流程用了很久，踩过 PDB 中转丢盒子的坑，也踩过三斜盒子当正交盒子的坑，最终还是回到了“自己写脚本、自己验证”这个路子上。最后再分享一个小建议：格式转换脚本一定不要把源文件覆盖掉，每次转换后留一份 gro 存档，验证出问题随时能回去查。做模拟这行，数据可追溯比什么都重要。