仓库源文站点原文


layout: post title: AMBER资料整理 categories:


从个人角度而言, 我不是很喜欢AMBER. 大可以给他发张好人卡, 便道: 你是极好极好的, 我却偏不喜欢. 一个人若是不喜欢, 原因总可以说出很多, 却大抵不是自欺便是欺人, 无甚可谓的了. 但猜测起来, 我不喜欢AMBER的最主要原因, 还是我最开始真正接触的MD程序是GROMACS, 而非AMBER. 我既已花心思熟悉了GROMACS的那一套实现与流程, 也就慢慢习惯, 入了他的道. 以此心态, 再去看AMBER的那些实现与流程, 总觉得不顺眼, 不习惯, 也就进而喜欢不起来了. 人之俗情, 也大抵如是. "太上忘情, 最下不及情, 情之所钟, 正在我辈". 诚哉斯言.

相比GROMACS而言, AMBER资格更老一些, 也因此在实现上有很多不好的地方, 也算历史包袱吧. 比方说, 各种语言混编, FORTRAN, C, C++. 现在似乎更抱紧了PYTHON的大腿, 好多新的工具都用PYTHON来实现, 以致还要自带一个PYTHON的大包. 这样做的结果就是安装时不仅下载慢, 编译也困难重重, 稍有一点地方不对路, 就只能折腾了. 系统不兼容, 版本不兼容, 库不兼容, 各式花样不兼容总能让你找不到北. 折腾半天, 你也不知道为什么不好, 侥幸装好了, 你更不知道为什么好了. 从这个角度讲, GROMACS就单纯得多, 安装包很小, 源码基本就是C++, 安装环境的配置也就简单多了.

其实, 这恰恰说明了GROMACS和AMBER的最大不同. GROMACS是一个MD模拟的引擎, 专注于各种方法的实现, 计算的速度; 而AMBER是一个MD模拟的完整解决方案, 从建模到分析, 一切都可以在其中完成. 因此, GROMACS是小而精, 遵循Linux的理念; AMBER是大而全, 有点Windows的风格. GROMACS是赛车发动机, 强劲有力, 但你要想驾驶它回家, 却要先将它和其他组件装配起来, 费点周折. 一旦装配好, 那自然到家极快了. AMBER是普通汽车, 好在组件齐全, 你马上就能开, 虽然速度慢点, 晃晃悠悠也能到家. 至于到底是谁先到家, 那就要看是谁在装配, 又是谁在开了.

人总是不知足的. 所以就有人开始动歪脑筋: 来, 让我们将GROMACS发动机装进AMBER汽车吧. 这样开起来简单, 跑起来又快, 两全其美, 岂不乐哉. 虽说GROMACS和AMBER未必乐见其成, 但总禁不住有人这样做. ACPYPE就是其中之一, 它可以将AMBER建模所得的输入文件转换为GROMACS的输入文件, 然后就可以用GROMACS开跑了. 而建模, 正是GROMACS欠缺的地方, 非借助于其他程序或软件不可. 在建模方面, AMBER是一个很好的工具, 所以即便不用AMBER跑MD, 只用它来建模也是极好的.

每种工具都有其优缺点, 你接触得越多, 了解得越多, 越能保持开放的心态, 正确地评估各个工具, 而不是陷入信徒式的迷狂争论.

基于以上考虑, 我 不要脸地 决定借助大家的力量, 整理翻译AMBER的相关资料, 包括但不限于教程和手册. 作为开始, 我觉得还是先将主要精力放在教程的翻译整理上. 在此基础之上再翻译整理手册. 原因就是, AMBER的手册实在是厚厚一大本, 接近1000页. 我都有点没信心能把它翻译整理完. 不过, 好在热心人很多呢, 况且我们也不赶时间. 那就学习愚公的移山做法, 一点一点蚕食, 说不定哪天感动上苍, 就帮我们完成心愿了呢. 哼哼, 想想总是可以的吧, 万一实现了呢.

ALL for ONE, ONE for ALL.