OpenFOAM-v2412

コメントする / 未分類 / By

OpenFOAM-v2412のAllrunの結果を公開した。総ケース数490（478）、使用ディスク容量：1007GB（約1TB）、総計算時間：約26日（27日）であった。かっこ（）内数字はv2406のもの。

今回も更新された計算環境で実施しており、こちらの記事で並列数を「8」（パフォーマンスコアのコア数）以上に設定しても意味のない事がわかったので、該当ケースは並列数を「8」に変更して実施した。したがって計算速度の面で、v2406との直接比較は少々割り引いて見る必要がある。

計算開始：2025年1月9日9時31分　/　計算終了：2025年2月4日7時41分

Table of Contents

ケースサマリー

基本的に、先の記事に記した方法で、ほぼログ解析まで問題なく実行できた。残された手作業項目もOpenFOAM-ｖ2206（Linuxの場合）と同じであった。その他、実行エラーしたケース等についても、簡単に取り纏めておく。

ログファイル（testLoopReport, logs）中に”ERROR”の出力があったもの

“ERROR”出力は無かったが、計算が発散終了していたもの

（注1）設定ミスでやり直した

（注2）ERRORが出ること自体は問題無い

（注3）Allrunでは正常に計算できていた（ERRORはAllTest）

  • Allrun実行前
    • チュートリアルリスト作成
    • プロセッサ数が不足するケースでのdecomposeParDict変更
    • AllTest実行し、ERRORケース確認
  • ログ解析スクリプト実行前
    • incompressible/pimpleFoam?laminar/cylinder2D ケースの、log.blockMesh.main をlog.blockMesh に変更
  • ログ解析スクリプト実行後
    • ケース名変更
      • combustion/XiFoam/RAS⇒combustion/XiFoam/RAS/moriyoshiHomogeneous
      • compressible/sonicLiquidFoam⇒compressible/sonicLiquidFoam/decompositionTank
    • ディスクスペースの重複カウント修正
      • IO/fileHandler
      • compressible/rhoPimpleFoam/laminar/helmholtzResonance

データベースのグラフ化例

別記事で記した通り、上記データベース化されたデータはバックボーン（phpMyAdmin）で動的にグラフ化できるようになっているが、現在のところ閲覧者が動的にグラフを作成する仕組みまでは出来ていない。HP管理者が、本結果（OpenFOAM-v2412）を中心に様々な観点で作成したグラフをいくつか紹介しておく。

使用したSQL構文

使用したSQL構文

使用したSQL構文

使用したSQL構文

使用したSQL構文

使用したSQL構文

使用したSQL構文

使用したSQL構文

上図で、変化のなかったライン（x1）から大きく乖離したケースについて番号付きの角矢印記号を付しておいた。以下の項目中の行頭（）中の数字はその番号に併せてある。また、赤字で記したものは、計算時間が大きくなったもので、それ以外は短くなっている。

ケースファイルの内容が変化していたもの

  • (3)finiteArea/liquidFilmFoam/cylinder
  • (9)mesh/snappyHexMesh/distributedTriSurfaceMesh
  • (6)multiphase/overCompressibleInterDyMFoam/compressibleTwoSimpleRotors
  • (7)multiphase/overInterPhaseChangeDyMFoam/twoSimpleRotors
  • (8)verificationAndValidation/atmosphericModels/atmFlatTerrain
  • (17)multiphase/cavitatingFoam/LES/throttle3D

実行時並列数が異なるケース

  • (1)IO/cavity_parProFiling
  • (5)incompressible/adjointOptimisationFoam/topologyOptimisation/monoFluidAero/turbulent/1_Inlet_2_Outlet/levelSet/R_05x_NB_01
  • (7)incompressible/pimpleFoam/laminar/cylinder2D
  • (10)incompressible/adjointOptimisationFoam/topologyOptimisation/monoFluidAero/laminar/3DBox/losses
  • (11)incompressible/adjointOptimisationFoam/topologyOptimisation/monoFluidAero/laminar/3DBox/losses-mass
  • (14)incompressible/lumpedPointMotion/bridge
  • (15)incompressible/adjointOptimisationFoam/topologyOptimisation/monoFluidAero/laminar/3DBox/losses-mass-uniformity
  • (16)incompressible/adjointOptimisationFoam/topologyOptimisation/monoFluidAero/laminar/3DBox/losses-mass-uniformity-SQP
  • (19)incompressible/pimpleFoam/LES/periodicHill
  • (20)incompressible/pimpleFoam/LES/planeChannel

その他（変化理由不明）

  • (2)mesh/foamyHexMesh/flange
  • (4)heatTransfer/chtMultiRegionFoam/externalSolarLoad
  • (12)lagrangian/kinematicParcelFoam/drippingChair
  • (13)heatTransfer/chtMultiRegionTwoPhaseEulerFoam/solidQuenching2D
  • (18)incompressible/adjointOptimisationFoam/shapeOptimisation/motorBike

後のまつり（データ整理してからわかった事）

先の記事で、現在の計算サーバーではプロセッサ数が「8」を超える多並列計算ケースについて、そのままでは速度が低下することがわかっていたので、今回は並列数「8」となるようsystem/decomposeParDict を変更して実行した。変更したほとんどのケースにおいて、v2406での計算（こちらは変更していない）に比べて速度向上が見られたが、一部に設定ミスがあったので、次々回（次回分はすでに進行中につき間に合わない）の参考とすべく、ここに記しておく。

IO/cavity_partProfiling

デフォルトでは、decomposeParDict が以下に示すようにnumberOfSubdomains 「20」( Np=20 ）となっており、これを 「8」 として実行したが、エラー終了してしまった。

				
					numberOfSubdomains  20;
method              scotch;
coeffs
{
    // Divide into 20/10=2 nodes
    domains (10);
    // Inside a node the communication weight is 1% of that inbetween nodes
    domainWeights (0.01);
}

method が scotch となっていたので、この numberOfDomains 数字だけを変えれば良いだろうと早とちりした。よく見れば、その下の coeffs のブロックも書き換えが必要であった。

incompressible/adjointOptimisationFoam/sensitivityMaps/motorBike
iincompressible/adjointOptimisationFoam/shapeOptimisation/motorBike

上記2つのケースは、デフォルトで並列数「20」の計算になっているが、これを見落とした。理由は、多並列計算ケースを抽出するのに、decomposeParDict をテキストサーチしていたのだが、これらのケースは、decomposeParDict でなく、decomposeParDict.20 というファイルで並列数が指定されていた為。

ExecutionTime or ClockTime

個別のケースでバージョン比較するのに、これまでexeTimeを使って比較してきたが、並列数が異なっていると exeTime による比較は判断を誤らせる。例えば今回の incompressible/adjointOptimisationFoam/topologyOptimisation/monoFluidAero/laminar/3DBox/losses-mass-uniformity-SQPの場合、

  • v2406（Np=60）では
    • ExecutionTime = 4521.87 s ClockTime = 9277 s
  • v2412（Np=8）では
    • ExecutionTime = 5702.8 s ClockTime = 5704 s

当初は、従来通りexeTimeによる比較グラフを見ていておかしい（悪化した？）ことに気づき、clockTimeによる比較グラフに差し替えた。

その他気付いた点

メッシュユーティリティー

v2412の新規チュートリアル（全12）のうち、約半数（7）はメッシュ関連であった。個人的に興味をそそられたのは以下の2ケース。

4つのブロック（central, inlet, top, bottom）でメッシュを個別に作成しておいて、メッシュをマージ（mergeMesh）し、接合部を cyclicAMI で連通できるようにしたケース。

ポイントは接合部の面の大きさが異なっているという点である（面が同一サイズであれば、これまでも可能であった）。これを実現する為には createPatchDict を参考にせよ…ということらしい。パット見ただけであるが、かなり難解であった。チュートリアルケースはblockMeshで作成したメッシュを対象としているが、そうでなくとも（たとえばcfMeshでも）可能と思われる。機会があれば使ってみたい。

下図、左側のメッシュをblockMesh で作成した後、moveDynamicMeshコマンドで右側のようにメッシュ変形させたもの。

もちろん、右側のメッシュにすべく参照形状データ（.obj ファイル）は予め用意してある。Allrun の内容を調べると、何となくやっていることの想像はできる。自分でやってみようとまでは思わない（そもそも左側のblockMeshを作る段階で諦める）が、構造メッシュおたくさんには是非とも紹介したいテクニックである。

foamyHexMesh

foamyHexMesh は永らくの間、開発が中断されていたと思われるが、今回のバージョンでは、わずかであるが変化があった。同梱チュートリアル全5例のうち、これまでエラーで動かなかったケースが2例（flange, simpleShapes）動くようになり、動いていたケース（straightDuctImplicit）も作成されるメッシュが従来とは変化していた。但し、もっとも実用的というか複雑なケース（mixerVessel）は依然としてエラーで動かない。

optimisationDict

adjoinOptimisationFoam 関連のチュートリアルケースには多並列計算が多く存在し、並列数を「60」から「8」へ変更した際のExecutionTimeの変化（悪化？）については先の項で記した通りであるが、実はv2406との比較において、ケースファイルパラメタそのものに相違点が存在した。KDiff3を使って、

  • adjointOptimisationFoam/topologyOptimisation/monoFluidAero/laminar/3DBox/losses-mass/system/optimisationDict　

ファイルを比較したのが下図である。

これも当初は、exeTimeが変化した原因かと早とちりした。バグフィックスだったかもしれないが多分、大勢には影響が無いと推察している。

the Next Allrun

実は、ほんの1週間前に計算サーバーを更新し、早速ながら新たにAllrunを実行中である。何が出てくるか、乞うご期待。

補足（SQL文、備忘録）

SQL-1

				
					select `ver_name` version,
 count(*) postcount,
 sum(`clockTime`)/3600 clockHr,
case when exe_system = 4 then 0.5* sum(`diskUsage`)/1000000
else  sum(`diskUsage`)/1000000 
end as du,
 sum(`clockTime`)/3600 ,
`name` exeSys,
`release_date`
 from `of_tutorials`
JOIN of_ver ON of_tutorials.of_ver = of_ver.id
JOIN of_exe_system ON of_tutorials.exe_system=of_exe_system.id
group by `exe_system`, `of_ver`
order by `release_date`

SQL-4

SQL-5

				
					DROP TABLE IF EXISTS of_temp;
create table of_temp as

with old_data 
as( select category as o_category, solver as o_solver, model as o_model, caseName as o_caseName,diskUsage as o_diskUsage ,exeTime as o_exeTime ,clockTime as o_clockTime from `of_tutorials` where of_ver in (32) )

select  new.category, new.solver, new.model, new.caseName, new.diskUsage, old.o_diskUsage, new.exeTime, old.o_exeTime , new.clockTime, old.o_clockTime 

from 
 of_tutorials as new 
 inner join old_data old
  on new.category = old.o_category 
  and new.solver = old.o_solver 
  and new.model = old.o_model 
  and new.caseName = old.o_caseName 
where new.of_ver in (33)
order by new.category, new.solver, new.model, new.caseName 
;
select category, solver, model, caseName,  diskUsage/1000, o_diskUsage/1000, exeTime, o_exeTime , clockTime, o_clockTime from of_temp
where exeTime > 0
;

SQL-6

				
					DROP TABLE IF EXISTS of_temp;
create table of_temp as

with old_data 
as( select category as o_category, solver as o_solver, model as o_model, caseName as o_caseName,diskUsage as o_diskUsage ,exeTime as o_exeTime ,clockTime as o_clockTime from `of_tutorials` where of_ver in (32) )

select  new.category, new.solver, new.model, new.caseName, new.diskUsage, old.o_diskUsage, new.exeTime, old.o_exeTime , new.clockTime, old.o_clockTime 

from 
 of_tutorials as new 
 inner join old_data old
  on new.category = old.o_category 
  and new.solver = old.o_solver 
  and new.model = old.o_model 
  and new.caseName = old.o_caseName 
where new.of_ver in (33)
order by new.category, new.solver, new.model, new.caseName 
;
select category, solver, model, caseName,  diskUsage/1000, o_diskUsage/1000, exeTime, o_exeTime , clockTime, o_clockTime from of_temp
where diskUsage < 50000000
;

コメントする

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です