icoUncoupledKinematicFoam/hopperEmptying(2.2.x VS 2.3.x)

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

範囲を選択_472

 

計算時間の内訳分析

これらのケースの計算時間について、ログファイルを分析(foamSolverSweep)すると、以下のようになりました。

範囲を選択_359

計算ステップ数は同じなのに、計算時間が大きく異なっており、かつ増えている点は気がかりです。

 

計算結果を見れば納得

左側の旧ヴァージョンでは、粒子の排出が急速に進行しており、粒子間の相互作用の計算量そのものが少なくなっている、ということでしたね。しかも粒子の減少の仕方に所々異常な振る舞い(瞬間的な減少)が見られます。しかるに右側の新ヴァージョンではほぼ一定量が徐々に減少していくという、まぁ自然な挙動です。

 

ケースファイルの変化点

範囲を選択_477

そこでケースファイルの変化点を調べてみると、kinematicCloudPropertiesに若干の相違があったものの、本質的な違いとも思われませんでした。

 

検証計算

念の為、これらもケースファイルを新旧入れ替えて、計算をやり直してみました。

  • 2.2.x(w/23sys)—2.3.xのケースファイルを使って、2.2.xにて計算
  • 2.3.x(w/22sys)—2.2.xのケースファイルを使って、2.3.xにて計算

範囲を選択_478

範囲を選択_479

 

計算時間、計算結果ともに、ケースファイル(kinematicCloudProperties)の相違による違いはあるものの、やはりその差は僅か・・・といったところでしょうか。

結論(わかったことと所感)

計算速度が遅くなったということではなく、ちゃんと計算できるようになった・・・と見るべきでしょうね。

ちなみに、新ヴァージョンのリリースノート中、Discrete Particle Modellingやら、Physical Modellingあたりに、Particle関連の更新内容が記されていますが、本ケースでどの効能が現れることになったとかは、浅学にして不明です。

chemFoam/nc7h16(2.2.x VS 2.3.x)

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

範囲を選択_471

 

計算時間の内訳分析

これらのケースの計算時間について、ログファイルを分析(foamSolverSweep)すると、以下のようになりました。

範囲を選択_443

計算ステップ数が増えたのにも拘らず、計算時間が大きく減少しています。

 

計算結果も良くなった!

範囲を選択_473

本チュートリアルは場の計算ではなくて、単一要素にて反応計算を行い、chemkinの式と比較していますが、明らかに精度が良くなっていることが判ります。

 

ケースファイルの変化点

ケースファイルの変化点を調べてみると、chemistoryPropertiesにありました。odeCoefs のsolverが、SIBXからseulexに変更されているあたりが気になります。

範囲を選択_474

検証計算

これらもケースファイルを新旧入れ替えて、計算をやり直してみました。

  • 2.2.x(w/23sys)—2.3.xのケースファイルを使って、2.2.xにて計算
  • 2.3.x(w/22sys)—2.2.xのケースファイルを使って、2.3.xにて計算

範囲を選択_475

 

2.2.x(w/23sys)で計算不能、つまりsolver:seulexというのは今回のヴァージョンで新しく登場したものだということです。

しかも、2.3.x(w/22sys)つまり旧ヴァージョンと同一設定で計算しても計算時間が減少しており、かつ計算精度も向上(下図参照)していることがわかりました。

範囲を選択_476

結論(わかったことと所感)

本チュートリアルでは、ヴァージョンアップによって明らかな性能向上(速度・精度アップ)が見られました。

当初、新ヴァージョンのリリースノートを見ていても、よく判らなかったのですが、先日の勉強会でTMさんからちゃんと書いてあるよと教えていただき、調べなおしたら、確かにNumerical MethodsのOrdinary Differential Equation Solversのセクションに記してありました・・・が、チュートリアルケース名が例示されていなかったので気づきませんでした・・・(例示してくれよ!)ということです。

pimpleFoam/elipsekkLOmega(2.2.x VS 2.3.x)

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

範囲を選択_459

 

計算結果は大体同じ

速度分布などの結果(下図)は大体同じですが、微妙な分布の違いは認められます。まぁ非定常計算なので、このくらいの違いはあっても・・・の感。

範囲を選択_403

 

計算時間の内訳分析

これらのケースの計算時間について、ログファイルを分析(foamSolverSweep)すると、以下のようになりました。

範囲を選択_360

計算ステップ数はあまり違わないのに、計算時間が大きく異なっています。その要因は圧力計算の回数が約1/4とかなり少なくなっていることが考えられます。ただ、この減少割合は、先に調べたsimpleFoam/pitzDaily,pitzDailyExptInletの例に比べて、それほどではありません。

ケースファイルの変化点

そこでケースファイルの変化点を調べてみるとfvSolutionに変化点がありましたが、ここではsimpleFoam/pitzDaily,pitzDailyExptInletの場合ほどにはドラスティックなものではなさそうです。

範囲を選択_461

あと、もう1点。本ケースでは対称境界を使用しているのですが、その書式が変更になったようです。

範囲を選択_462

 

検証計算

fvSolutionの変化は、先に調べたsimpleFoam/pitzDaily,pitzDailyExptInletの例に比べてさほどドラスティックではありませんでしたが、これらもケースファイルを新旧入れ替えて、計算をやり直してみました。

  • 2.2.x(w/23sys)—2.3.xのケースファイルを使って、2.2.xにて計算
  • 2.3.x(w/22sys)—2.2.xのケースファイルを使って、2.3.xにて計算

ただし、対称境界の書式についてはヴァージョン互換性がないので、この部分だけはヴァージョンに合わせて手修正しました。

範囲を選択_463
範囲を選択_460

 

結論(わかったことと所感)

計算時間についてはほぼ予想通りの結果となりましたが、計算結果については何とも微妙です。

つまり計算速度の差はsimpleFoam/pitzDaily,pitzDailyExptInletの例と同じで、ソルバーの性能が変化したからということではなく、ケースファイルの解法パラメタの設定(fvSolution)が変更されたからに他なりません。

ただ、追加で(ケースファイルを入れ替えて)計算した結果は、かなり異なっているようにも見受けられ、その違いをfvSolution,対称境界あるいはヴァージョンの違いでもってしても、何とも説明できません(たとえば中段の2つの結果を入れ替えてみればfvSolutionの違いと説明できそうですが・・・)。

これらの結果をあえて説明するなら、4つの結果は2つのパターンに分類できそうに見受けられてしまいますが、たまたまそう見えるだけで、4つとも微妙に異なっていると解釈すべき・・・なのかなぁ?

 

simpleFoam/pitzDaily,pitzDailyExptInlet(2.2.x VS 2.3.x)

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

範囲を選択_456

 

計算結果はほとんど同じ

速度分布などの結果(下図)はほとんど同じですが、定常解に達するまでのステップ数がわずかに異なっています。

 

範囲を選択_418 範囲を選択_419

 

計算時間の内訳分析

これらのケースの計算時間について、ログファイルを分析(foamSolverSweep)すると、以下のようになりました。

 

 

範囲を選択_349計算ステップ数はあまり違わないのに、計算時間が大きく異なっています。その要因は圧力計算の回数が大幅に少なくなっていることが考えられます。

ケースファイルの変化点

そこでケースファイルの変化点を調べてみると・・・案の定でした。fvSolution で、圧力方程式のsolverが、PCGからGAMGに変更されておりました。範囲を選択_457

検証計算

問題はGAMGは2.3.xで使えるようになったという代物ではないということです。ということは、2.2.xで、新しいケースファイルを使ってやれば【2.2.x(w/23sys)】、また逆に、2.3.xで古いケースファイルを使ってやれば【2.3.x(w/22sys)】、同等の結果になることが予想されるので、これらを追加計算してみました。

範囲を選択_458

 

結論(わかったことと所感)

結果は予想した通りで、計算速度の差はソルバーの性能が変化したからということではなく、ケースファイルの解法パラメタの設定(fvSolution)が変更されたからに他なりません。

では、何故かような変更がなされたか? 今更の感はありますが、古くからのチュートリアルケースも地道に見直して、より実用的なパラメタセットに変更しているんだろうな・・・と好意的に解釈してあげたいものです。

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.xのsnappyHexMeshDictを用いて2.3.xで実行
  • case3 — 2.3.x標準チュートリアルにてnFSI(nFeatureSnapIter)の値のみ変更
  • case5 — 2.3.xのDictを用いて2.2.xで実行

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

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

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

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

implicitFeatureSnap

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

範囲を選択_394

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

その他のケース

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

範囲を選択_395

総じて、

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

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

範囲を選択_396

範囲を選択_397

範囲を選択_398

範囲を選択_399

範囲を選択_400

範囲を選択_401

その他の所見

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

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

範囲を選択_402

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

最後に

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