タグ: blockMesh

interDyMFoam/stirredMillAMI

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を有効にすることで、大幅な改善効果が見られました。 範囲を選択_846 範囲を選択_847 なお、表中の○は計算が可能、✕は計算が不能、△は前述の手作業で可能、であったことを示します。また計算時間は、現象時間の0.1秒分（丁度1回転するのに要する時間）を計算するのに要した時間であり、4並列計算で実行したもので、計算モデルとしては、以下の擬似開口部を設定して計算したものです。

擬似開口部の境界条件

今回のケースでは、対象の計算領域が密閉構造となる為、圧力基準点を設定してやる必要がありましたが、これを通常のpRefCell や、pRefPointで設定すると、それらの場所のとり方次第で、計算性能（とくに並列性能）が大きく劣悪化するという問題があり、これを回避するのに、小さな開口部を設けてそこで圧力一定条件を適用してやれば問題なさそう（発表資料のp.14〜18）・・・ということでした。

ちなみにこの時の境界条件は以下のようにしておりました。

範囲を選択_848

開口部は表中赤枠で囲った部分、パッチ名はoutletとし、圧力（p_rgh）を固定値として、その他はすべてzeroGradientです。

とはいえ、これだと開口部を設けることで、微少ながらも実際に流出入が生じてしまうことになり、その流量を気にしながら計算結果をチェックする必要があり、あまり気持ちの良いものではありません。ならばということで、圧力以外のzeroGradientを止めて、以下のようにする。

範囲を選択_849

つまり、stator と同様、圧力以外は、単純なすべり無し壁と同じ条件にしてしまったらどうか？　という点です。

結果は、それでもちゃんと計算できて、流れ場の状態は当然同一にはなりませんが、どちらが良い/悪いの区別できるものでもありませんでした。

以下に計算時間の推移を示します。

範囲を選択_868

 

赤色は「流入出有り」の計算で、緑色は「すべり無し壁条件」の計算です。横軸はSimulationTimeですが、0.1秒で、丁度１回転することになります。0.06秒あたりで、少しの間計算速度の違いが見られますが、そこを除けば、ほぼ同一の速度です。

当初は、「すべり無し壁条件」＝「密閉空間」なので、こちらが遅くなるのではないかと懸念してましたが、そんな事もないようです。

「流入出有り」の計算で、実際の流量をモニターした結果を以下に示しますが、0.06秒あたりでの計算速度低下を説明できるとは言い難い結果でした。

範囲を選択_867

結局、まぁ良く判らないけど、「すべり無し壁条件」で、圧力だけを規定する・・・で良さそうです（公開ケースファイルは、これで作成してあります）。

 

implicitFeatureSnapの効果

前述の発表資料のp.4に記してあるように、本件では、implicitFeatureSnapを使うこと（true）を採用しましたが、本件とは別の事例で効果を確認したところ、その場合は逆の傾向（使わない false のほうがメッシュ品質が良好であった）が見られました。

そこで、本記事では再度計算をやり直し、定量的な比較を試みました。

当初の見立ては、以下のメッシュ図によるものでした。

範囲を選択_863

特に、突起の根本部において、明らかな違いが見られました。

一方、回転領域の境界面は、下のようになっており、違いはあるものの、どちらが良いとは判断しかねます。

範囲を選択_864

そこで、前述の発表資料中にもあった、AMI: Patch target sum(weights) min/max/averageを調べてみました。

範囲を選択_865

 

こうして見比べると、確かに違いがわかります。falseとすると、特にminの値が0になる状態が頻出するので、当初の、lowWeightCorrectionを使わない計算ではたちどころに異常終了することとなり、trueを採用したということでした。

しかしながら、lowWeightCorrectionを使えば、これでも計算は可能になったので、以下に計算時間を比較しました。

範囲を選択_866

横軸はSimulationTimeですが、0.1秒で、丁度１回転することになります。計算の終盤になって、やや違いが生じてきましたが、期待（？）の程には差が出るものではないようです。流れ場の状態も、当然同一にはなりませんが、どちらが良い/悪いの区別できるものでもありませんでした。

結局、implicitFeatureSnap true/false は、さほど重要なファクターでなさそう、ケースバイケースだと思っておくのが良い・・・ということでしょうか。

最後に

lowWeightCorrectionの効果は絶大で、これから新しくcyclicAMIを使った回転体解析をやるのであれば、必須アイテムです。そういう意味で今回の公開ケースはこれを利用可能な、OpenFOAM-2.3.0以降に対応するものです。これ以前のヴァージョンで実施するにはPropertyファイルや、成分名の命名方法を変更する必要があります。その改造はさほど困難でないのですが、再整備する手間もままなりません。ご要望が多ければ・・・ということで。

おまけ

先の勉強会にて、ほぼ同程度のメッシュ規模の計算結果をアニメーション表示するのに、ボリュームレンダリングはさほど困難でない・・・という紹介があったので、ここでもやってみました。

ちなみに、下の動画が、これまで勉強会などで紹介してきたもので、alpha.waterをスレショルド表示させたものです。

アニメーションの総コマ数は500でしたが、製作時間が従来の方法で約10分、今回のボリュームレンダリングで約40分と、確かにまぁ、許容レベル内といったところでしょうか。

 

ケースファイルに関する説明

以下のように、m4Snappyと、normalSnappyという２つのフォルダに、それぞれ２つのケース（全密閉構造タイプと、擬似開口部を設けたタイプ）が収納してあります。各々のケースファイルにはAllrun スクリプトが同梱してあり、自動実行できるようになっています。また、Allcleanスクリプトで最初からやり直しする事もできます。

範囲を選択_869

m4Snappyケースで、Extend blockMesh を利用できる場合には、Allrunスクリプト中、以下の部分を選択使用する（13行目と14行目を使い分ける）だけです。

範囲を選択_870

また、メッシュの細分化レベルは、各ケースの　system/snappyHexMeshDict を変更して使って下さい。解凍したままの状態では、もっともメッシュ数を少なくして計算できるパラメタにしてあります。

 

 

DEXCS2012 for OpenFOAM(R) Winkチュートリアル　その２と３

DEXCS2012からは、ランチャーでメッシュ作成する際にSwiftツール使う方法を採用することとした為、これまでのやり方とは大きく変更になります。ようやくチュートリアルも出来たのでここに公開です。

その２（Swiftツールの使い方）

その３（メッシュ作成）

  • Winkチュートリアルはこちら
  • 従来は、メッシュ１（blockMesh作成）とメッシュ２（snappyHexMesh作成）の２つのタグメニューを使ってやっていましたが、一つのタグメニューの中でやれるようになりました。
  • SwiftSnapでは現在のところ、cellZone指定できないという問題もありますが、DEXCSツール（snappyDictExporter.pyの改良版）で補完する方法についても解説しています。

今後の予定

  • winkチュートリアルとしては、残り２つ。計算実行の部分と後処理の部分ですが、これらは従来のやり方とほとんど変更はない為、いよいよゴールは見えてきた・・・の感です。
  • その他、Blenderの画面やメニューが、従来と大きく変更になったいる為、使用法マニュアルも更新する必要がありそうです。
  • snappyDictExporter.pyの改良版ですが、上記用途（SwiftSnapの不足機能補完）に使えるべく、必要最小限は実装できているのですが、もう１点改良したい部分（対象ケースのsnappyHexMeshDictファイルから、細分化パラメタを読み込む機能を実装すること）があり、これをどうするか思案中。(2012/12/7 実装はほぼ完了）

攪拌槽のメッシュ作成方法

OpenFOAMの掲示板にて表題のメッシュ作成方法に関するQAがあったのですが、これもSwiftツールを使って簡単に出来る格好の例題でした。ここにやり方とケースファイルを公開しておきます。

ケースファイルの説明

モデル＆ケースファイル一式のダウンロード

ダウンロードしたケースファイルを解凍すると、以下のファイル構成で、２つのケースファイルから成っています。

  • 左端最下行の２つのファイルが、掲示板にて公開されている２つのstlファイル
  • この２つのファイルをBlenderへstlインポートして、回転領域を指定する円柱データを追加して１つのstlファイルに合体（円柱データの追加方法と、合体方法は後述）、blender形式で保存したのが、meshAのmodelA.blend。
  • タンク部の上端位置を伸長、上記合体したstlファイルとは別オブジェクトにて、blockMesh領域を設定する為の矩形データ（上端位置が開口部と一致すべく）を追加し、Blenderファイルとして保存⇒meshBのmodelB.blend
  • 上記Blenderファイルにて、Swiftツールを使って、blockMeshパラメタと、snappyHexMeshパラメタの設定を織り込んだもの（具体的な設定方法は後述）⇒modelA（またはB）Swift.blend
  • 上記modelA（またはB）Swift.blendから各Swiftツールのwriteボタンを押して自動出力されたパラメタファイルを赤枠で示してあります。
  • 但し、snappyHexMeshDictファイルだけは、一部手修正が施してあります。（下図、赤枠部：cellZone, faceZone 指定パラメタ）

実行方法

  • blockMeshを実行し、引き続きsnappyHexMeshを実行するだけです。
  • メッシュ作成例（meshA）

  • メッシュ作成例（meshB）

円柱データの追加方法

  •  視方向は上面（または下面）から見た状態
  • 追加　⇒　メッシュ　⇒　円柱
  • 左側ツールシェルフ中に、円柱のスペックを指定できるようになるので、サイズや位置を決める。深度だけは適当な値にしておいて、後で詳しく指定する。
  • 視方向を横（前・後・左・右のどちらでも良い）にして、編集モードにて、上端面を選択し、高さ（ｚ座標）を指定する。
  • 同様に下端面の座標値を指定して完成

複数オブジェクトの合体方法

  •  オブジェクトモードにて、どれか一つのオブジェクトを選択（下図では外枠のタンクを選択）した状態にて、Shiftキーを押しながら他のオブジェクトを選択（右ボタンクリック）。⇒最初に選択したオブジェクト以外はやや濃いオレンジ色となって全オブジェクトを選択した状態にする。
  • メニューのオブジェクト⇒接続を選択
  • 全て同一色となって、一つのオブジェクトに合体される

SwiftSnappの具体的設定方法

  • フィーチャーエッジの作成方法やメッシュ制御点の設定方法は割愛（別途講習資料を参照下さい）
    • （2013/1/4 補足）　追加情報を記載しました→記事
  • ここでは、STLのパーツ毎に名前や細分割レベルを変更する為の具体的手順を示します。
  • まずは編集モードの面編集モードにて、全選択状態にしておく「下図）。

  • SwiftSnappツールのPatch settingsのメニューにて、名前を指定し、SetPatchのボタンを押せば、設定が反映される。この時点で、tankというパッチ名で、タンク以外の部分も選択されてしまっているが、この後のプロセスで別の名前に変更する。
  • 視方向を横からの方向にして、Aキーを押して、非選択状態。
  • Bキーを押して、ブロック選択状態にて、回転領域を選択。
  • 回転領域（＋回転体）が選択されたら、名前（blade_area)を付け、細分割レベルを指定して、Set Patch ボタンを押す。この時点で回転体（blade）そのものを選択されているが、後のプロセスで別の名前に変更する。
  • 再度、全非選択状態にて、表示拡大し、回転領域と回転体が識別できる状態にしておく
  • 「ビュー」メニューから、ボーダーでクリッピングを選択
  • 回転体だけを範囲選択する
  • マウスボタンを話すと。指定範囲だけがクリッピングされる
  • 視方向を上または下に切り替える。
  • ブロック選択を、数回繰り返せば、回転体（blade）だけを選択できるようになるので、
  • 選択できたら、名前（）を付け、細分割レベルを指定して、Set Patch ボタンを押す。
  • 以上で完了。下図はオブジェクトモード、で全体の半分領域をクリッピングして、ソリッドで表示確認したもの。

補足

  • ｍｏｄｅｌASwift.blend では、さらにタンク容器の上面だけを別の名前に変更している
  • mashAのケースで使用しているblockMeshDict は公開しているものをそのまま使用している。
  • 一方、SwiftSnappにて、Make base mesh（下図）にチェックマークを付けてWriteボタンを押すと、対象モデル全体を包含するblockMeshDictを自動作成してくれる。（meshA/system/blockMeshDict)
  • しかし、このｂlocｋMeshDictを使って作成した基礎メッシュ（下図参照）を用いてsnappyHexMeshを作成することもできるのだが、何故かfeaturesや、refinementSurfacesの指定が有効になってくれない。
  • 基礎メッシュのサイズはとモデルサイズよりも、ある程度の余裕が必要ということなのか・・・詳細は不明。
  • meshAの方法と、meshBの方法の一番の相違点は、基礎メッシュ（blockMesh）端面をpatchとして使用しているかどうかの違いです。
  • meshBの方法（基礎メッシュ端面をpatchとして使用）で作成した場合、基礎メッシュ端面の近くに、ごく一部ですがメッシュの凹凸が出来てしまっています。これが一般解なのかどうか、本ケースに特有な事例であったのかもしれないが、詳細は不明。

風穴のある柱状構造

OpenFOAMのGoogleグループに、表題のメッシュ作成法に関する質問がありました。

質問者の当初の意向は、Netgenを使いたいとの事だったんですが、やりたい事は、SwiftBlockの格好の例題であると判ったので、ここに作成法を公開しておきます。

ファイル一式の説明

ダウンロード⇒

blenderにて形状モデル作成

  • グリッド（平面格子）を作成して、区分したい境界線毎に高さ方向に積み上げていくだけです。
  • x方向は、ここでは区分しないので、中心の分割線は不要ですが、グリッドを起点に作成しており、分割線のないグリッドは作成できなかったのでそのまま残しました。
  • 矩形平面をベースに始めることも出来たのですが、モデル作成の手間との兼ね合いです。

SwiftBlockのパラメタ設定

  • 風穴など、境界面として識別したい面を選択して、個別に名前を付け、patchやwallなどのType指定しておきます。

 

blockMeshDictの作成

  • SwiftBlockツールのwriteボタンを押せば、blockMeshDictを自動作成してくれます。その時、ファイルの出力先が、constant/polyMesh の下になるように間違えないことが肝要です。
  • なお、この書き出しにはそれなりの時間（数分程度）がかかり、その間blenderの画面はフリーズ状態になりますが、システムダウンしている訳ではないので、慌ててリセットボタンを押すことなどしないように。
  • モデル作成の手間を惜しまないで、ｘ方向の中心分割線のないモデルで作成していたら、ここでの所要時間は、約1/4になります。

blockMeshの作成

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

nPoints: 1636362　nCells: 1574400

  • メッシュ作成時間は数分
  • 分解能を、一番細長い穴を３分割できるサイズ（0.05）とした為、かなり大きなメッシュになってしまいました。
  • y方向とx方向でサイズを変えたりすることができないのがこのツール（SwiftBlock）の難点ですが、自動生成されたblockMeshDictを直接編集で書き換えてしまうという方法も、実際問題としてはありでしょう。

メッシュとpatchの確認（paraFoam）

 補足

  • ここでは風穴部分だけをｐａｔｃｈとして区分しましたが、壁面の一部だけを加熱したいような場合に、その部分だけを識別できるようにモデル化すれば、同様の手順で出来ることになります。
  • 但し、区分したい形状は、基本的に直交平面であることが前提です。
  • 形状が傾いていたり、円形などの場合にも、出来無いことはありませんが、モデル作成にひと工夫（多くの手間）が必要になります。

 

サーバールームの熱流れ解析

OpenFOAMのユーザーグループにて投稿された記事にて、表題の解析をする為のモデル作成法についてのQAがあり、基本的に直交格子で作成できるとはいえSwiftBlockではハードルが高い・・・とのコメントがあったので、ここにサンプルケースを作成し公開することにしました。

⇒サンプルケース一式
実行方法は、解凍して出来るフォルダ中の、memo.txt　に記してあります

1. serverRack フォルダにて
SwiftBlock→write（constant/polyMesh/blockMeshDict作成）
blockMesh の実行

2. roomRack フォルダにて
SwiftBlock→write（constant/polyMesh/blockMeshDict作成）
blockMesh の実行

3. serverRack フォルダにて
$ mergeMesh . ../roomRack
（mergeMesh の実行）
serverRack/1/polyMesh を、
serverRoom/constant の下に移動またはコピー

4. 7_serverRoom フォルダにて

$ ./makeCyclic.sh

constant/polyMesh/boundary を手修正

fanOut
{
type cyclic;
nFaces 192;
startFace 100156;
matchTolerance 0.0001;
neighbourPatch fanOutRoom;
}

… など

モデルの概要

  • 簡単の為、サーバーラックは１セットだけです。

メッシュ作成方針

サーバーラックの内部と外部に分けて、別々にメッシュ作成し、あとでそれぞれのメッシュを結合することとしました。

領域別メッシュ作成と結合方法の概要

  • serverRackと、roomRackというフォルダ中に、blenderで作成しSwiftBlock定義したモデルがあるので、これらを起点としてblockMeshDictを作成、blockMesh実行し、メッシュ作成、結合（mergeMesh）します。
  • 結合したメッシュを、7_serverRoom/constant の下に置いて、結合面処理（stitchMeshやcyclicBaffle作成）します。

SwiftBlockモデル作成手順の概要

  • モデル作成は基本的に、グリッドを押し出していくだけです。
  • ある程度Blenderの操作に習熟すれば、作成には30分もかからないと思います。

結合面の処理方法

  • 単純にmergeMeshしただけでは、ラックの出入り口がつながったことにはならないので、stitchMeshコマンドで、これらを結合します。
  • fanOutの流出口ではcyclic fan 特性を付与したいので、stitcｈしたメッシュから改めてfaceSet作成⇒baffle作成し、cyclicFace化します。
  • ちなみにOpenFOAM-2.1以降であれば、cyclicAMIが使えるので、単に通気性を付与するだけならstitchMeshは不要ですが、cyclicAMI＋cyclicFan は使えないようなので、cyclicFanにしたい部分はstitchMeshするしかないようです。

境界条件

計算結果

補足というか、そもそもの作成動機

  • 012/6/9に、オープンCAEワークショップ2012の講習会Aにて「SwiftツールによるOpenFOAM®用メッシュ作成」を実施しましたが、その中で、SwiftBlockの実習は、「第16回オープンCAE初心者勉強会（夏合宿）」にてやるとアナウンスしてありました。
  • そこで本ケースをその題材に出来ないか・・・ということでした。
  • メッシュ作成自体は、OpenFOAMのユーザーグループの投稿記事を見てすぐに、実に簡単に出来ていたのですが、メッシュの結合処理やらcyclicFanの設定法やら調べるのに手間取って、ようやく今頃になって公開ということです。
  • 実習用の仮想マシンとテキスト（上記講習会でやったものに、約40ページ追加されることになる）もほぼ出来上がって、この部分の実習時間は1時間程度と予定しております。