企业官网建设流程全解析

写这篇东西之前，先交代一下背景。我自己的主力机是 Windows，平时带学生做课题，跑分子动力学模拟算是最日常的操作。Gromacs 这软件在 Linux 服务器上是爸爸级的待遇，一个 module load 就完事，但落到个人电脑上，安装这一步就能劝退一批人。尤其是刚接触模拟的新手，往往卡在 WSL2 的配置上，或者苦于手头没有 Linux 机器，只能对着 Colab 网页发呆。这篇博文就把我实际验证过的两条安装路线写清楚：一条是 Windows 上用 WSL2 装原生 Linux 环境再编译安装 Gromacs，另一条是纯网页端的 Google Colab 方案，不花钱也能跑小体系模拟。两条路线都亲测跑通过，里面涉及的坑、参数的取舍、版本的雷区，我都会尽量交代明白，适合刚入坑分子动力学、或者想在个人电脑上跑通小体系模拟的朋友直接照抄。毕竟，能顺利把软件跑起来，比背十遍理论公式更能提升学习效率。

1. 先弄清两条路线，再决定怎么装

安装 Gromacs 这件事，网上教程一抓一大把，但很多都默认你已经有了一台 Linux 服务器，或者愿意折腾双系统、虚拟机。实际操作下来，Windows 用户最舒服的两条路就是 WSL2 和 Colab，各有各的适用场景。

1.1 WSL2 和 Colab 到底解决什么问题

WSL2 是 Windows 自带的 Linux 子系统方案，本质是用轻量级虚拟机跑一个完整的 Linux 内核。和传统双系统、VirtualBox 虚拟机相比，它最大的优点是和 Windows 文件系统互通、启动快、占用资源少，而且能直接调用 Windows 侧的 GPU 驱动做 CUDA 加速。你在 Windows 桌面上写脚本，在 WSL2 里就能直接跑，文件访问的路径也不绕。对于日常要长期用 Gromacs、需要频繁调试模拟参数的人来说，WSL2 基本可以当作一台低配 Linux 工作站来用。

Colab 则是 Google 提供的在线 Jupyter 环境，本质是个远端 Linux 虚拟机，免费额度下能拿到 CPU 和偶尔的 GPU（常见是 T4）。它的核心价值在于零安装成本：只要有个浏览器，注册个账号，就能拿到一个带有 NVIDIA 驱动、CUDA 环境、Python 解释器的 Linux 系统。对于只是临时跑个小体系、验证一下流程、或者电脑配置确实太老跑不动的朋友，Colab 可以帮你跳过所有环境配置的麻烦，直接进入模拟环节。

两者的本质区别在于：WSL2 解决的是“本机长线作战”需求，环境是自己的，装好了可以长期用，性能损耗小；Colab 解决的是“临时起意”需求，随开随用，断线就重新来，适合学习、演示、快速验证。

1.2 为什么我不推荐虚拟机或双系统

很多人一想到 Linux 环境就会说“我装个 VirtualBox 不行吗”“直接拿一块硬盘折腾双系统不就完了”。当然行，但我自己试过一圈，维护成本真的不在一个量级。VirtualBox 这类传统虚拟机的图形开销大，文件共享配置繁琐，运行 Gromacs 这种 CPU/GPU 密集型任务时性能损失明显，特别是 GPU 穿透，VirtualBox 对 CUDA 的支持历来都很别扭。双系统就更不用提了，每次切换都要重启，我在做课题的时候经常需要在 Windows 里查文献、在 Linux 里跑模拟，双系统切来切去能把人逼疯。

WSL2 在架构上虽然是虚拟机，但微软做了大量优化，文件系统互通开了 9P 协议，跨系统访问文件几乎没有配置成本，性能损失也比传统虚拟机小很多。更重要的是，在 WSL2 里跑 GPU 计算，Windows 侧的显卡驱动会被直接透传，CTO 连续跑几天也不容易掉，这一点传统虚拟机很难比。

1.3 两条路线各自适合什么样的人

先给一个简单的判断标准。如果你满足下面任意一条，优先考虑 WSL2：电脑硬盘空间足够（至少留 20GB 以上给 Linux 子系统装环境）、打算把 Gromacs 作为长期工具慢慢研究、模拟的体系规模不大但频次高、希望本地网络环境下做大批量参数扫描。如果你满足下面这些情况，直接去开 Colab 就行：手边是公司或学校给的统一配发电脑、不方便开启 BIOS 虚拟化、只是跑教程里的水盒子练手、临时要复现别人论文里的模拟流程。

另外补充一点，即使你以后会用到高性能计算集群（HPC），我也建议先用 WSL2 把 Gromacs 的输入文件准备、拓扑构建、参数调试这些技能学会。集群上的登录节点通常不允许跑重型计算，但用来构建体系、生成拓扑文件、递交作业，操作习惯跟在 WSL2 里非常接近。等你熟练了，再上手集群就自然得多，这也是我推荐多数入门者先在本机搭一个 WSL2 环境的原因。

2. WSL2 安装 Gromacs：从零到能跑通的完整流程

这一部分我写得尽量细，因为 WSL2 安装 Gromacs 的过程中，最容易出问题的其实不是 Gromacs 本身，而是前面几层基础环境的配置。很多人卡在 CUDA 装不上、CMake 版本太旧、mpi 库冲突这些地方，最后灰头土脸卸载了事。其实按步骤来，每一步看清楚再走，成功率极高。

2.1 第一步：把 WSL2 本身装好并换成可用版本

装 WSL2 我用的是最简单的方式：以管理员身份打开 PowerShell，输入wsl --install，系统会自动启用相关 Windows 功能、下载 Linux 内核并安装默认的 Ubuntu 发行版。装完后重启电脑，Ubuntu 终端会自动弹出来让你设置用户名和密码。这个过程中有两点要留神。

第一，安装完成重启后，务必先执行一次wsl --version（注意，较新版本支持这个命令）或在 PowerShell 里执行wsl -l -v，确认你的 Linux 子系统版本显示的是 2，而不是 1。如果显示的是 2，说明 WSL2 内核正常；如果显示 1，大概率是 Windows 版本太旧，需要先更新系统。旧版本 Windows 的 WSL 历史包袱多，直接更新到最新版最省心。

第二，默认安装的 Ubuntu 可能是 WSL 自动选择的版本，不一定是你想要的。我习惯装 Ubuntu 22.04，因为这个版本的用户量大、软件源里依赖齐全、Gromacs 官方编译文档也主要是基于这个版本测试的。如果你想指定版本，在 PowerShell 里先执行wsl --list --online查看可用发行版列表，然后输入wsl --install -d Ubuntu-22.04指定安装即可。

2.2 第二步：更换软件源和系统依赖

Ubuntu 装好后的第一件事，我建议先更换 apt 软件源。默认的官方源在国内网络环境下下载速度经常不够理想，换用国内镜像源后，后面安装编译器、依赖库的速度会快很多。这一步不是必须的，但做实验讲究效率，省下的时间足够多跑几组测试。具体做法：编辑/etc/apt/sources.list，把archive.ubuntu.com和security.ubuntu.com替换成你所在地区访问快的镜像地址即可。我这里不做具体推荐，你自己搜索一下“Ubuntu 22.04 镜像源”就有现成的配置模板。

换完源之后，执行更新和升级：

sudo apt update sudo apt upgrade -y

接下来安装编译 Gromacs 需要的基础依赖：

sudo apt install -y build-essential cmake cmake-curses-gui libfftw3-dev libblas-dev liblapack-dev libmpich-dev libopenmpi-dev openssh-client git wget

这里我故意把libopenmpi-dev和libmpich-dev都装上了。为什么？因为 Gromacs 的-DGMX_MPI=ON构建选项需要至少一个 MPI 实现。多数教程会推荐 OpenMPI，但有些集群上的作业调度系统和 OpenMPI 存在兼容性小毛病，备用一个 MPICH 能救急。不过要注意，两个 MPI 实现同时存在偶尔会引发一些环境变量冲突，如果后面出现奇怪的 MPI 报错，可以先排查一下是不是系统默认选错了mpirun。

依赖版本身上的一个坑：CMake 版本必须别太老。Gromacs 2023 版本系列对 CMake 的最低要求大概在 3.16 左右，Ubuntu 22.04 软件源里自带的 CMake 版本通常够用，但如果你用 Ubuntu 20.04 或者更老的版本，就要考虑用pip install cmake或者手动编译新版本 CMake。我试过一次在 CMake 3.10 的环境里强行构建 Gromacs，那感觉就像拿扫帚开飞机，各种奇奇怪怪的报错轮番上阵，不值得折腾。

2.3 第三步：下载 Gromacs 源码并理解目录结构

依赖装好后，下一步是获取 Gromacs 源码。我习惯从官网直接下载稳定版 tarball 包，而不是用 git clone 拉最新开发版。原因很简单：最新开发版可能包含尚未充分测试的新特性，对新手来说反而增加不确定性；稳定版虽然功能上保守一些，但遇到问题更容易在网上搜到解决方案。

比如下载 2023.4 这个版本（以你实际选择的版本为准），命令大概是：

wget https://ftp.gromacs.org/gromacs/gromacs-2023.4.tar.gz tar -xzf gromacs-2023.4.tar.gz cd gromacs-2023.4

在开始编译之前，我想先解释一下 Gromacs 的构建系统逻辑，这对你后面自己调整参数很有帮助。整个构建过程分为两个阶段：先是在一个独立的 build 目录里运行 CMake 配置，生成编译规则；然后调用 make（或者 ninja）执行编译。把 build 目录和源码目录分开，是个好习惯，这样你要是配置参数填错了，直接把 build 目录删掉重来就行，完全不会污染源码，也不用重新解压。

mkdir build cd build

2.4 第四步：CMake 配置参数的选择与解释

这一步是整个安装过程的核心，也是最容易让人困惑的地方。常见的几个关键参数我逐一解释一下：

-DGMX_BUILD_OWN_FFTW=ON是最省心的选择。FFTW 是 Gromacs 做快速傅里叶变换的核心库，用来处理 PME 长程静电相互作用。虽然前面我们用 apt 装了libfftw3-dev，但系统版的 FFTW 默认可能没开单精度支持和 SIMD 优化，性能会打折扣。让 Gromacs 自己编译内置的 FFTW，它会在编译时自动检测 CPU 的 SIMD 指令集，生成最匹配的版本。

-DGMX_GPU=CUDA表示启用 CUDA 加速。如果你现在还不打算用 GPU 跑，就先不要开这个选项，避免引入 CUDA 工具链的安装复杂性。如果确定要用，我的建议是：Windows 侧先装好最新的 NVIDIA 显卡驱动（这一步很关键，WSL2 里的 GPU 驱动完全依赖于 Windows 侧的驱动），然后到官网下载 WSL 专用的 CUDA Toolkit 安装包。这里有个容易误解的地方：WSL2 里不需要自己装显卡驱动，但编译时需要 CUDA Toolkit 里的nvcc编译器。顺便提一句，CUDA 版本别盲目追新，先查一下你下载的 Gromacs 版本官方测试过哪些 CUDA 版本，再用对应的版本，否则编译器版本不匹配的报错会让你怀疑人生。

-DGMX_BUILD_MPI=ON表示启用多节点并行支持。如果你只是在一台电脑上跑，OpenMP 线程并行已经足够了，可以不开 MPI；但要模拟大体系或者未来打算上集群，开了 MPI 能提前熟悉作业提交流程。我一般在个人电脑上都会顺手开了，代价只是多装几个库，后面需要并行时不至于重装。

实际的配置命令我建议这样写：

cmake .. -DCMAKE_INSTALL_PREFIX=/usr/local/gromacs \ -DGMX_BUILD_OWN_FFTW=ON \ -DGMX_GPU=OFF \ -DGMX_BUILD_MPI=ON \ -DCMAKE_BUILD_TYPE=Release

这里把安装前缀设为/usr/local/gromacs，好处是方便卸载。以后不想要了，直接删掉这个目录，再删掉/usr/local/bin/gmx软链接，干净利落。如果选了默认的/usr/local，文件会散落到各处，卸载时就不那么清爽。

配置完成后，接下来就是编译和安装：

make -j$(nproc) sudo make install

编译时间取决于你的 CPU 核心数。我用一个 8 核的机器编，大概 10 到 15 分钟；如果是 4 核老本子，可能得半小时以上。所以编译前先确认-j参数，别把 CPU 跑满到无法操作。编译完成后，在~/.bashrc里加上 Gromacs 的环境变量：

# 根据自己的安装路径调整 source /usr/local/gromacs/bin/GMXRC

然后执行source ~/.bashrc，输入gmx --version，如果能看到版本号和使用说明，说明 Gromacs 已经安装成功。

2.5 验证安装：跑一次最小水盒子模拟

装了不能用等于白装。验证 Gromacs 安装成功最标准的方法，是跑一个最小水分子模拟。这里我用的是官方教程里常用的 SPC/E 水模型，整个流程只需要十几个命令，几分钟就能看完在跑。

# 进入工作目录 mkdir -p ~/test_md && cd ~/test_md # 下载必要文件（如果没有现成的，可以先用 gmx 自带的示例） # 简单起见，我直接用一个最简单的拓扑和坐标文件： # 此处以官方 Tutorial 的 spc216.gro 为例 # 实际使用中请从 Gromacs 官网 Tutorial 下载对应文件

如果手头没有现成的输入文件，最快的验证方式是到 Gromacs 官网找一份“Lysozyme in Water”教程，下载里面的输入文件，按教程执行gmx grompp生成 tpr 文件，然后执行：

gmx mdrun -deffnm step1

看到Finished mdrun的提示和一系列输出文件生成，就说明软件本身已经能在你的机器上正常工作。我第一次装完 Gromacs 跑完这个测试，看到命令行里跳出一堆能量数据，心里的石头才终于落地。模拟结束后，可以用gmx energy快速提取一项性质，比如温度或总能量，对比一下有没有异常跳变，这也是验证软件算得对不对的简单手段。

2.6 WSL2 下 GPU 加速的实际踩坑记录

WSL2 下跑 Gromacs 的 GPU 加速，我前后折腾了不少时间，中间有几个坑值得单独拿出来讲。

第一个坑出现在显卡驱动的安装上。WSL2 的 GPU 透传依赖 Windows 侧驱动，但并不是所有版本的驱动都支持 WSL。如果你装的是 Windows 商店里那种精简版驱动，或者很老的实验室驱动，WSL2 里输入nvidia-smi很可能会直接报错。解决办法是去 NVIDIA 官网手动下载最新的 Windows 驱动，安装完重启 WSL2 再验证。注意在 WSL2 里执行nvidia-smi能正常显示显卡信息，是 GPU 加速可用的前提。

第二个坑是 Gromacs 编译时选择的 CUDA 版本和驱动不匹配。我有一台机器的驱动支持最新 CUDA 12.x，但 Gromacs 2021 版本只测试到 CUDA 11 系列，强行用新 CUDA 编译出来的二进制执行时会出现各种“无效设备”之类的诡异报错。后来我发现，Gromacs 官网的发布说明里其实有一个支持矩阵表，把每个版本测试过的 CUDA 版本写得清清楚楚，照着那个选就稳妥了。所以别小看官网文档，遇到问题先去看这份支持矩阵，能少走很多弯路。

第三个坑是 OpenMP 线程数和 GPU 同时使用时的资源竞争。在 WSL2 里跑小体系模拟，我建议先用-ntmpi 1 -ntomp 4这类参数把核数控制住。特别是体系规模不大时，线程开太多反而会因为调度开销让速度变慢。这一步没什么标准答案，建议结合自己的 CPU/GPU 组合多做几组对比。

3. Colab 安装 Gromacs：不用买显卡也能跑分子动力学

如果说 WSL2 方案是为长期使用做准备，那 Colab 方案就是纯粹为了快速验证和学习。我在给学生上课时，经常用 Colab 做演示，因为不需要任何前期配置。浏览器打开，登录，新建笔记本，贴代码，跑通，就这么简单。

3.1 Colab 环境特点与免费资源量级

Colab 的免费版环境基本配置是这样的：双核 CPU、约 13GB 内存、大约 100GB 磁盘空间，GPU 是偶尔能分配到的 Tesla T4（显存 16GB）。免费额度下 GPU 不是总有，需要看运气，但 CPU 版也足够跑小型模拟了。我对免费版的使用体验是：跑个几百个原子的体系，几百皮秒的时长，完全没问题；跑更大体系就会明显感觉到力不从心。

另外要清楚 Colab 的几个特性，免得后面白干：每次关闭浏览器标签或长时间不操作，运行时会被回收，所有安装的软件、上传的文件都会消失；单次会话最长运行时间大概 12 小时（更精确的时长会根据负载浮动）；文件系统不是持久的，要保存结果必须挂载 Google Drive 或者主动下载。这些限制在做长时间模拟的时候尤其要小心，所以我一般不建议在免费 Colab 上跑超过几十分钟的模拟任务，除非你把结果文件不断同步到网盘。

3.2 Colab 一键安装脚本：从系统依赖到编译

在 Colab 里编译 Gromacs 并不难，其实和 WSL2 里的步骤大同小异，只是 Colab 环境更干净，一些东西已经预装好了，比如 Python numpy 等。我的常用脚本是放在一个代码块里，每次新建笔记本先执行：

# 更新系统软件源并安装编译工具 !apt install -y cmake build-essential libfftw3-dev libopenmpi-dev libmpich-dev 2>&1 | tail -20 # 下载 Gromacs 源码（以官方稳定版为准） !wget https://ftp.gromacs.org/gromacs/gromacs-2023.4.tar.gz !tar -xzf gromacs-2023.4.tar.gz # 编译安装 !mkdir -p /content/gromacs-build %cd /content/gromacs-build !cmake /content/gromacs-2023.4 -DCMAKE_INSTALL_PREFIX=/usr/local/gromacs -DGMX_BUILD_OWN_FFTW=ON -DGMX_GPU=OFF -DGMX_BUILD_MPI=ON -DCMAKE_BUILD_TYPE=Release !make -j2 !make install

在 Colab 里我用-j2而不是-j$(nproc)，因为 Colab 免费环境就给你两个逻辑核心，你把它全占满是正常的，但别有太高的心理预期。整个编译过程大概 10 分钟，期间你可以先去把模拟输入文件准备好，这样编译完就能立刻开始跑。

编译完成以后，在当前会话里每次使用前都要执行一下环境变量：

import os os.environ['PATH'] = '/usr/local/gromacs/bin:' + os.environ['PATH'] os.environ['LD_LIBRARY_PATH'] = '/usr/local/gromacs/lib64:/usr/local/gromacs/lib:' + os.environ.get('LD_LIBRARY_PATH', '')

然后执行gmx --version确认能调用到。注意 Colab 每次运行完代码块如果你切换了运行时类型，环境变量可能会丢，所以别嫌麻烦，直接把这些设置放在同一个代码块里最稳妥。

3.3 用 Colab 跑模拟时的文件管理技巧

在 Colab 里跑 Gromacs，一个核心问题就是文件管理。本地机器上你可以随意创建目录、移动文件。Colab 是远端服务器，你在网上看到的上传、挂载操作要好好理解一下。

先说输入文件。小文件（比如单体的 PDB 结构）最简单的方法是直接上传：左侧文件面板里点上传图标就行。但一旦文件多了，上传速度不太理想，而且运行时会话被回收后文件会消失。我的习惯是把所有输入文件打包成一个input.zip，上传到 Google Drive，然后挂载网盘，在笔记本里解压。挂载 Drive 的命令是：

from google.colab import drive drive.mount('/content/drive')

执行后会生成一个授权链接，点击登录授权即可。挂载成功后，你 Google Drive 里的文件路径就是/content/drive/MyDrive/。我通常会把模拟相关的输入文件放在 Drive 里一个专门的文件夹里，比如MyDrive/gmx_projects/lysozyme/，然后每次会话开始就拷贝到本地工作目录跑：

!cp -r /content/drive/MyDrive/gmx_projects/lysozyme /content/lysozyme %cd /content/lysozyme

模拟跑完以后，输出文件要同步回 Drive 再下载，或者直接用代码打包下载：

!tar -czf /content/output.tar.gz /content/lysozyme from google.colab import files files.download('/content/output.tar.gz')

这个步骤一定不要省。我有一次模拟跑了大半天，因为忘了保存就把标签页关了，结果所有轨迹文件全没了，那种心态爆炸的感觉，你绝对不想体会第二次。

3.4 Colab 上启用 GPU 与 CUDA 版本的注意事项

Colab 免费版在“代码执行程序 → 更改运行时类型”里可以选择 GPU 或 CPU。选 GPU 后，免费额度偶尔能分配到 Tesla T4，但高峰期经常提示“无可用 GPU 配额”。相比本地 WSL2，Colab 的 GPU 环境是现成的，不需要自己装驱动和 CUDA 工具链，里面已经预装了最新的 CUDA 和 cuDNN。

在 Colab 上编译 Gromacs 选择 GPU 加速，需要把 CMake 参数里的-DGMX_GPU=CUDA打开（或者省略也行，Gromacs 会自动检测）。但我实际测试发现，Colab 编译 GPU 版的时间比 CPU 版要长不少，而且免费版每次会话回收后都要重来，所以如果你只是验证流程，我建议先用 CPU 版跑通；确认自己确实需要 GPU 加速了，再去改编译参数。这里有个朴素的工程判断：不要为了一分钟就能跑完的小体系，花二十分钟去编译一个可能很快就失效的 GPU 版本。

另外提醒一句，如果你在 Colab 里用 GPU 跑，参数设置上把-nb gpu加上，其余像-pme gpu、-bonded gpu这些高级选项可以等熟悉之后再试。新手阶段，先保证 GPU 能用，再追求效率。

4. 两条路线怎么选：性能、成本与场景对比

走到这里，你可能会想：我到底该用哪个？我打算从几个维度给一个经验性对比，但结论是：先决定你的需求，再决定工具。

4.1 相同体系下的速度对比

我在同样的体系（一个约 5 万原子的溶菌酶盒子，跑 10ns）下做过粗略测试：WSL2 用本机 8 核 CPU 跑，速度大约是每天几十纳秒（ns/day）；Colab 免费 CPU 环境（双核）大概只有 WSL2 的一半不到；Colab 分到 T4 GPU 后，速度能提升到每天几百纳秒甚至更多，具体提升幅度要看体系大小。也就是说，如果是 CPU 为主的小体系，WSL2 的本地 CPU 其实比 Colab 免费 CPU 更占优势，因为本地机器的核心数普遍比 Colab 免费版多；但一旦涉及 GPU，Colab 的 T4 又比很多入门级的家用显卡要强。

这个数据没有绝对参考价值，毕竟每个人的 CPU 型号、GPU 型号、模拟体系性质都不同。但给大家一个直观概念：如果你的需求是跑通流程而不是追求长时间采样，WSL2 CPU 版完全够用；如果你需要长轨迹，就要认真考虑 GPU 了。本地没有好显卡的前提下，Colab 的免费 GPU 是很值得利用的资源。

4.2 成本与可持续性对比

成本方面，WSL2 方案唯一的支出是电费和电脑折旧，但你的电脑在跑模拟时没法干别的重活，一台机器相当于被占用了。Colab 免费版零成本，但断线重来、会话回收这些不确定性让人很没有安全感。如果你确实打算长期做分子模拟，预算也允许，我觉得可以认真考虑如下组合：本地 WSL2 负责常规的体系搭建、拓扑生成、预处理和小规模测试；官方 Colab 或其他云 GPU 负责需要长轨迹或大体系的正式生产任务。很多研究组其实就是这么干的。

4.3 我的建议：新手先 WSL2 后 Colab，各司其职

针对刚入门的朋友，我的建议很简单：先在 WSL2 上把整套流程完整跑通，这个过程中你学到的 Linux 命令、文件管理、CMake 参数、MPI 概念，都是通用的技能；遇到问题能学到怎么排查思路。等 WSL2 已经熟练到不再需要查教程了，再上手 Colab，你会觉得 Colab 就像是个有四只手的外挂，只管跑就完了。反过来，如果你直接上手 Colab，虽然装得快，但环境细节你会一概不知，遇到报错很难定位根因，后续想写脚本批处理模拟，会觉得处处碰壁。

5. 常见问题排查：这些坑我基本都踩过

安装 Gromacs 的过程中，我见过的报错几乎可以编一本小册子了。下面挑一些出现频率最高、也最有代表性的问题，按场景分类列出来，方便你直接对号入座。

5.1 WSL2 环境相关的典型问题

问题：wsl命令提示“WSL2 无法启动，因为此计算机上未启用虚拟化”。

这大概率是 BIOS 里的虚拟化技术（Intel VT-x 或 AMD-V）没打开。重启电脑，进入 BIOS 设置，找到类似Intel Virtualization Technology或SVM Mode的选项，启用后保存退出。另外 Windows 的“虚拟机平台”功能可能也没开启，可以在“启用或关闭 Windows 功能”里勾选“虚拟机平台”和“适用于 Linux 的 Windows 子系统”，重启后再试。

问题：WSL2 里 apt update 速度很慢，或者出现“Failed to fetch”错误。

原因一般是默认的软件源在国外。把/etc/apt/sources.list换成国内镜像源后，速度一般能提升一个量级。注意 WSL 里你可能需要先编辑这个文件，如果是新装的 Ubuntu，里面内容很少或者被注释了，可以用sudo nano /etc/apt/sources.list直接编辑。

问题：在 WSL2 里访问/mnt/c/下的文件或数据时速度特别慢。

WSL2 访问 Windows 文件系统的性能天生比访问 Linux 原生文件系统慢很多，因为中间有跨文件系统的转换开销。解决办法是：把你的模拟工作目录放在 WSL2 自己的文件系统里（比如~/md_sims），只把最终结果拷回 Windows 盘。这个小事解决后，你会觉得 WSL2 一下子就“流畅”了。

问题：执行某个 Gromacs 相关命令时报错“could not safely verify the WSL2 environment”或类似提示。

这类环境校验失败通常和 WSL 版本太老、系统时间不同步、或者 WSL2 内核需要更新有关。先执行wsl --update把内核更新到最新版，再检查 Windows 时间和 WSL2 内时间是否一致。时间偏差过大有时也会引发证书校验类错误。实在不行，卸载旧 WSL 组件后重装最新版本即可。

5.2 编译阶段的常见报错与解决办法

问题：CMake 执行时报错，提示找不到 FFTW、BLAS、LAPACK 等依赖。

多半是系统依赖没装全。重新检查libfftw3-dev、libblas-dev、liblapack-dev有没有用 apt 装好。如果确实装了还是找不到，可能是 CMake 缓存问题，删掉 build 目录从新配置。这也是我之前强调单独建 build 目录的原因——删起来真的方便。

问题：执行make时编译中断，显示内存不足。

Gromacs 编译时某些源文件特别消耗内存，尤其是在并行编译时。解决方法是降低并行度，把-j$(nproc)改成-j2或者不指定。如果你是在 Colab 上编译，-j2几乎是我认为的标配，别嫌慢。

问题：configure 时选了-DGMX_GPU=CUDA，但编译报错说找不到 nvcc。

这大概率是因为 CUDA Toolkit 没有正确安装，或者nvcc不在 PATH 里。在 WSL2 里，你需要主动把 CUDA 的 bin 目录加入 PATH，比如：

export PATH=/usr/local/cuda/bin:$PATH export LD_LIBRARY_PATH=/usr/local/cuda/lib64:$LD_LIBRARY_PATH

然后把 CUDA 相关的环境变量也写进~/.bashrc，避免每次开终端都要手动设。我遇到过一种情况，nvcc能找到但版本特新，Gromacs 官方还没匹配，就会报出一堆莫名其妙的“undefined reference”。这时候查官网的支持矩阵，换一个官方测试过的 CUDA 版本就能解掉。

5.3 运行阶段的问题汇总

问题：gmx mdrun报错，提示找不到libgromacs.so。

这是典型的动态库路径没设置好。确认你在运行 Gromacs 之前在同一个终端会话里执行过source /usr/local/gromacs/bin/GMXRC，或者至少把/usr/local/gromacs/lib64加进了LD_LIBRARY_PATH。如果你用的是 Colab，每次新会话都要重新设置，这是老生常谈。

问题：并行运行时 CPU 占用看不到明显提升，或者速度反而更慢。

可能是模拟体系太小，线程之间通信的开销超过了并行计算的收益。我建议小体系模拟（原子数少于 1 万）就老老实实用单核或者四核以下，别开一堆核；大体系并行时，先测试-ntomp从 2 到最大值的一个比例关系，找到这个体系下的拐点。

问题：模拟中途 Colab 直接被断开，之前跑的都白费了。

这是 Colab 方案最难根治的问题。应对策略是：把整个模拟拆成多个短任务，每个任务结束后自动把轨迹文件拷贝回 Google Drive，同时用一个简单的日志记录任务进度。下次重新开始后，从最近的 checkpoint 恢复，而不是从头再来。这个技巧说起来简单，但能极大降低 Colab 断线的挫败感。

5.4 问题速查表

写在最后的一点个人体会

安装 Gromacs 这件事，说难其实也不难，按部就班走就是了。但回头看，我觉得真正宝贵的不是最后那个能跑的 gmx 命令，而是整个过程中建立起来的那套对系统的理解：Linux 的目录结构、CMake 的配置逻辑、CUDA 与驱动的对应关系、并行编程里线程和 MPI 的权衡。这些知识像一层底层的地基，以后无论你是继续用 Gromacs 做模拟，还是转向其他计算化学软件，甚至学深度学习框架的部署，都会发现它们是相通的。

我自己现在的工作习惯是：Windows 为主机日常办公，WSL2 里长期驻扎一套 Gromacs 环境，日常批量小任务直接在 WSL2 里跑；遇到大体系要长轨迹，就在云平台上临时起一个实例或者用 Colab 的 GPU。两条路线各有不可替代的位置，互补使用，效率最高。最后再分享一个小技巧：不管在哪条路线编译 Gromacs，都建议用一份现成的CMakeCache.txt配置备份着，下次想复现或换机器安装的时候，直接拿着它改，能省掉很多填参数的功夫。祝大家的模拟任务都能一把跑通。