かけやによる起振

今日は表面波探査。

施工が止まる日曜日を選んで実施しました。
いつもと異なり非常に静かで、天気も穏やか。条件は最高です。

ギリギリの工程が予想されたので、今日は4人。私は本部担当ですので、残り3人で起振を担当。
かけやで叩き始めると、測定は早かったですね。

測定画面を見ていると、特にきれいなデータを叩き出す方がいらっしゃいました。画面だけ見ていても、その方が叩かれているのが分かります。他の方との差は微妙なのですが、やはりわかるのです。叩く動作に差は認められないのですが、違いが出ます。なぜでしょう。

その話を帰りの車でしていたら、後輩も同じ体験をしていました。ある現場で、一人だけ綺麗な波形を出す奴がいた、と。

綺麗な波形を出す方に共通なのが、現場経験の長い方のようです。ずっとハンマーやかけやを扱っていると、何かコツが身につくのでしょう。それが何かは、本人もわからないようですが、とにかく、何かあるのです。
弾性波の鉄板をたたき割るようなパワーを持っている方ではありません。動きに無駄のない、効率的な打ち方なのでしょうね。

おかげさまで、帰社後のデータチェックでは、高次モードなし、ノイズも少ないデータとなっていました。生データのまま逆解析をかけても、エラーなし。今後の解析のツメが楽になりそうです。

気持ちの良い現場でした。

水位予測 using deep learning その4

雨量と水位を使って計算してみました。

今回は関数内で配列を並べ替えたのですが、うまくいきました（雨量は0.01mmを加えています）。

過去48時間から12時間後を予測

過去24時間から12時間後を予測

過去48時間から1時間後を予測

過去24時間から1時間後を予測

つまらないですね。以前と同じ状況です。
https://phreeqc.blogspot.jp/2016/10/using-deep-learning.html

雨量を入れたせいか、特に1時間後の立ち上がりは水位のみからの予測時より改善されたように思われます。が、12時間後はやはり遅れます。直近はそこそこ合いますが、それでは逃げる時間を確保する目的での判断材料に使えません（防災面で利用する場合には、夜間の非難を避けるためにも、ある程度先の正確な予測が欲しいところです）。

過去の参照データを多くすると「なまる」し、少なくする「小賢しい」結果を出します。何か改善点があるはずですが、今の私の頭ですとココまでです。


実効雨量から回帰分析で作った水位と、同じく実効雨量から多層 NN、deep learning で作った水位の比較もしてみましたが、前者の方がよく合っていました。実効雨量自体が過去のデータに時系列で重みをかけて作成されていますので、両者ともに同じような計算をしているはずなのですが。ま、そういう意味では、実効雨量からの水位予測が「よくできている」と、あらためて認識できただけでも良しとしましょう。

deep learning は数値よりも、やはり画像を扱った場合に本領発揮するのでしょうね。

水位予測 using deep learning その3

Nan を回避するのに、はまりました。
前回のUPから5日かかっていますね。

原因はやはり「0」と関数の定義の2種のようです。
ただ、コードの思いつく箇所を修正してもダメ。場当たり的な回避方法は見つけましたが、根本的な対処法はいまだわからず。まだ、Pythonを理解し始めたばかりですので、どこか記述の仕方を誤っているのだと思います。プロが傍に欲しいですね。

まず、関数定義の異常について。
def 内で雨量を読み込ませると、それを計算に使用しなくてもNanを吐きます。最初はVSのバグかと思い、それを経由させずに直接 Python で走らせてみました。すると、より多くのエラーが吐き出されました。
まず、関数を認識しません。インデントがおかしいと、吐き出されます。スペースとタブが混在していたため、そこがおかしいのだろうとタブに統一（今まで、適当に扱ってきたところです）。
次は、関数の終わりを認識してくれません。次の行まで関数として認識されます。これは1行開けることで問題なく修正できました。
さらに、def  内で配列を加算させていたのですが、これもダメなようです。データを読み込む前にEXCELで計算させてcsvを作り、そのファイルを読み込むとNanを吐きません。一方、def 内での加算を使うと、Nanを吐きます。両者を比べても全く同じ値・並びになっているのですが、なぜか後者だけNanを吐きます。理解できません。

「0」に関しては、まず一番に疑っていたのですが、前回、適当な数値を def 内で足しても Nan を吐いていましたので検討から外していました（前回は加算の方で引っかかっていたようですが）。
しかし、0にいくら重み係数をかけても0でしょうから、やはり調整は難しいのでしょう。
対処法は先にEXCEL内で雨量に0.01mmを加算しておくという場当たり的なもの。これを直接読み込めばNan は吐き出されなくなりました。

で、計算！

が結果が悪い。

2層ほど追加してみましたが、予測形状は変わりません。ま、あたりまえの結果ですね。
過去24時間の雨量データを使っていますので、雨量のない日は一律0.01mmになります。それ以上の長期雨量は考慮されませんので、基底がフラットな形状に近くなるという訳でしょう。実効雨量に半減期の考え方が取り入れられているのも、こういったフラットな形状を回避するためなのでしょうね。違うツールを使って初めて気づくその工夫。思いつかれた方は凄いとあらためて感心。

で、使用するデータを過去24時間から240時間に変更。

ダメでしょう。これは。

もう少しケース数を増やさないと結論は出せませんが、雨量のみから水位を推定するのは得策ではないようです。複数期間の実効雨量から deep learning を使って推定するのは特許に引っかかりそうですし、それなら今まで通り実効雨量と回帰分析で十分です。これは、雨量と水位から推定させる方針にした方が良いのでしょうか？そうなると、井戸の枯渇が施工の影響かどうか？といったような問題には適用できなくなりますが。うーん。

水位予測 using deep learning その2

今度は雨量から水位を予測。正攻法です。

使うのは先日のコードとほぼ同じ。読みに行く先を水位から雨量に変更しただけです。

で、テスト開始！

がダメ。ロス関数が nan を返します。うーん、雨量の連続 0mm で引っかかっているのでしょうか？

雨量に0.1を足したらどうなるか？

ダメ。

では、30では？

これもダメ。データが原因ではないのでしょうか？


では、ロス関数を変更すればどうなるか？

optimizer を変更すればどうなるか？

活性化関数を変更すればどうなるか？

バッチ数を増やせばどうなるか？

隠れ層を減らすとどうなるか？


全てダメ。


うーん、小手先の操作だけでは対応できませんでした。素人だとここまででしょうか？
中身を理解して計算を追う必要があるのでしょうね。deep learning のアルゴには全く興味を惹かれないのですが、どうしましょう？

水位予測 using deep learning

まずは「24時間先まで予測させてみる」をテスト。optimizer は adam で変更なし。

24時間すべてでなく、24時間後のみを刻々と予測させる方針の方が見た目がよくなります。、コードの改変もほとんどありません。

過去10時間の水位データのみを使って、24時間先を予測。結果はこちら。

最高水位やピーク位置はあってないですが、 形状はあってます。ズレは24時間。実際に上がるのを確認してから、予測も追随して上がってくるのでしょう。当たり前ですか。



では、過去240時間（10日間）のデータで額種させるとどうでしょうか？

全くダメですね。考えすぎです。



では逆に、5時間に短縮するとどうなるか？

あ、これです。
ピークの形状は合いますが、ずれてます。HPの旅客データもそうでしたね。
http://machinelearningmastery.com/time-series-prediction-with-deep-learning-in-python-with-keras/

We can see that the model did a pretty poor job of fitting both the training and the test datasets. It basically predicted the same input value as the output.

そういうことだったのですか。違和感の正体ですね。全くダメです。
察するに、使用データが単純になる程、24時間先もそれに近い値を選択すれば誤差が少なくなる、というように学習したのでしょうね。賢いのか、ポンコツなのか。小賢しい能力です。

やはり雨量をトリガーとして教えないとだめでしょうか。

続きは後日。

ベテラン勢で弾性波探査

今日はベテラン勢4人で弾性波探査。

4人中3人は、本部を担当することができます（昔の調査屋さんは皆できたそうですが、今では少なくなりました）。

そのような面子でこなすので、指示なくとも連携良く、作業は速く、楽でした。ベストメンバーだったと思います。


帰りは私が運転していたのですが、後ろに陣取った2人は最初から寝る体制。ベテラン故、体力を使い切ったのでしょう。現場ではシャキシャキ動いていたのですが。

そういえば、探査の習得を希望する若い方はいないですね。おそらく、やらないといけないことに追われ、それどころではないのでしょう。ノルマや覚えないといけないことも多々あるのでしょうが、現場で踏査や探査を行うと、理解の仕方も違ってくるように思います。

ま、チャレンジしないといけないのは、若手もベテランも、関係ないですね。


 

多層ニューラルネットワークと時系列予測

先のコードを確認しながら、水位予測結果の（綺麗すぎる）一致の原因を探ってみました。

過去10時間の水位データを使って、1時間先の水位を予測しようという方針になります（時系列は「分」でも「日」でも等間隔であれば、特に気にしなくてよい部分です）。

ただし、若干の変更を加えました。
・データ長をフルで読めるように修正した。
・隠れ層を追加した。
・エポック数を減らした。
・格納されたデータを表示し、確認できるようにした。

ネットの情報や買ってきたPython の本を見ながら1行づつ確認したのですが、おかしなところは見つけられません。うーん、でも、納得できません。
これ、1時間後という設定がまずいのでしょうか？人の感覚でも、データが得られるたびに直近の勾配を延長しとけばある程度の挙動は一致するような気がします。機械学習の結果、近傍の勾配を重視するようなモデルを作り上げたのかもしれません。
ただ、旅客データでは、ここまで一致しなかったことを考えると、データの質の相違に起因する可能性が考えられます。水位の方が単純でノイズが少なく、予測しやすいとか。あー、傍にプロが欲しいですね。

私の知識ではコレ以上は分かりませんが、ま、正しい結果として受け入れるべきなのでしょうね。良いことではありますが。

今後の方針としては、以下の通りでしょう。
1.　24時間先まで予測させてみる。
1時間後という設定がまずいのであれば、さらに先まで予測させて状況を見てみるのが次の手でしょう。出力が24個になるので少し考えないといけないですね。
うまくいけば、WEBベースでデータ収集から結果表示までが可能となりますので、河川の防災情報などに使えそうですね。

2.　雨量から予測させてみる。
複数の入力値から1つの値を予測するといったこのコードは、どちらかというと雨量からの予測に適しているように思えてきました。トレーニング等に使用した水位データを雨量に変更し、水位予測をしてみましょう。これまでの実効雨量計算に対し、多層ニューラルネットワークを利用するといった方針です。これがうまくいけば、施工の影響についても今まで通り、判定できますね。

*******************************************************
参考にしたネットの情報
https://keras.io/ja/optimizers/#adam
https://arxiv.org/pdf/1412.6980v8.pdf ←後で読むこと
https://keras.io/ja/activations/