extBlockMeshをOF3.0以降で利用する場合はこちらから。
GitHub - HIKassem/extBlockMesh: extBlockMesh fork for OpenFOAM-dev version
SL6にdevtoolを入れる
SL6やCentOS6系はコンパイラのバージョンが古いため、OF4.xのビルドなどのためには、いろいろ支障が出てきている。そこで、devtoolと呼ばれるコンパイラ関係の更新パッケージをいれてみる（SL6.8）。
devtoolは現在4まであるみたいだが、あまり新しいコンパイラだとハマる可能性もあるため、devtool-2をいれてみた（gcc4.8.2）。
$ su
# cd /etc/yum.repo.d/
# wget http://linuxsoft.cern.ch/cern/devtoolset/slc6-devtoolset.repo
# yum install devtoolset-2
# exit
$ source /opt/rh/devtoolset-2/enable
$ gcc --version
gcc (GCC) 4.8.2 20140120 (Red Hat 4.8.2-15)
Copyright (C) 2013 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
chtMulitRegionFoam + DynamicMesh(fluidRegion) + interFoam + Evapolation/Condensation on OF3.0.x (その１)
というのをやりたいので、以下の順番に進める。
OF4.0が出たばっかりだが、ちょっとヘッダファイルが変わったようなので、とりあえず3.0.xで進める。
①chtMulitRegionFoam + DynamicMesh(fluidRegion) = chtMultiReginDyMFoam
Immersed boundary method on foam-extend 3.2
（注意） foam-extend 3..2はgcc 4.9.2以上が必要なようです。
OpenFOAMのforkしたバージョンであるfoam-extend 3.2が昨年9月にリリースされ、前から気になっていたImmersed boundary methodが正式にリリースされていたので、知らべてみた。現在は、nextReleaseとして4.0の作業を進めているらしいです。
ライブラリ：src/immersedBoundary
ソルバー：applications/solvers/immersedBoundary/ (六つ)
icoIbFoam porousSimpleIbFoam simpleIbFoam
icoDyMIbFoam interIbFoam potentialIbFoam
チュートリアル：tutorials/immersedBoundary/*
テスト1（Tutorial・・・cylinderInChannelIcoIbFoam）
2次元チャネル内に、2次元stlファイルでIB（Immersed boundary）が静止している計算。ここで設定として
- IBはstlないしftrで指定（ベースメッシュで考慮は不要）する。ファイル名がboundary名になる。stlファイルはsurfaceConvertコマンドでftr形式にも変換して、同じフォルダにおいておく。
- IBのconstant/boundaryには、以下のように記述する。nFacesは０で、それ以外のfaceIDに合わせて適宜startFaceを指定する。
ibCylinder
{
type immersedBoundary;
nFaces 0;
startFace 3650;
internalFlow no;
}
- 0/U,pファイルは、以下のように記述する。
0/U
ibCylinder
{
type immersedBoundary;
refValue uniform (0 0 0);
refGradient uniform (0 0 0);
fixesValue yes;
setDeadCellValue yes;
deadCellValue (0 0 0);
}0/ｐ
ibCylinder
{
type immersedBoundary;
refValue uniform 0;
refGradient uniform 0;
fixesValue no;
setDeadCellValue yes;
deadCellValue 0;
value uniform 0;
}
テスト２（Tutorial・・・cylinderInChannelIcoIbFoam）
2次元チャネル内に、2次元stlファイルでIB（Immersed boundary）が変動している計算。ソルバーはicoDyMIbFoamになる。
下記のとおり、dynamicMeshDictの中で、往復するsolidBodyMotionを定義している。
- constant/dynamicMeshDict
dynamicFvMesh immersedBoundarySolidBodyMotionFvMesh;
immersedBoundarySolidBodyMotionFvMeshCoeffs
{
motionFunctions
(
ibCylinder
{
// solidBodyMotionFunction translation;
// translationCoeffs
// {
// velocity (0.1 0 0);
// }
solidBodyMotionFunction linearOscillation;
linearOscillationCoeffs
{
amplitude (0.5 0 0);
period 2.5;
}
}
);
}
Adaptive Mesh Refinement(AMR) on OpenFOAM 3.0.x
AMRはDyMソルバーで利用可能。3Dメッシュのみ＋Parallel計算可能。
interDyMFoamのチュートリアルに含まれているconstant/dynamicMeshDictでは以下の通りに記述されている。
dynamicFvMesh dynamicRefineFvMesh;
dynamicRefineFvMeshCoeffs
{
// How often to refine refineの頻度(time step)
refineInterval 1;
// Field to be refinement on refineの基準変数（volScalarしかできない？）
field alpha.water;
// Refine field inbetween lower..upper 基準変数のrefine下限値/上限値(この範囲がrefineされる)
lowerRefineLevel 0.001;
upperRefineLevel 0.999;
// If value < unrefineLevel unrefine unrefine最大の値（通常は大きな値としておくと、自動的にunrefineも行われることになる)
unrefineLevel 10;
// Have slower than 2:1 refinement refineのバッファー
nBufferLayers 1;
// Refine cells only up to maxRefinement levels refineの最大追加レベル
maxRefinement 2;
// Stop refinement if maxCells reached リファイン停止条件の最大セル
maxCells 200000;
// Flux field and corresponding velocity field. Fluxes on changed
// faces get recalculated by interpolating the velocity. Use 'none'
// on surfaceScalarFields that do not need to be reinterpolated.
correctFluxes
(
(phi none)
(nHatf none)
(rhoPhi none)
(ghf none)
);
// Write the refinement level as a volScalarField
dumpLevel true;
}
Dakotaの並列計算機能について（その５）
Dakotaの並列計算機能について整理してみる。
計算機環境で整理すると、
１）マルチコアワークステーション1ノード向け
- dakotaのinstanceは1つだけ起動（シリアル）
- 例えばasynchrnous evaluation_concurrency 4 （4つ同時にeval.）を指定する。
- 1個1個のevaluation(simulation)は、シリアルorパラレル可能ただし、パラレル計算はノード内のコア間に限定される
- 16coreのノードであれば、asynchrnous evaluation_concurrency 4 で個々のevaluation を4並列とするとcoreをすべて使用して計算することになる。
２）マルチノードクラスタ向け（ただし各ノードは1~4coreと小規模な場合）
- dakotaをmpirun -np 4 -host node0,node1,node2,node3 dakota hoge.inのように並列起動する
- ただし、dakotaはMPI supportでビルドされていることが必要
- evaluationはシリアル計算のみ可能（パラレル計算とするとmpiプロセスのバッティングが起こる）
３）マルチノードクラスタ向け（ただし各ノードは8core~とそれなりにまともなHPCの場合）
３－１）バッチファイルシステムが使用できる場合
- dakotaを起動
- dakotaからバッチファイルシステムにevaluationのキューを順次投入
- 個々のevaluationはシリアルでもパラレルでも可能
- ....ということで、あまり通常のバッチファイルシステムの使い方に変更はない。
３－２）バッチファイルシステムが使用できない（しない）場合
- dakotaを起動
- dakotaからevaluationする場合に、どのノードに投入するか決定する（このNode Placement Methodにはいくつかの方法がある）。
- 個々のevaluationはシリアルでもパラレル(mpirun)でも可能だが、ノード跨ぎのパラレル計算はできない。
- work_directory "runs/run"
directory_tag
directory_save で個々のevaluationフォルダは残す。
Node Placement Methodとしては、
- Compute list of relative nodes based on
- Number of nodes in allocation
- Number of MPI tasks per node
- Number of MPI tasks per simulation run
- evaluation number (obtain from e.g. file_tag)
- Then launch simulation with relative node list option (-host) or machinefile option (-machinefile)
- Use local_evaluation_scheduling static in an input file
とのことで、以前の記事のような感じで計算できる。
ざっくりと再掲しておくと、
[snip]
APPLIC_PROCS=2 # 1 evaluationあたりのCore数
# Current Eval. Number
num=$(pwd | awk -F. '{print $NF}') # workdir名からEval.番号を取得
CONCURRENCY=4 # Dakotaのconcurrency（inputファイル中で指定した値）
PPN=16 # ノード当たりのcore数
# 剰余演算でjob番号と、OFで利用するcore数などからホスト番号を計算
applic_nodes=$( ( (APPLIC_PROCS+PPN-1) / PPN ) )
relative_node=$( ( (num - 1) % CONCURRENCY*APPLIC_PROCS / PPN ) )
### relativeノードが使える場合(MPIのバージョンによる)
node_list="+n${relative_node}"
for node_increment in $(seq 1 $( (applic_nodes - 1) ) ); do
node_list="$node_list,+n$( (relative_node + node_increment) )"
done
### relativeノードが使えない場合は以下のように、relative番号から実際のホストを対応づける
if [ $relative_node -eq 0 ]; then
node_list="ensis10"
elif [ $relative_node -eq 1 ]; then
node_list="ensis12"
elif [ $relative_node -eq 2 ]; then
node_list="ensis13"
else
node_list="ensis14"
fi### evaluationの実行
mpirun -np $APPLIC_PROCS -host $node_list my_simulation
