電脳Rubyプロジェクト概要 堀之内 武（京大生存圏研究所）, 西澤 誠也, 高橋 憲義, 水田 亮, 豊田 英司, 塚原 大輔, 竹本 和彰, 小高 正嗣, 林 祥介, 石渡 正樹, 塩谷 雅人, 乙部直人、中野 満寿男, 中島 健介, 神代 剛, 谷口 弘智, 電脳Rubyプロジェクト

目的 Rubyを地球・惑星流体データの解析、可視化、シミュレーション、データベースに用いるための基礎的なライブラリー群を開発する。

なぜ Ruby？ 型なし、スクリプト言語（インタープリター） ⇒ 素早くプログラムが開発できる 　　⇒　素早くプログラムが開発できる 洗練され使いやすいオブジェクト指向言語　⇒　開発・保守効率がよく、汎用なソフトを作り易い　⇒　コミュニティーでツールの共有 対話的に利用可能　⇒　試行錯誤に良い 拡張性が高い　⇒　CやFortranのライブラリーの有効利用 増え続けるライブラリー（ネットワーク関連 / GUI / データベース等々）　⇒　高度なサービスを実現しやすい。 文字処理が容易（データ解析中に文字処理が必要になることは多い） ゴミ集め、例外処理等の近代的支援機能あり

既存のツール・言語があるじゃん？ IDL, Matlab GrADS C,C++,Java,Fortran 手続き型　⇒　汎用なプログラムを作りにくい IDL: 拡張性・発展性に乏しい。Matlab：いろんなツールボックスがあるけど揃えるのは高価。 GrADS 気象分野ではよく使われているが出来ることが限られすぎ C,C++,Java,Fortran データを前に試行錯誤する現場において直接使うのは非効率。むしろインフラ整備向き。

Rubyの利用：実行速度の問題 流体の場合、計算量を増やすのは主にデータサイズ（グリッド数） ⇒ 流体の場合、計算量を増やすのは主にデータサイズ（グリッド数）　⇒ Cのべた並びポインターを構造体にくるんだ多次元数値配列クラスNArrayを利用 C等で書かれた既存数値計算ライブラリーをラッピング

地球流体電脳倶楽部 電脳Rubyプロジェクト 基本的にボランティアベース 現在は、格子点データの解析・可視化関連の開発と情報交換が中心

電脳Rubyホームページ（日本語版） http://ruby.gfd-dennou.org 地球流体電脳倶楽部トップはhttp://www.gfd-dennou.org

電脳Rubyホームページ（英語版） http://ruby.gfd-dennou.org

主な電脳Ruby製品の一覧 (2004年5月現在) 基礎 中間 応用 多次元配列 その他 数値計算・統計ﾗｲﾌﾞﾗﾘ NArray Misc 数値配列 ﾌﾟﾛｸﾞﾗﾐﾝｸﾞ補助 Misc SSL2ラッパー RubySSL2 NArrayMiss 欠損値付 FFTW3ラッパー 多ビット整数（１Ｄ） Units 単位 RubyFFTW3 Multibitnums ファイルIO グラフィックス RubyNetCDF GrADS_Gridded GPV RubyDCL NetCDFラッパ GrADS形式 気象庁データ DCLラッパー 中間 データハンドリング基礎 格子点上の多次元物理量を 包括的に扱うライブラリ GPhys 応用 グラフィックス GUI・グラフィックス 遠隔データアクセス GPhys可視化 （GPhys付属） GPhysデータの解析・可視化 サーバー・クライアント GGraph gave gphys_remote 枠の色： 地の色： （ほぼ）安定 結構開発が進行 初期段階 Pure Ruby Cによる拡張ﾗｲﾌﾞﾗﾘ 斜線：ﾌﾟﾛｼﾞｪｸﾄ外

「中間層」：格子点データ取り扱い基礎ライブラリー GPhys 名前は Gridded Physical quantity より 格子点状に離散化された多次元の物理量を抽象化したクラス 配列データ、格子etc関する付加情報を持つ。単位有。 データの実態は様々あり得る（統一的に扱われる）： メモリ上の配列プラス付加情報 ファイル中に存在（現在はNetCDFとGrADSの2形式） 他のGPhysのサブセット／複数GPhysの合成 数学・統計演算などサポート（但しまだ限られている） メモリー上に乗り切らない巨大データも扱えるよう配慮

応用ライブラリー GPhysを利用する形で構築 GPhysを利用する利点 グラフィカルユーザーインターフェースgave （by 西澤） 分散オブジェクトによる格子点データの遠隔サービス gphys-remote（プロトタイプ版）分散オブジェクトライブラリーdRuby利用 GPhys可視化ライブラリーGGraph GPhysを利用する利点 応用プログラムをデータの物理的な構造による制約から解放： GPhysがサポートするファイル形式が増えれば、応用ライブラリーが扱えるファイル形式が自動的に増える。 ファイル中のデータと、それを読み込んで加工したデータが全く同列に扱える。

gaveのスクリーンショット

パッケージ化 Linux用：Debianパッケージ、RPM Windows用：VC++版用（整備中）、Cygwinパッケージ UNIX系汎用一括インストーラー（ダウンロード込み）

今後期待される発展 インフラの一層の充実！ gave等のGUI, グラフィックライブラリーの充実 分散オブジェクトの活用 Webサービス 数学・統計処理や気象学等個別分野用ライブラリーなど （汎用なライブラリーが作りやすい　⇒　コミュニティーのソフトウェア資産形成） サポートするファイル形式の増加、などなど gave等のGUI, グラフィックライブラリーの充実 分散オブジェクトの活用 データベースとの連携による、遠隔データの解析・可視化の充実 データ公開サーバー構築 Webサービス 数値シミュレーションへの応用 シミュレーションコードが短く、見通し良く書ける。但し遅い。 別言語のコード生成（中野らの発表）

fin

なぜオブジェクト指向？ データの抽象化が必要 コンポーネント間の依存性を減らす必要 似たような、しかし異なるデータが沢山（ファイル形式、次元性、ジオメトリ、単位…）。 抽象化しないと、微妙に異なるプログラムが沢山必要。（プログラムの再利用性が悪い。∴コミュニティーでツールの共有が難しい。） 　[抽象化：物理構造ベース⇒論理ベース] コンポーネント間の依存性を減らす必要 組み合わせて使うソフトが、それぞれ互いの変更に出来るだけ影響されないようにしないと維持が大変。