日本の某大手学会の論文の査読で reject しまっくていたら、最近ではその学会から査読依頼が来なくなった。どうみてもせいぜい修士論文レベルで学会のためを思って reject したら、editor から accept してくださいと言われた。仕方が無いので掲載するならば editor の責任でやってくださいと言っておいた。その後どうなったかは知りませんが、その editor の先生から別の学会誌の査読依頼が来たので、学会の方針として基本的に通すということだと思い、editor の方も大変そうだ。
今後のクラスタ計画についてあれこれ考慮中です。以下はあくまでも計画案です。
SCore 開発者によるとそろそろ Kernel 2.6.x (Fedora Core 3) ベースで新バージョン(6.0?)
が出るらしいです。
1: SDPA クラスタ(Athlon 2GHz × 80)
現在の RedHat 7.3(Kernel 2.4.21)はそろそろ古いので、Fedora Core 3(Kernel 2.6.x)に
入れ替え、SCore も 6.x にする。これは大変な作業。
2: OPT クラスタ(Opteron 1.4GHz × 32)
これも Fedora Core 3 & SCore 6.x に入れ替えか。そうすると Network Trunking で Gigabit
Ethernet ２本が有効に使えます。Jumbo Frame 対応のハブも必要か？
3: COE クラスタ(Xeon 2.8GHz × 16)
すでに Fedora Core 3 なので、SCore 6.x を入れるぐらいか？ むしろ SCore は要らないので、
Fedora Core 4 にしてもいい。
4: 新クラスタ
検討中だが、Dual Core の Opteron 275 2way あたりが面白いのでは。
いずれにしても大変な作業。大学に合宿するぐらいの気合いが必要かも。
SCore 開発者によるとそろそろ Kernel 2.6.x (Fedora Core 3) ベースで新バージョン(6.0?)
が出るらしいです。
1: SDPA クラスタ(Athlon 2GHz × 80)
現在の RedHat 7.3(Kernel 2.4.21)はそろそろ古いので、Fedora Core 3(Kernel 2.6.x)に
入れ替え、SCore も 6.x にする。これは大変な作業。
2: OPT クラスタ(Opteron 1.4GHz × 32)
これも Fedora Core 3 & SCore 6.x に入れ替えか。そうすると Network Trunking で Gigabit
Ethernet ２本が有効に使えます。Jumbo Frame 対応のハブも必要か？
3: COE クラスタ(Xeon 2.8GHz × 16)
すでに Fedora Core 3 なので、SCore 6.x を入れるぐらいか？ むしろ SCore は要らないので、
Fedora Core 4 にしてもいい。
4: 新クラスタ
検討中だが、Dual Core の Opteron 275 2way あたりが面白いのでは。
いずれにしても大変な作業。大学に合宿するぐらいの気合いが必要かも。
大地震東京危険度マップ（朝日出版社）という本を買ってみた。
このマップの特徴は個々のビルや家を対象にしたものではなく、東京のほぼ全地域を
1: 避難場所
2: 地区内残留地域（避難の必要なし)
3: 避難危険度が高い地域（避難所が遠い、道が悪いなど）
4: 建物倒壊危険度が高い地域（地盤が悪い、液状化など）
5: 火災危険度の高い地域（木造住宅が密集など）
6: その他（そんなに危険ではないが、避難する必要あり）
7: データなし
の７つに分類したもの。意外なことに千代田区、中央区はほとんど 1 か 2 だった。
RC 造などの不燃系の建物が多く、火災が延焼しにくいようだ。
この地域では自分の建物が倒壊したり、燃えたりしなければ、敢えて避難する必要はないらしい。
とは言っても、この２区を囲む多くの区（新宿、文京、豊島、品川、北、足立、下町付近）が
3, 4, 5 の地域を多く持っているので、逃げるのは大変だし、交通機関もないのでむしろ都心で一泊
した方が無難かもしれない。下町は地盤は悪く、木造が密集しているので大変危険なようだ。
このマップの特徴は個々のビルや家を対象にしたものではなく、東京のほぼ全地域を
1: 避難場所
2: 地区内残留地域（避難の必要なし)
3: 避難危険度が高い地域（避難所が遠い、道が悪いなど）
4: 建物倒壊危険度が高い地域（地盤が悪い、液状化など）
5: 火災危険度の高い地域（木造住宅が密集など）
6: その他（そんなに危険ではないが、避難する必要あり）
7: データなし
の７つに分類したもの。意外なことに千代田区、中央区はほとんど 1 か 2 だった。
RC 造などの不燃系の建物が多く、火災が延焼しにくいようだ。
この地域では自分の建物が倒壊したり、燃えたりしなければ、敢えて避難する必要はないらしい。
とは言っても、この２区を囲む多くの区（新宿、文京、豊島、品川、北、足立、下町付近）が
3, 4, 5 の地域を多く持っているので、逃げるのは大変だし、交通機関もないのでむしろ都心で一泊
した方が無難かもしれない。下町は地盤は悪く、木造が密集しているので大変危険なようだ。
AD-POWERsについて、調べたり聞いたりしてみた。
1: Windows 専用のソフト（マスタ、ワーカ型）
アプリケーションは、コンパイルして DLL にする。
DLL を、AD-POWERs が各ワーカに配布する。
2: ブロードキャストを活用しているため、
全 PC は同一ブロードキャストドメイン内、
つまりサブネット内に設置されている必要がある。
よって 254 台までの接続が可能。
調べてみますと、やはり Ninf や MPI とは相当違うようだ。
1: Windows 専用のソフト（マスタ、ワーカ型）
アプリケーションは、コンパイルして DLL にする。
DLL を、AD-POWERs が各ワーカに配布する。
2: ブロードキャストを活用しているため、
全 PC は同一ブロードキャストドメイン内、
つまりサブネット内に設置されている必要がある。
よって 254 台までの接続が可能。
調べてみますと、やはり Ninf や MPI とは相当違うようだ。
GridASP をユーザーとして使用することになりそうです。GridASP とはグリッドビジネスポータルを構築するためのソフトで、単なるグリッドポータルならば楽なのですが、ビジネスになると、ユーザー管理、資源管理、セキュリティ、課金、性能保証などがあって大変面倒で開発者の方には頭が下がります。
GridASP は ACT-JST で作成していたGridLibを発展させたものだそうです。こちらは以前使用して SC2003 などで発表しました。少々使い勝手が良くなかったと思いますが、どう変わっているのか楽しみです。
将来的にどう使うのかは未定ですが、せっかくの枠組みですから是非試してみたいところです。
GridASP は ACT-JST で作成していたGridLibを発展させたものだそうです。こちらは以前使用して SC2003 などで発表しました。少々使い勝手が良くなかったと思いますが、どう変わっているのか楽しみです。
将来的にどう使うのかは未定ですが、せっかくの枠組みですから是非試してみたいところです。
こちらについてですが、コンピュータサーバーなどは今でも Intel や AMD が大きなシェアを持ってますので、デジタル機器に力を入れていくのはわかります。ただ、PowerPC G5 互換から言っても Mac は Cell系を採用するかもしれません。そうなると Mac サーバーを衝動買いしそうです。Cell は内部の SPE の数を変更したり用途に応じて様々な構成が可能なので、その内にいろいろなバージョンが出てくるでしょう。研究室のクラスタもまだ活躍できそうです。
こちらの記事に同感。メタ解法の漠然としたアイデアなどは誰でも出せるもので、実際に構築して実験的解析に持っていく力量が重要だと思う。私自身もこの世界（メタ解法、近似解法）では、ベンチマーク問題による比較すら悲観的で、SDP に関する経験などから考えて
1: 自分で自分のソフトを評価するとどうしても評価が甘くなりがちであり、ソフトは他人に渡して評価してもらえるような体制を作るべき。他人は多くの時間を掛けて実験したり、パラメータチューニングしてくれないので、自分で実験する場合と比べて結果が何割か悪くなる。ましてや研究者以外の一般ユーザーならばデフォルトの設定で使うのが精一杯では。比較数値実験の論文で、自分のソフトと同じくらい手間ひまかけて他人のソフトを実験している人はいったい何人いるのだろうか？
2: 1 と同じだが、開発者以外のユーザーが多数評価してくれて、はじめて優れたソフトということになろう。ソフトを公開しない、できないのなら、本来応用、実務志向のメタ解法の世界に論文を出さない方が良いと思う。もちろん単に公開しただけではユーザーは付きませんが。
メタ解法の論文や発表は、”私はこう考えて、こういう風に作ったら、他と比べて良かったです。おしまい”というのが多いので、聞いている方、読んでいる方も本当にそうなのかも検証出来ずに”はい。そうですか”としか言いようもなく無駄な時間を過ごしている気分になる。これも他の分野（例えば数理計画法）だと、アルゴリズムや内容からある程度の性能に関する予想が付き、聞いているだけでも結構程度判断できるのだが。
1: 自分で自分のソフトを評価するとどうしても評価が甘くなりがちであり、ソフトは他人に渡して評価してもらえるような体制を作るべき。他人は多くの時間を掛けて実験したり、パラメータチューニングしてくれないので、自分で実験する場合と比べて結果が何割か悪くなる。ましてや研究者以外の一般ユーザーならばデフォルトの設定で使うのが精一杯では。比較数値実験の論文で、自分のソフトと同じくらい手間ひまかけて他人のソフトを実験している人はいったい何人いるのだろうか？
2: 1 と同じだが、開発者以外のユーザーが多数評価してくれて、はじめて優れたソフトということになろう。ソフトを公開しない、できないのなら、本来応用、実務志向のメタ解法の世界に論文を出さない方が良いと思う。もちろん単に公開しただけではユーザーは付きませんが。
メタ解法の論文や発表は、”私はこう考えて、こういう風に作ったら、他と比べて良かったです。おしまい”というのが多いので、聞いている方、読んでいる方も本当にそうなのかも検証出来ずに”はい。そうですか”としか言いようもなく無駄な時間を過ごしている気分になる。これも他の分野（例えば数理計画法）だと、アルゴリズムや内容からある程度の性能に関する予想が付き、聞いているだけでも結構程度判断できるのだが。
COEの研究用に3次元マンデルブロー図形を高速に計算、描画するプログラムを作成した。非線形システムを対象とした安定化可能領域を調べるとマンデルブロー集合のようなフラクタル構造を持っているので、目的は高速計算、描画してパラメータのどの領域が安定、不安定が調べることにある。基本システムが完成したので、次は複雑なシステムに対応していくことになる。特徴としては、
1: 画像ピクセルをある程度の単位に分割して Ninf による並列計算
2: GUI は Qtで作成
個人的には Qt は割と気に入った。
メタ解法などの最適化でも、こんな感じでいろいろ表示出来ると便利で面白いと思うので、考えてみよう。
1: 画像ピクセルをある程度の単位に分割して Ninf による並列計算
2: GUI は Qtで作成
個人的には Qt は割と気に入った。
メタ解法などの最適化でも、こんな感じでいろいろ表示出来ると便利で面白いと思うので、考えてみよう。
こちらによると、噂には出ていたが Cell のワークステーションも順調に開発しているらしい。問題は値段だが、PS3 が大量に出回れば Cell もメモリも安くなるのではと期待できる。Cell と言っても、興味の対象は PS3 ではなく、ほとんどこちらの計算用サーバーだけ。実際にはコンパイラの問題や本当に科学技術計算に有効か（単精度演算重視？）など不確定要素が多いのだが、今後も注目していきたい。
前にも書いたように gcc 4.0.0 を使い始めた。そこで glpk4.7 と glpk4.8 及び gcc 3.4.3 と gcc 4.0.0 を用いていろいろな組合せを試したみたが、特に有意差なし。そのため当面 gcc 3.4.3 と glpk 4.8 を用いることにする。
さて以下のファイルにロットサイズ決定問題に対する容量スケーリング法の実験結果が入っている。
数値実験結果
データはこちら
上記のファイルにあるように、容量スケーリング法のパラメータλを 0 から 1 の間で変化させながら、どのλの値が最も値が良かったのかが載せてある。しかし、この場合に容量スケーリング法が終わったあとに、値を改善させるような簡単な近傍探索が入っているので、実際にはその改善も含めて一番結果が良かったλを載せている。
例えば S-10-10-1-1 の問題では、
λ 容量スケーリング法終了時 近傍探索改善後
0.1 25939 25308
0.2 26579 25303
0.3 26172 25322
0.4 26124 25323
0.45 25961 25209*
0.5 25886 25300
0.6 25739 25619
0.7 25735 25434
0.8 25691* 25555
0.9 25757 25333
容量スケーリング法では λ=0.8 が一番良いが、最終的には λ=0.45 が良くなっている。
面白いことに結果からは最良のλの値はばらばらで傾向は見えにくい。
メタ解法では、初期解は悪くても改善近傍探索が良ければ最終結果は逆転することは
良くあるし、あまり中途半端に良い初期解を出して形を決めない方が良い場合も多い。
だから容量スケーリング法の解を他の方法の初期解に使えるかどうかも見極めた方がいいですね。
さて以下のファイルにロットサイズ決定問題に対する容量スケーリング法の実験結果が入っている。
数値実験結果
データはこちら
上記のファイルにあるように、容量スケーリング法のパラメータλを 0 から 1 の間で変化させながら、どのλの値が最も値が良かったのかが載せてある。しかし、この場合に容量スケーリング法が終わったあとに、値を改善させるような簡単な近傍探索が入っているので、実際にはその改善も含めて一番結果が良かったλを載せている。
例えば S-10-10-1-1 の問題では、
λ 容量スケーリング法終了時 近傍探索改善後
0.1 25939 25308
0.2 26579 25303
0.3 26172 25322
0.4 26124 25323
0.45 25961 25209*
0.5 25886 25300
0.6 25739 25619
0.7 25735 25434
0.8 25691* 25555
0.9 25757 25333
容量スケーリング法では λ=0.8 が一番良いが、最終的には λ=0.45 が良くなっている。
面白いことに結果からは最良のλの値はばらばらで傾向は見えにくい。
メタ解法では、初期解は悪くても改善近傍探索が良ければ最終結果は逆転することは
良くあるし、あまり中途半端に良い初期解を出して形を決めない方が良い場合も多い。
だから容量スケーリング法の解を他の方法の初期解に使えるかどうかも見極めた方がいいですね。
つくばSAOR1とつくばSAOR2のお話に関して今日は SDP(半正定値計画問題)についてまとめてみます。つくばでの研究会では SDP 関連の講演が多かったそうです（半分は内輪かも）。また K 師匠によるとスウェーデンの SIOPT でも、かなり SDPA について関心も持ってもらったそうです。
K 師匠だったと思いますが、SDP は 21世紀の線形計画問題(LP)と言ってました。私もかつての LP のように気軽に SDP を使ってと言ってます。単なる SDP でしょ、そんなのは軽いと言うわけです（少し大胆ですが）。
SDPA の開発チームも大変増えて（ざっと７人はいます：K, F, N, Y, F, K, F)、おそらく世界中全ての SDP 開発チームのなかで最大だと思います。本当にいろいろなバージョンがありますというか、出来てきました。こちらも参照してください。
1: SDPA (SDP を解くための主双対内点法のソフトウェア。もっとも基本的でノーマルなソフト。最も古く、格が最上。1995年より公開中）
2: SDPA-CG (Shur Complement 行列の線形方程式を解くために CG 法を用いている。良い条件の前処理方法が見つからなかったので、特殊な場合のみ有効。公開していない）
3: SDPA-C (入力問題の疎性の処理に行列補完による方法を用いている。公開中だが使用は SDPA-C の並列版 SDPARA-C をお勧めします)
4: SDPARA (SDPA のボトルネックの部分を MPI を用いて並列化したもの、SDPA と並ぶ主力ソフトウェア。公開中)
5: SDPARA-C (SDPA-C を並列化したもの。並列化思想は SDPARA とほぼ同じ。公開中。問題によっては全 SDPA の中で最速を誇る）
6: SDPA-M (SDPA に Matlab インターフェイスを付けたもの。当初の予定を裏切って意外とユーザーが多い。公開中。このために米国 V 大の F 君にもチームに参加してもらってます）
7: SDPA-S (基本はSDPA。Shur Complement 行列が疎になる場合に対応しているが、その変更が様々な場所に波及して、全体的に疎データのために書き直しになっている。現在非公開）
8: SDPA-R (SDPA の Robust 版。速度よりも精度や安定性を重視している。現在非公開）
9: SDPA-? (SDPA で等式制約をそのまま扱えるようにしている。現在非公開。名前も正式に決まっていない）
以下に今後の課題や計画について書いて見ます。
1: 上記のように様々なバージョンがあるので、ユーザーは混乱してしまうかもしれない。そのために二つの方法を考えている。一つ目は、前処理用のプログラムを作成する。入力問題を読んで、問題のサイズや疎性などから適切なソフトウェアを選択したり、適切なデータ構造に変換したりする。二つ目は Online Solver を提供して、ユーザーにいろいろ試してもらって適切なソフトウェアを選択してもらう。現在開発中の WebSDPA はこのためにも重要。この件ではお世話になっております。
2: SDP の解くための方法には、主双対内点法、双対内点法、ラグランジュ関数を用いた非線形最適化のアルゴリズムなどがあるが、それらの優劣、長所短所についての自己調査（他人の調査ではなく）。
3: SDPARA のグリッド化。SDPARA は並列化による効果によって、その性能を誇っているが、いずれ他のグループも追随してくるので、一歩先に GridMPI などを用いてグリッド化してしまおうと思う。
上記の 1, 2, 3 に関しては新しい人材も欲しいですね。
K 師匠だったと思いますが、SDP は 21世紀の線形計画問題(LP)と言ってました。私もかつての LP のように気軽に SDP を使ってと言ってます。単なる SDP でしょ、そんなのは軽いと言うわけです（少し大胆ですが）。
SDPA の開発チームも大変増えて（ざっと７人はいます：K, F, N, Y, F, K, F)、おそらく世界中全ての SDP 開発チームのなかで最大だと思います。本当にいろいろなバージョンがありますというか、出来てきました。こちらも参照してください。
1: SDPA (SDP を解くための主双対内点法のソフトウェア。もっとも基本的でノーマルなソフト。最も古く、格が最上。1995年より公開中）
2: SDPA-CG (Shur Complement 行列の線形方程式を解くために CG 法を用いている。良い条件の前処理方法が見つからなかったので、特殊な場合のみ有効。公開していない）
3: SDPA-C (入力問題の疎性の処理に行列補完による方法を用いている。公開中だが使用は SDPA-C の並列版 SDPARA-C をお勧めします)
4: SDPARA (SDPA のボトルネックの部分を MPI を用いて並列化したもの、SDPA と並ぶ主力ソフトウェア。公開中)
5: SDPARA-C (SDPA-C を並列化したもの。並列化思想は SDPARA とほぼ同じ。公開中。問題によっては全 SDPA の中で最速を誇る）
6: SDPA-M (SDPA に Matlab インターフェイスを付けたもの。当初の予定を裏切って意外とユーザーが多い。公開中。このために米国 V 大の F 君にもチームに参加してもらってます）
7: SDPA-S (基本はSDPA。Shur Complement 行列が疎になる場合に対応しているが、その変更が様々な場所に波及して、全体的に疎データのために書き直しになっている。現在非公開）
8: SDPA-R (SDPA の Robust 版。速度よりも精度や安定性を重視している。現在非公開）
9: SDPA-? (SDPA で等式制約をそのまま扱えるようにしている。現在非公開。名前も正式に決まっていない）
以下に今後の課題や計画について書いて見ます。
1: 上記のように様々なバージョンがあるので、ユーザーは混乱してしまうかもしれない。そのために二つの方法を考えている。一つ目は、前処理用のプログラムを作成する。入力問題を読んで、問題のサイズや疎性などから適切なソフトウェアを選択したり、適切なデータ構造に変換したりする。二つ目は Online Solver を提供して、ユーザーにいろいろ試してもらって適切なソフトウェアを選択してもらう。現在開発中の WebSDPA はこのためにも重要。この件ではお世話になっております。
2: SDP の解くための方法には、主双対内点法、双対内点法、ラグランジュ関数を用いた非線形最適化のアルゴリズムなどがあるが、それらの優劣、長所短所についての自己調査（他人の調査ではなく）。
3: SDPARA のグリッド化。SDPARA は並列化による効果によって、その性能を誇っているが、いずれ他のグループも追随してくるので、一歩先に GridMPI などを用いてグリッド化してしまおうと思う。
上記の 1, 2, 3 に関しては新しい人材も欲しいですね。
ブログ作成のためにいろいろな所を探したが、結局 goo に落ち着いた。
どこでも同じような感じだと思っていたが、某３文字の大手は使い勝手が
悪かった。ブログを始めたが使いにくいので、ほぼ４０分ぐらいで閉鎖した。
どこでも同じような感じだと思っていたが、某３文字の大手は使い勝手が
悪かった。ブログを始めたが使いにくいので、ほぼ４０分ぐらいで閉鎖した。
アクセス
トータル
