趣味で計算流砂水理

趣味で計算流砂水理 Computational Sediment Hydraulics for Fun Learning

数値計算とか河川工学とかプログラミングのことを書いています

MENU

Linuxとか

書き込み遅くなりました。

Linux

サーバーで動かすという場合であれば、CentOSが多いような気がします。 WebもCentOS(もしくはFree BSD)が多いようです。

チェック用であれば、VMwareでも良いかと思いますが、 実際に稼働するサーバーと同じ環境にしておいたほうが良いかと思います。

また、ライブラリを利用しているようでしたら、そこらへんにも気を使う必要があるかと思います。

個人的にはCentOSをネイティブに用意しておくのも悪くないと思います。

なお、個人PCにCent OS 6は入れてます(Win7とのデュアルブート)が、最近使ってません・・・。

Parabolic bowl

これでチェックできそうですね。 まだ回せていませんが、Python良いです。 リスト内包表記は強烈です(笑)

中身は後ほど確認します。

Pythonでプロトタイプを作って回しますが、 結局中身が肥大化して遅くなるので、結局Fortranに書き換えたくなります。。。 この前教えてもらったFortranでのDLLを試してみたいと思います。

最近

いろいろあって、波動方程式とかシェルスクリプトとかPythonとか仕事で使いそうです。 まあ、WinなのでCygwinですが・・・。

Parabolic Bowl

更新空いてしまいました。

Parabolic Bowl

先週末から平面二次元の計算を始めました。 手始めにparabolic bowlの図化をpythonで書いてみました。 気が向いたら回してみてください。DBに置いておきます。 さすがに遅すぎるので実計算には使えそうにないです。動画っぽくしたいなら、ImageMagickでgifにするほうが良いかもしれないです。

f:id:SedimentHydraulics:20160713185217p:plain

ソースコードはこんな感じです。ほぼグラフのところで、解析解の計算は数行です。やっぱりI/Oは手間ですね。

# -*- coding: UTF-8 -*-
# use python3.4
## @package
#
#
#
###%matplotlib inline
from mpl_toolkits.mplot3d import Axes3D
import matplotlib.pyplot as plt
from matplotlib import cm
import numpy as np

class MyGragh:
    def __init__(self,X,Y,zb,wL,idX,idY):
        self.X,self.Y,self.idX,self.idY = X,Y,idX,idY
    #make gragh
        self.fig = plt.figure(figsize=(12, 10))
    #make 3Dgragh
        self.ax = self.fig.add_subplot(2, 1, 1, projection='3d')
        self.ax.set_zlim3d(0, 14)
        self.ax.view_init(elev=33, azim=38)
        Xm, Ym = np.meshgrid(self.X, self.Y)
        h = list(map(list,zip(*zb)))
        self.ax.plot_surface(Xm, Ym, h, color='k', zorder=1, rstride=1, cstride=1,linewidth=0.1, antialiased=False,alpha=0.3)
        h = list(map(list,zip(*wL)))
        self.surf = self.ax.plot_surface(Xm, Ym, h, cmap=cm.jet, zorder=2, rstride=1, cstride=1,linewidth=0.1, antialiased=False, alpha=1)
    #make 2Dgragh
        self.ax2 = self.fig.add_subplot(2, 2, 3)
        plt.title('X = '+str(self.X[self.idX]))
        h = zb[self.idX,:]
        plt.plot(self.Y,h, color='k')
        h = wL[self.idX,:]
        self.lineX = self.ax2.plot(self.Y,h, color='b')

        self.ax3 = self.fig.add_subplot(2, 2, 4)
        plt.title('Y = '+str(self.Y[self.idY]))
        h = zb[:,self.idY]
        plt.plot(self.X,h, color='k')
        h = wL[:,self.idX]
        self.lineY = self.ax3.plot(self.X,h, color='b')

    def plotWL(self,wL,t,u,v):
    #make 3Dgragh
        self.surf.remove()
        Xm, Ym = np.meshgrid(self.X, self.Y)
        h = list(map(list,zip(*wL)))
        self.surf = self.ax.plot_surface(Xm, Ym, h, cmap=cm.jet, zorder=2, rstride=1, cstride=1,linewidth=0.1, antialiased=False, alpha=1)
    #make 2Dgragh
        for c in self.lineX : c.remove()
        h = wL[self.idX,]
        self.lineX = self.ax2.plot(self.Y,h, color='b')
        for c in self.lineY : c.remove()
        h = wL[:,self.idY]
        self.lineY = self.ax3.plot(self.X,h, color='b')

    #make title
        self.fig.suptitle('t='+str(t)+'[sec]'+' U='+str(round(u,3))+'[m/s]'+' V='+str(round(v,3))+'[m/s]')
        plt.pause(0.001)

    def __enter__(self):
        return self

    def __exit__(self, exc_type, exc_value, traceback):
        plt.savefig('output.png')
        return False

# main
nx, ny = 21, 21
X = np.arange(-10, 11, 1)
Y = np.arange(-10, 11, 1)
a = 7
h0 = 4
zb = np.array([[h0/a**2*(X[i]**2+Y[j]**2) for j in range(ny)] for i in range(nx)])
eta = a/3
tPriod=60
omega = 2*np.pi/tPriod
#wL = lambda t: np.array([[ eta*h0/a**2*(2*X[i]*np.cos(t*omega)+2*Y[j]*np.sin(t*omega)-eta)+h0 for j in range(ny)] for i in range(nx)])
wL = lambda t, x, y: eta*h0/a**2*(2*x*np.cos(t*omega)+2*y*np.sin(t*omega)-eta)+h0
wLr = lambda t: np.array([[ wL(t,X[i],Y[j]) if wL(t,X[i],Y[j]) - zb[i,j] > 0 else zb[i,j] for j in range(ny)] for i in range(nx)])
u = lambda t: -eta*omega*np.sin(t*omega)
v = lambda t: -eta*omega*np.cos(t*omega)

idX=10
idY=10
tmax = 600
with MyGragh(X,Y,zb,wLr(0),idX,idY) as g:
    for t in range(1,tmax):
        if t%10==0 : g.plotWL(wLr(t),t,u(t),v(t))

ジョイント

とりあえず、矩形断面ではできたっぽくて、テンションが上がってます。パッと見せれる絵がないので勉強会のときにでも話します。

linux環境を構築したい

linux環境を構築したいわけ

ずっとlinux環境が良いと考えておりましたが、以下の理由によりそろそろやろうかと

OSに依存しないコードの作成

このブログで書いているコードをある程度できたものはgithubで管理しようかなと思ってます。でも、例えば、先日のpython + fortran DLLのコードとかはwindowsに限定しているような気がします。(configureとかをしっかり書けば良いのですが。。。)そんなこともあり、開発環境としてwindowsはどうかなとようやく思い始めました。

諸事情でCentOSで動くコードを作る必要がある

仕事でちょっとした水理計算をクラウド上のCentOSで動かす必要があり、チェック用にlinux環境が欲しいなと。

質問

VMware or デュアルブート ...etc

  • できればモバイルで作りたいです。そうなるとwindowsベースでVMware or デュアルブートかなと思ってます。
  • それとも新たなモバイルを買って作ったほうが良いでしょうか。

おすすめのlinuxディストリビューション

  • 基本的なところですとCentOSとかUbuntuとかでしょうか。いろいろあって面白そうです。思い切って軽量なelementary OSとかでもいいですが。
  • せっかくなのでいっしょに入れませんか。

その他

  • 2D SWEの話はいろいろ書きたいので後日。
  • 最近EUROの見過ぎでいろんなことが遅れ気味です。

Re:平面二次元モデルについて

名前

平面2次元だと何がよいのでしょうかね。個人的には2DSWEが解りやすい気がします。

Horizontalでもわかりますが、Shallow Water Equationの方が、浅水流近似してる事が明確だから好きなのかもしれません。

1D Upwind Flux Scheme

以前頂いた1次元版のDamBreakを回してみましたが、 下流側の水深0.001mくらいなら計算できそうですね。 ここら辺の勉強はちゃんとやってないので、評価はできないのですが・・・。

2D Upwind Flux Scheme

  • Reference に記述されてた「Two-dimentional numerical simulation of Malpasset dambreak wave propagation」ってご存知ですか?って書こうと思ったら、やっぱりないんですね。 探してみたのですが、マイナーな感じのジャーナルだったので見つかりませんでした。

  • 「Two-dimensional dam break flooding simulation: a GIS-embedded approach」ありがとうございます。ちゃんと離散式が書いてあるので、参考になりそうです。空間(x方向、y方向)でSplittingはしてないんですね。ちょっと追っかけてみます。

  • 個人的にはCSLRが好きなのですが、Wuさんの本や、Yingさんの論文でも書いてあるとおり、 ただ流れを解くなら良いのですが、境界条件が複雑なので、安定性が必要ですし、 何よりシンプルなアルゴリズムの方が、うまく解けない時の原因が特定しやすいと思います。

  • 数値計算のテクニック的なところで悩むのはあまり本質的じゃないです。 (まあ、そういうの好きですが、あくまで現象を見るのが本質ですから)

境界条件

上流端

上流端はハイドロを与えるので、ディリクレ条件ではないのでしょうか?

{ \displaystyle
Q = Q_{up}
}

運動量(?)を考えるやり方があるのであれば教えて下さい。

下流端

下流端は流量の勾配0としてノイマン条件で良いかと思います。

集中格子で考えていますが、あくまでConservative Schemeなので、 コントロールボリュームを考えてあげる必要があるかと。

水際

これが一番処理が面倒くさいように思います。 私がやるなら、長田さんのやり方を踏襲するのが第一歩かな。

スキーム

結局、境界条件の煩雑さがスキームの簡便さと安定性を求める要因です。 煩雑なものを使うとかなり面倒くさい事になりそうです。

ブラックボックス

  • この議論は出て当然ですね。車輪の再発明という言われ方もありますが、ある程度理解してないと車輪は使っちゃいけないんですよね。

  • 数値計算は、物理現象、数学を用いた現象の記述、解くためのアルゴリズムの理解等々、必要な素養はたくさんあるので難しいです。

  • こういったソフトウェアは、プリポスト処理に特化するといい気がしますけどね。GUIはコード量がだいぶ増えますから。

平面二次元モデルについて

平面二次元って正式に略語は何なんでしょうか?よく2DH(多分、2 dimensional horizontal)とか2D-SWE(shallow water eq.)とか見ますが、何が適切なのかよく分かりません。

Upwind flux scheme

  • Upwind flux schemeを推すのは意外でした。もっと凄いのを勧めるのかの思ってました。このスキームでチャレンジしてみます。

  • 関連する論文を列挙しておきます。再記のものも含みます。

Upwind Conservative Scheme for the Saint Venant Equations

元論文です。

http://ascelibrary.org/doi/abs/10.1061/41114(371)141

Yingさんの2Dですが出典がマニアックで手に入りません。

Two-dimensional dam break flooding simulation: a GIS-embedded approach - Springer

2Dだとこれが参考になりそうです。よくまだ理解できていません。

DBに置いておきます。

Boundary Condition

  • 集中格子なのでいつも悩みます。特に上流端のH or Aと下流端のQです。1Dの場合、こんな感じで大丈夫でしょうか。

下流端Q

{ \displaystyle
\frac{ \partial Q }{ \partial x } = 0
}

上流端A

{ \displaystyle
\frac{ \partial }{ \partial x } \left( \frac{ Q ^2 }{ A } \right) = 0
}

とりあえずシンプルな問題だと解けるのであまり気にしてないですが意見を頂けると幸いです。

雑談

Advances in Water ResourcesでNumerical modelling of river morphodynamicsという特集が組まれてました。

巻頭でSivigliaさん(http://www.sciencedirect.com/science/article/pii/S0309170816300057)が、「iRIC Software ( www.i-ric.org ), BASEMENT ( www.basement.ethz.ch ), Delft3D ( http://oss.deltares.nl/web/delft3d ), TELEMAC-MASCARET ( www.opentelemac.org )等のフリーソフトで計算してるけど本当に大丈夫?中身はブラックボックスだよね。」と書いていたのが面白かったので共有しておきます。また、Five common mistakes in fluvial morphodynamic modelingも面白かったので共有しておきます。

その他必要な論文があれば集めますので言って下さい。

網状流路とWebに関する処理

既往研究

山地河川の本にもありますが、高橋先生や里深先生はスタッガードスキーム+1次風上のようですね。

解析精度ももちろん大事ですが、流行りの?ロバストは重要だと感じてます。特にドライベッドが頻発するとおもいますので。

スタッガードスキームであれば、細田先生のスキームがよろしいかと思います。FDS型の粘性(2次元版)を入れるとドライベッドでも飛ばずに計算できると思います。

集中格子が良いという場合、Upwind Flux Schemeがいいかと思いますが、保存性がどうかなと感じています。網状流路での流れに関する変量の保存性がどのくらい重要かを理解していないので、なんとも言えませんが。

HLLCは微妙のような気がします。 1次元版でもドライベッドの処理をちょっと考えないといけない気がしてます。

個人的にはUpwind Flux Scheme押しですかね。シンプルで理解しやすく、コードもシンプルになると思います。

Web

既存のページからデータを拾ってくるという話でしょうか?クローラーとかスクレイピングですね。

やったことが無いのでなんとも言えませんが、書籍としては、下記のものがあるようです。

Rubyによるクローラー開発技法 巡回・解析機能の実装と21の運用例

Rubyによるクローラー開発技法 巡回・解析機能の実装と21の運用例

PythonによるWebスクレイピング

PythonによるWebスクレイピング

JavaScriptが情報が多そうですが、わざわざ覚えるのも・・・。 スクレイピングで調べればそれなりにでてくると思います。Pythonだと学習コストが少なくて済むと思います。

パイプライン?

以下の記事を読んでいて、「5 間違いその4」に記載されている内容が気になりました。

開発者がビッグデータ分析にPythonを使う時によくやる間違い | プログラミング | POSTD

  • 「複雑なデータ分析パイプラインを扱うためのフレームワーク」としてluigiが紹介されてますが、このようなものはご存知でしょうか?私は初めて知りました。

  • luigiをググるといろんな情報がありますが、python同士の処理が多いです。

  • ここではjavapythonを結合しているようですが、科学技計算に使えないかなと考えてます。

  • 情報をお持ちでしたら教えて下さい。