5/31の関西勉強会にて表題の発表（発表資料はこちら）をして以来、少々間が空いてしまいましたが、ようやくほぼ完了して、ここにケースファイルを公開（ダウンロードはこちらから、使用法説明は本記事の一番下）することとしました。
関西の勉強会で指摘のあった点を含め、具体的には以下の３点を検証、
- lowWeightCorrectionの効果
- 擬似開口部の境界条件
- implicitFeatureSnapの効果
加えて、オープンCAE学会の講習会準備に時間をとられて公開が遅れました。
lowWeightCorrectionの効果
このオプションは、Non-Conforming AMI Patches として、OpenFOAMのヴァージョン2.3.0以降新たに導入されたもので、 cyclicAMI境界で、AMI: Patch source/target sum(weights)（パッチ間を補間する為の重み係数のようなもの）が所定の値を下回った場合に、zero-gradientの条件を適用してしまおう、というものです。
これがない従来の計算ではたちどころに異常終了していた事に比べれば、ごく一部にそういう処理を施したところで、誤差の影響の及ぶ範囲は狭いので大丈夫だろう、という考え方に基づくものです。
基礎メッシュとしてm4マクロで作成したblockMeshを用いた例で、一部手作業で計算を継続させていた部分（発表資料の39ページ）があったのですが、このオプションを使えば、そういう手間は必要でなかったんじゃないかという指摘でした。
実際に確認したところ、まさにその通りでしたので、ついでに他のケースで計算が出来なかったケースについても再検証してみました。
結果を以下の表に示しますが、上の表は、通常（単純な直交六面体）の基礎メッシュをベースにsnappyHexMeshでメッシュ作成したもので、下の表は、m4マクロを用いて、回転領域に適合させた基礎メッシュを用いたものです。いずれも、lowWeightCorrectionを有効にすることで、大幅な改善効果が見られました。 
なお、表中の○は計算が可能、✕は計算が不能、△は前述の手作業で可能、であったことを示します。また計算時間は、現象時間の0.1秒分（丁度1回転するのに要する時間）を計算するのに要した時間であり、4並列計算で実行したもので、計算モデルとしては、以下の擬似開口部を設定して計算したものです。
擬似開口部の境界条件
今回のケースでは、対象の計算領域が密閉構造となる為、圧力基準点を設定してやる必要がありましたが、これを通常のpRefCell や、pRefPointで設定すると、それらの場所のとり方次第で、計算性能（とくに並列性能）が大きく劣悪化するという問題があり、これを回避するのに、小さな開口部を設けてそこで圧力一定条件を適用してやれば問題なさそう（発表資料のp.14〜18）・・・ということでした。
ちなみにこの時の境界条件は以下のようにしておりました。
開口部は表中赤枠で囲った部分、パッチ名はoutletとし、圧力（p_rgh）を固定値として、その他はすべてzeroGradientです。
とはいえ、これだと開口部を設けることで、微少ながらも実際に流出入が生じてしまうことになり、その流量を気にしながら計算結果をチェックする必要があり、あまり気持ちの良いものではありません。ならばということで、圧力以外のzeroGradientを止めて、以下のようにする。
つまり、stator と同様、圧力以外は、単純なすべり無し壁と同じ条件にしてしまったらどうか？ という点です。
結果は、それでもちゃんと計算できて、流れ場の状態は当然同一にはなりませんが、どちらが良い/悪いの区別できるものでもありませんでした。
以下に計算時間の推移を示します。
赤色は「流入出有り」の計算で、緑色は「すべり無し壁条件」の計算です。横軸はSimulationTimeですが、0.1秒で、丁度１回転することになります。0.06秒あたりで、少しの間計算速度の違いが見られますが、そこを除けば、ほぼ同一の速度です。
当初は、「すべり無し壁条件」＝「密閉空間」なので、こちらが遅くなるのではないかと懸念してましたが、そんな事もないようです。
「流入出有り」の計算で、実際の流量をモニターした結果を以下に示しますが、0.06秒あたりでの計算速度低下を説明できるとは言い難い結果でした。
結局、まぁ良く判らないけど、「すべり無し壁条件」で、圧力だけを規定する・・・で良さそうです（公開ケースファイルは、これで作成してあります）。
implicitFeatureSnapの効果
前述の発表資料のp.4に記してあるように、本件では、implicitFeatureSnapを使うこと（true）を採用しましたが、本件とは別の事例で効果を確認したところ、その場合は逆の傾向（使わない false のほうがメッシュ品質が良好であった）が見られました。
そこで、本記事では再度計算をやり直し、定量的な比較を試みました。
当初の見立ては、以下のメッシュ図によるものでした。
特に、突起の根本部において、明らかな違いが見られました。
一方、回転領域の境界面は、下のようになっており、違いはあるものの、どちらが良いとは判断しかねます。
そこで、前述の発表資料中にもあった、AMI: Patch target sum(weights) min/max/averageを調べてみました。
こうして見比べると、確かに違いがわかります。falseとすると、特にminの値が0になる状態が頻出するので、当初の、lowWeightCorrectionを使わない計算ではたちどころに異常終了することとなり、trueを採用したということでした。
しかしながら、lowWeightCorrectionを使えば、これでも計算は可能になったので、以下に計算時間を比較しました。
横軸はSimulationTimeですが、0.1秒で、丁度１回転することになります。計算の終盤になって、やや違いが生じてきましたが、期待（？）の程には差が出るものではないようです。流れ場の状態も、当然同一にはなりませんが、どちらが良い/悪いの区別できるものでもありませんでした。
結局、implicitFeatureSnap true/false は、さほど重要なファクターでなさそう、ケースバイケースだと思っておくのが良い・・・ということでしょうか。
最後に
lowWeightCorrectionの効果は絶大で、これから新しくcyclicAMIを使った回転体解析をやるのであれば、必須アイテムです。そういう意味で今回の公開ケースはこれを利用可能な、OpenFOAM-2.3.0以降に対応するものです。これ以前のヴァージョンで実施するにはPropertyファイルや、成分名の命名方法を変更する必要があります。その改造はさほど困難でないのですが、再整備する手間もままなりません。ご要望が多ければ・・・ということで。
おまけ
先の勉強会にて、ほぼ同程度のメッシュ規模の計算結果をアニメーション表示するのに、ボリュームレンダリングはさほど困難でない・・・という紹介があったので、ここでもやってみました。
ちなみに、下の動画が、これまで勉強会などで紹介してきたもので、alpha.waterをスレショルド表示させたものです。
アニメーションの総コマ数は500でしたが、製作時間が従来の方法で約10分、今回のボリュームレンダリングで約40分と、確かにまぁ、許容レベル内といったところでしょうか。
ケースファイルに関する説明
以下のように、m4Snappyと、normalSnappyという２つのフォルダに、それぞれ２つのケース（全密閉構造タイプと、擬似開口部を設けたタイプ）が収納してあります。各々のケースファイルにはAllrun スクリプトが同梱してあり、自動実行できるようになっています。また、Allcleanスクリプトで最初からやり直しする事もできます。
m4Snappyケースで、Extend blockMesh を利用できる場合には、Allrunスクリプト中、以下の部分を選択使用する（13行目と14行目を使い分ける）だけです。
また、メッシュの細分化レベルは、各ケースの system/snappyHexMeshDict を変更して使って下さい。解凍したままの状態では、もっともメッシュ数を少なくして計算できるパラメタにしてあります。