いわて駐在研究日誌2。

NEVER STAND BEHIND ME

extBlockMesh for OF3.0 and higher

extBlockMeshをOF3.0以降で利用する場合はこちらから。

GitHub - HIKassem/extBlockMesh: extBlockMesh fork for OpenFOAM-dev version

 

SL6にdevtoolを入れる

SL6やCentOS6系はコンパイラのバージョンが古いため、OF4.xのビルドなどのためには、いろいろ支障が出てきている。そこで、devtoolと呼ばれるコンパイラ関係の更新パッケージをいれてみる(SL6.8)。

 

linux.web.cern.ch

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.

 

SLは、次のバージョンからCentOSベースになるらしいけど、それならCentOSでいいのかな。

chtMulitRegionFoam + DynamicMesh(fluidRegion) + interFoam + Evapolation/Condensation on OF3.0.x (その1)

というのをやりたいので、以下の順番に進める。

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は0で、それ以外の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/p

    ibCylinder
    {
        type immersedBoundary;
        refValue uniform 0;
        refGradient  uniform 0;
        fixesValue no;

        setDeadCellValue   yes;
        deadCellValue      0;

        value uniform 0;
    }

 

f:id:waku2005:20160627133934p:plain

f:id:waku2005:20160627133939p:plain

f:id:waku2005:20160627133943p:plain

スト2(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;
            }
        }
    );
}

 

f:id:waku2005:20160627140854p:plain

f:id:waku2005:20160627140901p:plain

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;
}

 

助成金申請

なかなか科研費があたらないので、助成金のほうで頑張って稼ごうと足掻いています。

本日2件提出しました。来月も2件提出予定です。

現状、

・企業さんの申請に協力する形で2件(@30弱)

・某M社、E社の助成金(@100, @65)

を提出して結果待ちで、来月〆切のものは、

・某S社、I社の助成金(@100、@200)

とちょっと額が大きいので頑張って書くべし。

Dakotaの並列計算機能について(その5)

Dakotaの並列計算機能について整理してみる。

計算機環境で整理すると、

1)マルチコアワークステーション1ノード向け

  • dakotaのinstanceは1つだけ起動(シリアル)
  • 例えばasynchrnous evaluation_concurrency 4 (4つ同時にeval.)を指定する。
  • 1個1個のevaluation(simulation)は、シリアルorパラレル可能ただし、パラレル計算はノード内のコア間に限定される
  • 16coreのノードであれば、asynchrnous evaluation_concurrency 4 で個々のevaluation を4並列とするとcoreをすべて使用して計算することになる。

2)マルチノードクラスタ向け(ただし各ノードは1~4coreと小規模な場合)

  • dakotaをmpirun -np 4 -host node0,node1,node2,node3 dakota hoge.inのように並列起動する
  • ただし、dakotaはMPI supportでビルドされていることが必要
  • evaluationはシリアル計算のみ可能(パラレル計算とするとmpiプロセスのバッティングが起こる)

3)マルチノードクラスタ向け(ただし各ノードは8core~とそれなりにまともなHPCの場合)

3-1)バッチファイルシステムが使用できる場合

  • dakotaを起動
  • dakotaからバッチファイルシステムにevaluationのキューを順次投入
  • 個々のevaluationはシリアルでもパラレルでも可能
  • ....ということで、あまり通常のバッチファイルシステムの使い方に変更はない。

3-2)バッチファイルシステムが使用できない(しない)場合

 

  • dakotaを起動
  • dakotaからevaluationする場合に、どのノードに投入するか決定する(このNode Placement Methodにはいくつかの方法がある)。
  • 個々のevaluationはシリアルでもパラレル(mpirun)でも可能だが、ノード跨ぎのパラレル計算はできない。
  • work_directory "runs/run"
    directory_tag
    directory_save で個々のevaluationフォルダは残す。

Node Placement Methodとしては、

  1. 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)
  2. Then launch simulation with relative node list option (-host) or machinefile option (-machinefile)
  3. 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