いわて駐在研究日誌

OpenCAE、電子工作、R/C等、徒然なるままに

C++のダイナミックライブラリの作成・使用

 

$ more hello.cpp
#include<iostream>
#include<stdio.h>

using namespace std;

int hello(){
   cout<<"Hello,World!"<<endl;

}

linuxC++でのdynamic linkライブラリ(.so)の作り方

g++ -shared -fPIC -o libhello.so hello.cpp

メモ:

  • fPICオプションは速度は遅くなるがつけたほうが良いらしい。
  • nmコマンドでシンボルテーブルを確認できる。
  • $ nm libhello.so

    0000000000200c70 d DW.ref.__gxx_personality_v0
    0000000000200a48 a _DYNAMIC
    0000000000200c30 a _GLOBAL_OFFSET_TABLE_
    00000000000008f2 t _GLOBAL__I_hello.cpp
                     w _Jv_RegisterClasses
    00000000000008aa t _Z41__static_initialization_and_destruction_0ii
    000000000000087c T _Z5hellov
                     U _ZNSolsEPFRSoS_E@@GLIBCXX_3.4
                     U _ZNSt8ios_base4InitC1Ev@@GLIBCXX_3.4
                     U _ZNSt8ios_base4InitD1Ev@@GLIBCXX_3.4
                     U _ZSt4cout@@GLIBCXX_3.4
                     U _ZSt4endlIcSt11char_traitsIcEERSt13basic_ostreamIT_T0_ES6_@@GLIBCXX_3.4
    0000000000200c88 b _ZStL8__ioinit
                     U _ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_PKc@@GLIBCXX_3.4
    0000000000200a20 d __CTOR_END__
    0000000000200a10 d __CTOR_LIST__
    0000000000200a30 d __DTOR_END__
    0000000000200a28 d __DTOR_LIST__
    0000000000000a08 r __FRAME_END__
    0000000000200a38 d __JCR_END__
    0000000000200a38 d __JCR_LIST__
    0000000000200c78 A __bss_start
                     U __cxa_atexit@@GLIBC_2.2.5
                     w __cxa_finalize@@GLIBC_2.2.5
    0000000000000910 t __do_global_ctors_aux
    00000000000007d0 t __do_global_dtors_aux
    0000000000200a40 d __dso_handle
                     w __gmon_start__
                     U __gxx_personality_v0@@CXXABI_1.3
    0000000000200c78 A _edata
    0000000000200c90 A _end
    0000000000000948 T _fini
    0000000000000738 T _init
    00000000000007b0 t call_gmon_start
    0000000000200c78 b completed.6349
    0000000000200c80 b dtor_idx.6351
    0000000000000850 t frame_dummy

 

linuxC++でのdaynamicライブラリ(.so)の利用の仕方

  • 呼び出す関数の頭にextern "C"を記述し、シンボル名をマングル(名前変更)されないようにしておく

extern "C" void func(void)
{
   cout << "This is Function" << endl;
}

  • 実行時にリンクする(-lオプションで頭のlib***と、.so拡張子を除いた部分を指定する。-Lでパスを指定する。-Iはinclude headerのパスを指定する)

g++ -I./ -L./ -o main main.cpp -lhello

  • もしくは、libdl.soを利用してプログラム中で動的にロードする
  • main.cpp中に#include <dlfcn.h>
  • g++ -I./ -L./ -o main main.cpp -ldl

#include <iostream>
#include <dlfcn.h>

using namespace std;
int main()
{
  void *handle = dlopen("./libhello.so", RTLD_LAZY);
  if (handle == 0) {
    cout <<  " dlopen error .... %s", dlerror() << endl;
  }

  void (*func)(void) = dlsym(handle, "func");
  if (func == 0) {
    cout <<  " dlsym error .... %s", dlerror() << endl;
  }

  hoge :: func();

  if (dlclose(handle) != 0) {

    cout <<  " dlclose error .... %s", dlerror() << endl;
  } 

return 0;

}

 

 

 

 

 

 

 

OF+外部ライブラリ(物性値ライブラリ)その2

去年の9月に調べていたOF+熱物性値ライブラリ関連を放置していたけど、μORCシステムを真面目に設計するため、再調査してみる。

 

使えそうなライブラリ

freesteam 2.1: 国際標準IAPWSを利用した水・水蒸気熱物性値ライブラリ(C/C++) http://freesteam.sourceforge.net/

CoolProp 5.1.0: オープンソース熱物性値ライブラリ(C/C++/Fortran/C#ほか多数, prerequisites: cmake/git/python/c++compiler/7zip)

https://github.com/CoolProp/CoolProp

NIST Refprop 9.1:NIST提供(有償)熱物性ライブラリ

http://www.nist.gov/srd/nist23.cfm

 

NIST Refpropのダイナミックライブラリ化

Refpropのダイナミックライブラリ化を行っているプロジェクト

https://github.com/jowr/librefprop.so

 

 CoolPropのダイナミックライブラリ化

バイナリファイルはこちらにあるようだ。

http://sourceforge.net/projects/coolprop/files/CoolProp/5.1.0/shared_library/Linux/64bit/

自前でビルドするなら、

OF23の環境になってから

# Check out the sources for CoolProp
git clone https://github.com/CoolProp/CoolProp --recursive

(-recursiveをつけないとexternals以下が不完全です。)
# Move into the folder you just created
cd CoolProp
# Make a build folder
mkdir build && cd build
# Generate builder
cmake .. -DCOOLPROP_SHARED_LIBRARY=ON
# Build
cmake --build .

→ libCoolProp.soができる。bitは指定しなければ、OSと同じ。

# Installation

OFとの連携を考えるのであれば、上記の.soファイルをケースフォルダなどに入れておけば良い。

 

 FreeSteamライブラリとOF(>2.2)との連携

https://github.com/romansCode/IAPWS-IF97-OF

git clone https://github.com/romansCode/IAPWS-IF97-OF.git

cd IAPWS-IF97-OF
wclean && wmake libso

※ OF-2.3.xでもビルドOKでした。

Usage:

- add libIAPWSRangeThermo.so and libfreesteam.so to the libraries in controlDict libs {"libIAPWSRangeThermo.so" "libfreesteam.so" }

- use the thermophysicalProperties file provided in example folder

 

 

 

 

refineWalllayerコマンド

OFのツールに標記のコマンドがあって、メッシュを再分割(とくに物体のパッチ近傍など)ができるんだが、文法が変わったのかな。'()'で括るようになってた。

 

refineWallLayer '(blade1)' 0.47 -overwrite -noFunctionObjects

 

 

あと、派生バージョンで

http://www.cfd-online.com/Forums/openfoam-meshing-utilities/109885-contribution-new-utility-refine-wall-layer-mesh-based-yplus-field.html

というのもある。こちらはyPlusベースで指定できるようだ。

 

 

 

Blanin問題(単一目的関数、多峰性、制約条件なし)

Blanin問題

http://www-optima.amp.i.kyoto-u.ac.jp/member/student/hedar/Hedar_files/TestGO_files/Page913.htm

をDakotaのSOGAとSBO(Surrogate Based Optimaization (Kriging))でやってみた。poulation とかgeneration とかはそろえてある。

計算結果は下記のとおりで、SBOのほうが圧倒的に速い。ただし、流体解析を組合せた場合はどうなるのかこれから検証しないといけない。

 

SOGA

>>>>> soga: post-run phase.
<<<<< Function evaluation summary: 835 total (835 new, 0 duplicate)
         obj_fn: 835 val (835 n, 0 d), 0 grad (0 n, 0 d), 0 Hess (0 n, 0 d)
<<<<< Best parameters          =
                     -3.2251838447e+00 x1
                      1.2234689303e+01 x2
<<<<< Best objective function  =
                      4.9002902766e-01
<<<<< Best data captured at function evaluation 26


<<<<< Iterator soga completed.
<<<<< Environment execution completed.
DAKOTA execution time in seconds:
  Total CPU        =       0.61 [parent =   0.611907, child =  -0.001907]
  Total wall clock =    103.548

SBO

>>>>> surrogate_based_global: post-run phase.
<<<<< Function evaluation summary (APPROX_INTERFACE): 6328 total (6328 new, 0 duplicate)
         obj_fn: 6328 val (6328 n, 0 d), 0 grad (0 n, 0 d), 0 Hess (0 n, 0 d)
<<<<< Function evaluation summary: 105 total (105 new, 0 duplicate)
         obj_fn: 105 val (105 n, 0 d), 0 grad (0 n, 0 d), 0 Hess (0 n, 0 d)
<<<<< Best parameters          =
                      9.3747568430e+00 x1
                      2.4445742729e+00 x2
<<<<< Best objective function  =
                      4.1002862086e-01
<<<<< Best data captured at function evaluation 105


<<<<< Iterator surrogate_based_global completed.
<<<<< Environment execution completed.
DAKOTA execution time in seconds:
  Total CPU        =       0.87 [parent =   0.867868, child =   0.002132]
  Total wall clock =    14.2522

 

最適化手法の勉強

DAKOTAを使えるだけではなくて、ちゃんと最適化手法を勉強せんとあかんなということで、まとめてみる。言葉だけだと、なんか分かりにくいかもしれないが...。

 

  1. 勾配法のほうが最適解を求めるのは早いが、複数の最適解が存在する場合や、応答曲面にノイズが乗っかっているような場合は、過剰な勾配評価により必ずしも大域的最適解には到達できない。
  2. 問題にもよるが、GAやPSOのような大域的最適化手法のほうが大域的最適解を見出す可能性が大きく、かつロバストである。ただし、試行・評価回数は増えてしまい、計算時間は増大する。
  3. 形状最適化によく用いられるのはSurrogate Based MOGAというもので、多目的関数のパレート解を得るMOGAに、近似応答曲面(Surrogate response surface)を併用するものである。
  4. もともとMOGA自体は、多目的関数のグローバル最適化に向いた手法であるが、大域的最適解を見つけるには上述のように多数回の評価が必要であることから、厳密な応答曲面での評価ではなく、近似応答曲面をまず見つけ、そこでの最適化を評価し(少ない試行回数・サンプル数で)、その結果からさらに応答曲面の近似精度を上げていく。これを繰り返す。
  5. 結果的に、トータルの評価回数を大きく減らすことが可能

※ GAとかのアルゴリズムはまた別に勉強せんとな。

もう少しで3ヶ月

息子の話。22日で3ヶ月になる。大分、腹とか太ももとかムチムチしてきた。

気がついた点は、

  • 先日計ったら体重6.2kgで倍以上になってた。
  • 目つきや顔つきがしっかりしてきたような気が...。
  • 前に比べて、アー・ウーとかいって会話?が成立するようになってきたかもしれない(ただし機嫌の良いときに限る)。
  • 両手で握ったり、服とかタオルをよく握りしめるようになった。
  • 夜もしっかり寝ることが多くなり、昼夜の区別がはっきりしてきたような(もう少し、昼寝してくれるとよいけど)。
  • うんちは1日朝1回大量にする(母乳なのでやや緩い。オムツの仕方が悪いと大変なことが....。)

といったところか。

コラージュフルフルというボディソープを使うようになって、へんなオムツかぶれもしなくなったので、あとは、風邪を引かせないように大人が手洗い・うがいを気をつけねば...。

LHS

LHSとかRHSとか、流体とか数学やってる人は、数式の左辺(left hand side)の意味というのは分かってるが、最適化の勉強を始めるとLHSが結構出てくるので何ぞや?ってなことになったので調べてみた。

 

LHS: Latin HyperCube Sampring=ラテン超方格の訳だそうで、多次元設計データの中からのデータサンプリングの手法の一つらしい。

例えば設計変数が2つあるいは3つあるとすると、設計空間は2次元あるいは3次元ということになる。この中で個々の設計変数の範囲から、データサンプリングして目的関数を評価してみるとする。(設計変数というよりも実験変数としたほうがわかりやすいか。実験計画=”Design of Expreriments”)

 

データサンプリングの方法として、直感的に分かりやすいのは、

・規則的に設計変数範囲を分割してサンプル点を設定(直交化法:orthogonal method)

・不規則に設計変数範囲からサンプル点を設定(ランダム法=モンテカルロ法

だろう。

このサンプル点の設計変数を用いて、形状やコストなどの目的関数(複数あり)を制約条件のもとで評価し、是非を判断する。

問題は、設計変数の数が増えると急激にサンプルの数も増えること。また、局所最適解ではなく、グローバル(設計空間全体という意味で)最適解を見つけるのが望ましいが、それだときわめて多数回のサンプリング→評価を実施しなければならないということがある。

 

以上のことから、実験計画のサンプリングの実用性を考え、

・実験回数を指定できる

・個々の設計変数で、必ず1回は実験(評価)が実施されるような変数の組を生成させる

ということで、これに対応できるように2次元のラテン方格をn次元に拡張した物=ラテン超方格が実験計画に用いられるようになったらしい。ラテン超方格の選択可能な最大の設計変数組み合わせ数は、線形変数の種類をN,個々の設計変数の分割数をMとすると、(M!)^(N-1)個になる。

 

参考:

Latin hypercube sampling - Wikipedia, the free encyclopedia