2016/02/12 電脳倶楽部ミーティング 議事録
履歴
- 2017/02/21 荻原弘尭 修正
- 2016/02/12 荻原弘尭 初版作成
Ruby による科学技術計算・可視化の動向に関する議論
現状 (堀之内)
- Ruby で科学計算の歴史
- RubyMath (2000 年) フェードアウト
- 多次元配列は NArray が良くつかわれていた
- SciRuby (2009 年)
- インタラクティブ (IRuby) 上でプロットとかもできる
- チュートリアルの DennouLive で使うなら
- https://github.com/SciRuby/iruby/blob/master/README.md の Ubuntu/Debian を見てやるとできる
SciRuby (西田)
- 科学技術用向けのライブラリをRuby で使用という団体
- 創始者: Jhon さん
- 基本的にメールでやり取り
活動
- 科学技術系 gem のメンテ
- GSoC というイベントでコードを書かせている
- Google Summer of Code
- 学生にお金を配ってコードを書かせる
- Google Summer of Code
作ったソフト
- NMatrix
- 配列順序は C-order
- 標準で配列的な操作になる
- API は Numpy 風
- 欠点
- core dump しやすい
- gem install nmatrix で入らない
- Daru
- 2014 にできたデータフレーム gem
- csv 等の統計的な操作とかできる
- その他いろいろ
IRuby
- インタラクティブにブラウザ上でruby を実行できる
- IRuby は Jupyter(python) に依存している
- Mathmatica, MATLAB みたいなことができる
- Web 上でスクリプトを回して計算, 可視化ができる
- 共有が楽
- 現在の使用状況
- アメリカでは大学の授業に使われている
- Cookpad など
- 本日の資料の場所
- http://naoki.pw/ruby/
Jupyter
- 歴史
- 2012 年に IPython としてスタート
- 2014 年に IPython と Jupyter のチームが分割
- 1か月後に Jupyter が IPython を吸収した
- 検索するなら IPython の方がヒットしやすい
- Jupyter はIRuby とフロントエンドの間に入るインターフェース
- Jupyter のサーバに格納されたデータをフロントエンドに返す
- IPython やIRuby などはカーネルの名前
- Jupyter のサーバに格納されたデータをフロントエンドに返す
- インタープリンタとやり取りするだけなのでカーネルを作るのが簡単.
- ドキュメントもちゃんとある
Nyaplot
- ブラウザ上でプロットができる
- 2D, 3D, 地図その他もろもろ
- SVG や WebGL で稼働
- 出力は PNG か SVG
- Web から離れることはできない
- Ruby のコードでJSON を生成, javaScript に JSON を渡して描画してもらう
- Ruby は JSON をいじるだけ, JavaScript が JSON を解釈して書く
各活動の進捗状況
dennou ruby 現状報告・議論
GPhys/GGraph (堀之内)
- 問題
- 現在依存している NArray は fortran-order
- この先業界は C-order に移行していく
- それに対して GPhys 自体は C-order に対応するのは難しくないがユーザ側がそれに対応できるかが問題
- NArray の方にスイッチを付けて fortran-order と C-order で分けられるようにする ?
- NMatrix を使うべきかどうか
- 長期のメンテナンス的に NArray は田中さん一人しかいないので不安
- NMatrix は実働隊はたくさんいる
- もし使うなら NMatrix の開発にも積極的にかかわっていく
- 試しに NMatrix 版の拡張ライブラリ一つ作ってみる ?
- 人員募集中
- 長期のメンテナンス的に NArray は田中さん一人しかいないので不安
- 現在依存している NArray は fortran-order
- memo
- 2 GB 以上のファイルを扱える西沢さん謹製 NArray
- 2 GB の壁を超えた NArray を西沢さんが作ってフォークをしていた
- 現在以前のものと名前が同じだった
- フォークされていたものを NumRu 以下に入れるのに合わせて以前のものと被らないように名前を変更する必要がある
- numru-narray
- 2 GB の壁を超えた NArray を西沢さんが作ってフォークをしていた
- 2 GB 以上のファイルを扱える西沢さん謹製 NArray
binary packaging 現状
cygwin package (大塚)
- ruby は gem で入れられる
- 次は dcl を何とかしなくてはいけない
debian package (佐々木)
- リポジトリは wheezy はもう取り合わない
- jessie, stretch, sid のみ
ubuntu package (乙部)
- gtool 以外は新しくなっている
windows installer (乙部)
- 順調に進んでいる
rubygems (堀之内)
- 着々とリリースしている
- ToDo
- git で同じリポジトリにgem_spec ファイルが二つあると気持ちが悪い
- ブランチを分けてほしい
- gem_spec
- git ls-files を消してほしい
- rb-gsl への依存性をなくす
- 推奨程度にする
- git で同じリポジトリにgem_spec ファイルが二つあると気持ちが悪い
FreeBSD ports/packages (村上(真))
- portsについて
- RubyLapack をサブミット
- GPhys サブミット
- コンパイルできないためにリジェクトされた
rpm (西澤)
- fedora について
- ちょこちょこ進んでいる
- suse について
- 作ったが公開していない
Mac ports (樫村)
- Ruby 1.8, 1.9. 系列のサポート終了
- Ruby 製品は gem install させる
- (C-)DCL を廃止して (C-)DCL5 と (C-) DCL6 に
- 提供は MacPorts-JP を通じて
- Homebrew
- 佐々木さんが DCL (Fortran版) をサポートしている
- https://github.com/uwabami/homebrew-dennou
- 佐々木さんが DCL (Fortran版) をサポートしている
- 問題
- GPhys が gem でインストールできない
- rb-gslが GSL のバージョンに対応していないので他の物もパッケージで提供できない
- rb-gsl を依存にしないで推奨程度にしてもらう
- rb-gslが GSL のバージョンに対応していないので他の物もパッケージで提供できない
- GPhys が gem でインストールできない
DCL 現状報告 (樫村)
- DCL でシステムフォントが使えるようになった
- gid リポジトリの systemfont ブランチで今すぐ試せる
- $ git clone -b systemfont ssh://dennou-k.gfd-dennou.org/GFD_Dennou_Club/ftp/arch/dcl/git_repos/dcl.git
- 従来はストロークフォント
- 線と同じように文字を書く
- gid リポジトリの systemfont ブランチで今すぐ試せる
- システムフォント
- システムフォントを使って DCL の文字が書ける
- システムフォントでもストロークフォントと同じところに同じ文字を書ける
- コンターラベルもちゃんとできる
- utf-8 対応で日本語やほかの国の言語, 記号も使える
- 従来とほぼ同じように制御できる
- 使い方
- SW_SYSFONT (論理型)
- TRUE: システムフォント
- FALSE: 従来通り
- SW_FONTNAME (文字列)
- フォント名を指定う
- スタイルも指定可能
- Bold 等
- SW_SYSFONT (論理型)
- demo もある
- demo/tmp_sysfont/
- listfont.f: ターミナルにフォント名の一覧を表示
- sgfont_select.f: GUI でフォントを選ぶ
- sysfont.f: 印字サンプルリスト
- demo/tmp_sysfont/
- Pango マークアップ記法が可能
- 現在は文字列 80 byte 制限がある
- 緩和される予定 (とりあえず 1024 byte)
- 現在は文字列 80 byte 制限がある
- マークアップ記法を応用してオーバーラインを実装
- ただし複数文字は不可
- ハイフンマイナスはマイナスに置換される
- ハイフンを打ちたい場合は(ハイフン) を入力する
- [unicode ハイフン マイナス] で検索すると詳しくわかる
- ハイフンを打ちたい場合は(ハイフン) を入力する
- 欧文フォント指定時に日本語を入力すると和文フォントを使う
- Sans, Serif, Monospace は環境毎に実体が違う
- スタイル名は適当に置き換えてくれる
- 対応していない機能
- 文字の太さはフォント依存, スタイルで多少は変更化
- SG_LCNTL 等の途中変更には対応していない
- クリッピング
- マーカー記号がフォントによって大きさが変わるので従来通りにしている
- システムフォントを使って DCL の文字が書ける
- Todo
- SG 系内部変数の途中変更の反映
- クリッピング
- マーカー記号のフォント化
- フォント未指定時に IFONT, LFPROP に合わせてデフォルトシステムフォントを変える
- 文字列 80 byte の緩和
- コードの整理
- Windows 版対応
- 議論
- アンダースコアが下付き添え字になってしまう
- SG_LCNTL が true の時は下付き文字になり false のときはそのまま出力する
- もし従来型と仕様を変更するなら互換性を犠牲にしていいのか ?
- 従来のと同じ始まりと終わりがそろっていればよい ?
- マークアップ法を変えることでできるようになればいいのでは ?
- アンダースコアを書きたいならエスケープシーケンスを付ける ?
- いろいろな付属ツールはどうするの ?
- dclpsrot とか
- 現在は pdf で出すので使わない
- 今後は付属しないようにする
- 今後デフォルトをどっちにするの ?
- 今のところは決まっていない
- デフォルトはどこでも同じになってほしい
- 今のところ無理
- 再配布可能なフォント(デジャブフォント)を付ける?
- 個人の感覚もあるのでどうするか悩んでいる
- 従来のフォントはライセンス的に大丈夫なので従来のものをデフォルトにする
- debian パッケージ化
- man が必要
- debian で irb で絵をかくとウィンドウなどで一度覆ってしまうと再描画されない
- アンダースコアが下付き添え字になってしまう
gtool5 現状報告 (佐々木)
- gfortran5 でビルドできない
- 暗黙の型誓言がいっぱいある
- gfortran4から 5 で gcc の仕様が変わった
- Ubuntu16.04 で gfortran5 がデフォルトになるのでそれのリリースまでに gtool5 をリリースしなければいけない
- 4 月までが期限
- dc_test の改善をずっとやっていた
- 文字列の処理が問題になっている
- gtool5 は gtool4 NetCDF 規格とは異なっている
- gtool5 は NetCDF ファイルに描画情報を書き出していない
- GTOOL4 NetCDF 規格を書き換えるべき
- 誰がするべき ?
- GTOOL4 NetCDF 規格を書き換えるべき
- gtool5 は NetCDF ファイルに描画情報を書き出していない
dcmodel 現状報告 (竹広)
- いくつかの資源は git へ移行
- DCPAM
- spmodel
- etc
- ブラウン大学とシミュレーションスクール
- あまり gpview とか GPhys は使われなかった. Paraview が良くつかわれた
- モデルのコンパイル方法の改善
- spmconfig, gt5config を使ってオプション指定を楽にする
dcrtm (大西)
- 地球を含め, 多様な惑星の放射計算を行うことを目指したモデル
- line-by-line 放射伝達モデル
- 公開できる段階
- GCM 用 k 分布吸収係数作成モデル
- GCM でも回るくらい軽いモデル
- 現在試作段階
- ドキュメント
- チュートリアルやマニュアルを非公開領域に格納
- https://www.gfd-dennou.org/GFD_Dennou_Club/dc-arch/dcrtm/
- Todo
- ライセンスどうするの ?
- dcrtm には MT_CKD が含まれている
- MT_CKD は line by line 計算で地球計算するために必要
- dcrtm と MT_CKD モデルとの関係をどうするか?
- 現在一部ファイルを MT_CKD から流用している状態
- MT_CKD 由来のファイルとそれ以外の dcrtm のソースコードが適切に分離されている状況ではない
- MT_CKD の中身をちょっと書き換えてサブルーチンで呼び出せるようにした
- MT_CKD 由来のファイルとそれ以外の dcrtm のソースコードが適切に分離されている状況ではない
- MT_CKD はノンフリーライセンス
- オープンソースでは使えない.
- 商用利用はできず研究用のみ
- 一緒に配布は難しい
- 同梱せず, MT_CKD を個人でもらってきてこれのここを書き換えてという README を書く?
- ユーザーが持ってきてもらって make かなんかで使えるように書き換えるスクリプトを書く?
- オープンソースでは使えない.
- README に自分たちが書いた場所はここまでです一部 MT_CKD に依存していますと書いて MT_CKD のライセンスはこちらですと書く. 最後にだれか MT_CKD と繋げる部分を書いてくれという希望を書いておく.
- 現在一部ファイルを MT_CKD から流用している状態
- dcrtm には MT_CKD が含まれている
- ライセンスどうするの ?
spmodel (竹広)
- Web ページを改善
- 並びを変更
- 新モジュールの追加
- w_plane_module : 2 次元無限領域モジュール
- fe_module : 無限領域 + 周期境界条件モジュール
- wq_zonal_module : 球内軸対称領域モジュール
- サンプルプログラムと解説の追加
- ロスビー波(初期値問題, 山岳応答) (w_plane_module)
- 地衡流調節問題 (w_plane_module)
- 順圧不安定 (fe_module)
- 慣性不安定 (wq_zonal_module)
- シアー流中の内部重力波 (et_module)
- シアー流中のロスビー波 (et_module)
- QBO (et_module)
- 傾圧不安定(Eady 問題) (tee_module)
- まだ Web ページのサンプル集にまとめていない
- 資源の git への移行
- Todo
- spml のインストールを簡単にしたい
deepconv (小高)
- 計算例
- 土星・天王星計算
- 2D
- dx=fz = 2km
- 熱強制は固定 ( 木星計算の3 倍の値)
- 金星
- 2D/3D
- 128kmx128kmx30km
- dx=dy=200m, dz = 124m
- 熱強制は鉛直1D モデルで計算された分布を与える
- 2D は水平鉛直に領域を拡大して計算
- 火星
- 2D/3D
- 50kmx20km
- dx=dz=100m
- LT=14 にすると温位などが Odaka et al. 2001 と合う
- それ以外の時間だとarare5 の方が大きくなってしまう
- 地表面近くの格子点間隔が違うことが原因 ?
- 非一様な格子間隔を実装する必要がある ?
- 地表面近くの格子点間隔が違うことが原因 ?
- それ以外の時間だとarare5 の方が大きくなってしまう
- 現状報告
- 地表フラックス計算モジュールの導入
- DCPAM のコードを移植
- DCPAM の方のバージョンが上がったのでそれと合わせるようにしなければならない
- DCPAM のコードを移植
- arare6 の開発
- 木星計算を arare5 と arare4 で微妙に異なる
- arare4 から arare5 への改編項目が多すぎて原因が特定できない
- arare4 と arare5 をつなげるように arare6 を作成
- 地表フラックス計算モジュールの導入
- 今後の方針
- 年度前半で力学コアの整備, 終わり次第物理過程へ
- 不等間隔格子
- 現在のコードでテストしたが微分演算の精度が悪い(1次精度しかない)
- 離散化の問題
- 4 次精度の離散化の仕方が分からない
- 現在の気象業界では任意の不等間隔では 2 次精度程度のものまでしか使ってない
- あまりこだわってもしょうがないのでは?
- 2 次精度のものまでとりあえず入れることにする
- 安直に行うと精度が確保できない
- 現在のコードでテストしたが微分演算の精度が悪い(1次精度しかない)
- 移流スキームの保存性チェック
- そもそも 4 次精度になっていなかった
- 微分値から格子点を出すときに平均を取ってしまっているので 2 次精度しか出てなかった
- 世の中のモデルもそれが多い
- これもあまりこだわってもしょうがないのでは?
- 世の中のモデルもそれが多い
- 微分値から格子点を出すときに平均を取ってしまっているので 2 次精度しか出てなかった
- 非線形項を以下の様に変形してから差分化した方が精度が良いらしい
- u dA/dx = d(uA)/dx - A du/dx
- 流れがほとんど非発散だと右辺の第二項が積分して落とせる
- そもそも微分式が保存していないのでどれだけ違うかわからない
- u dA/dx = d(uA)/dx - A du/dx
- そもそも 4 次精度になっていなかった
DCPAM (高橋)
- 開発
- デバッグ
- 火星条件での水蒸気(&アルゴン)分布の計算
- 地球に加えて火星条件での検証
- 氷が降ったり, 火星用の物理過程を足したりしていてるが苦労している
- 地球に加えて火星条件での検証
- 計算
- それぞれの人がいろいろ行っている
- 竹広さんが木星計算を今年になって行った
- パラメータ設定を改良したら shnaidour and liu を再現できた
- ブラウン大学とシミュレーションスクール
- DCPAM を使わせてみた
- 地球の風と会わない問題は目算が立っていない
ウェブページ整理
電脳 Ruby
- 特にない
その他
gui でdcpam の計算結果を可視化(高橋)
- GUI 的にインタラクティブに絵を描ける
- ruby で作成
ruby-mpi (西澤)
- ruby で mpi ができる
- jessie にはパッケージがある
DCPAM と海洋海氷モデルを結合のときの困ったこと (河合)
- Jcup (カップラー) で結合
- 大気モデルや海洋モデル毎に MPI コミュニケータを使い分ける
- dcmodel は使い分けしていない
- MPI_COMM_WORLD を指定して MPI 通信
- カップラーが与えたコミュニケータグループを利用するように変更が必要
- spml と ISPACK 内の一部ルーチン
- DCPAM の mpi ラッパー
- gtool は該当箇所を書きかえれなかった
- DCPAM には並列用の gtool5, 海洋モデルにはシリアル用の gtool5 を性的リンクしてごまかした
- カップラーが与えたコミュニケータグループを利用するように変更が必要
- MPI_COMM_WORLD を指定して MPI 通信
configure (佐々木)
- 現在は gnu make に依存している
- configure を書き換えるべき
- configure.ac, Makefile.am を作って $ autoreconf --install をすると configure や Makefile.in が生成される
- configure を書き換えるべき
NArray と NMatrix を比べてみた (樫村)
- 単純に配列 (要素 300000) 同士を足して一つの配列に入れ直す計算を 300 回してみた
- NArray
- 0.24 real 0.15 user 0.08 sys
- NMatrix
- 12.76 real 12.52 user 0.22 sys
- NArray