堀之内 武 - Dennou Ruby

電脳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 多ビット整
数(1D)
ファイルIO
RubyNetCDF
NetCDFラッパ
RubySSL2 SSL2ラッ
パー
FFTW3
RubyFFTW3 ラッパー
GrADS_Gridded
GPV
GrADS形式
気象庁データ
中
間
データハンドリング基礎
応
用
グラフィックス
グラフィックス
RubyDCL
DCLラッパー
格子点上の多次元物理量を
GPhys 包括的に扱うライブラリ
GUI・グラフィックス 遠隔データアクセス
GPhysデータの
GGraph GPhys可視化 gave 解析・可視化 gphys_remote サーバー・
クライアント
(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
なぜオブジェクト指向?
• データの抽象化が必要
– 似たような、しかし異なるデータが沢山(ファイル形
式、次元性、ジオメトリ、単位…)。
– 抽象化しないと、微妙に異なるプログラムが沢山必
要。(プログラムの再利用性が悪い。∴コミュニティー
でツールの共有が難しい。)
[抽象化:物理構造ベース⇒論理ベース]
• コンポーネント間の依存性を減らす必要
– 組み合わせて使うソフトが、それぞれ互いの変更に
出来るだけ影響されないようにしないと維持が大変。