AMI境界付近の結果の不連続に関して

[zukki]

こちらで何回か質問をさせて頂いておりますzukkiと申します。

現在、OF-2.1を用いて撹拌容器内の解析を行っております。
その中で、回転領域と静止領域の間をＡＭＩで結合した場合、
添付ファイル（断面の速度場）に示しますように境界付近で値の不連続が生じてしまいます。
1は撹拌容器を横から見た場合の断面図で、上部では問題ないような気もしますが、ロータ横付近では不自然な状況となっております。
2は上から見た、ロータ中心を通る断面図ですが、明らかに境界面（円形）のところで不連続が生じております。
何らかの設定が問題で解析もうまくいっていないのか、見た目だけの問題で、この程度は仕方ないのか分かりかねている状況です。

本解析はテストケースのため格子点数が少なく（40万点程度）しておりますが、200万点程度で行った別の解析でも同様の結果となりました。
CFD onlineや本グループにおいて、色々と情報を集め、解決方法を模索したのですが、未だ解決に至らなかったため、質問をさせて頂きました。

以下、解析の手順となります。

1. Gridgenにより回転領域と静止領域を作成し、Fluent形式で出力
2. Fluent形式からOF形式へメッシュの変換
3. 回転領域に対して、setSetで全領域を選択(boxToCell)し、setsToZones
4. mergeMeshesにより回転領域と静止領域を一体化
5. boundary, U, Pなど境界条件の設定
6. MRFSimpleFoam (10000stepまで計算)

となります。なお、AMI領域の格子形状（点数）は両者で全く同じです。
確実な解決方法としては回転領域と静止領域を分けずにひとつのメッシュで作成したものに対して、setSetで領域を決定してやると
このような問題は生じませんが、定常から非定常（pimpleDyMFoam)に移行する際の手順を省くため、領域を初めから２つに分けております。
チュートリアルのpimpleDyMFoam/mixerVesselAMI2Dに対して、試しにMRFSimpleFoamで計算もしてみましたが、このような問題は生じませんでした。
VesselAMI2Dと唯一の違いは、setsディレクトリの中にAMIという名前でFaceSetが定義されており、AMIの領域を指定する必要があるのかとも思い（FaceZonesはない）、試してみましたが、特に変化は見られませんでした。

これは、1.6extでは、FaceZonesを定義する必要があったようですので、このなごりかと考えております。
後は、メッシュをGridgenで作っているというところでしょうか。

 

boundary、Uに関しても念のため、以下に示しておきます。

boundary
    RWall
    {
        type            wall;
        nFaces          11992;
        startFace       996076;
    }
    IR1
    {
        type            cyclicAMI;
        nFaces          9832;
        startFace       1008068;
        matchTolerance  0.0001;
        neighbourPatch  IS1;
        transform       noOrdering;
    }
    RUPart
    {
        type            patch;
        nFaces          3360;
        startFace       1017900;
    }
    IS1
    {
        type            cyclicAMI;
        nFaces          9832;
        startFace       1021260;
        matchTolerance  0.0001;
        neighbourPatch  IR1;
        transform       noOrdering;
    }
    SWall
    {
        type            wall;
        nFaces          12832;
        startFace       1031092;
    }
    SUPart
    {
        type            patch;
        nFaces          2400;
        startFace       1043924;
    }

Ｕ
{
    RWall
    {
        type            fixedValue;
        value           uniform (0 0 0);
    }
    RUPart
    {
        type            slip;
    }
    SWall
    {
        type            fixedValue;
        value           uniform (0 0 0);
    }
    SUPart
    {
        type            slip;
    }
    IR1
    {
        type            cyclicAMI;
        value           $internalField;
    }
    IS1
    {
        type            cyclicAMI;
        value           $internalField;
    }

大変お忙しいところ誠に申し訳ありませんが、
もしよろしければ、皆様方のお知恵をお貸し頂ければ幸いです。

以上、よろしくお願いいたします。

 

 

[zukki]

追記です。

 

アップロードしたファイルですが、そのままブラウザ上で見る（表示）と問題ないように見えますが、

ダウンロードして見て頂いたものが、Paraviewで見たものそのものとなりますので、何卒よろしくお願いいたします。

[ohbuchi]

こんにちは。

Bug Reportを見ると、２月にAMIとMRFを併用するとマスバランスが崩れるバグが修正されている様です。

http://www.openfoam.org/mantisbt/view.php?id=412

最新のものにアップデートして試したらどうでしょうか？

2012年12月20日木曜日 21時26分03秒 UTC+9 zukki:

[zukki]

ohbuchi様

早速の御回答ありがとうございました。
使用しているバージョンは最新のものとなっております。
（ご紹介いただいた2月のバグレポート以降にインストールしております）
説明が不足しており申し訳ありませんでした。

なお、AMIそれぞれの境界面においては、分布は全く同じでした。
境界面を堺として内外第一セルの値が不連続のような状況です。

AMIとMRFの併用にトラブルが過去あったということで、
もしかすると、他のメッシャー使用時にそのようなバグが現在も
残されているのかもしれない気がしてまいりました。

そのため、現在、pimpleDyMFoamにて非定常解析を試すことを検討しております。
ただ、その場合、MRFでの解析結果を使えるかどうか不明のままですので、
もし他に何か解決方法を思い付かれたらご教授頂ければ幸いです。

[ohbuchi]

最新版をお使いで、AMIの各パッチの分布が完全に一致ということは保存則は満たしているという
ことですね。
具体的に、どの変数がどれくらいズレているのでしょうか？
最初に添付されていた図は、速度でしょうか？スケールがないのでズレの程度が解りません。
また、AMIを挟んだ両側のメッシュサイズは、ほぼ一致していますでしょうか？



2012年12月21日金曜日 13時18分33秒 UTC+9 zukki:

[zukki]

ohbuchi様

zukkiです。度々申し訳ありません。

以下、添付致します。

 

mesh.tif：回転領域（赤）と静止領域（青）の格子サイズ

MRF.tif：速度場と圧力場（補完と格子上）

pimple.tif：pimpleDyMFoamでの速度場と圧力場

（10回転程度回転した状態ではあるが、流れ場は落ち着いているよう）

 

速度、圧力場とも境界付近で比較的大きなズレとなっております。

また、メッシュサイズもほぼ同等としております。

pimpleDyMFoamで同じ格子を用いて計算を走らせたところ、まだ途中ではありますが、

境界付近での結果の不連続は生じませんでした。

そう考えると、MRFとAMIの相性がやはり悪いという事になるのでしょうか？

[zukki]

追記です。

上記添付ファイル説明で、pimpleDyFoamにおいて流れ場は落ち着いているようと記載しましたが、落ち着いていないの間違いです。

申し訳ありません。

[S Nakagawa]

nakagawaです。
関連ソルバに関心があり，興味深くディスカッションを拝見しています。

気になったことがあるため，投稿させて頂きます。

　ohbuchiさんからの情報にあったサイトでは，nonRotatingPatches
にAMI面を指定するとの記述がありました。今回のケースでも，指定されていますか？
However, when using AMI with MRF, the AMI patches should be added to
the non-rotating patches in the constant/MRFZones dictionary, i.e. for
your case:
nonRotatingPatches (AMI1_1 AMI1_2 AMI2_1 AMI2_2);

この部分の指定ができておらず，AMI面にも回転の寄与が与えられていることはないのでしょうか？

[zukki]

nakagawa様

 

zukkiです。

大変、興味深い情報ありがとうございます。

 

nonRotatingPatchesには非回転領域のみを指定するとばかり思っており、

ご指摘頂いたように、境界面の追加は出来ておりません。

早速試させて頂きたいと思います。

[ohbuchi]

もう解決済とおもいますが、試してみました。

pimpleDyMFoam/mixerVesselAMI2DをMRFSimpleFoam/mixerVessel2Dの

fvSolution,fvSchemes,controlDictで計算して確認しました。

press.pngはnonRotatingPatchを設定しない場合で、不連続が見られます。

一方、press2.pngは設定した場合で、不連続はありません。

2012年12月23日日曜日 5時45分35秒 UTC+9 zukki:

[zukki]

ohbuchi　様

 

お世話になります。zukkiです。

 

わざわざ、お試し頂きありがとうございました。

私も自分のモデルでnakagawa様からご教授頂きました方法で試したところ、

無事、不連続は発生しませんでした。

 

一点だけ気になる点としましては、収束性が低下した事です。

速度分布はほぼ同じでしたが、圧力分布がAMIを使わない場合と異なりました。

この辺りは、スキームを調整するとうまくいく可能性が十分ありますが、

その点はまだ検討できておりません。

 

現在、一体型メッシュでMRF解析を行ってからその結果を初期値としてマッピングしてから、

非定常解析（pimpleDyMFoam）を行う事も検討しておりますが、

MRF（一体型メッシュ：AMIなし）→pimpleDyMFoam（分割メッシュ：AMI領域追加）へ

マッピングする場合、boundaryの数が異なるためか、マッピングがうまくできていない状況です。

 

ただ、お陰様で、MRF（AMI）で不連続が生じなくなりましたので、

この結果を用いて、pimpleDyMFoamで計算をしようと考えております。

 

もし、上記に関して何か追加の情報などありましたら、ご教授頂ければ幸いです。

[zukki]

お世話になります。
 
以前、質問をさせて頂きました本スレッドの内容に関して、
再度行き詰っておりますので、ご助言を頂ければ幸いです。
 
前回ご助言いただいた内容を受け、現在撹拌槽内（立方体容器）の解析を行っております。
商用のソフトとの比較を行っておりますが、流れ場が、両者で異なる結果となっていたため、
色々と確認をしていたところ、特に上部壁付近で、速度場がおかしな結果となっておりました。
 
前回、AMI領域で不連続となるという件に関して、
MRFZones内のnonRotatingPatchesにAMIのPatchを指定する必要があるということで、
解決致しましたが、上部壁面に近づくにつれて、非連続というか、静止領域と回転領域との間で
流れ場が分断されているような状態となっております。
 
なお、収束状況等に関しては、特に問題はなく、30000stepほど計算が進んだ状況です。
商用のソフトでは5000step程で流れ場は落ち着いております。
撹拌槽下部付近の流れに関しては、比較的商用のものと類似しておりますが、上部にいくにつれて、異なった結果となっております。
上部の速度場から判断するに、静止領域の流れが回転領域に入って行けていない状況です。
そう考えると、境界面が壁になっていると考えるのが妥当ですが、下部では特に問題ないような
流れ場となっておりますので、何が原因か分かりかねている状況です。
なお、境界条件は境界面でcyclicAMI、壁面でnon-slip、上部壁面のみ大気開放を仮定してslipとしております。
 
添付ファイルは攪拌層内の速度分布となっております（上部に行くにつれて不連続）。
境界は半球と円柱を組み合わせたような形で、ひとつの境界として与えております。
以前、商用の解析ソフトで、インターフェースはできるだけ細かく分割して設定した方がよいと言われたことがあり、
もしかするとその影響（半球と円柱部を分けた方が良い！？）かもとも考えておりますので、
念のため、境界を分けて計算することは今後、予定しております。
 
お忙しいところ誠に申し訳ありませんが、皆様方のお知恵をお貸し頂ければ幸いです。
以上、何卒よろしくお願いいたします。

[ohbuchi]

こんにちは。明らかに変な結果ですね。でも、この情報だけでは何が原因かまでは解りません。
５つの断面のカラースケールが一致しているとすると、上壁面近傍が最も流速が早くなっており、なおかつ静止域に
最大流速が存在しています。ミキサーブレードの設置位置が解りませんが、通常は層の中央よりも下部でしょうから
明らかに不自然です。
計算を行った回転数と、計算結果の最大流速はどの位でしょうか？

また、回転領域の形状ですが、回転対称であれば半球面でも問題ないはずです。





2013年2月5日火曜日 14時09分55秒 UTC+9 zukki:

[zukki]

ohbuchi 様

いつもお世話になります。
初歩的なミスでしきい値が一致しておりませんでしたので、
しきい値を一致させた場合の結果を添付致します。
なお、z=0は容器下面、z=1は容器上面となります。
ブレードはz=0.2付近に設置されており、そこからz=1まで
ブレード軸が伸びている形となっております。

やはり、上面に近づくにつれて、境界の不連続が生じております。
まだ、収束に至っていないかという問題もあるかと思われますが、
30000stepまで進んでいることや、上部壁面付近での速度を
モニタリングしていますが、現在はある範囲で振動を繰り返している状態ですので、
これ以上、計算を続けてもおそらく意味はない状況かと思います。

回転数は1000rpmとしております。以下MRFZonesの設定となっております。
なお、IR、ISは回転、静止領域の境界面(AMI）となっております。
RUPartは上部壁面(回転領域）となっております。(RUPartを除いた形でも結果は同様でした）

rotor
{
　nonRotatingPatches (IR IS RUPart);
  origin    origin [0 1 0 0 0 0 0]  (0 0 0);
  axis      axis   [0 0 0 0 0 0 0]  (0 0 1);
  omega     omega  [0 0 -1 0 0 0 0] 104.72;
}

商用のソフトとの違いですが、ブレードがある部分より下の領域はほぼ同様ですが、
上部に近づくにつれて、本計算の場合、大幅に速度が低下している状態となります。
恐らく、上部付近ではAMI領域でうまくデータのやり取りができていないのではないかと考えております。

現在、各種設定を何回も確認しましたが、特に問題なさそうですので（初歩的ミスであれば申し訳ありません）、
とりあえず、上部壁面では壁に回転領域と静止領域がある状態ですので、
ブレード軸を上部壁面まで到達させずに、回転領域を完全に流体中で作った場合に、
どうなるかを検討しようかと考えております。

お忙しいところ申し訳ありませんが、お気づきの点など何かありましたら、ご指摘頂ければ幸いです。

以上、よろしくお願いいたします。

以下、boundary,U,P,k,epsilonとなります。長くなり申し訳ありません。

boundary
(
    RWall  //Blade wall
    {
        type            wall;
        nFaces          11850;
        startFace       6869505;
    }
    Hole  //In blade
    {
        type            wall;
        nFaces          12600;
        startFace       6881355;
    }
    Shaft  //Blade Shaft
    {
        type            wall;
        nFaces          7200;
        startFace       6912195;
    }
    RUPart //Upper wall in rotor region
    {
        type            wall;
        nFaces          5400;
        startFace       6919395;
    }
    SWall  //Stator wall
    {
        type            wall;
        nFaces          33600;
        startFace       6958395;
    }
    SUPart //Upper wall in stator region
    {
        type            wall;
        nFaces          12000;
        startFace       6991995;
    }
    IR   //AMI in rotor region
    {
        type            cyclicAMI;
        nFaces          18240;
        startFace       6893955;
        matchTolerance  0.0001;
        neighbourPatch  IS;
        transform       noOrdering;
    }
    IS   //AMI in stator region
    {
        type            cyclicAMI;
        nFaces          33600;
        startFace       6924795;
        matchTolerance  0.0001;
        neighbourPatch  IR;
        transform       noOrdering;
    }
)


U
boundaryField

{
    RWall
    {
        type            fixedValue;
        value           uniform (0 0 0);
    }

    Hole

    {
        type            fixedValue;
        value           uniform (0 0 0);
    }

    Shaft

    {
        type            fixedValue;
        value           uniform (0 0 0);
    }
    RUPart
    {
        type            slip;
    }
    SWall
    {
        type            fixedValue;
        value           uniform (0 0 0);
    }
    SUPart
    {
        type            slip;
    }
    IR

    {
        type            cyclicAMI;
    }
    IS
    {
        type            cyclicAMI;
    }
}

P
{
    RWall
    {
        type            zeroGradient;
    }
    Hole
    {
        type            zeroGradient;
    }
    Shaft
    {
        type            zeroGradient;
    }
    RUPart
    {
        type            zeroGradient;
    }
    SWall
    {
        type            zeroGradient;
    }
    SUPart
    {
        type            zeroGradient;
    }
    IR
    {
        type            cyclicAMI;
    }
    IS
    {
        type            cyclicAMI;
    }
}

k
{
    RWall
    {
        type            kqRWallFunction;
        value           uniform 0;
    }
    Hole
    {
        type            kqRWallFunction;
        value           uniform 0;
    }
    Shaft
    {
        type            kqRWallFunction;
        value           uniform 0;
    }
    RUPart
    {
        type            slip;
    }
    SWall
    {
        type            kqRWallFunction;
        value           uniform 0;
    }
    SUPart
    {
        type            slip;
    }
    IR
    {
        type            cyclicAMI;
    }
    IS
    {
        type            cyclicAMI;
    }
}

epsilon
{
    RWall
    {
        type            epsilonWallFunction;
        value           uniform 0;
    }
    Hole
    {
        type            epsilonWallFunction;
        value           uniform 0;
    }
    Shaft
    {
        type            epsilonWallFunction;
        value           uniform 0;
    }
    RUPart
    {
        type            slip;
    }
    SWall
    {
        type            epsilonWallFunction;
        value           uniform 0;
    }
    SUPart
    {
        type            slip;
    }
    IR
    {
        type            cyclicAMI;
    }
    IS
    {
        type            cyclicAMI;
    }
}

[ohbuchi]

確かにAMIで運動量が正しく伝わっていない様に見えます。

高さ１ｍということからブレード径は０．１ｍ程度でしょうか？

角速度が１０４rad/sだと周速度は５．２ｍ／ｓ。それにしては各断面の

速度コンタが小さすぎますね。それともブレード径は回転領域よりも

ずっと小さいのでしょうか？

各変数の設定に問題は無さそうです。

どうもAMIパッチが怪しい気がします。フェース数が大きく違いますし。

計算実行時に何かWarningの様なものは出ていませんでしょうか？

2013年2月7日木曜日 16時40分21秒 UTC+9 zukki:

[zukki]

ohbuchi 様

いつもお世話になります。

スケールに関して、詳細をご説明しておらず申し訳ありませんでした。

（なお事情により、こちらの形状データを完全にお見せすることが出来ないことを、お詫び申し上げます。）

容器の大きさは、0.25×0.25×0.3mで、ブレード径は0.065m程度となります。

周速度は3.5m/s程度となります。

 

結果の比較には商用ソフトSTARCCMを用いており、メッシュは完全に同じものを使用しております。

結果がなく申し訳ありませんが、上面付近の速度分布に関して、スケールを同じ（全体において０～最大値）

とした場合、OpenFOAMではOpenFOAMでは真っ青、STARCCMでは、色の変化が目視で確認できます。

もしかすると、OpenFOAMの結果が正解ということも考えれなくもないですが、

OpenFOAMでは上部は流れていないのではと思う状況で、違和感を感じております。

 

AMI領域を分割して計算を行ってみましたが、結果は同じでした。

また、軸を途中で切り、上部壁面まで到達しないようにし、MRFZoneを完全に

流体中で定義してみましたが、結果は変化しませんでした。

 

ご指摘の、AMI領域のフェース数が倍ほど違うのは、メッシュ作成の際に生じたものです。

メッシュ作成段階において、格子数に差が生じたため、このような差となってしまいました。

また、エラーメッセージに関しては、特に何も表示はされておりません。

以下、念のため、開始時のログメッセージを示させていただきます。

 

Create time

Create mesh for time = 22000

Reading field p

Reading field U

Reading/calculating face flux field phi

AMI: Creating addressing and weights between 18240 source faces and 33600 target faces
AMI: Patch source weights min/max/average = 0.999918, 1.00045, 1.00005
AMI: Patch target weights min/max/average = 0.999377, 1.0002, 0.999974
Selecting incompressible transport model Newtonian
Selecting RAS turbulence model kEpsilon
kEpsilonCoeffs
{
Cmu             0.09;
C1              1.44;
C2              1.92;
sigmaEps        1.3;
}

No field sources present

--> FOAM Warning :
From function MRFZones(const fvMesh&)
in file cfdTools/general/MRF/MRFZones.C at line 65
The MRFZones are not run time modifiable
using 'timeStampMaster' or 'inotifyMaster'
for the entry fileModificationChecking
in the etc/controlDict.
Use 'timeStamp' instead.

SIMPLE: no convergence criteria found. Calculations will run for 100000 steps.

Starting time loop

なお、現在は、AMI境界は一旦置いておき、stitchで繋げて計算をかける準備をしております。

また、AMIを使用する場合、pimpleDyMFoamでの検討も視野に入れておりますが、

とりあえずは、定常での確認を行いたいと考えております。

 

色々とお手数をおかけしておりますが、何でも構いませんので、

気になることがありましたら、ご指摘頂ければ幸いです。

 

以上、よろしくお願いいたします。

 

[zukki]

お世話になります。

AMIをやめて、Stitchでメッシュを繋げて計算を行ってみましたが、AMIとほぼ同様の結果となりました。
なお、AMIで見られたような、上部壁面付近での非連続性領域においては、若干結果が異なっておりました。
Stitchにおいて結果が変化しなかったということは、商用のソフトと結果が合わない原因は、
AMIの問題ではないということだと思われます。調査不足で申し訳ありませんでした。

なお、添付ファイルは商用ソフトとOpenFOAMによる攪拌槽上部付近の速度場の比較となります。
なお、OpenFOAMにおいては、スキームも、複数試しております（いずれも、収束性は問題ありません）
上部回転軸付近の流れは、上部に回転軸がありますので、少なくとも軸付近は商用のソフトの結果のように、
軸対称に半径方向に増加していくかと思われますが、OpenFOAMでは、そうはなっていないことから、
MRFZonesの与え方に問題があるような気がしております。

本スレッドの趣旨と外れて参りましたので、これ以上の議論はご迷惑をおかけするかと思いますので、
また、何か新たな結果が得られれば、参考程度にご報告させて頂きたいと思います。

なお、気になる点などありましたら、ご助言頂ければ幸いです。

長々と申し訳ありませんでした。