OpenFOAM-v2412 新々サーバーでやってみた

先の記事はOpenFOAM-v2406を題材に、新サーバー(E.Mogura’s 2024 Server / Intel Core i9-14900K)と、新々サーバー(E.Mogura’s 2025 Server / AMD Ryzen 9 9950X)の比較であったが、本記事ではOpenFOAM-v2412を題材にしたものである。

基本的に、先の記事(v2306に記した方法に加えて、並列数が8を超えるケースについては並列数を変更した上で、ほぼログ解析まで問題なく実行でき、残された手作業項目や、実行エラーしたケース等についても全く同一であった。

2025-05-18 19:31:39 +0900(Start) / 2025-06-06 19:04:26 +0900(Finish)

総計算時間 462Hr(旧計算環境では618Hr)

データベースのグラフ化による比較

念の為、ディスク使用量の変化についても調べたのと、カテゴリ別、チュートリアルケース毎で計算時間の比較を実施した。

カテゴリ別ディスク使用量の比較(新旧計算サーバー)

念の為、ディスク使用量の違いについても調べたが、ほとんど同じであり、間違いなく同じ計算をしていることは確認できたと言えるだろう。

使用したSQL構文

ほとんど同じと記したが、わずかに増加しているようにも見える。この点に関しては個別ケース毎の比較で改めて調べている。

トータルの計算時間としては、100時間強短くなっていたが、incompressibleを除くほとんどのカテゴリで計算時間が1/2〜1/3になっているのに対して、incompressibleのカテゴリでは、計算時間が増えてしまっていた。

使用したSQL構文

新サーバーで実質有効なコア数は8であり、新々サーバーでは16であるので、並列数が8以下の計算ケースとそうでないケースを区別して比較するのが妥当であろうと考え、以下のように取り纏めた。

並列数(Np)別ClockTime比較_v2412

clockTime(Hr) Np<=8 Np>9
2025 Server 163(188) 300(274)
2024 Server 218(228) 401(421)
変化(%) 74.7 (82.6) 74.9(65.1)

かっこ()内の数字はv2406での値

やはり高並列数ケースでの計算時間短縮効果が大きいところを見てとれたが、そうでないケースでの短縮効果も予想以上に大きかった。但し、v2406での傾向とは、同様とは言い難い。

並列数が8を超えるケースでの比較はあまり意味が無いので、8以下のケースについて、個別ケース毎に比較した。

使用したSQL構文

図中には、等速ライン(x1)も記してある。全平均として小さくなっている(v2406の場合は82.6%であった)ところまでは良しとしても、74.7%となるようには見えないが、これは、個別のケースで見たNo.2の低下量が大きいからであり、個別のケースで見ると、v2406の時と同様やはりかなりばらつきが大きい。

参考までに、図中の番号を付したケースの名前を、計算時間が短縮したケースと、増加したケースとを区分して記しておく。

計算時間短縮したケース(黄色番号)

  1. incompressible/pimpleFoam/LES/surfaceMountedCube(8)
  2. lagrangian/DPMFoam/Goldschmidt(6)
  3. multiphase/interFoam/laminar/vofToLagrangian(4)
  4. incompressible/pimpleFoam/RAS/propeller(4)
  5. incompressible/simpleFoam/turbulentFlatPlate(1)
  6. multiphase/compressibleInterFoam/laminar/depthCharge3D(4)
  7. compressible/acousticFoam/obliqueAirJet(6)
  8. lagrangian/MPPICFoam/Goldschmidt(5)
  9. verificationAndValidation/atmosphericModels/atmDownstreamDevelopment(8)
  10. multiphase/interIsoFoam/iobasin(8)
  11. multiphase/interFoam/laminar/waves/stokesII(2)

計算時間増加したケース

  1. multiphase/interFoam/laminar/waves/irregularMultiDirection(2)
  2. lagrangian/sprayFoam/aachenBomb(1)
  3. combustion/reactingFoam/laminar/counterFlowFlame2D_GRI(1)
  4. combustion/reactingFoam RAS/SandiaD_LTS(1)
  5. lagrangian/icoUncoupledKinematicParcelFoam/hopper(4)
  6. incompressible/ pimpleFoam/RAS/wingMotion(4)
  7. discreteMethods/dsmcFoam/supersonicCorner(4)
  8. combustion/reactingFoam/laminar/counterFlowFlame2D_GRI_TDAC(1)
  9. multiphase/MPPICInterFoam/twoPhasePachuka(4)
  10. incompressible/overPimpleDyMFoam/twoSimpleRotors(1)
  11. discreteMethods/molecularDynamics/mdEquilibrationFoam/periodicCubeWater(1)
  12. combustion/reactingFoam/laminar/counterFlowFlame2DLTS_GRI_TDAC(1)
  13. incompressible/adjointOptimisationFoam/topologyOptimisation/monoFluidAero/laminar/1_Inlet_2_Outlet_Dual_Bottleneck/losses-mass-30-70(4)
  14. incompressible/adjointOptimisationFoam/topologyOptimisation/monoFluidAero/turbulent/1_Inlet_2_Outlet/levelSet/R_10x_NB_02(4)
  15. incompressible/adjointOptimisationFoam/topologyOptimisation/monoFluidAero/laminar/1_Inlet_2_Outlet/porosityBased/R_10x-init(4)
  16. incompressible/adjointOptimisationFoam/topologyOptimisation/monoFluidAero/laminar/1_Inlet_2_Outlet/porosityBased/R_20x(4)
  17. incompressible/adjointOptimisationFoam/topologyOptimisation/monoFluidAero/laminar/1_Inlet_2_Outlet/levelSet/R_10x_NB_02x(4)
  18. incompressible/adjointOptimisationFoam/topologyOptimisation/monoFluidAero/laminar/1_Inlet_2_Outlet/levelSet/R_10x_NB_01x(4)

リスト中、太字で記したのは、v2406での新旧サーバー比較記事でも抽出されたものである。

計算時間が短縮したケース中、2番と8番は、v2406の比較ではなかったものであり、大きく低減したのは、並列計算の効果である(新サーバーでは単体計算であった)。

また、計算時間の増加したケースのリスト中、15番以降は、adjoiintOptimizationFoamソルバーを使ったケースであり、図を見ると抽出した番号の近くには、他にも多くのケースのあることがわかる。これらもやはり同一ソルバーのケースであった。

カテゴリー別ディスク使用量を比較した場合、ほぼ同一と記したが、わずかな違いがあるようにも見られた。そこで個別のケース毎にも調べてみた。

全体グラフで見ると、やはり違いはわからないが、以下のように詳細化して明確になった。

明らかに変化なし(x1)のラインからオフセットしたケースが多く存在していた。これらのケースは、ほとんどが、前項の最後の方に記したadjoiintOptimizationFoamソルバーを使ったケースであった。

つまりこれらのケースは新々サーバーにおいて、新サーバーで実行した場合より、余分な計算を実行しており(逆に言うと新サーバーで計算していない部分があった)、その為計算時間も増えたと解釈できる。

新サーバーでの計算ログは残っていないので推察でしかないが、これらのケースの実行内容を調べたところ、思い当たるふしも出てきた。これらのケースのAllrunは以下の内容となっている。

				
					#!/bin/sh
cd "${0%/*}" || exit                                # Run from this directory
. ${WM_PROJECT_DIR:?}/bin/tools/RunFunctions        # Tutorial run functions
#------------------------------------------------------------------------------

runApplication blockMesh
runApplication topoSet
runApplication setsToZones -noFlipMap
runApplication decomposePar
runParallel $(getApplication)

if [[ ! -z $(which cartesian2DMesh) ]]
then 
    echo "Re-evaluating topO solution on a body-fitted grid"
    cd reEval
        ./AllrunReEval > log.AllrunReEval 2>&1 && echo "End" >> log.AllrunReEval 
    cd ..    
fi

#------------------------------------------------------------------------------

				
			

ここで16行目で、/AllrunReEval を実行することになっているが、新サーバーでは、この部分のログ集計がなかった(実行されていなかった)ということである。これは12行目で「cartesian2DMesh(いわゆるcfMesh)」の有無を調べているが、これが存在しなかった為と考えられる。v2412のcfMeshは現時点の更新版には存在するが、リリース直後のバージョン(新サーバーで実行した時点)では、これが存在しなかったという記憶である。

追加計算

念の為、新サーバー(2024Server)において、adjointOptimisationFoamソルバーを使って、かつcfMeshも使うケースの代表例として、以下のケースを再計算してみた(下表の一番右側の列)。

adjointOptimisationFoam/.../R_05x_NB_01x

2025Server 2024Server
実施年月 2025/5 2025/2 2025/8
R_05x_NB_01x clockTime 50 50 48
diskUsage 36,128 30,324 36,008
reEval clockTime 11 0 11

reEval のフォルダでの計算が実行され、2025Serverでの結果と、ほぼ同一になることを確認できた。

結論と今後

新々計算サーバー(Ryzen 9 9950X)において、新計算サーバー(Core i9-14900K)に対して、全体として約25%の速度向上が見られた。この数字の中には一部の単体計算を並列計算に変更した効果も含まれているとはいえ一般的なCPUベンチマークの数字とは、かなりかけ離れている。

但し個々のケースで見比べると、バラツキが大きく、速度が低下するケースもある。また、v2406で比較した場合に比べて、個々のケースで変化量として大きく異なるケースにいくつか共通点は見られたものの、全体としての傾向がやや異なる点など不明点も残っている。

なお、adjointOptimisationFoamソルバーを使って、かつcfMeshも使うケースは多くあり、今後の新しいバージョンで実施する場合は、cfMeshのインストール有無は要確認である。

CPUベンチマーク

参考までに、PassMarkのCPUベンチマークの結果を以下に転載しておく

Core i9-14900K

AMD Ryzen 9 9950X

SQL-1

				
					select `ver_name` version,
 category,
 count(*) postcount,
 sum(`diskUsage`)/1000,
 sum(`clockTime`)/3600 ,
`name` exeSys,
`release_date`,
case when exe_system = 4 then 0.5* sum(`diskUsage`)/1000000
else  sum(`diskUsage`)/1000000
end as du
 from `wp_of_tutorials`
 JOIN of_ver ON wp_of_tutorials.of_ver = of_ver.id
JOIN wp_of_exe_system ON wp_of_tutorials.exe_system=wp_of_exe_system.id
where of_ver.id in (33)
group by `exe_system`, `of_ver` ,`category`
order by `exe_system`
				
			

SQL-2

				
					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, Np as o_Np from `wp_of_tutorials` where of_ver in (33) and exe_system in (7))

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

from 
 wp_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) and exe_system in (8)
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, Np, o_Np from of_temp
where clockTime<5000000 and Np <9;
				
			

コメントを残す

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

このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください

上部へスクロール