【Multall】(1) WSL2環境での蒸気版Multall　”LP-END 2Stages Analysis”が動かないぞ：　2025/11/15

Multall

Segmentation Errorにより実行不可

  • 64bit gfortran 13 環境で巨大 COMMON ブロックを扱っていることによる構造的な問題
  • コンパイル時 relocation エラーや、実行時の初期化段階でのアクセス違反
    が本質であり、「単にメモリが足りない」だけではありません。
  • Multall自体は、64ビットでも動作する設計
  • 以下のオプションで、コンパイルしたmultall_mediumでもsegmentation errorは改善されず
    • -mcmodel=medium（メモリモデル medium）
    • -fno-align-commons（COMMON の自動アラインメント無効）
  • 結論：はまりそうなので、当面は、理想気体版で検討を進める
/run_steam# free -h
               total        used        free      shared  buff/cache   available
Mem:           3.8Gi       1.5Gi       2.4Gi       2.8Mi       132Mi       2.4Gi
Swap:          1.0Gi       149Mi       874Mi

※WSL2のメモリ割当増は可能（詳細略）

1. 背景・目的

本検討の目的は、DentonCFD（MULTALL）コードの**蒸気版（real gas / steam table 版, 20.9）**を Linux/WSL2 環境上で実行し、蒸気タービン解析に使用可能な状態にすることである。

既に**理想気体版（17.1）**については、

  • 正常終了
  • 効率 91.98% 程度の妥当な結果
  • Linux ネイティブの gnuplot 可視化（7枚の PNG を自動生成）

まで達成済みであり、本報告書では主に蒸気版が動かない要因と現時点での限界を整理する。

2. 実行環境の概要

  • OS: Ubuntu 20.04 on WSL2（Windows 上）
  • 物理メモリ: 約 3.8 GiB
  • Swap: 約 1.0 GiB
  • Fortran コンパイラ: gfortran 13.3.0 (Ubuntu 13.3.0-6ubuntu2~24.04)
  • エディタ／実行環境: VS Code + VS Code Server（サーバ側が 3.1 GiB 近いメモリを消費する時間帯あり）
  • 対象コード:
  • 入力ファイル:

3. 蒸気版 MULTALL のコード構造と特徴

multall-open-20.9.f 冒頭のコメントより、以下の特徴がある:

  • 3D 定常流を、非定常計算（時間発展）により収束させるコード。
  • 複数翼列（多段タービン）を扱うため、翼列数 NRS をパラメータで可変。
  • 2000年代にかけて多数の機能追加:
    • 実在気体 / real gas プロパティ（2006年頃）
    • 表面粗さ（2008年）
    • Spalart–Allmaras 乱流モデル（2010年）
    • Q3D 計算や SSS スキーム（2014年）
    • 混合面モデルの改善（2015年）
  • 蒸気版では、さらに蒸気テーブル参照用のテーブル配列とロジックが追加されている。

特に配列サイズと COMMON ブロック構造が本問題に直結している。

4. 配列次元と COMMON ブロックの規模

commall-open-20.9 冒頭より:

      PARAMETER(ID=64,JD=2500,KD=82,MAXKI=82,NRS=21,IG1=32,
     &          JG1=1000,KG1=41)
...
      COMMON/BKUTIL/
     &         NAME(18),STORE(ID,JD,KD),TEMP1(ID,JD,KD),TEMP2(ID,JD,KD),
     &         TEMP3(ID,JD,KD),TEMP4(ID,JD,KD),STORE2(ID,JD,KD),
     &         SGEN(ID,JD,KD),PI,DEGRAD,RADDEG

  • ここから分かる点:
  • グリッドサイズ:
    • ID = 64（周方向）
    • JD = 2500（子午面方向）
    • KD = 82（スパン方向）
  • 代表的配列 STORE(ID,JD,KD) の要素数:
    • 64 × 2500 × 82 ≒ 13,120,000 要素
    • 倍精度実数(8バイト)とすると、約 105 MB 1配列で使用
  • 同様の 3次元配列が COMMON ブロックに多数存在 (TEMP1〜4, STORE2, SGEN, RO, P, FLOWX など)

結果として:

  • 1つの COMMON ブロックだけで数百MB級 のサイズとなる可能性が高い。
  • さらに、複数の COMMON が合計されると、リンク時にアドレス空間や relocation に関する制約に触れる。

5. 実際に発生している問題

5.1 コンパイル・リンク時のエラー

複数のコンパイル試行を行ったが、以下のようなエラーに直面した。

(1) 通常オプションでの試行

gfortran -O1 -std=legacy -fdefault-real-8 -fdefault-double-8 \
  -no-pie multall-open-20.9.f -o multall_fixed

  • → 出力の要点:
  • relocation truncated to fit: R_X86_64_PC32 against symbol 'bkintg_' defined in COMMON section
  • relocation truncated to fit: R_X86_64_PC32 against symbol 'bkstag_' defined in COMMON section
  • collect2: error: ld returned 1 exit status

意味:
COMMON ブロック（例: BKINTG, BKSTAG）に対する参照が、64bit アドレスの制約や PC 相対アドレッシングの制約で収まりきらず、リンクエラーになっている。

(2) オプション調整

  • -mcmodel=medium, -fno-align-commons, -O0 など、COMMON の配置やアラインメントを変える試行:
gfortran -O0 -std=legacy -fdefault-real-8 -fdefault-double-8 \
  -fno-align-commons -mcmodel=medium multall-open-20.9.f -o multall_medium

  • → このケースではリンクは成功し、multall_medium が生成された。
  • しかし、実行すると次の問題へ進む。

5.2 実行時の挙動

multall_medium を実行:

cd run_steam
./multall_medium

  • 結果: 即座に Segmentation fault
  • ulimit -s unlimited でスタックサイズ制限を解除しても挙動は変わらず。
  • strace でシステムコールを追跡しようとしたが、trace.log がほとんど書かれない段階で落ちており、ユーザ空間内（初期化段階）でのメモリアクセス違反が疑われる。

このことから、

  • リンクが通っても、実行時に巨大 COMMON／配列の境界やレイアウトが破綻し、アクセス違反 に至っている可能性が高い。
  • ifgfortran 13 による内部の配置最適化や、元々のコードが想定していたコンパイラとの不整合なども要因と考えられる。

6. メモリ・環境側の要因

6.1 VS Code Server のメモリ消費

  • 調査中に、VS Code Server プロセスが 約 3.1 GiB のメモリを占有しているフェーズがあり、システム全体の空きメモリが減少していた。
  • これに対して:
    • 不要な VS Code タブを閉じる
    • 一時的に VS Code Server を再起動する
    • その他キャッシュ削除

などでメモリを空け、その状態で再度コンパイル／実行を試行したが、

  • コンパイル時 relocation エラー
  • 実行時即セグフォルト

という根本挙動は変わらなかった。

したがって:

  • 一時的なメモリ不足だけが原因ではなく、構造的にコード/コンパイラの組合せが不整合 であると判断される。

7. 理想気体版との比較

  • 理想気体版（17.1）は同じ WSL2 + gfortran 13 環境で正常にコンパイル・実行済み。
  • multall 実行により:
    • flow_out, global.plt, grid_out などの出力を生成
    • gnuplot ベースの Linux ネイティブ可視化スクリプト visualize_linux_fixed.sh により 7枚の PNG（効率分布など）を生成
  • file コマンドの結果:
    • 理想版, 蒸気版ともに「ELF 64-bit LSB executable」
      → 32bit バイナリではないことを確認済み

理想気体版が問題なく動作する一方で、蒸気版のみが relocation エラーおよび即セグフォルトを起こすことから、

  • 問題は「環境一般」よりも「蒸気版特有の配列規模・COMMON 構造・テーブル参照」に起因していると考えられる。

8. コード改造による解決可能性の検討

8.1 可能性があるがリスクが高い案

  1. 配列次元（ID, JD, KD, NRS）の削減
    • commall-open-20.9 内の PARAMETER を小さくし、格子点数を大幅に減らすことで COMMON のサイズを削減。
    • relocation エラーの回避、および実行時メモリ負荷軽減が期待できる。
    • ただし：
      • 既存の入力データが JD=2500 などを前提としているため、そのままでは範囲外アクセスのリスク大。
      • 実質「小さい格子の新規ケース用ミニ版蒸気コード」を新たに構築する形になり、既存ケースの再現性は失われる。
  2. COMMON ブロックの分割
    • 例えば BKUTIL を複数の COMMON（BKUTIL1, BKUTIL2 など）に分け、1 COMMON あたりのサイズを減らす。
    • 全てのサブルーチンで一貫して COMMON 宣言を書き換える必要がある。
    • 手作業・部分的な変更は非常に危険で、わずかな不整合でも不可解なクラッシュの原因となる。
  3. ALLOCATABLE 配列への置換（F90化）
    • 大規模配列を動的確保し、モジュール＋USE 構文で管理する。
    • 現状の F77 スタイルコードを全面的に書き換える必要があり、工数的に「別プロジェクト」レベル。

8.2 現時点での判断

  • WSL2 上で VS Code から安全に進められる範囲で、既存の大規模ケース用蒸気版を完全に動かすための「少しの改造」では済まない。
  • ガチのリファクタリング or 環境移行が必要になる。

9. 環境側の解決案（推奨）

蒸気版をオリジナルの設定通りに動かしたい場合、ソース改造より環境を元の前提に近づける方が現実的かつ安全と考えられる。

推奨案

  1. 32bit Linux + 古い gfortran の用意
    • 例: VirtualBox 上に 32bit 版 Ubuntu 16.04 などをインストール。
    • gfortran 4.8〜8 系 をインストールし、multall-open-20.9.f を当時に近いオプションでコンパイル。
    • 32bit アドレスモデルでは、COMMON ブロックの取り扱いが元のコード設計に近く、relocation 問題が起きない可能性が高い。
  2. 可能であれば、元の配布資料の「推奨コンパイラ・OS」を確認
    • MULTALL 同梱の PDF/技術仕様書（MULTALL/技術仕様書.md 等）に記載があれば、それに合わせる。

10. 理想気体版の活用と代替案

蒸気版が現環境で動作しない一方、理想気体版は:

  • 数値的に安定しており、高効率な結果（約 92%）を出している。
  • gnuplot による可視化も自動構築済み。

したがって、現時点での実務的な代替案としては:

  1. 理想気体版で主な設計検討を行う
    • まずは理想気体版で流れ場・効率を評価。
  2. 蒸気物性の影響は別途テーブルで補正・検証
    • props_table.dat 等の蒸気テーブルを用いて、入口・出口条件の比熱、ガンマ、比体積等を別途確認し、感度を評価する。
  3. 将来的に、蒸気版専用の軽量ケース or 新コードへの移行を検討
    • 格子点数を減らしたミニ版蒸気ケースを作る
    • あるいは、よりモダンな CFD コード（explicit に real gas を扱えるもの）への移行も選択肢となる。

11. 要点まとめ（箇条書き）

  • 蒸気版 MULTALL（20.9）は、巨大な COMMON ブロックと配列次元（例: JD=2500, KD=82, NRS=21）により、
    64bit gfortran 13 環境で relocation エラーと実行時セグメンテーションフォルトを起こしている。
  • コンパイルオプションを変更しても、リンクエラーが消えた後に起動直後のセグフォルトが発生し、実質的に利用不能。
  • VS Code Server のメモリ解放など環境調整を行っても問題は解消されなかった。
  • 理想気体版（17.1）は同環境で正常に動作し、高品質な可視化も実現できている。
  • コード改造による根本解決には、
    • 配列次元削減
    • COMMON 分割
    • F90 以降への全面移行
      など、大規模かつリスキーな変更が必要であり、現状の作業範囲を超える。
  • 実務的には、
    • 32bit + 古い gfortran 環境で蒸気版を動かす
    • 理想気体版で解析を行い、蒸気物性は別途補正・検証する
      といったアプローチが現実的な解決策である。

この内容をベースに、必要に応じて「概要（日本語要約）」「技術詳細（英語）」の二言語版に整形することもできますし、Word/LaTeX の章立てや図表（格子サイズ・メモリ見積りなど）も追加できます。もし「社内報告用のフォーマット」やページ制限があれば、それに合わせた短縮版も作成可能です。

コメント

タイトルとURLをコピーしました