やり残し事項 2018-2

今年は地すべり、崩壊、基礎、海上など、スタンダードな調査モノが半分、デスクワークが半分でした。

道具では、思いがけず VRS を使えるようになりました。が、課題に挙げていた2点はそのまま。帯磁率計は来年度購入したいところ。

技術面では、機械学習関連が進みました。
クラウド、GPU利用含め環境を整備し、ストレスなく？計算までたどり着けるようになりました。が、容易に計算できるようになると、今度はデータの質に目が向いてしまいます。今後はデータ収集・整理の仕組みづくりが課題になるでしょう。
ただ、やり残し事項は何一つ進まず。来年はSAR を加えて一つは解決したいところです。

以下、やり残し事項です。

道具
帯磁率計
ガンマ線測定器（携帯型）

技術
動的解析（耐震、液状化）
斜面設計
SAR

コード・ソフト
優先度低：DtransuのCUDA化・・・100万で購入可。
優先度低：PSIｎSAR・・・700万で購入可
優先度中：地表流＋地下水・・・GSFLOW、HydroGeoSphere
優先度中：GMS・・・J-SHISの取り込みまではできました。いつか続きを。
優先度中：OpenMI・・・PHREEQCとDtransuの連成等

中期目標は2年目も進展なし。コチラにシフトしないといけないかな。

大規模データの扱い

メモリに載らない大規模データを、機械学習にかけたい場合にどうするか？

1.メモリに載るように細分したデータを作成
ただし、計算時にオーバーフローする可能性あり。

2.メモリ容量のより大きなマシンで動かす
2-1.PC購入
高価。

2-2.クラウド利用（AWS）
2-2-1. EC2, Cloud Formation
https://phreeqc.blogspot.com/2018/10/aws-2.html
AWS マーケットプレイスに H2O あり。
無料のCPU版でも動くが、計算遅い。
GPU版はソフトの購入が必要（400万）。

2-2-2．SageMaker
コードを準備する必要あり。
＝問題に応じて自由にスクラッチ可能。
＝汎用性を持たせるのは困難

2-2-3. Machine Learning
H2O ライクでお手軽。
データは 100GB まで。
ロジスティック回帰のみ。

思いつくのはこの程度。本当はまだまだ選択肢（と正解）があるのでしょう。
傍にプロが欲しい。

SAR ＋ 機械学習

土木分野において、SAR の認知が広まりつつあるようです。

 PS-InSAR を利用した変位観測を示す文献もちらほら。例えば以下。
古関潤一
道路土構造の維持管理の効率化のための干渉SARによる変状調査方法

地盤工学会誌 66 2018

国交省「社会インフラのモニタリング技術活用推進検討委員会」で SAR を用いた技術開発案が複数採り上げられていますので、認知が広まってきたのでしょう。http://www.mlit.go.jp/tec/monitoring.html

河川堤防では日本工営さんが特許をかけようとされています。が、認められるのでしょうか？せっかく芽吹きそうな分野ですが、広まる前に芽をつぶすことになければよいと思います。ま、従来からあるPS-InSAR や経産省のコンペに出ていた機械学習による崩壊個所自動抽出には特許をかけられないと思いますので、個人的には影響ないでしょう。

近年は、SARデータに機械学習を組み合わせるのが流れのようです。例えば、以下。

山谷 祐貴ほか

CバンドSARデータを利用した 機械学習アルゴリズムによる圃場の作物分類

写真測量とリモートセンシング 56(4), 143-148, 2017

Random Forest 利用

郷右近 英臣ほか

TerraSAR-X画像の機械学習による津波被災地の自動検出

土木学会論文集B2(海岸工学) / 69 巻 (2013) 2 号

Logistic function、SMO（SVM）

支倉 一磨ほか

光学衛星画像とSAR画像の統合解析による東北地方太平洋沖地震の津波浸水域抽出手法の検討
生産研究 / 70 巻 (2018) 4 号

決定木

災害前後 SAR 画像と DEM データを用いた CNN による土砂災害検出
人工知能学会全国大会論文集 / 第32回全国大会(2018) 

CNN、転移学習（ImageNet）

大野 翔平

多偏波 SAR画像を用いた自己組織化マップによる自動目標認識法

電気通信大学　修士論文　2015

私も流れに載って年始早々に開催される東京・大阪の研修に申し込みました。残念ながら大阪は外れましたが、東京の結果は来てません。当たればいいな。

RAPIDS

第三段階は GPU での機械学習。

環境作成には、手軽な NVIDIA の RAPIDS を選択。Docker コンテナを稼働し、ノートブックを開くと、準備OK。
のはずが、そのままでは流れませんでした。Python 3.7 で作成していたコードでしたが、RAPIDS の イメージは 3.5。微調整が必要でした。

最初に試したのは KMeans と DBSCAN。教師なし学習です。コチラは GPU を使用し、すんなり流れました。OKです。

次は教師あり。XGBoot と KNN。
コチラはダメ。個人的に前者は難しく、後者は Faiss のエラーが取れませんでした。コンテナの example でも同じエラーが出ていましたので、早々にあきらめました。

第三段階は50点。
年内に片を付けたいので、次の段階に進みましょう。

Matplotlib

週末は、昼大掃除、夜 python の生活でした。

数千万行のデータの扱いにも慣れ、図化までは早々に実装できました。が、それをブラッシュアップするのに時間がかかりました。使っていたデータに日本語が入っていたため、それを Matplotlib で表示させるとか、変数への手入力箇所を一元化するとか。Python の能力不足でなく、私の能力不足。ま、初心者ですから仕方ありません。
それでも、データ読み込みから複数の図化、出力まで10秒ほどで流せるようになりました。データ規模に対しては速い方だと思います。

使った中でのお気に入りは MatPlotlib の hist2d。最初は散布図を作成していたのですが、同じデータで縦横のビン数を指定すると2Dヒストグラムにしくれます。賢い。
そこから値を抜きだし、演算して新たなデータフレームを作成。pcolor 等を使えば同種の絵ができます。気を抜くと1行・1列少なりますが、そこさえ対策しておけば使える機能です。

まだ（私の能力不足で）使えない機能が山ほどあり、展開も速く、マスターするには道のりの長い言語になりそう。
ま、テストとしての第一段階（CPU での機械学習）、第二段階（大規模データの取り扱い）は終了しました。次の段階に向かいましょう。

巨大CSVファイルの操作

5000万行以上の CSV データを取り扱い。

ファイルサイズは 13GB 程度。
ひとまず、手元の Ubuntu ＋ Python ＋ Pandas で読み込もうとしましたが、途中でメモリ実装分の 24GB を超えたため中止。何も指定せずに取り込んでも大丈夫だろうと安易に試行しましたが、ダメでしたね。
調べてみると、分割読み込み、for ループを利用した分割ファイルの一括操作など、メモリに載らない巨大データの取り扱い方法はありました。が、今回はWin10 に帰り EmEditor で不要な列を削除。半分程度の容量に落とし、再度 Python へ。
今度は読めました。

データフレームにしてしまえば、あとは速い。
describe で簡単な統計量を表示。最小値、最大値等で異常値を確認し、その値を含む行を削除。Nanを含む行も削除。それらのチェックを各列を対象に数度回繰り返せば、4000万行程度になりました。EmEditorだと削除だけでも時間かかりますからね。このあたりは Pyhton ＋ Pandas 様サマ。ありがたい。

できたデータは hdf5 で保存。容量が減って、次回からのアクセスも早くなりました。
これ、今後のデフォにしましょう。

*****************************************************
20181230追記
DASK を試しました。
途中の表示は速いのですが、最後にcsv保存しようとすると、メモリーオーバー。
hdfだと時間はかかるものの保存できました。が、18GBに。なぜ？

Fortran とEXCEL

先輩が Fortran で SCE-UA を改変されていました。

ちょうど EXCEL で作成したタンクモデルの最適化シートのチェックができると思い、お手伝い。RMSE にペナルティを与える箇所だけ修正し、返しました。

Fortran の SCE-UA と EXCEL のソルバーを比較すると、RMSE ベースでは似たようなもの。見た目はどちらもそこそあっていますが、昔の方が見られるとおそらく嘆かれるような出来（RMSE を選択する時点で嘆かれるかもしれませんが）。やはり、データを見て半減期を考えて1段目から合わせていく方が良いように思われます。先輩曰く「データは見たもの勝ち」。よくわかります。

1時間単位で2年間のデータがあったのですが、計算時間は SCE-UA の圧勝。数十秒対数時間のオーダーです。グラフ化まで考えても、長期のデータに対しては EXCEL に勝ち目がありません。短期では手軽でグラフまで描いてくれる EXCEL ソルバー、長期では SCE-UA を選択するのが現状では BEST でしょう。

まだまだ Fortran を捨てられません。

災害と降雨にかかわる文献

たまっていた文献にざっと目を通しました。
※20181230追加しました。

災害と降雨指標

複合土砂災害シミュレータSiMHiSを用いた山間地域における土砂災害の警戒避難情報の提供に関する一考察
山野井 一輝, 藤田 正治
砂防学会誌 / 69 巻 (2016) 6 号
https://www.jstage.jst.go.jp/article/sabo/69/6/69_15/_article/-char/ja/
H26広島土砂災害、H25伊豆大島土砂災害、H23紀伊半島大水害のスネークラインを区分

斜面崩壊の誘因となった降雨の評価手法
小杉 賢一朗
砂防学会誌 / 67 巻 (2014) 5 号
https://www.jstage.jst.go.jp/article/sabo/67/5/67_12/_article/-char/ja/
4つの災害事例において崩壊発生時間には降雨の既往最大値超過
深層崩壊の方が表層崩壊に比べて実行雨量半減期大

RBF ネットワークを用いた土壌雨量指数の確率評価について
五十嵐淳博ほか
平成26年度砂防学会研究発表会概要集
http://www.jsece.or.jp/event/conf/abstract/2014/
100年、50年、30年、10年超過確率の土壌雨量指数は、RBFN出力値0.4、0.5、0.7、0.9に概ね対応

日本列島における土砂災害発生危険性を高めた大雨の空間分布とその地域的特徴―土壌雨量指数を用いて―
瓜田 真司, 齋藤 仁, 中山 大地, 泉 岳樹, 松山 洋
地学雑誌 / 120 巻 (2011) 4 号
https://www.jstage.jst.go.jp/article/jgeography/120/4/120_4_615/_article/-char/ja/
過去10年間のSWIの履歴上位3位以内を更新する降雨を「大雨」と定義し抽出


災害要因の分析と予測

地域への適用性をふまえた斜面崩壊発生確率のモデルとアウトプットの開発
齋藤 洋介, Thuy Thi Thanh LE, 川越 清樹
土木学会論文集G（環境） / 73 巻 (2017) 5 号
https://www.jstage.jst.go.jp/article/jscejer/73/5/73_I_229/_article/-char/ja/
多重ロジスティック回帰（標高・斜面傾斜度・表層土壌・降水量）
250×250mまでダウンサイジング
空間解像度の細分化により地形的要因の影響が高まる
動水勾配0（水の影響を考慮しない）場合、発生確率の高い地質の序列は崖錐、凝灰岩、泥岩、花崗岩、礫岩、安山岩
泥岩は動水勾配の上昇に対して鈍感

数値地理情報と降雨極値データを利用した土砂災害発生確率モデルの構築
川越 清樹
自然災害科学 27(1), 69-83, 2008-05-31
https://ci.nii.ac.jp/naid/110006812761
地質4区分（崩積土・新第三系・古第三系・花崗岩）
多重ロジスティック回帰（地質・起伏量・動水勾配データ（降雨・浸透流））
土砂災害発生確率モデルを構築
再現期間10年の土砂災害発生確率は急峻な山岳地が中心
中国山地の山裾部でも高い地域あり
解像度1kmの発生確率は50mの発生確率と概ね同値

ロジスティック回帰分析を用いた土砂災害発生危険基準線の確率的評価
篠崎 嗣浩ほか
土木学会論文集Ｆ 66(1), 122-131, 2010
https://ci.nii.ac.jp/naid/130004468701
災害発生時刻以前で最も小さいRBFN値
・ピークと発生が一致・・・ピークのRBFN値を採用
・ピーク前に発生・・・発生前の最小値を採用
・ピーク後に発生・・・ピークのRBFN値を採用
ロジスティック回帰によりRBFN値を確率値として表示

機械学習を用いた1kmメッシュごとの斜面崩壊に対する危険度評価
https://ci.nii.ac.jp/naid/40021669817/
伊藤 真一ほか
地盤工学会誌 66(9), 8-11, 2018-09
いくつかの機械学習手法を利用し、崩壊・非崩壊を教師として学習。GBMの予測性能が良かった。

土砂災害発生に関わる降雨規模と地質の関係分析
国土交通省 国土技術政策総合研究所　池田ほか
http://www.jsece.or.jp/event/conf/abstract/2017/pdf/518.pdf
・降雨・土砂災害・地質の情報をすべて 5km メッシュ単位で整理。
・土砂災害発生状況には、土砂量や崩壊地形などを網羅的に精度良く整理することが困難であるため、土砂災害の発生件数で整理。
・降雨データには、解析雨量・土壌雨量指数・Surface データを用いた。各メッシュにおいて、1988 年～2007 年の土壌雨量指数および RBFN 出力値の最大値（最小値？）を整理し、 2008 年～2014 年でその最大値（最小値）を超過する降雨を 抽出し、これを履歴順位 1 位相当の降雨とした。
・地質データには、20万分の１土地分類基本調査の結果を用いた。指標には岩石区分を用いることとし、メッシュに複数の岩石区分が含まれる場合 は、面積割合が最も大きい区分を代表区分とした。
・①RBFN 履歴 1 位降雨では複数の土石流が発生するポテンシャルが高いこと、 ②SWI履歴1位降雨とRBFN履歴1位降雨で災害が発生しやすい岩石区分が異なることが示唆された。また、③履歴順位 1 位相当の降雨では西日本の方が災害発生率が高い場合が多く、東日本と西日本で履歴順位のもつ意味が異なると推察された。


土砂災害警戒情報の対象とする災害

最近の豪雨による土砂災害と警戒避難強化に向けた取り組み
岡本　敦
平成30年度（公社）日本地すべり学会総会およびシンポジウム
https://japan.landslide-soc.org/symposium_index/symposium_symposium.html
基準雨量設定の対象とする現象は「土石流及び集中的に発生するがけ崩れ」
「集中的に発生するがけ崩れ」とは、土壌雨量指数が一定以上になった場合に一連降雨のピーク付近で、一定の範囲で発生する崩壊として定義。

都道府県と気象庁が共同して 土砂災害警戒情報を作成・発表するための手引き
国土交通省水管理・国土保全局砂防部・気象庁予報部
 平成17年6月 平成27年2月改訂
http://www.mlit.go.jp/river/sabo/seisaku/tebiki_h2702.pdf
土砂災害警戒情報は、個別の災害発生個所・時間・規模等を特定するものではない。
土砂災害警戒情報の基準設定は、一連の降雨のピーク付近で、ある一定の範囲で発生する急傾斜地の崩壊や土石流が発生した際のデータ等に基づく。
降雨に関係なく発生する散発的な急傾斜地の崩壊は発表対象でない。
深層崩壊等も発表対象でない。
地すべりも発表対象でない。（国や都道府県等が個別箇所毎に実施する移動量等の監視・観測等の調査結果等に基づき、 市町村が避難勧告等の発令の判断をする等が原則。）

￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣

全国的には雨だけで災害発生・非発生を区分できません。履歴1位に近いほど災害発生の危険性が高いというのも半分正解で、半分間違いでしょう。根拠データを見せてほしいところです。
残念ながら、現段階では全国を網羅した質の良い「災害発生データ」「崩壊データ」等はありません（文献の中にはその指摘もありました）。したがって、議論はいくつかの仮定や災害の定義、あるいはローカルな話題に絞られています。
まずは、質の良いデータを全国的に収集できるシステムを整備すること、ターゲットを「災害」にするのか「崩壊」にするのかを絞ること、扱う「災害」の定義を明確にすることなどが先決です。
多次元を扱える機械学習は予測に必要ですが、データの質を上げることの方が予測精度向上に効果的でしょう。

フレーズ

専門分野の技術資料は英語でも読みますが、それだけです。
専門分野外や日常生活に出てくる英語はわかりません。

Darren Cook「Practical Machine Learning with H2O」では、時折わからないフレーズが出てきました。


call it a day

black swan

It sure is trendy

cut to the chase

dive into

spoil the party

jump straight in

suck all the marrow out of

on a hunch

socially awkward

英語を使う環境にあれば自然と覚えられるのでしょうけど。
日本語も拙い年寄りに、今から実装するには難しい。

S波速度はN値から？

設計者より質問を受けました。
「PS検層（ダウンホール）結果とN値からの推定で、表層部のS波速度が合わない。なぜ？」

なぜ？と問われても、知らない現場の話です。一般論を伝えました。

・盛土の不均質性
本試験30cmのN値は不均質性の影響を検層よりも受けやすい。

・手法上の問題
ダウンホールではoffsetが必要。表層は深さ方向の速度でない。

・補助的な探査
上記の理由により、補助的な探査を実施する場合がある。

・技術者のミス
初動走時の認定ミス。

個人的には、検層のS波が正解で、N値のばらつきが推定誤差の原因と判断すべきと考えます。平均的でないN値からS波速度を推定しても一致するわけがないのです。


先日、物理探査学会のH30講演論文集を読んでいて、それと同じことを発表されている方がいらっしゃるのに気づきました。

稲崎富士「PS検層をめぐる技術的課題（その3）S波速度データの活用と地盤物性との関連性検討」

「N値10の場合、Vsが100~350m/sの間でばらついており、推定精度が低いと言わざるを得ない」という趣旨のの指摘を受けた。

これに対し筆者は上述の標準貫入試験に関わる重大な問題点の存在を指摘するとともに「Vs200m/sの場合N値が2~50程度の間でばらついており、N値の測定精度が極めて低いことが端的に示されている」と反論した。

うまい表現だと思います。N値信仰もほどほどにしないとダメですね。

この論文のほかにも、手法の比較や信頼性の表現についての発表が掲載されていました。まだ数年はPS検層にかかわる検討を続けられるようですので、今後の報告を楽しみにしておきましょう。

タンクモデル その3

菅原正巳「続・流出解析法」1979年

自動最適化の話がメインです。というか、そこに至るまでの経緯が書かれていました。

序文にて悲しみに共感、読み始めて考え方に共感。人物像にひかれて googling すると、2011年に鬼籍に入られたようでした。

技術図書というよりか、読み物として面白かったです。
以下、印象に残った個所です。

p41
絶対誤差では流量の大きい箇所で大勢が決まってしまう。
相対誤差の利用：　√((log推定流量ーlog実測流量）^2の平均）
p113

これは、ペナルティ関数で対応していた問題です。
誤差関数の選択肢は試してみましょう。

p67
自動最適化プログラムは試行錯誤法で十分良いパラメータが得られた後に用いるものである。
p69
試行錯誤が不十分な段階で自動最適化を行うと、あるいは収束しなかったり、非現実的な解に収束したりする。
p102、103
タンクモデルのパラメータはかなり鈍感で、かなり異なったパラメータの組が、似たハイドログラフを与えるのである。

これも心当たりがあります。妥当な値に収まるよう、探索範囲に制限をかける作業が必要でしょう。

p73
3段目タンクは15日とか1月を単位とし、4段目タンクは6か月とか1年を単位として入出力を解析する。

妥当な値の範囲として使えます。

p76
（α0+α1）が減衰の仕方を決める
α0：α1が流出量を決める

先日覚えた根本的な理論ですね。

p78、p97
出発モデル

気象庁のモデルと共に、出発点として使いましょう。

p105
最適解が得られることは審美感を満足させるし、実用上からは説得に便利であるから、重要視されるのは無理もないが、ある種の最適解は不安定で、条件や評価法のわずかな変化により、大きく揺れ動く。最適解と大差がない多くの解が広範囲に分布しているときは、前提条件や評価を少し変えることによって、最適解が広い範囲を動き回るのである。

 難しいですね。

p143
私には、自動化は現代の必要悪の一種に思われる。自動化によって、人間の考える自由、したいことをする自由、ものを創り出す喜びが失われ、感受性、判断力、行動力が失われていく。便利や、省力化の代償として、失われるものが時としてはあまりに大きいことがある。
この自動化プログラムを、試行錯誤法の際の一つの道具として使うことにより、人間の思考力、洞察力、感受性などが損なわれることなしに、能率が増進することになれば、手間が省けることにより、パラメータ探し以外の、大切な水文学的問題に、人間の思考力、洞察力、感受性等が向けられることになるならば、私としてはこれに過ぎたる幸せはないし、またそうなることを切望している。

前半は「流出解析法」を読んだ際に痛感させられた内容です。
最近読んだ文献では、パラメータの全自動最適化のみでなく、段数や横孔数といった構造まで自動で求めようとしていました。時間を作るために自動化されたものが、素人に考えるチャンスを奪ってしまう道具になりかねません。
後半は、まさにその通り。考える時間を生むために省力化を図るのであって、大量消費・高速処理自体が目的になってはいけません。これはすべてに共通する考え方です。

この方の話、直接伺ってみたかったですね。

タンクモデル その2

菅原正巳「流出解析法」

この図書の出版が1972年（昭和47年）。直列貯留型ができたのは1956年（昭和31年）。
当時、タンクモデルは手計算とか、手回し計算機？が主流のようで、後半は OKITAC？とかが使われていたようです。いずれにしても、多変数を数秒～数分で最適化できるような能力はなかったでしょう。

ではどうしたか？

人の能力は大したもので、経験である程度のパラメータのあたりをつけることができたようです。そのうえで調整を行っていたらしい。この図書にはその手順が書かれていました。昔の人は本当にすごい（作ったEXCELツールが、なんとも薄っぺらく感じます）。
幸い、丁寧にまとめられていましたので、その理論・ノウハウ等は理解できました。ありがたいですね。案外簡単なので、1段目くらいは私でも大丈夫でしょう。

あたりをつけて EXCEL での探索範囲を絞ったり、経験上の値と照らし合わせたり、異常な結果が出ていないかチェックしたり。これでまともな計算ができそうです。
いえ、危なかったですね。

タンクモデル

タンクモデルのパラメータ最適化に、SCE-UAでなく、EXCEL ソルバーを使おうと考えました。

理由は「簡単だから」＆「文献であったから」。

わざわざプログラミングしなくても、大域的最適解（らしきもの）をソルバーで求められます。四則演算のみで負荷のかかる計算ではありません。VBA も必要ないので、ペナルティ関数やタンクの段数、横穴の数などカスタマイズが容易になります。パラメータ推定が終わればグラフも自動で更新されるので EXCEL の方が数段便利。

気象庁のホームページに3段の式とパラメータがあります。まずはこれを手本に組んでみました。が、タイムステップの取り方がイマイチわかりにくい表現になっており、また配信されている土壌雨量指数は補正がかかっているので、正しく組めているのか検証できません。
何か検算できる資料はないか、と古い資料「流出計算例題集2」を引っ張り出してきました。が、この計算例も時間の取り方が怪しい。

ま、基本に返りましょうと、菅原正巳「流出解析法」を見直し。というか、以前は眺めただけでしたね。数式部分を少し補足しながら書き下しておきましょう。


*********************************************
降雨を0とすると貯留高Sの時間変化（減少）は
-dS/dt=αS+βS=(α+β)S

λ=α+βとおくと、放射性元素の半減期と全く同じ式となり、変数分離型の解法が使えます。
-dS/dt=λS
-dS=λSdt
∫(1/S)dS＝-λ∫dt
lnS=-λt+c

t=0のときS=S0とおくと
S=S0e^（-λt）
S0=e^c

半減期t=TのときS=S0/2で
1/2=e^（-λT）
2=e^λT
ln2=λT
T=0.693/λ

つまり、（α+β）によって半減期が決まる。
というか、タンクモデルは指数関数型で多段の場合はその重ね合わせになっているのね。今まで理解していませんでした。


Δtにおける貯留高の変化は
S0-S0e^-λΔｔ
=S0(1-e^(-λΔｔ)）

Δｔ当たりの流出高は、マクローリン展開で
S0(1-e^(-λΔｔ)）（α/λ）
=αS0（1/λ-(e^(-λΔｔ)/λ）
=αS0（1/λ-(1-λΔｔ/1!+λ^2Δｔ^2/2!-λ^3Δｔ^3/3!・・・・)/λ）
=αS0（1/λ-(1/λ-Δｔ/1+λΔｔ^2/2-λ^2Δｔ^3/6・・・・)）
=αS0（Δｔ-λΔｔ^2/2+λ^2Δｔ^3/6・・・・)）

α+βやΔｔが小さいときは2項以下を無視して
≒αS0Δｔ

単位時間当たりの流出高の変化は
≒αS0

ってことでしょう。実測流量にあわせこむ際には、数項分の影響を考慮したαが得られるということ。
***********************************************

理屈では、タイムステップの取り方に間違いはありません。組み込みの際のミスチェックに何らかの検証は必要ですが、ひとまず、ペナルティ付き・1~4段タンク・最大18パラメータの最適化付き EXCEL シートができました。

多変量正規分布

確率密度関数を扱っていて、ふと思いつきました。

「今取り扱っているデータの分布って、2次元正規分布で近似できるのでは？」

早速、EXCELで組んでみることに。

っと、式がわかりません。1次元の確率密度関数を掛け合わせて、回転させるだけだった？と思いながら検索。

ありました。高校数学でした。orz
多変量正規分布の式。これの最も簡単な形が1次元ですね。

まずはテスト。
シート1に2次元正規分布の値を計算で入れます。
シート2に別の値。
シート3に誤差。
目的変数は RMSE にしました。
シート2で使用したパラメータ６つをソルバーで解くだけ。簡単。

結果は完璧。
正規分布は正規分布で完璧に近似できるというだけのチェックでした。
で、実際のデータ。

結果は惨敗。
正規分布ではなかったということ。
他の確率密度関数で試してみますか。

Win10 + Ubuntu + Fortran

windows10 で Fortaran コードを編集・コンパイルしたいとのこと。

少し古い方に相談されていたみたいで、Cygwin + gfortran を進められていました。が、Cygwin がうまく入らないとのこと。
それなら、ということで Windows Subsystem for Linux をお勧め。Windows10 に Ubuntu を入れ、gfortran を使えるように。

フォルダ・ファイル等の permition の変更、ディレクトリの表現に気を付ける必要はありますが、Win とのファイルのやり取りは容易。Win からファイルを Ubuntu の home/ユーザーフォルダ内に移動して、コンパイル。そのまま計算して結果を Win ＋EXCELへ。

ま、ちょっとした計算ならコンパイラーを買うまでもないですし、デュアルブート を構築することもないでしょう。
Win10では、ずいぶん手軽になりました。

Amazon SageMaker

SageMaker の ハンズオンに参加。

内容は初心者向けでしたが、私には非常に効果的なレベル。というかギリセーフでした。半年前なら全く理解できていなかったでしょう。
参加者の顔ぶれを見ると働き盛りの若い方が多く、健全な分野と感じます。講習会といえばおじさんばかりの建設業界の異常さをあらためて認識させられました。

以下、備忘録です。
****************************************
フロー
①Sagemaker で開発
②Dodker 利用で学習環境に移行、学習、API化
③推論は API 利用
開発・学習はSagemaker、推論はオンプレミスというように、部分利用可

アルゴリズム
①AWS ビルトイン利用
・学習データのみ
②TensorFlow 等、一般的なモデルを使用
・学習データと開発したコードが必要
・Docekerでコンテナ作成
③それ以外
・学習コードと推論用 Web サーバが入ったコンテナを ECR に push
・学習データは S3 へ


開発と学習・・・データサイエンティストが SageMaker SDK を使ってJupyterで。
デプロイ~推論・・・機械学習と関連のないエンジニアリングが大半・・・インフラエンジニアが AWS SDK を利用
役割の違うチームがそれぞれに合ったツールを利用

ビルトインで気になったアルゴリズム・・・Image Classification（教師あり）
・ゼロからトレーニング or 大量のデータを用意できない場合に転移学習を使用
・ResNet を使用。
https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-algo-docker-registry-paths.html


学習時のＴｉｐｓ

・分散学習
instance_count を2以上で自動で分散学習
⇒基本はデータを分割
Tensorflow/Chainer/PyTorch/MXNet → instance_countに加えてコードも分散学習に対応させる必要あり。

・ハイパーパラメーターの自動チューニング
Estimater 初期化時に hyperparameters で引き渡すパラメータに関し自動チューニング
Tensorflow/Chainer/PyTorch/MXNetでも利用可

・学習ジョブの評価
CloudWatchLogs、後から集計

・Tensorflow
AWS 側で Tensorflow の分散学習に最適な Docker コンテナイメージ用意
https://github.com/aws/sagemaker-tensorflow-container

・大量データの読み込みにpipeモード
PIPE：学習用データを必要なタイミングで必要な分だけ S3 API 経由でストリーム処理
Tensorflow ： TFRecord フォーマット
MXNet ： RecordIO フォーマット


推論時のTips
・オートスケーリング
・Tensorflow
AWS 側で Tensorflow の推論に最適な Docker コンテナイメージ用意


セキュリティ
学習時の入出力データ、インスタンス、ストレージ、バッチ推論時の入出力データは暗号化可能

amazon-sagemaker-examples
https://github.com/awslabs/amazon-sagemaker-examples
SageMaker SDK
https://github.com/aws/sagemaker-python-sdk

出席者
Tensorflow 半数
次いでChaneir 、Keras
Pytorch　０
MXnet ０


不要な課金を避けるため、
エンドポイントの削除
ノートブックの削除
※停止でも良いが、S3に保存したデータは課金される
s3の削除
ログの削除
※ログは微々たるもの。置いたままでもOK
※トレーニングジョブは課金対象でなく、日がたつと自動で削除される。
ロールを削除
※課金対象ではない。