DEXCS2014 for OF(ubuntu-14.04)on VMwarePlayer システム更新トラブル(その2)

VMwarePlayerで使用する場合に、システム更新すると共有フォルダが使えなくなってしまうという問題がありました。どの時点から使えなくなったのか定かではありませんが。

システム更新と併行してVMwareToolsもアップデートするんですが、その際のエラーメッセージを見落としてていました。

範囲を選択_999(461)

 

色々調べたところ、VMwareToolsのバグらしいということは判ったのですが、このツールのヴァージョンによって微妙に対処方法が違うようで、(VMwareTools-9.6.4-2441333)では、以下の方法でソースを変更、再インストール(vmware-config.tools.pl)で何とかなりました。

# cd /usr/lib/vmware-tools/modules/source/
# tar xf vmhgfs.tar
# sed -i ‘s/d_alloc/d_u.d_alloc/’ vmhgfs-only/inode.c
# tar cf vmhgfs.tar vmhgfs-only

要は、Linuxのカーネルに応じて、d_allocの部分を書き換えてやる必要があるということらしいんだが、対象ソースファイルや、書き換え対象テキストが、ツールのヴァージョンによって、微妙に変化してきているようです。

参考にしたサイト情報

http://chocolapod.sakura.ne.jp/blog/entry/47

https://communities.vmware.com/thread/503607

http://akiki2starlet.blog.fc2.com/blog-category-5.html

OpenFOAM-2.3.1全チュートリアルのAllrunをやってみた

昨日の第37回オープンCAE勉強会@岐阜にて発表した資料です。

新しく追加されたチュートリアルの動画も披露させていただきましたが、pdf化した上記スライドシェアの資料では見れなくなってしまいますので、以下に別途(YouTube)アップロードしておきました。

また、各チュートリアルの全データリスト(計算時間やディスクスペース、メッシュ数などの情報)はこちらにて公開しています。特にヘビーな(計算時間が長大になるものや広大なディスクスペースが必要な)チュートリアルを実行する際の参考にしてもらえればと思います。

 

multiphase/interFoam/ras/angleDuct

multiphase/twoPhaseEulerFoam/laminar/injection

multiphase/potentialFreeSurfaceDyMFoam/oscillatingBox

multiphase/multiphaseEulerFoam/mixerVessel2D

DEXCS2014 for OF(ubuntu-14.04) システム更新トラブル

DEXCS2014 for OpenFOAM(R)にて、セキュリティアップデートなどのシステム更新をしたりすると、(自分の環境の場合、実マシンでは問題なかったが、仮想マシンで)再起動後にログイン画面でパスワードを入力した後、デスクトップ画面が表示されなくなってしまう、というトラブルが多発しておりました。
まぁ、仮想マシンなので、駄目になったら、再インストールすればいいや・・・ぐらいで使ってきていましたが、少し前に記載した Hira Stl Viewer を使用したいが為、wineをインストールした時も同じ状態になってしまい、この場合は、それまでに何かと作りこんだケースファイルも多くあったので、何とか復旧する手立てはないものかと調べました。

 

これもまぁ結果オーライで、一般性のある解決手段であるかどうか定かではありませんが、自分のマシン環境では解決できたので、その方法を記しておきます。

参考にした情報はこちら

CTRL + ALT + F1 を押して、ターミナルモードでログインし、以下コマンド入力

$ sudo apt-get install –reinstall ubuntu-desktop
$ sudo apt-get install unity
$ sudo apt-get purge nvidia* bumblebee*
$ sudo apt-get install nvidia-prime
$ sudo reboot

自分のマシンは、仮想マシンを動かすマシンはnvidiaのグラフィックカードを使っており(OSもubuntuでない)、DEXCS2014をインストールした実マシンはnvidiaのグラフィックカードを搭載しておらず、多分、この方法で何とかなったんじゃないかと思います。

OpenFOAM ソースコードの探索・デバッグ on DEXCS2014

最近、あるソルバーの動作を調べてもらいたいという注文があったので、久しぶりにコード検索・デバッグツールを使ってみようと思い立ちました。

しかし、数年前に使ったきりで、その当時からお世話になったPENGUINITISさんのサイトには今でも紹介されているんですが、情報が少々古くなってきており、この最新の環境だと、昔の方法がそのまま使えない事項もあったので、ここにDEXCS2014(OpenFOAM-2.3.x on ubuntu-14.04)の場合、どうであったかを取りまとめておくこととしました。

なお、ここで取り扱うのは、本家のWikiページ(HowTo debugging)にあるような、コマンドライン入力でgdbなんかを使ってシコシコやるっていうのではなく、あくまでGUIツールを使ってやる方法です。

 

GUIデバッグツール

これまでに使用したことのあるデバッグツールは以下の3つです。

  • NetBeans
  • KDbg
  • Eclipse

ソースコードを静的に探索するならNetBeans、動的というかステップ実行したり、変数の内容を確認したりの、いわゆるデバッグするにはKDbgがお手軽に使える反面、これらのツールで両方共出来るということはない。片やEclipseではどちらも出来るのだが、設定が面倒だし重いとかあって、お手軽でないという、どれも一長一短あって、用途に応じて使い分けるしかないのかなぁ・・・というのがこれまでの個人的な結論でありました。

そこで、それぞれのツールについて、DEXCS2014で動かす方法とその結果について以下に記しておきます。

 

NetBeans

現時点での最新版 IDE 8.02が使えました。PENGUINITISさんのサイトでは、IDE 7.2 for OF-2.1.1 の説明で、当時は日本語表示がうまく使えなかったようですが、現在は問題なく使えます。言語設定(LANG=…)の必要はありません(英語で使いたい人は別ですが)。また、富山勉強会のサイトにも、NetBeans設定方法(IDE 7.4 for OF-2.2.2)について取りまとめられており、基本的にはこれらの方法と同じで大丈夫でした。

範囲を選択_016

ソースファイル一式を丸ごと解析するので、最初はちょっと時間がかかりますが、解析が終われば、上の図に示すような感じで、キーワードの上でマウス右クリックを使って、さほどストレスなくコードの中味をたどることが出来るようになります。

範囲を選択_015

但し、上の図の例でいうと、ソース行番号の欄で、何やらマークが付けられた行、

turbulence->correct();

は、ライブラリの中味まではたどることが出来ないということです。ただ、ここは後で述べるEclipseのようにコンパイル環境の設定までは実施していないのがそもそもの原因なので、そこが出来ていれば多分可能なんでしょう。そのやり方が判れば・・・なんですがね。(判りました⇒追記参照)

 

KDbg

残念ながら、KDbgはDEXCS2014上では動きませんでした。Synapticパッケージマネージャからはインストール出来るようになっていたのですが、インストール出来はしたものの、実行しようとするとSegmentation fault です。そもそもランチャー用のアイコンも実体がありませんでした。

ソースコードからインストールする方法も試してみましたが、KDEのヘッダーが何チャラというエラーメッセージで、要するにちゃんとしたKDE環境でないと動かないということらしい。多分、ubuntu系なら、Kubuntuを使えということなんでしょう。

とはいうものの、DEXCS2013(OS は、mint 13、実質ubuntu-12.04)の古い環境で、OpenFOAM-2.3.1(注)を動かすことは出来たので、ここで他のツールとの比較という観点から、ちょっとだけ紹介。

(注)本当は、OpenFOAM-2.3.xを調べたかったのですが、拙宅マシン(mint 13 / ubuntu-12.04)で、DEXCS2014公開当時の2.3.xはコンパイル出来ていたのですが、拙宅マシンに当時の版は残っておらず、更新した最新版2.3.xは、不完全なコンパイルしか出来なくなってしまっていたので、2.3.1で検証しました。

基本的には、PENGUINITISさんのサイト記載してある方法でインストールから、ブレークポイントを設定したり、ステップ実行が出来るようになります。

そこで、たとえばNetBeansの静的な解析でたどれなかった箇所にブレークポイントを置いてデバッグを「実行」すると、その箇所で待ち状態になってくれます。

範囲を選択_018

 

ここで「ステップ イントゥ」を何回か(この場合は4回)押すと…

範囲を選択_019となって、所望のライブラリファイル(この例ではkEpsilonを使っているので、kEpsilon.C)にたどり着くことが出来るという次第です。

チャチャッと調べるには、このツールがなかなか便利なだけに、DEXCS2014で使えないのが残念です。

 

Eclipse

はっきり言って、これはややこしい。

「openfoam eclipse debug 」あたりでググっても、拙作記事が結構上位に出てくるくらいで、本家の方にも新しい情報がない。結局、この拙作記事からたどれる、これまた拙作のインストール方法やら、使用(コンパイルから実行までの)方法やらを頼りに、ほぼ同じ方法で、DEXCS2014に環境構築するところまでは出来ました。

範囲を選択_020

コードを検索するあたりは、Ctrlキーを押しながらマウスクリックで、範囲を選択_021

簡単にたどれるようにはなる。

また、Eclipseの上でコンパイルする方法も判っていたので、これも同じやり方(といってもかなり試行錯誤でやり直したが)でなんとかコンパイル出来るようにはなった。

範囲を選択_022

ただこの時点でも、ライブラリの中味までたどれないのはNetBeansと同じです。

次にデバッグ用のケースファイルを作成してデバッグを実行しますが、設定を間違えていなければ、次のメッセージ画面が現れます。

範囲を選択_023

問題は、これが出てくるまでに、異常に長い時間(数分というオーダー)がかかってしまう事でした。2回目以降はそうでもないようですが。

範囲を選択_024

何はともあれ、デバッグが開始されれば、KDbgと同じように、ブレークポイントを設定⇒Step Into(F5) で、所望のライブラリまでたどり着くことは出来ました。

 

なお、以前の方法と「ほぼ同じ」やり方と記しましたが、違う点はgdbをインストールし直す点です。以前の方法では、標準のgdbをアンインストールして、古いヴァージョン(gdb-6.8)を入れ直す必要がありました。今回もそれを試みましたが、残念ながら出来ませんでした。コンパイルすると…

In file included from amd64-linux-nat.c:26:0:
linux-nat.h:63:18: error: field ‘siginfo’ has incomplete type
struct siginfo siginfo;
^
make[2]: *** [amd64-linux-nat.o] エラー 1

というエラーで、ググったところ、それらしい情報もいくつか見かけましたけど、解決策には到らずでした。

デバッガーが起動するまでにやたら時間がかかるのはこのことが原因なのかもしれません。ここ(gdbを入れ直すところ)はスキップ、もしくは最新版を入れ直すなどもやってみて、違いがあるような、無いような・・・よく判りません。

 

まぁ、とりあえず動くようになって、今回調べたいコードの探索も出来るようにはなっており、これ以上時間をかけるのは本筋ではないので、これにて調査終了としました。

 

追記(2015/1/30)

NetBeansでデバッグまでは出来ていないと記しましたが、本記事を見たFaceBookの読者さん(富山県立大の中川慎二先生)から情報を頂きました。

範囲を選択_025

情報はこちら(⇒ http://eddy.pu-toyama.ac.jp/bb7e59f23-126/#_126

早速確認させていただきました。

範囲を選択_017やはり、コンパイルのやり方にひと工夫(wmakeを変更)が必要だったようですが、出来てしまえば、あとは簡単でした。

英語メニューでの解説を日本語メニューで読み替えるのに少し戸惑いましたが、Eclipseに比べるとメニューがそれほど込み入っておらず、メニュー探しに手間取ったり、間違えたりすることは断然少なく済みそうです。

安定性の面では、もう少し使い込まないことにはわかりませんが、これもEclipseとの比較でOKなら、Eclipseは不要になりますね。

 

 

 

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

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

範囲を選択_999(194)

 

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

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

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

そこで…

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

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

範囲を選択_999(195)

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

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

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

 

 

stlファイルを使ってみた(その1)

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

範囲を選択_999(226)

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

 

stlファイルを使ってみた(その2)

その1の検証で、輪郭線が鈍る件は、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、計算進行状況、y+の結果もほとんど差異は見られませんでした。

範囲を選択_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品質は劣ったが、境界レイヤーは格段に優れていた。)を覆す結果には到らなかった。