160 likes | 523 Views
電脳 Ruby プロジェクト概要. 堀之内 武 (京大生存圏研究所) , 西澤 誠也 , 高橋 憲義 , 水田 亮 , 豊田 英司 , 塚原 大輔 , 竹本 和彰 , 小高 正嗣 , 林 祥介 , 石渡 正樹 , 塩谷 雅人 , 乙部直人、中野 満寿男 , 中島 健介 , 神代 剛 , 谷口 弘智 , 電脳 Ruby プロジェクト. 目的. Ruby を地球・惑星流体データの解析、可視化、シミュレーション、データベースに用いるための基礎的なライブラリー群を開発する。. なぜ Ruby ?. 型なし、スクリプト言語(インタープリター)
E N D
電脳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.gfd-dennou.org電脳Rubyホームページ(日本語版)http://ruby.gfd-dennou.org 地球流体電脳倶楽部トップはhttp://www.gfd-dennou.org
電脳Rubyホームページ(英語版)http://ruby.gfd-dennou.org電脳Rubyホームページ(英語版)http://ruby.gfd-dennou.org
主な電脳Ruby製品の一覧(2004年5月現在) 基礎 多次元配列 その他 数値計算・統計ライブラリ NArray 数値配列 プログラミング補助 SSL2ラッパー Misc RubySSL2 欠損値付 NArrayMiss 枠の色: 地の色: FFTW3ラッパー Units 単位 多ビット整数(1D) RubyFFTW3 Multibitnums ファイルIO グラフィックス RubyNetCDF GrADS_Gridded GPV RubyDCL GrADS形式 NetCDFラッパ 気象庁データ DCLラッパー 中間 データハンドリング基礎 格子点上の多次元物理量を 包括的に扱うライブラリ GPhys 応用 グラフィックス GUI・グラフィックス 遠隔データアクセス GPhysデータの解析・可視化 サーバー・クライアント GPhys可視化 (GPhys付属) GGraph gphys_remote gave (ほぼ)安定 結構開発が進行 初期段階 Pure Ruby Cによる拡張ライブラリ 斜線:プロジェクト外
「中間層」:格子点データ取り扱い基礎ライブラリーGPhys「中間層」:格子点データ取り扱い基礎ライブラリーGPhys • 名前は Gridded Physical quantity より • 格子点状に離散化された多次元の物理量を抽象化したクラス • 配列データ、格子etc関する付加情報を持つ。単位有。 • データの実態は様々あり得る(統一的に扱われる): • メモリ上の配列プラス付加情報 • ファイル中に存在(現在はNetCDFとGrADSの2形式) • 他のGPhysのサブセット/複数GPhysの合成 • 数学・統計演算などサポート(但しまだ限られている) • メモリー上に乗り切らない巨大データも扱えるよう配慮
応用ライブラリー • GPhysを利用する形で構築 • グラフィカルユーザーインターフェースgave (by 西澤) • 分散オブジェクトによる格子点データの遠隔サービス gphys-remote(プロトタイプ版)分散オブジェクトライブラリーdRuby利用 • GPhys可視化ライブラリーGGraph • GPhysを利用する利点 • 応用プログラムをデータの物理的な構造による制約から解放: • GPhysがサポートするファイル形式が増えれば、応用ライブラリーが扱えるファイル形式が自動的に増える。 • ファイル中のデータと、それを読み込んで加工したデータが全く同列に扱える。
パッケージ化 • Linux用:Debianパッケージ、RPM • Windows用:VC++版用(整備中)、Cygwinパッケージ • UNIX系汎用一括インストーラー(ダウンロード込み)
今後期待される発展 • インフラの一層の充実! • 数学・統計処理や気象学等個別分野用ライブラリーなど (汎用なライブラリーが作りやすい ⇒ コミュニティーのソフトウェア資産形成) • サポートするファイル形式の増加、などなど • gave等のGUI, グラフィックライブラリーの充実 • 分散オブジェクトの活用 • データベースとの連携による、遠隔データの解析・可視化の充実 • データ公開サーバー構築 • Webサービス • 数値シミュレーションへの応用 • シミュレーションコードが短く、見通し良く書ける。但し遅い。 • 別言語のコード生成(中野らの発表)
なぜオブジェクト指向? • データの抽象化が必要 • 似たような、しかし異なるデータが沢山(ファイル形式、次元性、ジオメトリ、単位…)。 • 抽象化しないと、微妙に異なるプログラムが沢山必要。(プログラムの再利用性が悪い。∴コミュニティーでツールの共有が難しい。) [抽象化:物理構造ベース⇒論理ベース] • コンポーネント間の依存性を減らす必要 • 組み合わせて使うソフトが、それぞれ互いの変更に出来るだけ影響されないようにしないと維持が大変。