共役伝熱（CHT）解析手法の全体像

その認識は半分正解で半分間違いです。重要なのは「境界を共有する界面での熱流束と温度の連続性を、直接的に満たしながら解く」という点です。従来の逐次解析では、流体側で求めた熱伝達率（h）を固体側の境界条件として与えていましたが、CHTではその仮定が不要になります。例えば、自動車のブレーキディスクでは、ディスク表面温度が400°Cを超えると熱ふくらみが発生し、流体（空気）の流路形状が変わります。このような強い連成現象を捉えるのがCHTの本質です。

数学的には一つの連立方程式系として扱います。領域を流体（f）と固体（s）に分離して離散化すると、以下のようなブロック行列形式で表されます。

最も基本的な条件は二つです。第一に温度の連続性：

ソフトウェア内部では「マルチフィジックス結合」のフレームワークを用います。例えばCOMSOL Multiphysicsでは、各物理場の弱形式を統合した単一のヤコビアン行列を構築します。一方、Ansys Fluentのような分離型ソルバーでは、流体と固体の領域を別々に解きながら、界面条件を各反復ステップで更新する「パーティションド（分割）結合」手法を採用しています。後者の場合、固体側の熱伝導方程式は、流体ソルバー内でFVM（有限体積法）で離散化されることが多いです。

いいえ、収束するまで繰り返します。典型的なワークフローはこうです：1. 流体方程式を数反復（例えば5回）解く。2. 得られた界面温度・熱流束を固体領域に渡す。3. 固体の熱伝導方程式を完全に解く。4. 固体側の界面条件を流体側に渡す。この1〜4を、界面での熱流束の残差が、例えば1e-06 W/m²以下になるまで繰り返します。この「外ループ」の収束性を高めるため、SIMPLEアルゴリズムと同様の緩和係数（0.5〜0.8）が設定可能です。

ソフトウェアによります。Abaqus/StandardとCFD（Fluent/Star-CCM+）を共役させるCo-simulationでは、メッシュが非一致でも、インターポレーションでデータを転送します。しかし、Ansys Fluent内の「固体領域」機能やSiemens Star-CCM+の「共役熱伝達」モデルでは、界面でメッシュを一致させる（コンフォーマルメッシュ）ことが推奨されます。非一致メッシュを使う場合、熱流束保存性を担保するための特別な補間手法（GGI: General Grid Interfaceなど）が必要で、計算コストが約5〜10%増加します。

まずは「CHTが必要かどうか」の判断です。無次元数であるビオ数

界面近傍のメッシュ解像度が全てです。固体側では、急峻な温度勾配が生じる界面から少なくとも3〜5層の境界層メッシュ（インフレーションレイヤー）を貼ります。その厚さの目安は、熱浸透長さ

残差の監視だけでは不十分です。必ず監視すべきは「界面での正味の熱流束」です。流体から固体への流入熱流束と、固体から流体への流出熱流束（計算上は符号が逆）の差を監視し、これが計算領域全体のエネルギー収支誤差（例えば0.1%以下）に収まっていることを確認します。また、代表点（固体内部のホットスポット、界面の一点）の温度履歴が定常状態に達しているか、時間変化をプロットして確認します。Ansysでは「Surface Report」の「Heat Transfer Rate」、Star-CCM+では「Interface Flux Balance」レポートを使います。

アーキテクチャの根本的な違いがあります。Ansysは「Fluent」内でFVMベースの流体と固体を統合的に解く方式が主流です。一方、Abaqus（FEM）とFluent（FVM）を連携させる「Co-simulation」では、MPI通信で各ソルバーを並列実行し、定期的に界面データを交換します。これはエンジンマウントなどの複雑な構造熱応力解析に強い。Siemens Star-CCM+はFVM一本槍で、流体・固体・電磁場まで全てを同一のFVMフレームワークで解く「マルチフィジックス連成」を標榜しています。COMSOL MultiphysicsはFEMベースで、全ての物理場を単一の連立方程式系として定式化・求解する「完全連成」アプローチです。

大きく違います。一般的に、単一コードベースでメモリ内で連成するFluentやStar-CCM+は、データ転送のオーバーヘッドが少なく、大規模並列（1000コア以上）でのスケーリング効率が高いです。特にStar-CCM+は独自の並列化技術に強みがあります。Co-simulation（Abaqus+Fluent）は、二つのソルバー間のデータ交換（通常1タイムステップ毎）がボトルネックとなり、並列効率が落ちる傾向があります。COMSOLの完全連成は精度が高い反面、ヤコビアン行列が巨大化・密化しやすく、直接法ソルバーが必要になる場合があり、メモリ消費と計算時間が課題になります。ベンチマークでは、1000万要素の問題で、FluentのCHTはStar-CCM+より約15%高速だったという事例があります（ハードウェア依存）。

オープンソースでは可能です。OpenFOAMの`chtMultiRegionFoam`ソルバーは、FVMベースのCHT解析を可能にします。ただし、前処理（メッシュ作成、境界条件設定）や後処理が商用ソフトに比べて手間がかかります。また、CalculiX（FEM構造ソルバー）とElmer（マルチフィジックスFEMソルバー）を組み合わせる方法もあります。商用では、Autodesk CFDが比較的低価格でCHT機能を提供していますが、乱流モデルや複雑な物理モデルの豊富さでは上位ソフトに劣ります。まずはOpenFOAMで学術的なベンチマーク（例えば、T型管でのCHT）を試すのがコストパフォーマンスに優れています。

最も多い原因は、流体と固体の「熱容量の不一致」と「タイムスケールの違い」です。固体（例えば鋼）の熱拡散率

その警告は、数値的な誤差が許容値を超えていることを意味します。原因は主に3つ。1. メッシュの非一致：界面でメッシュが一致しておらず、補間誤差が大きい。GGIなどの保存的補間を適用するか、メッシュを一致させてください。2. 収束不足：外ループ（流体←→固体の反復）が十分収束する前に計算を止めている。界面熱流束の残差履歴を確認。3. 境界条件の見落とし：固体側で発熱（ジュール熱など）を設定しているのに、流体側のエネルギー方程式にそれに対応する項（例えば放射）がないなど。まずは、発熱も外部熱流束も一切ない、単純な定常熱伝導問題で、解析解と比較して界面バランスが取れるか検証すべきです。

それは「数値振動」または「条件付き安定」の問題です。特に陽的解法や、Co-simulationでデータ交換間隔（Coupling Frequency）をタイムステップより粗く設定している場合に起こります。例えば、流体のタイムステップが1e-4秒、データ交換間隔が1e-3秒だと、流体が10ステップ進む間に固体は古い境界条件のままです。これが不安定性を生みます。対策：1. データ交換間隔を流体タイムステップと一致させる（「毎ステップ交換」）。2. 暗解法（Implicit）を使用する。3. 固体と流体で異なるタイムステップを使う「サブサイクリング」をオフにしてみる。Star-CCM+では「Implicit Coupling」オプションを有効にすることで、この問題を軽減できます。

これは重大な並列化の落とし穴です。CHTでは、界面を構成するセル/面が、異なるプロセッサ（CPUコア）に分割されてはいけません。なぜなら、界面条件の計算には両側（流体と固体）の情報が同一メモリ空間内に必要だからです。対策：プリプロセッサで「インターフェースをまたがない」ように領域分割を設定します。Ansys Fluentでは「Mesh/Partition/Domain」で、インターフェースを`boundary`として指定してから分割します。Star-CCM+では「Partition Surface」を使用して界面を保護します。自動分割を使う場合、このチェックを必ず行ってください。これが原因で、界面熱流束が局所的に2倍や0になるという誤差が生じます。