水循環モデルと農業生産モデルの相互比較
CREST成果としてのモデル(MANDALA計画)のありかたを考える
安形康／談国新／鼎信次郎 (東京大学生産技術研究所)

これまでの成果


水循環モデルと農業生産モデルの相互比較

望ましいモデルとは？

従来の世界水資源評価との比較
ニューハンプシャー大学（ヴォロスマーティ氏ら, "Science"掲載）

国連（シクロマノフ氏ら）
2000〜2001年に相次いで発表
 全世界グリッドデータ化．世界的にはじめての試み
 が，実測流量のある地域対象．
未来開拓・東大生産研グループ
気候データと水循環シミュレーションから世界中の河川流量を推定．
 水供給量に関しては，現状でベストの解水供給量 ：GSWP+TRIP
元ネタ：ISLSCP Initiative I Dataset
全陸地 1度グリッドの土壌植生気象データ
 87-88年．気象データは6時間おき
→GSWP（Global Soil Wetness Project）
ISLSCP-Iデータを使って，12種類の地表面水文モデルを動かす．
 データは喜連川研がアーカイブ
 1度グリッドで，1987-88年の10日ごと・1度グリッドの地表面水分状態がデータ化されている
→TRIP(Total Integrated Runoff Pathways)
デジタル河川網．現在では0.5度グリッド
 上記GSWP結果とTRIPを使って，全陸地の河川流量を推定
水需要量 ：WRIから何とか…
元ネタ：WRI Dataset
国別統計値．農業用水工業用水生活用水取水量
 5年おきにある．


元ネタ2：CIESIN人口（Center for International Earth Science Information Network）


2.5分人口データ

元ネタ3：Kassel大学灌漑面積
WRIの国別統計を元に，工業・生活用水は人口比例，農業用水は灌漑面積比例でグリッドに再配分する

水需要評価
水需要とそのper capita←水需要量

人口あたり水需要量→

水ストレス評価
必要な水／河川から取水可能な水←上流からの河川水が全て使える時

上流からの水を全く使えない時→

水需要量推定の改良：これまでは…
同じようなデータを使っている

国別統計(WRIなど)＋ごく少数のグリッドデータ(CIESIN人口など)

同じような単純な手法を使っている「灌漑量は灌漑面積に比例」 などプロセスを無視した仮定
 しかしデータの制約から，そうせざるを得なかった


国別統計の呪縛から逃れ，水需要プロセスをきちんと組み込んだ自立的な計算方法を使うことが必要．
最初は（取水量が最も多い）農業用水から

食糧生産モデルと水循環モデルの「握手」
食糧生産グループ(談)
灌漑取水
水量

データを介した握手へ

水循環グループ(安形・鼎)
利用可能な水の量

生産量
水危機
評価
経済／
食糧需要

食糧生産モデル

水循環モデル

共通データ

気象

土地利用

地形 人口 土壌 植生 経済 等等…

農業モデル「EPIC」 で灌漑水量を推定する
EPIC：農業生産に関するプロセスを網羅的に含んだ世界標準モデル
灌漑取水量の算定：EPICの応用

気象データ・穀物種類・土層データ等から…



土層の水分を最適に保つための水量を計算
 「最大有効灌漑水量」

各月で，実際に有効に使える水の量を計算
 「灌漑水量」

EPICによる灌漑水量推定
月ごと，全陸地0.1度グリッド値

年合計 灌漑水量EPICによる灌漑水量推定(2)←最大有効灌漑水量

最大マイナス実際→
赤いところは，水資源制約で食糧生産が落ちている

WRI灌漑水量とEPIC灌漑水量
WRI：これまで使用
国別統計灌漑水量値を，その国内で灌漑面積グリッドデータで面積配分


穀物種の地域差は無視

EPIC：今回使用
グリッドごとに自らのアルゴリズムで灌漑水量を推定
各地点の穀物種を自動的に判定
 国毎の食糧生産量はFAO統計値と合う事が確認済
農業取水量比較
EPICから推定した方が大きい
使われる位置が違う(米国など)↑EPICから

WRIデータから→WRI統計値との食い違い
EPIC＝5,631

WRI＝2,396（×109m3)

原因は？
EPICの過大評価
 使える水があってもそれが使われるとは限らない
EPICの「農地」は本当に農地か？

 灌漑方式の進化が正しく反映されているか？
WRIの過小評価
 国別統計値の信頼性：もっと水は抜かれている？


この取水量でこの食糧は本当に作れるのか？

真実の値はこの両者の間？
複数の方法の相互比較(「握手」のひとつ)により，正解の範囲を狭め，計算方法を改良し，真実を追い詰める水需要評価：WRI版とEPIC版
水需要量 per capita←WRI版

EPIC版→

水危機評価：WRI版とEPIC版
グリッド毎の農業プロセスを計算したEPIC版
国別統計と灌漑面積だけを使ったWRI版

位置も多少異なる．

食糧生産モデルと水循環モデルの「もっと握手」
食糧生産グループ
灌漑取水
水量

水循環グループ
次回の発表？

利用可能な水の量

生産量
経済／
食糧需要
さらにあとの課題

食糧生産モデル←今後の課題

水危機評価
水循環モデルモデルの「握手」を阻むもの
モデル間の開発思想の違い
内部変数か外部データかの食い違い
 どう克服？→適切なインタフェース設計と，モデルのモジュール化を並行して行なう必要 複数のモデルで，同じ値を内部計算している例多 複数のモデルで行われる同種の計算の抽出移植・コード読み解きが出来る人・時間CRESTの成果としてのモデル群「MANDALA」(仮称)のあり方とは？
モデル設計(モジュール)
1. 各サブモデルが通信しあいながら自らは自律的に行動する
分散モジュールモデル
2. 単体モデルを全てモノリシックに統合した巨大モデルといってもコーディング上はモジュール（クラス)化を行なう

モデル設計(データ構造)
1. 集中型（世界は一つ）
2. 分布型(すべてのグリッドにobject)
3. パーツ型（国や地域ごとに一つのobject)

モデルを「つなぐ」
キャッチボールと同じで，まずはone to oneから共通データ
モデルにとって必要な情報：
1.データの送受信方法
2.自分の「何」が相手の「何」に影響を与えるか

Whatだけ知っていればいい．Howの情報は不要で，相手にとにかく「投げる」or相手が「受け取れる」場所にデータを置く
農地モデル
最大灌漑

灌漑水量

流出モデル

ｔ＝t or t+Δｔ
ｔ＝ｔ

河川流量

データ：気象・地形・土壌・現存植生・土地利用・人口・経済…

データの送受信「オフライン」：ファイル渡し
決まった場所に，決まった形式の，メタデータ付のファイルをおき，お互いにそこを参照する
 データの「要求」方法を別途定める必要あり「オンライン」：socket, SOAPなどのネットワーク技術：要求−受信まで全てネットワーク技術

データ要求の構造は難しい

「要求ループ」の処理 ／ 当該データを計算するモデルがない場合
農地モデル
最大灌漑

灌漑水量

流出モデル

What if t＝t?
ｔ＝ｔ

河川流量

Solution1:超越者モデルの導入
全てのデータのインヴェントリを管理
各モデルの要求を処理
各モデルの結果を格納
各モデルは，この超越者モデルに対してだけ問合せをする（クエリを投げる） 各「パケット」を厳密に定義
超越者
データクエリ
サブモデル(どこのいつの何のデータがほしいか)

モデル

モデル

クエリキューアンサ

スケジューリング

計算クエリ
アンサ（データ)

データカタログ

既存モデルは対応できるのか全てをいきなりSOAP化（など）は現実的でないモデルのオフライン構造を守り？ながらクエリ方式を実現する方法;"File-Driven"「私書箱」(dir)超越者からのクエリ(ファイル)

サブモデル
監視・発見私書箱監視
ループコール

クエリ処理
アンサ（データ)

計算処理

SOAP／UDDI的に…
モデルでは，一つのデータの計算に他の値の計算も行なうのが普通．


一つ一つ順番にクエリを出すのは疑問
 （注：モデル自体に結果のキャッシュを持っていれば別）UDDI：どのホスト（モデル）がどんなサービス（計算）をしてくれるのかという「電話帳」
計算の始めに，「超越者」が，つながっている全モデルに「キミは何から何を計算するの」とレポートを要求 超越者モデルはそれをもとにスケジューリング
 計算途中でそのレポート内容が変わる場合には対応できない 第一世代としては妥当結局…
モデル(モデラーorユーザー)に要求されること：「何」と「何」と「何」と「何」と…から
 「何」と「何」と「何」と…を

計算するのかということの認識↑じつは意外と難しい．


モデル間の設計思想の違い・用語のズレ……
水循環ー食糧生産結合実験の期待される成果は，このノウハウの蓄積にあり！