[ 地球流体電脳倶楽部 / davis ]
- 日時: 2007年3月10日(土) 9:00-18:00
- 場所: 東京大学生産技術研究所D棟 6F 大セミナー室 Dw-601
- 大規模なデータを real time に可視化する
- 計算サーバで可視化して X で飛ばすのは UI のストレスなど問題が多い
- SGI OpenGL Vizserver という製品がある
- 値段は億円単位. OS 限定. とにかくよく落ちる
- サーバサイドの可視化は良くないと思った.
- 医療分野の可視化ではニーズがあるようだ.
- これまでの方法は計算サーバで計算, 計算終了してから, データ持って来て可視化.
これだと, 計算が終るまで結果を見ることができない.
- MDRV 発送の起点
- local で可視化
- 計算途中で rsync で持って来るということをすると
何度も大容量データを転送する必要がある. やっぱり差分転送
- netCDF フォーマットのデータ
- 大型計算機には可視化ツールをインストールしにくい
- MDRV
- mdrserver, mdvclient
- 計算サーバにログインして mdrserver を起動
- mdrclient はyaml 形式の設定ファイルで設定を行う.
- 実はnetCDF フォーマットは
- MDRV のセキュリティ
- マルチユーザー
- 1 つの mdrvserver に複数人ぶら下がることができる
- RDB ソフトでは atomic な type が微妙に異なるらしい.
- ソース置場として sourceforge を使えないだろうか?
- 非球形の Mie 散乱計算のライブラリを
堀之内さんの隣の研究室の M2 が半年足らずで作ってしまった.
- 「ルビま」の紹介
- Rails のキーワード
- DRY (Don't Repeat Yourself)
- Convention over Configuration
- Code Generation
- MVC
- GUI 作成でよく使われるデザインパターン
Smalltalk で最初に使われたらしい.
- 例: PC の時計
M: PC の内部クロック
V: 画面上の時計
C: M と V をつなぐもの
- 資料: <URL:http://www.gfd-dennou.org/arch/davis/gfdnavi/doc/register_directory_tree.htm>
- Gfdnavi がスキャンするディレクトリ
- "RAILS_ROOT" は rails を起動したディレクトリ
- 公開データ(ダウンロード可能なデータ)の置き場所は RAILS_ROOT/public 以下に置く
- シンボリックリンクを解釈するようにする予定
- 非公開データ(ダウンロード不可なデータ)が共存する場合は, 1 つの rails で
複数のデータを扱うよりも, 公開データを扱う rails と非公開データを扱う
rails を別々に用意した方が楽であろう.
- メタデータファイル(YAML, SIGEN)
- gfdnavi の表示画面にファイル/ディレクトリに関する説明が追加される.
- YAML と SIGEN が両方ある場合には両方に記載の情報が登録される.
- YAML の方が機能が豊富
- 複数のファイルの変数データを統合した仮想ファイルを作ることができる
- 基本的に % は使わなくて良いはず, 使うな.
- 対象のファイル/ディレクトリが存在しなくなったとき, スキャンすると
エラーが表示される, ただしエラーメッセージはわかりにくい
- エラーメッセージにはユーザに「こうしなさい」という指示を含むように
したい
- データベースへの登録
- 現在はデータの更新分だけ登録することができない.
データに追加があった場合には一度既存の登録をクリアし,
全てのデータを再度登録しなければならない.
ゆくゆくは更新分だけ登録できるようにしたい.
- YAML ファイルの記述方法
- メタデータを付加する場合は SQL の正規表現
- データを統合する場合には shell の正規表現
- 議論
- long_name は yaml ファイルでも指定できてしまうので重複して問題はないか?
- データの再登録方法をいろいろ考えておくとよい
- ディレクトリ構成, ファイル名を変更した場合
- YAML ファイルの名前/記述を変更した場合
- あるディレクトリから先のデータについてのみ何らかの変更を行った場合
- user 領域もスキャンできるようにすること.
データベースの中身を dump できるようにすること.
- 基本的に全部再スキャンするという作戦で良いのではないか.
でも, ある部分だけやり直してくれ, という指定ができるように
できると良いかも(その場合, 変更が正しいとか重複が生じてない
とかの保証はユーザー自身が行う, というポリシー).
それはスイッチで切替えるようにすると良いかも.
- 空間属性の取得
- point 型のデータも, Swarth 型のデータも
緯度・経度に平行な最小矩形の最大値・最小値
が緯度・経度情報として抽出されるメタデータ
となる.
- Google map の ID 取得では, local address でも良い.
- 緯度円, 経度円の指定はまだできてない.
- Exploratory search (探索的検索) として体系化するのも課題.
イメージは mSpace Explore
- 横断検索したいが center server を作るのは大変. よって P2P.
- 分散ハッシュテーブル (DHT)
どこにどういうノードがあるかというテーブルを分散して持っている.
- DHT アルゴリズムとして chord というものを使う.
- 空間情報の登録
- カバーする領域の最大座標と最小座標が入っているセルの ID を使う.
- P2P アプリ構築のためのツールキット Overlay weaver という
ものを使って実装をおこなってみた.
- 議論
- P2P を使うのは情報的な研究課題としては良いんだろうが,
我々としての使い道はどうだろうか?
- MVC
- Model : Rails では大抵の場合, データベースのラッパー.
描画パラメータを受け取って, Vizshoto を返す.
- 描画までの流れ
- drwa ボタンを押すと ajax が
http://host:port/path/analysis/execut を呼び出す.
- すると execute メソッドが呼び出される.
- パラメータ(rails が params に入れてくれる)をもとに analysis model
(具体的には ruby script の temp.rb だと思えば良いのだろう)が作られる.
- Vizshot には, 実際には処理の流れが配列に入っている.
右クリックで保存される script には
覚えている Vizshot が code として吐き出される.
- 吐かれた Vizshot から図を作成する ruby コードを実行する.
この処理に関する general rule としては, 図を作成しておしまい・
後は View におまかせ, である.
- このruby コードで, browser に引き渡す Javascritp (実際には rjs ファイル)
を作ってしまっても良い(controller の中に View の処理を埋め込むことになる).
- ruby script で rjs も生成するようにしておくと
今表示しているページの図を取り換える(実際には html で指定してある
id の部分だけを取り換える, ということができる)ということもできる.
しかも, そのような処理を ruby ぽく書けるので嬉しい.
- マウスによる図移動
- マウスを離すという動作が URL に位置付けられている.
そのURL にはcontroller 名とaction 名が入っている.
あとは ajax の処理.
- 横断検索に関して
- 渡辺さんは Overlayweaver を使っている. これは java.
- jruby というのがあるらしい. java で書かれた ruby interpreter.
- 知見情報の集積
- 文章も一緒に保存できるようにしたい.
簡単にコメント付けられるようにしたい.
- フリッカーというのもあるらしい.
Flicke のことか?
- 各所に分散する web ページをまとめて自分の my page
とか作ることもできるらしい.
- Russ Rew は pdf にデータとか画像とかテキストとか全部つっこんで
そこから情報を引き出すプロトコルを開発中らしい.
revision 管理も導入して, 誰がいついじったかまで管理できるようにする予定.
- GSMaP
davis Group / GFD Dennou Staff 
Last Updated: 2006/03/10 (小高正嗣), Since: 2006/03/10 (小高正嗣)