• N=100 で NITSOL がこける問題、解決。
  • 問題は、またもや config の設定 （else if すべき所が一ヶ所 if だけになっていた、というおバカなもの）。
• 以上で no-HI 版のテストは終了とする。

• ノートに戻って、定式化を確認。
  • ふむ、 right-hand side vector のみの変更で対応できる。
• しかるべく、実装。
  • できた。 straight chain の F の決め打ちで、しかも non periodic だけ。
  • ついでなので corrector step の初期と update の統合もしておく。 （詳しい理由は知らないけど、微妙に違うんだよな。 この違いについては、後でちょっと調べておこう。）
  • これまでのチェックで通ることを確認ののち、古い（非統合）コードは破棄。
• これで、一応 HI 化はできたはす。
  • 不十分な点がもう一つ、 connector から position を作るのに、 COM を手で与えている。
• テスト：
  • 既存のテストに flag_noHI を追加。 一通り走るようになった！！
  • と思っていたら、 何かの加減で check_fastSI_solve_cubic が文句を言うようになった。
    • 見ると、いろいろ下らない bug や、思い違いがあった。
    • それらを修正後も、まだどこかで nan になっている模様……。
• 今月はここまで。

• 自分のコードにやっとこさ間違いを発見。 正直に書くと、 x^y の計算で、結果を代入していなかった。 つまり

  x = pow (x, y);

  と書くべき所を

  pow (x, y);

  としただけで、のんびりしていた。 bug なんてこういうものだよね、 という教訓のために明記しておこう。
• その後、 GSL と速度比べしたら、あれれ倍近く遅いや。
• GSL のコードを見ると、きちんと戻り値で解の数を返しているので （これが欲しかったのだ。 しかも後で見たらきちんと document にも書かれているではないか…… 手を抜かずにきちんと読みましょう）、 GSL のルーチンをそのまま使うことにする。
• 一つ一つ bug を潰して行って、やっと６種類で妥当な結果を得る所まできた。 勝率１０割！！
  • FENE-Fraenkel では s を大きくとりすぎていて、 おかしい（精度が悪い）としばらく悩んだ。 論文に従って s=0.01 程度にしておく。

• これもなかなか骨が折れた。
  • ポイントは configuration を作る際、 FENE モデルでは bead distance を Q₀ よりも 小さく取らないといけないが、そこをしくじっていた。
• 速度を比較したところ、本当に高速 scheme がダントツだな （これを期待して頑張っていたわけだけど）。
  • N=3 だと 少なくとも３倍、全般的に５倍程度は出ている。
  • N=30 だと GSL が急に performance が悪くなる。 それでも NITSOL の３倍弱は出ている。
  • 調子にのって N=100 も見てみると、 いくつかの場合 NITSOL がこけるなぁ……。
• 6/30/2008: noHI のテスト、終了。

• 6/27/2008: さらに続き。

• 調べてみたら、３次方程式が正しく解けていない。
• 自分でコードを書いているのだが（6/24/2008）、そいつがうまく動いていない模様。参ったね。
• 結局、これで一日潰す。しかもまだ動いていない……。
• 帰宅後、 GSL を覗くとあったよ。 gsl_poly_solve_cubic. こいつは（当然）きちんと解けているな。

• ３勝３敗、勝率５割だ！（悪いな -- 内二つは線形だし。）
• 6/26/2008: 勝率５割なんて大嘘だった……。
• 6/27/2008: さらに続き。

• 以前一瞬やってる（9/21/2007）。 その時のテスト・コードを動くようにしておく。
• 1D は動いていて、 2D も組んではいる模様。動くのかな？

ボルツマンは「優美にすることは靴屋と仕立屋にまかしておけばいい」と言った。

• 私の記憶にあるのは maxwell が boltzmann の書いたものを評して言った 「彼の書くものは長すぎて困る」というようなもの（出典はなにだったっけなあ）。 これを見て「いかん、俺は boltzmann タイプだな」と思ったので覚えている。

では最後に自慢話をひとつ。
　ぼくは自分が科学にまったく携わってこなかった者としては、 いちはやくアインシュタインの相対性理論を理解できた 数少ない一人だったのではないかと思っている。 これは湯川秀樹博士とのちょっとした蜜月が支えになったからなのだが （このことについてはまた書くことにするが）、 明けても暮れても相対性理論に集中した濃厚な日々も役立っている。
　ずっとのちになって、当時、大阪大学理学部教授だった内山龍雄さんが 岩波新書に『相対性理論入門』（1978）を書くことになったとき、 内山さんから「どういうふうに書こうか悩んでいるんで、相談にのってよ」と言われ、 二人であれこれそのシナリオを練ったことがあるのだが、 そのとき内山さんは「君はどうしてそんなにおもしろく相対性理論のことが考えられるの？」 と聞かれた。正確ではないが、こんなふうに応えたのではないかとおもう。
　「アインシュタインがおもしろそうに考えたということばかりが気になってましたから」。

• いや本当に恐れ入るな、松岡さんには。 「いちはやく理解できた」ことにではなく、 「本物」な人の懐に飛び込む、その行動力なのか、人間的な魅力なのか、 そういうものについて。
• 4/17/2008: 本格的で本気な人に沢山会ってきた人としての松岡さん。
• 3/3/2008: 松岡さんのアンテナ（シェイクスピアのレコーダー）。

かつてぼくは「炭男」（すみおとこ）と称していたことがあるんだね。 「半巡通信」というたった８ページのパーソナルメディアを、最初は３００人に、 最後は４０００人に無料で送っていたころのことです。７年ほど続けたかな。 その「半巡通信」のなかで、「ぼくは炭男だ」と書いた。 その炭男が発火すると火元になる（笑）。

• 考えてみると、この日記が私にとっての「パーソナルメディア」なんだな、 「無料で送って」いる。しかし私には、届けたいと思う明確なターゲットが そもそも「３００人」もいないけれど。
• そういえば、 自分がやりたいことをやるメディアとしての「雑誌」というのは大塚英志をみて ふうんと思ったし（4/3/2003）、 「ベンチャー」は近藤淳也をみて ふうんと思ったし（9/5/2005）、 「（私）学校」は西郷隆盛をみて ふうんと思ったな（12/27/2006）。

• 作業場にて実装開始。
• まずは３次方程式の解から……。えっと、千里の道も一歩から、と。
• 6/26/2008: バグっている。

• とりあえず straight chain の決め打ち
  • また、である……後で一般化するのが、また大変なのは分かっているが……。
• あと、とりあえず noHI だけ。
• ただし force law は ILC 以外６種類、一通り組みました。
• 対応する非線形解法アプローチも GSL multiroot 版と NITSOL 版とも組んだ。

• 先週はじめた計算、予定通り終了（ってことは、７日）。
  • もう一本は、この調子だと倍ちょっとかかりそうだな。
• 結果は、ふむ、 d を大きくとりすぎていて面白くない （し、分布がきれいではない == 相空間を十分走り回っていない）。
• 計算の追加を流しておく。これも一週間の予定（１００％で）。

• Somasi et al (2002) は、いわゆる Werner spring,
• Hsieh et al (2003) は Cohen's approximation,
• Hsieh et al (2006) は FENE-Fraenkel を使っている。
• ILC 以外は、代数的に計算できる。

• 5/7/2007: 論文の印刷。
• 10/12/2007: 勉強中。
• 11/16/2007: 依然、勉強中。
• 11/29/2007: まだまだ、勉強中。

• なんというか、諦めの悪い性分だなあと思いつつ。
• 具体的に使ってる仕事を探してみる。 あんまりなかったけど、一つ見つけた。 ううむ、確かに、しち面倒くさいことをやっている（やる必要がある）みたい。

• うむ、確かに諦めの悪い性分だ。

• 第７の spring type を導入（既に６種類も実装している、ということ）。
• こいつは３つパラメータが必要なので、 struct bonds に手を入れる。
• guile parser も update.

• 論文には結果の式は出揃っているみたいだけど、 途中がすっとばしてあり、しかも何か難解。 彼の本は手に入らないし、困ったなあ……。
• 6/20/2008: そうだ、一般相対性理論を勉強してみよう！

• こいつら、どう実装するのか、結構悩ましいな。
• それに多分、 stiff な bead-spring がやっぱり正解みたいだな。

• 初見（11/5/2007）ではスルーしていた部分にある、お話の背景が分かってきた。
• ということで、またこいつを実装してみようかな。 （今回は、すでにパーツは全部そろっているはずなので、簡単だろう。）
• 6/18/2008: 進む前に、もうちょっと。

• 先週仕込んだ結果、もう一つも終了。 （ってことは７日か - 6/10/2008）
• 結果を解析。平衡に行っているかどうかが（いつもの）懸念。 前みたいに、現状ではまず、 下限に注目しておくことにするか。
• 追加計算を仕込んでおく。（予定では一本は１週間、もう一本はそれ以上。）
  • 6/24/2008: 予定通り、一本終了。 もう一本は、倍ちょっとかかりそう……。

• 幾つかの高速化のアイデアと、 取り扱いの改善案（SCM での設定項目を増やすという話）。

• 先週仕込んだ結果、一つが終了。 （ってことは６日か - 6/10/2008）
• 結果を解析。落ち着いたかなと思ったら、最後の最後にまた動き出している様子……。 endless だなあ。
• 現状では下限を見て、そういうものだ、という結論で置いておくのがいいのかな。
  • 6/17/2008: 似たように……。

• まずはノートにまとめを書く。
  • 式の上では問題なくできた（当たり前だけど）。
  • 一部詰めていない点は残っているが、とりあえず置いておく。 （例の gradient 項の話）
  • no-HI で曖昧にしていた点（polydispersity）も、 この一般化で全てかたが付く。
• 既存の no-HI 系とは独立に HI 系のコードを書き下ろす。
  • もちろん使えるパーツは使って、ということだが。
  • 計算手順（計算する部分の切り分け方）を少し変えたりする。
  • とりあえず書き上げた。
• チェック：
  • これがまた結構、手間取った。 まあ今回は no-HI と one-by-one で詰めていけるので、比較的楽ではあったが。
  • 今回も、結局は下らんことであった。 つまり（またしても）変数（vector）の入出力における上書きの手順の間違い （本当は、頭の中で「こう組んだ」という思い込みと、実際の実装が別であった）。 トホホである（なんて、誰も言わんな）。
• 今日は、とりあえず、目処が立った、というところまで。

• 6/8/2008: bead-rod の古典的な論文を読む。

• guile parser のテストコードを書く。テスト終了。
• constraints がきちんと満たされているかを確認。 こまかい bug が一通り落ち、機能するよになった。
• stokes3 で短い chain を走らせるが、おかしい。 一つ一つ押さえていって、 position の更新順序の間違い（上書き）を発見。お粗末。
  • 6/14/2008: 似たような間違い。

• 既に定式化されていたとはいえ、 6/9/2008に思い立って一週間で動くものができたので、 よしとしよう（定量的な検証は、まだ、これからだけど）。
• 6/8/2008: bead-rod の古典的な論文を読む。
• さて、勝負はこれからだ、と。 「急がば回れ」が正しかったことをきちんと証明するためにはね、奥さん。 （cf. 6/5/2008）
  • ちょっと無駄話。
  • 普通の研究者は、何か（その人にとって）新しいことをはじめるとき、 どうアプローチするんだろう？ 風見鶏のように人のことばかり気にしてフラフラしているのはみっともないが、 かと言って、人は人、自分は自分とまったく無視するのもバカだし、ということ。 あさっての方向に走っていないかを確認するためにも、 たまには人の振りを（意識的に）気にしてみようかな、と。
    • 9/29/2003: たまには人の振り見よう企画。
  • science ってのは、建前は、みんなが誰もまだやったことのない問題に 取り組んでいるわけだけど、各人の学習プロセスで、果たしてどこまで降りているのかな。 その深さが、実際にその人の発言の深さにつながるということは、 経験上、だいたい分かっているが（浅い人はやっぱり浅い、という意味）。
  • 理論は、まあ式を追うというプロセスで最低限、 自分の足で立てるところまで来れるとおもうが、 計算をやっている人は、普通、どうしているんだろうな、と。 例えば私の今回の「急がば回れ」は、理論で式の導出を追うごとく、 既存の手法を自分で実装することで「自分の足で立っている」と思えるところまできたが、 みんながみんなそうしているようには思われないので。
  • 理論でも、計算でも、（自分で降りることなく） テーブルの上に並んだ最新の成果をつまんで（花屋がブーケを作るが如く） というようなことをやると、まあ trend に乗ったそれらしいモノが一応できるのだろうが。 計算で言えば、どっかから既存のコードを取ってきて、理解せずに使う、というのかな、 よく分からんが。
  • 計算物理が理論と同様の、科学としての検証可能性を保証しようと思ったら、 コードの公開は避けられないと思うが（RYUON マニュアル、おくづけ）、 現状は、コードは個人（or 研究グループ）に所有されていて、 何か新しいことをやりたいと思ったときに、やっぱりちょっと手が出せないし、 それだけでなく、下手すると第三者による検証もできない、と。

• bead から connector への変換だけでよい。
• 実装は比較的 straightforward。 予定通り、すんなりとは動いてくれない（動かないことが予定通り、の意）。
• いつものようにゴニョゴニョして最後には動くところまで持ってくる。
• で、結局 tridiagonal scheme （6/10/2008）は排除 （straight のみにしか使えないので）。 今は libiter を使っている。

• 実はここ数日、頭の中に置いてモヤモヤと考えていた。 で初手は、既存のスキームに後付けで補正を噛ます、 という方向でいこうという気になっている。
• 初期値と非拘束な最終値の両方が必要なので、 上の階層で一括して、とはいかなかった。 今のところ、各 scheme に処理を追加しておく。

• 書き上げた。
• 途中、 BeadRod の初期化方法を変更。 こういうのは、実際に使ってみる局面にならないと、何が正しいのか分からないよな。
  • こういうのを人は「頭が悪い」と言うのだろうな、と。 そう言われたくない「頭の悪い」人は、そう言われないようにと、 どんどん何もしない人になっていくのだろうな、と。 だから、やっぱり川上弘美は正しいのだ、と。
• stokes3 にも反映させる。今日はここまで。 integrator と parser は未チェック。

• 軽く見返すと、いくつか trivial な間違いを見つけた。
• しかし、これだけですんなり動くわけがないのが、 debug の楽しいところ （半分本音 -- サマリー：デバッグ）。

• ノートのまとめで、基本的な構造はクリアーになってきた。 原理的な困難はなさそう、ということ。
• 文献を調べてみると、しかし closed link な時に効率が悪くなるとかで、 いろいろと亜種が開発されているみたい（全部 MD の話）。

• wikipedia にあった Thomas algorithm というのを実装しておく。
• ちなみに numerical recipes には tridag というルーチンが、 GSL には tridiag というルーチンがある。 上の Thomas algorithm との関係は調べてない。
• 6/12/2008: 一般化により、結局、不採用。

• うまく動かず、ああでもない、こおでもない、とテストコードを書きまくる。 最終的に動く所まできたが、オチはメモリ確保でのサイズ間違い……。 まあこういうものだ。
• これで Lagrange multiplier を求めるところまで完成。 非線形方程式の解法には（今のところ） Liu (1989) のものと NITSOL。

• 延長してた計算が終了。解析してみると、さらに一段、緩和している模様。 つまり時間が全然足りていなかったのか。
• 別の計算を追加（d を振る、 N を振る）。
• 6/16/2008: N=157, 50000 steps が１００％で回して６日。
• 6/17/2008: N=200, 50000 steps が１００％で回して７日。

• test/check-bd-imp-nitsol.c をしかるべく update. 結果は確認した。

• GSL vs NITSOL で速度の比較。非周期の N=20 の場合で４倍から７倍くらいでている。 N が大きいともっと開くかな？
• 今回の構造変更による performance up は、しかし見られなかった。残念。

• 6/13/2008: さて、回って来ました。

• 結果の回収。
• 解析。 transient を除き、初期配置より random number の方が重要なんだな。
• こういう当たり前なことばかりで、自分のアホさを目の当たりにする日々だが、 日々賢くなっているのだと思うことにしよう。

• Newton-GMRES に関して以前調べたとき （11/23/2007）に見つけた NITSOL という library を使ってみようという話。
• NITSOL の reference は以下のとおり：
  M. Pernice and H.F. Walker, SIAM J.Sci.Comput. (1998) 19, pp.302-318:
  "NITSOL: A Newton Iterative Solver for Nonlinear Systems"
  (http://www.siam.org/journals/sisc/19-1/30384.html)

• 以前もはまって、解決したような気がしていたが、 その時の記述などが見当たらないので、また１から調べ直した。
• ポイントを「FORTRAN のライブラリを C から使う事例の１つとして」にまとめておく。

• まだ top level （例えば stokes3 の level）から 使えるようにはなっていない。

• 既存の結果を整理
• 足りない部分を（再）計算させるための準備。 新 stokes3 （正しく continue ができる）でやり直したいということもある。

• 解析。統計平均をとらなければいけないな。
• 既存の論文を見て extensional flow もやることにする。
• 毎度のこと、どうパラメータを与えたらいいか迷うので、 今度こそきちんと documentation しておく(RYUON-manual)。
• shear をベースに planar を一通り（20個）作り bue9 に回して計算開始。 が、しばらくすると悲鳴を上げている。
• 見てみると bond が伸びすぎ。 よく考えてみたら、 dWLC は単なる Hookean なので、当たり前だな……。
• モデルにまた手を入れなければならないか。
• 6/5/2008: 勉強、開始。
• 6/12/2008: できたてほやほやの bead-rod でテスト、予定通り（ダメだった）。

• まず過去の結果を確認。
• いろいろとパラメータを振ってみるが、それぞれ停止してしまうな。
• 対策をいろいろと思案中。

umass0: PINGTEC Flash Disk, rev 2.00/1.00, addr 2
da0 at umass-sim0 bus 0 target 0 lun 0
da0:  Removable Direct Access SCSI-2 device 
da0: 40.000MB/s transfers
da0: 497MB (1019392 512 byte sectors: 64H 32S/T 497C)
tpr60# mount -t msdos /dev/da0s1 /mnt
lstpr60# ls /mnt
tpr60# df
Filesystem  1K-blocks     Used   Avail Capacity  Mounted on
/dev/da0s1     509424       16  509408     0%    /mnt
   

• 6/2/2008: 月刊レポート、６月号。