パイプカッター

自転車生活をしてると、たまにフォークコラムを切りたいとかシートポスト切りたいとか、そういう欲求が発生するわけで、しかし円形のパイプをきれいにノコギリで切るというのはなかなか難しい。 フォークコラムは精度が重要なのでちょっとアレだが、シートポストなんかは長すぎるなら適当に切っちまえばいいのだから、これくらいは自分で何とかしたい。

パイプカッター買った。安物で、840円とかだった。
自転車生活をしてると、たまにフォークコラムを切りたいとかシートポスト切りたいとか、そういう欲求が発生するわけで、しかし円形のパイプをきれいにノコギリで切るというのはなかなか難しい。
フォークコラムは精度が重要なのでちょっとアレだが、シートポストなんかは長すぎるなら適当に切っちまえばいいのだから、これくらいは自分で何とかしたい。なにしろ、いまの自転車はプロの手を一切借りずに組み上げてるからな。
で、パイプカッターというのはつまり、ローラーのついた万力みたいな仕掛けになっていて、パイプを挟んでぐるぐる回せるようになっているところに、これまた回転する円形の刃がついていて、ちょっとずつ締め込みながらパイプをぐるぐる回していけば、パイプを剪断することができる、というツールである。これは、ノコギリみたいに切りシロが必要にならないうえに、安物でも比較的よい精度でぐるぐる回していけば、切断面が曲がったりすることなくきれいに仕上がるという点で非常に優れている。ただし、剪断加工であるが故に多少の変形は免れないのであり、ぐるぐる回しているから変に歪むことはないものの、切断面の直径がじゃっかん膨らんだりする。これがフォークコラムを切るにはふさわしくない、という理由であり、逆に言うと適当にヤスリかなんかで削ってやれば済むシートポストの場合にはこれでいいってことだ。
家に余っていた、Tioga のアルミのシートポストはきれいに切れたので、シマノか日東あたりのシートポストを買ってきて、こいつで切って使おうと思う。ていうか、いまは普通のホリゾンタルなフレームに 350mm のシートポストがささってるんですよ。脚短いから 200mm もあれば充分なのに、あほですね。

買うより直した方がずっと安いし、なにより修理は楽しい。 で、パイプカッター買いにいった折に、撥水スプレーを500円くらいで売ってたので、吹いてみた。

別にいい傘を使っているわけではないのだが、祖父からもらった奴で、
昔のもので、けっこう丈夫にできており、なかなか壊れない。
まあ、一カ所ホネが折れたりしたが、そんなもんは直せばいいわけで。
買うより直した方がずっと安いし、なにより修理は楽しい。
で、パイプカッター買いにいった折に、撥水スプレーを500円くらいで売ってたので、吹いてみた。アクリル・シリコン系で、フッ素系ではないので、新品の傘みたく、雨水が玉になって転がる、というほどではないのだが、キレの部分に水がしみこまなくなり、振れば水が切れるので、折りたたんでカバンに放り込む場合には非常にいい感じだ。
傘のシャフトが伸びた状態でロックするための爪の引っかかり具合が悪いので、次はこれをなんとかしようと思う。

SQLite3

研究で、大量のデータをテーブルに保存する必要があり、しばらくは STL の multiset みたいなやつを、自分で memory conservative な実装に書き直してメモリ上に展開していたのだけれど、いよいよメモリの容量がしんどくなってきた。 具体的にどれくらいしんどいかというと、32bit な環境では到底ダメで、64bit な環境で 16GB メモリを積んでも、ぎりぎり足りるか足りないかな感じ。

研究で、大量のデータをテーブルに保存する必要があり、しばらくは STL の multiset みたいなやつを、自分で memory conservative な実装に書き直してメモリ上に展開していたのだけれど、いよいよメモリの容量がしんどくなってきた。具体的にどれくらいしんどいかというと、32bit な環境では到底ダメで、64bit な環境で 16GB メモリを積んでも、ぎりぎり足りるか足りないかな感じ。これからもっとデータセットを大きくしたいので、もうメモリじゃ無理だ。
まあ、そんなわけで、最初は小さいデータセットをディスク上に展開することを考えてみた。で、Key:Value な表がひとつあればそれだけで幸せなので、こういうので一番簡単そう、というかよく知っているのはBerkeley DB なのだが、こいつは全然ダメだった。後から考えると、もしかしたら index を付ける方法があるのかもしれないのだが、それがよくわからず、結局のところ検索がうんざりするほど遅くて、実用には耐えないという判断。Berkeley DB を採用した理由は、API が簡単、というのはもちろんなのだが、PostgreSQL だとか MySQL のような RDBMS のように、データの実体は DBMS が管理していてユーザが直接ファイルを消したり移動したりできない、という状況がイヤだったので。こういう場合、DBMS への充分なアクセス権がないユーザは table を作ることさえできないしね。
で、いろいろ調べていたら、SQLite というのがあることを思い出した。こいつは、Berkeley DB と同じく、任意のところにファイルを作ってそいつをデータベースの実体にすることができるし、ライブラリをリンクしてやれば自分のプログラムが DBMS になる、という形式の SQL engine だ。しかも、性能はそれなりに良いらしく、少なくともテーブルの規模がそこそこならば MySQL とあんまりかわんない、というベンチマークも Web に落ちていた。こりゃいけそうだ。しかも、最近の MacOS X の /usr/{include,lib} にはこいつが最初から入ってるんですよ!
というわけで、いまテスト中。ほぼ完全に SQL92 Compliant で、index も定義できるし、けっこういい感じだ。

Fumy

全日本で別府史之が勝った。

全日本で別府史之が勝った。圧勝。
Discovery Channel に、日本のナショナルチームのジャージを着た選手が入るんですよ。
すっげえぜ!
Team Vang の活躍も目覚ましいし、
欧州ロードレース界に対する強烈なアピールになりますね!

あうー

梅雨の間にガンガン仕事するので、梅雨が明けたら休みください、ボス。… 梅雨が明ける前にぶっ倒れそうですが。

峠へ行きたいぜ。
梅雨の間にガンガン仕事するので、梅雨が明けたら休みください、ボス。
… 梅雨が明ける前にぶっ倒れそうですが。

今日のインストール (2)

GTK が新しくなってた。 gtk-2.8.19vi configure%s/-ltiff/-ltiff37/%s/-ljpeg/-ljpeg62/./configure ; makeきっと libtiff とか libpng も新しくなってるんだよなあ。

GTK が新しくなってた。
gtk-2.8.19
vi configure
%s/-ltiff/-ltiff37/
%s/-ljpeg/-ljpeg62/
./configure ; make
きっと libtiff とか libpng も新しくなってるんだよなあ。そろそろやるか。

今日のコンパイル

Berkeley DB 入れた。 64bit 環境でも動かしたいので、こんな感じだ。

Berkeley DB 入れた。
64bit 環境でも動かしたいので、こんな感じだ。
% env CFLAGS=’-arch ppc -arch ppc64′ LDFLAGS=’-arch ppc -arch ppc64′ ../dist/configure –enable-cxx –prefix=/usr/local
% make
default だと –prefix=/usr/local/BerkeleyDB ほげほげ なので注意が必要な感じ。
まあ、バージョンアップの時に移行作業が必要になるような使い方(ていうか、普通はそうだ)をするなら、そっちのほうがいいのかも…

ANSS’06

[宇宙開発・宇宙科学における数値シミュレーションの利用]混相流・軸振動・燃焼・破壊などのモデリング・シミュレーション。 シミュレーションの信頼性はどうか?

JAXA の計算科学シンポジウム。
別に、biology を辞める、とかそういうわけではないんですが、
流体方面の方から共同研究のお話をいただいたので参加してみました。
CFD はぜんぜんやったことがないのですが・・・
[宇宙開発・宇宙科学における数値シミュレーションの利用]
– 構造解析
– 混相流
– ロバスト最適化
など。Robust な解を探すのはどこでも重要だな…
流体でもキャビテーションがあったりとか、液滴を含む燃焼系とか。
シミュレーションの信頼性はどうか?精度は?といったところが問題。
航空機体周りに関してはかなりいろいろ進んでいるが、宇宙ではそうもいかない。
流体以外のシミュレーション技術の innovation が必要。
エンジン解析・プルーム音響解析(衛星へのダメージなど)・プラズマ系解析(衛星の帯電など)、など。
宇宙では Euler ではだめで、粘性・剥離をちゃんと考えないとダメ。
直交格子だけで計算すると精度的にしんどい場合もあるので、物体近くでは補助格子を使うとか。
火星の大気密度は地球の 1/100 、音速は 2/3 。
速度をあげるとあっという間に遷音速になっちゃうので、揚力を稼ぐのはけっこう大変。
そんなシミュレーションもあるんだな。
[航空機開発のためのCFDの現状と課題]
A380 とか B787 とか、どんどん大きくなるのでとても大変そう。
大型機も小型機も開発競争。
最近の航空機の設計でいちばんしんどいのは遷音速 (transonic) な部分の計算が入ったこと。
いままでは要素設計をやっていたが、これからは全機設計する時代だぜ。
ツールはそろってきているが、精度はどうなのか?
macro な最適化はけっこう大変。勾配法は速いけど local minimum に落ちてしまいがち。GA 使ったりする人もいる。設計最適化をやる場合は、形状定義とかが難しい・・・人工生命を使ったデザイン最適化とか、できるかも!?
micro な最適化も重要。実験だと難しくて、CFD を使うことで幸せになれる可能性も。
機体がでっかいと、micro な最適化を全体に適用したときの効果は大きい。
欧州は Airbus を中心にして産官学の連携がうまくいっているっぽい。
[革新的計算科学技術への展望]
設計最適化で、いろんな要素を最適化する方法が必要(MDO: 多目的最適化?)。
SOM (自己組織化マップ) なんかを使ってやるわけですよ。
計測融合シミュレーション。
航空機で生データを測定して、晴天乱気流のシミュレーションとか。 
[Supercomputing History]
小柳先生。
日本製の supercomputer が top500 に占める割合がどんどん下がっている、と大変お嘆きでした。
中国 (Lenovo) とかも supercomputer を作る気らしいぞ。
日本も頑張らないとな。

Go! Koji!

福島康司がフランスのレースで優勝。
やったぜ!
なんか、こう、彼らが日本のロードレースを変えてくれる気がする。
あとは、僕ら日本のアマチュアが、彼に続く選手を送り出せるかどうか、だ。
ツール・ド・スイスでは我らがウルリッヒが優勝。
le Tour でも勝ってくれー。