NASTRAN入力形式 — CAE用語解説

歴史的経緯と信頼性が理由だ。NASTRANは1960年代にNASAで開発され、当時の計算機環境ではカードリーダーで読み込む固定長フォーマットが標準だった。この形式は、Bulk Data File (BDF) として規格化され、ソルバーがデータをパースする際の曖昧さを排除できる。例えば、1カラム目が「$」ならコメント、1-8カラムがフィールド名、9-16カラムが第1データ…という具合に、位置が決まっている。MSCやSiemensのソルバーも、この基本フォーマットを継承している。

その通りだ。例えば、節点座標を定義するGRIDカード。9-16カラムに節点番号「100」を入れるつもりで「100」と書いたが、12カラム目から書いてしまった場合、ソルバーは9-16カラムを「    100」と解釈し、節点番号は「100」ではなく「0」と読まれる（空欄は0扱い）。これがモデリングエラーの原因になる。GUIツール（Patran, Femap）は最終的にこのBDFを生成する“翻訳機”のようなものだ。

大まかに3つのブロックに分かれる。まず、実行制御部（SOL, CENDなど）。次に、ケース制御部（SUBCASE, SPC, LOADなど）。最後が、モデルデータ全てが詰まったバルクデータ部だ。バルクデータ部は、GRID, CQUAD4, MAT1, FORCEといった「カード」の集合体で、各カードが特定のフォーマットに従う。これがNASTRAN入力の骨格だ。

等方性線形弾性材料ならMAT1カードを使う。フォーマットは「小さいフィールド」と「大きいフィールド」があるが、基本は1-8カラムがカード名、以降8文字ごとにデータを置く。例えば、鋼材を定義するなら：

その場合は、「大きいフィールド」フォーマットを使う。1-8カラムがカード名、9-16カラムが第1データ、17-24カラムが第2データ…というのは同じだが、1つのデータフィールドを16カラムに拡張する。具体的には、9-24カラムが第1データ、25-40カラムが第2データとなる。データを記入する際、9カラム目からではなく、10カラム目から書き始めるのが慣例だ。これで倍の桁数が使える。

4節点シェル要素のCQUAD4は、最低限、要素ID、プロパティID、4つの節点番号が必要だ。例：

基本はGUIプリプロセッサ（Patran, Femap, HyperMesh）でモデルを作り、BDFをエクスポートする。しかし、パラメータスタディで材料定数だけを一括変更したり、特定の節点群に荷重を追加する場合は、スクリプト（Python, Perl）やテキストエディタで直接編集するのが速い。その際、カラム位置を可視化するエディタ設定（グリッド線表示）が必須だ。また、MSCやSiemensのソルバーには、構文チェックのみを行うnastran checkオプションがあり、実行前にエラーを検出できる。

UNIX系のgrep、awk、sedコマンドが強力だ。例えば、grep -n "CQUAD4.*[5-9][0-9][0-9][0-9]" model.bdf | head -20とすれば、IDが5000-9999のCQUAD4カードとその行番号を上位20件表示できる。WindowsならPowerShellや、findstrコマンドで代用可能。このように、BDFはテキストベースだからこそ、プログラミングによるフィルタリングや一括編集が容易という利点がある。

まず、FATAL MESSAGEの直後のメッセージを読む。例えば「USER FATAL MESSAGE 9050 (SCAN)」は、バルクデータのスキャンエラーで、カードのフォーマット不正が疑われる。出力された.f06ファイルや.logファイルに、エラーが発生した「付近のカード」が表示されるので、そのカードの前後数行を重点的にチェックする。特に、カード名の綴り間違い（GRIDをGRIDDと書く）、数値フィールドに文字が入っている、継続カード（「*」で始まる）の使い方ミスが典型だ。

基本フォーマットは共通だが、各社が独自拡張を加えている。MSC NASTRANのBDFをそのままSiemens NX NASTRANで実行できることが多いが、100%互換ではない。例えば、MSC独自の非線形要素や解法オプションに対応するカードは、Siemensでは無視されたりエラーになる。逆も然り。また、自由フォーマット入力の扱いにも差がある。MSCはカンマ区切りをサポートするが、Siemensはより厳格に固定フォーマットを要求する傾向がある。

固定カラム位置に縛られず、カンマやスペースでデータを区切って記述する形式だ。BDFの先頭にNASTRAN SYSTEM(344)=1 などの実行制御文を入れることで有効になる。例：

根本的な哲学が違う。Abaqusの.inpはキーワードベースで、比較的自由なフォーマットだ。Ansysの.cdbはNASTRAN BDFと同様の固定フォーマットの系譜を引くが、カード名やデータ構造が異なる。例えば、節点定義はGRIDではなくNだ。NASTRAN BDFは、航空宇宙業界で長年使われてきた「標準」としての地位が強く、異なるベンダーのプリポストツール（Altair HyperMesh, ANSA等）もBDFの入出力を標準サポートしている点が最大の強みだ。

9052は「バルクデータのカードイメージが認識できない」エラーだ。最も多い原因は、カード名の綴り間違いまたはカード名が許可された位置にないこと。例えば、バルクデータ部にCENDやBEGIN BULKといった実行制御カードを書いてしまった場合などだ。エラーメッセージの近くに「OFFENDING CARD:」と表示されているはずなので、そのカードの1-8カラムを一字一句確認せよ。

4272は「ジョブが実行可能な大きさを超えた」というライセンスやシステムリソース関連のエラーだ。BDFファイル自体のエラーではないが、モデルが大きすぎる（例えば、要素数がライセンスで許可された上限を超える）ことが原因。MSC NASTRANならPARAM,MAXRATIOやPARAM,POSTの設定を見直すか、あるいはモデルをパーツ分割してマルチランすることを検討する必要がある。

FATALではないが最も危険なケースだ。まず、単位系の不一致を疑え。BDFは単位を規定しない。例えば、GRID座標をmmで書き、MAT1のヤング率をMPaで書いたが、FORCEカードの荷重値をNではなくkNで書いていたら、力のつり合いが崩れる。次に、境界条件の見落とし。SPC（単点拘束）カードで拘束した節点番号が、実際のモデルに存在するか。最後に、材料定数の桁間違い。E+05をE+04と書いていれば、剛性が1/10になり変位は10倍になる。

三つの対策がある。第一に、専用のBDFエディタや、カラムガイド線が表示されるエディタ（VSCode, Notepad++などにプラグインあり）を使う。第二に、編集は必ず「一括置換」や「スクリプト」で行い、手打ちを避ける。第三に、編集前後のファイルの差分を取る（diffコマンドやWinMergeなどのツール）。変更した部分だけを視覚的に確認でき、意図しない位置ずれを発見できる。これらは実務では基本の作業手順だ。