CGNS (CFD General Notation System) — CAE用語解説
CGNSとは
CGNSってどういうフォーマットなんですか? 普通のテキストファイルとは違うんですか?
CGNSは「CFD General Notation System」の略で、CFDデータを標準的に格納するためのフォーマットだ。中身はHDF5というバイナリ形式がベースだから、テキストファイルとは全然違う。大規模メッシュでも数百万セルのデータを効率よく扱えて、読み書きが非常に高速なのが特長だよ。
なるほど、バイナリなんですね。じゃあ、なんでわざわざCGNSなんて規格を作ったんですか? 各ソルバーが独自形式で保存すればいいんじゃ…
まさにそこが問題だったんだ。1990年代のCFD業界は、各ソルバーが独自フォーマットで保存していたから、メッシャーAで作ったメッシュをソルバーBに渡して、結果をポスト処理ツールCで可視化する、っていう当たり前のワークフローがすごく面倒だった。NASAとボーイングが中心になって「ソルバーに依存しない共通データ形式」を作ろうとしたのがCGNSの始まりだよ。
HDF5バックエンド
HDF5がバックエンドということは、普通のテキストエディタでは中身を見られないんですか? デバッグのとき困りませんか?
そのとおり、テキストエディタでは開けない。ただし cgnsview や HDFView といった専用GUIツールを使えば、ツリー構造をグラフィカルにブラウズできるよ。Pythonなら pyCGNS や h5py で読み書きできるから、スクリプトで自動処理するのも簡単だ。例えばこんな感じでノード一覧を取得できる:
import CGNS.MAP as CGM
(tree, links, paths) = CGM.load("flow.cgns")
HDF5がベースなら、パラレルI/Oもできるんですか? 大規模解析だとファイルの読み書きがボトルネックになるって聞いたことがあるんですけど。
いい質問だね。CGNSはHDF5のパラレルI/O機能(MPI-IO)をそのまま活用できる。つまり数千プロセスで分割計算していても、各プロセスが1つのCGNSファイルの自分の担当領域に同時に書き込める。これが無いと、全データをランク0に集約してから書き出すことになって、メモリも時間も爆発的に増える。数億セル規模の解析では、パラレルCGNSが事実上の必須要件だよ。
ファイル構造とデータモデル
CGNSファイルの中身ってどういう構造になっているんですか? フォルダみたいな階層があるんですか?
ツリー構造になっていて、各ノードに「名前」「ラベル(型)」「データ」が格納される。ざっくり言うとこんな階層だ:
- CGNSBase_t — 最上位。空間次元(2D/3D)とセル次元を定義
- Zone_t — 計算ゾーン。構造格子なら
Structured、非構造格子ならUnstructured - GridCoordinates_t — 節点座標(CoordinateX, Y, Z)
- Elements_t — 要素の接続情報(TRI_3, QUAD_4, TETRA_4, HEXA_8 など)
- FlowSolution_t — 解データ(圧力、速度、温度など)
- ZoneBC_t — 境界条件(inlet, outlet, wall など)
例えば航空機の翼の解析なら、BaseのPhysicalDimensionが3、ゾーンが翼面・ファーフィールドなどに分かれて、各ゾーンにメッシュ座標と解が入る、というイメージだ。
構造格子と非構造格子って、CGNSの中では扱いが違うんですか?
違うね。構造格子の場合は、Zone_tにIJKのサイズ(例えば 129×65×33)を指定すれば、要素の接続情報は暗黙的に決まるからElements_tは不要。一方、非構造格子ではElements_tに全要素の頂点接続リストを明示的に書く必要がある。実務では非構造格子の方が圧倒的に多いから、Elements_tの扱いに慣れておくのが大事だよ。混合要素(テトラ+プリズムなど)のときは、要素タイプごとにセクションを分けて格納するんだ。
ソルバー間の相互運用性
CGNSを使うと、異なるソルバー間でデータをやり取りできるって聞いたんですけど、本当にスムーズにいくんですか?
それがCGNS最大のメリットだ。例えばPointwiseやICEM CFDでメッシュを作って、ANSYS Fluent、OpenFOAM、FUN3D、elsAなど異なるソルバーに渡すとき、CGNSなら変換の手間が最小限で済む。メッシュだけでなく境界条件や解データも一緒に持てるから、ポスト処理ツール(ParaViewやTecplot)への受け渡しもスムーズだよ。
でも実際には、ソルバーAが書いたCGNSをソルバーBが読めないとか、そういう問題ってないんですか?
正直に言うと、完全にシームレスとは言い切れない。CGNSの規格(SIDS: Standard Interface Data Structures)はかなり広範で、各ソルバーがサポートしている範囲が微妙に違ったりする。例えば、ある特殊な境界条件タイプをソルバーAは独自拡張ノードに書き込んでいて、ソルバーBはそのノードを無視する、なんてことはある。ただ、メッシュ座標と基本的な流れ場のデータ(圧力、速度、温度)は互換性が非常に高いから、8〜9割のケースは問題なくいけるよ。
メッシュと解データの格納
FlowSolution_tに解データを入れるって言ってましたけど、節点ベースとセル中心ベースの両方に対応してるんですか?
対応してるよ。FlowSolution_tの中に GridLocation_t というノードがあって、Vertex(節点)か CellCenter(セル中心)かを指定する。有限要素法ベースのソルバーは節点値を使うことが多いし、有限体積法ベースのFluent・OpenFOAM・FUN3Dなどはセル中心値が自然だ。どちらで保存されているかをチェックしないと、ポスト処理で値がずれる原因になるから要注意だよ。
非定常解析のタイムステップごとの結果も保存できるんですか? ファイルが膨大になりそうですけど…
できるよ。BaseIterativeData_t と ZoneIterativeData_t というノードで、各タイムステップの解データへのポインタを管理する仕組みがある。1つのCGNSファイルに全タイムステップを入れることもできるし、ステップごとに別ファイルにすることも可能だ。実務的には、数千ステップの非定常LESなんかだと1ファイルに全部入れると数百GBになるから、ステップごとに分割するか、間引いて保存するのが現実的だね。
実務でのCGNS活用
実際の現場で、CGNSがよく使われる場面ってどんなところですか?
航空宇宙分野が一番多い。NASAやAIAA関連のワークショップでは、検証用ベンチマークケースのメッシュがCGNSで配布されることが標準だ。ターボ機械の分野でも、elsAやTURBO、CFX間でデータを受け渡すときにCGNSが活躍する。最近は自動車のCFDでもCGNSが増えてきたし、Pythonの meshio ライブラリ経由でSTLやVTKと相互変換する人も多い。
OpenFOAMでもCGNSを使えるんですか? OpenFOAMって独自のディレクトリ構造のイメージが強いんですけど。
OpenFOAMには標準で ccm26ToFoam や cgnsToFoam(バージョンによって有無が異なる)といった変換ユーティリティがある。Foundation版にはないけどESI版(OpenCFD版)にはCGNS読み込みが入っていることが多い。なくても、Pythonで pyCGNS でメッシュを読んでOpenFOAMの polyMesh 形式に変換するスクリプトを書けば対応できる。逆にOpenFOAMの結果をCGNSにエクスポートして、Tecplotで可視化する、みたいなフローも実務では結構ある。
CGNSを使い始めるにあたって、最初にやるべきことってありますか?
まずは cgnsview をインストールして、サンプルのCGNSファイルを眺めてみることだ。ツリー構造が視覚的に理解できる。次に、CGNSの公式ドキュメント(SIDS)のうち、GridCoordinates_tとElements_tとFlowSolution_tの3つだけ読めば、実務の8割はカバーできる。Pythonで読み書きしたいなら pip install pyCGNS で入るから、小さなメッシュで試してみるのが最短ルートだよ。
関連用語
- HDF5 (Hierarchical Data Format 5) — CGNSのバックエンドとなるバイナリデータ形式。高速I/Oとパラレルアクセスをサポート
- SIDS (Standard Interface Data Structures) — CGNSのデータモデル規格。ノードの種類や命名規則を定義
- MLL (Mid-Level Library) — CGNS操作用のC/Fortran API。ノードの読み書きを簡潔に行える
- CFD — 数値流体力学。CGNSが主にターゲットとする解析分野
- 離散化 — 連続体を要素に分割する過程。CGNSはその結果のメッシュを格納する
CAE用語の正確な理解は、チーム内のコミュニケーションの基盤です。 — Project NovaSolverは実務者の学習支援も視野に入れています。
CGNSの実務で感じる課題を教えてください
Project NovaSolverは、CAEエンジニアが日々直面する課題——データ変換の煩雑さ、ソルバー間の互換性、大規模データのI/O——の解決を目指しています。あなたの実務経験が、より良いツール開発の原動力になります。
お問い合わせ(準備中)関連トピック
なった
詳しく
報告