例のSection Quasi 2Dモデルについて、Githubで公開しようかなと考えているのですが、そろそろライセンスのことも気にしたほうが良いかもしれないと思ってます。
どうしましょうか。MITかGPLかと思いますが、GPLにするほど大したものじゃないですが悩ましいです。
作者はこのHPにします。ミスがあればその都度gitで直していこうかと思います。
fortranとpythonですが、calSectionProfileとinitializeを呼んでます。いろいろ試していると、fortranの共有部分でallocateしたものが、ずっと残ってしまうので、計算が終わるごとにdeallocateしたほうが良さそうです。また、まとめて報告します。
今年最後になると思いますが、ゆっくりだけどそれなりコードを書いた一年でした。徐々にストックも溜まってきてうれしいです。来年も頑張ります。
ソースコードだけ見ました。力作ですね。
fortranのcalSectionProfileを呼び出してるということで良いんでしょうか?
Pythonを使ってしまうと、行列の演算は他の言語だとキツくなってきますね。 fortranもライブラリを使えば良いのでしょうが、ちょっとしたものだとどうしてもPythonですね。
楽なのでPythonで書いてしまうのですが、2次元以上だと計算時間が厳しくなって、 結局Fortranで書き換えるのですが、辛いです。
あともはや最近はCを書けなくなってます。ヘッダが書きたくないです。
ソースはWindowsで試してみますね。
可視化が使えるのが良いですね。グラフも綺麗ですし。
仕事では、gnuplotが多いですが、matplotの方がカッコイイです。
会社の人間はあまり新しいプログラミング言語だったり、新しいツールに興味に持つのが難しいようですね。 仕事なので仕方ない部分もありますが。
先月PGIのコンパイラにCommunity Editionが出た模様です。
https://www.softek.co.jp/SPG/Pgi/product.html
基本はフリーで使えますが、最新版のみのライセンスのようです。
また、LinuxとMacのみでWindowsは対応未定のようです。 PGIはGPUとの連携が強いので、使ってみたいです。
Macでは入れてみましたが、特に問題なく動きました。 動作チェックしかしていないので、実行速度については見ていませんし、 家にGPUマシンがないので、ちゃんと使えてはいませんが。。。
本業が忙しくて全然だめです。
以前書いた話の続きですが、pythonからfortranのdllを使うときもやっぱりOOPで書きたいので、チャレンジしてみました。
結果から言うと、main文に共有moduleを設け、その中で共有のclassを設定することにより雰囲気はでました。 C系だとpythonからobjectを渡せるのでこんなことをする必要はないと思いますが、fortranだとこれが限界です。
あと忘れないように書いておくと、fortranのfunctionは使えません。
!file name : test.f90 !class module classModel implicit none private type, public :: model DOUBLE PRECISION :: x contains procedure, public :: init end type contains subroutine init(self, x) class(model) :: self DOUBLE PRECISION, INTENT(IN) :: x self%x = x end subroutine end module classModel !main module pubMod use classModel CLASS(model), ALLOCATABLE :: m end module subroutine init(x) !DEC$ ATTRIBUTES DLLEXPORT :: init use pubMod DOUBLE PRECISION, INTENT(IN) :: x allocate(m) call m%init(x) end subroutine subroutine plus(y, ans) !DEC$ ATTRIBUTES DLLEXPORT :: plus use pubMod DOUBLE PRECISION, INTENT(IN) :: y DOUBLE PRECISION, INTENT(OUT) :: ans ans = m%x + y end subroutine
@echo off gfortran -std=f2003 -shared -o test.dll test.f90
import numpy as np from ctypes import * f = np.ctypeslib.load_library("test.dll",".") f.init_.argtypes = [POINTER(c_double)] f.plus_.argtypes = [POINTER(c_double),POINTER(c_double)] x,y = 2.0 ,1.1 x = c_double(x) y = c_double(y) res = c_double() f.init_(byref(x)) f.plus_(byref(y), byref(res)) print(res.value) # 3.1 del f
DBに置いておくので回してみて下さい。
これを使ってsection2Dモデルの拡張版を書いているので近々公開します。
先日gfortranの4.8が良いって言いましたが、6.0代も安定してますのでこっちのほうが良さそうです。
64bit の Windows10 上でフリーの fortran コンパイラを導入して、簡単なプログラムを作成する - あらきけいすけの雑記帳
exe一発です。
最近知ったのですが、inteのnmakeとgmakeって結構違いますね。どちらでもmake一発でという思いでmakeファイルを書いていたので、残念です。
書く気をなくしました。
結構忙しくて全然書けておりません。すいません。
メールでも送った話ですが結構面白かったので、書いておきます。
不等流計算と不定流計算の定常解の計算値に結構差がでるなと気付き、色々考えてみました。
計算結果がフィールドを対象としているため、結果は出せないのが辛いところです。
物理的な根拠としては、Frが1以下の場合は下流の影響のみで評価できるというのは矩形で、dB/dxが漸変的な流れで導出される考え方であり、当然上下流の影響は受けるとだろうということだと思います。
また、一般断面の場合、Frの定義にもdA/dBを考慮する必要があると思います。
後日式関係も整理しておきます。
この辺のからみで高橋保先生の面白い実験があったので、再現計算してみようと思います。
いっしょにやりませんか。
一般断面のHLLCを書いてほしいなあ。。。
たしか以前Mac OSのアップデートでgfortranに問題あるって言ってましたけど、環境はどうでしょうか?
上記のコードはF2003で書いているのでできれば環境を構築してほしいなと思ってます。gfortran4.8シリーズが安定してるのでおすすめです。5.0シリーズは全然使えないです。
関係ないですがVScode使い始めました。いい出来ですね。まだ慣れてないですが、言語に よってはデバッグもできるようだし、IDE的にもなるのかなと思ってます。
これはいけました.ドライベットです.
流速0かつ凸または凹の処理は,中央差分の限界かもしれないですね.
何とか一工夫して使えるようにしたいです.
なお,gifはここにあげるために強烈に画質を落としてます.