NVIDIA ALCHEMI ツールキット、AI コーディングエージェントで材料シミュレーションを支援
本文の状態
日本語全文を表示中
詳細モードで約22分の本文を読めます。
同じ出来事の情報源
この情報源を基点に整理
NVIDIA Developer Blog
NVIDIA は AI コーディングエージェントを活用し、材料シミュレーションの複雑な実装障壁を解消する ALCHEMI Toolkit の新機能を発表し、研究者が自然言語で GPU 加速ワークフローを構築可能にした。
AI深層分析を開く2026年8月19日 03:52
AI深層分析
キーポイント
AI コーディングエージェントによる実装障壁の打破
従来の MLIP エコシステムはソフトウェアスタックの違いからアクセスが困難だったが、AI コーディングエージェントが自然言語記述からコードを生成・実行することでこの課題を解決する。
ALCHEMI Toolkit の専用スキルとリファレンス
NVIDIA は ALCHEMI Toolkit API の使用パターンを提供するエージェント用スキルとリファレンスファイルを公開し、プロンプトを科学的内容に集中させる仕組みを整えた。
信頼性の高いワークフロー構築の知見
45 件の生成されたパイプラインから得た教訓を基盤に、AI エージェントを用いた信頼性の高い GPU 加速シミュレーションワークフローを構築するための実践的ガイドを提供した。
具体的なシステム要件と環境
Python 3.11〜3.14、PyTorch 2.8 以上、CUDA 12/13、および NVIDIA RTX 20xx 以降の GPU を備えた Linux または macOS 環境での利用を推奨している。
実行可能環境の構築がコード生成の信頼性を高める
Python 環境にツールキットをインストールし、エージェントが生成したスクリプトを実行させる構成では、インポートエラーや存在しない API の参照が発生しない。
重要な引用
ALCHEMI Toolkit agent skills and reference files provide the missing API patterns on demand, leaving the prompt to your science: the material, the conditions, and the constraints on the simulation protocol.
This post distills lessons from 45 generated pipelines into practical guidance for building trustworthy GPU-accelerated simulation workflows with coding agents.
In the final 45-pipeline campaign, this setup produced no broken imports or references to nonexistent APIs.
Letting the agent run what it writes removes almost all mechanical errors before you see the script.
編集コメントを表示
編集コメント
AI エージェントを専門的な科学ツールに統合するアプローチは、研究現場のワークフロー変革において極めて有効な一歩である。特に実装の複雑さが障壁となっていた MLIP の普及において、自然言語による制御が可能になる点は大きな進歩と言える。
Source Article
元記事を日本語で読む
本文に関係しない購読案内、埋め込み通知、サイト内プロモーションは除いています。
原子レベルのシミュレーションには、3 つの要素が必要です。それは科学に関する知識、計算効率の高いシミュレーションの実装、そしてシミュレーションスタックへのアクセスしやすいインターフェースです。
最初の「科学知識」は依然として研究者の領域であり、何をシミュレートすべきかや、物理的に意味のある結果を認識する能力を代替できるツールはありません。一方、今年初めに導入された NVIDIA ALCHEMI Toolkit は、Machine Learning Interatomic Potentials (MLIP) における第 2 の障壁を劇的に低減しました。これは、GPU アクセラレーションされたシミュレーションワークフローを構築するためのコンポーザブルで PyTorch ネイティブなビルディングブロックを提供し、実行中のバッチ処理(in-flight batching)も可能にしています。
しかし、第 3 の障壁は依然として残っています。古典的な力場とは異なり、MLIP エコシステムはまだ未成熟です。古典的なシミュレーション向けに存在するアクセスしやすいインターフェースは非常に限られており、計算化学者が慣れ親しんでいるツールとは異なるソフトウェアスタック上で動作します。新しいデータ構造や構成パターン、依存関係が求められるため、参入障壁となっています。
AI コーディングエージェントはこの課題に対する解決策となります。彼らは、研究者が日常的な技術議論で使用する用語で記述された自然言語の説明からコードを生成・実行します。ただし、汎用的なエージェントは ALCHEMI Toolkit の API を知らず、正しく使用しているように見えるが実際には誤ったコードを生成する可能性があります。
ALCHEMI Toolkit 用のエージェントスキルと参照ファイルが、必要な API パターンをオンデマンドで提供します。これにより、プロンプトは科学の核心である「材料」「条件」、そしてシミュレーションプロトコルにおける制約に集中できるようになります。
コーディングエージェントでシミュレーションワークフローを構築する
本記事では、ALCHEMI Toolkit を用いたエンドツーエンドのワークフローを紹介しています。研究者が最初に用意すべきものから、エージェントへのプロンプト方法、生成されるコードとシミュレーションパイプラインの詳細、そして NVIDIA H200 GPU 上での結果検証に至るまでを解説します。さらに、45 件の生成されたパイプラインから得られた教訓を基に、コーディングエージェントを活用して信頼性の高い GPU アクセラレーテッドなシミュレーションワークフローを構築するための実践的なガイドラインもまとめています。
始め方
システムとパッケージの要件
Python は 3.11 以降が必要です。エージェントの環境をどのように設定するかは、生成されるコードの信頼性に直結します。Toolkit を実行可能な Python 環境にインストールし、エージェントが生成したスクリプトを実行させることを推奨します。この構成を採用した最終的な 45 パイプラインキャンペーンでは、インポートエラーや存在しない API への参照といった不具合は一切発生しませんでした。
手順 1: Python 環境を作成し、uv パッケージマネージャー を使用して ALCHEMI Toolkit をインストールします。
uv venv --seed --python 3.12
uv pip install "nvalchemi-toolkit[mace,ase]==0.2.0"
NVIDIA GPU で実行する場合は、お使いの CUDA 環境に一致する CUDA エクストラを追加してください。例えば、CUDA 13 の場合は nvalchemi-toolkit[mace,ase,cu13]==0.2.0 をインストールします。 (原文の技術表記: uv venv --seed --python 3.12 )
ステップ 2: インストールした API と整合性を取るため、同じリリースタグからエージェントのスキルをダウンロードします。
# Download the nvalchemi-toolkit skills
npx degit NVIDIA/nvalchemi-toolkit/.claude/skills#v0.2.0 .claude/skillsステップ 3: コーディングエージェントをインストールします。今回のベンチマークでは Claude Code を使用しました。
npm install -g @anthropic-ai/claude-code
curl -fsSL https://claude.ai/install.sh | bash
claude
プロジェクトディレクトリでエージェントを開き、コード実行を許可してシミュレーションの説明を開始します。すると、必要なスキルがオンデマンドで読み込まれます。エージェントに書いたコードを実行させることで、スクリプトを確認する前に機械的なエラーのほとんどを排除できます。その後の品質は、主にプロンプトの内容によって決まります。
実行可能なシェルがない場合、ソースコードの git チェックアウトが代替手段となります。以前のテストでは、ソースコードを読み込むことで 617 のインポート文にわたる壊れたインポートを解消できました。一方、シェルもソースコードもない状態での pip install は、最も性能が低い構成でした。
Open Agent Skills 標準をサポートするエージェントであれば、Cursor や OpenCode などすべて利用可能です(設定については Agent Skills ユーザーガイド を参照してください)。
良いプロンプト作成のためのベストプラクティス
以下の原則は、一般的なコーディングエージェントのアドバイスではなく、ベンチマーク出力品質における測定可能な差異から導き出されたものです。最も指定が少ないものから最も詳細なものの 5 つのプロンプトレベルを、以下の図 1 に示します。

図 1. 液体リチウムの自己拡散ワークフローに示した 5 レベルのプロンプト階段。各レベルは前のレベルを厳密に拡張するものであり、ゴールは良い出発点となり、結果がシミュレーションプロトコルに依存する場合はレシピが推奨されます。
システム名、手法、スケールは常に明記し、無人運用が必要な場合のみ CLI コントラクトを追加してください。材料・手法・スケールを明示したプロンプトが最も高いスコアを獲得しました。完全な CLI コントラクトを用いると再利用性が完全に保証される一方、トークン数はスケッチ用プロンプトの約 4 倍、生成コード量は 2.3 倍に増大します。仕様(Spec)ベースのプロンプトは最も脆弱で、7 つのスクリーニング失敗のうち 3 つがこれに起因しています。科学的内容と成果物を明確にし、API パターンはスキルの側で提供されるように任せましょう。
物質名、相、および参照規約を明示的に記述する。システムを不十分にする記述は、以前のテストで最も明確な物理的な失敗を引き起こした。「リチウム材料の輸送特性」という曖昧な指示ではアルゴンのデモが出力され、2 つの銅(Cu)スクリプトでは吸着参照が異なり、結果に決定的な影響を与えた。最終的なプロンプトは、物質名、相、参照規約を明確に指定することでこれらの失敗を排除する。また、手順も重要である。サーモスタット指示のないスクリプトはランジュアン生成ダイナミクスを使用し、拡散が 3〜5 倍減衰した。NVE を要求すると、すべてのスクリプトが適切な測定アンサンブルに切り替わった。
実装ではなく制約を指定する。スクリプトが達成すべき内容を記述し、内部の API クラスには言及しない。統制的な比較では、パイプライン構成を明示しても 12 の実装のうち何も変化しなかった。API パターンは例やスキルから得られるものであり、プロンプトから来るものではない。完全なインターフェース契約なしに内部構造を指定することは、脆弱性が集中する場所である。
自己評価と前提の検証を明示的に求めること。エージェントは、要求された性質が物理的に妥当かどうかを疑問視しなかった。前提チェック、検証、不確実性の見積もりを明示的に求め、独立した既知の結果への回復を必須とする。これらの機能は、エージェントが自発的に追加するものではない。
プロンプトから GPU 実行までの 3 つのワークフロー
以下のワークフローは、自然言語のプロンプトから ALCHEMI Toolkit とコーディングエージェントがどのようにエンドツーエンドで処理できるかを示しています。これらの推奨事項を実測結果に基づいて裏付けるため、3 つのワークフロー、5 つのプロンプトレベル、各レベルあたり 3 サンプルの計 45 のシミュレーションパイプラインを対象に体系的なベンチマークを実施しました。
- シリコンの状態方程式(EOS)
- Cu(111) 表面における酸素吸着
- リチウム自己拡散分子動力学(MD)
スクリプトは以下の 2 つの観点から評価されました。第一に、決定論的なコード機能チェックです。これには、必要なプロパティのカバレッジ(数値と式が正しいか)、API パターンカバレッジ(ツールキットのバッチ API の利用状況)、そして再利用性(パラメータ化された再実行可能なインターフェースの有無)が含まれます。第二に、基準となる NVIDIA H200 GPU 上での実行検証です。
45 スクリプトすべてがバッチ GPU 実行を採用しました。L2〜L5 のプロンプトではバッチ処理が必須であり、L1 でもツールキットのスキルと例からこの手法を採用しています。デモンストレーション規模で全スクリプトをスクリーニングした上で、各ワークフローおよびレベルから代表となる 1 つずつを選び、本番環境設定で実行しました。

図2:45のベンチマークパイプラインにおけるH200の実行結果。38本が完了し、生産代表者15名全員が完了した。
体積シリコンの状態方程式
タスク: ダイヤモンド立方晶構造のシリコンの状態方程式
エネルギーと体積の関係曲線から、最小値を格子定数 a0 に、曲率を体積弾性係数 B0 に導出します。すべてのプロンプトレベルにおいて、エージェントは同じパイプラインを構築しました。具体的には、50〜60の歪んだ体積を1つのGPUバッチとして並列に緩和処理し、その後 Birch-Murnaghan によるフィッティングを行いました。すべての生産代表者が最終桁まで一致しており、a0 = 5.4661 Å、B0 = 88.15 GPa という結果を得ています。これは 確立された全電子 PBE 参照範囲 の内部に収まります。
格子定数は NISTの実験値 とは異なりますが、体積弾性係数の比較元は McSkiminによる実験測定 です。これらのズレは、報告されている PBE の挙動 と整合しています。
この結果の教訓は、ベンチマーク全体で見られるパターンと同じです。プロンプトの具体性がコードの構造とコストを変化させることはあっても、物理法則そのものを変えることはありません。

Cu(111) 表面への酸素吸着
タスク: 原子状酸素が Cu(111) 表面上で吸着するサイトの順位付け
パイプラインではスラブの下部層を固定し、4 つの高対称サイト上で 24 以上の候補構造を 1 つの GPU バッチとして緩和計算します。そして吸着エネルギー *E*ads = *E*slab+ads − *E*clean slab − *E*O を算出します。すべての生産代表モデルは、fcc 中空位置が最も安定であることを発見しました。5 つのレベルすべてで *E*ads(fcc) = −4.799 ± 0.004 eV という値を示し、安定性の順序は fcc ≥ bridge > hcp >> top となりました。
報告された参照値 は 0.25 モノレイヤーで −4.31 eV です。Giamello らや Naumann d'Alnoncourt らによる銅マイクロカロリメトリー研究では、−4.46 から −4.60 eV の値が報告されています。被覆率の違いやモデル誤差が、より強い結合エネルギーの原因となっている可能性があります。独立したスクリプト間でミリ電子ボルト単位の一致が見られることは、参照基準を明確に定義しておくことの価値を示しています。

分子動力学によるリチウムの自己拡散
タスク: 液体リチウムの自己拡散係数 D を推定する。
本パイプラインでは、まず体心立方構造 (bcc) のリチウム超セルを構築し、融点である 454 K を超える温度で溶融・平衡化します。その後、3 つの温度と 3 つのシード(乱数初期値)を組み合わせた計 9 つのレプリカを、GPU 上でバッチ処理された単一システムとして展開。原子が移動する平均二乗距離である MSD (mean-squared displacement) の時間変化における傾きをアインシュタインの関係式に適用することで、自己拡散係数 D を算出します。
| プロンプトレベル | 本番環境アンサンブル | 600 K における D (cm²/s) | 800 K における D (cm²/s) | 1000 K における D (cm²/s) |
|---|---|---|---|---|
| L1 (スケッチ) | ランジュバン | – | 1.21 x 10⁻⁴ | – |
| L2 (ゴール) | ランジュバン | 0.80 x 10⁻⁴ | 1.03 x 10⁻⁴ | 1.55 x 10⁻⁴ |
| L3 (レシピ) | NVE | 2.91 x 10⁻⁴ | 5.38 x 10⁻⁴ | 7.22 x 10⁻⁴ |
| L5 (契約) | NVE | 3.62 x 10⁻⁴ | 4.32 x 10⁻⁴ | 6.49 x 10⁻⁴ |
表 1 リチウム液体の自己拡散係数(プロンプトレベル別・温度別)。生成されたスクリプトがエネルギー保存則を満たさなかったため、L4 は除外されています。

図 5 リチウム液体の自己拡散と温度の関係。NVE 計算の結果は実験外挿値の約 2 倍以内です。一方、ランジュバン計算はサモスタットの摩擦効果によって輸送が抑制されるため、NVE の結果よりも 3〜5 分の 1 に低下します。L4 は生成されたスクリプトがエネルギー保存則を満たさなかったため除外されています。
技術仕様
本記事で取り上げたワークフロー例は、以下の構成で実行されました:
- コーディングエージェント:Claude (claude-opus-4-8)
- エフォートレベル:High(高)
- MLIP チェックポイント:MACE-MPA-0 (medium-mpa-0)
- ツールキットバージョン指定:0.2.0
| プロンプトレベル | 処理されたトークン総数(キャッシュ含む) | 生成されたトークン | 反復回数 | スクリプト長(LOC) |
|---|---|---|---|---|
| Sketch | ~2.4M | ~32k | 44 | 498 |
| Goal | ~3.3M | ~39k | 48 | 451 |
| Recipe | ~4.4M | ~43k | 60 | 574 |
| Spec | ~8.9M | ~81k | 88 | 788 |
| Contract | ~10.0M | ~107k | 84 | 1,168 |
表 2:プロンプトレベル別のセル生成コスト、反復回数、コード長。総トークン数の大部分はプロンプトキャッシュの読み取りによるものです。

図 6:プロンプトレベルごとの生成コストとスクリプトサイズ
ベンチマークからの洞察
このベンチマークでは、プロンプトの精度、ツールのアクセス権限、実行能力を体系的に変化させることで、3 つの実践的な知見が得られました。
プロンプトの具体性がコード構造を生む。 どのレベルでもプロパティカバレッジは 1.00 を維持しており、科学的事実自体は最初の段階から正確に反映されています。しかし、具体的な指示を与えることで得られるのは「構造」です。API パターンのカバレッジは L4-Spec で 2 倍になり(0.52 から 0.96)、完全なインタフェースの再利用性が実現されるのは L5-Contract の段階になって初めてです(0.67 から 1.00)(下の図 7 参照)。

Figure 7. Line chart of three coverage metrics versus five prompt levels
Agents defaulted to familiar algorithms: 38 of 45 scripts used FIRE and none used FIRE2, despite FIRE2 being documented beside it as an improved variant. What the examples and skills showcase, the agent uses; what they do not, it fills from pretraining.
Execution exposed failures that CPU self-tests could not. The runnable shell eliminated broken imports, but seven scripts still failed on GPU-specific paths. More elaborate prompts exercised more of these paths and failed more often. Self-testing improves code generation, but does not replace validation on target hardware. A generation sandbox with GPU access may close this gap, but our methodology accounts for what a typical user would do in practice: Use "Claude autorun" in the Claude app on their laptop and then submit to a GPU cluster after.
Limitations
科学的な判断は依然として不可欠です。テストされたすべての条件において、どの構成も物理的に不適切なタスクに対して抵抗を示しませんでした。以前の調査では、すべてのエージェントが、シミュレーション時間スケールで測定不可能な性質である、完全結晶 LiF 中のリチウムイオン拡散に関する要求に従いました。ただし、ウェブ接続を備えたエージェントであればこのチェックを実行した可能性があります。生成サンドボックスにはウェブアクセスがないため、その性質が妥当かどうかを確認することはできませんでした。また、エージェントは物質や時間スケールに適しているかを評価することなく、妥当なタイムステップとサーモスタットを選択しました。エージェントは科学的意図からコードへの翻訳を加速しますが、意図されたシミュレーションが物理的に意味があるかどうかを判断することはできません。
機械学習ポテンシャル(MLIP)の基盤モデルは普遍的に正確ではありません。ベンチマークには MACE-MPA-0 (medium-mpa-0) が使用されましたが、これは学習分布外では精度が変動します。シリコン、銅、液体リチウムの結果は参照値に対して妥当ですが、新しい化学系については必ず DFT または実験との対比検証が必要です。これはモデルの限界であり、場合によっては参照となる DFT の限界でもあります。ALCHEMI Toolkit やエージェント自体の制限ではありません。
数値結果は、必ず独立した参照データと比較してください。
Langevin 生成を用いたリチウムシミュレーションのスクリプトでは、拡散係数が統計的に完璧な値を示しながらも、サーモスタットの影響で実際の値の 3〜5 倍程度に低下するケースがありました。これは温度条件を一致させた実験データという「アンカー(基準点)」と比較することで初めて明らかになります。
また、検証自体も独立したものである必要があります。あるスクリプトは、同じ誤った定数を用いて合成データを生成し、単位変換の妥当性を検証しましたが、その自己テストでは結果が正しく表示されてしまいました。つまり、「統計的に信頼できる」ことと「物理的に意味のある」ことは、必ずしも一致するわけではないのです。
Ecosystem adoption(エコシステムの採用)
複数の企業が、本ブログで取り上げたアプローチの検討を進めています。2026 年 5 月には、150 社以上で使用されている AI 駆動シミュレーションプラットフォーム「Matlantis」が、ALCHEMI エコシステムのパートナーとして GitHub に公開スキルライブラリをリリースし、汎用シミュレータへの Claude Code の統合を発表しました。
BIOVIA もまた、Dassault Systèmes が提供する AI 駆動バーチャルコンパニオン「MARIE」において、NVIDIA ALCHEMI NIM を活用しています。これにより、高度なシミュレーション機能へのアクセスが民主化され、分子シミュレーションの利便ある実行が可能になりました。その結果、より多くの科学者が材料の「バーチャルツイン(Virtual Twins)」の開発と検証に取り組めるようになっています。
ALCHEMI Toolkit とコーディングエージェントを用いたシミュレーションワークフローの構築
NVIDIA/nvalchemi-toolkit GitHub リポジトリ や NVIDIA ALCHEMI Toolkit のドキュメント を訪問して、構築を開始してください。
本リポジトリには、基本・中級・上級・分散ユースケースにわたる 30 以上のワークフローとエージェントのスキルが含まれています。
*謝辞*
*この投稿への貢献に対し、Matlantis Corporation の Nikita Fedik 氏、Susumu Ohno 氏、および Dassault Systèmes – BIOVIA の James Wescott 氏に感謝いたします。*
原文を表示
Atomistic simulation requires three things: knowledge of the science, compute-efficient implementation of simulations, and accessible interfaces to the simulation stack.
The first remains the researcher’s domain, as no tool substitutes for knowing what to simulate or recognizing a physically meaningful result. NVIDIA ALCHEMI Toolkit, introduced earlier this year, has dramatically reduced the second barrier for Machine Learning Interatomic Potentials (MLIP) with composable, PyTorch-native building blocks for constructing GPU-accelerated simulation workflows with in-flight batching enabled.
The third barrier has persisted. Unlike classical force fields, the MLIP ecosystem is still nascent, and the accessible interfaces that exist for classical simulations are very limited. They run on a different software stack than the tools many computational chemists are accustomed to with new data structures, composition patterns, and dependencies.
AI coding agents offer a way through: They generate and execute code from natural-language descriptions written in the terms a researcher would use in daily technical discussions. But a general-purpose agent may not know the ALCHEMI Toolkit API, and can produce plausible-looking code that only appears to use it correctly.
ALCHEMI Toolkit agent skills and reference files provide the missing API patterns on demand, leaving the prompt to your science: the material, the conditions, and the constraints on the simulation protocol.
Building simulation workflows with a coding agent
This post follows an end-to-end ALCHEMI Toolkit workflow: what the researcher starts with, how they prompt the agent, what code and simulation pipeline it produces, and how the results are validated on NVIDIA H200 GPUs. It also distills lessons from 45 generated pipelines into practical guidance for building trustworthy GPU-accelerated simulation workflows with coding agents.
How to get started
System and package requirements
- Python ≥3.11, <3.14
- PyTorch ≥2.8
- CUDA 12 or CUDA 13, with a compatible NVIDIA driver (570+ recommended)
- Operating System: Linux (primary), macOS
- NVIDIA GPU (RTX 20xx or newer), CUDA Compute Capability ≥ 7.0
- Minimum 4 GB RAM (16GB recommended for large systems)
Installation
How you set up the agent’s environment meaningfully affects the reliability of generated code. We recommend installing the Toolkit in a runnable Python environment and letting the agent execute the scripts it generates. In the final 45-pipeline campaign, this setup produced no broken imports or references to nonexistent APIs.
Step 1: Create a Python environment and install ALCHEMI Toolkit with uv package manager:
uv venv --seed --python 3.12
uv pip install "nvalchemi-toolkit[mace,ase]==0.2.0"
To run on an NVIDIA GPU, include the CUDA extra that matches your CUDA environment. For example, for CUDA 13, install nvalchemi-toolkit[mace,ase,cu13]==0.2.0.
Step 2: Download agent skills from the same release tag so they match the installed API:
# Download the nvalchemi-toolkit skills
npx degit NVIDIA/nvalchemi-toolkit/.claude/skills#v0.2.0 .claude/skillsStep 3: Install a coding agent. This benchmark used Claude Code:
npm install -g @anthropic-ai/claude-code
curl -fsSL https://claude.ai/install.sh | bash
claude
Open the agent in your project directory, allow it to execute code, and start describing simulations; the agent loads the relevant skills on demand. Letting the agent run what it writes removes almost all mechanical errors before you see the script. From there, the quality is decided mostly by your prompt.
Without a runnable shell, a source git-checkout is a fallback: In earlier tests, reading the source eliminated broken imports across 617 import statements. A pip install with neither shell nor source was the weakest configuration.
Any agent supporting the open Agent Skills standard works, including Cursor and OpenCode (see the Agent Skills user guide for configuration).
Best practices for writing a good prompt
The following principles are synthesized from measurable differences in the benchmark’s output quality, not from general coding-agent advice. The five prompt levels, from least to most specified, are shown in Figure 1, below.

Name the system, method, and scale always; add a CLI contract only for unattended operation. Prompts naming the material, method, and scale scored best. Full CLI contracts achieved complete reusability, but cost about 4× more tokens and produced 2.3× more code than Sketch prompts. Spec prompts were most fragile, accounting for three of seven screening failures. Specify the science and deliverables; let the skills supply API patterns.
Name the material, phase, and reference convention explicitly. Under-specifying the system caused the clearest physics failures in earlier tests: “a transport property of a Li material” produced an argon demo, and two Cu scripts used different adsorption references, materially affecting the outcomes. The final prompts eliminate those failures by naming the material, phase, and reference convention. Protocol matters too: Scripts without a thermostat instruction used Langevin production dynamics that damped diffusion by 3-5×; requesting NVE changed every script to the appropriate measurement ensemble.
Specify the constraint, not the implementation. Describe what the script must accomplish rather than internal API classes. In a controlled comparison, naming a pipeline construct changed none of 12 implementations. The API pattern comes from the examples and skills, not the prompt. Naming internals without a complete interface contract is where fragility concentrates.
Ask explicitly for self-assessment and premise-checking. Agents did not question whether any requested property was physically well-posed. Ask explicitly for premise checks, validation, and uncertainty estimates, and require recovery of an independent known result; the agent won’t add these on its own.
Three workflows, from prompt to GPU execution
The following workflows illustrate what ALCHEMI Toolkit and a coding agent can handle end-to-end from a natural-language prompt. To ground these recommendations in measured results, we ran a systematic benchmark of 45 simulation pipelines across three workflows, five prompt levels, and three samples per level.
- Silicon equation of state (EOS)
- Oxygen adsorption on Cu(111)
- Li self-diffusion molecular dynamics (MD)
Scripts were assessed two ways. Firstly, deterministic code-feature checks: property coverage (right quantity, right formula), API-pattern coverage (use of the toolkit’s batched API surface), and reusability (a parameterized, re-runnable interface). Secondly, execution on identical NVIDIA H200 GPUs as ground truth.
All 45 scripts used batched GPU execution. L2-L5 prompts required batching; L1 adopted it from the Toolkit skills and examples. We screened all scripts at demonstration scale and ran one representative per workflow and level at production settings.

Bulk silicon equation of state
The task: The equation of state of diamond-cubic silicon
The energy-volume curve whose minimum gives the lattice constant a0 and whose curvature gives the bulk modulus B0. At every prompt level the agent built the same pipeline: 50-60 strained volumes relaxed concurrently as one GPU batch, then a Birch-Murnaghan fit. All five production representatives agree to the last digit, *a0* = 5.4661 Å and *B0* = 88.15 GPa, inside the established all-electron PBE reference window. The lattice constant differs from the NIST experimental value, while the bulk-modulus comparison comes from McSkimin’s experimental measurements. These offsets are consistent with reported PBE behavior. The takeaway mirrors the benchmark-wide pattern: prompt specificity changed the code’s structure and cost, never the physics.**

Oxygen adsorption on Cu(111)
The task:** Rank the adsorption sites for atomic oxygen on Cu(111)
The pipelines freeze the slab’s bottom layers, relax 24+ candidates across the four high-symmetry sites as one GPU batch, and compute *E*ads = *E*slab+ads − *E*clean slab − *E*O. Every production representative finds the fcc hollow most stable, *E*ads(fcc) = −4.799 ± 0.004 eV across the five levels, with the ordering fcc ≥ bridge > hcp >> top. Reported reference values are −4.31 eV at 0.25 monolayer. Copper microcalorimetry studies by Giamello et al. and Naumann d’Alnoncourt et al. reported values from −4.46 to −4.60 eV. Coverage differences and model error may contribute to the stronger binding. Millielectronvolt agreement across independent scripts is what a stated reference convention buys.

Lithium self-diffusion via molecular dynamics
The task: Estimate the self-diffusion coefficient D of liquid lithium.
The pipelines build a bcc lithium supercell, melt and equilibrate it above lithium’s 454 K melting point, propagate three temperatures times three seeds (nine replicas) as a single batched system on the GPU, and extract D from the mean-squared displacement, MSD — the average squared distance that atoms travel — whose slope over time gives D through the Einstein relation.
| Prompt level | Production ensemble | D at 600 K (cm2/s) | D at 800 K (cm2/s) | D at 1000 K (cm2/s) |
|---|---|---|---|---|
| L1 (Sketch) | Langevin | – | 1.21 x 10-4 | – |
| L2 (Goal) | Langevin | 0.80 x 10-4 | 1.03 x 10-4 | 1.55 x 10-4 |
| L3 (Recipe) | NVE | 2.91 x 10-4 | 5.38 x 10-4 | 7.22 x 10-4 |
| L5 (Contract) | NVE | 3.62 x 10-4 | 4.32 x 10-4 | 6.49 x 10-4 |
*Table 1. Liquid-lithium self-diffusion by prompt level and temperature. L4 is excluded because its generated script did not conserve energy*

Technical specifications
The following configuration was used to produce the workflow examples in this post:
- Coding agent: Claude (claude-opus-4-8)
- Effort level: High
- MLIP checkpoint: MACE-MPA-0 (medium-mpa-0)
- Toolkit version pin (0.2.0)
| Prompt level | Total tokens processed (incl. cache) | Generated tokens | Iterations | Script length (LOC) |
|---|---|---|---|---|
| Sketch | ~2.4M | ~32k | 44 | 498 |
| Goal | ~3.3M | ~39k | 48 | 451 |
| Recipe | ~4.4M | ~43k | 60 | 574 |
| Spec | ~8.9M | ~81k | 88 | 788 |
| Contract | ~10.0M | ~107k | 84 | 1,168 |
*Table 2. Per-cell generation cost, iterations, and code length by prompt level. Prompt-cache reads dominate total token counts*

Benchmark insights
The benchmark produced three practical findings by systematically varying prompt level, tool access, and execution capability.
Prompt specificity buys code structure. Property coverage was 1.00 at every level, so the science is right from the first prompt. What specificity brought was structure: API-pattern coverage doubles at L4-Spec (0.52 to 0.96) and full interface reusability arrives only with the L5-Contract (0.67 to 1.00) (Figure 7, below).

Agents defaulted to familiar algorithms: 38 of 45 scripts used FIRE and none used FIRE2, despite FIRE2 being documented beside it as an improved variant. What the examples and skills showcase, the agent uses; what they do not, it fills from pretraining.
Execution exposed failures that CPU self-tests could not. The runnable shell eliminated broken imports, but seven scripts still failed on GPU-specific paths. More elaborate prompts exercised more of these paths and failed more often. Self-testing improves code generation, but does not replace validation on target hardware. A generation sandbox with GPU access may close this gap, but our methodology accounts for what a typical user would do in practice: Use “Claude autorun” in the Claude app on their laptop and then submit to a GPU cluster after.
Limitations
Scientific judgment remains essential. Across every tested condition, zero configurations pushed back on a physically ill-posed task. In an earlier probe, every agent complied with a request for Li-ion diffusion in pristine crystalline LiF, a property not measurable at the simulated timescale. However, it is possible a web-equipped agent would run this check; the generation sandbox had no web access, so the agent could not have looked up whether the property was plausible. Agents also chose plausible timesteps and thermostats without assessing their suitability for the material or timescale. Agents accelerate translation from scientific intent to code, but cannot determine whether the intended simulation is physically meaningful.
MLIP foundation models are not universally accurate. The benchmark used MACE-MPA-0 (medium-mpa-0), whose accuracy varies outside its training distribution. Our silicon, copper, and liquid-lithium results are reasonable against their references, but every new chemistry should be validated against DFT or experiment. This is a model and sometimes reference DFT limitation, not an ALCHEMI Toolkit or agent limitation.
Always compare numerical results with an independent reference. The Langevin-production lithium scripts reported diffusion coefficients that were statistically impeccable yet damped 3-5× by the thermostat; only comparison against the temperature-matched experimental anchor exposes it. The check must also be independent: one script validated its unit conversion by generating synthetic data with the same wrong constant, so its self-test passed. Statistically reliable and physically meaningful can be orthogonal.
Ecosystem adoption
Several companies have been exploring the approaches we discuss in this blog. In May 2026, Matlantis, an AI-powered simulation platform used by over 150 companies and an ALCHEMI ecosystem partner, released a public Skills library on GitHub and announced a Claude Code integration for its universal simulator. BIOVIA is also leveraging NVIDIA ALCHEMI NIM in Dassault Systèmes’s AI-powered virtual companion, MARIE, to democratize access to advanced simulation capabilities and enable convenient execution of molecular simulations, empowering more scientists to develop and validate Virtual Twins of materials.
Get started building simulation workflows with ALCHEMI Toolkit and coding agents
Visit the NVIDIA/nvalchemi-toolkit GitHub repo and NVIDIA ALCHEMI Toolkit documentation.
The repository includes agent skills and more than 30 workflows across basic, intermediate, advanced, and distributed use cases.
*Acknowledgments*
*We would like to thank Nikita Fedik, Susumu Ohno from Matlantis Corporation, and James Wescott from Dassault Systèmes – BIOVIA for their contributions to this post.*
関連記事
今日のまとめ
AIデイリーブリーフで今日の重要ニュースをまとめ読み