データベースの一括追加

全チュートリアルの実行結果情報（計算時間やディスク使用量）をデータベース化するに際しては、いずれ完全自動化を目指してはいるもの、まだまだ道半ば。これまでの経験をベースにある程度の自動化は出来るようになってきているが、手作業が必要な箇所がいくつかあり、半年（マイナスアルファ）に一度の作業では忘れてしまいかねない。そこで備忘録として取り纏めておくこととした。

作業全体のフローイメージは、以下の通り。

図中の各ステップにおける留意点を番号順に記しておく。

Allrun の実行

使用する研鑽環境に依存してAllrunが失敗するケースが存在する。これまでは全実行後に失敗したケースのAllrunを手修正して再実行してきたが、事前に判っておれば事前に手修正しておいた方が、トータルの手間は少ない。今の所、事前に失敗が予測されるケースは以下の通り。

シェルの問題

ubuntu の標準シェルはdashなので、これをOpenFOAMの推奨シェルbashに変更していないと、実行できないケースがある。

スロット数不足

高並列のチュートリアルケースも増えてきた。具体的に、openFoam-v2112を対象に8スロットを越えて必要なケース名とスロット数（分割方法）を以下に挙げておく。基本的にはdecomposeParDictを修正すれば動くはずである。

incompressible/pimpleFoam/laminar/cylinder2D 12(hierarchical)
incompressible/pimpleFoam/LES/planeChannel 36(scotch)
incompressible/pimpleFoam/LES/periodicHill 16(scotch)
incompressible/adjointOptimisationFoam/shapeOptimisation/motorBike 20(hierarchical)
incompressible/adjointOptimisationFoam/sensitivityMaps/motorBike 20(hierarchical)
incompressible/lumpedPointMotion/bridge 12(scotch)
incompressible/lumpedPointMotion/building 12(scotch)
lagrangian/reactingParcelFoam/airRecirculationRoom 10(scotch)
lagrangian/MPPICFoam/cyclone 12(simple)

Mac の場合

Allrun以前の問題として、foamyHexMesh系のメッシャーを使うケースは要注意であるが、それ以外にcp -r コマンドの挙動がLinuxの場合と異なるので変更する必要がある。これもopenFoam-v2112を対象に具体的なケース名を記しておく。

incompressible/adjointOptimisationFoam/shapeOptimisation/naca0012 　以下の全3ケース
incompressible/adjointOptimisationFoa/shapeOptimisation/sbend 　以下の全11ケース
incompressible/adjointOptimisationFoam/sensitivityMaps/naca0012 　以下の全5ケース
incompressible/adjointOptimisationFoam/sensitivityMaps/sbend 　以下の全4ケース
lagrangian/reactingParcelFoam/airRecirculationRoom/transient

ログ解析スクリプトの実行

ログ解析は、countAll.sh でチュートリアルケースのカテゴリー毎のフォルダ名を指定して、allFile.py がログファイルの解析（計算時間など取得）し、結果をtutorials.csv に出力する。

coutAll.sh の4行目が、

				
					tutorialCases="DNS IO basic combustion compressible discreteMethods electromagnetics financial finiteArea heatTransfer incompressible lagrangian mesh multiphase preProcessing stressAnalysis verificationAndValidation modules"

となっているので、解析したいケースに応じて変更する。

また、allFile.pyでは、メッシュ情報を取得するのにcheckMesh コマンドを使用するので、172行目でOpenFOAMのインストール場所を指定するようになっている。必ずしもチュートリアルのOpenFOAMバージョンと合わせる必要はないが、このallFiles.pyをコピーして異なる環境で使う場合には注意を要する。

				
					cmd1 = " . /Volumes/OpenFOAM/OpenFOAM/openfoam-OpenFOAM-v2112/etc/bashrc; "

なお、このallFiles.pyのおおまかなログ解析手順は以下の通りであるが、これも開発途上で、ログ情報を正しく取得出来ていないケースもいくつか存在する。

全ディレクトリーをサーチし、指定したカテゴリー毎に、<カテゴリー名>.csvを作成

systemフォルダが存在すれば解析対象とする。

- ソルバー名、ケース名は、ディレクトリパスから取得
- du -s * コマンドを実行し、その出力和をディスク使用量
- checkMeshコマンドを実行し、メッシュ情報（節点数、要素数）を取得
- ソルバーログファイル（log.<ソルバー名>）から計算時間情報を取得
- clockTimeを取得できなかった場合には、ソルバーログファイルのタイムスタンプを調べて代用
- log.* ファイルを実行順に並び替えて出力
- log.snappyHexMeshが存在する場合には、その計算時間情報も出力（行を追加）
- log.FoamyHexMeshが存在する場合には、その計算時間情報も出力（行を追加）

ログ情報を正しく取得出来ていないケース

ログ情報を正しく取得出来ていないケースもいくつか存在するが、OpenFOAMのケースフォルダの体をなしていななど、原因は判っている。基本的にはログ解析スクリプト（allFiles.py）の改変で対処できるはずであるが、まだそこまで手が回っていない。

IO/dictionary
incompressible/simpleFoam/turbulentFlatPlate
incompressible/pimpleFoam/laminar/cylinder2D
verificationAndValidation/atmosphericModels/atmDownstreamDevelopment
verificationAndValidation/atmosphericModels/atmForestStability
verificationAndValidation/multiphase/StefanProblem
verificationAndValidation/turbulentInflow/oneCellThickPlaneChannel

ログ情報の整理

前節で取得したログ解析情報の生データ（tutorials.csv）をgoogleドキュメントの tutorialsシート

https://docs.google.com/spreadsheets/d/18orlHve-aZ_n4YEJjrToMbVfrWbkdvR_JEl3XAwN9TQ/edit#gid=59634542

ににインポートしているが、そのままでは整合しない箇所がいくつかあるのでそれらを手修正している。作業イメージの要点説明図を図2.に示しておく。

インポートした後で、データベース用のID番号を指定するカラムと、モデル情報を追記するためのカラムを追加している。

カラムの並びは、チュートリアルのフォルダー構成そのままに、カテゴリー名、ソルバー名、ケース名に引き続き、メッシュ節点数、要素数、使用ディスクスペース、計算時間（exe）、計算時間（calk）、使用ユーティリティ、となっているが、必ずしも列が揃っているわけではない。

列が揃わない原因は、clockTimeを取得できなかった場合で、かつログファイル情報も取得できていないケースが該当し、まだ十分に検証できていないが、プログラム改良は予定している。

列が揃わない事以外にも大きな問題が3つあって、これらも今の所、手作業でデータを修正している。

snappyHexMeshなどメッシュ作成情報を追記した行
モデル情報が未取得
チュートリアルケース名と解析フォルダが一致しないケース

このうち下から2つの項目について、以下もう少し詳しく説明しておく。

モデル情報について

チュートリアルケースのディレクトリー情報から、カテゴリ名、ソルバー名、ケース名を取得しているが、これはtutorialsフォルダ以下をパス表記して、

としたものである。大半のケースはこれでチュートリアルケースとして特定できるので、これだけで済ませたかったのだが、たとえば以下の２つのケースは識別できない。

ここは素直に、モデル情報として、乱流モデル（RAS or laminar）を使えば良いので、モデル名としてはパス名の中間部分を自動抽出しても良さそうではあるが、以下の2つのケースは

モデル情報が無くとも最後のフォルダ名だけで区別できないこともない。ただこの例は、本来のチュートリアルケース名としては解析対象の形状をイメージ出来る命名が一般的なので、ケース名をangledDuct として、モデル区分を explicit/implicit とするのがイメージしやすいと思うのだが、上に記した命名ルールでは、angledDuct モデルの、explicit/implicit ケース名ということになってしまう。これも良しと考えれば、ケース名が4番目にある場合には、パス名表記中3番目をモデル名とする単純ルールが使える。

また、ソルバー名を「system/controlDict から読み取る」としたことによって、わかりにくくなってしまうケースがある。たとえばincompressible/lumpedPointMotion 系のチュートリアルである。本来、lumpedPointMotion というソルバーは存在せず、system/controdDictの表記に従えばpimpleFoamがソルバー名であり、この名前が出力される。計算時間情報もlog.pimpleFoamから取得できている。ただ本ケースの表記としては、lumpedPointMotion ソルバーとした方がわかりやすいので、ソルバー名は手修正にて変更している。

これも、表記用のソルバー名を、パス表記の2番目のディレクトリ名とし、ログ解析（計算時間情報取得）用のソルバー名とは別物にした方が良かったかもしれない。

しかし問題は、パス名のディレクトリ階層が5つ以上あるケースをどうするかであった。いくつか例をあげておく。

チュートリアルケースと解析フォルダ

さらに問題を厄介にしているのは、チュートリアルケースの実行前後で、フォルダー構成が大きく変化してしまうケースがあることである。古くから存在する incompressible/icoFoam/cavity のケースを例に説明する。

ログ解析ツール（allFiles.py）では、単純に全ディレクトリへ移動してOpenFOAMのケースファイルであるかどうかを調べているだけなので、上記例の場合、cavityフォルダ下に5つのケースファイルが存在する事となり、それぞれ個別ケースとしてカウントされてしまう。

incompressible, icoFoam, cavityClipped, 754, 336, 220, 0.02, 0, blockMesh, mapFields, icoFoam
incompressible, icoFoam, cavityHighRe, 882, 400, 1464, 0.23, 0, blockMesh, icoFoam
incompressible, icoFoam, cavityFine, 3528, 1681, 776, 0.24, 0, blockMesh, mapFields, icoFoam
incompressible, icoFoam, cavity, 882, 400, 484, 0.07, 0, blockMesh, icoFoam
incompressible, icoFoam, cavityGrade, 882, 400, 336, 0.06, 0, blockMesh, mapFields, icoFoam

古く（5年以上前）はこれらをそのままチュートリアルケースとしてカウントしていたが、現在ではAllrun実行前にチュートリアルとして認識されるケース（icoFoam/cavity）をケース名として、それ以外のケース情報は付加的なものとして取り扱うこととして、tutorialsでは、以下のように同一データ箇所を空白にするのと、caseNameをチュートリアル本来の名前になるよう手修正している。

現在のところ最終的にデータベースへエクスポートする際、ディスク使用量、計算時間（Exe,Clock）は、5つのケースの総和を表示するようにし、灰色で表記した情報は使用していないが、将来使用する余地は残してある。

また、かようなケースが近年増えてきている（たとえば、verificationAndValidation ）ので、このあたりは何とか自動化したいところである。

データベース用ログ情報の抽出

googleドキュメントの tutorialsシートでの作業が終了したら、図2.の紫色の枠で囲った部分をコピーして、データベース用のsplファイルへの変換元データとしてcsvファイルにエクスポートしている（図1.）。

また、併せて、当該データセットの付帯情報（OpenFOAMのヴァージョン、計算環境）を記したファイルも作成しておく。

				
					of_tut_dir	/media/et/OpenFOAM/OpenFOAM/openfoam2112/tutorials/
of_ver	25
exe_sys	44
execution_date	2022-02-01 00:00:00

2,3 行目はデータベースのID番号であり、新たにデータベースを追加した場合などは、phpMyAdminを使って、wp_postデータを直接参照して確認することになる。

データベースのエクスポート

データベースを追加するには、最新のWordPressのデータベースをエクスポート（図1.）して、これに追加分を加えたデータベースファイルをインポートする。WordPressのデータベースをエクスポートするには、phpMyAdminを使っており、対象データベースは以下の3つ,

wp_posts
wp_postmeta
wp_podsrel

であるが、エクスポートオプションとして、1点デフォルト変更する箇所がある。

データベースの追加

sql文追加用にエクスポートしたcsvファイルと、データセットの付帯情報（.info）ファイルを用意して、sv2PostSql1.py

				
					# coding: utf-8
import datetime
import os
from urllib import parse

#追加csvデータファイル
csvFileName = "./csv/v2112.csv"
infoFileName = "./csv/v2112.info"
#更新前のSQLファイル
fileName = {"key1":"./wp_posts.sql", "key2":"./wp_postmeta.sql", "key3":"./wp_podsrel.sql"}
#更新用のSQLファイル
outputAddSql = {"key1":"./wp_posts_Add.sql", "key2":"./wp_postmeta_Add.sql", "key3":"./wp_podsrel_Add.sql"}

の、7、8行目にその在所を記述する。しかる後に、このスクリプトを実行（putyon3 conv2PostSql1.py）すれば、ダウンロードしたSQLファイル（10行目で定義してある）に対して、WordPress用のSQL文に加工したデータを追加するようになっている。追加後のSQLファイル名は、12行目に定義してある。

今の所、csvデータを正しく記述できておれば、間違いなく変換できるはずであるが、csvデータの作成には手作業に依存する部分が多くあるので、どうしても間違いが避けられない。次節のインポートでエラーになる場合には、エラーの原因（ID番号の整合性不具合がほとんど）を調べて、csvファイルの修正が必要になる場合も多い。

データベースのインポート

前節のスクリプトを実行すると、

wp_post_Add.sql
wp_postMeta_Add.sql
wp_podsrel_add.sql

という３つのSQLファイルが作成されるので、これらをphpMyAdminを使ってインポートして、エラーが生じなければ作業が完了となる。

３つのファイルのインポートの順番は問わないが、前節で述べたインポートエラーの大半は、wp_post_Add.sql をインポートする際に生じるので、これを最初にインポートしてエラーの無いことを確かめてから、残りの2つをインポートするのが良い。

目次