「ぎょーむ日誌」目次に戻る
|
KuboWeb top に戻る
|
twilog
|
atom
ぎょーむ日誌 2001-09-18
苦情・お叱りは, たいへんお手数かけて恐縮ですが, 久保 (
kubo@ees.hokudai.ac.jp
) までお知らせください.
本日
(
kubolog20010918
) |
次の日
|
1 日前
|
7 日前
|
31 日前
|
365 日前
|
top
2001 年 09 月 18 日 (火)
0700 起床. 寝たのは 0200 すぎ. 眠い. 今晩はさっさと寝よう.
朝飯・弁当の準備. 炊飯準備わすれてた. 昨晩にかじったバゲット (にせ) があるのでそれで朝飯. コーヒー. シャワー.
0750 自宅発. 晴れ. 特急に乗って 0804 京急平和島発. 普通に乗り換えて 0830 京急上大岡発. なんか晴れてて暑い. 25 ℃は越えてるな. 0845 研究所着. 朝からばて.
ばててる暇も無いようなので, パラメーター調節を少しやってから, Abies PipeTree 集団シミュレイション. 年間最大生産力 pmax は 2.0 g/g/year だと 樹高成長 8cm ぐらい. pmax = 2.2 で 12cm, pmax = 2.5 で 15cm.
同所的で同齢ということになっている 観測プロット内の すさまじいばらつき具合 (60 年経過した場所でも個体間の樹高・直径にまだ 2 倍の差があり …… そもそも 20 年の時点で 100 倍だからなぁ) を説明するためには, こういったパラメーターに個体差がある, と考えねばならんような気がする. (後記: 以上はかなり
勘違い
…… 同齢集団ではなく, 年齢そろってない連中が同じ場所にはえていたのである!!)
個体間にパラメーターの差がありそうなもうひとつの 理由は (個体はことごとく均質であるとしてる) 現在の PipeTree たちの挙動である. こいつらの集団では, 競争に敗けつつある個体ほど高さ成長にはしる傾向がある. 個体内での資源ぶん取り競争と 頂芽優先みたいなモデリングの影響である.
つまり敗けつつある樹木個体は (他個体にいち早く接近する) 側枝がまず暗い環境におかれてしまう. そういう生産性の低い枝はリストラされてしまって, 一番明るい場所 ―― つまり個体の頂点などにいるような枝に資源が傾斜配分される. さらに枝次数が上がるごとに資源誘引係数が ダンピングされていくので PipeTree 用語でいうところの Vertical かつ Main である幹先端は そういう状況においてますます伸びてしまうのである.
側枝が刈られつつある PipeTree は (パイプモデル教の世界なので) 細い, そのわりには背が高い, となる. ところが観測データでは 背が高ければ太く, 背が低ければ細い, という関係があるように見える. このアロメトリというのも実態がよくわからんけど.
樹高と太さに正の相関, というのを出したければ PipeTree 内の資源配分系を 「そうなるように」いじるか, あるいは同化系のパラメーターが個体によって違う, とするしかないのではなかろーか. そして資源配分系はむやみに変更できないかもしれない. たとえば頂芽優先的なことをやめると, たちまちにして いかにもうそくさい形状の樹冠が形成されるのである. 何が針葉樹らしい樹冠なのか, 私にはいまいちわからんけど.
書き忘れていたけど, 書く末端における資源誘引能力は, 先述の係数かける「明るさ」の自乗である (これを規格化したもの). ここまで差をつけなくてもよいかも, とは思うんだけど …… これぐらいにしておかないと 「何でこんなところに葉っぱつけるんだ」 という結果になりがちである. 実際はどうなんだろうな. これまたさっぱりわからん.
時刻は 1020. まだ 30 個体シミュレイションが 27 年しか進んでないけど, 1 個体も死んでないな. 維持呼吸下げたためか, なかなか死にがたい Abies である. 死にかけの樹木たちが側方を捨てて「背伸び」に走るのは, 理にかなった逃避になっている. アタマひとつぶん他より高いので, 幹先端部では全力で資源獲得できるためである. こういう自助的な延命措置もあって なかなか死なない.
3m 四方に 30 個体もつめこむと全体に背が高くなってしまうな. pmax = 2.2 で 30 年目において 550-590cm か. ちょっと速い. 高さの幅は観測値というのと比べるとがちがちに狭い.
いつまでたっても, 言うところの競争排除というのが生じそうにないので (あるいは自己間引きという奇妙な類義語もときどき用いられる), 個体によって最大生産力 pmax が異なる, というのを設定できるようにコードを変更してみる.
これをうまくやればそれらしい計算結果は出てくるかもしれない. しかしあまりうまい改造ではない. というのも, こういう個体内部の違い, というのはデータから推定するのが困難なのである. 生物に個体差が無いとは誰も考えてないだろうけど, だからといって「これが個体差です」と 直接に観測・測定してみせるのは困難だ. モデリングではこういう要因はできるだけ取り扱わずに すませたいところなんだが …… 今回は緊急避難ということで.
1045 集団シミュレイション継続中. 40 年経過. まだ 1 個体も死なない. 場所が悪かったために (たぶん包囲されてるんだろう) 痛めつけられている個体はあいかわらず樹高成長に努力してるけど, 高齢化が進んだためにもはや「集団からアタマひとつぬけて」 という方針を維持できなくなっている. 生産に直接は寄与しない部分に奪われる資源が増大してるためである. さて, どうなるか.
コード書き直しもできた. 80 年シミュレイションも終った. 結局 1 個体も死ななかった. 最後は全個体が共倒れ寸前,といった状況である.
[そして誰も死ななかった]
領域の面積 9m
2
に 30 個体. ランダム分布. 80 年目の樹高約 920-950cm.
甲山さんとメイルやりとりして, また仕様変更. 維持呼吸は樹木の表面積に比例, か. パラメーター値の変換方法を手許の紙にごそごそと 書きながら検討してると, 昨日の気色悪い逆数式とやらの趣旨が理解できた. あれは, よくある「単位重量あたり」という考えでは 維持呼吸がうまく説明できないんで, けったいな逆数式とやらを持ち出して 表面積に変換してたわけだ. なーんだ.
むろん PipeTree では逆数式など使わず, 現象論的な「維持呼吸量は樹木の表面積に比例」 を直接的に用いる. 表面積はすべての PipeBundle に個別に計算させてから, 全部について足し合わせるわけだ.
さらに今ごろになって, 元データについて説明されている 甲山さん 1981 年論文を見直す …… げ, 調査区画ごとに age がつけられているんだけど, これって樹木の年齢とはまったく無関係だったのか. たとえば, 齢が 8 ということになっている St.03 の樹木齢分布をいつものごとく perl | sort | uniq の複合ワザで数えてみると ……
じつはこういう齢分布だったのか. くそう, 「林分の齢」というのとその中の樹木の齢を取り違えていた. どおりで個体の太さ・高さが むちゃくちゃにばらついてると思った.
えーい, どうしてくれよう …… と考えつつ昼飯. シミュレイター開発に入る前に 完全に掌握できるところまで元データを解析しとくんだった. 反省.
昼飯食ってからさっさとコード改造に着手する. 変更点は
非同化部の維持呼吸「量」は 枝・幹の表面積に比例.
年齢の異なる樹木の集団を扱えるようにする.
順番にやる. 予想としては 1. は結果に対して影響与えないだろう. 比例係数も unknown だし. 2. をいれることで「パラメーター値を変えて個体差を出す」 というアイデアは当分は棚上げだ. 齢がこれだけばらついているなら, パラメーター値が均質でも派手な競争排除が生じるだろう.
と着手しようとしたら, 甲山さんからメイルの三連打. 参考になる. 対応はたいへん.
メイル書きながら perl | sort | gnuplot で描いたグラフ. さてさて, 調査区内の初期ばらつきはなんか影響するんだろうか.
齢ばらつき版作ってみたんだが …… いまだに core 吐きエラー? gdb で解析してみたがこれは難物.
core 退治ぷろふぇっしゅなるの意地にかけても …… なる奮闘もむなしく一時撤退. 腹減った. 1900 研究所発. 普通に乗って 1910 京急杉田発. 快特に乗り換えて 1920 京急上大岡発. 普通に乗り換えて 1940 京急川崎発. 2000 帰宅.
晩飯後も core 吐きバグに挑む.
今回のは個体間競争でばたばたと Abies が死んでるような 状況でときどきうまく死んでくれない個体がいる, という問題なんだよね. 数値森林にわけいり うまく死ねない個体を選びだし, そうなった事情をあれこれと聞く.
つい先日いいかげんに作った死亡処理なんだよな, 問題あるのは. PipeTree を構成する部品はさまざまな理由で 死ぬわけだが, そのときに礼儀正しくも 「もうすぐ死にますんで, あとはよろしく」 なる通知を出す. この通知のまわりかたがいくつかあって …… そのうち一つがやられてるんだよね.
夕方からこの問題を考え続けてるので, 死亡通知の流れる経路が頭の中で把握できつつあるような …… しかしわからん. あっちをつつき, こっちを掘り返し …… 死亡処理そのものはどんどん手直しされるも, かんぢんのバグは消えず.
一休みして明日の米を虚心に研いでるときに 突如としてバグに気づいた. 末端における Foliage の赤字自滅 → PipeTerminal 通知届かず → Eye 見つからず, だ !! そうか, この経路が必要なのに入れてなかった.
改良してコンパイル. いままでバグが出た事例で実行. 毎年のように出現する個体たち. どんどん暗くなる林分. さてさて「くらっしゅたいむ」時刻 9 …… 26 番目の個体の計算 …… 無事に突破. やれやれ, 「最後」の難バグが片づいた.
何でそれが「最後」のバグなんだよう, と不審に思われるかもしれない. しかし今回の対けべっく作戦では シミュレイターの抜本的な改良は行わずに, 現時点の版をもって「勝負」するからである. いや, これで充分と考えてるわけでない. りすきーな改造やってる 時間が残されていないのである. そして現ヴァージョンのものは発表準備に求められる 機能はことごとく備えている. あとは小手先の修整だけで対応できるだろう.
で, こういうプログラムは改造さえやらなければ 難しいバグは出ないのである. まだ残存してる手ごわいバグ? うーん, もう潰しまくったと思うんだけど …… ともあれ, そいつらはあと一週間ほど表面化しなけれりゃ, それでいーや.
ということで, もう変な計算結果が出たって かまわず発表してやります, という自暴自棄宣言でもあるわけだが.
[今回はこれで勝負だ PipeTree]
よーやくにして「(とりあえず)最後」の難バグがとれた Abies PipeTree. 9m
2
の独房に閉じ込めた 20 年生. オレンジ色は死につつある葉群. 樹高 260cm, 基部直径約 7cm.
ばててるけど, アタマの中は 呪われバグ探策撃滅モードの終了処理中なので しばらく眠れそうにない. アドレナリンはもう出さなくていいっつーの …… 時刻は 2610.
けべっく出発まであと 8 日.
今日の食卓
朝 (0720): パン. シシトウ・タマネギ・ニンニク茎・ヒラタケの炒めもの.
昼 (1220): 弁当. 米 0.8 合. 朝と同じ.
晩 (2020): スパゲッティー. 朝と同じ.
本日
(
kubolog20010918
) |
次の日
|
1 日前
|
7 日前
|
31 日前
|
365 日前
|
top
KuboLog
|
KuboWeb