Transcript 堀之内 武 - 地球流体電脳倶楽部

電脳Rubyプロジェクト概要
堀之内 武（京大生存圏研究所）,
西澤 誠也, 高橋 憲義, 水田 亮, 豊田 英
司, 塚原 大輔, 竹本 和彰, 小高 正嗣, 林
祥介, 石渡 正樹, 塩谷 雅人, 乙部直人、
中野 満寿男, 中島 健介, 神代 剛, 谷口
弘智,
電脳Rubyプロジェクト
目的
• Rubyを地球・惑星流体データの解析、可視
化、シミュレーション、データベースに用いる
ための基礎的なライブラリー群を開発する。
なぜ Ruby？
• 型なし、スクリプト言語（インタープリター）
⇒ 素早くプログラムが開発できる
• 洗練され使いやすいオブジェクト指向言語 ⇒ 開発・
保守効率がよく、汎用なソフトを作り易い ⇒ コミュニ
ティーでツールの共有
• 対話的に利用可能 ⇒ 試行錯誤に良い
• 拡張性が高い ⇒ CやFortranのライブラリーの有効利
用
• 増え続けるライブラリー（ネットワーク関連 / GUI / デー
タベース等々） ⇒ 高度なサービスを実現しやすい。
• 文字処理が容易（データ解析中に文字処理が必要にな
ることは多い）
• ゴミ集め、例外処理等の近代的支援機能あり
既存のツール・言語があるじゃん？
• IDL, Matlab
– 手続き型 ⇒ 汎用なプログラムを作りにくい
– IDL: 拡張性・発展性に乏しい。Matlab：いろんな
ツールボックスがあるけど揃えるのは高価。
• GrADS
– 気象分野ではよく使われているが出来ることが限
られすぎ
• C,C++,Java,Fortran
– データを前に試行錯誤する現場において直接使
うのは非効率。むしろインフラ整備向き。
Rubyの利用：実行速度の問題
• 流体の場合、計算量を増やすのは主にデー
タサイズ（グリッド数） ⇒
– Cのべた並びポインターを構造体にくるんだ多次
元数値配列クラスNArrayを利用
– C等で書かれた既存数値計算ライブラリーをラッ
ピング
地球流体電脳倶楽部
電脳Rubyプロジェクト
• 地球・惑星流体の研究・教育にRubyを活用
するためのプロジェクト
• 基本的にボランティアベース
• 現在は、格子点データの解析・可視化関連の
開発と情報交換が中心
電脳Ruby
ホームページ
（日本語版）
http://ruby.gfddennou.org
地球流体電脳
倶楽部トップは
http://www.gfddennou.org
電脳Ruby
ホームページ
（英語版）
http://ruby.gfddennou.org
主な電脳Ruby製品の一覧 (2004年5月現在)
多次元配列
NArray
基
礎
その他
数値配列
数値計算・統計ﾗｲﾌﾞﾗﾘ
Misc ﾌﾟﾛｸﾞﾗﾐ
ﾝｸﾞ補助
NArrayMiss 欠損値付
Units 単位
Multibitnums 多ビット整
数（１Ｄ）
ファイルIO
RubyNetCDF
NetCDFラッパ
RubySSL2 SSL2ラッ
パー
FFTW3
RubyFFTW3 ラッパー
GrADS_Gridded
GPV
GrADS形式
気象庁データ
中
間
データハンドリング基礎
応
用
グラフィックス
グラフィックス
RubyDCL
DCLラッパー
格子点上の多次元物理量を
GPhys 包括的に扱うライブラリ
GUI・グラフィックス 遠隔データアクセス
gphys_remote サーバー・
GGraph GPhys可視化 gave GPhysデータの
解析・可視化
クライアント
（GPhys付属）
枠の色： （ほぼ）安定 結構開発が進行
地の色： Pure Ruby Cによる拡張ﾗｲﾌﾞﾗﾘ
初期段階
斜線：ﾌﾟﾛｼﾞｪｸﾄ外
「中間層」：格子点データ取り扱い基礎ライブラリー
GPhys
• 名前は Gridded Physical quantity より
• 格子点状に離散化された多次元の物理量を抽象化し
たクラス
• 配列データ、格子etc関する付加情報を持つ。単位有。
• データの実態は様々あり得る（統一的に扱われる）：
– メモリ上の配列プラス付加情報
– ファイル中に存在（現在はNetCDFとGrADSの2形式）
– 他のGPhysのサブセット／複数GPhysの合成
• 数学・統計演算などサポート（但しまだ限られている）
• メモリー上に乗り切らない巨大データも扱えるよう配慮
応用ライブラリー
• GPhysを利用する形で構築
– グラフィカルユーザーインターフェースgave （by 西澤）
– 分散オブジェクトによる格子点データの遠隔サービス
gphys-remote（プロトタイプ版）分散オブジェクトライブラ
リーdRuby利用
– GPhys可視化ライブラリーGGraph
• GPhysを利用する利点
– 応用プログラムをデータの物理的な構造による制約から
解放：
• GPhysがサポートするファイル形式が増えれば、応用
ライブラリーが扱えるファイル形式が自動的に増える。
• ファイル中のデータと、それを読み込んで加工した
データが全く同列に扱える。
gaveのスク
リーンショット
パッケージ化
• Linux用：Debianパッケージ、RPM
• Windows用：VC++版用（整備中）、Cygwin
パッケージ
• UNIX系汎用一括インストーラー（ダウンロー
ド込み）
今後期待される発展
• インフラの一層の充実！
– 数学・統計処理や気象学等個別分野用ライブラリーなど
（汎用なライブラリーが作りやすい ⇒ コミュニティーのソ
フトウェア資産形成）
– サポートするファイル形式の増加、などなど
• gave等のGUI, グラフィックライブラリーの充実
• 分散オブジェクトの活用
– データベースとの連携による、遠隔データの解析・可視化
の充実
– データ公開サーバー構築
• Webサービス
• 数値シミュレーションへの応用
– シミュレーションコードが短く、見通し良く書ける。但し遅い。
– 別言語のコード生成（中野らの発表）
fin
なぜオブジェクト指向？
• データの抽象化が必要
– 似たような、しかし異なるデータが沢山（ファイル形
式、次元性、ジオメトリ、単位…）。
– 抽象化しないと、微妙に異なるプログラムが沢山必
要。（プログラムの再利用性が悪い。∴コミュニティー
でツールの共有が難しい。）
[抽象化：物理構造ベース⇒論理ベース]
• コンポーネント間の依存性を減らす必要
– 組み合わせて使うソフトが、それぞれ互いの変更に
出来るだけ影響されないようにしないと維持が大変。