趣味で計算流砂水理

Computational Sediment Hydraulics for Fun

続:改めて不等間隔格子の河川流一次元計算

冷静に考えたら、座標変換ですね。

基礎式です。


\frac{\partial A}{\partial t} + \frac{\partial \xi}{\partial x}\frac{\partial Q}{\partial \xi} = 0


\frac{\partial Q}{\partial t} + \frac{\partial \xi}{\partial x}\frac{\partial }{\partial \xi} \left( \frac{Q^2}{A} \right) = -gA\frac{\partial \xi}{\partial x}\frac{\partial H}{\partial \xi} -gAI_e


\frac{\partial \xi}{\partial x} = \frac{1}{\Delta x_{i+1} + \Delta x_{i}}\left(\frac{ \Delta x_{i}}{ \Delta x_{i+1} }(\xi_{i+1} - \xi_{i} ) + \frac{ \Delta x_{i+1}}{ \Delta x_{i} }(\xi_{i} - \xi_{i-1} )\right)


\Delta x_{i+1} = x_{i+1} - x_{i}


\Delta x_{i} = x_{i} - x_{i-1}

実河川の問題では必須のような気がします。

今度テスト計算をしてみます。

改めて不等間隔格子の河川流一次元計算

改めて河川流一次元計算を考えていると、計算格子の定義点が測量点で決まるという一般的な流体解析ではあり得ない状況です。

顕著な不等間隔の場合、コロケート、スタッガードに関わらず、コントロールボリュームが以下のようになってしまいます。

f:id:SedimentHydraulics:20170826212244p:plain

なので、観測点が全然セルセンターになりません。あまり気にせず計算していましたが、やっぱりまずい気がします。

いっそのこと、以下のようにしたほうが良い気がします。

f:id:SedimentHydraulics:20170826212236p:plain

良い検証材料があればチャレンジしてみようかと思います。

いろいろ

地理院地図とdeep learnning

http://ccpn.gsi.go.jp/meeting_partners/data/20170608/4.pdf

この前話そうと思っており、忘れてました。 deep learnningの部分を抜きにすると、公開データを一括処理でやっちゃうあたりは、我々がやりたいことと少し近いような気がしてます。 物理モデルと公開データを組み合わせて何かやりたいですね。

環境構築

c++の開発環境で、VC++って話をしていましたが、あえてのBash on windowsはどうでしょうか。もうすぐ、Fedora版がでるので、それで開発するとcentOSとの相性も良いのかなと。gccになるけど科学技術計算+αを書くだけなら十分でしょう。cmakeとか使いたいです。

例のもの

http://www.pref.shizuoka.jp/kensetsu/ke-830/numagawa/gaiyo/

まだ作ってないみたいです。ほんとにこんなにうまく流れるのかな。

twitter連携

始めて見ました。情報は共有してます。基本的には、ブログで書くほどもないことを上げようかなと。

勉強会での話

並列化

大きなプログラムを書きたいため、並列化の勉強をしているですが、気になる内容がありましたので、列挙しておきます。

ハイブリッド並列化

最近の主流っぽいですね。MPI+openmpが基本で。MPIで分割したものに、openmpで並列化をかけるようです。情報はお持ちでしょうか。

ポインタ配列の並列化

ポインタ配列って並列化できないのかなって思ってましたが、openmp3.0からサポートしているようです。

以下のp.36参照。ただし、Cだけっぽいですね。

http://jp.xlsoft.com/documents/intel/seminar/openmp20161202/OpenMP45_2016_Dec_JA_Final.pdf

openmpはMPIと比較して、いろいろと小回りがきくので、ハイブリッド並列化は良いような気がします。

意思決定の自動化

http://jpn.teradata.jp/library/ma/ins_17.html

最近検索に引っ掛かり、気になってます。 いづれは、私のような仕事もこうゆう世界になるのかなと思ってます。 問題解決のために必要な物理モデルの決定から、得られた解より対策を決定する過程が自動化されると仕事がなくなっちゃいますね。 でも、物理モデルを書ければ仕事はあるのかなと。

関係ない話

ちょっとしたことからPCを初期化しました。 インストールに気になったことを忘れないように書いておきます。

Windows 10 Creators Update

結構大幅に変わりましたね。まだ、使いこなせてないです。

vscodeのextensionが入らない

http://qiita.com/KuwabataK/items/f044b037bde50afbbca6#_reference-26d5b85ec3d8b2eafc11

proxy環境下でのバグっぽいです。とりあえずコマンドラインから対応。

visual studio comminityを入れると

勝手にanacondaがインストールされてました。node.jsも入るので、こっちのほうが楽かもしれないですね。ただし、15GBくらいありますが。

GC

メモリリーク

fortranでも起こるんですね。知りませんでした。。。

fortranでは気にしたことないですね。

deallocateはちゃんと書いた方が良さそうです。

ガベージコレクション

C++では必須でしたが、最近はGCを備えているようです(Cは必須)。

メモリの管理はGCを備えてない言語の一番不便な点です。 ただし、コンパイラ言語でGCを備えていても、 書き手は気にした方がいいですね。あとで大変なことになる場合があります。

σ座標系に手を出そうかと

連投になってすいません。

VOFを書いたところで、自由表面流れにおけるデカルト座標系の限界を感じてしまいました。河川流には向いてないような気がします。周期境界条件も作りにくいし。

そこで、今まで敬遠していたσ座標系に手を出そうかと思ってます。

Wuさんの本を読んでいると、水面の更新と座標変換について、Wuさんなり考え方で、ざっくり扱っても問題無いよ的なことが、7.1.3.2 SIMPLE algorithmの後半のWater level calculationとGrid adjustmentに書いてありました。

どうでしょうか。ご意見を頂きたいです。

ポインタとメモリリークについて

先日のアップしたプログラムを書いた際に初めてメモリリークという壁にぶち当たりました。 fortranメモリリークって無いだろと思ってましたが、結構あるみたいです。

例えば、

http://jjoo.sakura.ne.jp/tips/f90/memory_leak.html

ただし、今回陥ったものは、ifortだと問題なかったので、gfortranのバグっぽいですが、メモが代わりにまとめておきます。 下記のようにsubroutine内でポインタの配列を複製を作ると解放出来なくってしまいました。

subroutine test(pA)
    type(c), pointer :: pA(:)  !引数:構造体cの配列
    type(c), pointer :: p(:) => null() !ローカル変数

    allocate(p, source = pA) !pAのコピーをアロケート

!処理を実行

    deallocate(p) !pが開放されない。

end subroutine

全く原因が不明です。

今後c++で書くことを考えると、メモリリークは十分に注意しないといけないと思いました。