分子動力学リポジトリ: 実践ガイド
分子動力学リポジトリとは、シミュレーションコード、入力データセット、力場パラメータ、解析スクリプトをバージョン管理下でホストするものであり、GROMACS、LAMMPS、OpenMM といったエンジンや、DCD や XTC といったトラジェクトリ形式にまで及びます。ストレージの選択は大規模になると重要になります。100,000 原子の系を 100 ナノ秒シミュレーションし、10 ピコ秒ごとに座標を書き出すと、およそ 10,000 フレームになります。したがって、適切な構造を選ぶかどうかが、数年後にもシミュレーションが再現可能であり続けるかを決めます。
主なポイント
- 分子動力学リポジトリは単一のものではありません。エンジンコード、力場定義、トポロジーおよび座標ファイル、実行スクリプト、解析ノートブックのスタックであり、それぞれに異なるバージョン管理のニーズがあります。
- バイナリトラジェクトリ形式（XTC、DCD、TRR、NetCDF/AMBER）は精度とサイズをトレードオフします。その選択はストレージコストと長期的な可読性の両方に影響します。
- 再現性はエンジンよりも、4 つのものを固定できるかどうかにかかっています。エンジンのバージョン、力場のバージョン、乱数シード、そして正確な入力ファイルです。
- Git はテキスト入力とスクリプトに適したツールですが、大きなバイナリトラジェクトリは Git LFS、DVC、あるいは Zenodo のようなデータリポジトリに置くべきであり、メインの Git 履歴に置くべきではありません。
- FAIR データ原則（Findable、Accessible、Interoperable、Reusable）は、初日に行うリポジトリレイアウトの決定にきれいに対応します。
- 他人が再実行できないリポジトリは、再現性ではなくドキュメントです。
「分子動力学リポジトリ」が実際に指すもの
分子動力学リポジトリは多義的な言葉であり、その曖昧さは研究室のグループが標準化しようとするときに実際の混乱を引き起こします。少なくとも 4 つの異なるものがこの名前で呼ばれ、それらは技術的にほとんど共通点がありません。
1 つ目は エンジンリポジトリ です。これはシミュレーションプログラム自体のソースコードです。GROMACS、LAMMPS、NAMD、OpenMM、AMBER はそれぞれ独自の上流リポジトリに存在し、あなたはメンテナではなくユーザーとしてそれらと関わります。ここで気にするのはリリースタグとバージョン番号であり、コードではありません。
2 つ目は 力場とパラメータのリポジトリ です。CHARMM36、AMBER ff14SB、OPLS-AA、粗視化の Martini ファミリーといった力場はパラメータファイルとして配布され、しばしば独自のバージョン管理を持ちます。OpenKIM プロジェクトは、材料および分子系のための原子間ポテンシャルの相互運用可能なアーカイブを維持しており、これは Git リポジトリとはまったく異なる提供モデルです。
3 つ目は プロジェクトリポジトリ です。特定の研究のためのあなた自身の作業ディレクトリです。これにはトポロジーファイル、座標ファイル、.mdp や入力デッキ、実行スクリプト、解析コードが含まれます。ほとんどの再現性の失敗はここから生じます。
4 つ目は データリポジトリ です。トラジェクトリ、チェックポイント、派生データのための長期アーカイブです。Zenodo、Figshare、機関リポジトリがこの役割を果たし、特定のデータセットを引用できるように DOI を割り当てます。
関連: — ガイド付きターミナルと実際のデータセットを使用したプロジェクトベースのデータ サイエンス パス.
これら 4 つを混同すると、予測可能な間違いにつながります。40 GB のトラジェクトリを Git にコミットしたり、Zenodo の預託をアクティブな作業ディレクトリのように扱ったりすることです。これらを分離することが、シミュレーションプロジェクトを立ち上げる上で最も効果の高い単一の決定です。
ロングデータ問題：なぜトラジェクトリが通常のバージョン管理を壊すのか
分子動力学シミュレーションが生み出すロングデータは、リポジトリ設計を決定づける制約であり、ツールを選ぶ前にその理由を理解することが重要です。100,000 原子の単一の系を 100 ナノ秒シミュレーションし、10 ピコ秒ごとに座標を書き出すと、およそ 10,000 フレームになります。非圧縮の倍精度座標として保存すると、約 100,000 原子 × 3 座標 × 8 バイト × 10,000 フレームとなり、圧縮前で数百ギガバイトになります。
トラジェクトリ形式はまさにこれを管理するために存在します。XTC は設定可能な精度で非可逆圧縮を使用し、通常はナノメートル単位で小数点以下 3 桁であり、GROMACS のデフォルトです。DCD は古典的な CHARMM 形式で、非圧縮であり広く読み取り可能です。TRR は GROMACS の可逆な完全精度形式で、正確な速度や力が必要なときに有用です。AMBER のトラジェクトリ規約を含む NetCDF ベースの形式は自己記述的で、単位のメタデータを含みます。
一見の価値があります: — 大学が支援する Python およびデータサイエンス証明書の 1 つのサブスクリプション.
リポジトリへの実際の影響は具体的です。
- Git はすべてのファイルのすべてのバージョンを保存します。 実行のたびに変化するトラジェクトリはリポジトリを永久に肥大化させます。Git の履歴は追記専用だからです。ファイルを削除しても、履歴を書き換えない限り容量は回収されません。
- Git LFS（Large File Storage） は大きなファイルをポインタに置き換え、内容を別の場所に保存します。これはめったに変化しない数ギガバイトまでのファイルにはうまく機能します。絶えず再生成されるトラジェクトリには不向きです。
- DVC（Data Version Control） はデータをハッシュで追跡し、設定可能なリモート（ローカルディスク、S3、機関のストア）に保存しつつ、小さな
.dvcポインタファイルを Git に保持します。これはデータが大きくコードが小さいシミュレーションワークフローに適しています。 - DOI 付きのデータリポジトリ は、凍結された公開版のトラジェクトリの正しい置き場所です。それらは作業ディレクトリではありません。
実行可能な役割分担はこうです。スクリプト、入力デッキ、解析コードには Git。中程度のバイナリアーティファクトには DVC または Git LFS。最終的に公開されるデータセットには DOI を発行するアーカイブ。これによりクローン時間が常識的な範囲に収まり、公開記録が引用可能になります。
再現可能なシミュレーションリポジトリの解剖
再現可能な分子動力学リポジトリには予測可能なレイアウトがあり、そのレイアウト自体が、開いた人に意図を伝えます。以下の構造は分子動力学プロジェクトの妥当なデフォルトであり、LAMMPS、GROMACS、OpenMM のワークフローに適応できます。
project/
├── README.md
├── environment.yml # or requirements.txt / conda spec
├── systems/
│ ├── system-a/
│ │ ├── topology/
│ │ ├── coordinates/
│ │ └── parameters/
│ └── system-b/
├── simulations/
│ ├── equilibration/
│ │ ├── inputs/
│ │ └── run.sh
│ └── production/
│ ├── inputs/
│ └── run.sh
├── analysis/
│ ├── notebooks/
│ └── scripts/
├── data/ # DVC-tracked or gitignored
└── docs/各ディレクトリにはそれぞれの居場所があります。systems/ ツリーは、何をシミュレーションしているかという化学的定義を、どのようにシミュレーションしているかから分離します。これは、同じ系がしばしば複数のプロトコルの下で実行されるため重要です。simulations/ ツリーは平衡化と本番を分離します。これは失われやすく、再構築にコストがかかる区別です。
environment.yml ファイルは最も過小評価されている構成要素です。エンジンのバージョン、Python 解析スタック、すべてのサポートライブラリを単一のファイルに固定することで、共同研究者が 1 つのコマンドで環境を再構築できます。Conda 環境ファイル、pip 要件ファイル、コンテナ定義（Docker または Apptainer/Singularity）はすべてこの目的を果たします。コンテナはシステムライブラリも取り込むため、最も堅牢です。
README.md は少なくとも次を示すべきです。研究が何であるか、どのエンジンとバージョンか、どの力場とバージョンか、生の入力から最終的な図までパイプラインをどう実行するか、そして大きなデータがどこにあるか。読者が著者であることを前提とした README はドキュメントではありません。
リポジトリホストの選択：重要な基準
計算科学のためのリポジトリホスティングは、商用の Git ホスティングがカバーしない線に沿って分かれます。以下の表は、分子動力学リポジトリを選ぶ際にほとんどの研究室グループが実際に検討する選択肢を比較したものです。
| ホスト / ツール | 最適な用途 | 大きなバイナリの扱い | DOI / 引用 | 備考 |
|---|---|---|---|---|
| GitHub / GitLab | コード、スクリプト、小さな入力 | Git LFS 経由（クォータ制限あり） | ネイティブ DOI なし | どこにでもある。LFS クォータに驚かされることがある |
| Zenodo | 凍結された公開データセット | はい、寛大な制限 | はい、バージョンごとの DOI | GitHub リリースと統合 |
| Figshare | データセット、図、補足資料 | はい | はい | ジャーナルのワークフローで一般的 |
| 機関リポジトリ | 長期的な機関アーカイブ | さまざま | 通常ははい | 永続性は機関に依存 |
| DVC + クラウドリモート | アクティブな大容量データのバージョン管理 | はい | いいえ | Git 履歴を小さく保つ |
| Open Science Framework | プロジェクトレベルの整理 | はい | はい | コードとデータが混在するプロジェクトに良い |
決定は一般に 3 つの問いに帰着します。データは DOI で引用可能であるべきか？ 変化するにつれてバージョン管理されるべきか、それとも一度凍結されるべきか？ 10 年後に利用可能に保つ責任は誰にあるか？
一般的で擁護可能なパターンは、Zenodo 統合を有効にした GitHub をコードに使い、タグ付きリリースごとに自動的に DOI を発行させ、さらに作業データには DVC を使うことです。これにより Git 履歴を肥大化させることなく、引用可能なリリースが得られます。
力場、パラメータ、そしてバージョン管理の罠
力場のバージョン管理は、再現性が静かに失敗する場所であり、失敗モードが見えないため別途扱う価値があります。3 年離れて実行された「CHARMM36」と題された 2 つのシミュレーションは、力場が改訂されているため異なるパラメータセットを使用している可能性があります。同じことが AMBER のタンパク質力場にも当てはまり、ff99SB、ff99SB-ILDN、ff14SB およびそれ以降の改訂は測定可能に異なる挙動を生み出します。
厄介なのは、力場ファイルがしばしばエンジンのインストール全体に分散していたり、プロジェクトのウェブサイトからダウンロードされたりして、そのバージョンがシミュレーション出力のどこにも記録されないことです。エンジンのバージョンは固定しているが力場のバージョンは固定していない分子動力学リポジトリは、半分しか再現可能ではありません。
実用的な緩和策：
- パラメータファイルをリポジトリに同梱する。 使用した正確な
.itp、.prm、.frcmodファイルをsystems/*/parameters/にコピーしてコミットします。これらは小さなテキストファイルであり、リポジトリに存在することで曖昧さがなくなります。 - 力場の名前と改訂を README と機械可読なメタデータファイルに保存する。 入力のそばに短い YAML または JSON ファイルを置くのはほとんどコストがかからず、その問いに決定的に答えます。
- すべてのローカルな変更を記録する。 部分電荷や結合パラメータを調整した場合、その変更は個人的なスクラッチディレクトリではなくリポジトリにあるべきです。
- 材料シミュレーションの原子間ポテンシャルには、バージョン管理されたアーカイブを優先する。 OpenKIM はまさにポテンシャルを引用可能かつバージョン管理可能にするために存在し、その使用はある種の曖昧さを取り除きます。
一般的な原則：数値結果に影響を与え、エンジンバイナリではないものはすべて、コミットされたファイルとしてリポジトリに属します。
リポジトリを超えた再現性：シード、ハードウェア、浮動小数点
分子動力学リポジトリは完璧に整理されていても、結果を再現できないことがあります。分子動力学にはバージョン管理の外側に存在する非決定性の源があるからです。それらを理解することで、誤った自信を避けられます。
乱数シード は初期速度の割り当てを制御し、確率論的手法ではサーモスタットとバロスタットの挙動を制御します。シードが保存されなければ、同一の入力であっても実行は再現可能ではありません。多くのエンジンは明示的なシードを受け付けます。それを使って保存しましょう。
並列分割 は浮動小数点の総和の順序に影響します。同じ系を 16 コアで実行するのと 64 コアで実行するのでは、蓄積された丸め誤差の違いにより、時間とともに発散するトラジェクトリを生み出す可能性があります。これはバグではなく、異なる縮約順序の下での浮動小数点演算の本質です。厳密な再現性のためには、領域分割とコア数を記録するか、ビット単位の同一性は実現不可能であると受け入れて、代わりに統計的な再現性を目指しましょう。
ハードウェアとコンパイラの違い は、異なる数学ライブラリと命令セットを通じてさらなる変動をもたらします。コンテナはこれを減らしますが、排除はしません。
サーモスタットとバロスタットの選択 はアンサンブルを変え、したがって物理を変えます。リポジトリはアンサンブルを明示的に記録すべきです。NVT、NPT、NVE を、カップリング定数とともに。
正直な枠組みはこうです。ビット単位の再現性は固定されたハードウェアとソフトウェア構成で達成可能であり、統計的な再現性が構成をまたいだ現実的な目標です。構成を文書化したリポジトリは、前者を達成可能にし、後者を検証可能にします。
シミュレーションデータに適用される FAIR 原則
FAIR 原則 – Findable、Accessible、Interoperable、Reusable – は研究データ一般のために策定され、具体的な分子動力学リポジトリの実践に翻訳できます。
Findable とは、データセットが永続的な識別子と記述的なメタデータを持つことを意味します。Zenodo や機関リポジトリからの DOI がこれを満たします。研究室のサーバー上のディレクトリではそうではありません。
Accessible とは、データが標準的なプロトコルを用いて人間または機械によって取得でき、明確なライセンスを持つことを意味します。預託時にオープンライセンスを選ぶことで、データがアーカイブされているのに法的に使用できないというよくある状況を避けられます。
相互運用可能 (Interoperable) とは、形式が標準化され、文書化されていることを意味します。カスタムバイナリ形式ではなく XTC、DCD、または NetCDF を使用し、単位を文書化することで、数年後でも標準的なツールで軌跡（trajectories）を読み取ることが可能になります。
再利用可能 (Reusable) とは、新しい目的でデータを再利用するための十分なコンテキストがあることを意味します。これには、エンジンのバージョン、力場のバージョン、アンサンブル、温度、および適用された処理など、前述のメタデータが必要です。
FAIRフレーミングが有用なのは、「ファイルを保存したか」ではなく「他の誰かがこれらのファイルを使用できるか」に注意を向けさせるためです。これらは異なる問いであり、長期的なデータにとって重要なのは後者のみです。
実践的なセットアップ: 最小限の動作例
他のエンジンにも適応可能な、GROMACSスタイルの分子動力学リポジトリワークフローの再現可能な最小構成は、実際には次のようになります。
リポジトリを初期化し、大容量ファイルの処理を構成します：
git init md-project
cd md-project
git lfs install
git lfs track "*.xtc" "*.trr" "*.tpr"
git add .gitattributes環境仕様を作成し、入力ファイルとともにコミットします：
conda env export --no-builds > environment.yml
git add environment.yml systems/ simulations/ analysis/
git commit -m "Initial reproducible setup"DOIを作成できるようにバージョンにラベルを付け、凍結されたデータセットを作業リポジトリとは別にアーカイブします。タグはコードの正確な状態をマークし、アーカイブはデータの正確な状態を保持します。
上記のワークフローは意図的に最小限に抑えられています。重要なのはツールの高度さではなく、結果を決定する要素をコミットし、バージョン管理するには大きすぎる要素をアーカイブするという規律です。
出典と詳細情報
- Molecular dynamics — Wikipedia: 分子動力学 (MD) は、原子や分子の物理的な動きを分析するためのコンピューターシミュレーション手法です。原子と分子は相互作用し…
よくある質問
分子動力学リポジトリとは何ですか？
分子動力学リポジトリとは、シミュレーションを定義し再現するためのファイル（エンジンの入力、トポロジーおよび座標ファイル、力場パラメータ、実行スクリプト、解析コード）をバージョン管理して保存する場所のことです。また、この用語は GROMACS や LAMMPS などのエンジンの上流ソースリポジトリや、軌跡を保持するデータアーカイブを指すこともあります。これら3つの用途を区別することで、リポジトリ設計におけるほとんどのミスを防ぐことができます。
MD軌跡をGitに保存すべきですか？
通常、軌跡を単純なGit履歴に含めるべきではありません。Gitはすべてのバージョンを永続的に保存するため、大きなバイナリファイルはリポジトリを不可逆的に肥大化させるからです。Git LFSは、変更頻度が低く中程度のサイズのファイルに有効であり、DVCは頻繁に再生成される大容量データに適しています。公開され凍結された軌跡のバージョンは、ZenodoのようなDOIを発行するデータリポジトリに保存すべきです。
分子動力学シミュレーションを再現可能にするにはどうすればよいですか？
再現性には、エンジンのバージョン、力場のバージョン、乱数シード、正確な入力ファイル、およびハードウェアまたはコンテナ構成の固定が必要です。リポジトリ内で力場パラメータファイルを検証することで、サイレントな発散（silent divergence）の最も一般的な原因を取り除くことができます。固定構成であればビット単位の再現性は現実的ですが、コア数やハードウェアが異なる場合は、統計的な再現性を目指し、その差異を文書化してください。
どの軌跡形式を使用すべきですか？
XTCは、精度を構成でき、圧縮効率が良いため、GROMACSワークフローのデフォルトとして適しています。DCDは広く読み取り可能で非圧縮であるため、相互運用性に適しています。TRRは完全な精度を保持し、速度や力が大きい場合に有用です。NetCDFベースの形式は自己記述型であり、単位のメタデータが含まれているため、長期的な再利用が容易になります。
シミュレーションデータにDOIは必要ですか？
データセットを論文とは独立して引用可能にしたい場合は、DOIが必要です。これはジャーナルや資金提供者からますます求められるようになっています。ZenodoとFigshareはどちらもDOIを発行し、GitHubリリースと統合しているため、リリースにタグを付けることで引用可能な識別子を自動的に生成できます。内部的な未公開ワークの場合、DOIは任意ですが、同様のアーカイブ規律を維持することは依然として有益です。
力場のバージョンはどのように記録すべきですか？
力場パラメータファイルは小さなテキストファイルであり、その正確な内容が結果を決定するため、リポジトリ内のパラメータディレクトリに保存し、検証する必要があります。力場名とリビジョンも、READMEおよび機械可読なメタデータファイルに記録しなければなりません。料金（fees）や関連設定へのローカルな変更は、ホームディレクトリに保持するのではなく、検証して保存してください。
よくある質問
分子動力学リポジトリとは何ですか?
分子動力学リポジトリは、シミュレーションを定義および再現するファイル (エンジン入力、トポロジーおよび座標ファイル、力場パラメーター、実行スクリプト、解析コード) のバージョン管理されたストアです。この用語は、GROMACS や LAMMPS などのエンジンの上流ソース リポジトリや、軌跡を保持するデータ アーカイブも指します。これら 3 つの用途を区別することで、リポジトリ設計のほとんどの間違いを防ぐことができます。
MD 軌跡を Git に保存する必要がありますか?
Git はすべてのバージョンを永続的に保存し、大きなバイナリはリポジトリを不可逆的に肥大化させるため、通常、軌跡を単純な Git 履歴に含めるべきではありません。 Git LFS は、めったに変更されない中程度のサイズのファイルに対して機能し、DVC は頻繁に再生成される大きなデータに対してより適切に機能します。公開され、凍結された軌道のバージョンは、Zenodo などの DOI 発行データ リポジトリに属します。
分子動力学シミュレーションを再現するにはどうすればよいですか?
再現性を確保するには、エンジンのバージョン、力場のバージョン、ランダム シード、正確な入力ファイル、ハードウェアまたはコンテナの構成を固定する必要があります。リポジトリ内の力場パラメータ ファイルを検証すると、サイレント発散の最も一般的な原因が除去されます。ビットごとの再現性は固定構成で現実的です。コアやハードウェアの数が異なる場合は、統計的な再現性を目指し、その違いを文書化します。
どのような軌跡形式を使用すればよいですか?
XTC は、設定可能な精度で適切に圧縮できるため、GROMACS ワークフローのデフォルトとして適しています。 DCD は広く読み取り可能で非圧縮であるため、相互運用性に適しています。 TRR は完全な精度を維持し、速度や力が大きい場合に役立ちます。 NetCDF ベースの形式は自己記述型であり、ユニットのメタデータが含まれているため、長期的な再利用が容易になります。
シミュレーション データには DOI が必要ですか?
DOI は、データセットを論文とは独立して引用可能にしたい場合に必要です。これはジャーナルや資金提供者からの期待が高まっています。 Zenodo と Figshare は両方とも DOI を作成し、GitHub リリースと統合するため、リリースにタグを付けると引用可能な識別子を自動的に生成できます。社内の未公開作品の場合、DOI はオプションですが、同じアーカイブ規律を維持することが効果的です。
力場のバージョンはどのように記録されるべきですか?
フォース フィールド パラメータ ファイルは、小さなテキスト ファイルであり、その正確な内容によって結果が決まるため、パラメータ ディレクトリの下のリポジトリで販売し、検証する必要があります。フォース フィールドの名前とリビジョンも、README と機械可読メタデータ ファイルに記録する必要があります。料金や関連設定に対するローカルの変更は、ホーム ディレクトリに保存するのではなく、検証する必要があります。
ブラウザでコーディングして Python を学習する
ブラウザーで直接コーディングするインタラクティブな Python およびデータ サイエンス コース