継続時間、再現期間と崩壊

2011年、台風12号による奈良県の深層崩壊では、”雨”についていくつかの指摘がありました。

その中で、2軸指標（長期雨量、短期雨量、土壌雨量指数などの組み合わせ）を使うという動きがあります。「技術者に必要な斜面崩壊の知識」にも簡単ですが掲載されていました。p215のグラフです。

それをもっとわかりやすくしたのが、次ページの降雨継続時間と再現期間での議論。これは面白いですね。

今年、初めて自分で手を動かして確率降水量を計算した際に、継続時間の区切りなどで引っかかったことがあります。この本では、それを意識することなく、継続時間毎に再現期間を計算しプロットしてありました。これにより、一連の雨の中で、どの継続時間がもっとも斜面にとって不慣れな雨だったかを視覚的にわかるように工夫されています。砂防分野ではスタンダードな手法なのでしょうか？

3章では確率降水量の基礎、再現期間と表層崩壊の話がまとめられています。このように、継続時間毎の再現機関を比較できると、どの継続時間の雨が斜面崩壊に起因したかを推定しやすくなります。当然、概略の域を超えませんが、傾向をつかむには良い手法だと思います。また、これらが土研さんが提供しているEXCELシートで計算できることも紹介されています。
http://www.pwri.go.jp/jpn/seika/amedas/top.htm

実際に触ってみましたが、非常に手軽ですね。アメダスに限定されますが、データを集めて期間毎に整理する必要がありません。国土技術センターさんの水文統計ユーティティとあわせて持っておけば、多くの場合、事足りるでしょう。

台風12号の深層崩壊では、72時間の再現期間が約200年のようです。その前に、48時間が150年ですので、雨量だけではどのあたりで崩壊したかが分かりません（振動センサーなど、他の観測結果で分かっていますが）。しかし、傾向として、短期より長期の雨量が崩壊に対し危険ということはすぐにわかります。すばらしい。

一方、誘因としての再現期間200年では、斜面が安定していたと考えられる数千年（数千年の根拠は書かれていません）で壊れていないのが説明できないとも。従って、クリープなどの素因の変化があるはずと展開されています。ま、この辺は地質屋さんが根拠を持ってこないといけませんね。

古いデータを使われている箇所もありますので、この手法自体、昔からあるのでしょう（私が知らなかっただけです）。もう少し、読み進めましょう。

斜面の動水勾配

大掃除も終わり、朝から家でゴロゴロ。
振り返ってみると、これだけゆっくりしたのは、この一年でも久々です。年末ですね。

冬休み用に2冊本を買っていました。そのうち、1冊目を読みはじめました。

飯田智之「技術者に必要な斜面崩壊の知識」

引っかかったところが1か所。p142の動水勾配について。
いえ、私の基礎知識がなかったわけなのですが、最初はそれに気が付きませんでした。

非常に基礎的かつ単純な話です。
斜面で基盤岩に沿った流れがある場合、その動水勾配をsinθで表現されています。理由は分かりますが、tanθでは間違いなの？と思いつつ調べてみますと、やはりsinθでないといけないようです。こういった問題は、学生のころに習うようですね。以下は新潟大学の講義資料です。
http://geotech.eng.niigata-u.ac.jp/lecture/enshu12/ans121107.pdf

ΔLを水平距離と考え，動水勾配を tan 20°とした間違いが多く，正答は7名のみでした。
この問題では，流線がすべて斜面と平行になっています。動水勾配を求める際の透水距離ΔLは流線に沿った長さなので，ここでは水平距離ではなく斜面長になります。
したがって，動水勾配は浸潤面（斜面）勾配のtanではなくsinの値になります。
なお，動水勾配が正しいが，透水断面積を 2.8 m2としていた解答も目に付きました。

見事に動水勾配を間違え、断面積にcosをかけるのを間違えました。情けないですが、実力です。独学ですと、こういった基礎力がぽっかり抜けていることがあるんですよね。自覚はしているのですが、なかなか見つけられません。今回は良い機会でした。

もう少し読み進めましょう。

少し早い仕事納め

今年の仕事納めは例年より早く、26日でした。
その後はメールでのやり取りが続き、メールの来なくなった今日が本当の仕事納め。現場で締めなかったのでやや拍子抜けしていますが、ま、こういう”危険”のない年末もたまには良いでしょう。

今年もいろいろ経験させてもらいました。
前半は現場とシミュレーションが半々、夏から秋にかけて現場が続き、最後にシミュレーションといった、変則的な年でした。

中期的な目標「多くの現場で経験をつむ」に対しては、そこそこの年でした。もっと多くの現場を経験しないとダメですが、なかなか携わることのない分野、スケールの現場にかかわることができました。個人的に良い経験だったと思います。
また、意図せずシミュレーションの種類や幅も増えました。移流分散や土砂移動のシミュレーションコードを改良し、満足いくレベルで実施可能になったのは今年の収穫でしょう。

短期目標としていた技術士試験はダメでしたね。来年も同じ目標に設定します。ただ、選択問題減に対して対処する方法はわかるのですが、それに対するモチベーションが上がっていません。最初は無理に手を動かして様子を見てみましょう。


振り返ってみると、人との縁で、思わぬチームに混ぜていただいたり、声をかけていただいたり。逆にギクシャクしたり。営業の方のように、うまく対応できるスキルがあれば良いのですが、嘆いていても仕方ありません。めげずに来年も頑張りましょう。

libfcoremdd.dll が見つからなかったため、このアプリケーションを開始できませんでした。

後輩から、以下の報告がありました。

「”アプリケーションを正しく起動できませんでした(0xc000007b)。”というエラーが出ます。」

私がコンパイルした exe で計算しようとし、このエラーが出た模様です。
似たようなことがあったなぁと思いつつ、このブログを検索すると、過去に同じエラーを解決していました。
http://phreeqc.blogspot.jp/2012/08/0xc000007b.html

しかし、今回は同じように Redistributable Libraries x64 をいれてもらっても、解決しませんでした。私の使用しているPCより新しい XEON が入っているので、そのせいか？と思いつつ、別の PC で試してもらうと、今度は別のエラー。

”libfcoremdd.dll が見つからなかったため、このアプリケーションを開始できませんでした。”


意味が分からずいろいろ調べ、やっと原因特定。
32bitでコンパイルしていました。それが x64 の dll を見に行っていたため、0xc000007b のエラーが出たわけです。
しかもデバッグ版をわたしていました。libfcoremdd.dll が出たところですぐに気づくべきでしたね。まだまだです。

すまない、後輩君。来年は、もっと頑張ります。

技術者の階段

御飯を食べながら録画していたTVを聞いていると、おおぉ、というセリフが。

リーガルハイ2で伊東四朗さん（被告側）が言われたセリフ。

そもそも才能なんてものはな、自分で掘り起こして見つけるものなんだ。
俺だって天才なんかじゃない。
誰よりも必死で働き、階段を１つ１つ、踏みしめてきただけだ。
振り向いたら、誰もついてきてない。
怠けた連中がふもとでこうつぶやく。
「あいつは天才だから」
冗談じゃない！

正論です。
が、サラリーマン技術者は言えないセリフです。基準はあくまで努力している技術者と、していない方の平均、あるいは上司の技術レベルや価値観です。

先日の忘年会で、後輩の大残業、ストレス太りの話が出ました。「上司が仕事をしないので、仕方なく上司の仕事をやっている」と嘆いていたのを常に聞いていましたし、仲間内ではその上司が仕事をしないことで有名でした。実際、昨年度は私の1/10以下の生産でしたので、十分予想できたことです。しかも、太りだしたことを言い出したのが仕事を後輩に頼んでいるその上司自信。後輩は何も言えず。
で、思わず、その上司に「もう少し仕事がんばってもらえたら、」と言ったら、激高されました。コンプレックス ＆ NG ワードだったのでしょうか。プライドを大きく傷つけてしまったようです。その後はコンコンと、自分は頑張っていることを主張されていました。謝ったのですが、それでも怒り心頭のようでした。別の上司や後輩はその上司より仕事を多く抱えていたのですが、もうそれ以上話すのはやめました。そういえば、昨年度も別の方に突っ込まれて、憤慨されていたようです。その位置における、それなりの言い分はあるのでしょう。

将来、他の方が階段のどの位置にいて、自分がどこにいるということを正しく理解するとともに、そこで生まれた差が何だったのかを判断し、努力し続けることが、技術者として必要だなあと感じたセリフと出来事でした。


もう一つ。原告側のセリフ。

すぐに追い抜いてやる、王様の椅子は俺がもらう。
あんたのより遙かにどデカいピラミッド作ってやるよ！

コチラはセリフ自体に別に共感したわけではありません。ピラミッドというキーワードに引っかかりました。解釈は異なるかもしれませんが、はるかにでかいピラミッドを作ろうとすると、基礎の幅を大きくする必要があるなあと、いまさらですが感じました。
地質屋さんは地質だけをやっていてプロになれるわけではありません。数学・物理・化学の基礎力、工学など他分野の知識や表現技術、あとは現場での経験を大事に、幅広く身に着ける必要があります。基礎を固め広げ続けることと、コア技術を伸ばすこと、両者が技術者には必要なのでしょう。

良い気分転換になりました。

========================================================
2013/12/29追記
会社に行くと、激怒した上司とは別の上司が出社されていました。明日も現場へ行くとのこと。私もまだまだ努力が足りません。

2013/12/31追記
ここまではひどくないですが、訳アリ感含めて似ていますね。ヨイショしとけばいいんでしょうけど。
http://detail.chiebukuro.yahoo.co.jp/qa/question_detail/q12106710507

Autodesk Geotechnical Module

地質を3次元で可視化する場合、その根拠となるボーリングも同時に表示します。

表現手法は様々ですが、個人的には MVS のように、シリンダーに球がつく表現法が好きです。球は濃度、N値、透水係数など目的によって変えますが、基本的にはスカラーの表現です。

GEORAMA のような簡易柱状図表示は、見る方向が限定されますし、細かいN値などが読めなくなるので、あまり好きではありません。
そのため、今回、MVSを使わずに infraworks へデータを持っていくには、どのような形にすれば見栄えがよいか？と考えていました。

思い付いたのが Geotechnical Module。以前、GEORAMAの洗礼が嫌になり、一度触ってみたことがあるのですが、使用法がよくわからなかったので放り投げていました。
今回、ヘルプを読んでみますと、そのコンセプトは GEORAMA と同じでした。ボーリングから地層のサーフェス作成、およびそれらのデータ管理といった内容です。操作法は動画でも詳しく説明されています。
http://kbs.keynetix.com/category/term/488/488

無償ですので、機能は GEORAMA に勝てません。ボーリングの地層境界を直線で結んでTINを作るといった簡易的な面の作成はできますが、複雑な形状は手間がかかりそうです。が、柱状図は地質による色分けシリンダーになっています。これがSolidであれば問題なく infraworks に移行できそうです。

これを確認しようと、csv を読み込むまで実施しましたが、そこでやめました。データサーバーとライセンスマネージャーを別途インストールする必要があったのです（最後まで ヘルプを読んでからやればよかったのですが）。

とりあえず、今日はここまで。別の方法がなければ続きを行いましょう。

==========================================================
2013.12.28追記
結局、MVS でボーリングを表示してしまいました。
来年、Infraworks を触る場合には、MVS から CAD データに書き出しましょう。

地質の可視化

先週より、シミュレーションコードの改良と、3次元可視化の作業を行っています。

コードは簡潔で分かりやすい。計算が軽いのも手伝い、私のような素人でも非常に読みやすく、簡単に改良できました。こういったコードをかけるようになりたいですね。

可視化のほうはイマイチ。先のシミュレーションで使用した3次元地質モデルを甘めに、さらに広域で作成しています。が、面倒。しかも one off （これが気に入らない）。
2次利用とはいえ、可視化だけのためにモデルを作成するのは初めてです。今までは、計算という目的や、正しい2次元モデルを、3次元を利用して作るといった目的がありました。今回は見せるためとはいえ、ただ作るためだけに作るといった感があります。興味はそれほどありません。
CG専門の方が作成されたら良いと思うのですが、調査結果のない箇所も含めた地下のモデル化というのは、やはり地質屋でないと難しいようです。逆に言えば、地質屋がこういった見せる努力を行ってこなかったので、一般の方も見える部分だけに意識が向き、見えない地下に意識が向かなかないのかもしれません。

広域のモデル化は重たいですね。空中写真を読み込むだけでも時間がかかります。
本来、こういった作業はCADではなく、可視化に特化したツールを使わないといけないのでしょう。地形の可視化＋地質表示だけなら、ツールは多くあります（私が使えるのは限られていますが）。
エンドユーザーレベルでもいくつかありますよね。例えば、Google Earth。精度は粗いのですが、携帯端末でも高速で動きます。ただ、写真は被災後、DEMは被災前なんてことがほとんどですので、被災地などの可視化といった目的には不向きです。ま、それが目的で作られているわけではないので贅沢は言えません。

ArcGIS で可視化が可能だろうと思い、モデル（dwg）を読んでみましたが、ソリッドは表示できませんでした。shp か何か、読める形にする必要があるのでしょう。
ん？取り込んでしまえば、 MODFLOW に持って行って、結果を MVS で可視化するなんてことも可能では？試してみる価値はありそうですね。

GEORAMA ユーザー

構造物を3次元ソリッドで作成していただこうと、他分野の方と話をしていました。

席に来られるなりPCの画面をのぞかれ、「Civil3D ですか」と。
グラボ、CPU の名称を話しても通じました。ケースも珍しそうに見られていました。GEORAMA も御存知でした。話を聞くと、Civil3D や InfraWorks をよく使用されているそうで、ユーザー会にも積極的に参加されているようでした。

その方のお話ですと、GEORAMAユーザーはレアとのこと。
ま、そうでしょう。BIMやCIMなど、設計者による3次元化は始まっています。が、上物が主体です。地質屋さんががんばって3次元化を進めているといった話も聞きませんし、必要だという設計者の声も聞きません。

ただ、GEORAMAも、それしかないので使っているだけですし、おすすめできるソフトではありません（先日もエラーで立ち上がりすらしませんでした）。
ですが、3次元で地質分布を組み立てていく方が、間違いが少なくて済みます。断面毎の整合性や分布のなめらかさをPCにチェックさせた方が楽ですし、自分のミスに気づきやすくなります。とにかく、手を動かさないと気付かないことだと思います。

今週は、大手さんが調査された結果を使って、シミュレーション用の3次元地質モデルを作成していました。ですが、3次元で地質を組み立てている = 他社の地質屋さんのミスを手直ししている、といったような状況でした。横断で断層のずれを考慮しているが縦断で断層が表示されていない and 断面のズレが考慮されていない、断面交差位置で崩土の厚さが違う、平面では1つのすべりブロックであるが、断面では途中から段差が生じるなど。それ以外にも基本的なこととして、ボーリングの位置が読み込んだXMLと平面で違う、平面に座標を持たせていない＋トンボがない=大体でしかプロットできない、等々。気付かれていないのでしょうね。


Civil3D2013 ＋ GEORAMA2013 （いまだにGEORAMAの2014が出ていません。どうなっているのでしょう、CTCさん）でモデルを作った後の可視化については MVS を考えていたのですが、その方曰く、「InfraWorks のほうがきれいかも」。
データを移す手間はほとんどないそうですので、手を付けてみますか。

深層崩壊と隆起量

先日、「深層崩壊」を見てきました。

といっても、崩壊の発生は数年前であり、対策は進んでいます。
今回は崩壊面の位置と状況を把握することがメインでした。LPだけでも読めるのですが、やはり、現場を見ると情報量・解釈のしやすさが違います。

７か所ほど回ったのですが、どこも一様ではありませんでした。流れ盤である箇所、受け盤である箇所、１回で落ちている箇所、２回以上の箇所、砂岩主体の箇所、頁岩が多い箇所、岩盤崩壊がメインの箇所、表層の土砂崩壊も多く含まれている箇所、天然ダムの有無など様々です。

ただ、共通しているのが地形。
山の形状は隆起量の大きい地域と似ていましたので、ここもそうなんだろうなあと想像しながら歩いていました。
帰ってから調べてみると、やはりそのようでした。隆起量の大きな地域は、まさに今、山が高くなろうとしていると同時に、不安定になった箇所は削られ険しくなっている地域と言えます。
国交省さんの発表資料でも、深層崩壊と隆起量の関係をまとめられていました。
平成24年度 国土技術政策総合研究所講演会「深層崩壊～その実態と対応～」
http://www.nilim.go.jp/lab/bbg/kouenkai/kouenkai2012/pdf/121204_6.pdf

「深層崩壊」という用語はよく使用されていますが、いまだにその定義はあいまいなようです。崩壊土砂量で定義していることもあるようです。砂防学会によれば「山地および丘陵地の斜面の一部が表土層（風化の進んだ層）のみならずその下の基盤を含んで崩壊する現象」だそうです。
http://www.jsece.or.jp/news/2012/teigen20120402.pdf
いずれも、規模の大きな崩壊や地すべりを指すことが多いようです。


移動中に、車道からとった写真です。三角形のところに,山中の天然ダムが見えます。大きいですよね。

Phast４windows

PHAST の最新版を DL しようと、USGS の HP をのぞいてみました。
http://wwwbrr.cr.usgs.gov/projects/GWC_coupled/phast/

実際に使用するのは久しぶりでしたが、気になるので時々のぞいていました。
64bit 版あり、GUIありと、定期的に更新されています。

で、以前から気になっていた「 Phast４windows 」というプレを DL。
解凍してみると、なんと WPhast の最新版でした。WPhastは参考書についていたプレですが、使い勝手がよく、気に入っていました。ですが、最新版を DL する箇所が分からず、ずっと 2008年の Ver.0.6.1 を使用していました。

使ってみると、WPhast とほぼ同じインターフェース。非常に簡単です。浸透流と PHREEQC を御存知の方であれば、すぐに使えると思います。

Arc の shp も読めるんですね。shpが読めるなら、地層のモデル化もできそうですね。

唯一、 parallel の計算だけは動きませんでした。parallel は浸透流と反応を平行で計算するという意味でしょうか？多コアでしょうか？これはマニュを読まないとダメでしょうね

ポストは Model_Viewer。これも変わっていません。新規作成し、h5を取り込むだけ。
http://phreeqc.blogspot.jp/2010/10/as.html＜こんな感じです。



で、肝心のPRBsの結果はというと、イマイチ。
うーん、仕方ないですね。

透過反応壁とPHREEQC その2

結果が微妙に異なるのは、使用していた熱力学データベースが文献と異なっていたようです。


WATEQ4f で計算していたのですが、文献は PHREEQC でした。扱っている鉱物の数が倍半分ですので、結果も異なったのでしょう。ま、傾向は同じですし、どちらが正解に近いかは、試験室でないとわかりません（局所平衡を仮定し、EQUILIBRIUM_PHASES を使用した Test Run であって、地下水の流れを再現しているわけではありません）。

ZVI は PHASES で Fe を分解し、logK、enthalpy を与えています。ま、その値が分からずに今まで何もしなかったのですが。手元にある参考書には logK しか載っていなかったので、温度変化が扱えなかったんですよね。

とにかく、PHREEQC で再現できたのは収穫です。input ファイルの組み方が確認できましたので、次は PHAST で透過させてみましょうか。

透過反応壁とPHREEQC

以前より、ZVI を用いた PRBｓ の計算をしたかったのですが、情報が少なく、そのままにしていました。

先日より、また気になりだして資料を探していました。

今回、一番に引っかかったのは Amazon。洋書でした。
「なか見!」で本の中を見ましたが、モデリングの詳細は書かれていませんでした。買う必要はないと思い、そこの引用文献だけ検索してみました。（便利な時代になりました）。
引用文献は PDF で入手できました。古い米空軍の PRBs に関する資料です。

これ、当たりでしたね。PHREEQC による簡単な計算結果が載っています。
ただ、肝心な ZVI のモデル化が抜けており、掲載されているinputファイルそのままでは動きません。たぶんこのように組んだはずだと、文献を読みながら作成。で、計算！


結果を見ますと、傾向は合っているのですが、数値が微妙に合いません。

続きは後日。

スタックサイズの変更

並列化済みの Dtransu を動かす場合、スレッド数やスタックサイズは、batファイル内で指定していました。

後輩から、それをソース内で固定できないか？といった問い合わせがありました。
ソース内で固定したことはないのですが、当然可能だろうと触ってみたところ、うまくできません。力不足です。

調べてみると、スレッド数の指定はすぐに引っかかりました。Win7 + Fortran では以下の通り。

call OMP_SET_NUM_THREADS(スレッド数)


しかし、スタックサイズの指定が分かりません。オプションの中を見てもわからなかったので、その日は解決できず。


後日、調べてみましたが、結局明示する方法はわからず。最終的に、Win7側で環境変数を固定することにしました。

OMP_STACKSIZE　を追加すればOKです。スタックサイズはそれほど変更することがないので、固定しておいても問題ないですね。画像では、OMP_NUM_THREADSも追加していますが、ソース内で指定する場合は不要です。

しかし、これらを解決するのに、3夜かかりました。
プロがそばに欲しいですね。

玉石径は3倍？

今日、突然電話がかかってきました。

「玉石の径を推定する場合、ボーリングで確認した長さを3倍するが、これ、何かに書かれていないか？」

前からよく聞かれます。が、使わないので忘れます。せっかくなので、書き残しておきましょう。


玉石径3倍についての記載は、基準類には書かれていません。調べてみましたが、参考書では、以下のp126の一文だけでしょう。
近代図書「ボーリングデータの見方と活用ノウハウ」

HPではいくつかあります。
例えば、東北地質調査業協会でも、3倍の説明があります。
http://www.tohoku-geo.ne.jp/technical/qa/07/index.html

発表要旨もいくつかあります。しかし、3倍で良い、3倍じゃダメ、いろいろです。いずれにしても、発表程度では会検に耐えられません（ココまで指摘されるんですね）。


個人的には、地質によって長短比が異なるため、実際に河原などで測るようにしています。でも、それが3倍よりも小さいと、設計者は3倍として扱うことが多いようです。

ま、そのようなところまで根拠を求める方もいらっしゃると、頭の片隅においておきましょう。

面流量

要素の面を通過する流量について。

境界面なら、節点流量で計算できます。が、モデルの中の節点は+-0なので、集計できません。

計算するとすれば、以下の手順でしょうか？

要素No.チェック
面No.チェック
面の構成節点チェック
節点の座標チェック
3点から２辺のベクトル作成
２辺のベクトルから外積計算
要素流速から合成ベクトル作成
法線ベクトルと合成ベクトルの内積計算
面積をかけて流量とする。


いえ、適当です。組み立てていかないと、正しいかどうか分かりません。書いている途中から実務では無理だと思いましたので。

やはり、ポスト処理のソフトを使うべきですか。

NHKスペシャル 汚染水 ～福島第一原発 危機の真相～

NHKスペシャル　汚染水 ～福島第一原発　危機の真相～
http://www.nhk.or.jp/special/detail/2013/1201/

地下水の流れに汚染がのることは、TEPCOさんなら、重々承知されていたことでしょう。
ただ、わかっていても、できなかったのだと思います。

一方、番組では現在も漏洩の原因を究明していく体制が映されていました。現場で船を操作する映像にも、後ろに余裕のありそうな方が映っていました。

違和感の多い番組でしたね。

浸透流計算が収束しない その2

また、後輩からヘルプ。Dtransu で初期定常が収束しないとのこと。
http://phreeqc.blogspot.jp/2012/08/blog-post_25.html

改良済みの UNSAF なら回るのに、Dtransu だと回らないそうです。地下水や雨がオーバーフローした時の取り扱い方が違うのでしょうね。
Dtransu は、降雨浸透境界に降雨があり、さらに正の水圧がかかると P=0 の水頭固定となります。私は UNSAF を使用しませんので、どのように改良されたか知りません。知る必要がありますね。

原因としては境界条件の張り方や透水係数のオーダーなどいくつかあったのですが、やはり根本は不飽和特性。
これを簡易に回避している資料が、原子力安全基盤機構さんより公開されています。
http://www.jnes.go.jp/content/000117846.pdf

なお不飽和特性に関しては、収束性の観点より飽和度の低い領域では比透水係数の最小値の最小値を0.2として設定して補正を行った(図3.8は補正を行う前のものである)。

なお、AC-UNSAF3DにおいてはDtransu・3D・ELとほぼ同様な結果が得られた。
3D-SEEP及びTOUGH2においては,上述の通り適切な涵養量を設定できずDtransu・3D・EL等にて設定した降雨強度をそのまま使用したため、地表において飽和となった領域に対しても設定した降雨強度を無理やり押し込むと言った計算になってしまい水頭が異常に高い結果となってしまった。特にTOUGH2においては、収束性をよくするための不飽和特性曲線に対する補正が行えず、今回設定した収束条件を満たすまで解を収束させることが出来なかった。

広域解析では比透水係数の最小値を0.2とした補正を施したが、小域は山岳部が存在しないことから負のサクション圧が大きくなることはないと考えられること、メッシュ分割が細かいため解析が収束しやすいこと等を考慮し、小域解析では比透水係数の最小値を0.01に補正した不飽和特性曲線を使用した(図3.9は補正を行う前のものである）。

うーん、0.2は大きいですね。
解決したといえるのかわかりませんが、ま、悩んでいるのは私たちだけではないということです。