コンテナ化されたシミュレーション — CAEソルバーの再現性と自動化を実現する
「同じソルバー・同じ入力なのに、別のマシンで結果が違う」——CAEエンジニアなら一度は経験したことがあるはずです。コンテナ技術は、ソルバー・ライブラリ・設定を丸ごとパッケージ化し、どの環境でも同じ結果を再現する手段です。本記事では、CAEにおけるコンテナ化の実践方法を解説します。
なぜCAEにコンテナが必要か
先生、コンテナ化ってCAEソルバーをDockerで動かすってことですか？ Web開発では使ったことあるんですけど、CAEでも使えるんですか？
基本的な考え方はWeb開発と同じだよ。ただ、CAEには特有の事情がある。例えば、OpenFOAMをソースビルドすると、コンパイラのバージョン、MPIの実装（OpenMPI vs MPICH）、Scotchのバージョン、PETScのビルドオプション……これらの組み合わせで結果が微妙に変わることがある。
現場でよくあるのは、こういうケースだ。
- 半年前に動いたモデルが、OSアップデート後に動かなくなった
- ベンダーのサポートに問い合わせたら「そのバージョンの組み合わせは未検証です」と言われた
- 同僚のPCでは収束するのに自分のマシンでは発散する
コンテナは、ソルバー + ライブラリ + OS環境をまるごとイメージに固めて、この「環境依存性」問題を根本的に解決するんだ。
あー、確かにOpenFOAMのビルドって依存関係が地獄ですよね。MPIのバージョン違いで動かなくなった経験あります…。
DockerとSingularity/Apptainerの違い
HPCだとDockerじゃなくてSingularityを使うって聞いたんですけど、何が違うんですか？
最大の違いはroot権限だ。
- Docker：デーモンがroot権限で動作する。マルチテナントのスパコンでは、他のユーザーのプロセスに干渉できる可能性があるためセキュリティ上NGとされることが多い
- Singularity/Apptainer：rootレスで動作。一般ユーザーがそのまま実行でき、ファイルシステムのパーミッションも維持される。HPCクラスタやスパコンではこちらが標準
他にも重要な違いがある。
| 項目 | Docker | Singularity/Apptainer |
|---|---|---|
| root権限 | 必要（デーモン） | 不要（rootレス） |
| MPI連携 | 追加設定が必要 | ホストMPIとのバインドが容易 |
| イメージ形式 | レイヤー構造 | 単一SIFファイル |
| GPUサポート | nvidia-docker2 | --nvフラグで即利用可 |
| InfiniBand | 特殊設定が必要 | ネイティブサポート |
ちなみにSingularityは2021年にLinux Foundationに移管されて「Apptainer」に改名されたけど、実態は同じものだ。
なるほど、Singularity/Apptainerのほうが断然HPC向きなんですね。DockerイメージからSingularityイメージに変換もできますか？
できるよ。apptainer build solver.sif docker://myrepo/openfoam:v2312 というコマンド一発でDockerイメージからSIFファイルを作れる。だから開発はDockerで行い、実行環境ではSingularity/Apptainerに変換するというワークフローが一般的だね。
コンテナイメージの設計
CAEソルバーのコンテナイメージって、具体的に何を入れるんですか？
典型的なCAEコンテナイメージの構成はこうなる。
- ベースOS：Ubuntu 22.04 / Rocky Linux 9 など
- コンパイラ：GCC 12+ / Intel oneAPI
- MPI：OpenMPI 4.x（ホストMPIとABI互換にするのがポイント）
- ソルバー本体：OpenFOAM v2312、CalculiX 2.21 など
- 依存ライブラリ：PETSc、Scotch/PT-Scotch、METIS、HDF5
- ポストプロセス：ParaView（CLI版）、Python + matplotlib
重要なのはMPIのバージョン管理だ。コンテナ内のMPIとホスト側のMPIのABI（Application Binary Interface）が一致していないと、マルチノード実行でエラーが出る。Singularityには --bind オプションでホスト側のMPIライブラリをコンテナ内にマウントする「ハイブリッドモデル」がある。
CI/CDパイプラインでの回帰テスト
コンテナ化するとCI/CDで回帰テストを自動化できるって聞いたんですけど、CAEでCI/CDって現実的なんですか？
すでにやっている企業は増えているよ。典型的なパイプラインはこうだ。
- コード変更をGitにプッシュ（ソルバーのカスタムコードや入力ファイルの変更）
- GitLab CI / GitHub Actions がトリガー
- コンテナイメージをビルド（Dockerfileからビルド → Singularity SIFに変換）
- 回帰テストケースを実行（小規模なベンチマークモデルで正解値と比較）
- 結果の差分チェック：最大応力・変位・流量等の出力値を基準値と比較。許容差（例：0.1%以内）を超えたらPipelineを失敗にする
- 合格したらレジストリにプッシュ
例えばある自動車部品メーカーでは、LS-DYNAのユーザー材料モデル（UMAT）を変更するたびに、5ケースの回帰テストを自動実行している。以前は手動で2日かかっていた検証が、コンテナ化+CI/CDで30分に短縮された。
30分はすごいですね！ でもCAEの計算って時間かかりますよね。テストケースはかなり軽いモデルにするんですか？
そう、回帰テスト用には要素数を大幅に減らした「ミニチュアモデル」を使うのが一般的だ。フルモデルは1000万要素でも、回帰テスト用は1万要素程度で物理的な挙動が再現できれば十分。大事なのは「コードの変更が結果に影響を与えていないか」を素早く確認することだからね。
クラウドでのジョブスケジューリング
クラウドでコンテナCAEジョブを動かすときは、何を使うんですか？ Kubernetesですか？
選択肢はいくつかある。
- AWS Batch：最も手軽。コンテナイメージを指定してジョブを投入するだけ。Spot Instanceと組み合わせてコスト削減も可能。マルチノードMPIジョブにも対応
- AWS ParallelCluster + Slurm：オンプレのHPCクラスタに近い運用感。Slurmスクリプトをそのまま使える。Singularityイメージをそのまま実行可能
- Kubernetes + MPI Operator：大規模なジョブオーケストレーション。ただしMPIジョブの管理が複雑で、CAE専用のセットアップが必要
- Azure CycleCloud：Azure環境でのHPCクラスタ管理。Slurm/PBS対応
実務的には、少量の大規模ジョブならAWS ParallelCluster、大量の小規模パラメトリックスタディならAWS Batchが使いやすい。KubernetesはCI/CDパイプラインとの連携には良いけど、純粋なHPCジョブには少しオーバースペックだ。
実務導入のポイント
コンテナ化を始めるときに、まず何からやればいいですか？
段階的に進めるのがおすすめだ。
- まずは1つのソルバーをDockerize：OpenFOAMやCalculiXなどオープンソースソルバーから始めるのが楽。Dockerfileを書いてビルド・テストする
- Singularity SIFに変換してHPCで動作確認：マルチノードMPIジョブが正しく動くことを確認
- 回帰テストケースを3〜5個用意：正解値（基準値）を記録しておく
- GitLab CI / GitHub Actionsでパイプライン構築：自動ビルド＋自動テスト
- 商用ソルバーのコンテナ化：ライセンス管理（FlexLM等）の対応が必要。ベンダーの公式コンテナイメージがある場合はそれを使う
最初から完璧を目指さなくていい。まずは「開発マシンと計算マシンで同じ環境を再現できる」状態を作ることが第一歩だ。
商用ソルバーだとライセンス管理が面倒そうですね。AbaqusとかLS-DYNAだとどうなるんですか？
商用ソルバーのコンテナ化では、ライセンスサーバー（FlexLM / LSTC License Manager）への接続をコンテナ外に出す設計が必要だ。環境変数 ABAQUSLM_LICENSE_FILE や LSTC_LICENSE_SERVER でライセンスサーバーのアドレスを指定し、ネットワーク経由でチェックアウトする。コンテナ内にライセンスキーを焼き込むのはセキュリティ上も運用上もNGだ。
最近は Ansys や Siemens が公式のDockerイメージを提供し始めていて、状況は改善されつつある。
CAE技術は日々進化しています。 — Project NovaSolverは最新の研究成果を実務に橋渡しすることを目指しています。
CAEの未来を、実務者と共に考える
Project NovaSolverは、コンテナ化されたシミュレーションにおける実務課題の本質に向き合い、エンジニアリングの現場を支える道具づくりを目指す研究開発プロジェクトです。
プロジェクトの最新情報を見る →関連トピック
なった
詳しく
報告