バッチ実行 (Batch Execution) — CAE用語解説
バッチ実行とは
定義と基本概念
バッチ実行(Batch Execution)とは、CAEソルバーをGUI(グラフィカルユーザーインターフェース)を介さず、コマンドラインやスクリプトから起動して計算を行う方式のことである。ユーザーが画面の前に張り付いている必要がなく、ジョブを投入したら結果が出るまで放置できるのが最大の利点だ。
典型的なバッチ実行のコマンド例:
# Abaqusの場合
abaqus job=model_01 cpus=8 interactive
# OpenFOAMの場合
mpirun -np 16 simpleFoam -parallel > log.simpleFoam 2>&1
# ANSYS Mechanicalの場合
ansys212 -b -np 4 -i input.dat -o output.txt
バッチ実行って、GUIで普通に解析を走らせるのと何が違うんですか? 会社ではみんなAbaqus/CAEの画面から「Submit」ボタンを押してるんですけど……
GUIからSubmitすると、裏ではまさにバッチ実行が走ってるんだよ。ただ、GUIだとそのPCに張り付いてないといけないし、1ケースずつ手動で操作する必要がある。バッチ実行を直接使えば、夜中に50ケースまとめて流して、朝来たら結果が揃ってる——みたいなことができるわけだ。
なるほど、それは便利ですね。でもコマンドラインって難しそう……。Linuxの知識がないとダメですか?
最低限のLinuxコマンド——cdでディレクトリ移動、lsでファイル一覧、catでファイル中身を見る——くらいは必要だね。でもそれだけ覚えれば十分始められる。実務ではHPCクラスタがLinuxなことがほとんどだから、遅かれ早かれ覚えることになるよ。
HPCキューシステム
企業や研究機関では、複数ユーザーが共有するHPC(High Performance Computing)クラスタ上でCAE解析を行う。このとき、計算資源の公平な配分を担うのがジョブスケジューラ(キューシステム)である。
代表的なジョブスケジューラ:
- SLURM(Simple Linux Utility for Resource Management)— 現在最も普及。
sbatchでジョブ投入、squeueで状態確認 - PBS / Torque(Portable Batch System)— 古くからの定番。
qsubで投入、qstatで確認 - LSF(Load Sharing Facility)— IBM製、大企業での採用例が多い。
bsubで投入 - SGE(Sun Grid Engine)— 現在はOpen Grid Schedulerとして存続
HPCクラスタで解析を走らせるとき、SLURMとかPBSっていうのをよく聞くんですが、あれは何ですか? 自分のPCで走らせるのとどう違うんですか?
ジョブスケジューラと呼ばれるソフトウェアだよ。例えば100人のエンジニアが同じクラスタを使うとき、全員が好き勝手にジョブを走らせたら資源が足りなくなるよね。スケジューラが「この人のジョブはノード3〜6で、あの人のジョブはノード10〜12で」と自動的に振り分けてくれるんだ。
具体的にはどうやってジョブを投入するんですか?
SLURMの場合を例にすると、まず「ジョブスクリプト」というシェルスクリプトを書く。そこに必要なCPU数、メモリ、実行時間の上限、実行コマンドを記述して、sbatch job.sh で投入する。するとキューに入って、リソースが空き次第自動で実行される。待ち時間が長いときは squeue -u ユーザー名 で自分のジョブの状態を確認できるよ。
ジョブスクリプトの書き方
SLURMジョブスクリプトの基本構造:
#!/bin/bash
#SBATCH --job-name=crash_sim_01
#SBATCH --nodes=2
#SBATCH --ntasks-per-node=32
#SBATCH --time=24:00:00
#SBATCH --partition=general
#SBATCH --output=job_%j.out
#SBATCH --error=job_%j.err
module load abaqus/2024
cd $SLURM_SUBMIT_DIR
abaqus job=crash_model cpus=$SLURM_NTASKS scratch=$TMPDIR mp_mode=mpi
PBSジョブスクリプトの場合:
#!/bin/bash
#PBS -N thermal_analysis
#PBS -l nodes=1:ppn=16
#PBS -l walltime=12:00:00
#PBS -q batch
#PBS -o thermal.log
#PBS -e thermal.err
module load ansys/2024r1
cd $PBS_O_WORKDIR
ansys242 -b -np 16 -i thermal_input.dat -o thermal_output.txt
#SBATCH --time=24:00:00 のウォールタイムって、超えたらどうなるんですか?
ジョブが強制終了される。これは初心者が一番ハマるポイントの一つだね。ウォールタイムを短く設定するとキューの待ち時間が短くなる傾向があるから、なるべくギリギリを狙いたいところだけど、短すぎると途中で切られてしまう。最初は余裕をもって設定して、実績から適切な値を学んでいくのがいいよ。
途中で切られたら、最初からやり直しですか? それはきついですね……
ソルバーによってはリスタート機能がある。例えばAbaqusなら oldjob=前回のジョブ名 で途中から再開できる。LS-DYNAも R=rstfile でリスタートが効く。大規模な非線形解析や陽解法の衝突解析では、こまめにリスタートファイルを書き出す設定にしておくのが鉄則だ。
パラメトリックスタディとの連携
バッチ実行の真価が発揮されるのは、設計パラメータを変えながら多数のケースを自動実行するパラメトリックスタディ(パラメータスイープ)だ。板厚を5段階、材料を3種類、荷重を4水準——このような全組み合わせ(5×3×4=60ケース)を手動でGUIから回すのは非現実的だが、バッチ実行なら自動化できる。
パラメトリックスタディをバッチで回すとき、どうやって入力ファイルを作り分けるんですか? 60ケースも手で書くわけにいかないですよね。
定番のやり方は「テンプレート+置換スクリプト」だ。まず入力ファイルのテンプレートを作って、パラメータ部分を @@THICKNESS@@ みたいなプレースホルダにしておく。あとはPythonやシェルスクリプトで、パラメータリストからプレースホルダを実際の値に置換しながらファイルを生成する。こんなイメージだね:
# Pythonでのパラメトリック入力ファイル生成例
import itertools, os
thicknesses = [1.0, 1.5, 2.0, 2.5, 3.0]
materials = ['steel', 'aluminum', 'titanium']
loads = [1000, 2000, 3000, 4000]
template = open('template.inp').read()
for t, mat, load in itertools.product(thicknesses, materials, loads):
case_name = f"case_t{t}_mat{mat}_F{load}"
inp = template.replace('@@THICKNESS@@', str(t))
inp = inp.replace('@@MATERIAL@@', mat)
inp = inp.replace('@@LOAD@@', str(load))
os.makedirs(case_name, exist_ok=True)
with open(f"{case_name}/model.inp", 'w') as f:
f.write(inp)
入力ファイルができたら、ジョブの投入も自動化できますか? 60個を1つずつ sbatch するのも面倒です。
SLURMにはジョブアレイという仕組みがある。#SBATCH --array=0-59 と書くと、60個のジョブが一括で投入されて、各ジョブには $SLURM_ARRAY_TASK_ID として 0〜59 の番号が振られる。スクリプト内でこの番号からパラメータを引っ張ってくれば、1つのジョブスクリプトで全ケースを管理できるんだ。これはHPC運用の基本テクニックだよ。
#!/bin/bash
#SBATCH --job-name=param_sweep
#SBATCH --array=0-59
#SBATCH --ntasks=8
#SBATCH --time=04:00:00
#SBATCH --output=logs/job_%A_%a.out
# パラメータリストからケースを取得
CASE_DIR=$(sed -n "$((SLURM_ARRAY_TASK_ID + 1))p" case_list.txt)
cd $CASE_DIR
module load abaqus/2024
abaqus job=model cpus=$SLURM_NTASKS scratch=$TMPDIR
結果の後処理も自動化できたりしますか? 60ケース分のグラフを手で作るのもしんどいです。
むしろ後処理の自動化こそバッチ実行の醍醐味だね。Pythonでodbファイルから結果を読み取って、最大応力をCSVに書き出して、pandasとmatplotlibで一気に可視化する。こうすることで「パラメータを変えたら結果がどう変わったか」のトレンドが即座にわかる。DOE(実験計画法)と組み合わせれば、最適設計への入り口にもなるよ。
トラブルシューティング
バッチジョブが途中で落ちたとき、どうやって原因を調べればいいんですか? GUIと違ってエラーダイアログも出ないですよね。
まずはジョブの標準出力と標準エラー出力のログファイルを確認する。SLURMなら job_12345.out と job_12345.err だ。それからソルバー固有のログも見る。Abaqusなら .msg や .sta ファイル、OpenFOAMなら log.simpleFoam。よくある原因は次の3つだね:
- メモリ不足(OOM: Out of Memory): 確認コマンド:
sacct -j <jobid> --format=MaxRSS。対策: ノード数を増やすか、メッシュを粗くする - ウォールタイム超過: 確認コマンド:
sacct -j <jobid> --format=Elapsed,Timelimit。対策: 制限時間を延ばすか、リスタートを活用 - ライセンス不足: ソルバーのライセンストークンが全て使用中だとジョブが開始できない。
lmstat -aで確認
ライセンスが足りないときって、ジョブはエラーで終わるんですか? それともキューで待ってくれるんですか?
これはソルバーとスケジューラの設定次第だ。Abaqusはライセンスが取れないと即座にエラーで落ちる。だから大量のジョブを一気に投入すると、ライセンスが足りなくて大半が失敗……なんてことがある。対策としては、ジョブスクリプト内でライセンスの空きをチェックしてから投入する仕組みを作るか、SLURMのライセンスリソース管理機能を使うんだ。一方、OpenFOAMみたいなオープンソースソルバーならライセンスの心配は一切不要だよ。
関連用語
- HPC(High Performance Computing): 大規模並列計算機環境。CAEではクラスタ型HPCが主流
- MPI(Message Passing Interface): 並列計算における標準的なプロセス間通信ライブラリ
- DOE(Design of Experiments): 実験計画法。パラメトリックスタディの効率的な計画に使用
- ジョブアレイ: 同一スクリプトを異なるパラメータで多数同時実行するスケジューラ機能
- リスタート解析: 中断されたジョブを途中から再開する機能
CAE用語の正確な理解は、チーム内のコミュニケーションの基盤です。 — Project NovaSolverは実務者の学習支援も視野に入れています。
バッチ実行の実務で感じる課題を教えてください
Project NovaSolverは、CAEエンジニアが日々直面する課題——セットアップの煩雑さ、計算コスト、結果の解釈——の解決を目指しています。あなたの実務経験が、より良いツール開発の原動力になります。
お問い合わせ(準備中)関連トピック
なった
詳しく
報告