かけやによる起振

今日は表面波探査。

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

ギリギリの工程が予想されたので、今日は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 を使って推定するのは特許に引っかかりそうですし、それなら今まで通り実効雨量と回帰分析で十分です。これは、雨量と水位から推定させる方針にした方が良いのでしょうか？そうなると、井戸の枯渇が施工の影響かどうか？といったような問題には適用できなくなりますが。うーん。