物理検証

物理検証テストは、シミュレーションの結果が物理(または数学的な)期待値と一致するかどうかを確認します。

既存のテストとは異なり、これらのテストを「秒単位ではなく、分単位」の時間枠で実行することはできません。代わりに、「時間単位ではなく、日単位」で実行することを目的としています。したがって、定期的に実行する必要がありますが、必ずしもすべてのビルドで実行する必要はありません。

また、長期間の実行時間のため、多くの場合、システム(たとえば、特定の時間や別のリソースで実行するなど)の実行を分離する必要がある。これにより、makeスクリプトが以下のようなオプションを提供できるようになる。

  • 実行ファイルと実行スクリプトを準備する。

  • 既存のシミュレーションを分析する、

  • または、まとめて準備、実行、分析を行うことも可能です。

テストの説明

現在、シミュレーション結果は、3つの物理的/数学的に期待される結果と比較されます。

  • 積分器の収束性: スインプラティックな積分器は、微小な熱力学系におけるエネルギー(シミュレーション)のような保存量(運動量など)を、選択された時間ステップの二次関数である変動まで保存することが示せます。異なる時間ステップ(ただし、それ以外のシミュレーションパラメータは変更されていない)を使用して実現される、複数の保存量の軌跡を比較することで、積分器のスインプラティック性を検証できます。ただし、スインプラティック性の欠如は、積分アルゴリズムに必ずしもエラーがあるとは限りません。また、モデルの他の部分、たとえば、不連続なポテンシャル関数や、制約の不正確な処理など、物理的な違反を示唆する可能性もあります。

  • 運動エネルギー分布: (平衡状態にある) システムが、標準的なまたは等温・等圧のエンsemblesからサンプルを抽出する場合、その運動エネルギーの軌跡は、マクスウェル・ボルツマン分布に従うと予想されます。 物理的に期待される分布と観測された分布の類似性は、サンプリングされた運動エネルギーのエンsemblesの妥当性を検証するために使用できます。

  • 構成要素の分布: 潜在エネルギーや体積などの構成要素の分布は、一般的に解析的に知られていないため、特定の軌跡が特定のエンsemblesをサンプリングする確率を評価することは、運動エネルギーの場合よりも複雑です。ただし、一般的には、異なる状態点(例えば、異なる温度、異なる圧力)における同じエンsemblesのサンプル間の確率分布の比率は知られています。したがって、異なる状態点における2つのシミュレーションを比較することで、サンプリングされたエンsemblesの検証が可能になります。

|Gromacs|のテストに含まれる物理検証は、複数のシステムで最も一般的な設定の範囲をテストします。一般的な考え方は、デフォルト値のほとんどをデフォルト値のままにし、明示的にテストする必要がある設定のみを変更することです。これにより、デフォルト値の変化に敏感になります。興味深いテストシステムや特殊なケースが見つかるにつれて、テストセットは拡張されます。ダブル精度では、追加のテストも実行され、他のテストはより低い許容範囲で実行されます。

統合の実現

NVEで実行された、アルゴン(1000個の原子)と水の(900個の分子)システムに関するすべてのシミュレーション。これらのテストは、数値的な不正確さに非常に敏感であるため、レンナー・ジョーンズと静電相互作用の両方に対して、長距離の補正を使用し、非常に低いペアリストの許容度(verlet-buffer-tolerance = 1e-10)と、適用可能な場合は高いLINCS設定を使用します。

アルゴン:

  • 統合者: - integrator = md - integrator = md-vv

  • 長距離修正 (LJ): - vdwtype = PME - vdwtype = cut-off, vdw-modifier = force-switch, rvdw-switch = 0.8

:

  • 統合者: - integrator = md - integrator = md-vv

  • 長距離修正 (LJ): - vdwtype = PME - vdwtype = cut-off, vdw-modifier = force-switch, rvdw-switch = 0.8

  • 長距離の修正:静電場: - coulombtype = PME, fourierspacing = 0.05

  • 制約アルゴリズム: - constraint-algorithm = lincs, lincs-order = 6, lincs-iter = 2 - constraint-algorithm = none - SETTLE

テストの実施

生成されたアンサンブルは、以下の組み合わせで、Argon (1000個の原子) と水 (900個の分子、SETTLEとPMEを使用) を用いてテストされます。

  • integrator = md, tcoupl = v-rescale, tau-t = 0.1, ref-t = 87.0 (アルゴン) または ref-t = 298.15 (水)

  • integrator = md, tcoupl = v-rescale, tau-t = 0.1, ref-t = 87.0 (アルゴン) または ref-t = 298.15 (水), pcoupl = parrinello-rahman, ref-p = 1.0, compressibility = 4.5e-5

  • integrator = md-vvtcoupl = v-rescaletau-t = 0.1``ref-t = 87.0``(アルゴン)または``ref-t = 298.15``(水)

  • integrator = md-vv, tcoupl = nose-hoover, tau-t = 1.0, ref-t = 87.0 (アルゴン) または ref-t = 298.15 (水), pcoupl = mttk, ref-p = 1.0, compressibility = 4.5e-5

すべてのサーモスタットはシステム全体に適用されます(tc-grps = system)。シミュレーションは、2fsの時間ステップでVerletカットオフを使用して、1nsで実行されます。その他の設定はデフォルト値のままです。

ビルドシステムを使用した構築とテスト

これらのテストは、現在のテストと同じ頻度で実行できないため、厳密にオプションで有効化されます。有効化するには -DGMX_PHYSICAL_VALIDATION=ON を使用し、デフォルトでは -DGMX_PHYSICAL_VALIDATION=OFF が設定されます。ただし、これ以前から存在していたすべてのビルドターゲットは変更されません。例えば、 make check も変更されません。

物理検証が有効になっている場合、以下の追加のビルドターゲットを使用できます:

  • make check は変更されていません。このコマンドは、主要なバイナリとユニットテストをビルドし、ユニットテストを実行し、利用可能な場合は回帰テストも実行します。

  • make check-phys は、主要なバイナリをビルドし、その後、物理検証テストを実行します。注意: これには、すべてのシステムをシミュレートする必要があり、平均的なマシンでは数時間かかる場合があります!

  • make check-all は、make checkmake check-phys を組み合わせます。

シミュレーションを実行して物理検証テストを実施するために必要な時間が長くなる可能性があるため、外部リソースで実行することが有益となる場合があります。 これを可能にするために、2つの追加のmakeターゲットが用意されています。

  • make check-phys-prepare は、ビルドディレクトリ内の tests/physicalvalidation フォルダにあるすべてのシミュレーションファイルを、および同じフォルダにある基本的な実行スクリプトを準備します。

  • make check-phys-analyze は、make check-phys と同じテストを実行しますが、システムをシミュレートしません。代わりに、このターゲットは、ビルドディレクトリの tests/physicalvalidation に結果が存在することを前提としています。

これらの追加ターゲットの意図は、シミュレーションファイルを準備し、別のリソースまたは異なる時間で実行し、その後分析することです。 これを使用する場合は、以下の点に注意してください (i)、生成される実行スクリプトは非常にシンプルであり、設定に合わせて調整が必要となる場合があること、および (ii)、分析スクリプトはフォルダ構造に依存するため、結果を別のリソースにコピーする際には、その構造を保持するようにしてください。

上記に挙げられたmakeターゲットに加えて、いくつかの内部makeターゲットが定義されています。これらのターゲットは、直接使用することを意図していませんが、上記の機能、特に複雑な依存関係をサポートするために必要です。これらの内部ターゲットには、異なるテストを実行する run-ctestrun-ctest-nophysrun-ctest-phys、および run-ctest-phys-analyze、物理検証のためのシミュレーションを実行する run-physval-sims、およびテストの欠落をユーザーに通知する missing-tests-noticemissing-tests-notice-allmissing-phys-val-physmissing-phys-val-phys-analyze、および missing-phys-val-all が含まれます。

直接的なPythonスクリプトの使用

上記で言及されている make コマンドは、python スクリプト tests/physicalvalidation/gmx_physicalvalidation.py を呼び出しており、これは make システムに依存せずに独立して使用できます。 一般的な使用方法については、オプションの -h を、利用可能な物理検証に関する詳細についてはオプションの --tests を使用してください。

このスクリプトは、テストを定義する「json」ファイルを入力として必要とします。 他のオプションの中には、|Gromacs|のバイナリと使用する作業ディレクトリを定義し、シミュレーションの準備のみ、シミュレーションの準備と実行、シミュレーションの分析のみ、またはこれらのすべてのステップを一度に実行するかどうかを選択することができます。

新しいテストを追加する

利用可能なテストは、同じディレクトリにある systems.json (単精度ビルドで標準的に使用されるテスト) および systems_d.json (倍精度ビルドで標準的に使用されるテスト) ファイルにリストされています。GROMACS ファイルは systems/ フォルダにあります。

json``ファイルには、さまざまなテストがリストされています。各テストには、一意である必要のある"name"属性、テスト対象のシステム(``systems/``ディレクトリ内の)のディレクトリを示す"dir"属性、およびシステムに対して実行する検証をリストする"test"属性が含まれています。さらに、オプションの"grompp_args"および"mdrun_args"``属性を使用すると、それぞれ``gmx grompp``または``gmx mdrun``に特定の引数を渡すことができます。1つのテストには複数の検証を含めることができ、同じ入力ファイルに対して複数の独立したテストを実行できます。

既存のシステムに新しいテストを追加するには、テスト名と引数を json ファイルに記述します。新しいシステムを使用するには、systems/ ディレクトリに、input/system.{gro,mdp,top} ファイルを含むサブフォルダを作成し、システムを定義します。