CAEシミュレーションの回帰テスト — ソルバー更新・モデル変更時の品質保証戦略

理論と背景

CAE回帰テストとは

なぜ回帰テストが必要か

• Nastranのバージョン変更で固有振動数が0.3〜0.5%変動した（剛性マトリクスの組み立てアルゴリズム変更による）
• Abaqusのマイナーアップデートで接触判定のデフォルトが変わり、接触力が数%変化した
• OpenFOAMのバージョン変更で乱流モデルの壁関数実装が修正され、Cd値が2%以上変わった
• コンパイラの最適化フラグ変更だけで、浮動小数点演算の丸め順序が変わり、非線形解析で収束パスが分岐した

判定の数学的枠組み

ここで $Y_{baseline}$ はベースライン（基準）結果、$Y_{new}$ は新しい環境での結果。判定基準は：

さらに、テストスイート全体の合格率も管理する：

ソルバーバージョン変更の影響

ベースライン管理と許容差設計

ベースライン結果の管理

• Git リポジトリにベースラインJSONまたはCSVを格納
• 各ベースラインにメタデータを紐付け：ソルバー名・バージョン、実行日時、メッシュサイズ、OS/コンパイラ情報
• 結果値はスカラー値の抽出結果（最大変位、最大応力、固有振動数、反力合計など）
• 必要に応じてフィールドデータ（節点変位分布、応力コンター等）もバイナリ形式で保存

{
  "model": "cantilever_beam_001",
  "solver": "MSC Nastran",
  "solver_version": "2024.1",
  "date": "2026-01-15",
  "os": "RHEL 8.9",
  "results": {
    "max_displacement_mm": 5.234,
    "max_vonmises_mpa": 325.8,
    "freq_mode1_hz": 142.35,
    "reaction_force_n": 1000.02,
    "energy_balance_pct": 99.97
  }
}

許容差基準の設計

多段階判定の考え方

• GREEN (PASS)：$e_{rel} < \varepsilon_1$ — 問題なし。自動承認
• AMBER (WARNING)：$\varepsilon_1 \leq e_{rel} < \varepsilon_2$ — 要確認。エンジニアのレビュー後に判断
• RED (FAIL)：$e_{rel} \geq \varepsilon_2$ — 不合格。リリースブロック

実践：テストスイートの構築

テストケースの選定

• レベル1：理論解が既知のベンチマーク — NAFEMSベンチマーク、片持ち梁、円孔板など。解析の基本機能が壊れていないかを確認
• レベル2：社内標準モデル — 過去のプロジェクトで繰り返し使われているモデル。業務で重要な解析タイプをカバー
• レベル3：エッジケース — 非線形接触、大変形、マルチフィジクスなど、ソルバー変更で影響を受けやすい高難度モデル
• レベル4：大規模モデル（スモーク用） — 数百万DOFクラス。完走するかどうかとメモリ使用量を確認

Python自動比較スクリプト

import json
import numpy as np
import pytest

def load_results(filepath):
    with open(filepath) as f:
        return json.load(f)

TOLERANCES = {
    "max_displacement_mm": {"rel": 0.005, "abs": 1e-4},  # 0.5%
    "max_vonmises_mpa":    {"rel": 0.03,  "abs": 0.1},   # 3%
    "freq_mode1_hz":       {"rel": 0.01,  "abs": 0.01},  # 1%
    "reaction_force_n":    {"rel": 0.001, "abs": 0.01},   # 0.1%
    "energy_balance_pct":  {"rel": 0.001, "abs": 0.01},   # 0.1%
}

baseline = load_results("baseline/cantilever_001.json")
current  = load_results("results/cantilever_001.json")

@pytest.mark.parametrize("key", TOLERANCES.keys())
def test_regression(key):
    b = baseline["results"][key]
    c = current["results"][key]
    tol = TOLERANCES[key]

    if abs(b) > 1e-12:
        rel_err = abs(c - b) / abs(b)
        assert rel_err < tol["rel"], \
            f"{key}: rel_err={rel_err:.6f} > {tol['rel']}"
    else:
        abs_err = abs(c - b)
        assert abs_err < tol["abs"], \
            f"{key}: abs_err={abs_err:.6e} > {tol['abs']}"

テスト結果レポートの自動生成

• テスト実行日時・環境情報（ソルバーバージョン、OS、ホスト名）
• 全テストケースの PASS/AMBER/FAIL 一覧表
• FAILしたケースの詳細（ベースライン値、今回値、差分、許容差）
• 全体合格率と前回実行からの推移グラフ
• FAILの根本原因分析（RCA）セクション（手動記入）

CI/CDパイプラインへの統合

Jenkins / GitLab CI / GitHub Actions比較

ソルバー別の自動化手法

1. Trigger：Gitへの入力ファイルPush or 定期スケジュール（毎晩・毎週）
2. Build：ソルバーをバッチ実行（HPCジョブスケジューラ経由の場合もあり）
3. Test：Pythonスクリプトでベースラインと自動比較（pytest）
4. Report：HTML/PDFレポート生成、Slackに通知
5. Archive：テスト結果をJenkinsアーティファクトとして保存

大規模組織でのCI/CD運用

• Nightly Run：毎晩、全テストスイート（50〜200件）を自動実行。翌朝にレポートが届く
• ソルバーバージョン評価：新バージョンのリリース時に、専任チーム（2〜3名）が2〜4週間かけて全テストスイートを回し、FAILケースの原因を調査
• ゲートキーパー制：ソルバーバージョンの社内展開は、回帰テストが全件パスした後に「CAEプラットフォームチーム」が承認
• ベースライン更新プロセス：FAILの原因が「意図的な改善」と判断された場合、エンジニア2名以上のレビューを経てベースラインを更新

先端トピック

機械学習による異常検知

• 主成分分析（PCA）：フィールドデータを低次元に圧縮し、ベースラインからの「距離」を計算。スカラー値では検出できないパターン変化を検出
• オートエンコーダ：正常パターンを学習し、新結果の「再構成誤差」が大きければ異常と判定
• 時系列異常検知：過去のテスト結果の推移から、統計的に外れた値を検出（例：回帰テスト結果が徐々にドリフトしている傾向の検出）

クラウドHPCとの連携

トラブルシューティング

回帰テスト特有の落とし穴

• 並列度を固定する（4コアなら常に4コアで実行）
• ソルバーのオプションで再現性モードを有効化する（NastranのSYSTEM(207)=1など）
• それでも微小差が出る場合は、「非決定的差分」に対する専用の緩い許容差を設定する

バージョン変更時の緊急対応

1. FAILのパターンを分析：全てのFAILが同じ種類の物理量か？ 同じ要素タイプか？ 同じ解析タイプか？ パターンがあれば原因の絞り込みが早い
2. リリースノートを確認：ソルバーベンダーのRelease Notesに「変更されたデフォルト」や「修正されたバグ」がないか確認。多くのFAILはここで説明がつく
3. 最小再現ケースを作成：複雑なモデルのFAILは、要素1個のモデルにまで簡略化して原因を特定する
4. ベンダーに問い合わせ：自社で原因が特定できない場合は、FAILケースの入力ファイルと両バージョンの結果をベンダーサポートに提出
5. 判断：「バグ修正による改善」ならベースラインを更新。「新バグの疑い」ならバージョンアップを保留し旧バージョンを継続使用