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

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

先の記事（v2406）では、ｖ2312との比較をしたが、使用した計算サーバーが異なっていたので、特に計算速度の比較において、あまり意味のないものになっていた。そこで本記事では、純粋に計算サーバーの比較を目的に、OpenFOAMのバージョンをv2306で固定し、計算サーバーによる違いについて調査した結果について取りまとめている。

基本的に、先の記事（v2306）に記した方法で、ほぼログ解析まで問題なく実行でき、残された手作業項目や、実行エラーしたケース等についても全く同一であった。

総計算時間　639Hr（旧計算環境では764Hr）

 

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

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

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

使用したSQL構文

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

使用したSQL構文

個別のケースについて、新旧の計算サーバーでの計算時間（sec）を散布図としてプロットした。横軸が旧計算サーバー（Dual Xeon Gold 6130）、縦軸が新（Core i9-14900K）の計算時間 Execution Time (sec）である。

参考に、等速（x 1）と3倍速（x 3）のラインも示しておいたが、（特に計算時間が1時間以下であるケース）データの大半は、3倍速のラインにプロットされているのに対して、所々大きくずれるケースが散在していた、3倍速のラインから大きく乖離したケースについては、チュートリアルケース名も記しておいた。

グラフは全4枚あるが、下の方になるにしたがって計算時間が長いケースについて取りまとめたものとなっている。

使用したSQL構文

一番下がもっとも計算時間のかかるケースについてとりまとめたもので、上位3点がカテゴリーincompressible のもので、その内2点は計算時間が長くなってしまっており、これが要因となってカテゴリーincompressible の計算時間が長くなっていたことがわかる。

その他ケース名を色分けしてあるのは、等速ラインに近いものをピンクで、3倍速〜等速ライン中間のものを薄黄色、3倍速ラインに近いものを薄緑色で区別した。

ケース名の後のカッコ内の数字は、並列計算のプロセッサ数である。この数字と併せてデータを見直すと、並列数が大きいケースほど計算速度が遅くなっていると見ることができるであろう。

わかったこと

全くスピードアップしない。むしろ遅くなるケースもある。

約3倍のスピードアップがあった。

スピードアップはざっくり2倍といったところ。但しバラツキ大で、ある程度モデル規模による要因（要素数が大きいものほどスピードアップが少ない）が認められるものの、確実ではない。

上記結果を定量的に確認すべく、今回、新たにチュートリアルケースの実行時のプロセッサ数をカウントし、データベースに追加し、グラフ化した。

使用したSQL構文

但し、Np=22のケース（incompressible/pimpleFoam/LES/planeChannel）は標準チュートリアルでは、Np=40となっているが、使用計算機の制限（コア数24）上変更した数字となっており、旧計算環境ではNp=30としていた。

結局のところ、新計算サーバー（Core i9-14900K ）においてコア数が24となっていたものの、その実体はPコア8、Eコア16であるので、8コアを超える計算はEコアを使用せざるを得ず、Eコアの演算速度が遅いため、そこで律速されてしまっていたと考えられる。

追加計算その1

念の為、並列数が8を超えるケースにおいて、いくつか並列数を変更して計算をやり直してみた。

incompressible/pimpleFoam/LES/periodicHill

processors 16 8
steady exeTime 3388.27 2926.21
clockTime 3388 2934
transient exeTime 445890.2 402334.88
clockTime 446129 402830

incompressible/pimpleFoam/LES/planeChannel

processors 16 10 8 2
DFM exeTime 1805.94 1862.13 1699.29 2764.67
clockTime 1812 1862 1699 2765
DFSEM exeTime 1923.85 1991.92 1796.36 2780.56
clockTime 1935 1996 1801 2785
FSM exeTime 2462.01 2617.11 2460.68 4483.87
clockTime 2462 2618 2461 4485

incompressible/pimpleFoam/LES/planeChannel(HT/ON)

processors 30 16 12 8 4 2
DFM exeTime 1906.48 1862 1859.49 1791.98 2214.4 2848.91
clockTime 1941 1862 1860 1792 2215 2849
DFSEM exeTime 2207.18 2039 1945.68 1838.96 2226.11 2759.74
clockTime 2380 20455 1949 1843 2231 2764
FSM exeTime 2741.26 2707.07 2715.15 2640.48 3499 4832.86
clockTime 2769 2707 2715 2640 3500 4833

（この計算は、本来 endTime = 180 となっていたものを、endTime = 1 と打ち切って実施している）

lagrangian/MPPICFoam/cyclone

processors 12 8
exeTime 7918.73 6483.66
clockTime 7920 6527

結論と今後

インテルのCore i系CPUは第12世代（2021年）以降、すべからくPコアとEコアが搭載されるようになっているが、新計算サーバー（Core i9-14900K）ではPコアのコア数（8）以上での並列計算はことごとく旧計算サーバー（Dual Xeon Gold 6130）よりも速度が低下しており、8を超えた並列数で計算すると却って速度が低下することもわかった。つまりEコアを併せて並列計算することはまずもって意味がない。

まだ一つのCPUで確かめただけで、この結果がインテルのCore i系の第12世代以降の全てのCPUに当てはまるかどうか定かではないが、CAE計算でよく使う領域分割型の並列計算をする上では、Eコアのコア数は当てにしないほうが良さそうである。

新計算サーバー（Core i9-14900K）を使った今後のAllrunにおける多並列計算のケースでは、最大並列数を8として実施していく予定。参考までに、並列数が8を超えるケースについては、次項にとりまとめておいた。

また、新計算サーバーは、旧計算サーバー（Dual Xeon Gold 6130）の昇天に起因して、デスクトップマシンとして使用予定であったマシンの暫定的な流用であったので、改めて新計算サーバーの選定をやり直したいところもある。その際には現行の実質有効コア数（8）を超えないことには意味がなく、そうなるとインテルであればXeon系、インテル以外のRyzen9以上という選択肢しかなくなってくる。個人事業主の予算面では30万円以下におさめたいところであり、しばらくは無理かな…の感。

並列数が8を超えるケース（OpenFOAM-v2406）

 

追加計算その2

今年になってから購入したノートPCでも一部やってみた。因みにこちらのCPUは　Core i5-1335Uで、Pコア(2)/Eコア(8)の構成である。また、こちらはWindowsマシンであるので、VirtualBoxの仮想マシン（メモリー31GB、プロセッサ数10）上で実行しており、OpenFOAMもv2406（DEXCS2024）である。

incompressible/pimpleFoam/LES/planeChannel(PC-Note / native ubuntu 24.04)

processors 2 4 8 参考1
DFM exeTime 4291.63 4342.2 3994.94 2764.67
clockTime 4292 4344 3999 2765
DFSEM exeTime 4166.01 4309.38 4004.98 2780.56
clockTime 4173 4321 4017 2785
FSM exeTime 7610.19 7406.72 6364.04 4483.87
clockTime 7611 7409 6370 4485

incompressible/pimpleFoam/LES/planeChannel(PC-Note / VirtualBox onWindows11)

processors 2 4 8 参考1
DFM exeTime 6387.4 6387.13 5736.01 2764.67
clockTime 6396 6398 5846 2765
DFSEM exeTime 6577.39 6289.77 6165.19 2780.56
clockTime 6604 6334 6368 2785
FSM exeTime 12007.19 10998.69 9214.22 4483.87
clockTime 12026 11013 9374 4485
  • 参考1：Core i9-14900K Np(processors)=2

（この計算は、本来 endTime = 180 となっていたものを、endTime = 1 と打ち切って実施している）

lagrangian/reactingParcelFoam/cylinder

processors 1 参考2 参考3 参考4
exeTime 4036.78 917.3 2554.13 1878.68
clockTime 4039 918 2555 1883
  • 参考2：Core i9-14900K Np(processors)=1
  • 参考3：Dual Xeon Gold 6130 Np(processors)=1
  • 参考4：Core i5-1335U　Np(processors)=1　on native ubuntu 24.04

CPUベンチマーク

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

Dual Xeon Gold 6130

Core i9-14900K

Core i5-1335U

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 `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
where of_ver.id in (30)
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 from `of_tutorials` where of_ver=30 and exe_system=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 

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=30 and exe_system=5
order by new.category, new.solver, new.model, new.caseName 
;
select category, caseName,  diskUsage/1000, o_diskUsage/1000, exeTime, o_exeTime , clockTime, o_clockTime from of_temp
where exeTime < 1000
;

SQL-3

				
					DROP TABLE IF EXISTS of_temp;
create table of_temp as

with old_data 
as( select of_ver as o_of_ver, category as o_category, solver as o_solver, model as o_model, caseName as o_caseName,Np as o_Np, diskUsage as o_diskUsage ,exeTime as o_exeTime ,clockTime as o_clockTime from `of_tutorials` where of_ver=30 and exe_system=5)

select  of_ver, new.category, new.solver, new.model, new.caseName, new.Np, 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=30 and exe_system=7
order by new.category, new.solver, new.model, new.caseName 
;
select of_ver, Np, count(*) postcount, sum(`diskUsage`)/1000, sum(`o_diskUsage`)/1000, sum(`exeTime`)/3600, sum(`o_exeTime`)/3600 , sum(`clockTime`)/3600, sum(`o_clockTime`)/3600 from of_temp
where exeTime > 0
group by Np
;

コメントする

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