水循环农业生产相互比较

水循環モデルと農業生産モデルの相互比較CREST成果としてのモデル(MANDALA計画)のありかたを考えるこれまでの成果水循環モデルと農業生産モデルの相互比較望ましいモデルとは？安形康／談国新／鼎信次郎(東京大学生産技術研究所)従来の世界水資源評価との比較ニューハンプシャー大学（ヴォロスマーティ氏ら,Science掲載）国連（シクロマノフ氏ら）2000～2001年に相次いで発表全世界グリッドデータ化．世界的にはじめての試みが，実測流量のある地域対象．未来開拓・東大生産研グループ気候データと水循環シミュレーションから世界中の河川流量を推定．水供給量に関しては，現状でベストの解水供給量：GSWP+TRIP元ネタ：ISLSCPInitiativeIDataset全陸地1度グリッドの土壌植生気象データ87-88年．気象データは6時間おき→GSWP（GlobalSoilWetnessProject）ISLSCP-Iデータを使って，12種類の地表面水文モデルを動かす．データは喜連川研がアーカイブ1度グリッドで，1987-88年の10日ごと・1度グリッドの地表面水分状態がデータ化されている→TRIP(TotalIntegratedRunoffPathways)デジタル河川網．現在では0.5度グリッド上記GSWP結果とTRIPを使って，全陸地の河川流量を推定水需要量：WRIから何とか…元ネタ：WRIDataset国別統計値．農業用水工業用水生活用水取水量5年おきにある．元ネタ2：CIESIN人口（CenterforInternationalEarthScienceInformationNetwork）2.5分人口データ元ネタ3：Kassel大学灌漑面積WRIの国別統計を元に，工業・生活用水は人口比例，農業用水は灌漑面積比例でグリッドに再配分する水需要評価水需要とそのpercapita人口あたり水需要量→←水需要量水ストレス評価必要な水／河川から取水可能な水上流からの水を全く使えない時→←上流からの河川水が全て使える時水需要量推定の改良：これまでは…同じようなデータを使っている国別統計(WRIなど)＋ごく少数のグリッドデータ(CIESIN人口など)同じような単純な手法を使っている「灌漑量は灌漑面積に比例」などプロセスを無視した仮定しかしデータの制約から，そうせざるを得なかった国別統計の呪縛から逃れ，水需要プロセスをきちんと組み込んだ自立的な計算方法を使うことが必要．最初は（取水量が最も多い）農業用水から食糧生産モデルと水循環モデルの「握手」食糧生産モデル経済／食糧需要気象利用可能な水の量水循環モデル灌漑取水水量水危機評価地形人口土壌等等…水循環グループ(安形・鼎)食糧生産グループ(談)土地利用植生データを介した握手へ生産量共通データ経済農業モデル「EPIC」で灌漑水量を推定するEPIC：農業生産に関するプロセスを網羅的に含んだ世界標準モデル灌漑取水量の算定：EPICの応用気象データ・穀物種類・土層データ等から…土層の水分を最適に保つための水量を計算「最大有効灌漑水量」各月で，実際に有効に使える水の量を計算「灌漑水量」EPICによる灌漑水量推定月ごと，全陸地0.1度グリッド値年合計灌漑水量EPICによる灌漑水量推定(2)←最大有効灌漑水量最大マイナス実際→赤いところは，水資源制約で食糧生産が落ちているWRI灌漑水量とEPIC灌漑水量WRI：これまで使用国別統計灌漑水量値を，その国内で灌漑面積グリッドデータで面積配分穀物種の地域差は無視EPIC：今回使用グリッドごとに自らのアルゴリズムで灌漑水量を推定各地点の穀物種を自動的に判定国毎の食糧生産量はFAO統計値と合う事が確認済農業取水量比較EPICから推定した方が大きい使われる位置が違う(米国など)↑EPICからWRIデータから→WRI統計値との食い違いEPIC＝5,631WRI＝2,396（×109m3)原因は？EPICの過大評価使える水があってもそれが使われるとは限らないEPICの「農地」は本当に農地か？灌漑方式の進化が正しく反映されているか？WRIの過小評価国別統計値の信頼性：もっと水は抜かれている？この取水量でこの食糧は本当に作れるのか？真実の値はこの両者の間？複数の方法の相互比較(「握手」のひとつ)により，正解の範囲を狭め，計算方法を改良し，真実を追い詰める水需要評価：WRI版とEPIC版←WRI版EPIC版→水需要量percapita水危機評価：WRI版とEPIC版グリッド毎の農業プロセスを計算したEPIC版国別統計と灌漑面積だけを使ったWRI版位置も多少異なる．食糧生産モデルと水循環モデルの「もっと握手」食糧生産モデル経済／食糧需要利用可能な水の量水循環モデル灌漑取水水量水危機評価水循環グループ食糧生産グループ次回の発表？生産量←今後の課題さらにあとの課題モデルの「握手」を阻むものモデル間の開発思想の違い内部変数か外部データかの食い違いどう克服？→適切なインタフェース設計と，モデルのモジュール化を並行して行なう必要複数のモデルで，同じ値を内部計算している例多複数のモデルで行われる同種の計算の抽出移植・コード読み解きが出来る人・時間CRESTの成果としてのモデル群「MANDALA」(仮称)のあり方とは？モデル設計(モジュール)1.各サブモデルが通信しあいながら自らは自律的に行動する分散モジュールモデル2.単体モデルを全てモノリシックに統合した巨大モデルといってもコーディング上はモジュール（クラス)化を行なうモデル設計(データ構造)1.集中型（世界は一つ）2.分布型(すべてのグリッドにobject)3.パーツ型（国や地域ごとに一つのobject)モデルを「つなぐ」キャッチボールと同じで，まずはonetooneから共通データモデルにとって必要な情報：1.データの送受信方法2.自分の「何」が相手の「何」に影響を与えるかWhatだけ知っていればいい．Howの情報は不要で，相手にとにかく「投げる」or相手が「受け取れる」場所にデータを置くデータ：気象・地形・土壌・現存植生・土地利用・人口・経済…河川流量最大灌漑灌漑水量流出モデル農地モデルｔ＝ｔｔ＝tort+Δｔデータの送受信「オフライン」：ファイル渡し決まった場所に，決まった形式の，メタデータ付のファイルをおき，お互いにそこを参照するデータの「要求」方法を別途定める必要あり「オンライン」：socket,SOAPなどのネットワーク技術：要求－受信まで全てネットワーク技術データ要求の構造は難しい「要求ループ」の処理／当該データを計算するモデルがない場合河川流量最大灌漑灌漑水量流出モデル農地モデルｔ＝ｔWhatift＝t?Solution1:超越者モデルの導入全てのデータのインヴェントリを管理各モデルの要求を処理各モデルの結果を格納各モデルは，この超越者モデルに対してだけ問合せをする（クエリを投げる）各「パケット」を厳密に定義データカタログモデル超越者サブモデルデータクエリ(どこのいつの何のデータがほしいか)クエリキューアンサ（データ)モデルスケジューリング計算クエリアンサ既存モデルは対応できるのか全てをいきなりSOAP化（など）は現実的でないモデルのオフライン構造を守り？ながらクエリ方式を実現する方法;File-Driven私書箱監視ループサブモデル超越者からのクエリ(ファイル)アンサ（データ)「私書箱」(dir)監視・発見クエリ処理コール計算処理SOAP／UDDI的に…モデルでは，一つのデータの計算に他の値の計算も行なうのが普通．一つ一つ順番にクエリを出すのは疑問（注：モデル自体に結果のキャッシュを持っていれば別）UDDI：どのホスト（モデル）がどんなサービス（計算）をしてくれるのかという「電話帳」計算の始めに，「超越者」が，つながっている全モデルに「キミは何から何を計算するの」とレポートを要求超越者モデルはそれをもとにスケジューリング計算途中でそのレポート内容が変わる場合には対応できない第一世代としては妥当結局…モデル(モデラーorユーザー)に要求されること：「何」と「何」と「何」と「何」と…から「何」と「何」と「何」と…を計算するのかということの認識↑じつは意外と難しい．モデル間の設計思想の違い・用語のズレ……水循環ー食糧生産結合実験の期待される成果は，このノウハウの蓄積にあり！