OpenFOAM-v2312のAllrunの結果を公開した。総ケース数478（476）、使用ディスク容量：1016GB（約1TB）、総計算時間：約27日（35日）であった。かっこ（）内数字はv2312のもの。
今回は計算環境が更新されているので、特に計算速度の面で、v2312との直接比較はあまり意味が無い。後述する「新計算環境について」の項で、多分、こういうことだろうという知見は得られたが、これらの点については、別途v2306 につて、新しい計算環境にて、計算をやり直しているので、まとまり次第、別途報告予定である。
また、データベースの仕組みであるPodsプラグインが更新され、動的ページ（phpタグを使用するページ）が使えなくなってしまっていた。具体的には、キーワードなど指定して検索するページが使えなくなっていた。この対策に手こずったこともあり、公開が遅れた。
基本的に、先の記事に記した方法で、ほぼログ解析まで問題なく実行できた。残された手作業項目もOpenFOAM-ｖ2206（Linuxの場合）と同じであった。その他、実行エラーしたケース等についても、簡単に取り纏めておく。
v2312から変化無しで。
ログファイル中に”FATAL ERROR”の出力があったもの
- mesh/foamyHexMesh/flange
- mesh/foamyHexMesh/mixerVessel
- mesh/foamyHexMesh/simpleShapes
- mesh/snappyHexMesh/motorBike_leakDetection
- multiphase/reactingMultiphaseEulerFoam/laminar/mixerVessel2D
“ERROR”出力は無かったが、計算が発散終了していたもの
- 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
- ケース名変更
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
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 (31, 32)
group by `exe_system`, `of_ver` ,`category`
order by `release_date`
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 (31) )
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 (32)
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 < 10000000
;
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 (32)
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/1000 < 1000000
;
SQL-7
select `ver_name` version,
`clockTime`,
`exeTime`,
case when exe_system = 4 then 0.5* (`diskUsage`)/1000000
else (`diskUsage`)/1000000
end as du,
`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
where category = "multiphase" and solver = "cavitatingFoam" and model = "LES" and caseName = "throttle3D"
order by `release_date`
新計算環境について
これまでの計算環境がついに昇天した。これはMAXSYSという通販サイトで購入したワークステーションで、CPUとしてリテールパッケージ版と同じ性能でありながら安価な製造者向けOEM版XEONや、圧倒的に低価格なESモデルXEONを搭載することで、ワークステーションのシステム価格としても格安となって、個人事業主が固定資産税のかからない費用で購入できたものを使っていた。
約5年前に購入したものであったが、多分エアコンも無い部屋での長時間酷使が原因で昇天した。5年前のものであるのでスペック的には、3年前に購入したデスクトップマシンと性能は大差なく、これが復活できたからといって嬉しさは少い。5年という期間使えたので、まぁ元は取れたと思っている。後継機の候補として類似の最新スペック品（たとえばこちら）もあったが、ESモデルなのでBIOSを更新できないだとか、総重量20Kg程あって、高齢者が取り扱うレベルでは無いなどあって、後継としては断念した。
今回（というか最近）新たに購入したのは、いわゆるBTOパソコンというジャンルで、やはり個人事業主の固定資産税のかからない範囲のスペック品を選択した。購入したのは、約半年前だが、Core i9-14900K搭載品。元々デスクトップの更新用にと購入したマシンだが、計算サーバーが昇天してしまったので、急遽こちらをAllrun実行用のサーバーに変更して使っている。
本記事を書くにあたり、改めて現時点での商品ラインアップを見直したところ、ワンランク下といって良さそうな、Core i7-14700Fを搭載したマシンが購入当時とほぼ同じ価格帯で販売されており、Core i9-14900K搭載品は対象商品が無い。したがって、購入当時は随分お得感があって購入できた事になるが、実は、Core i9-14900Kには、不具合による返品が多発して品不足状態になっているという記事（たとえばこちら）もあり、安かったのはこのせいか…と、なんとも不都合な納得感。
何はともあれ、今の所、そういう不具合（クラッシュ）は無しで稼働している（Allrunは正常に動いている）ので、まぁ良しとしておく。
ただ、このCore i9-14900Kにせよ、Core i7-14700Fなりの14世代（12世代以降）のCPUでは、コア数の表記が
Total Cores: 24 Cores, 32 Threads
Performance Cores: 8 Cores, 16 Threads, 3.2 GHz Base, 6.0 GHz Turbo
Efficient Cores: 16 Cores, 16 Threads, 2.4 GHz Base, 4.4 GHz Turbo
となっており、Performance Cores（Pコア）とEfficient Cores（Eコア）という2種類の組み合わせになっている、購入時にはこの点をほとんど気にしていなかったのであるが、今回のAllrunの結果を見て、ようやく得心した。
すなわち、v2406（新マシン）とv2312（旧マシン）との間の計算速度の比較において、ケースによって大きなバラツキがある事がわかった。詳しく調べると、単体計算では3倍程度高速化していたものがあったのに対して、特に多並列の計算において、ほとんど速度向上が無く、むしろ低下しているものもあったくらいであった。これらから察するに単体計算や小並列計算はPコアが使われ、大並列計算では、併せて使わざるを得ず、性能の低いEコアで律速されていたんではないか、ということである（これらの推測は、改めて検証する予定である）。
なお、PコアとEコアという構成になっているのは、ゲーミングプロセッサをターゲットとしているという記事（たとえばこちら）もあったので、CAEというか、多並列の計算をしたいというニーズに対しては、PコアとEコアが混在するマシン構成はあまり意味の無いものであるという事にもなりそうなので、このマシンは本来の用途であったデスクトップマシンで使うこととし、計算サーバー用途には別途購入した方が良いかもしれない。Xeonとか、Ryzenが良いのかなぁ…
Podsプラグインの更新対策について
今回のデータベース更新で、当初ヴァージョン指定して検索するListページなど、全く表示されなくなってしまった。
てっきりデータベースの更新作業で、何かやらかしてしまった？！と焦りまくったが、データベースそのものを直接参照するTutorialsページには、追加したデータを含めてちゃんと表示されていた。
となると、次はPodsのTemplateコードの問題か…となって見直すこととなった。これが凡そ100行くらいのhtmlファイルなんだが、コード仕組みや使われ方など完全に忘却しており、リハビリに大変な苦労であった。ようやく何とか思い起こすことができて、Templateを使った中で唯一使えていたList0のページから始めて、検索機能を追加しよう…となって、ここでようやくphpタグが使えないんだ！という問題の本質にたどりついた。
こうなれば、あとはGoogle様頼りで、”Pods”とか”phpタグ使えない”のキーワードで、ようやくPHP support for Pod Templates and Pod Pagesというページにたどり着いた。とはいえこのページに書いてあることも難解で、当面は
manually enable PODS_DISABLE_EVAL in wp-config.
として凌げるようになったものの、3.3になるとこれも使えなくなるかもしれない。こちらと同じように困っている人のコメントもあるので、何とかなることを期待しているのだが…