メッシュの生成

[H.Y]

初めましてOpenFOAM超初心者のH.Yです。

メッシュ生成がうまく行かず、投稿させていただきました。

 

Windows7のBlender2.60でモデルを作成し[ File > Export > Stl（stl） ]で保存し

VMware Player5.0.0のLinux（Ubuntu 12.04）のNetgen4.9.13にて[ File > Load Geometry... ]

という手順でSTLファイルを読み込もうとすると、なぜか勝手にNetgenが閉じてしまいます。

 

読み込めない原因として何が考えられるでしょうか？

 

初歩的な質問で申し訳ございませんが、よろしくお願いします。

 

[E.Mogura]

E.Mogura です

Blender　でSTLで保存する際に、

ascii　にチェクマーク付けましたか？

デフォルトだとバイナリ形式で保存され、

これだとNetgenで認識できません。

2012年9月20日 10:12 H.Y <ca0...@cc.it-hiroshima.ac.jp>:

--
このメールは Google グループのグループ「OpenFOAM」の登録者に送られています。
このディスカッションをウェブ上で閲覧するには、https://groups.google.com/d/msg/openfoam/-/P8h3F2LKmcYJ にアクセスしてください。
このグループに投稿するには、open...@googlegroups.com にメールを送信してください。
このグループから退会するには、openfoam+u...@googlegroups.com にメールを送信してください。
詳細については、http://groups.google.com/group/openfoam?hl=ja からこのグループにアクセスしてください。

[H.Y]

 

E.Mogura様、返事ありがとうございます。

 

ご指摘通り、asciiにチェックマークを付ける事により、Netgenで読み込む事ができました。

ですが、その後さっそく[ Generate Mesh ]を行うと、また勝手にNetgenが閉じてしまいました。

メッシュを生成できない原因として何が考えられるでしょうか？

 

また、根本的にNetgenの使い方をよく知らないのですが、参考になる資料やサイトなど教えていただけると助かります。

 

アドバイスお願いします。

 

[E.Mogura]

E.Mogura です。

[ Generate Mesh ]を行なって勝手にNetgenが閉じるということなんですが、

あっという間に閉じるのか、それともメッシュ作成＆表示は開始するんだが、途中まで行って閉じてしまうのか、

どちらなんでしょう？

前者だとすれば、STLの整合性をcheckして下さい。

（Geometry  -> STL Info)

実際の製品CADデータなどからエクスポートしたSTLの場合、

整合性はOKでも、後者の状況で落ちるのはよくあることです。

余談ですが、Netgenを素のままで使うと、そういうことが良くあるせいか、

Salome　とか、enGrid　とかをベースに　netgen をメッシュ作成エンジンとして

使用する人が多いみたいです。

2012年9月20日 17:33 H.Y <ca0...@cc.it-hiroshima.ac.jp>:

 

--

このメールは Google グループのグループ「OpenFOAM」の登録者に送られています。

このディスカッションをウェブ上で閲覧するには、https://groups.google.com/d/msg/openfoam/-/GCZZmhQu8M4J にアクセスしてください。

[H.Y]

 

E.Mogura様、ご返答ありがとうございます。

 

あっという間に閉じてしまうので、前者です。

STLの整合性をcheckした結果。

 

 

 

NO STL-Triangles : 40

Geometry:

X =   -2 -      2

Y =   -1 -      1

Z = 　 0 -    24

Consistency Check = 0

 Status: ERROR

 

 

 

と、表示されました。

 

根本的に、自分の作成したモデルに問題があったのではと思ったので、作成したモデルを添付します。

モデルは煙突状の柱に、風穴がいくつかある物を作成したつもりです。

 

一部の壁面に熱を与えると中の空気がどのように動くか…

ということを行う予定です。

 

>余談ですが、Netgenを素のままで使うと、そういうことが良くあるせいか、

>Salome　とか、enGrid　とかをベースに　netgen をメッシュ作成エンジンとして

>使用する人が多いみたいです。

 

参考にさせていただきます。

SalomeやenGridについても少し勉強してみようかと思います。

ありがとうございます。

 

 

[E.Mogura]

E.Mogura　です。

Netgenでメッシュ作成したい場合は、流体部分をSTL化する必要がありますが、これは壁のSTLファイルでしたね。

基本的なところで「問題あり」です。

仮に流体部分をSTL化したところで、風穴部分をどうやってNetgen上で識別するかという問題もクリアーせねばなりません。

⇒　blenderをお使いということであれば、SwiftBlockというプラグインを使うことがお勧めです。

作成サンプルを、

http://mogura7.zenno.info/~et/wordpress/ocse/?p=586

にアップしておきました。

製作に要した時間（モデル作成からメッシュ作成・確認まで、説明資料の作成時間は除く）は３０分とかかりませんでした。

2012年9月20日 23:22 H.Y <ca0...@cc.it-hiroshima.ac.jp>:

 

 

--

このメールは Google グループのグループ「OpenFOAM」の登録者に送られています。

このディスカッションをウェブ上で閲覧するには、https://groups.google.com/d/msg/openfoam/-/3nzZZpj5lv8J にアクセスしてください。

[H.Y]

 

E.Mogura様、ご返答ありがとうございます。

 

作成サンプルを参考にさせて頂いております。

 

Swiftツールをインストールし、『blockMeshDictの作成』までは無事に進めたのですが。

『blockMeshの作成』に

 

 

作成方法は「省略」というか、blockMesh コマンドを叩くだけ

nPoints: 1636362　nCells: 1574400

 

という記述でしたが、どこに叩けば良いのでしょうか？

初歩的な質問ばかりで申し訳ありませんが、よろしくお願いします。

 

[E.Mogura]

E.Mogura です

blockMesh　というのは、

OpenFOAMを使うのであれば、

基本中の基本といってよいコマンドなんですが・・・

端末上で、ケースフォルダ（例題の場合は tower ）の下に移動して。

blockMesh　と打ち込んで　Enterキーを押す

但し、その端末でOpenFOAMを使える環境であることが前提です。

2012年9月24日 11:17 H.Y <ca0...@cc.it-hiroshima.ac.jp>:

 

--

このメールは Google グループのグループ「OpenFOAM」の登録者に送られています。

このディスカッションをウェブ上で閲覧するには、https://groups.google.com/d/msg/openfoam/-/eOxGuEPQF1QJ にアクセスしてください。

[H.Y]

お久しぶりです。H.Yです。

風穴のある柱状構造の非圧縮、乱流の熱流体解析を行いたいと考えております。
今回は柱状構造内部だけでなく、外部の気流も含めて解析したく、モデルを作り直してみましたので、モデルを添付します。

前回、柱状構造物の横のroofだった場所はフロア分けされた構造物内と繋がり、上部のroofだった場所は外部と繋がっています。

ひとまず、柱状構造物の上内部に温度を与え、温度差のみで気流の動きを見ようと考えています。

風穴のある柱状構造とSwiftSnap and SwiftBlock, GUIs for OpenFOAM’s meshersを参考にし、、blenderで作成しSwiftBlockとSwiftSnapを定義したモデルにてblockMeshDictとsnappyHexMeshDict、triSurfacesデータを自動作成しsnappyHexMeshの作成を行うと下記の通り表示後、計算が進まなくなります。

--------------------------------------------------------------------------
mpirun noticed that process rank 0 with PID 5565 on node XXXXXX-desktop exited on signal 9 (Killed).
--------------------------------------------------------------------------

SwiftBlockやSwiftSnapの定義を間違えているのでしょうか？

また、サーバールームの熱流解析のように内部と外部を分けて作成し、結合した方が良いのでしょうか？

アドバイスをお願い致します。

2012年9月25日火曜日 12時44分03秒 UTC+9 E.Mogura:

[E.Mogura]

E.Mogura です

このエラーメッセージだけでは、並列計算が破綻しているということがわかるだけで、

もう少し詳細なメッセージがないと、原因を推定しようがありません。

なお自分が作成した例題では、blockMeshだけでメッシュを作成することを

想定しており、H.Yさんが、それに加えてsnappyHexMeshあるいは、

SwiftSnapでどういう使い方をされているのかという情報もないので、

どうにもコメントできません。

モデル添付とありますが、添付ミスなんでしょうか？

2012年11月13日火曜日 17時05分24秒 UTC+9 H.Y:

[H.Y]

添付ミスでした。

こちらに添付し直すので、よろしくお願いします。



2012年11月13日火曜日 17時50分17秒 UTC+9 E.Mogura:

[E.Mogura]

E.Mogura　です

モデルを確認しましたが、直方体が１つあるだけです。

しかも、バイナリエクスポートされたstlファイルのようで、

表示はできても編集がままならない。

⇒これで間違いありませんか？

2012年11月13日火曜日 23時16分24秒 UTC+9 H.Y:

[H.Y]

度々申し訳ありません。
添付がうまくいかなかったので、下記URLの［データ便〕よりモデルデータ（ST.5.G.Swift.blend）を落とし、確認していただけないでしょうか？

https://www.datadeliver.net/receiver/file_box.do?fb=0665ceba137040c5a725c7434e5b557c&rc=f9635724c03d4163a8305af243d0d47e&lang=ja

よろしくお願いいたします。

2012年11月14日水曜日 5時40分12秒 UTC+9 E.Mogura:

[E.Mogura]

E.Mogura です。

モデルを確認しました。

建物の窓などの開口部を除いて、

壁の厚さを考慮してSTL化したということですね。

SwiftSnap、SwiftBlockの設定も問題ないようで、

自分の環境ではすんなりメッシュを作成できました。

（単体計算）

Layer mesh : cells:1100494  faces:3553523  points:1354088

Cells per refinement level:

    0 1030

    1 4680

    2 26978

    3 92694

    4 975112

Writing mesh to time 3

Wrote mesh in = 49.5 s.

Layers added in = 49.5 s.

Finished meshing in = 650 s.

End

H.Yさんのエラーは、

並列計算のメッセージだったので、まずは単体計算で確認下さい。

2012年11月17日土曜日 10時27分57秒 UTC+9 H.Y:

[H.Y]

 お久しぶりです、HYです。

 

前回までやってたので、もっと簡略化したもので今シミュレーションを行っています。

 

http://mogura7.zenno.info/~et/wordpress/ocse/?p=586

上記のサイトで作っていただいたモデルを参考に熱を与えたい場所も別に識別できるようにモデル化しました。

 

『OpenFOAMの実践的活用演習』の「演習２　標準チュートリアルのスタディ」を参考にcaseファイルをつくりました。

 

DEXCS2012の十徳ナイフにてsolverを起動したのですが、うまく行きません。

 

--> FOAM FATAL IO ERROR:
keyword defaultName is undefined in dictionary "/home/ca08059/Desktop/SCtest7.2/0/p::boundaryField"

file: /home/ca08059/Desktop/SCtest7.2/0/p::boundaryField from line 25 to line 70.

    From function dictionary::subDict(const word& keyword) const
    in file db/dictionary/dictionary.C at line 461.

 

下記に自分の作ったcaseファイルを載せますので、見て頂けないでしょうか？

https://www.datadeliver.net/receiver/file_box.do?fb=77bd91ed4d414024aba0d35e618f0f1d&rc=c3fd8152633248f0b66c739e507450d6&lang=ja

 

また、DECXSランチャーにて自分の作ったケースファイルのようにsnapyyHexMeshDictを扱わない物の解析を行う事は出来ないのでしょうか？

 

[E.Mogura]

E.Mogura です。

エラーメッセージの示す通り、

p　の境界条件定義の中で、defaultName　というpatchが存在しないことが原因です。

但し、このdefaultNameというpatchについては、

constant/polyMesh/boundary の中で、

（途中省略）

12

(

    defaultName

    {

        type            wall;

        nFaces          0;

        startFace       22834;

    }

    SC

    {

        type            wall;

        nFaces          2494;

        startFace       22834;

    }

    CS

（以下省略）

のように定義されている。

つまり、nFaces が0だから、実体がないのに、

名前だけが定義されている。。。に過ぎないので、

これを削除してしまっても構いません。

（削除すれば動くようになります）

削除の方法は、この

constant/polyMesh/boundary を以下のように、

（途中省略）

11

(

    SC

    {

        type            wall;

        nFaces          2494;

        startFace       22834;

    }

    CS

（以下省略）

直接変更してもよいし、

DEXCS2012をお使いであれば、

TreeFoam(+十徳ナイフ）のgridEditorにて、

対応行を選択して右クリック「patch削除」で可能です。

あと、DECXSランチャーを使って計算したい、

ということであれば、

DEXCSの解析ケースを作成するとexeフォルダ

に隠しファイルとして、

.dexcsSolver

というファイルがあり、

ここでソルバーの名前を定義するようになっています。

なので、ここで所望のソルバー名を記述しておけば、

所望のソルバーを起動できるようにはなります。。。

が、systemやconstantフォルダの内容を

ソルバーに応じた内容に変更する必要はあり、

それを完全手作業でやるならともかく、

その作業は引用のあった演習３で示すように、

TreeFoam(+十徳ナイフ）を使ってやるのが断然お勧め。

ならば、そのままTreeFoam(+十徳ナイフ）

上で実行すれば良いのでは？

ということで、DEXCS2012では、

DEXCS2011で出来ていたソルバー変更機能を

メニューから削除したというのが舞台裏事情です。

2013年1月13日日曜日 13時48分50秒 UTC+9 H.Y:

[H.Y]

ご返答ありがとうございます。
指摘いただいたとこを修正することで、無事に計算は行われました。
今後はTreeFoamを中心に進めて行きたいとおもいます。

ですが、シミュレーション結果の各階流入口の風速や風量の数値をどのようにすれば見れるのかわからず、また投稿させて頂きました。

下記にケースファイルを添付します
https://www.datadeliver.net/receiver/file_box.do?fb=9598a8f1e78640eaab4460996e5ed83a&rc=2640c834e88d453c93b2497a4f6cc859&lang=ja

ちなみに、シミュレーションは下記の鍋島らの論文と似たような事をしようと考えています。
http://ci.nii.ac.jp/naid/110007980944

どうか、よろしくお願いします。



2013年1月13日日曜日 14時53分52秒 UTC+9 E.Mogura:

[E.Mogura]

E.Mogura です。

ケースファイルを拝見しました。

質問

＞各階流入口の風速や風量の数値をどのようにすれば見れるのか

に対する回答としては、paraFoamにて、MeshPartsのところで、internalField でなく、所望の境界面を選択すれば、その面内の分布を見れるようになります。

また、それぞれの面全体での総和を計算するなどは、controlDict中に、functionを定義して経時的に数値出力させることも可能ですが、これらはDEXCS/template/exe/system/controlDict 中にサンプルがあるので、これらを参考に使用して下さい。

なお、ケースファイルを少し動かしてみた感触ですが、このままの設定では合理的な解に収束しそうにありません。

一番大きな原因は、流入口と流出口のすべての境界条件が、

    type inletOutlet;

になっていることで、これだと建屋から流出するだけで、流入出来ないということになって、そもそも不合理ですよね？

あと、乱流パラメタの初期値の合理性をチェックすることや、それでも駄目なら緩和係数を調整するといったことが必要になると思います。

 

2013年1月28日月曜日 8時35分46秒 UTC+9 H.Y:

[H.Y]

ご親切な態様、ありがとうございます。

指示通り直したつもりですが、結果は自然現象と異なった計算結果になりました。
つまり、1階より4階が多くの風量が出ています。
原因がわからなく困っています。
以下のファイルを見ていただけないでしょうか。
https://www.datadeliver.net/receiver/file_box.do?fb=44cfddfff0f04c6aa5753a946176a1f6&rc=cac0ddc1c27d4ed781351545a47fde35&lang=ja
よろしくおねがいします。

2013年1月28日月曜日 10時53分03秒 UTC+9 E.Mogura:

[E.Mogura]

E.Mogura です

ケースファイルを拝見しました。

⇒いくつか問題がありました。

（１）重力の方向

    value           ( 0 -9.81 0 );

                    ⇒      ( 0 0  -9.81);

（２）outletの温度が

        type        fixedValue;

        value       uniform 293;

これでも実害はないかもしれないが、流出境界であることを意図するなら、zeroGradientとしておいたほうがわかりやすい。

（３）先のメールにも書きましたが、

開口部の流速条件がすべて、

        type        inletOutlet;

        inletValue  (0 0 0);

        value       uniform (0 0 0);

となっていたが、これだと流入できない。

本来、zeroGradientにしたいところで、変更して少し計算してみたのですが、たしかに少々厳しいところがあったので、せめて流入口となる部分は、

        type        outletInlet;

        outletValue uniform (0 0 0);

        value       uniform (0 0 0);

としておく。

（４）p_rgh　を、全開口部で

        type        fixedValue;

        value       uniform 0;

としてしまっているので、この拘束が強すぎる。４階の方が強く出るのはこれが原因かと推察されます。つまり、４階以下には壁の温度差がないので、流れを起こそうとする駆動力も存在しないことになる。上部から温度差のある空気が流入した時に生ずる圧力変化を成り行きで振る舞えるようにしてやらないと、流れも成り行きで振る舞えない。この圧力の制限で流れの勢いが静められてしまっていると推察しました。

そこで、全開口部を、

        type        buoyantPressure;

        rho         rhok;

        value       uniform 0;

としたかったのですが、それだと計算を始動できない。とりあえず、１階の開口部だけを、fixedValueにすることで、なんとかそれらしい流れになってくれそうな気配ですが、落ち着くまでかなりのイタレーションが必要のようです。

2013年1月28日月曜日 20時17分44秒 UTC+9 H.Y:

[H.Y]

事細かく、丁寧なご説明ありがとうございます。
指摘していただいた通り、修正し（SCtest01.1）動かしてみたところ、それらしい流れになってきました。
ですが、outlet1の値を見たところ、想像以上の逆流が起きていました。

次に自分なりにパッチを書き換え（SCtest05.1）動かしてみたところ、またそれらしい結果が見えてきました。

U
流入口部を

　　 type        pressureInletOutletVelocity;

        value       uniform (0 0 0);

流出口部を

        type        inletOutlet;
        inletValue  (0 0 0);
        value       uniform (0 0 0);

に変更し

p_rgh
流出口部を

        type        fixedValue;
        value       uniform 0;

流入口部を

        type        buoyantPressure;
        rho         rhok;

        value       uniform 0;

に変更しています。

しかし、自分は使用したパッチの意味をあまり知らず使ってしまっているため、助言を頂きたく投稿しました。

以下のファイルを見ていただけないでしょうか。

SCtest01.1
https://www.datadeliver.net/receiver/file_box.do?fb=f349bd5b3e9e4b18aca5d666b08504d6&rc=17121bb8160444d6b41f94d526d50b21&lang=ja

SCtest05.1
https://www.datadeliver.net/receiver/file_box.do?fb=6068394535c14a8fbff331bcd47b0f34&rc=c20ae107033d45b98541e992db3186f5&lang=ja

よろしくお願いします。

2013年1月29日火曜日 18時23分11秒 UTC+9 E.Mogura:

[E.Mogura]

E.Mogura です。

いろいろたてこんでおり、回答が遅れました。

ケースを拝見しました。

ある程度安定して計算できているという点で「それらしい流れ」になっているようには見えますが、流速の大きさが１０の１０乗を超えており、非物理解を探しに行ってしまっています。

考えられる最大の原因は、乱流変数です。とくに流入口で、

zeroGradient

となっており、epsilonが定まらない（0が入る）と、とんでもない結果になってしまいます。

ちなみに、

        type        turbulentMixingLengthDissipationRateInlet;

        mixingLength 0.1;

として計算しようとしてみましたが、こうすると、これはこれですぐ発散して、安定に計算できない。

初期値や、緩和係数の調整で計算できるようになる可能性もあるかとは思いますが、、、

もう一つの手としては、計算の初期では乱流計算をしないでおいて、ある程度流れ場が出来たら、乱流計算をオンにするというやり方。いちおうこれで、物理的におかしくない速度範囲内で、ある程度の安定解にはなってくれました。但し、初期残渣がなかな減らない。時々暴れる、などあるので、やはり初期値やその他の境界条件の見直しは必要かも、、、といった感触です。

以上、ご参考まで。

2013年1月31日木曜日 17時56分17秒 UTC+9 H.Y: