軸対称解析 — トラブルシューティングガイド

カテゴリ: 構造解析 | 2026-02-20
axisymmetric-troubleshoot
問題解決のヒント

軸対称解析のトラブル

🧑‍🎓

軸対称解析でよくあるトラブルを教えてください。


🎓

軸対称特有の盲点がいくつかある。


回転軸上の拘束忘れ

🧑‍🎓

$r = 0$ 上の節点で $u_r = 0$ を忘れるとどうなりますか?


🎓

回転軸が横に動くため、応力分布が非物理的になる。特異剛性マトリクスのエラー(Nastranの FATAL 2012 等)が出ることもある。


🎓

多くのソルバーは軸対称要素の $r = 0$ 上の節点に自動的に $u_r = 0$ を設定するが、手動で設定が必要なソルバーもある。必ず確認すること。


フープ応力の見落とし

🧑‍🎓

結果で $\sigma_r$ と $\sigma_z$ だけ見て $\sigma_\theta$ を見忘れることがあります。


🎓

軸対称では $\sigma_\theta$(フープ応力)が最大応力になることが多い。内圧を受ける円筒では $\sigma_\theta > \sigma_z > \sigma_r$ だ。$\sigma_\theta$ を見落とすと最大応力を過小評価する重大なミスになる。


🎓

von Mises応力をチェックする場合も、$\sigma_\theta$ は自動的に含まれるが、応力分類(ASME Div. 2の膜/曲げ分離)では個別に確認する必要がある。


荷重の入力単位ミス

🧑‍🎓

軸対称の荷重入力で注意すべきことは?


🎓

ソルバーによって荷重の解釈が異なる:


  • Abaqus — 集中力は全周分($2\pi r$ 分)。$F = 100$ N を入力すると、全周で100 N
  • Nastran — FORCE カードは全周分。$F = 100$ N = 全周100 N
  • Ansys — ノードの集中力は全周分

🧑‍🎓

全ソルバーで全周分なんですね。


🎓

「リング荷重」という意味だ。内圧100 MPaを面として与える場合はどのソルバーでも正しく処理されるが、集中力を与えるときは全周の合計力として入力することを忘れないこと。


$r = 0$ 付近の応力集中

🧑‍🎓

回転軸付近で応力が異常に大きくなることがあります。


🎓

$r \to 0$ で $\varepsilon_\theta = u_r / r$ の分母がゼロに近づくため、数値的な精度低下が起きることがある。特にメッシュが粗いと $r = 0$ 付近の要素で応力がばらつく。


🎓

対策:

  • $r = 0$ 付近のメッシュを十分細かくする
  • $r = 0$ 上の応力は「参考値」として扱い、設計判断には使わない
  • 必要なら3次元モデルで $r = 0$ 付近を検証

ラメの理論解との比較

🧑‍🎓

FEMの結果がラメの理論解と合わないときは?


🎓

確認項目:


1. 開口端か密閉端か — ラメの問題は平面ひずみ(無限長円筒)を仮定。密閉端では端部効果で $\sigma_z$ が変わる

2. 端部条件 — FEMモデルの端部($z$ 方向の境界条件)が理論と一致するか

3. メッシュ密度 — 肉厚方向に最低4要素(二次要素なら2要素)

4. 薄肉近似との混同 — 薄肉公式 $\sigma_\theta = pD/2t$ はラメの近似。$D/t < 20$ では差が出る


🧑‍🎓

薄肉公式とラメの式の差が出るのは $D/t$ がいくつ以下ですか?


🎓

$D/t < 20$ で差が5%以上になる。$D/t < 10$(厚肉)ではラメの式が必須。FEMは当然どちらも正確に解けるが、検証でどちらの理論解と比較するかを間違えないこと。


まとめ

🧑‍🎓

軸対称のトラブル対処、整理します。


🎓
  • $r = 0$ で $u_r = 0$ — 忘れると非物理的な結果
  • $\sigma_\theta$ を見落とさない — 軸対称で最大応力になることが多い
  • 荷重は全周分 — 入力値がリング荷重であることを理解
  • $r = 0$ 付近の精度 — メッシュを細かく。応力は参考値
  • 理論解との比較 — ラメの問題(厚肉)と薄肉公式を区別

🧑‍🎓

フープ応力の見落としが一番怖いですね。$\sigma_\theta$ が最大応力なのに気づかないと、設計が危険側になる。


🎓

圧力容器の事故の多くはフープ応力による破裂だ。$\sigma_\theta$ は軸対称解析で最も注目すべき成分であることを常に意識してほしい。


Coffee Break よもやま話

NASAとNASTRAN — FEMの夜明け

今や世界中で使われている有限要素法ソルバー「NASTRAN」は、1960年代にNASAが開発しました。アポロ計画でロケットの構造解析が必要だったのです。当時のコンピュータはメモリ数KBの時代——今のスマートフォンの100万分の1以下の性能で、人類を月に送る構造計算をしていたのです。

トラブル解決の考え方

デバッグのイメージ

構造解析のトラブルシューティングは「医師の問診」に似ている。「いつから症状が出たか」(どのステップでエラーが出るか)、「どこが痛いか」(どの要素で収束しないか)、「何をしたか」(直前に何を変更したか)を系統的に聞くことで原因を特定する。

「解析が合わない」と思ったら

  1. まず深呼吸——焦って設定をランダムに変えると、問題がさらに複雑になる
  2. 最小再現ケースを作る——軸対称解析の問題を最も単純な形で再現する。「引き算のデバッグ」が最も効率的
  3. 1つだけ変えて再実行——複数の変更を同時に行うと、何が効いたか分からなくなる。科学実験と同じ「対照実験」の原則
  4. 物理に立ち返る——計算結果が「重力に逆らって物が浮く」ような非物理的な結果なら、入力データの根本的な間違いを疑う

構造解析の収束問題や計算コストに課題を感じていませんか? — Project NovaSolverは、実務者が日々直面するこうした課題の解決を目指す研究開発プロジェクトです。

次世代CAEプロジェクト:開発者と実務者をつなぐ

Project NovaSolverは、軸対称解析を含む幅広い解析分野において、実務者の知見を最大限に活かせる環境の実現を探求しています。まだ道半ばですが、共に歩んでいただける方を募集しています。

開発パートナー登録 →