タグ: TreeFoam

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が書き換わってしまいます。なのでパラメタ変更したかったら、後はコマンド実行するしかないという事です。

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

DEXCS2013 for OpenFOAM(R) リリースノート

DEXCS for OpenFOAM(R) は、OpenFOAMと、これをより簡単・高度に活用できるようにする為の様々なツールをすべてインストール済のオール・イン・ワンパッケージで、誰でも簡単・即使えるようにしたマシンイメージ（isoファイル）です。

範囲を選択_999(280)

DEXCS2013では、

  • OpenFOAMやその他の組み込みツールのヴァージョンアップに対応
  • 初心者向けのランチャーは、ほぼ機能開発が完了したとして、国際化対応に向けての英語版（翻訳は未熟ですが・・・）での動作も可能にした
  • DEXCS2011から搭載するようになった中級者向けツールの機能強化を図りました。

なお、DEXCS2012までは、32/64bit版がありましたが、DEXCS2013からは、64bit版のみです。

インストールと利用法

範囲を選択_161

詳しくはこちら（資料はDEXCS2012のものですが、DEXCS2013でも画面イメージが異なるのみで同じです）2013/10/22更新

  • マシンイメージなので、DVDにイメージ書き込みすれば、DVDから起動してそのまま利用することができます。 （DEXCS初体験の人はこのライブDVDとして「まずは使ってみる」方法をお薦めします。）
  • 起動後にインストール機能により、HDD等に直接インストールできる上、使用するユーザー名等を選択することができます。
  • VMWare Playerや、VirtualBox等の仮想環境で起動して、仮想環境を作成することも簡単です。
    • VirtualBoxにインストールする方法は、こちらに詳しく記されています
  • 基本的に、DEXCS2011でやった方法と同じですが、同じやり方が通用しない部分が一部あるので、DEXCS2011の利用経験者はご注意のほど。

同梱プログラム

範囲を選択_999(281)

OSはLinux Mint13

といっても、ベースはUbuntu-12.04なので、アプリケーションのインストール方法などは、ubuntuのそれと全く同じです。違うのはデスクトップのGUI環境だけです。
標準のターミナル、ファイルマネージャ、テキストエディタがubuntuとは異なりますが、DEXCSランチャーやTreeFoamは、ubuntuの標準ツールを使用することを前提に作られているので、ubuntu互換ツールとして起動できるようにしてあります。

その他のドキュメントについて

    • DEXCSランチャーのヘルプメニューを参照下さい。
    • 本当に初めて使う人は、「ランチャーの使い方」-「まずは使ってみる」をご覧下さい。
    • 「ランチャーの使い方」-「形状作成」にて、Swiftツールの使い方を概略説明しています。
    • 「ランチャーの使い方」-「メッシュ」「計算実行」「結果処理」を理解できるようになると、OpenFOAMの基本的なファイル構造を理解できたことにもなります。
    • 以上は動画チュートリアルになっていますが、「フラッシュプレーヤー」を変更して参照することを強くお勧めします。変更方法は、最下段の「フラッシュプレーヤーの変更方法」をご覧ください。
    • TreeFoamの実践的な使用方法

 

DEXCS2013 for OpenFOAM(R) に向けて雑感

今回、DEXCS2012 for OpenFOAM(R) 特別版を作成してみて、次期リリース版、DEXCS2013の目標のようなものが見えてきた、、、ズバリ

目標は国際化対応

こう考えるに至った理由というか、背景を以下に記しておきます。

 

理由その1：8th OpenFOAM Workshop

という、ある程度OpenFOAMに親しんだユーザーなら誰でもご存知、年に１回開催される国際会議に初めて参加した。つい１週間前のことでした。

たまたま、開催場所が韓国のチェジュ島と日本に近いこと、日本のオープンCAE学会が主催でツアー（といっても現地での日本人飲み会）を企画してくれたこともあって、ほとんど観光旅行のつもりで参加しただけなんですが・・・

バンケットでは大トリの１等賞品に当選するという幸運で、想定外の受賞スピーチ。翌日に参加した「アジア環太平洋地域フォーラム」で、これはある程度想定していたとはいえ、自己紹介までやることになって、単語の羅列だけでこれらを何とか切り抜けることになった。

恥ずかしいスピーチではあったが、かといって、この歳で今更、英会話勉強して、もうちょっと気の利いたことが言えるようになりたい・・・という気持ちには全くならなかったんですが、頂いたものがあったらお返しするのが日本人。

理由その2：CFD Online

という、OpenFOAMでわからないことがあったら、ここに訊け！という代表格のグローバル掲示板の中で、DEXCSやTreeFoamについて取り上げられた記事も上がり、今年の春くらいから、一部の人の間では話題になっていた。とはいえ、

I’m guessing TreeFoam is a custom solver, and DEXCS is the software suite. More info here:http://dexcs.net/ocse2/?p=816. I don’t understand Japanese, so I can’t say any more about it.

 などと、少々正しく認識されていない面もあって、これを正すコメントを投稿できればよいのだが、理由その１:に述べたように、自分の英語力では、到底おぼつかないので放置状態であった。

 とまぁ、色々あったんですが、お返しには、自分が作ったものを、そのまま見てもらうのが一番、つまり国際化対応したものを作ればいいだろ・・・ってことです。単語の翻訳くらいは自動変換もそんなに難しくないし、他の人に助けてもらうこともできるので。幸いなことに・・・

理由その3：DEXCS for OpenFOAM(R) の目指すGUI

がほぼ固まり、ツールとして必要な開発部分が無くなった（詳しくは後述）。後は、DEXCSの中で使わせて頂いているそれぞれのツールのブラッシュアップに期待するしかない。年に１回、最新版に更新。あるいは、それらに替わるツールが出現したら、組み換えるという仕事くらいしか自分の役割はなさそうだ、と思えるようになったというのが、この特別版をリリースした後の実感です。

なので、次の自分の仕事は、国際化対応ということになった次第。とはいえ、無謀な挑戦する気はなくて、こう宣言するからには、ある程度の見通しが立ったからこそです。

国際化対応への手懸り発見

いつものようにグーグルで調べていたら、色々参考情報が出てきた。たとえば　⇒　参考１　参考2　参考3

要するに、

国際化対象にしたい文字列を_(…)で囲んでおいて、指定した文字列に対する翻訳文を別ファイルで用意しておけば、gettextという仕組みを使える

というものであるらしい。なんとなく理解はできたのだが、作業量がどのくらいになるのか、さっぱり見当がつかない。

手懸りその1:

Properties - -app-_170

DEXCSランチャーやTreeFoamでは、操作用のGUIパネルをwxGladeというツールを使って設計し、ボタンやテキストボックスなどのGUIボタンに特定の機能（名前や関数名）を割り付けておいて、最終的に、右図中①の、Generate codeのボタンを押せば、pythonの実行プログラムを生成してくれるという仕組みを使っている。割りつけた関数名の中味については、wxGlade自体何もしてくれないが、そこだけを自分でプログラミングすれば、全体としてちゃんと動いてくれるようにしてくれるというものです。

ここで、これまで何気に意識していなかった、②の、Enable gettext support で、チェックマークを付けてコード生成したところ、、、なんと、ボタンなどで表示されるテキスト部分が、すべて、_(…)で囲われて生成してくれることが判ったという次第。

つまり、DEXCSランチャーもTreeFoamもベースは国際化対応のプラットフォームで作成出来ていた。あとは、自分で書き足した部分のテキスト部分を_(…)で囲ってやればよいということでした。

これなら、なんとかなりそう・・・・

 

手懸りその2:

昨年のオープンCAEシンポジウムで、「Salome-Mecaの日本語化」の発表があり、そのなかで、 Web上での訳語登録システムの紹介がありました。この資料の中では「開発中」とありましたが、実はつい最近、これによく似たシステムで、実際に訳文を入力するという作業を経験したばかりです。

少し前に、DEXCSを外付けのUSBドライブにインストールする際に、ブートローダーが壊れてしまう問題に遭遇、その時に、Boot-Repairなるツールがあって、結果的にこれで解決することは出来なかったのですが、解決できない場合に開発者にメールを送れば相談に乗ってくれる…とあって、開発者とは、少しやりとりしたという経験があります。

その際に、向こうもボランティアでやっているので、どうやって貢献してくれるんだ？となって、寄付でも良いが、国際化の為の翻訳でも良い、といって紹介されたページがあり、実際にここでいくつか訳文を書かせてもらうことになった。

ということで、この DEXCS / TreeFoam 版を作れば良さそうだ・・・ということです。

 

最後に、本題とはそれるかもしれませんが、、、

DEXCS for OpenFOAM(R)の目指すGUI

DEXCS2012 for OpenFOAM(R)のリリースノートにも書きましたが、

DEXCS for OpenFOAM(R)は、OpenFOAMと、これをより簡単・高度に活用できるようにする為の様々なツールをすべてインストール済のオール・イン・ワンパッケージで、誰でも簡単・即使えるようにしたマシンイメージ（isoファイル）です。

ということで、主体はOpenFOAMであり、それを支える様々なオープンツールです。それらツール間連携を、コマンドラインでなくGUIで出来るようにさせることが主眼であり、連携に際して、どうしても足りない部分は自作する、という方針で作成してきました。

当初は初心者に使ってもらうことを最優先

として、DEXCSランチャーやWinkチュートリアルの充実につとめてきました。しかし、これで初心者の壁を乗り越えられたとして、その次に来るのは、自分がやりたい計算をどうやったら出来るんだ？という問題です。

ランチャーを改造すれば出来るようになるうんだろうけど、それは初心者に出来ることではありません。その前にOpenFOAMのファイル構造やプログラムに対する総括的な知識が必要になります。その為には、マニュアルやソースコードを見たり、多分、チュートリアルを実際に動かしてみて・・・というのが一番の近道でしょう。

OpenFOAMの勉強をすぐに出来る環境を提供

できていた、という意味でDEXCSを褒めてもらう場合も少なからずありました。しかし、これを自得するには、Linuxのコマンドライン操作の壁があります。OpenFOAMを使って、自分なりのプログラミングをやりたいと思う人もいれば、標準ソルバー、もしくは誰かが作ってくれたソルバーを使えれば良いと考える人も多くいます。前者の人にとって、この壁は嫌でも乗り越えなくてはならない壁であるのに対して、後者の人にはそうではありません。この壁を乗り越えられないが為に辞めてしまったという人が多くいます。特に企業内ユーザーには、コマンドライン入力が必要と聞いただけで敬遠されてしまいます。

ところで、OpenFOAMのユーザーって？

現時点で目に見えるユーザーの数では前者が多く、ワークショップでの発表を見てもそういう人達によるものが多いという実態ですが、潜在ユーザーの数を考えたらどうでしょう？　後者の数が圧倒的に多いことは間違いないでしょう。

管理人は在職時代から、そういう人達に向けてのオープンCAE活用を推進してきました。ここで、ひとくちに「そういう人達」といって、実はこの中味も色々で、様々な観点で層別できるのですが、管理人は大きく、次のように分類しています。

  1. CAEを単なる設計ツールとして利用したい設計者
  2. CAEを設計の為の思考・検証ツールとして利用したい設計者
  3. 解析専任者（請負解析専従）
  4. 解析専任者（設計者CAE支援）

1.と2.の違いは、必ずしも明確ではありません。次のように言い換えても良いかもしれません。業務プロセスの中でCAEをやることが必須の場合、これを自分でやろうとする人（=2.）か、よほど簡単なツールでない限り、解析専任者や外注先にやってもらおうとする人（=1.）かの違い。

ここまでの前置きが長くなってしまいましたが、DEXCSが想定するユーザーは2.であり、また1.のユーザーが使ってくれるような設計ツールを作れるようになりたい人（=4.）であるという点を改めて強調したいということです。（話はそれますが、当サイトのキャッチコピーになっているSmart Engineer というのも、これらの人を指しています）

商用ソフトとはターゲットが違う

正直いって、3.の請負解析に専従する人のニーズに応えられるものを目指すものではありません。これは商用ソフトを使ったほうが良い。

では、逆に商用ソフトは、DEXCSの想定するユーザーのニーズに応えられているのでしょうか？　そうでもない。請負の解析専任者CAEと、設計者CAEの決定的な違いは、ユーザーがCAEツールと接している時間の長さと間隔です。

商用CAEソフトのほとんどは、様々なユーザーの用途に応えられるべく、メニューが複雑に多階層化されており、初期の導入教育を受けない限り、普通の人がすぐに使えるという代物ではありません。

解析専任者、設計者、立場の違い

解析専任者は毎日CAEツールに接しているので、使い込んでいくうちに、そのあたりのツールの使い方にも慣れ、ますます作業効率が上がっていきます。なので、商用ソフトの固定費がかかったとしても、時間短縮効果で十分回収できるわけです。

一方、設計者はどうでしょう？設計や開発という業務プロセスの中で、CAEを使う期間というのはほんの一部分です。図面を描いたり、実験したり、レポート書いたりする期間の方が圧倒的に多くあります。もちろんCAEをやる際には、まとまった期間集中してやって、やるほどにツールに習熟することはありますが、2ヶ月3ヶ月と触らないでいると、すっかり使い方を忘れてしまいます。管理人の歳になると、月でなく週の単位で同じ事になってしまいます。

せめて商用CAEソフトが、一般のパソコンに搭載されている普通のソフト並に、直感的に操作できるようになっていればそうはならないのですが、そういうソフトにはとんとお目にかかったことがありません。

CAEユーザーのニーズは千差万別

であって、商用ソフトはこれらニーズに汎用性で応えるべく複雑に階層化したメニュー体系にならざるを得なかった。DEXCSではここを、そうはしないで、ニーズに応じてカスタマイズできるようにしてしまおう！と考えました。そしてカスタマイズサンプルとして、DEXCSランチャーを公開しました。そして現在は、CAEコンサルタント業の中で、お客様の要望に沿ったカスタマイズ版も製作してきており、それが商用ソフトを導入することに比べれば、相当な格安で出来ることも実証してきたつもりです。

問題は、こういうカスタマイズや、2.の設計者が自分の問題を計算出来るようになるまでに、どれくらいの勉強が必要になるか？　という点です。この問いに対しても、個人差があるので標準的な数字というものはありません。ただ、OpenFOAMの標準的な使い方-コマンドライン入力-だけでやっていたのでは、これを専業にするという意欲でもない限り、非常に効率の悪いことになってしまいます。

これにも作業時間の長さと間隔の問題がつきまといます。毎日のように常套的に使っていない限り、コマンドや、またその入力の順番を、忘れてしまうからです。

管理人もコマンドライン入力が大嫌い

必ずしもOpenFOAM専業というのでないし、そもそもキーボード操作が不得手で、コマンドライン入力を極力少なくしたいという意識で仕事をしている人間です。自身の勉強を通じて、こういうツールがあったら助かる・・・という想いで作ったのが、DEXCS2011からリリースを始めたDEXCS十徳ナイフです。DEXCS2012では、これをTreeFoamとドッキングさせました。

TreeFoamとは

TreeFoamはDEXCSプロジェクトのツールではなく、あくまで個人有志が作成したもの（唯一の公開資料はこちら）をDEXCSで使わせてもらっているものです。今回、DEXCS2012特別版製作に際しては、TreeFoamも最新版を使わせていただきました。TreeFoamもこの半年で大きく進化し、

  • 標準チュートリアルをベースとした、ソルバーやメッシュの簡単入れ替え
  • MultiRegion対応のケースファイル設定機能

といった機能アップがあり、一応今回も、十徳ナイフとドッキングした形でリリースしましたが、十徳ナイフのメニューのいくつかは、すでにTreeFoamで出来るようになってきており、この調子でいけば、間もなくTreeFoamだけで十分なツールになってくれそうです。これが冒頭の理由その3です。

なお、冒頭の理由その2の、CFD Online の記事で、外人さんが、

TreeFoam is a custom solver,

と書いていたのですが、そうではなく、OpenFoamのケースファイルマネージャといった呼び方が適切でないかと思います。

 

それはさておき、

改めてDEXCSが目指すGUIコンセプト

ですが、このTreeFoamが体現してくれています。

TreeFoamはOpenFOAMの初心者には少しばかりハードルが高いかもしれませんが、そこをクリアーさえすれば、かなり痒いところに手が届く便利なツールです。

 

CAEユーザーにとって、本来の理想的なGUIは、ソルバーの中味がわからなくとも、計算したい実際現象と対比した形で、必要なパラメタだけを簡単に入力できるようになっていて欲しいものですが、それをやろうとすると、千差万別のユーザーニーズに応えるべく、非常に複雑なメニューになってしまうのは前述の通りです。

OpenFOAMに限らず、

オープンCAEは、自助努力・自己責任

で使うことが原則です。ライセンス費用を払うかわりに自助努力で勉強する。自己責任を全うする為には、プログラムの中味について、ある程度の理解も前提としたいところです（但し、1.のユーザーはその限りでない）。

逆に、OpenFOAMのファイル構造やパラメタファイルの仕組みなどをある程度理解できるようになれば、やりたい事に応じて必要なパラメタファイルを直接編集してやればいいんだということが理解できるようになります。問題はそれを実施するのに必要な作業量です。自助努力時間を時間コスト換算したら、ライセンス費用より高くなることは珍しくありません。それだけ時間をかけたからには、作業量は商用ソフト並に少なく済む。やりたい事が変わった時に、必要なケースファイルに簡単にたどりつけて、簡単に修正できるようになっていることです。

DEXCSは、そういうGUIを目指しています。

DEXCS2012 for OpenFOAM(R) 特別版

6月20日（木）に実施される、オープンCAEワークショップ2013の講習会で使用予定の、表記のisoイメージが完成、DVD焼付けを依頼中です。

同日より、会場もしくは、オープンCAE学会のWebサイトにて販売される予定です。

ここでは、公開版の同梱プログラムとの違いについて整理しておきます。ご質問、不具合情報などは、本スレッドにぶら下げて（コメント投稿して）下さい。

 ヴァージョンアップしたもの

新規に追加したもの

その他、特記事項

  • 当初、OpenFOAMのヴァージョンアップだけを予定していたのですが、ヴァージョンアップに伴って、ケースパラメタ設定ファイルの変更などがあった為、DEXCSランチャーや、TreeFoamにおいても、ヴァージョンアップ対応が必要になりました。
  • 講習会にて「OpenFOAMのためのメッシュ生成入門」として、様々なメッシュ作成演習が実施されることになり、オープンソースのメッシュツールも、講習では使用しないものも含めて各種組み込むこととしました。
  • サイズが3.8GBとなってしまい、そろそろライブDVDとしてのサイズ限界に近づいてきました。
  • 本isoイメージを使って、仮想マシンを作成するには、ディスク容量として一般的なデフォルトサイズ20GBでは足りません。最低でも25GBは必要になるようです。

 

 

forces problem on OpenFOAM-2.2.x

DEXCS2012 for OpenFOAM-2.1.x をお使いの人で、OpenFOAMを最新の2.2.ｘで使いたいという人向けの情報です。

（DEXCS2012 for OpenFOAM-2.2.xは、６月のオープンCAEワークショップの開催記念に、特別版にてリリース予定です）

基本的に、OpenFOAMを入れ替えて、DEXCSランチャーや、TreeFOAMのソースコード中、OpenFOAMの環境指定部分を2.1.ｘから、2.2.ｘに変更してやれば使えるようになります（詳細は別記事としてアップ予定）。

但し、DEXCSランチャーの標準問題（DEXCSフォント周りの流れ解析）において、OpenFOAMのヴァージョンアップに伴って、表題のforcesやprobes出力など、FunctionObjectに関する仕様変更があった為、これらデータを図化する為のテンプレートケースを変更する必要がありました（変更概要を以下に記しますが、詳細は別記事としてアップ予定）。

OpenFOAM-FunctionObjectの仕様変更

OpenFOAMでは、controlDict中に、

functions
(
forces
{
type                forces;
functionObjectLibs  ( “libforces.so” );
outputControl       timeStep;
outputInterval      1;
patches             (Dexcs_ExportedfromBlender-2.64(sub0));
pName               p;
UName               U;
rhoName             rhoInf;
log                 true;
rhoInf              1.225;
CofR                (0.25 0.007 0.125);
}
)

など記しておけば、上の場合、指定したpatchに加わるforces（流体力）を 出力させることができるようになっていますが、OpenFOAM-2.2.0 以降、この仕組みが少々変更されました。

従来は、ケースフォルダ中に、forcesというフォルダが作成され、その中に時系列データとして出力されていましたが、2.2以降は、postProcessingというフォルダが作成され、その下に、その他のfunctionで指定した、probeやsampleなどのデータも併せて出力されるようになりました。FunctionObjectで出力されるデータを１つのフォルダにまとめて、参照しやすくしたということでしょう。

下図は、DEXCSの標準ケース（DEXCSフォント周りの流れ計算）でのケースファイルの階層を示しており、DEXCS2012 for OpenFOAM において、OpenFOAMを2.2.ｘに入れ替えた場合、右のような計算結果になるということです。

範囲を選択_052

 

したがって、これらの経時データを図化処理する際の、スクリプトにおいても、当該ファイルの参照場所を変更しないと使えないということです。これまでは、ケースファイルを開くとすぐに見えていたforcesやprobesというフォルダがpostProcessingというフォルダの下に隠れてしまって、使えなくなってしまったのか？と勘違いしたところでもあります。

蛇足ながら、swak4Foamを使った類似出力は従来通りです。

 何が問題か

実は、patcheの名前を指定している部分、

patches             (Dexcs_ExportedfromBlender-2.64(sub0));

これが云うことを聞いてくれなくなってしまいました。このpatchの名前は、場の計算をする際に、boundaryの名前としてちゃんと有効になっていることは間違いないのですが・・・

色々調べた結果、名前の中にかっこ記号を含んでいなければ、問題ないことはわかったんですが、まぁ、仕様変更に伴って生じたバグといってよいものでしょう。ただバグレポートを見てもそれらしいものは上がっていません。そもそもpatchの名前の中にかっこ記号を含めるまでは、普通しないだろうから、まだ誰も気づいていない、ということだとは思いますがね。

また、それじゃpatchの名前の中に、かっこ記号を含めなければいいじゃん！　ということにもなるのですが、問題は、blenderを使ってエクスポートしたstlファイルを使うと、どうしてもかっこ記号が付いてしまうということです。patch名中の、_ExportedfromBlender-2.64(sub0)の部分は、blenderが勝手に付けた部分です。

 で、どうする/したか？

ま、一番まっとうな方策は、バグレポートを上げて、OpenFOAMの本体を直してもらうことですが、英語能力の問題もあって、そこは何方かにやってもらうことにして、ここで記しておくのは、DEXCSでは、こういう対処が出来たということです。DEXCSでは、どうせblenderもSwiftツール込みのカスタマイズ版として組み込んであるので、ついでにpatch命名部分もカスタマイズしてしまおう、ということです。

ただ、さすがにblender本体のカスタマイズにまでは手を出せませんが、blenderでstlファイルをエクスポートする部分はaddonスクリプトでやっていることは想像できたので、ここを調べることは、さほど難しくありませんでした。

スクリプトは、scripts/addons/io_mesh_stl/sti_utils.py があって、この中で、 89行目あたり、

def _header_version():
import bpy
return “Exported from Blender-” + bpy.app.version_string

として、この部分がpatchの命名に関わってくることがわかりました。なので、ここを変えてやれば良い。具体的には、

def _header_version():
import bpy
#return “Exported from Blender-” + bpy.app.version_string
return “Exported from Blender”

で良かろ、ってことです。