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

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 で可視化するなんてことも可能では？試してみる価値はありそうですね。