タグ: snappyHexMesh

motoBikeチュートリアルをcfMeshで実施する方法

先日の勉強会にて発表した表題の資料は、それなりに反響があったようで、アップロード先のslideshareさんからは、初めて下のような「Hot on Facebook」のお知らせを頂きました（こんなものがあるということも初めて知りました）。

範囲を選択_999(194)

 

ここでは、当日およびその後に頂いたコメントに対して検証計算した結果について報告しておきます。

検証内容は、大きく以下の２点です。

ひとつは、当日にakiyamaさんからいただいた、重複面があるモデルであっても、fmsファイルでなく、stlファイルをそのまま使えば出来るんではないか？

そこで…

  • stlファイルを使ってみた（その1）
  • stlファイルを使ってみた（その2）

もう一つは、Twitter上でいただいた下記のコメントです。

範囲を選択_999(195)

但し、このコメントの前半（格子が歪む原因）については、開発者に聞いて下さいとしか答えようがありません。また最後のmeshQuarity制限も何処をいじるのか、あまり思いつくものもないので、ここでは「分割レベル」についての検証で、

  • snappyの細分化レベルを変えてみた
  • cfMeshの細分化方案を変えてみた

結果について、以下記しておきます。

 

 

stlファイルを使ってみた（その1）

FreeCADでエクスポートしたstlをそのまま使う事は、以下の図に示した手順で簡単にできます。

範囲を選択_999(226)

ただこの方法ではFeatureEdges（輪郭線）情報を使わないので、上図、左側のfmsファイルを使った場合と比べると、輪郭線が鈍ってしまいます。

 

stlファイルを使ってみた（その2）

その１の検証で、輪郭線が鈍る件は、akiyamaさんもとっくにご存知で、輪郭線を使うのではなく、patchが分割されていればpatch境界として認識されるはずだというご指摘でした。

そこで、OpenFOAMのチュートリアルに付属のデータ（$FOAM_TUTORIALS/resources/geometry/motorBike.obj.gz）を、以下の図に示す手順で検証してみました。

範囲を選択_999(227)

これで、motorBikeの面が分割されたstlファイルが作れた事になるのですが、問題は、system/meshDict です。分割されたそれぞれの面に対し、レイヤーや細分化指定してやる必要があります（下図赤枠部分）。

範囲を選択_999(229)

solidブロック（patch）が全部で67箇所もあり、ここは面倒な作業になりそうでスクリプトを作ることも考えましたが、とりあえず適当に作ったメッシュのboundaryファイルから、patchリストが簡単に取得できたので、単純なコピペ作業で出来ました。

で、苦労した後の結果ですが…

範囲を選択_999(196)

範囲を選択_999(197)

残念ながら、何度やっても途中で終わってしまいます。やはり、厚みのほとんどない部分で困っているんだろうと推察されます。

 

snappyの細分化レベルを変えてみた

snappyHexMeshでは、patchの平坦部とそうでない部分に対して、細分化のレベルを 変えることが出来ますが、cfMeshは出来ません。そこで比較の土俵を合わせるのに、snappyHexMeshでも一律同じ細分化レベルにしてやってみました（下図参照）。

範囲を選択_999(230)

 

メッシュを以下に比較します。

範囲を選択_999(231)

頭部ヘルメットのあたりで、分割方案による差異が見られますが、メッシュ数の増加はほんのわずかでした。

以下、checkMesh、計算進行状況、ｙ＋の結果もほとんど差異は見られませんでした。

範囲を選択_999(232)

 

範囲を選択_999(233)

 

範囲を選択_999(234)

cfMeshの細分化方案を変えてみた

一方、cfMeshでPatchを指定して局所的な細分化指定を出来ないと記しましたが、minCellSizeパラメタを使って、結果的に局所的な細分化が出来る場合（たとえばDEXCSフォントの例⇒資料の111ページ参照）があります。ここではその方法を使ってみました。

範囲を選択_999(237)

この設定によれば、下図に示すように、MotorBikeGroupの表面で、平坦部とそうでない部分の差異を実現することが出来ます。もっとも、運転者頭部ヘルメットのあたりでは差異が無かったんですが…

範囲を選択_999(238)

それよりも、checkMeshや全体メッシュで大きな構造変化が生じてしまいました。

範囲を選択_999(239)

範囲を選択_999(240)

 

領域全体の隅部で、minCellSizeまで細分化されています。実はかようなケースが、cfMeshに付属の標準サンプルの中にもいくつかあります。先に例示したDEXCSフォントの例では、このような結果にならないのですがね。

cfMeshのオプションパラメタに関する記事の中で述べているminCellSizeについてよく判らない点の一つでもあります。

ま、いずれにせよ、こうなってしまうと、流れ場計算そのものも、すんなりとはいかなくなります。一例を以下に示します。

範囲を選択_999(241)

 

もう少し頑張れば、収束解が得られそうな気もしますが、それを見つけたからといって、意味のない仕事になりそうなので、これ以上は調べておりません。

 

まとめと結論

cfMesh作成に際し、fms形式でなく、stl形式の領域定義ファイルを使用してみたが、板厚が極端に薄い領域を持った（重複面と見做されそうな）データについて境界面を区分するメッシュ作成は出来なかった。⇒やはり重複面と見做されそうな面は単面化の処理が必要。

cfMeshとsnappyHexMeshで、分割レベルの土俵を近づけるべく、それぞれの分割方案を変えたメッシュ作成を実施してみたが、先の結論（cfMeshはsnappyHexMeshと比較して、メッシュ生成時間・checkMesh品質は劣ったが、境界レイヤーは格段に優れていた。）を覆す結果には到らなかった。

 

foamyHexMeshとcfMeshによるメッシュ作成演習

第33回オープンCAE勉強会＠岐阜（夏合宿）で実施した表題の演習テキストとケースファイル一式を公開します。

また、演習に使用したDEXCS2014 for OpenFAOM(R) プロトタイプ版のisoイメージは、製作実費＋アルファ（主にサーバーのメンテナンス費用）で、3，000円の有償販売とさせて頂きますので、ご希望の方は「問い合わせページ」よりお申し込み下さい。

なお、上記演習のうち「swiftツールによるsnappyHexMesh作成演習」以外は、基本的にOpenFOAM-2.3.0以上と、cfMeshがインストールされた環境があれば、同梱のAllrunスクリプトで実行できる（上記 isoイメージが無くとも実施できる）はずなので、興味のある方はお試しください。

 

cfMesh

少し前に表題のツールが公開されたので使ってみました。

結論から言うと、たいへん素晴らしいツールで、次のDEXCS2014 for OpenFOAM には搭載することに決定しました。

いくつかのチュートリアル問題も同梱されており、その試用結果イメージがM.OhbuchiさんのTwitter記事（たとえば、こちら）にも紹介されていたのですが、ここでは新規に作成する場合を想定、 何はともあれ、DEXCSランチャーでの標準チュートリアル問題（DEXCSの3次元フォント周りの流れ解析）にて作成したメッシュを、これまでの方法（snappyHexMesh）にて作成したメッシュとを比較してみました。

範囲を選択_926

また、実際にこれらのメッシュを使ってsimpleFoamで流れ解析した場合の収束状況と、y+についても比較してみました。

範囲を選択_932

snappyHexMeshでは、レイヤーメッシュが不完全で、コーナー部などで欠落し、その部分でy+の値が異常に大きくなってしまっていましたが、cfMeshでは連続的な分布となって、この事からもレイヤーに欠落がない事が確認できます。

ただ１点惜しむらくは、下の図で赤丸で囲った部分で、フォントの形状データがつながってしまっています。

範囲を選択_934

この際に使用した形状データは、stlもしくはftr形式のいわゆる表面形状データです。表面の細分化レベルをもう１段階細かくしてやれば、形状は区別できるようにはなりますが、どうしても対象形状に対して一様に細分化されてしまい、メッシュ数が大幅に増大してしまうことになります。

これに対して、表面データだけでなく輪郭線データを含んだfms形式のデータファイルを入力として使うと、下の図のように局所的な細分化の設定も可能になるようです。

範囲を選択_935

ちなみにこのデータは、今のところ、cfSuiteを使わないと作成できないようです。cfSuiteは有償（金額は不明）ですが、２週間のお試しライセンスがあるので、これを使って作成したものです。

 

詳しくは、来る7/26のオープンCAE勉強会＠富山にてcfSuiteのデモも含めて紹介予定です。

 

 

snappyHexMesh（2.2.x vs 2.3.x）

最新版のOpenFOAM（2.3.x）の標準チュートリアルの全ケースを実行した結果の中から、計算時間が前ヴァージョン（2.2.x）と大きく違ったケースについて検証した結果の第2弾です。

OpenFOAM-2.3.0のリリースノートの筆頭にsnappyHexMeshに関する改良点の記述があったのと、実際にpropellerチュートリアル（incompressive/pimpleDyMFoam/propeller）にて明らかな速度向上（下図参照）が見られたので併せて他のケースも調べてみたのですが・・・結論から先に書いてしまうと、期待はずれ・・・チュートリアルケースのレベルでアナウンスされた効能を確認することは出来ませんでした。

計算時間の比較

 

propellerチュートリアル以外、Dict内容はほとんど同一

propellerチュートリアル以外では目立った速度変化もなかったので、逆に言えば上に見られた速度向上は、snappyhexMeshDict内容の変化に依存した可能性があり、まずはそれを調べた。

範囲を選択_391

snappyhexMeshDict内容の実質的な変化点は上に示した2箇所であり、nFeatureSnapIterの回数が少なくなっている点と、implicitFeatureSnapがtrueになっている点。

そこで、これらのパラメタを変えてメッシュ作成をやり直して、計算時間だけでなくメッシュ品質も併せて結果を比較してみた（下表）。

範囲を選択_393

ここに横方向は、

  • case1 — 2.2.x標準チュートリアル
  • case2 — 2.3.x標準チュートリアル
  • case3 — 2.2.ｘのsnappyHexMeshDictを用いて2.3.ｘで実行
  • case3 — 2.3.x標準チュートリアルにてnFSI（nFeatureSnapIter）の値のみ変更
  • case5 — 2.3.ｘのDictを用いて2.2.ｘで実行

であり、縦方向にはcheckMeshを実行して得られる諸結果を抜粋した。

case1とcase2の標準チュートリアルの比較において、最下行のメッシュ作成時間（２回実行してバラツキも調べた）が短くなったのみならず、（max aspect ratio はやや悪化したものの）メッシュのnon-orthogonalityやmax-skewnessの値においても改善が見られたので、当初の期待は大きかったのですが・・・

細かな数字の違いはあって、その有意差をどう見るかという点はありますが、case1とcase2の変化点（特に赤字部分）に比べると、case1とcase3、case2とcase5の違いはほとんど無い・・・といって良いんじゃないでしょうか。また、case4においても、計算時間の主要因はnFeatureSnapIterであったと言ってよさそうです。

つまり、propellerチュートリアルの性能変化は、snappyHexDictの設定内容が変化したことによるもので、メッシャー（snappyHexMesh）の性能変化によるものではなかったということです。2.3.xを使わなくとも、Dictパラメタさえ変更してやれば、2.2.ｘでほぼ同等のメッシュが得られたということです。

implicitFeatureSnap

なお、implicitFeatureSnapの有無（true/false）に関して、数字面での差異ははっきりしませんでしたが、メッシュの見栄えは、明らかに違いがありました（下図）。

範囲を選択_394

但し、このパラメタに関しては2.3.ｘで使えるようになったということではなく、これまであまり意識して使い分けしていなかったもので、今回の調査で、trueにして使ったほうが良さそうだと、認識を改めたということです。

その他のケース

snappyHexMeshに関しては、propellerチュートリアル以外にも６つのケースがあるので、この際、これらに関しても調べてみた。結果をざっくりとまとめると以下のような表になった。

範囲を選択_395

総じて、

  • メッシュ品質はやや向上（変わらないものもある）。
  • メッシュ作成時間はやや増加（わずかに減少したものもある）。

と解釈しているが、これだけではあまりに主観的なので、数値データも以下に掲載しておく。図表中、朱字で記した部分が2.2.ｘと2.3.ｘとの比較において優れている箇所。また、2.3.x’とあるのは、2.2.ｘのsnappyHexMeshDictを用いて2.3.ｘで実行した結果である。

範囲を選択_396

範囲を選択_397

範囲を選択_398

範囲を選択_399

範囲を選択_400

範囲を選択_401

その他の所見

  • snappyHexMeshDictの記述方式として、#include形式記述が使用されるようになった。

上のまとめ表で、Dictの差異が「僅差」となっているチュートリアルケースで使用されており、meshQuarityControlのブロックに対して、以下のようにして、必要部分のみを書き換えれば済むようになっている。ケース間のパラメタの違いも見つけやすくなるので、だんだんこうなっていくんだろうなの感。

範囲を選択_402

  • featureデータ形式が拡張された（extendedFeatureEdgeMesh）が、その効能は不明　⇒　frange チュートリアル

最後に

調査に費やした時間の割に得られたものは少なかった。そういう事例でも公開するとなると更なる時間を費やす必要もあり、公開して得られるものを考えると滅入ってくる面が大いにあって、広島の勉強会（4/19）で発表して以来２週間以上たって、遅ればせの公開となった次第です。

 

Helyx-OS version 2.0.0

Helyx-OSは昨年の11月に新しいヴァージョンがリリースされていましたが、ようやくそこそこに使ってみる事が出来たので、その評価記事といったところです。

 

インストールの問題

バイナリーインストールではうまく起動しないという不具合がありました。この問題については、オープンCAE勉強会＠岐阜（第２７回）において、FSさんからいち早く取り上げられ、その時にはバイナリーインストールを諦めてコンパイルする方法について教えてもらいました（説明資料は本記事をアップした時点でまだ未掲載）が、かなり面倒で手を出すまでには至っておりませんでした。

その後、公開元HP情報を時々チェックしていましたが、いつまで経っても更新がないまま、先日（1/18）の第35回オープンCAE勉強会＠関東にて、開発元に近い人からの情報で対処方法を教えてもらうことが出来ました。

起動スクリプト（HELYX-OS.sh）中、

#!/bin/bash

LANG=”en_US.UTF-8″

THIS_FILE=`readlink -f $0`
THIS_FOLDER=`dirname $THIS_FILE`

export HELYX_LAUNCHER=$THIS_FILE
source $THIS_FOLDER/bin/launcher.conf

launchSuite $@

LANGの環境変数を追加指定する必要があった（赤字部分）という、たったそれだけの問題でした。

変化点

これも公開元HP情報を見ても、何が変わったのか判りません。画面全体のデザインがかなり洗練されてきた印象は確かにありますが、実質的な機能としては下のキャプチャ図に丸抜き数字で示した４点くらいでしょうか。


 範囲を選択_582

 

（参考） version 1.0.2

範囲を選択_584

  1. ParaViewを起動できるようになった。
  2. Multiphase/VOF ( = interFoam )のソルバー設定が可能になった。
  3. メッシュ作成やソルバー実行時の出力画面が、全体の操作画面の中に収納されるようになった。
  4. 解析中のケースフォルダを対象として、端末画面やファアイルマネージャを起動できるようになった。

このうち、1., 4. あたりは、OpenFOAMをちょっとでも使い出すと、誰でもが思いつくニーズでしたね。これで、2. のあたりの対応ソルバーのラインアップが充実してくれば、汎用ツールと比肩できるもになっていきそうな感触はありますが、まだまだ道は永そうです。

DEXCS for OpenFOAMにも、Helyx−OSは搭載させてもらっておりますが、現時点では、TreeFoamから起動するメッシャのプラットフォームとして使い、ソルバーの為の様々な設定はTreeFoamを使う方法を推奨しており、この方針はまだしばらく続きそうです。

ただ誰でも簡単にすぐに使えるというDEXCSの狙いからすると、ソルバー設定機能部分が2.のように機能拡張することよりは、単機能でも良いので、もっと簡単になってくれることを期待しているのですがね。

いや、それよりもメッシャーとして使う部分において、この新しいヴァージョンでは却っておかしくなってしまった部分があるのが心配です。単なるバグで、いずれフィックスされることを期待しているんですが、いましばらくは、こういうものだと思って使っていくしかなさそうです。

課題1. Blenderで出力するSTLファイル対応の問題

Blenderから出力されるSTLファイルでは、

solid Exported from Blender
facet normal 0 0 0
outer loop
vertex 0.278489 0.358779 0.164229
vertex 0.289535 0.361037 0.167021
vertex 0.301157 0.362951 0.170137
endloop
endfacet

solid名で、上の赤字部分のように、 Exported from Blender という付帯情報が勝手に付けられてしまいます。問題はその付帯情報の中にスペースがあるという点です。

以前のヴァージョンでは、こういう名前があった場合に、スペース部分を_（アンダースコア）で置き換えた形（Exported_from_Blender）にしたSTLファイルをpolyMesh/triSurfaces フォルダ下に収納し、snappyHexMeshDict 中でも、同じように記述されていたのに対し、新しいヴァージョンではその処理がされておらず、solid名にスペースがあると結果的にレイヤーを追加することが出来なくなってしまうということです。

課題2. snappyHexMeshDict のパラメタ変更の問題

 メッシュ作成をやり直そうとすると、何故かsnappyHexMeshDict 中、refinementSurfaces ブロックのlevelパラメタが認識されなくなってしまいます。画面上で指定は出来るのですが、Dictファイルに反映されません。

snappyHexMeshDictを手修正して保存しておいても、画面上のメッシュ作成（create）ボタンを押してメッシュ作成しようとした途端、その時点でsnappyHexMeshDictが書き換わってしまいます。なのでパラメタ変更したかったら、後はコマンド実行するしかないという事です。

ということでこれはかなり致命的に辛い。もっとも、自分の環境に問題がある可能性もありますが。